Re: Offer to take over sdlperl package
Le Wednesday 13 July 2011 16:01:26, Jon Dowland a écrit : > Shortly, the Debian Games Team will be co-opting the sdl maintainers team, > which is all but defunct. > > We would welcome you into the team if you would like to help to co-maintain > sdlperl: how does that sound? Great ! :-) I'll maintain sdlperl's dependencies as part of debian-perl team. My account on Alioth is dod. Do not use ddumont-guest, as this account will eventually be removed. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/
Bug#633953: ITP: tyxml -- typed XML in OCaml
Package: wnpp Severity: wishlist Owner: "Stéphane Glondu" * Package name: tyxml Version : 1.91 Upstream Author : Thorsten Ohl, Vincent Balat, and others * URL : http://ocsigen.org/tyxml/install * License : LGPL Programming Lang: OCaml Description : typed XML in OCaml TyXML allows one to build XML trees whose validity is ensured by the typechecker. It's based on a traduction of XML types into polymorphic variants, originally written by Thorsten Ohl. Currently, the transcription has been done for XHTML 1.0 and 1.1, HTML5 and SVG (partial). . TyXML also provides a generic printer and some low-level (and untyped) iterators over XML trees. The printer has options for printing XHTML in more browser-friendly way when served as "text/html" (instead of "text/xml"). HTML5 is always printed with those options. . All modules provided by TyXML are also provided in functorial interface, where every module is parameterised by the underlying XML representation. . A camlp4 extension, named Pa_tyxml, allows one to write HTML pages or HTML fragments with the usual syntax. Part of this library is already part of Ocsigen 1.3. It has been split out and extended, and is a new dependency of Ocsigen 2. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715113748.26198.15494.report...@korell.up7.fr
Improving package descriptions (I)
Hi, some time ago I read a post of the DPL regarding enhancing package description quality. Bug reports from translators should be a means for achieving this goal. (quoting from the developer's reference, section 8.4:) Best current practice concerning l10n ... As a translator, if you find an error in the original text, make sure to report it. Translators are often the most attentive readers of a given text, and if they don't report the errors they find, nobody will. Sometimes when beginning a new translation for a package description being part of Debian for quite some time I encounter descriptions which I consider faulty/improvable. Does it make sense to report errors concerning stable/oldstable when there are more recent descriptions? Should one use specific tags for the bug reports? If yes, are there appropriate ones (debian-i18n, debian-l10n, ...)? Kind regards, Martin P.S: I'm subscribed to the list. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e202d93.7020...@gmx.de
Bug#634003: ITP: conky-all -- highly configurable system monitor (all features enabled)
Package: wnpp Severity: wishlist Owner: Vincent Cheng * Package name: conky-all Version : 1.8.1 Upstream Author : Brenden Matthews, Philip Kovacs, et. al. * URL : http://conky.sf.net/ * License : GPL3, BSD Programming Lang: C, Lua Description : highly configurable system monitor (all features enabled) As part of my plans to adopt Conky, I've decided to split it into 2 source packages, conky and conky-all. Refer to #579102 for more info. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715203532.13968.35216.reportbug@vincent-laptop
How Debian Deals with Data
Hello All, I currently have two packages in the archive, one small ant related package (ant-contrib-cpptasks) and a FlightGear related package (fgrun). But its the FlightGear packaging I want to talk about. For those of you that have yet to enjoy playing with FlightGear, its a very flexible and powerful flight simulator. As a program, its not that big, but it has lots of data. The real world scenery FlightGear uses is massive ~10GB (I think), this can either be fetched in archives, or by svn (using a program called terrasync). Then there is also the aircraft, numbering in there hundreds (~3GB). Now as far as I know, this amount of data cannot be included in the Debian archives? While there may be perfectly reasonable practical reasons why this cant happen, it is probably inconvenient for those that can install a tiny portion of the scenery and a few of the aircraft through the package system, but then have to struggle fetching the rest by some other less convenient method. Now I was thinking about this, and came up with a few ideas, I will explain probably the best one. If any of you use flash, you might use the flashplugin-nonfree package, now because cant be included in the Debian archives, this package actually downloads the adobe installer and then runs it. Now while this is of cause not a perfect situation. It did get me thinking, what about doing this for the FlightGear data? So, imagine. The user wants to install a portion of the scenery, so they use whatever package manager and install the relevant package. Now behind the scenes, the package has picked out a default fetch method (probably terrasync), and then fetched the data to the correct directory (could ever find the best mirror). Now what about a different user that wants the data in archive form, they could use a debconf interface to select the correct fetch method. Now imagine that a user has the scenery on dvd (as the project sells to raise funds for charity), the package could check for this, and if possible install from there. The actual package would just contain the rules and checksums for the files it tries to fetch, but not the data itself, I think of this as a symbolic package. This approach in my opinion, would make packaging applications like FlightGear much easier, and improve the user experience. Any thoughts, or have I found a non-existent problem? Thanks, Chris signature.asc Description: This is a digitally signed message part
Bug#634008: ITP: ioping -- Simple disk I/O latency measuring tool
Package: wnpp Severity: wishlist Owner: Apollon Oikonomopoulos * Package name: ioping Version : 0.5 Upstream Author : Konstantin Khlebnikov * URL : http://code.google.com/p/ioping * License : GPLv3 Programming Lang: C Description : Simple disk I/O latency measuring tool ioping monitors disk I/O latency in real time. The main idea behind ioping is to have a utility similar to ping, which will show disk I/O latency in the same way ping shows network latency. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715222408.ga23...@noc.grnet.gr
Re: How Debian Deals with Data
On Fri, Jul 15, 2011 at 11:20:09PM +0100, Christopher Baines wrote:
[...]
> Any thoughts, or have I found a non-existent problem?
A very-existent problem (the scientific package maintainers deal
with this at least as much as the games package maintainers from
what I gather). It's come up a lot over the years, but the most
recent productive thread I remember was this one about a
data.debian.org archive proposal for extremely large,
architecture-independent data packages:
http://lists.debian.org/debian-devel/2010/09/msg00692.html
I'm not sure what became of that, but I'm curious to find out since
I'll be staring down the barrel of a similar problem soon enough.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110715223231.gc1...@yuggoth.org
Re: How Debian Deals with Data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Christopher, On 16.07.2011 00:20, Christopher Baines wrote: > The actual package would just contain the rules and checksums for the > files it tries to fetch, but not the data itself, I think of this as a > symbolic package. This approach in my opinion, would make packaging > applications like FlightGear much easier, and improve the user > experience. just as a random alternative idea (where other people may judge whether it is a good idea or not): There might still be benefits of letting dpkg handle the installation stuff, even if you don't want to have such a large amount of data in the archives. This eases maintenance, updates and clean removal of packages. For your purpose it might be worth to consider a half baked solution. For example you could provide a meta package [*] which builds a new binary package on the installation site. Without knowing anything about FlightGear this potentially seems a good solution to me. Your meta package could download your stuff, apply some checksumming and then produce a new binary package with the actual game data. Take a look into the google-earth package for an example what I'm thinking about. Their use case is of course different than yours, but the idea is the same. This binary package may ease installation, transportation and copying of your game's data. By using some nifty dependencies along with "Provides"/"Replaces" relationships you could even do some interesting dependency magic there, although the direct usage of "dpkg" makes it a bit tricky to benefit from it. [*] please don't confuse my usage of "meta package" with its archive-wide meaning for Debian here. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOIM3IAAoJEMcrUe6dgPNtdyEQAK3VVNWiguTMvlFl9JW6Mnua CBTFSDiBAw6Fbhtd4HKqGAe1nRrEkiMtczHnDjOUIKGI7+S9Z+M7nFAkRayz/KLr FMCKxAFuvshxAbNQTUHob6IXk9R/9ZRzRpbMVDiGpkWHSM+I7Mq3PAU2Ix4F+1+j D2JuCUSne9bpuxlFnf/xXZyMkBrHC99EWfoSg+okRI9V9lhVUurf1+bVosMDmium R5v8KktpmFyYSQ9Ik00QAItUxJOkExNAvfdZ+l9bTU5KIGI/lfjOXAbbfASYJ7cL TazM8TNeRadTqtWTC9KkhmplGLYBinNAZzcEPy0fSfGQdOd0u12dMwg1+Pqtmbfa /ivqfRxxlP7mCTXBcq+97Kadh/44Ei3uzxdQ9BQ/ZNj5Po0mCvx6PValrRzRHmaf +DVJhQdBec1ij+H0ouUdw+wzVRgUkL6RWz790jQ1xVB1wrKtwNnSaUiWGM3bQY/L 8eT/JiphCQvVx1ewaefA0q7pzYGT/ZlZ39TEMxtvfiHU+HPpLCPFUlmP8snp1/i+ lNOUwh+jdCQ2OOPt++LERq3a6ubuPtJWlYxEXOL2DZsNsiGRx12mG9hi2eZlGiAJ emOp4PtuF1KNdSg/0Fl5sM1MeJk5FC1BKMf5+LgM27G2mrSKBcwWvqCvFXXofSBj WB4Gbvo5RiH/EFIK6mve =Q03t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e20cdc9.2080...@toell.net
Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
Hi Raphaël, Thanks for looking at ways to improve the dpkg-source experience. On Sun, May 29, 2011 at 10:53:03AM +0200, Raphael Hertzog wrote: > b/ modify dpkg-source --before-build to keep a trace of the fact that >it applied the patches (for example by creating >.pc/dpkg-source-auto-applied) and in that case have dpkg-source >--after-build unapply the patches so that we're back to a clean >state after a succesful build. >If the build fails, we'd keep the patches applied. > My preference goes to b/ because it doesn't require changes for people > who like to keep the patches applied in their VCS too. And it's the > principle of least surprise, you keep the same state afer a build than > you had before the build (so it's still ok for people who rely > on the scenario unpack/hack/rebuild). > Comments? Does this look reasonable? That sounds perfectly reasonable to me. > Again to cope with the scenario explained at the start of this mail, > once a user has made modifications we must ensure that they end up in a > proper patch in debian/patches/. Right now this is entirely automatic, > the generated patches take the form of > debian/patches/debian-changes-. > Obviously this is a pretty poor name for a patch and given it's > automatically generated, it doesn't contain much useful description. > In general they are renamed by the maintainer who also adds a > description (or they are properly put in place before the build so that > dpkg-source doesn't have to create it). > But it still happens that those patches are generated[1] when the maintainer > did not expect any change at all. That's why we added the option > --abort-on-upstream-changes for maintainers who never wants dpkg-source > to auto-create a patch. For me, what's most annoying here is the use of the version number in the patch name. This means, for instance, that if the clean target modifies the contents (maybe by regenerating configure), each package version could create a *new* patch for something that should definitely be represented as part of a single patch. I'm inclined to think that --single-debian-patch is a more directly useful default (possibly without --abort-on-upstream-changes). It doesn't give the best results for patch naming and headers, but if the maintainer is actually going to put in the effort to do all that, I would assume they can change the default anyway. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
