Re: Anniv' Debian 16 août 2009
On mar, 2009-08-11 at 00:29 +0200, Carl Chenet wrote: Mardi 18 ça semble bien. Reste à trouver le lieu. ++ Comme je suis un chafouin, et que j'aime bien les threads qui trainent en longueur sans rien décider, je propose un CHOIX (et ouais !) - Le (tradditionnel) Trappiste, 4 rue St Denis, M. Châtelet ; - La horse's tavern, 16 carrefour de l'Odéon, M. Odéon ; - The Auld Alliance (pub écossais), 80 rue François Miron, M. St Paul. Cheers, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Bastian Blank wrote: On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote: In article 20090811183800.ge5...@const.famille.thibault.fr you wrote: Not necessarily. Any sane implementation should just use wchar_t Which could be UTF16 and therefore still has complicatd length semantics. No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like Windows). No wchar_t is locale dependent (per POSIX). BTW on gcc: -fwide-exec-charset=charset Set the wide execution character set, used for wide string and character constants. The default is UTF-32 or UTF-16, whichever corresponds to the width of wchar_t. As with -fexec-charset, charset can be any encoding supported by the system's iconv library routine; however, you will have problems with encodings that do not fit exactly in wchar_t. Note that default encoding is UTF-8, thus giving a UTF-32 wchar_t in most developer machines. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Giacomo A. Catenazzi, le Wed 12 Aug 2009 07:54:33 +0200, a écrit : Samuel Thibault wrote: Gunnar Wolf, le Tue 11 Aug 2009 13:28:08 -0500, a écrit : while length(str) in any language up to the 1990s was a mere substraction, now we must go through the string checking each byte to see if it is a Unicode marker and substract the appropriate number of bytes. Not necessarily. Any sane implementation should just use wchar_t and substraction gets back. An implementation that use wchar_t is usually not sane, but usually it is (also) buggy. Why? It's just about using wide functions instead of usual functions. PS: note that the binary encoding depend on compiler environment (but such info is not exported). See my other mail. A lot of things can be made to depend on the compiler environment. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Giacomo A. Catenazzi, le Wed 12 Aug 2009 08:03:30 +0200, a écrit : Bastian Blank wrote: On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote: In article 20090811183800.ge5...@const.famille.thibault.fr you wrote: Not necessarily. Any sane implementation should just use wchar_t Which could be UTF16 and therefore still has complicatd length semantics. No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like Windows). No wchar_t is locale dependent (per POSIX). What do you mean? The compiler can't know the locale in advance for the width and endianness. The value might depend on the locale, yes, but that's not a problem as long as you convert into UTF-8 before communicating with other applications. One same systems (Debian systems are), it's just always UCS-4. BTW on gcc: -fwide-exec-charset=charset Set the wide execution character set, used for wide string and character constants. It hurts when I shoot myself in the foot. The default is UTF-32 or UTF-16, whichever corresponds to the width of wchar_t. This documentation is bogus BTW. It should read UCS-4 or UCS-2. Note that default encoding is UTF-8, thus giving a UTF-32 wchar_t in most developer machines. I don't understand this sentence. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Remove control field Conflicts if the package is no longer in the repository
Hello Debian Developers, I've recently uploaded (thanks to Bart Martens for sponsoring) my first package and want to adopt the next one. It's cd-discid [1]. Its debian/control file contains the Conflicts field. This package conflicts with cdgrab ( 0.7), which is no longer exists in the repository. So, I have a question, may I remove Conflicts field safely? 1. http://packages.debian.org/sid/cd-discid Thanks. -- Timur -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
What’s the use for Standards-Version?
Hi, the question in the subject may sound a bit naive, but I’m starting to wonder why we still set the Standards-Version in package control files. AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. However I think this approach doesn’t fit the current way we deal with policy changes. The de facto way of dealing with policy breakages currently is to directly report serious bugs against packages not conforming, regardless of the Standards-Version they declare. We will even often NMU them without changing the Standards-Version, while having actually fixed them to conform to newer versions. Currently I don’t think this header reflects anything useful in a vast majority of our packages. I’m spending more time updating the header than actually updating old packages to conform to policy changes. What would you think of deprecating this header? Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: What’s the use for Standards-Version ?
Josselin Mouette wrote: Hi, the question in the subject may sound a bit naive, but I’m starting to wonder why we still set the Standards-Version in package control files. AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. However I think this approach doesn’t fit the current way we deal with policy changes. The de facto way of dealing with policy breakages currently is to directly report serious bugs against packages not conforming, regardless of the Standards-Version they declare. We will even often NMU them without changing the Standards-Version, while having actually fixed them to conform to newer versions. Currently I don’t think this header reflects anything useful in a vast majority of our packages. I’m spending more time updating the header than actually updating old packages to conform to policy changes. What would you think of deprecating this header? I find convenient to see what I should check, because of policy upgrades. [ /usr/share/doc/debian-policy/upgrading-checklist.txt.gz ] Not always I've time to check/update the package to the new policy (e.g. when correcting a single bug), so the upload date is not sufficient, and doing a complete/deep check is time intensive. Further I cannot trust lintian or bug reports for policy compliance. PS: I'm also not sure that lintian could do these check automatically. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
On Wed, Aug 12, 2009 at 09:56:49AM +0200, Samuel Thibault wrote: Giacomo A. Catenazzi, le Wed 12 Aug 2009 08:03:30 +0200, a écrit : Bastian Blank wrote: On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote: In article 20090811183800.ge5...@const.famille.thibault.fr you wrote: Not necessarily. Any sane implementation should just use wchar_t Which could be UTF16 and therefore still has complicatd length semantics. No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like Windows). No wchar_t is locale dependent (per POSIX). What do you mean? The compiler can't know the locale in advance for the width and endianness. The value might depend on the locale, yes, but that's not a problem as long as you convert into UTF-8 before communicating with other applications. One same systems (Debian systems are), it's just always UCS-4. Specifically, __STDC_ISO_10646__ is defined to indicate that wchar_t is always UCS-4 in all locales. BTW on gcc: -fwide-exec-charset=charset Set the wide execution character set, used for wide string and character constants. It hurts when I shoot myself in the foot. This feature of GCC is one of the more obscure areas of locale handling. How does the encoding of strings at the level of individial translation units work with a single per-process global locale and C formatted I/O? Curious minds would like to know! The default is UTF-32 or UTF-16, whichever corresponds to the width of wchar_t. This documentation is bogus BTW. It should read UCS-4 or UCS-2. It's strictly correct according to the standard. http://en.wikipedia.org/wiki/UTF-32/UCS-4 for an overview. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
MBF for removal of python-gnome2-desktop binary package
Hi, due to some upcoming changes in the list of supported modules upstream, the python-gnome2-desktop binary package will be removed soon. Packages must depend on the individual modules instead. For example, if the only module used is gnomeapplet, you must depend on python-gnomeapplet instead. A list of modules that different packages use is available at http://wiki.debian.org/GnomePythonSplitting but beware since it was generated a few months ago. Please also note that python-nautilusburn will be removed eventually, but if possible, this will happen only after python-braseroburn has been packaged and been here for a while. The dd-list follows. MBF will happen soon, except for packages for which I’ll be warned that it’s fixed in the repository. David Villa Alises david.vi...@uclm.es ows Michael Biebl bi...@debian.org tracker Adolfo González Blázquez c...@infinicode.org cameramonitor Salvatore Bonaccorso salvatore.bonacco...@gmail.com giplet Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org hamster-applet (U) ontv (U) Debian OLPC debian-olpc-de...@lists.alioth.debian.org sugar-toolkit Sebastian Dröge sl...@debian.org ontv (U) Pedro Fragoso em...@ubuntu.com hamster-applet Jeremy Guitton debo...@free.fr ontv Philipp Kern pk...@debian.org timer-applet Julian Andres Klode j...@debian.org gimmie Clement Lorteau northern_lig...@users.sourceforge.net gtkvncviewer Maintainers of GStreamer packages pkg-gstreamer-maintain...@lists.alioth.debian.org elisa-plugins-good Loic Minier l...@dooz.org elisa-plugins-good (U) Kartik Mistry kar...@debian.org ldtp Emilio Pozuelo Monfort po...@ubuntu.com scribes Sam Morris s...@robots.org.uk serpentine Josselin Mouette j...@debian.org hamster-applet (U) Philippe Normand phili...@fluendo.com elisa-plugins-good (U) Adriaan Peeters apeet...@lashout.net music-applet Frederic Peters fpet...@debian.org gnome-blog Siegfried-Angel Gevatter Pujals rai...@ubuntu.com webboard Ara Pulido a...@ubuntu.com ldtp (U) Python Applications Packaging Team python-apps-t...@lists.alioth.debian.org scribes (U) Arnaud Quette aque...@debian.org elisa-plugins-good (U) Jonas Smedegaard d...@jones.dk sugar-toolkit (U) Jose Carlos Garcia Sogo js...@debian.org conduit Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: default character encoding for everything in debian
On Wed, Aug 12, 2009 at 07:54:33AM +0200, Giacomo A. Catenazzi wrote: Samuel Thibault wrote: Gunnar Wolf, le Tue 11 Aug 2009 13:28:08 -0500, a écrit : while length(str) in any language up to the 1990s was a mere substraction, now we must go through the string checking each byte to see if it is a Unicode marker and substract the appropriate number of bytes. Not necessarily. Any sane implementation should just use wchar_t and substraction gets back. An implementation that use wchar_t is usually not sane, but usually it is (also) buggy. It is very difficult (AFAIK not impossible, but I'm not so sure) to write portable (POSIX way, so with changing locales) programs using wchar_t. Do you have any concrete examples to back up these assertions? They worked perfectly well for me last time I checked. There were bugs in the distant past, but I don't see any issues with current GCC/libc. BTW, since POSIX/SUS are a superset of the standard C library, they contain all of the same wide character handling functionality. I'm not sure what you're getting at with the changing locales; SUS locale functionality like setlocale() comes directly from C with no changes. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
It's impressing how quickly threads on this list grow big. :-) I'm not sure, whether a conclusion is already reached. 1. apt-get install mysql 2. enter mysql client 3. create database test; create table test( test char(10) ); Replace mysql with whatever application you like. What should be the encoding of database and table test in cases like the above? Currently it's iso-something, discriminating everybody from other countries. If it would be utf-8 instead, it would have at least two advantages - The clueless user would get a sane default - utf-8 isn't as discriminating as iso-8859-1 Best regards, Thomas Koch Hi, I've an issue, that I forgot to set the character encoding of tomcat to utf-8 after reinstalling a server. Now, before I report a wishlist(?) bug to tomcat, I want to ask (and invite to discuss) shouldn't utf8 be the default character set everywhere? So when installing a package from Debian I can assume that where a character encoding can be set, it't set to utf8. MySQL would be another example, which to my knowledge uses isoXYZ as default character encoding. Best regards, Thomas Koch, http://www.koch.ro Thomas Koch, http://www.koch.ro -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
Russ Allbery wrote:
Josselin Mouette j...@debian.org writes:
If we use build IDs (and this has quite some advantages, like being able
to do more than just dump the ddebs on a repository), this can lead to
having the same detached debugging symbols in two binary packages, since
sometimes a binary is built twice the same exact way and put in two
different binary packages.
Hm, really? The toolchains that I'm familiar with basically never produce
the same binary twice; something is always slightly different from
timestamp information. Could you give an example of such a case in the
archive right now where identical binaries are in multiple packages so
that I can better understand how this happens?
There are things the linker takes into account for calculating the build id. The
timestamp isn't one of them.
E.g.:
emi...@saturno:/tmp$ echo main(){} a.c; cp a.c b.c; gcc -o a a.c; gcc -o b
b.c; eu-readelf -n a b | grep Build
Build ID: c164b7f24a18b665601cd1d1b9fa0af6afb728bb
Build ID: c164b7f24a18b665601cd1d1b9fa0af6afb728bb
So in cases where you build a package twice with different configure flags, it's
be possible that those don't affect some binaries, getting the same build ids.
E.g., after a build of evince/2.26.1-2 from testing (the package in unstable has
been changed to ship the backends in the library package so this is no longer
the case, but to show this happens):
r...@saturno:~/evince-2.26.1# eu-readelf -n
debian/evince/usr/lib/evince/1/backends/*so
debian/evince-gtk/usr/lib/evince/1/backends/*so | grep Build | sort | uniq -c
2 Build ID: 0232654930d90461896f3d58fe08178082a217df
2 Build ID: 08de63310c0ff98c5aac6392d95c7bd6fc502c8b
2 Build ID: 71b914ea23bb199d9d98de2a15a9d07e982a3ae0
2 Build ID: 7a40178124bf7698de230b2298378f08795ddbe5
2 Build ID: 8de5ebfcb2bfceb9ed19a57d6bbc918392e152ec
2 Build ID: c0b63d2ecd7432f0a01441e0794306651c88f5f7
2 Build ID: c3b7f89bda6381e5849819032f842e6870e184b5
2 Build ID: dffdcca3f7a89b4b9da333d7cc638a96ed8b1bc8
Cheers,
Emilio
signature.asc
Description: OpenPGP digital signature
Re: MBF for removal of python-gnome2-desktop binary package
Josselin Mouette wrote: Emilio Pozuelo Monfort po...@ubuntu.com scribes Python Applications Packaging Team python-apps-t...@lists.alioth.debian.org scribes (U) Fixed in trunk. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: default character encoding for everything in debian
On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote: I'm not sure, whether a conclusion is already reached. 1. apt-get install mysql 2. enter mysql client 3. create database test; create table test( test char(10) ); Replace mysql with whatever application you like. What should be the encoding of database and table test in cases like the above? Currently it's iso-something, discriminating everybody from other countries. If it would be utf-8 instead, it would have at least two advantages - The clueless user would get a sane default - utf-8 isn't as discriminating as iso-8859-1 UTF-8 is the sane default choice in this situation, so long as MySQL is capable of handling it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, 12 Aug 2009 11:59:09 +0200 Josselin Mouette j...@debian.org wrote: However I think this approach doesn’t fit the current way we deal with policy changes. The de facto way of dealing with policy breakages currently is to directly report serious bugs against packages not conforming, regardless of the Standards-Version they declare. We will even often NMU them without changing the Standards-Version, while having actually fixed them to conform to newer versions. In many cases, wouldn't such a relationship be better expressed by a dependency on a package that implemented the new behaviour? Often it's dpkg and many of those situations are already handled via just such a dependency. So why have the extra field? Also, for Standards-Version: to be useful again, wouldn't it be appropriate for lintian to have support for testing the package against the *declared* standards version? I doubt that this would be particularly welcome or easy to implement, hence I agree that the field itself is becoming irrelevant. Yes, we can test with the version of lintian in lenny or etch but that's not really using the Standards-Version field, it's using the release process instead. Currently, lintian is taking a different approach that if the debian/changelog has not been touched since Policy was updated, it doesn't complain about tests that are new (and conversely complains if the pointless Standards-Version field is out of sync with that calculation). Presumably this is because the Standards-Version field itself isn't suitable for a lintian test, so why have the field at all? As a final thought, it would be nice to drop 10,000+ lines from the Sources.gz file too - Sources.gz doesn't need to be the same size as Packages.gz. $ grep -c Standards-Version /var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_main_source_Sources 13695 Interestingly, using a 'sort -u|grep -c Standards-Version' pipe gives *60* unique Standards-Versions in the current Sources for unstable. 3.0.0, 3.0.1, 3.0.1.1, 3.1.0, 3.1.0.0, 3.1.1, 3.1.1.0, 3.1.1.1, 3.2.0, 3.2.0.0, 3.2.1, 3.2.1.0, 3.5.0, 3.5.1, 3.5.10, 3.5.1.0, 3.5.10.0, 3.5.2, 3.5.2.0, 3.5.3, 3.5.4, 3.5.5, 3.5.5.0, 3.5.6, 3.5.6.0, 3.5.6.1, 3.5.7, 3.5.7.1, 3.5.8, 3.5.8.0, 3.5.9, 3.5.9.0, 3.6.0, 3.6.0.1, 3.6.1, 3.6.10, 3.6.1.0, 3.6.1.1, 3.6.2, 3.6.2.0, 3.6.2.1, 3.6.2.2, 3.6.3, 3.7.0, 3.7.1.2, 3.7.2, 3.7.20, 3.7.2.0, 3.7.2.1, 3.7.2.2, 3.7.3, 3.7.3.0, 3.8.0, 3.8.0.0, 3.8.0.1, 3.8.1, 3.8.1.0, 3.8.2, 3.8.2.0 Currently I don’t think this header reflects anything useful in a vast majority of our packages. I’m spending more time updating the header than actually updating old packages to conform to policy changes. +1 It could be made optional - only set if there is a reason to set it. (Quite what those reasons would be, I have no idea but someone will probably come up with one or two.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpDJudKo7Onu.pgp Description: PGP signature
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Josselin Mouette wrote: Hi, the question in the subject may sound a bit naive, but I’m starting to wonder why we still set the Standards-Version in package control files. AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. No, that is wrong. The reason we put in the Standards version is to let the next developer know what to look for in the upgrading checklist in policy in order to bring the package up to date with policy This is no way implies that the package with an old standards version does not have to comply to latest policy. In other words, I can't just set Standards-Version to 0.0.0 and blithely ignore any policy -- the package would be buggy if it does not follow the latest policy, regardless of the standards version. However I think this approach doesn’t fit the current way we deal with policy changes. The de facto way of dealing with policy breakages currently is to directly report serious bugs against packages not conforming, regardless of the Standards-Version they declare. We will even often NMU them without changing the Standards-Version, while having actually fixed them to conform to newer versions. Currently I don’t think this header reflects anything useful in a vast majority of our packages. I’m spending more time updating the header than actually updating old packages to conform to policy changes. What would you think of deprecating this header? This would be bad, since when someone looks at the package, they would not know easily what they have to look for to update the package. The Standards Version gives a pointer into the upgrading checklist, and that remains useful. manoj -- Insufficient facts always invite danger. Spock, Space Seed, stardate 3141.9 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Remove control field Conflicts if the package is no longer in the repository
On Wed, Aug 12 2009, Timur Birsh wrote: Hello Debian Developers, I've recently uploaded (thanks to Bart Martens for sponsoring) my first package and want to adopt the next one. It's cd-discid [1]. Its debian/control file contains the Conflicts field. This package conflicts with cdgrab ( 0.7), which is no longer exists in the repository. So, I have a question, may I remove Conflicts field safely? I think that as long as the package (cdgrab, in this case) is not longer in stable, the conflicts line may be removed (we support partial upgrades from stable, as far as is possible). In this case, apparently cdgrab is not anywhere, so the conflicts line may go. manoj -- The IBM purchase of ROLM gives new meaning to the term twisted pair. Howard Anderson, Yankee Group Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 11:59:09 +0200 Josselin Mouette j...@debian.org wrote: However I think this approach doesn’t fit the current way we deal with policy changes. The de facto way of dealing with policy breakages currently is to directly report serious bugs against packages not conforming, regardless of the Standards-Version they declare. We will even often NMU them without changing the Standards-Version, while having actually fixed them to conform to newer versions. In many cases, wouldn't such a relationship be better expressed by a dependency on a package that implemented the new behaviour? Often it's dpkg and many of those situations are already handled via just such a dependency. So why have the extra field? Because not all new policy changes are reflected by a new version of some package? And for Developer picking up a package and wanting to know what needs to be looked at in order to achieve policy compliance, a mess of possible dependency relationships is a lot harder to base that decision on than a simple standards version. Also, for Standards-Version: to be useful again, wouldn't it be appropriate for lintian to have support for testing the package against the *declared* standards version? I doubt that this would be particularly welcome or easy to implement, hence I agree that the field itself is becoming irrelevant. Yes, we can test with the version of That would be wrong. A Standards version has nothing to do with deciding whether or not a package is buggy WRT policy. If it does not match current policy, the package is buggy, period. Even if the mainteiner has cleverly set the standards version to 0.0.0. The standards version is not a means of getting out of meeting policy. From a Project point of view, it is useful to see if a package in the archive meets current policy, not whether it met policy when the standards version was last touched (and encourage people to not change the standards version or follow policy). So assuming there is a relation between bugginess and standards version is wrong; the latter is only useful for people trying to update the package, so that they know what to look for. manoj -- Some of my readers ask me what a Serial Port is. The answer is: I don't know.Is it some kind of wine you have with breakfast? Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Remove control field Conflicts if the package is no longer in the repository
Manoj Srivastava wrote: On Wed, Aug 12 2009, Timur Birsh wrote: Hello Debian Developers, I've recently uploaded (thanks to Bart Martens for sponsoring) my first package and want to adopt the next one. It's cd-discid [1]. Its debian/control file contains the Conflicts field. This package conflicts with cdgrab ( 0.7), which is no longer exists in the repository. So, I have a question, may I remove Conflicts field safely? I think that as long as the package (cdgrab, in this case) is not longer in stable, the conflicts line may be removed (we support partial upgrades from stable, as far as is possible). In this case, apparently cdgrab is not anywhere, so the conflicts line may go. Really it is still in the archive, but with an other name. So I see two options: - replace cdgrab ( 0.7) with abcde ( 0.7) - remove the conflicts (because it is too old). Notes: The rename was done just before freezing potato, nearly 10 years ago. http://lists.debian.org/debian-devel/1999/11/msg00182.html See also abcde changelog: http://packages.debian.org/changelogs/pool/main/a/abcde/abcde_2.3.99.8-1/changelog ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Remove control field Conflicts if the package is no longer in the repository
Giacomo A. Catenazzi wrote: Manoj Srivastava wrote: On Wed, Aug 12 2009, Timur Birsh wrote: Hello Debian Developers, I've recently uploaded (thanks to Bart Martens for sponsoring) my first package and want to adopt the next one. It's cd-discid [1]. Its debian/control file contains the Conflicts field. This package conflicts with cdgrab ( 0.7), which is no longer exists in the repository. So, I have a question, may I remove Conflicts field safely? I think that as long as the package (cdgrab, in this case) is not longer in stable, the conflicts line may be removed (we support partial upgrades from stable, as far as is possible). In this case, apparently cdgrab is not anywhere, so the conflicts line may go. Really it is still in the archive, but with an other name. So I see two options: - replace cdgrab ( 0.7) with abcde ( 0.7) Oops. This is a stupid option because abcde ( 0.7) never existed. Sorry for the noise ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
On Tue, Aug 11, 2009 at 9:56 PM, Romain Beauxisto...@rastageeks.org wrote: Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit : On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessyple...@debian.org wrote: Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit : On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessyple...@debian.org wrote: The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. Sounds like dh_make needs a bug report about the default packagaging license, could you file one? Dear all, we just had a case in the Debian Med packaging team where the upstream author of software licensed under terms similar to the BSD license got upset to see the Debian packaging licenced under the GPL, and posted a reminder that GPLed contributions to his software will not be accepted. Yes, this is precisely why the pkg-perl team usually goes with same terms as Perl itself (Artistic | GPL) and whatever the upstream licensing terms are (usually Artistic | GPL but sometimes BSD). So for example if upstream is BSD-licensed, then I'd personally put something like: Artistic | GPL | BSD for the debian/* files My reasoning is that the upstream can get stuff like patches back into their software (the BSD) provision but also allows anyone that can use Perl to use the patch (Artistic | GPL). Further, if upstream decides later to change to the same as Perl license (it is probably the most popular license on CPAN), it is okay for them to do so (with our patches). In the case of Debian-Med (being an outsider and not knowing what the team works with), I'd say explicitly licensing your debian/* files under the same license as upstream would be appropriate, or perhaps a combination of upstream | GPL licensing. This is clearly a discussion we all need to have within teams/package groups/etc -- namely, what do we want our debian/* files to be licensed under. And also what exactly is covered by the license claim. For instance, in the case of patches contained in debian/, I have some doubts about the license that applies. Usually, when one wants to propose a patch to a project, it has to do it under the original licence. That's particularly the case if the patch consists, for instance, of the diff of a commit from the current developpement code of the same upstream project... That does apply if you are proposing a patch for direct inclusion into the project, though not even necessarily. I think that in that case it's usually just assumed that you are providing code under the same license. With a patch you're writing original code so you should have the right to license it as you please, but you still need for the patch to comply with the original license so that it can be included without forcing upstream to change their license. In any case, some superset of upstream + whatever other licenses you want should be OK, since the upstream can integrate your changes by licensing the code under their license. You still technically hold the copyright to the diff but it usually doesn't matter, and authors often assume copyright of your work unless it's a rather sizable patch, which I think is what we want in the end. Anyway, if the patch is applied upstream it's usually removed from debian/patches/* so this point is sort of moot, right? As long as the upstream is allowed to integrate the patch Hence, are patches in debian/ covered by the license claimed for the project upstream, or for the debian packaging ? I'm of course not a lawyer, but my assumption is that code written by someone is owned by that person, so it's covered by the Debian packager/packaging team. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit : AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. No, that is wrong. The reason we put in the Standards version is to let the next developer know what to look for in the upgrading checklist in policy in order to bring the package up to date with policy This assumes that the previous developer has correctly updated the package according to the stated Standards version. Which is, in the general case, wrong. This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. If you want to bring a random package up-to-date with the policy, it is generally more useful to look at its RC bugs, and also at its other bugs. Said otherwise, with the current state of our practice, the workflow you describe is flawed. Which makes the standards version declaration useless. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: default character encoding for everything in debian
Roger Leigh, le Wed 12 Aug 2009 11:30:50 +0100, a écrit : The default is UTF-32 or UTF-16, whichever corresponds to the width of wchar_t. This documentation is bogus BTW. It should read UCS-4 or UCS-2. It's strictly correct according to the standard. http://en.wikipedia.org/wiki/UTF-32/UCS-4 for an overview. « except that the UTF-32 standard has additional Unicode semantics. » In UTF-32 mode, gcc introduces a BOM, and in UTF-16 it allows without warnings characters after U+. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version ?
Josselin Mouette wrote: Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit : AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. No, that is wrong. The reason we put in the Standards version is to let the next developer know what to look for in the upgrading checklist in policy in order to bring the package up to date with policy This assumes that the previous developer has correctly updated the package according to the stated Standards version. Which is, in the general case, wrong. 8-/ Why will developers update standard version, if they don't update the package? As shown by codehelp, a lot of package declare old policies. If this is the common case, we have a real problem on developer side. This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. If you want to bring a random package up-to-date with the policy, it is generally more useful to look at its RC bugs, and also at its other bugs. Bugs happens, so standard version doesn't mean no RC bugs according polixy x.y.z. But we must correct packages before user will file a RC bug. And I think few policy-induced RC bugs are discovered. Said otherwise, with the current state of our practice, the workflow you describe is flawed. Which makes the standards version declaration useless. But also your proposal: Maintainers are not able to check policy, so we must rely on other people checking the policy and filling the bugs? Who are such RC reporter? hmmm. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, 12 Aug 2009 08:22:17 -0500 Manoj Srivastava sriva...@debian.org wrote: In many cases, wouldn't such a relationship be better expressed by a dependency on a package that implemented the new behaviour? Often it's dpkg and many of those situations are already handled via just such a dependency. So why have the extra field? Because not all new policy changes are reflected by a new version of some package? And for Developer picking up a package and wanting to know what needs to be looked at in order to achieve policy compliance, a mess of possible dependency relationships is a lot harder to base that decision on than a simple standards version. OK, so if it's mainly for the benefit of the (next) maintainer, why not leave the field in debian/ but not put it into the Sources.gz file and not make an issue of it if it is out of date? It could be a comment in debian/rules. It's beginning to sound that it is neither more nor less important than the year of the copyright stamp in debian/copyright or whether a package uses CVS, SVN or git. i.e. it is a feature of the packaging and not much else. If Standards-Version is only useful for developers picking up a new package, why does that data ever have to be copied into the archive files? It's better just as a part of the .diff.gz - almost as if it was a file like debian/compat. Also, for Standards-Version: to be useful again, wouldn't it be appropriate for lintian to have support for testing the package against the *declared* standards version? I doubt that this would be particularly welcome or easy to implement, hence I agree that the field itself is becoming irrelevant. Yes, we can test with the version of That would be wrong. A Standards version has nothing to do with deciding whether or not a package is buggy WRT policy. If it does not match current policy, the package is buggy, period. Even if the mainteiner has cleverly set the standards version to 0.0.0. So all packages are only tested against Policy as it is at the moment that the test is considered. Fine, so again, what is the point of having Standards-Version: in the Sources.gz file? What is the point of complaining that it is out of date when the only version of Policy that matters is the latest one anyway? The standards version is not a means of getting out of meeting policy. Then what is the point of the field at all? From a Project point of view, it is useful to see if a package in the archive meets current policy, not whether it met policy when the standards version was last touched (and encourage people to not change the standards version or follow policy). So assuming there is a relation between bugginess and standards version is wrong; the latter is only useful for people trying to update the package, so that they know what to look for. In which case, I don't see why it needs to be preserved into the archive meta-data - it can just be left in the .diff.gz somewhere as a comment or left in the .changes file for the PTS to pick up on. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpnh4KdWZxRl.pgp Description: PGP signature
Re: What’s the use for Standards-Version?
On Wed, 12 Aug 2009 08:16:14 -0500 Manoj Srivastava sriva...@debian.org wrote: What would you think of deprecating this header? This would be bad, since when someone looks at the package, they would not know easily what they have to look for to update the package. The Standards Version gives a pointer into the upgrading checklist, and that remains useful. In which case all we need is the existing lintian check and for Standards-Version to be ignored by dpkg-dev so that it doesn't get into the .dsc, it doesn't get into the Sources.gz and it is finally OK to get rid of all these pointless messages in debian/changelog.gz: * updated Standards-Version (no changes needed) If people really want a way of scanning the Standards-Version from outside the source, it could be added as a field in the PTS, reading from the .diff.gz. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp8Ki8d9QoTO.pgp Description: PGP signature
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Josselin Mouette wrote: Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit : AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. No, that is wrong. The reason we put in the Standards version is to let the next developer know what to look for in the upgrading checklist in policy in order to bring the package up to date with policy This assumes that the previous developer has correctly updated the package according to the stated Standards version. Which is, in the general case, wrong. Firstly, when you update a package, the previous maintainer could have done all kinds of things wrong. If you do not trust the maintainer, you check. The chances are that they did not update the standards version, so youhave more checking to do from upgrading checklist. More work for you, but no other downside. If you think the maintainer was malicious, and updated the standards version without making changes to the package, you are stuck with a full review of policy and the package. And report the maintainer. If you think the majority of the maintainers upo blindly upgrading the standards version and not the package, we need to do some maintainer purging. In my experience, the packages I have worked with, the standards version has not been upgraded without the package itself. This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. Frankly, if you think that upgrading checklist does not contain everything relevant a maintainer has to check for the policy update in question, this is a bug, and I do not se that you have filed any. And can you point to a concrete case, please? Which policy upgrade came with a deficient upgrading checklist? If you want to bring a random package up-to-date with the policy, it is generally more useful to look at its RC bugs, and also at its other bugs. Heh. You have a far greater faith in people discovering and filing RC bugs. Lookgin at RC bugs is of course a necessary, but not, in my opinion, a sufficient, condition for bringing the package up to date. If a maintainer are not looking at the standards version, then the packages they maintain are suspect. Said otherwise, with the current state of our practice, the workflow you describe is flawed. Which makes the standards version declaration useless. I beg to differ. The standards version is a useful tool for people who follow the (simple) rules, and just because there are lazy (and perhaps malicious) maintainers out there does not mean the work-flow is broken. I hope that the majority of developers are not as lazy, incompetent, or malicious as you imply, and do not update the standards version without actually updating the packages in question. manoj -- Bachelor: A guy who is footloose and fiancee-free. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Remove control field Conflicts if the package is no longer in the repository
Hi, Giacomo A. Catenazzi wrote: I think that as long as the package (cdgrab, in this case) is not longer in stable, the conflicts line may be removed (we support partial upgrades from stable, as far as is possible). In this case, apparently cdgrab is not anywhere, so the conflicts line may go. Really it is still in the archive, but with an other name. So I see two options: - replace cdgrab ( 0.7) with abcde ( 0.7) Oops. This is a stupid option because abcde ( 0.7) never existed. Sorry for the noise OK. Thanks a lot. -- Timur -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, Aug 12, 2009 at 10:33 PM, Neil Williamscodeh...@debian.org wrote: On Wed, 12 Aug 2009 08:16:14 -0500 Manoj Srivastava sriva...@debian.org wrote: What would you think of deprecating this header? This would be bad, since when someone looks at the package, they would not know easily what they have to look for to update the package. The Standards Version gives a pointer into the upgrading checklist, and that remains useful. In which case all we need is the existing lintian check and for Standards-Version to be ignored by dpkg-dev so that it doesn't get into the .dsc, it doesn't get into the Sources.gz and it is finally OK to get rid of all these pointless messages in debian/changelog.gz: * updated Standards-Version (no changes needed) If people really want a way of scanning the Standards-Version from outside the source, it could be added as a field in the PTS, reading from the .diff.gz. IIRC, there is a plan for splitting Descriptions out of the Packages files, so Standards-Version could get a similar treatment. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Whatâs the use for Standards-Version?
On Aug 12, Josselin Mouette (j...@debian.org) wrote: Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit : AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. No, that is wrong. The reason we put in the Standards version is to let the next developer know what to look for in the upgrading checklist in policy in order to bring the package up to date with policy This assumes that the previous developer has correctly updated the package according to the stated Standards version. Which is, in the general case, wrong. I've had some packages for years during which policy was changed and required corresponding changes in my packages. In that case, the previous developer was me, so I'm pretty confident that the previous developer did at least as good a job as the current developer. :-) Your statement is a broad indictment of your fellow DDs as incompetent developers who cannot perform the simple task of reading a few lines of policy changes and determine if they imply any required changes for their packages. Oh, well, it's your life, make all the enemies you want. This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. Even if it contains most of the relevant information, it is useful. If there is something missing, that's when someone filing a bug can be a backup. No need to throw out the baby with the bath water. BTW, I just glanced at the debian-policy bug page and see none related to the upgrading checklist. Can you provide some bug numbers of those real cases of missing information so I can check my packages? No hurry, if you've just neglected to file them, do that first, then let me know. Thanks. If you want to bring a random package up-to-date with the policy, it is generally more useful to look at its RC bugs, and also at its other bugs. Said otherwise, with the current state of our practice, the workflow you describe is flawed. Which makes the standards version declaration useless. If there are current bugs, sure, you should attack those first. But you're making a stronger argument that because the workflow is not bulletproof, that invalidates the whole process and it should be discarded. I disagree, I find it very useful and hope we keep it. -- .''`. Josselin Mouette : :' : `. `' âI recommend you to learn English in hope that you in `- future understand thingsâ -- Jörg Schilling -- Neil Roeth -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 08:16:14 -0500 Manoj Srivastava sriva...@debian.org wrote: What would you think of deprecating this header? This would be bad, since when someone looks at the package, they would not know easily what they have to look for to update the package. The Standards Version gives a pointer into the upgrading checklist, and that remains useful. In which case all we need is the existing lintian check and for Standards-Version to be ignored by dpkg-dev so that it doesn't get into the .dsc, it doesn't get into the Sources.gz and it is finally OK to get rid of all these pointless messages in debian/changelog.gz: * updated Standards-Version (no changes needed) Firstly, you do not ahve to put that into the changelog, and, secondly, one should not have to update a packagejust to up the standards version string. I just fix local git and wait for a real reason to update the package. This way, I see no reason for it not to be in the Sources.gz, though making it easy to get to the standards version when contemplating taking a package over or doing and NMU would work too. If people really want a way of scanning the Standards-Version from outside the source, it could be added as a field in the PTS, reading from the .diff.gz. That would work. manoj -- Uneven economic and political development is an absolute law of capitalism. Nicolai Lenin Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 08:22:17 -0500 Manoj Srivastava sriva...@debian.org wrote: In many cases, wouldn't such a relationship be better expressed by a dependency on a package that implemented the new behaviour? Often it's dpkg and many of those situations are already handled via just such a dependency. So why have the extra field? Because not all new policy changes are reflected by a new version of some package? And for Developer picking up a package and wanting to know what needs to be looked at in order to achieve policy compliance, a mess of possible dependency relationships is a lot harder to base that decision on than a simple standards version. OK, so if it's mainly for the benefit of the (next) maintainer, why not leave the field in debian/ but not put it into the Sources.gz file and not make an issue of it if it is out of date? ould be a comment in debian/rules. I do not have a strong opinion about this, apart from the fact that it must be present in the sources when someone is looking to update the package, and it should be accessible before downloading all the sources. So having it in the diff.gz and PTS would be good enough. I also do not see much of a downside in letting current practice be -- what are the things I am missing? manoj -- A businessman is a hybrid of a dancer and a calculator. Paul Valery Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’ s the use for Standards-Version?
On Wed, Aug 12, 2009 at 10:10:43AM -0500, Manoj Srivastava wrote: On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 08:22:17 -0500 Manoj Srivastava sriva...@debian.org wrote: In many cases, wouldn't such a relationship be better expressed by a dependency on a package that implemented the new behaviour? Often it's dpkg and many of those situations are already handled via just such a dependency. So why have the extra field? Because not all new policy changes are reflected by a new version of some package? And for Developer picking up a package and wanting to know what needs to be looked at in order to achieve policy compliance, a mess of possible dependency relationships is a lot harder to base that decision on than a simple standards version. OK, so if it's mainly for the benefit of the (next) maintainer, why not leave the field in debian/ but not put it into the Sources.gz file and not make an issue of it if it is out of date? ould be a comment in debian/rules. I do not have a strong opinion about this, apart from the fact that it must be present in the sources when someone is looking to update the package, and it should be accessible before downloading all the sources. So having it in the diff.gz and PTS would be good enough. The only /real/ use for the standards version is using it as a starting point for upgrading to the current standards version, and that's already making the (rather naïve) assumption that it was already fully conforming with Policy to begin with. I also do not see much of a downside in letting current practice be -- what are the things I am missing? For most packages, it's typically the case that a new version of Policy requires no package changes, yet one needs to trawl through the changes in the upgrading checklist and then update the version number in the control file. Basically busy-work with no actual benefit; it's just pointless make-work for the maintainer. We have an automated method for checking Policy compliance: lintian. I'd far prefer that Policy transgressions were reported first and foremost by lintian rather than requiring manual (and potentially less reliable) checking by the maintainer. Rather than depending upon the maintainer's diligence, Policy conformance would then be assessed by automated checking than the presence of a number, which is of potentially unreliable provenance in the first place. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
Hi! On Tue, 2009-08-11 at 13:03:13 -0700, Russ Allbery wrote: Open questions: * Can we require a one-to-one correspondance between binary package names and debug package names that provide symbols for that binary package? I think we should; I think it would make the system more straightforward. Being able to debug your system with a mixture of applications using an old and new shared library coming from the same source package for which the soversion got bumped is pretty helpful, w/o needing to downgrade the whole debugging package every time one wants to debug applications using either. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’ s the use for Standards-Version?
On Wed, Aug 12, 2009 at 04:36:23PM +0100, Roger Leigh wrote: The only /real/ use for the standards version is using it as a starting point for upgrading to the current standards version, and that's already making the (rather naïve) assumption that it was already fully conforming with Policy to begin with. All it is is a bookmark into the policy upgrade-checklist - and it's a useful bookmark to have. It doesn't imply any assumptions about full Policy compliance. -- 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#540365: ITP: turnin-ng -- Assignment submitter and manager
On Sun, 2009-08-09 at 16:40:44 -0400, Ryan Kavanagh wrote: On Sun, Aug 09, 2009 at 05:23:43PM +0200, Guillem Jover wrote: I hope the packages uploaded won't have a «project» binary in the PATH? At the moment yes, Turnin-NG provides /usr/bin/project since that's what the original turnin / project app provided. However, I can either: 1) Rename the project script to something else upstream. 2) Rename it in the Debian package and add a note to README.Debian. I'm not sure which I prefer. #1 has the advantage of being consistent across all distributions. #2 makes it so that if someone else wants to move away from SPARC and use Turnin-NG as a direct replacement for their old binaries, they can. What do you think? I'd rename it upstream, less troubles for everyone. It's of course unfortunate that the original program was named like that, but I don't think continuing to take over such generic name is good in general. You could still document that in the Description, and README.Debian maybe also including a recipe for sites that might want to create for example a compat symlink under /usr/local for transitional purposes, or something to that effect. For the upstream part you could also do a slow transition, provide a «project» wrapper that prints a warning on stderr notifying the user about it being obsolete and pointing to the new name, the executing the actual program. The wrapper could be shipped for a period of time before complete removal, and installed only if enabled via some configure flag (or make target, as in “make install-obsolete”). Or just document the rename. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Roger Leigh wrote: On Wed, Aug 12, 2009 at 10:10:43AM -0500, Manoj Srivastava wrote: On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 08:22:17 -0500 Manoj Srivastava sriva...@debian.org wrote: In many cases, wouldn't such a relationship be better expressed by a dependency on a package that implemented the new behaviour? Often it's dpkg and many of those situations are already handled via just such a dependency. So why have the extra field? Because not all new policy changes are reflected by a new version of some package? And for Developer picking up a package and wanting to know what needs to be looked at in order to achieve policy compliance, a mess of possible dependency relationships is a lot harder to base that decision on than a simple standards version. OK, so if it's mainly for the benefit of the (next) maintainer, why not leave the field in debian/ but not put it into the Sources.gz file and not make an issue of it if it is out of date? ould be a comment in debian/rules. I do not have a strong opinion about this, apart from the fact that it must be present in the sources when someone is looking to update the package, and it should be accessible before downloading all the sources. So having it in the diff.gz and PTS would be good enough. The only /real/ use for the standards version is using it as a starting point for upgrading to the current standards version, and that's already making the (rather naïve) assumption that it was already fully conforming with Policy to begin with. I donot think it is a naive assumption at all. The commohn case with most package uploads is that the previous maintainer is the current maintainer. Usually, I try to make sure that my package is policy compliant (don't we all? we signed up for it). Then I see what has changed in policy since then, and try to ensure that the package still complies with policy. Now, I can still make mistakes, and leave room for others to notice and file bugs, but the primary process is still to look at policy and proactively fix policy related bts, not wait for people to find them for me and file bugs. Minimizing the reading I need to do (by checking what has changed in policy since I last checked policy) is a nice, useful optimization. I also do not see much of a downside in letting current practice be -- what are the things I am missing? For most packages, it's typically the case that a new version of Policy requires no package changes, yet one needs to trawl through the changes in the upgrading checklist and then update the version number in the control file. Basically busy-work with no actual benefit; it's just pointless make-work for the maintainer. Keeping packages policy compliant is one of the tasks that maintainers must do -- apart from the trawling through copyrights, making sure all configuration files live in /etc -- comes with the territory. We have an automated method for checking Policy compliance: lintian. I'd far prefer that Policy transgressions were reported first and foremost by lintian rather than requiring manual (and potentially less reliable) checking by the maintainer. Rather than depending upon the maintainer's diligence, Policy conformance would then be assessed by automated checking than the presence of a number, which is of potentially unreliable provenance in the first place. Lintian does not provide full coverage, and it can't. Some policy dictums do not have a lintian check. Looking over the policy changes seems like a decent addendum. By all means run lintian, but nothing actually beats a human paying attention. Quality of implementation improves. Deban developers ought to be acting like they could be replaced by a small script (a t shirt I own). manoj -- I think there is a world market for maybe five computers. Thomas Watson, chairman of IBM, 1943 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541223: ITP: libtext-dhcpleases-perl -- libtext-dhcpleases-perl -- an object-oriented interface to ISC DHCPD leases files
Package: wnpp Severity: wishlist Owner: Javier Uruen Val j...@warp.es * Package name: libtext-dhcpleases-perl Version : 0.9 Upstream Author : Carlos Vicente cvice...@cpan.org * URL : http://search.cpan.org/dist/Text-DHCPLeases/ * License : (Perl Artistic) Programming Lang: (Perl) Description : libtext-dhcpleases-perl -- an object-oriented interface to ISC DHCPD leases files Text::DHCPLeases provides an object-oriented interface to ISC DHCPD leases files. The goal is to objectify all declarations, as defined by the ISC dhcpd package man pages. This interface is useful for analyzing, reporting, converting lease files, or as a tool for other applications that need to import dhcpd lease data estructures. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le mercredi 12 août 2009 à 11:06 -0400, Neil Roeth a écrit : I've had some packages for years during which policy was changed and required corresponding changes in my packages. In that case, the previous developer was me, so I'm pretty confident that the previous developer did at least as good a job as the current developer. :-) Your statement is a broad indictment of your fellow DDs as incompetent developers who cannot perform the simple task of reading a few lines of policy changes and determine if they imply any required changes for their packages. Oh, well, it's your life, make all the enemies you want. When you only work on 6 packages for which you do a pretty good job, you tend to assume that other packages in the archive are maintained the same way. Well here’s a scoop, a lot of packages in the archive belong to maintainers with hundreds of them in their hands, whether alone or in teams. Not all packages can receive the level of attention you are expecting. Try going through large parts of the archive when you need to test a change, for example. You may be surprised with the overall quality you’ll meet. After that, you may change your mind about expecting a declarative field to be conformant with the rest of the packaging. Heck, I wouldn’t even trust *myself* to do that correctly. Bumping the standards version is a boring task I have to do so much that I never bother to have a look at the upgrading checklist, except for the most complex packages. This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. Even if it contains most of the relevant information, it is useful. If there is something missing, that's when someone filing a bug can be a backup. No need to throw out the baby with the bath water. BTW, I just glanced at the debian-policy bug page and see none related to the upgrading checklist. Can you provide some bug numbers of those real cases of missing information so I can check my packages? No hurry, if you've just neglected to file them, do that first, then let me know. Thanks. I’m not implying the upgrading checklist itself is incomplete. But there are other things in Debian than following the policy, you know? Most of the changes needed in packages are not here because of changes in the policy itself, but because of changes in other packages: packaging helpers, toolchain, menu system, various pieces of low-level plumbing that upstream redesigns every other month… these are the things that require attention. Not looking at whether the package is using the Speedo fonts. If there are current bugs, sure, you should attack those first. But you're making a stronger argument that because the workflow is not bulletproof, that invalidates the whole process and it should be discarded. I disagree, I find it very useful and hope we keep it. It may be useful for you, but it is being an annoyance for others. The suitable thing to do in such cases would be to make the field optional. Would that be OK? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: What’s the use for Standards-Version ?
Josselin Mouette wrote: Hi, the question in the subject may sound a bit naive, but I’m starting to wonder why we still set the Standards-Version in package control files. AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. However I think this approach doesn’t fit the current way we deal with policy changes. The de facto way of dealing with policy breakages currently is to directly report serious bugs against packages not conforming, regardless of the Standards-Version they declare. We will even often NMU them without changing the Standards-Version, while having actually fixed them to conform to newer versions. Currently I don’t think this header reflects anything useful in a vast majority of our packages. I’m spending more time updating the header than actually updating old packages to conform to policy changes. What would you think of deprecating this header? I'd be in favour of making it optional or deprecating it if we (as in the project) were good in adding checks to lintian for changes in the policy or reporting bugs where it's not possible (or in addition to the checks). Then, checking upgrade-checklist wouldn't be necessary, and S-V wouldn't have any sense (at least to me as I use it to check upgrade-checklist since the version specified in S-V). Also checking upgrade-checklist is time consuming, usually for no benefit (we all see those Update Standards-Version, no changes needed). So right now it's like if I was lintian and had to run those checks manually. So moving them from upgrade-checklist to lintian itself, or to the bts would be very welcome. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: What’ s the use for Standards-Version?
On Wed, 12 Aug 2009, Manoj Srivastava wrote: I do not have a strong opinion about this, apart from the fact that it must be present in the sources when someone is looking to update the package, and it should be accessible before downloading all the sources. So having it in the diff.gz and PTS would be good enough. The PTS gets it from Sources.gz so removing it is not really an option. I also do not see much of a downside in letting current practice be -- what are the things I am missing? Me neither. It's probably some size reduction affinity that Neil has due to his emdebian involvment... but I think it's diverging from the topic of this thread. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541239: ITP: GT.M -- Database Engine with Extreme Scalability and Robustness
Package: wnpp Severity: wishlist Owner: K.S. Bhaskar ks.bhas...@fnis.com * Package name: GT.M Version : V5.3-004A Upstream Author : K.S. Bhaskar ks.bhas...@fnis.com * URL : http://fis-gtm.com * License : AGPL v3 Programming Lang: C with some modules in x86 assembly language Description : Database Engine with Extreme Scalability and Robustness GT.M is a database engine with scalability proven in large real-time transaction processing systems that have thousands of concurrent users, individual database file sizes to the Terabyte range (with virtually unlimited aggregate database sizes). Yet the light footprint of GT.M allows it to also scale down for use in small applications and software appliances (virtual machines). The GT.M data model is hierarchical associative memory (i.e., multi-dimensional array) that imposes no restrictions on the data types of the indexes or content - the application logic can impose any schema, dictionary or data organization suited to its problem domain. (Database engines that do not impose schemas, but which allow layered application software to impose and use whatever schema that is appropriate to the application are popularly referred to as document oriented, schemaless or schema-free databases.) GT.M's compiler for the standard M (also known as MUMPS) scripting language implements full support for ACID (Atomic, Consistent, Isolated, Durable) transactions, using optimistic concurrency control and software transactional memory (STM) that resolves the common mismatch between databases and programming languages. Its unique ability to create and deploy logical multi-site configurations of applications provides unrivaled continuity of business in the face of not just unplanned events, but also planned events, including planned events that include changes to application logic and schema. Community support forums for GT.M can be found at http://sourceforge.net/projects/fis-gtm and support with assured service levels on commercial terms can be purchased from gtmsupp...@fnis.com. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty-backports'), (500, 'jaunty') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541242: ITP: VistA -- Real time health care information system including electronic health record
Package: wnpp Severity: wishlist Owner: K.S. Bhaskar ks.bhas...@fnis.com * Package name: VistA Version : To be determined Upstream Author : K.S. Bhaskar ks.bhas...@fnis.com * URL : http://worldvista.org/AboutVistA * License : Public domain, GPL v2, AGPL v3 Programming Lang: MUMPS Description : Real time health care information system including electronic health record VistA is the complete health care information system (HIS) which is developed and used by the US Department of Veterans Affairs to run all of its hospitals and clinics. It is in the public domain through the US Freedom of Information Act. Versions are also in use both in the US and internationally, including the US Department of Defense, the US Indian Health Service, the Mexican Instituto Mexicano del Seguro Social, etc. There are also flavors of VistA provided by WorldVistA (http://worldvista.org) and Medsphere (http://medsphere.org). I intend to create a VistA meta package that can be satisfied by other packages, such as WorldVistA EHR or OpenVista. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty-backports'), (500, 'jaunty') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541245: ITP: WorldVistA EHR -- WorldVistA EHR is a repackage and extended version of VistA produced by WorldVistA
Package: wnpp Severity: wishlist Owner: K.S. Bhaskar ks.bhas...@fnis.com * Package name: WorldVistA EHR Version : VOE/ 1.0 Upstream Author : K.S. Bhaskar ks.bhas...@fnis.com * URL : http://worldvista.org/World_VistA_EHR * License : GPL v2 Programming Lang: MUMPS Description : WorldVistA EHR is a repackage and extended version of VistA produced by WorldVistA Developed by WorldVistA (http://worldvista.org) and released under GPL v2, WorldVistA EHR is a repackaged and extended version of the VistA health care information system (HIS) developed by the US Department of Veterans Affairs, and in the public domain through the US Freedom of Information Act. WorldVistA successfully submitted WorldVistA EHR for certification by CCHIT (http://cchit.org) in 2007. WorldVistA EHR VOE/ 1.0 was tested and passed inspection of 100 percent of a set of criteria for functionality (ability to create and manage electronic records for all patients, as well as automating workflow in a physician's office), interoperability (a first step in the ability to receive and send electronic data to other entities such as laboratories), and security (ability to keep patients' information safe). Note: Downloading and installing the software is not sufficient and does *not* grant permission to make claim of CCHIT certification. Contact WorldVistA to discuss certification. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty-backports'), (500, 'jaunty') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Josselin Mouette j...@debian.org writes: This assumes that the previous developer has correctly updated the package according to the stated Standards version. Which is, in the general case, wrong. No, it assumes that the previous developer tried to update the package according to the stated standards version, which in my experience is correct. They may still have bugs -- bugs happen. But it means that the older stuff is just bugs they missed, and hence falls into the less common category of bugs missed by at least one person, instead of the new stuff that one knows from standards-version the maintainer had never even looked at. This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. Please report bugs against Policy if you see missing things in upgrading-checklist and I will add them. Note, though, that the file is intended to give you an idea, from reading the entry, whether you need to go re-read that section of Policy, not to be a substitute for re-reading. If you want to bring a random package up-to-date with the policy, it is generally more useful to look at its RC bugs, and also at its other bugs. Sure, and in practice it's even more useful to look at Lintian, but both of those miss things, sometimes a lot of things. Having a pointer into upgrading-checklist is also very useful. Said otherwise, with the current state of our practice, the workflow you describe is flawed. Which makes the standards version declaration useless. I *completely* disagree. Manoj speaks for me on this one. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Whatâs the use for Standards-Version?
On Aug 12, Josselin Mouette (j...@debian.org) wrote: Le mercredi 12 août 2009 à 11:06 -0400, Neil Roeth a écrit : I've had some packages for years during which policy was changed and required corresponding changes in my packages. In that case, the previous developer was me, so I'm pretty confident that the previous developer did at least as good a job as the current developer. :-) Your statement is a broad indictment of your fellow DDs as incompetent developers who cannot perform the simple task of reading a few lines of policy changes and determine if they imply any required changes for their packages. Oh, well, it's your life, make all the enemies you want. When you only work on 6 packages for which you do a pretty good job, you tend to assume that other packages in the archive are maintained the same way. Well hereâs a scoop, a lot of packages in the archive belong to maintainers with hundreds of them in their hands, whether alone or in teams. Not all packages can receive the level of attention you are expecting. You weren't saying people don't have time to give them attention, you were saying they were incompetently making the changes. That's a different argument and the one to which I responded. If people don't have time to handle all their packages properly, they should reduce the number of packages they maintain. I don't work on more packages precisely because I know my DD time is limited and there is a minimum level of attention that I think is required for each. I find the standards version and upgrading checklist combo to be a net time saver. Try going through large parts of the archive when you need to test a change, for example. You may be surprised with the overall quality youâll meet. After that, you may change your mind about expecting a declarative field to be conformant with the rest of the packaging. I suspect you are right, the general quality might not be up to my standards. However, as Manoj said, we did all sign up to maintain packages that conform to policy, and I think the problem you are describing is with some DDs not living up to their commitment rather than with the current process. Removing this just makes it easier for people to be sloppy, shift work onto someone else, and pretend they are living up to that commitment. Heck, I wouldnât even trust *myself* to do that correctly. Bumping the standards version is a boring task I have to do so much that I never bother to have a look at the upgrading checklist, except for the most complex packages. Why would you bump the standards version without actually checking to see if the package meets that standard? That's worse than leaving it as it was. I trust myself to make a conscientious effort to do it correctly if I choose to do it at all, but I no longer trust you. This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. Even if it contains most of the relevant information, it is useful. If there is something missing, that's when someone filing a bug can be a backup. No need to throw out the baby with the bath water. BTW, I just glanced at the debian-policy bug page and see none related to the upgrading checklist. Can you provide some bug numbers of those real cases of missing information so I can check my packages? No hurry, if you've just neglected to file them, do that first, then let me know. Thanks. Iâm not implying the upgrading checklist itself is incomplete. I don't see any semantic difference between the upgrading checklist is incomplete and This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. But there are other things in Debian than following the policy, you know? Most of the changes needed in packages are not here because of changes in the policy itself, but because of changes in other packages: packaging helpers, toolchain, menu system, various pieces of low-level plumbing that upstream redesigns every other month⦠these are the things that require attention. Not looking at whether the package is using the Speedo fonts. Yes, so go ahead and leave it at the last version it complied with and wait for the RC bugs. Just don't do more damage by changing it without making the corresponding changes. If there are current bugs, sure, you should attack those first. But you're making a stronger argument that because the workflow is not bulletproof, that invalidates the whole process and it should be discarded. I disagree, I find it very useful and hope we keep it. It may be useful for you, but it is being an annoyance for others. The suitable thing to do in such cases would be to make the field optional. Would that be OK? Disappointing, because I think it only serves to lower the standard (not
Re: What’s the use for Standards-Version?
Emilio Pozuelo Monfort poch...@gmail.com writes: I'd be in favour of making it optional or deprecating it if we (as in the project) were good in adding checks to lintian for changes in the policy or reporting bugs where it's not possible (or in addition to the checks). I already attempt to add checks to Lintian for everything that goes into each new release of Policy. Unfortunately, there are severe limitations in what's possible in an automated checking tool. There are a *lot* of changes to Policy that are just infeasible for Lintian to check, at least without considerable development work in hard and difficult areas, such as parsing and understanding arbitrary shell code. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Neil Williams codeh...@debian.org writes: In which case all we need is the existing lintian check and for Standards-Version to be ignored by dpkg-dev so that it doesn't get into the .dsc, it doesn't get into the Sources.gz and it is finally OK to get rid of all these pointless messages in debian/changelog.gz: * updated Standards-Version (no changes needed) If you don't want to put that in your changelog, don't. I consider it something I want to document in my packages, so I do. I would continue doing so even if it were an optional field (although I am completely opposed to making it optional). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On Tue, 11 Aug 2009, Matthew Johnson wrote: On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote: Personally I don't think we should do a GR to recommend a freeze or release date. We already used the DPL election to push a release, when it was *long* due, but I don't think we should push a freeze. Zack has been patching devotee to allow more informal (and not at all binding) polls to be run with the same infrastructure. I think this could be a suitable candidate to run using that. It allows us to have a poll which can only be voted in by DDs and not easily stuffed, but without having to go through the pain of a formal resolution. I would like to see such a poll as well. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Whatâs the use for Standards-Version?
Le mercredi 12 août 2009 à 14:17 -0400, Neil Roeth a écrit : If people don't have time to handle all their packages properly, they should reduce the number of packages they maintain. I’ve seen this kind of arguments again and again, and every time it looks more stupid to me. If you don’t have anything more interesting to say, maybe you could consider shutting up. It’s easy to try teaching lessons, but how about a reality check? Most Debian developers are interested only in maintaining their pet package, not in belonging to core teams. If what you suggest is that core teams should abandon their packages, you can immediately start looking for a new operating system. I suspect you are right, the general quality might not be up to my standards. However, as Manoj said, we did all sign up to maintain packages that conform to policy, and I think the problem you are describing is with some DDs not living up to their commitment rather than with the current process. I signed up to produce the best operating system possible. And unfortunately it doesn’t seem possible to do it with a 100 packages archive. Removing this just makes it easier for people to be sloppy, shift work onto someone else, and pretend they are living up to that commitment. Or maybe that makes it easier for people to shift work onto something more useful. Why would you bump the standards version without actually checking to see if the package meets that standard? That's worse than leaving it as it was. I trust myself to make a conscientious effort to do it correctly if I choose to do it at all, but I no longer trust you. I’m glad to learn that I can trust you to correctly put numbers in your control files. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Automatic Debug Packages
On 11826 March 1977, Emilio Pozuelo Monfort wrote: The proposal is (very briefly) to make dak accept .ddeb packages (containing debugging symbols using build-ids), and to then modify helper tools to automatically generate them and add them to the changes file. I've written down the details in the wiki [2], and I'll appreciate it if you could give some feeback. I don't want to trash this completely though, so no drastic changes preferred :) What a long thread, brrr. So lets take the start message of it and reply to a few points that have been all over in it. First, the naming: It is indeed us Ftpmasters who want them named .ddeb. For two reasons - a simple one is that it makes the handling much easier, if you can match on *.ddeb$. Another one is that they aren't real debs like .deb. They aren't meant for normal user consumption, but only for special situations. For most users possibly completly automated and transparently in the background. Seperating them as .ddeb helps making it clear it is something different than what you know from usual debian packages. More so than a -debug in the name alone. Also, ddebs should probably be defined in policy as not having maintainer scripts. Additionally the naming should include a -$DEBUG, so it will be $package-$DEBUG_$version_$arch.ddeb. $DEBUG should be a string not otherwise used, debug would probably work well. Second the storage: Archive side they will be put into the normal directories right beside the source and other binaries from the package. They will, however, not be exported to the public view of the archive. Instead we will export a second directory which contains them, which can then be mirrored seperately from mirrors that do want to have them. Now, as that will be a seperately exported mirror tree it leaves license compliance (provide binaries, provide source). Thats discussable - as we only provide debug symbols/code/whatever_funny_language_uses_for_it we might not fall below that requirement. Most likely we ensure compliance by having symlinks back into the normal /debian/ mirror tree of a mirror, and requiring each mirror to only mirror this if they also have /debian/. (This was one way the sarge amd64 archive was presented to the mirrors. Saved some of them quite a lot of space, not needing to duplicate the source from Debian.) Contents of a .ddeb: The contents of a .ddeb should strictly be limited to debugging symbols - or whatever their equivalent is in other programming languages/environments. No user needed/runable parts should be there. Which will keep -dbg packages like the python interpreters in the normal archive. Additionally a .ddeb must either include a /usr/share/doc/$package-$debug/ directory or a symlink to a /usr/share/doc/$package directory of a package it depends on. Quantity of .ddebs: Usually there should only be one .ddeb per source. Of course there are always exceptions from the rule, so Maintainers may chose to have one per binary package. This should only be taken when the size of the debug package gets *huge* otherwise. It is hard to set definite numbers here, but a 5mb package would surely not be a reason to split into two 2.5mb ones. Other stuff: Most of the other stuff is not of much concern to us. As to how the files within ddebs should be named, this isn't an archive side matter (although I personally favor to put files named after their build-ids into the .ddebs). The packages do also not need to be listed in debian/control, if they follow the one ddeb per source general rule. If there are more of them then they will need to be explicitly defined. They do *ALL* have to appear in the .changes file uploaded. -- bye, Joerg, your FTPMaster of the evening Hätten die Affen, von denen wir angeblich abstammen, geahnt, dass durch die Evolution eines Tages aus Ihren Reihen Politiker entstehen würden, wären sie auf Ihren Bäumen geblieben und hätten niemals versucht den aufrechten Gang zu erlernen. (J. Sheridan, Babylon5) pgpp5E43bfWNQ.pgp Description: PGP signature
I want to delete an ITP
Hello. I'm creating my first package, after reading the debian policy and others mails in 'debian-mentors' list I want to delete the ITP Bug #539568 in order to create a new one with the same library but with other name .. How can I do that? Thanks signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: I want to delete an ITP
Hello Leinier, first of all, this question is more fit for debian-mentors that for -devel, so I'm adding the list to CC (please follow up there, removing -devel). 2009/8/12 Leinier Cruz Salfran salfra...@ipigto.rimed.cu: Hello. I'm creating my first package, after reading the debian policy and others mails in 'debian-mentors' list I want to delete the ITP Bug #539568 in order to create a new one with the same library but with other name .. How can I do that? Well, if you only want to change the package name, simply retitle the bug. Instructions are at [1]. Please also note that the package name you specify in the ITP is the source package name, not the binary one(s) (and not, the may also not correspond, in some cases). [1] http://www.debian.org/Bugs/server-control In case you need also to add new information, do so mailing the bug at nn...@bugs.debian.org Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
On Wed, 12 Aug 2009 13:03:30 +0100 Roger Leigh rle...@codelibre.net wrote: On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote: I'm not sure, whether a conclusion is already reached. 1. apt-get install mysql 2. enter mysql client 3. create database test; create table test( test char(10) ); Replace mysql with whatever application you like. What should be the encoding of database and table test in cases like the above? Currently it's iso-something, discriminating everybody from other countries. If it would be utf-8 instead, it would have at least two advantages - The clueless user would get a sane default - utf-8 isn't as discriminating as iso-8859-1 UTF-8 is the sane default choice in this situation, so long as MySQL is capable of handling it. Is that a real problem? Usually applications that use a SQL DB come with some script to set up the schema. If they want UTF-8, they will create a table with UTF-8 encoding. I wouldn't change MySQL's default without reason, because old scripts might rely on that behaviour. Those applications, however, should be configured to use UTF-8 by default (if they support it) and their DB setup scripts accordingly. Cheers, harry signature.asc Description: PGP signature
Re: What's the use for Standards-Versio n?
Manoj Srivastava wrote: On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 08:16:14 -0500 Manoj Srivastava sriva...@debian.org wrote: * updated Standards-Version (no changes needed) Firstly, you do not ahve to put that into the changelog, and, secondly, one should not have to update a packagejust to up the standards version string. I just fix local git and wait for a real reason to update the package. I would add that updating the package just to bump the version is a really bad idea from the POV of the user, who gets to incur a bandwidth hit to d/l a new package that is identical to his/her existing one. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What's the use for Standards-Version?
On 08/12/2009 03:01 PM, David Claughton wrote: Manoj Srivastava wrote: On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 08:16:14 -0500 Manoj Srivastava sriva...@debian.org wrote: * updated Standards-Version (no changes needed) Firstly, you do not ahve to put that into the changelog, and, secondly, one should not have to update a packagejust to up the standards version string. I just fix local git and wait for a real reason to update the package. I would add that updating the package just to bump the version is a really bad idea from the POV of the user, who gets to incur a bandwidth hit to d/l a new package that is identical to his/her existing one. I don't think that anyone was every seriously defending that people do uploads just to bump the Standards-Version, I think the objection was more that bumping the Standards-Version needlessly clutters the changelog and wastes space. I'll admit I don't quite understand why, though. It's up to the maintainer to be as verbose as he or she feels there. Daniel signature.asc Description: OpenPGP digital signature
Re: What's the use for Standards-Version?
Daniel Moerner dmoer...@gmail.com writes: I don't think that anyone was every seriously defending that people do uploads just to bump the Standards-Version, I think the objection was more that bumping the Standards-Version needlessly clutters the changelog and wastes space. I'll admit I don't quite understand why, though. It's up to the maintainer to be as verbose as he or she feels there. Yeah, exactly. Personally, I prefer to explicitly record in changelog the points at which I've resynchronized my package with Policy and double-checked that I haven't missed anything. I don't always do that with every upload, depending on the urgency, and it's useful to be able to go back and see when I last did so. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What's the use for Standards-Version?
Daniel Moerner wrote: On 08/12/2009 03:01 PM, David Claughton wrote: Manoj Srivastava wrote: On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 08:16:14 -0500 Manoj Srivastava sriva...@debian.org wrote: * updated Standards-Version (no changes needed) Firstly, you do not ahve to put that into the changelog, and, secondly, one should not have to update a packagejust to up the standards version string. I just fix local git and wait for a real reason to update the package. I would add that updating the package just to bump the version is a really bad idea from the POV of the user, who gets to incur a bandwidth hit to d/l a new package that is identical to his/her existing one. I don't think that anyone was every seriously defending that people do uploads just to bump the Standards-Version, I think the objection was more that bumping the Standards-Version needlessly clutters the changelog and wastes space. I'll admit I don't quite understand why, though. It's up to the maintainer to be as verbose as he or she feels there. Daniel Fair enough - I thought Neil was implying that this sometimes happened but on re-reading this wasn't quite what he said ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On Tue, Aug 11, 2009 at 01:07:33PM +1000, Anthony Towns wrote: Any thoughts? We could have such a vote over and done in about two weeks, with the DPL's consent, and it'd seem a lot more inclusive and less cabal-tastic than how things seem to be working atm... Personally, I think the last thing we need is a GR on this front right now. There's still discussion going on and plenty of scope for interested people to make their feelings known. We don't need the overhead of a GR at all that I can see. -- Steve McIntyre, Cambridge, UK.st...@einval.com sladen I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying Paul: This fridge and fittings are the correct way around and do not need altering -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote: Quantity of .ddebs: Usually there should only be one .ddeb per source. Of course there are always exceptions from the rule, so Maintainers may chose to have one per binary package. This should only be taken when the size of the debug package gets *huge* otherwise. It is hard to set definite numbers here, but a 5mb package would surely not be a reason to split into two 2.5mb ones. This fails to address the rather valid concern brought up about having different versions of libraries and binaries installed from the same source package. Having one .ddeb per binary would solve this elegantly. It's also rather space-inefficient for the user. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Automatic Debug Packages
Roger Leigh wrote: On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote: Quantity of .ddebs: Usually there should only be one .ddeb per source. Of course there are always exceptions from the rule, so Maintainers may chose to have one per binary package. This should only be taken when the size of the debug package gets *huge* otherwise. It is hard to set definite numbers here, but a 5mb package would surely not be a reason to split into two 2.5mb ones. This fails to address the rather valid concern brought up about having different versions of libraries and binaries installed from the same source package. Having one .ddeb per binary would solve this elegantly. Except that in that case, the old library will be NBS and thus I see no point why you would want to keep it installed. The only reason would be if it was meant to stay around, but in that case I'm sure the source package names would be different. It's also rather space-inefficient for the user. If that bothers you, you can use the share we plan to provide. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: default character encoding for everything in debian
On Wed, Aug 12, 2009 at 11:44:36PM +0200, Harald Braumann wrote: On Wed, 12 Aug 2009 13:03:30 +0100 Roger Leigh rle...@codelibre.net wrote: On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote: I'm not sure, whether a conclusion is already reached. 1. apt-get install mysql 2. enter mysql client 3. create database test; create table test( test char(10) ); Replace mysql with whatever application you like. What should be the encoding of database and table test in cases like the above? Currently it's iso-something, discriminating everybody from other countries. If it would be utf-8 instead, it would have at least two advantages - The clueless user would get a sane default - utf-8 isn't as discriminating as iso-8859-1 UTF-8 is the sane default choice in this situation, so long as MySQL is capable of handling it. Is that a real problem? Usually applications that use a SQL DB come with some script to set up the schema. If they want UTF-8, they will create a table with UTF-8 encoding. I wouldn't change MySQL's default without reason, because old scripts might rely on that behaviour. Those old scripts which don't specify an encoding *are already buggy* due to not saying what they want, implying that the default (whatever that might be) is fine. There's the possibility that this might cause some problems, but they are problems in the script, not in MySQL. Keeping using an obsolete encoding like Latin 1 (or whatever the default currently is) prevents any breakage, but at the expense of moving to a sane default for the future. Those applications, however, should be configured to use UTF-8 by default (if they support it) and their DB setup scripts accordingly. They should indeed, but if they don't then they need to explicitly spell out what they *do* support. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Automatic Debug Packages
Emilio Pozuelo Monfort poch...@gmail.com writes: Roger Leigh wrote: This fails to address the rather valid concern brought up about having different versions of libraries and binaries installed from the same source package. Having one .ddeb per binary would solve this elegantly. Except that in that case, the old library will be NBS and thus I see no point why you would want to keep it installed. The only reason would be if it was meant to stay around, but in that case I'm sure the source package names would be different. Because you're trying to debug a binary on your system that's linked against it. It's also rather space-inefficient for the user. If that bothers you, you can use the share we plan to provide. I'm very curious to see more details about how this is going to work. It sounds like we may need to hold off making any decisions or Policy changes here until the details of that system is worked out if the normal delivery system for the things in .ddebs won't be via package installation. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Thu, Aug 13, 2009 at 02:58:45 +0200, Emilio Pozuelo Monfort wrote: If that bothers you, you can use the share we plan to provide. I'd like to still be able to debug offline, thank you very much. So far you've avoided answering the question, though: why one ddeb per source instead of per binary? Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
Russ Allbery wrote: Emilio Pozuelo Monfort poch...@gmail.com writes: Roger Leigh wrote: This fails to address the rather valid concern brought up about having different versions of libraries and binaries installed from the same source package. Having one .ddeb per binary would solve this elegantly. Except that in that case, the old library will be NBS and thus I see no point why you would want to keep it installed. The only reason would be if it was meant to stay around, but in that case I'm sure the source package names would be different. Because you're trying to debug a binary on your system that's linked against it. Then you should work on making your package build with the new library, since it will be FTBFS anyway :) I don't consider this a real issue. It's also rather space-inefficient for the user. If that bothers you, you can use the share we plan to provide. I'm very curious to see more details about how this is going to work. It sounds like we may need to hold off making any decisions or Policy changes here until the details of that system is worked out if the normal delivery system for the things in .ddebs won't be via package installation. There will still be a repository with all the .ddebs. But also we will have a share that will ship all the debugging symbols in a build id file hierarchy structure (so something like .build-id/xx/xxx.debug). You can mount it in your system and use it as if you had installed every -ddeb available in the archive. Furthermore, if disk space permits it, we will provide symbols for more than one version (i.e. not only the current package in the archive, but maybe the last three or whatever we can do), since build ids permit it. With this in place, we can integrate reporting tools (bug-buddy, drkonqi, apport) to use that service to magically provide meaningful bug reports with complete backtraces. If you use this, you won't need to get a backtrace, realize you're missing some symbols, install some more debug packages, rinse, repeat... :) Hope this was clear, Emilio signature.asc Description: OpenPGP digital signature
Re: Automatic Debug Packages
On Thu, Aug 13, 2009 at 02:58:45AM +0200, Emilio Pozuelo Monfort wrote: Roger Leigh wrote: On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote: Quantity of .ddebs: Usually there should only be one .ddeb per source. Of course there are always exceptions from the rule, so Maintainers may chose to have one per binary package. This should only be taken when the size of the debug package gets *huge* otherwise. It is hard to set definite numbers here, but a 5mb package would surely not be a reason to split into two 2.5mb ones. This fails to address the rather valid concern brought up about having different versions of libraries and binaries installed from the same source package. Having one .ddeb per binary would solve this elegantly. Except that in that case, the old library will be NBS and thus I see no point why you would want to keep it installed. The only reason would be if it was meant to stay around, but in that case I'm sure the source package names would be different. The scenario has been described already in the thread. It's also rather space-inefficient for the user. If that bothers you, you can use the share we plan to provide. No thanks, I like my debug symbols in a nice convenient packaged format, signed by the archive admins. While you might plan to be providing some fancy (yet enigmatic) service based upon the debug deb content, I still want them installable, preferably automatically getting all dependent debug symbols as well using apt. Preferably with a .deb extension; I see no reason why they can't be first-class Debian packages in addition to being used for mysterious as-yet-unspecified purposes. I can't say I'm particularly enthused with the apparent lack of consideration for most of the issues with the proposal brought up in this thread. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: default character encoding for everything in debian
On Thu, 13 Aug 2009 02:03:43 +0100 Roger Leigh rle...@codelibre.net wrote: On Wed, Aug 12, 2009 at 11:44:36PM +0200, Harald Braumann wrote: On Wed, 12 Aug 2009 13:03:30 +0100 Roger Leigh rle...@codelibre.net wrote: On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote: I'm not sure, whether a conclusion is already reached. 1. apt-get install mysql 2. enter mysql client 3. create database test; create table test( test char(10) ); Replace mysql with whatever application you like. What should be the encoding of database and table test in cases like the above? Currently it's iso-something, discriminating everybody from other countries. If it would be utf-8 instead, it would have at least two advantages - The clueless user would get a sane default - utf-8 isn't as discriminating as iso-8859-1 UTF-8 is the sane default choice in this situation, so long as MySQL is capable of handling it. Is that a real problem? Usually applications that use a SQL DB come with some script to set up the schema. If they want UTF-8, they will create a table with UTF-8 encoding. I wouldn't change MySQL's default without reason, because old scripts might rely on that behaviour. Those old scripts which don't specify an encoding *are already buggy* due to not saying what they want, implying that the default (whatever that might be) is fine. Agreed. Still no need to break them on purpose. There's the possibility that this might cause some problems, but they are problems in the script, not in MySQL. Keeping using an obsolete encoding like Latin 1 (or whatever the default currently is) prevents any breakage, but at the expense of moving to a sane default for the future. I really don't care too much about the specific case of MySQL, as I hardly ever create or manipulate SQL data by hand. All I was saying and you seem to be saying as well, if I understand you correctly, is that it is the duty of the application that creates and uses SQL tables to specify the encoding, if it cares about it. If the application does that, it will work, no matter what default is specified for MySQL. So this specific case is a non-issue, IMO, and MySQL's default doesn't need to be changed. But if it is, just for the sake of it, then that's fine with me. Some scripts might break, but OK. Those applications, however, should be configured to use UTF-8 by default (if they support it) and their DB setup scripts accordingly. They should indeed, but if they don't then they need to explicitly spell out what they *do* support. The should. Cheers, harry signature.asc Description: PGP signature
Re: Automatic Debug Packages
Emilio Pozuelo Monfort poch...@gmail.com writes: Russ Allbery wrote: Except that in that case, the old library will be NBS and thus I see no point why you would want to keep it installed. The only reason would be if it was meant to stay around, but in that case I'm sure the source package names would be different. Because you're trying to debug a binary on your system that's linked against it. Then you should work on making your package build with the new library, since it will be FTBFS anyway :) I was not under the impression that this system was intended only for the use of Debian Developers. I don't consider this a real issue. I do. I think it's a fairly significant one. There will still be a repository with all the .ddebs. But also we will have a share that will ship all the debugging symbols in a build id file hierarchy structure (so something like .build-id/xx/xxx.debug). You can mount it in your system and use it as if you had installed every -ddeb available in the archive. Furthermore, if disk space permits it, we will provide symbols for more than one version (i.e. not only the current package in the archive, but maybe the last three or whatever we can do), since build ids permit it. With this in place, we can integrate reporting tools (bug-buddy, drkonqi, apport) to use that service to magically provide meaningful bug reports with complete backtraces. Hm, that's interesting, but I suspect that few enough of our users will be able to use such a thing that we shouldn't let that influence any other design choices. Most shares are not going to be able to be mounted through firewalls, for example, so that form of the debug symbols won't be available to quite a few users. Or maybe by share you meant something that was more like a file download service over HTTP than, say, NFS? If you use this, you won't need to get a backtrace, realize you're missing some symbols, install some more debug packages, rinse, repeat... :) I thought you were planning on automating *this*, which I think is more useful than providing a share. It seems like it would be fairly straightforward in conjunction with the Contents database and the ldd output on the binary that crashed. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote: There will still be a repository with all the .ddebs. And aptitude and dpkg will know how to install ddebs, somehow? and synaptic, etc? But also we will have a share that will ship all the debugging symbols in a build id file hierarchy structure (so something like .build-id/xx/xxx.debug). You can mount it in your system and use it as if you had installed every -ddeb available in the archive. So all debugging has to happen online? Many places have a prohibition against mounting a file system from outside the firewall, though installing packages that have been vetted is permissible . Furthermore, if disk space permits it, we will provide symbols for more than one version (i.e. not only the current package in the archive, but maybe the last three or whatever we can do), since build ids permit it. With packages, mirrored repositories may have a different retention policy, and not rely on the packages one has installed disappearing off the remote filesystem. The system you propose works great for the use case you have envisaged: Debugging on a low security instllation with always on broadband connection to the network; but surely that is not the only model we provide. I am also wondering about the obstacles placed in the path of packages that will not be covered by the automated system. While we were talking about generating .debs, that was some work, but not any different from creating a package. Now, in order to create a hand crafted ddeb, what does one do? Add a nerw package to debian/control, build it, rename the package, edit ./debian/files before dpkg-genchanges is called -- this is more complex than just calling dpkg-buildpackage and be done with it. So I am wondering if the selction by package name is not good enough, and whether we really need selection using *.ddeb$ -- /.*-ddeb_.*\.deb$/ is not that much more complex a regular expression, and it brings with it the ability to manually create the debug symbol packages easily, using dpkg-bvuildpackage. I too am wondering if we should defer the polivy change until the details get shaken out with a partial deployment of the scheme. manoj -- Don't tell me I'm burning the candle at both ends -- tell me where to get more wax!! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastavasriva...@debian.org wrote: I too am wondering if we should defer the polivy change until the details get shaken out with a partial deployment of the scheme. Full deployment already happened (in Ubuntu). -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
Paul Wise p...@debian.org writes: On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastavasriva...@debian.org wrote: I too am wondering if we should defer the polivy change until the details get shaken out with a partial deployment of the scheme. Full deployment already happened (in Ubuntu). As .ddebs? What's the policy about what can go in them and how are they integrated with the packaging tools? And could you point me at the Ubuntu share for the debugging information so that I can see what protocols it's using? Prior experience is *great*. We can learn from the experiences of Ubuntu. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Thu, Aug 13, 2009 at 11:25 AM, Russ Allberyr...@debian.org wrote: As .ddebs? What's the policy about what can go in them and how are they integrated with the packaging tools? And could you point me at the Ubuntu share for the debugging information so that I can see what protocols it's using? Prior experience is *great*. We can learn from the experiences of Ubuntu. Not having anything to do with Ubuntu, I don't know anything about the details, but they have had automatic debug packages and automated crash report stuff for quite a while, a couple of years IIRC. The specs for that are here: https://launchpad.net/ubuntu/+spec/apt-get-debug-symbols https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
Paul Wise p...@debian.org writes: Not having anything to do with Ubuntu, I don't know anything about the details, but they have had automatic debug packages and automated crash report stuff for quite a while, a couple of years IIRC. The specs for that are here: https://launchpad.net/ubuntu/+spec/apt-get-debug-symbols https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports Ah, thank you! https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It does use *.ddeb. There isn't any clear statement about how *.ddeb packages differ from *.deb packages. It looks like, by and large, they don't, except they may not need to contain the same set of things. The packages are not in debian/control or the things fed from it, but are in *.changes. Ubuntu is creating one debug package per binary package, as I and a few other people have said we prefer. However, they're using the gnu_debuglink method, not the id method, so they don't have the one problem with that method previously identified in this thread when the same binary is copied into multiple packages. The debug packages depend on the packages for which they have symbols, which solves the problem of not installing debug packages that both provide symbols for the same binary. The proposal appears to only work for packages using debhelper, although the steps are laid out so presumably they could be done manually if need be. Ubuntu uses -dbgsym as the magic namespace. I don't know if it would be good for us to do the same or to use a different namespace to avoid problems for them in cases where we decide to build the package manually via debian/control and debian/rules. It looks like the plan with *.ddeb is to treat them specially in the archive software and divert them into a different tree in the archive instead of using a separate archive area, which I think they're doing now from that page. It also looks like one of the justifications for the separate package is to hide them in the apt front-end so that users don't see all the additional packages. I'm personally skeptical this is a good idea, although I can see the merits of not returning them in apt-cache search. Ah, and it looks like the automated crash reporting offers to download the -dbgsym packages and install them. I don't see any sign in this of a share. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le mercredi 12 août 2009 04:59:09, Josselin Mouette a écrit : AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. Cleartly, that this field is not quite used at the moment. Clearly also, the packaging workflow nowadays tends to be driven by lintian checks. You do the update, you pass through the automated tests. Some people remarked that, unfortunately, not all policy requirements can be automated, hence there is a difference between being lintian clean and conforming to the policy. Some other remarked that it is a very time-consuming task to do all the checklist for every policy change, which is quite true. But there could be another use of this field, which would fit into the test- driven workflow. What about a tool that displays the changes in the policy based on the declared supported version and the latest version ? This could display a simple checklist that the maintainer could check easily. This would also include only the relevant changes since the latest check, while we only have diff from one version to another. Eventually, after going through the list, you could safetly update this field knowing and also save time. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Wed, Aug 12 2009, Russ Allbery wrote: Paul Wise p...@debian.org writes: On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastavasriva...@debian.org wrote: I too am wondering if we should defer the polivy change until the details get shaken out with a partial deployment of the scheme. Full deployment already happened (in Ubuntu). As .ddebs? What's the policy about what can go in them and how are they integrated with the packaging tools? And could you point me at the Ubuntu share for the debugging information so that I can see what protocols it's using? Did ubuntu have to modify the default package manager (synaptic, right?) in order to allow the user to install the ddebs locally? I would be interested in the details of how to hook up to the debug packages archive in Ubuntu (I shall try installing an Ubuntu virtual machine this weekend to try this out). Prior experience is *great*. We can learn from the experiences of Ubuntu. I would also like to learn of the coverage Ubuntu managed to achieve, given that they have full deployment. What is the percentage of packages they managed to auto create? This is indeed very valuable information, I am surprised no one has been mentioning any figures at all about this full deployment in Ubuntu. manoj -- A mind is a terrible thing to have leaking out your ears. The League of Sadistic Telepaths Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Romain Beauxis to...@rastageeks.org writes:
But there could be another use of this field, which would fit into the
test- driven workflow. What about a tool that displays the changes in
the policy based on the declared supported version and the latest
version ?
Like:
zcat /usr/share/doc/debian-policy/upgrading-checklist.txt.gz \
| sed /`grep Standards-Version debian/control | awk '{ print $2 }'`/Q
? I just use zless on that file and stop reading when I get to the
current Standards-Version of the package, but that would automate it.
This is, indeed, exactly the use of the Standards-Version field that both
Manoj and I are advocating.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le mercredi 12 août 2009 23:22:45, Russ Allbery a écrit :
Romain Beauxis to...@rastageeks.org writes:
But there could be another use of this field, which would fit into the
test- driven workflow. What about a tool that displays the changes in
the policy based on the declared supported version and the latest
version ?
Like:
zcat /usr/share/doc/debian-policy/upgrading-checklist.txt.gz \
| sed /`grep Standards-Version debian/control | awk '{ print $2
}'`/Q
? I just use zless on that file and stop reading when I get to the
current Standards-Version of the package, but that would automate it.
This is, indeed, exactly the use of the Standards-Version field that both
Manoj and I are advocating.
Is it foolish to propose this as a lintian check ? Hey, standards version is
outdated, here are the changes that ought to be done
Even more, this could include only the changes that cannot be automated..
Romain
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’ s the use for Standards-Version?
Russ Allbery r...@debian.org (12/08/2009):
zcat /usr/share/doc/debian-policy/upgrading-checklist.txt.gz \
| sed /`grep Standards-Version debian/control | awk '{ print $2 }'`/Q
? I just use zless on that file and stop reading when I get to the
current Standards-Version of the package, but that would automate it.
Argh, you beated me to it.
This is, indeed, exactly the use of the Standards-Version field that both
Manoj and I are advocating.
It somewhat reminds me of something being checked during NM. I guess
old-timers will reply that once upon a time… but oh well.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Automatic Debug Packages
On Wed, Aug 12 2009, Russ Allbery wrote: Paul Wise p...@debian.org writes: Not having anything to do with Ubuntu, I don't know anything about the details, but they have had automatic debug packages and automated crash report stuff for quite a while, a couple of years IIRC. The specs for that are here: https://launchpad.net/ubuntu/+spec/apt-get-debug-symbols https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports Ah, thank you! https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It does use *.ddeb. There isn't any clear statement about how *.ddeb packages differ from *.deb packages. It looks like, by and large, they don't, except they may not need to contain the same set of things. The packages are not in debian/control or the things fed from it, but are in *.changes. Thanks for the link. They mention: --8---cut here---start-8--- # They (ddebs) can be arranged in a proper pool structure with a Packages file etc., so that existing tools to mirror, download, and ship debs can be reused. # Users can actually install them if they want to. ... An apt frontend will be provided to conveniently install debug symbols: e. g. apt-get debug apache2 would install the -dbgsym ddebs for apache2 and all its dependencies. This will allow developers to actually install the .ddebs --8---cut here---end---8--- This is what I find interesting. So, not quite aptitude/synhaptic, but analogous to apt-get source. This does answer some of the questions I had about implementation. Ubuntu is creating one debug package per binary package, as I and a few other people have said we prefer. However, they're using the gnu_debuglink method, not the id method, so they don't have the one problem with that method previously identified in this thread when the same binary is copied into multiple packages. Or the facility to keep debug symbols around for multiple versions of shared libraries (with the same soname), which is an advantage the build id method has. The proposal appears to only work for packages using debhelper, although the steps are laid out so presumably they could be done manually if need be. Yes, though some sleight of hand might be needed do build a package which is not in control (dpkg-deb --nocheck), or if the package is in debian/control, debian/files would have to have the .deb line removed, and dpkg-distaddfile used to register the ddeb file name). Ubuntu uses -dbgsym as the magic namespace. I don't know if it would be good for us to do the same or to use a different namespace to avoid problems for them in cases where we decide to build the package manually via debian/control and debian/rules. I would still like to see coverage figures to figure out what percentage of the archive will need this. It looks like the plan with *.ddeb is to treat them specially in the archive software and divert them into a different tree in the archive instead of using a separate archive area, which I think they're doing now from that page. It also looks like one of the justifications for the separate package is to hide them in the apt front-end so that users don't see all the additional packages. I'm personally skeptical this is a good idea, although I can see the merits of not returning them in apt-cache search. I am not sure I see that. When I ask apt cache for packages that currently have a debug package, I do not see the rpesence of information about the debug package as garbage; it is nice to know that the debg information exists. Ah, and it looks like the automated crash reporting offers to download the -dbgsym packages and install them. Reading the spec, it seems to me that the primary motivation was for users to provide crash dumps with bug reports, and not much screen time is given to users debugging their own applications linked to vendor libraries, or for the developer user in general. I think that use case should be addressed as well. I don't see any sign in this of a share. I am not sure I see much utility in a share, personally, since I have not really had an installation where I spent any time in where the mount would not have been prevented by perimeter defenses and security policies. manoj -- Help save the world! --Larry Wall in README Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’ s the use for Standards-Version?
Romain Beauxis to...@rastageeks.org (12/08/2009): Is it foolish to propose this as a lintian check ? Hey, standards version is outdated, here are the changes that ought to be done checks/standards-version.desc Mraw, KiBi. signature.asc Description: Digital signature
Re: What’ s the use for Standards-Version?
Le Wed, Aug 12, 2009 at 10:44:26PM +0800, Paul Wise a écrit : IIRC, there is a plan for splitting Descriptions out of the Packages files For the curious, there is some extra information here: http://lists.alioth.debian.org/pipermail/debian-l10n-devel/2009-August/000507.html In my experience, Standards-Version is not an accurate indicator of Policy conformance, so unless there is a collective effort to change this, I would support the idea of Standards-Version becomming optional. In further developments, it could later be managed independantly from debian/control together with other meta-data like the VSC, Homepage, Section and Description fields, the Debtags, etc. Have a nice day, -- Charles Plessy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le jeudi 13 août 2009 00:09:09, Cyril Brulebois a écrit : Romain Beauxis to...@rastageeks.org (12/08/2009): Is it foolish to propose this as a lintian check ? Hey, standards version is outdated, here are the changes that ought to be done checks/standards-version.desc Please, pretty please, try to make sentences. I hardly understand your comment, which makes it ambigous. Here is the output of a lintian warning currently in the case of an outdated standards-version: W: foo: ancient-standards-version 3.7.0 (current is 3.8.2) N: N:The source package refers to a Standards-Version that has been obsolete N:for more than two years. Please update your package to latest Policy and N:set this control field appropriately. N: N:If the package is already compliant with the current standards, you N:don't have to re-upload the package just to adjust the Standards-Version N:control field. However, please remember to update this field next time N:you upload the package. N: N:See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz in the N:debian-policy package for a summary of changes in newer versions of N:Policy. N: N:Severity: normal, Certainty: certain What I mean is that we can use the information contained in the standards- version tag and display at this place the list of changes that were done since 3.7.0 That makes a difference in the sense that it helps to improve the workflow by putting as much information as possible in the same place. Even more, if, as I suggested, it lists only changes that couldn't be automatised, that would make lintian a consistent tool for checking a package against the current policy. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Thu, Aug 13, 2009 at 1:15 PM, Romain Beauxisto...@rastageeks.org wrote: What I mean is that we can use the information contained in the standards- version tag and display at this place the list of changes that were done since 3.7.0 That makes a difference in the sense that it helps to improve the workflow by putting as much information as possible in the same place. Even more, if, as I suggested, it lists only changes that couldn't be automatised, that would make lintian a consistent tool for checking a package against the current policy. Please file a bug (and patch) against lintian, I doubt the lintian maintainers would have a problem with this as long as it is implemented sanely. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What's the use for Standards-Versi on?
Raphael Hertzog wrote: On Wed, 12 Aug 2009, Manoj Srivastava wrote: I do not have a strong opinion about this, apart from the fact that it must be present in the sources when someone is looking to update the package, and it should be accessible before downloading all the sources. So having it in the diff.gz and PTS would be good enough. The PTS gets it from Sources.gz so removing it is not really an option. PTS could read data from an other file. BTW also Maintainer and Uploader fiels are uselessly exported. The real maintainers and uploaders are defined by the values in the last uploaded package, not from actual package. [BTW sometime maintainers are also partially defined by wnpp reports] ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted monit 1:5.0.3-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 07:46:19 +0200 Source: monit Binary: monit Architecture: source i386 Version: 1:5.0.3-2 Distribution: unstable Urgency: low Maintainer: Stefan Alfredsson a...@debian.org Changed-By: Stefan Alfredsson a...@debian.org Description: monit - A utility for monitoring and managing daemons or similar programs Closes: 541139 Changes: monit (1:5.0.3-2) unstable; urgency=low . * inet6 and getaddr() fix (Thanks to Michael Stapelberg!) (Closes: #541139) Checksums-Sha1: 5ed5d20500e353c607f56103a1427646e99def1e 1005 monit_5.0.3-2.dsc a93c088ef14b9d8305b4914dddf9816d5be411c4 33911 monit_5.0.3-2.diff.gz 56a30ca1e47c662c4d7e16e3287e02a21d459226 318582 monit_5.0.3-2_i386.deb Checksums-Sha256: 40f1e48905f7a6f42da08ecdfc087a18ffbaad8809268445b1bd2afa624dc873 1005 monit_5.0.3-2.dsc 6ff19c42fffdc2225eb381cd6708748d00b3fdb9db9f3c0af175e59d7d0aec99 33911 monit_5.0.3-2.diff.gz 5ab0bcfc06985110421c73dc8afbd7aa15ca58c24f9a4d67ef136cc167838052 318582 monit_5.0.3-2_i386.deb Files: a7d0210717b84433bc6e24a8063045a4 1005 admin optional monit_5.0.3-2.dsc ec23001c4e530c6c9c55bf0e751c42ad 33911 admin optional monit_5.0.3-2.diff.gz 4934fde0e19bb59f12743bfea7f783ea 318582 admin optional monit_5.0.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKgljQ7WvuLRx04LcRAu2kAJ0Z6eeGwUF924D9V8DAPm+wxsjVCwCg2e4X +K8M1f3TH9G9kI/1HzHZs58= =vxUy -END PGP SIGNATURE- Accepted: monit_5.0.3-2.diff.gz to pool/main/m/monit/monit_5.0.3-2.diff.gz monit_5.0.3-2.dsc to pool/main/m/monit/monit_5.0.3-2.dsc monit_5.0.3-2_i386.deb to pool/main/m/monit/monit_5.0.3-2_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted gst-plugins-good0.10 0.10.15.2-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 07:13:08 +0200 Source: gst-plugins-good0.10 Binary: gstreamer0.10-plugins-good-doc gstreamer0.10-esd gstreamer0.10-pulseaudio gstreamer0.10-plugins-good gstreamer0.10-plugins-good-dbg Architecture: source all amd64 Version: 0.10.15.2-1 Distribution: experimental Urgency: low Maintainer: Maintainers of GStreamer packages pkg-gstreamer-maintain...@lists.alioth.debian.org Changed-By: Sebastian Dröge sl...@debian.org Description: gstreamer0.10-esd - GStreamer plugin for ESD gstreamer0.10-plugins-good - GStreamer plugins from the good set gstreamer0.10-plugins-good-dbg - GStreamer plugins from the good set gstreamer0.10-plugins-good-doc - GStreamer documentation for plugins from the good set gstreamer0.10-pulseaudio - GStreamer plugin for PulseAudio Changes: gst-plugins-good0.10 (0.10.15.2-1) experimental; urgency=low . * New upstream pre-release: + debian/build-deps.in, debian/rules: - Update build dependencies. + debian/control.in, debian/gstreamer-plugins-good.install: - Add the rtpmanager plugin which was moved from gst-plugins-bad. For this also add Replaces for gst-plugins-bad 0.10.13.2. + debian/patches/01_equalizer-integer-arithmetic-distortions.patch, debian/patches/02_SA35205-pngdec-integer-overflow.patch: - Dropped, merged upstream. * debian/control.in: + Update Standards-version to 3.8.2, no additional changes needed. Checksums-Sha1: 00567e5d5421f1da4c331cc72a11c27001a527a7 2820 gst-plugins-good0.10_0.10.15.2-1.dsc 4c14640d13ceb5e104b9b74f4a39c5c9ef834797 3717181 gst-plugins-good0.10_0.10.15.2.orig.tar.gz 23d74323ef268c3783706bd72bf1205853bf6b78 26040 gst-plugins-good0.10_0.10.15.2-1.diff.gz 090dc03307b2ca764b1ccb62abbf264ac406782b 285006 gstreamer0.10-plugins-good-doc_0.10.15.2-1_all.deb f26b483106eafb25b95cf677c2f5d99e127ad6cf 54136 gstreamer0.10-esd_0.10.15.2-1_amd64.deb 9b4091ccee42b97041c3cf8e2c5f6c407e34 82332 gstreamer0.10-pulseaudio_0.10.15.2-1_amd64.deb ad8c48a2cf56fe4b3ddd00a5f71cb71a074438ff 1409960 gstreamer0.10-plugins-good_0.10.15.2-1_amd64.deb a2a6dd8c93febeaeddef0bfb501315b17b023180 3721966 gstreamer0.10-plugins-good-dbg_0.10.15.2-1_amd64.deb Checksums-Sha256: 49f1d5f7b8e6b90a4200ec3c1dbe9e40fc8b20162fd61935f61b962ecffa188f 2820 gst-plugins-good0.10_0.10.15.2-1.dsc 141c5406e3ae71923dc5dd3913c88cd6ec193fc66dd8fda921f4febd843a2c63 3717181 gst-plugins-good0.10_0.10.15.2.orig.tar.gz 22cc498eda2c3bb89b8ecd311a5d5c78dbef5604f8616f9199f0007557137bea 26040 gst-plugins-good0.10_0.10.15.2-1.diff.gz ef94bff35e25d61293c9214463a4c2d1f612b8497fd4f92eac79013be25062a8 285006 gstreamer0.10-plugins-good-doc_0.10.15.2-1_all.deb 4bcd88c9af2d1f1bf08b3917b021f2bd385fa7672dc0365f981f46d87f9e5a1b 54136 gstreamer0.10-esd_0.10.15.2-1_amd64.deb 2482b6e66331172b3d34928cc7aab26deea47c6459245f55b3c4a95a0c1dc6c4 82332 gstreamer0.10-pulseaudio_0.10.15.2-1_amd64.deb 3f3a4d06dd853d6b178efc1fc24e2be484fed5185fa5440b68138975eb2ce574 1409960 gstreamer0.10-plugins-good_0.10.15.2-1_amd64.deb 7cbdf8ff1c315058320f10ae099b6cf97e6e3dbf1e3c79e6f8d169c374ec5e6a 3721966 gstreamer0.10-plugins-good-dbg_0.10.15.2-1_amd64.deb Files: e425c7a313bef2385e117ff2e1aee010 2820 libs optional gst-plugins-good0.10_0.10.15.2-1.dsc 925b45fd7686429fb0fe22cdeba92c5a 3717181 libs optional gst-plugins-good0.10_0.10.15.2.orig.tar.gz 8a429c89c0a9d03a1388af4c0249ccee 26040 libs optional gst-plugins-good0.10_0.10.15.2-1.diff.gz d5e32f8e01f93d3c3e386b0b017cfb6a 285006 doc optional gstreamer0.10-plugins-good-doc_0.10.15.2-1_all.deb 840c8ec77dd3336a65aee16edffeaa0c 54136 libs optional gstreamer0.10-esd_0.10.15.2-1_amd64.deb edb1b733722960d551506a64da62f3b6 82332 sound optional gstreamer0.10-pulseaudio_0.10.15.2-1_amd64.deb 5e22528610c77ecc4d0c0a8c0a5f3749 1409960 libs optional gstreamer0.10-plugins-good_0.10.15.2-1_amd64.deb 9063b12e05a9a6265f1784f420e1c9f6 3721966 debug extra gstreamer0.10-plugins-good-dbg_0.10.15.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCZ3QACgkQBsBdh1vkHyF4fwCcCfxkA4RM3h4NApz6kvzyy7Q5 2pwAn2y4YdF2a7eIV3zCNwePA3Hiqyjo =tWNd -END PGP SIGNATURE- Accepted: gst-plugins-good0.10_0.10.15.2-1.diff.gz to pool/main/g/gst-plugins-good0.10/gst-plugins-good0.10_0.10.15.2-1.diff.gz gst-plugins-good0.10_0.10.15.2-1.dsc to pool/main/g/gst-plugins-good0.10/gst-plugins-good0.10_0.10.15.2-1.dsc gst-plugins-good0.10_0.10.15.2.orig.tar.gz to pool/main/g/gst-plugins-good0.10/gst-plugins-good0.10_0.10.15.2.orig.tar.gz gstreamer0.10-esd_0.10.15.2-1_amd64.deb to pool/main/g/gst-plugins-good0.10/gstreamer0.10-esd_0.10.15.2-1_amd64.deb gstreamer0.10-plugins-good-dbg_0.10.15.2-1_amd64.deb to pool/main/g/gst-plugins-good0.10/gstreamer0.10-plugins-good-dbg_0.10.15.2-1_amd64.deb gstreamer0.10-plugins-good-doc_0.10.15.2-1_all.deb to
Accepted ctsim 5.1.0-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 00:57:32 -0600 Source: ctsim Binary: ctsim ctsim-help ctsim-doc Architecture: source all amd64 Version: 5.1.0-1 Distribution: unstable Urgency: low Maintainer: Kevin M. Rosenberg k...@debian.org Changed-By: Kevin M. Rosenberg k...@debian.org Description: ctsim - Computed tomography simulator ctsim-doc - Documentation for ctsim package ctsim-help - Online help file for CTSim Changes: ctsim (5.1.0-1) unstable; urgency=low . * Version bump for all known wxWidgets 2.8 bugs fixed Checksums-Sha1: 8ec3a85b403d52d130fc0c53c35047bc21fa95e3 1179 ctsim_5.1.0-1.dsc 70f53ae5cd3cf120ae1e41bd36b182e8e43440fc 2302658 ctsim_5.1.0.orig.tar.gz b01f408c9b5c50f8dc10bb8505c0e976ba2e7176 7522 ctsim_5.1.0-1.diff.gz a5389cec3338c43481ae9b38172c2776e6cb2ce0 137786 ctsim-help_5.1.0-1_all.deb 15f60a211482556e0f817879bb5bd3f0ef4deb4f 346754 ctsim-doc_5.1.0-1_all.deb ef8e0168b51a672d03c3342728234f3486569d54 649024 ctsim_5.1.0-1_amd64.deb Checksums-Sha256: 857f3b7bc7eee6015dfc7bfafc88ba098517456d53643e7f11ee4f2bd8a722e6 1179 ctsim_5.1.0-1.dsc 665157afaa74866cffa670b4c9af382e07dbafc3250762d7935d3687df4301fa 2302658 ctsim_5.1.0.orig.tar.gz 91c98348cb512930a76947a39c57f0a873200ac103aac2820cf7ea1fa45eb72e 7522 ctsim_5.1.0-1.diff.gz 6d7a96d617df02a3f2294cd0e1a8e2f94a3f2b9494d8f053ac2be7bf7f916418 137786 ctsim-help_5.1.0-1_all.deb 3ffdf374a045275ad3f33c780572e7b04b6fcab37c2bcce516001ccc15913c95 346754 ctsim-doc_5.1.0-1_all.deb 5f05bed16a090c91bba26aa4ae8ef71508611977d37d9ad792373a7a1b5a62ff 649024 ctsim_5.1.0-1_amd64.deb Files: 1bd0a9b9b5d2060855c4dce8de9f7d5f 1179 science extra ctsim_5.1.0-1.dsc f119bf43a74c0c211c8966761cf2cd9c 2302658 science extra ctsim_5.1.0.orig.tar.gz 33494c344e4e8f10e7f0f833f900aa3d 7522 science extra ctsim_5.1.0-1.diff.gz 991343d40be12f98a879ac86e0f9ae81 137786 science extra ctsim-help_5.1.0-1_all.deb 5e1b6afe313286d55103883b66c731a3 346754 doc extra ctsim-doc_5.1.0-1_all.deb 44c7cf48c68bafc6246d27765bcb8639 649024 science extra ctsim_5.1.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCaOkACgkQES7N8sSjgj53bwCeOKvZi5GMRYukXLeGauFO/fPF hVcAn3c7e1d4pKWMbcSnaWcJ2130ow84 =gsjI -END PGP SIGNATURE- Accepted: ctsim-doc_5.1.0-1_all.deb to pool/main/c/ctsim/ctsim-doc_5.1.0-1_all.deb ctsim-help_5.1.0-1_all.deb to pool/main/c/ctsim/ctsim-help_5.1.0-1_all.deb ctsim_5.1.0-1.diff.gz to pool/main/c/ctsim/ctsim_5.1.0-1.diff.gz ctsim_5.1.0-1.dsc to pool/main/c/ctsim/ctsim_5.1.0-1.dsc ctsim_5.1.0-1_amd64.deb to pool/main/c/ctsim/ctsim_5.1.0-1_amd64.deb ctsim_5.1.0.orig.tar.gz to pool/main/c/ctsim/ctsim_5.1.0.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted gst-plugins-bad0.10 0.10.13.2-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 07:20:46 +0200 Source: gst-plugins-bad0.10 Binary: gstreamer0.10-plugins-bad-doc gstreamer0.10-plugins-bad gstreamer0.10-sdl gstreamer0.10-plugins-bad-dbg Architecture: source all amd64 Version: 0.10.13.2-1 Distribution: experimental Urgency: low Maintainer: Maintainers of GStreamer packages pkg-gstreamer-maintain...@lists.alioth.debian.org Changed-By: Sebastian Dröge sl...@debian.org Description: gstreamer0.10-plugins-bad - GStreamer plugins from the bad set gstreamer0.10-plugins-bad-dbg - GStreamer plugins from the bad set (debug symbols) gstreamer0.10-plugins-bad-doc - GStreamer documentation for plugins from the bad set gstreamer0.10-sdl - GStreamer plugin for SDL output Closes: 537392 Changes: gst-plugins-bad0.10 (0.10.13.2-1) experimental; urgency=low . [ Fabian Greffrath ] * debian/extra: + Use @GST_PKGNAME@ instead of hard-coded gstreamer0.10. * debian/extra, debian/gstreamer-x264.install, debian/README.Debian: + Removed all references to the x264 plugin which has been moved to gst-plugins-ugly0.10. . [ Sebastian Dröge ] * New upstream pre-release: + Fixes integer overflow in MPEG demuxer that prevents playback of files larger than 4GB (Closes: #537392). + debian/patches/01_static-unstable-libraries.patch, debian/patches/99_automake.patch: - Only build static libraries, they're not API/ABI stable yet but are used by some plugins already. + debian/rules, debian/build-deps.in: - Update build dependencies. + debian/gstreamer-plugins-bad.install: - Add new asfmux, frei0r, kate and schroedinger plugins. - Remove rtpmanager plugin, which was moved to gst-plugins-good. + debian/control.in: - Add Conflicts/Replaces/Provides for gstreamer0.10-schroedinger. * debian/control.in: + Update Standards-Version to 3.8.2, no additional changes needed. Checksums-Sha1: d1d3915a1f827c4b6fd06a057e069dd2595865de 2730 gst-plugins-bad0.10_0.10.13.2-1.dsc 910d9072165458209766337277913042a3a97d34 4176920 gst-plugins-bad0.10_0.10.13.2.orig.tar.gz 592af6c7314cfc9821f082628ec061f7e991d341 17282 gst-plugins-bad0.10_0.10.13.2-1.diff.gz 5ed29f464f486916c90d222b7267f03a56a5340e 179292 gstreamer0.10-plugins-bad-doc_0.10.13.2-1_all.deb 7938a328c18dff9ecbd8d408c2c9181e70deb43f 1387454 gstreamer0.10-plugins-bad_0.10.13.2-1_amd64.deb 346e9777c6e02a788c4fcc4e0eb7328bd1a63e31 43872 gstreamer0.10-sdl_0.10.13.2-1_amd64.deb fb8e50648100648831d56f59b91b5b22f7b54675 3424416 gstreamer0.10-plugins-bad-dbg_0.10.13.2-1_amd64.deb Checksums-Sha256: 2a2dafcb674790819f263b79a9177bf79e58e40e1dfda8bfecbe9e91369cc2d3 2730 gst-plugins-bad0.10_0.10.13.2-1.dsc 2caea1902e61d0fc00fc330fd489fc3ec037eb28dfed788bea83729eae707375 4176920 gst-plugins-bad0.10_0.10.13.2.orig.tar.gz e1995a0f8fd4ff087e8fefba5ebd333a23c0aef49c29ca5fb7ed77d3ccca4fd4 17282 gst-plugins-bad0.10_0.10.13.2-1.diff.gz 19fcaaa9af409a89b4a847a00027879bf8c528fe80de9d9ba62fdf0e02e3ef4c 179292 gstreamer0.10-plugins-bad-doc_0.10.13.2-1_all.deb 7ef337c8a1f96d83414cb53a0a45bd73bb1ad27cd21facc9ee716b750e36246a 1387454 gstreamer0.10-plugins-bad_0.10.13.2-1_amd64.deb 80753da6797557e087823611dc7b8b5562011afe4564a6ee9c2c7c3dcaa01c1c 43872 gstreamer0.10-sdl_0.10.13.2-1_amd64.deb a90f1393ed1350bf212762aace3ec7aa7834957d399ef049b9d103049ac6a031 3424416 gstreamer0.10-plugins-bad-dbg_0.10.13.2-1_amd64.deb Files: 67f0d3edf1776156bb115bbd98b5aa56 2730 libs extra gst-plugins-bad0.10_0.10.13.2-1.dsc 0002394213393a065d047f49fa16bc69 4176920 libs extra gst-plugins-bad0.10_0.10.13.2.orig.tar.gz 1ec88fb52c69e2af14c1dea8498f3e5c 17282 libs extra gst-plugins-bad0.10_0.10.13.2-1.diff.gz c4e22358f7215954098b14e652597225 179292 doc extra gstreamer0.10-plugins-bad-doc_0.10.13.2-1_all.deb f7d577a74428afb6c5cd81540a6104d9 1387454 libs extra gstreamer0.10-plugins-bad_0.10.13.2-1_amd64.deb 89bfc3f80404cfcaa49a45e0bb0eb83c 43872 libs extra gstreamer0.10-sdl_0.10.13.2-1_amd64.deb ad072c01697daefd3b0d0cea31ad3270 3424416 debug extra gstreamer0.10-plugins-bad-dbg_0.10.13.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCb1EACgkQBsBdh1vkHyHD/gCgkK75roiL6mD7QeFEFUkV63Im OiwAoIlbFYJ4vh/aeiSitZs0KjnK/urG =xJKl -END PGP SIGNATURE- Accepted: gst-plugins-bad0.10_0.10.13.2-1.diff.gz to pool/main/g/gst-plugins-bad0.10/gst-plugins-bad0.10_0.10.13.2-1.diff.gz gst-plugins-bad0.10_0.10.13.2-1.dsc to pool/main/g/gst-plugins-bad0.10/gst-plugins-bad0.10_0.10.13.2-1.dsc gst-plugins-bad0.10_0.10.13.2.orig.tar.gz to pool/main/g/gst-plugins-bad0.10/gst-plugins-bad0.10_0.10.13.2.orig.tar.gz gstreamer0.10-plugins-bad-dbg_0.10.13.2-1_amd64.deb to pool/main/g/gst-plugins-bad0.10/gstreamer0.10-plugins-bad-dbg_0.10.13.2-1_amd64.deb gstreamer0.10-plugins-bad-doc_0.10.13.2-1_all.deb to
Accepted reportbug 4.6 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 12 Aug 2009 10:57:03 +0200
Source: reportbug
Binary: reportbug python-reportbug
Architecture: source all
Version: 4.6
Distribution: unstable
Urgency: low
Maintainer: Reportbug Maintainers reportbug-ma...@lists.alioth.debian.org
Changed-By: Sandro Tosi mo...@debian.org
Description:
python-reportbug - Python modules for interacting with bug tracking systems
reportbug - reports bugs in the Debian distribution
Closes: 166168 222621 304006 376810 414554 427560 435818 451041 529251 535560
535789 536873 537449 537624 537929 538021
Changes:
reportbug (4.6) unstable; urgency=low
.
* reportbug/__init__.py
- bump reportbug version
* bin/querybts
- allows to specify multiple bugs number with --mbox; thanks to Trent Buck
for the report and Carl Chenet for the patch: Closes: #427560
* reportbug/submit.py
- added support for gnupg-agent with signing emails; thanks to Mathias
Brodala or the report and Carl Chenet for the patch: Closes: #435818
* bin/reportbug
- allow ENTER to exit from file detaching menu (and enforced file
checking);
thanks to Rodrigo Campos for report and (partial) patch; Closes: 535789
- do not exit if no subject is entered for new bugs, but keep asking it;
thanks to Olaf van der Spek for the report and Carl Chenet for the patch;
Closes: #537449
- do not exit if no subject is entered for additional information, but keep
asking it; thanks to Carl Chenet for the report and patch: Closes:
#537624
- configuration asks also if 'smtptls' is needed or not; thanks to Jerome
Reybert for the report; Closes: #538021
- allow to add tags to the bug even in the last menu (right before
sending);
thanks to Enrico Zini for the report and Carl Chenet for the patch;
Closes: #304006
* bin/querybts, man/querybts.1, reportbug/ui/text_ui.py
- querybts is now able to handle multiple bug numbers, package names or any
mix of them when using --mbox option; thanks to Carl Chenet for the
report
and patch; Closes: #535560
- added -b/--buglist option to display a bugs list for the given package;
thanks to Andrew Ferrier for the report and Carl Chenet for the patch;
Closes: #222621
* bin/reportbug, reportbug/ui/text_ui.py
- provide a default reply subject ('Re: ' + original subject) when
providing additional information to a bug report; thanks to Carl Chenet
for the report and patch; Closes: #537929
* reportbug/ui/text_ui.py
- allow to open a browser with the complete packages' bugs list; thanks to
Eduard Bloch for the report and to Carl Chenet for the patch;
Closes: #166168
- expand the ~ or any other environment variables in attachment file name;
thanks to Andreas Pakulat, Raúl Sánchez Siles, Emil Nowak for the reports
and to Carl Chenet for the patch; Closes: #376810, #414554, #451041
* reportbug/submit.py, reportbug/ui/text_ui.py
- if MUA returns an error, notify the user allowing to re-edit the mail
(without loosing the mail); thanks to Raphaël Hertzog for the report and
to Carl Chenet for the patch; Closes: #529251
* reportbug/urlutils.py, debian/control
- use xdg-open instead of sensible-browser to open URLs: it uses the
selected browser in the desktop environment, else it falls back to s-b;
thanks to Alexandre Fournier for the report; Closes: #536873
Checksums-Sha1:
19b2ea7de6f358f19f602d697b6bba826c174593 1124 reportbug_4.6.dsc
47ad475f636c017ebcdbdfa1b3d6a6aa3e22d2b7 196050 reportbug_4.6.tar.gz
2692cec133d169eae400f6dbb9603ead50c66c16 121334 reportbug_4.6_all.deb
48f566971b463c7af4ae7f18cb1a992a5f20f2d1 115990 python-reportbug_4.6_all.deb
Checksums-Sha256:
f4063d14d5682d602a0ddd9f7391590a4df30e65d0d67060e5b464d68e1c5a9e 1124
reportbug_4.6.dsc
44ef47a4ad3f258c2b00d81b3f3ec8e79b2628bc490b9924c3c71e1e7f49094e 196050
reportbug_4.6.tar.gz
fec9ebf269cb0504bffcee6fa180533894296b874dc8039140b193f7237a028b 121334
reportbug_4.6_all.deb
66652453cd9cef4a6bb710d52ee24b2f51a6c571311e3c101b4e2e98bca6ff38 115990
python-reportbug_4.6_all.deb
Files:
162ff9a0c7048e3ddd407de01a2e3aaf 1124 utils standard reportbug_4.6.dsc
464806b26129175d7a8148e9372d4568 196050 utils standard reportbug_4.6.tar.gz
f8ee5d46274e61adc85840ba614e89de 121334 utils standard reportbug_4.6_all.deb
53bc1f428251c1c517b293d26df2061f 115990 python standard
python-reportbug_4.6_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqChZgACgkQAukwV0RN2VCk2gCgmxlLGaXhR5JAujBpDmmP2QYR
zwoAn1vIeBFKqe0Ft37piLO1ySoygI85
=3n1j
-END PGP SIGNATURE-
Accepted:
python-reportbug_4.6_all.deb
to pool/main/r/reportbug/python-reportbug_4.6_all.deb
reportbug_4.6.dsc
to pool/main/r/reportbug/reportbug_4.6.dsc
reportbug_4.6.tar.gz
to pool/main/r/reportbug/reportbug_4.6.tar.gz
Accepted goto-fai-progress 2.0-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 02:40:00 +0200 Source: goto-fai-progress Binary: goto-fai-progress Architecture: source all Version: 2.0-2 Distribution: unstable Urgency: low Maintainer: GOsa packages mainteners group gosa-...@oss.gonicus.de Changed-By: Cajus Pollmeier ca...@debian.org Description: goto-fai-progress - Fully Automatic Installation progress bar Closes: 540609 540670 Changes: goto-fai-progress (2.0-2) unstable; urgency=low . * Added debconf Czech translation (Closes: #540609) * Corrected binary-arch target (Closes: #540670) * Removed additional po-debconf template Checksums-Sha1: 197e379f7d2a1765b25a422af3bcbfde4ccb4568 1083 goto-fai-progress_2.0-2.dsc 5c34e42d47d54d51d5be8b97643797a6ebdc4221 170393 goto-fai-progress_2.0-2.tar.gz 604cdf6b85724533b1fb32385c61652a9655e2a8 86250 goto-fai-progress_2.0-2_all.deb Checksums-Sha256: 21a935ccd707c7957fabe5d0b998aea5727c076dad0020b206f7389773f7db09 1083 goto-fai-progress_2.0-2.dsc 13e060b764f54d25a4c507099358227be63d1dd05669bc375ec0dcdf91e1e23d 170393 goto-fai-progress_2.0-2.tar.gz c669524d8697e01079a490bacf2bca5b2b4d5be30ed6579fbf46ce234fe3e894 86250 goto-fai-progress_2.0-2_all.deb Files: f776cc74fcdfdeed791e1e81148e1443 1083 utils optional goto-fai-progress_2.0-2.dsc 0da6cd373d7ac562b825a7ec63116948 170393 utils optional goto-fai-progress_2.0-2.tar.gz e4b96d99ed61a6ba309898bf568cb108 86250 utils optional goto-fai-progress_2.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKgnn2tyibJ/7Y+CYRAljmAKDIEzk14J5SAwDpcVR0+vMUzSQmCwCaAxMu Ewz+zZGMMy2GrTqnLeRjk2E= =PKB4 -END PGP SIGNATURE- Accepted: goto-fai-progress_2.0-2.dsc to pool/main/g/goto-fai-progress/goto-fai-progress_2.0-2.dsc goto-fai-progress_2.0-2.tar.gz to pool/main/g/goto-fai-progress/goto-fai-progress_2.0-2.tar.gz goto-fai-progress_2.0-2_all.deb to pool/main/g/goto-fai-progress/goto-fai-progress_2.0-2_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ldap2zone 0.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 02:34:00 +0200 Source: ldap2zone Binary: ldap2zone Architecture: source i386 Version: 0.1-2 Distribution: unstable Urgency: low Maintainer: GOsa packages mainteners group gosa-...@oss.gonicus.de Changed-By: Cajus Pollmeier ca...@debian.org Description: ldap2zone - Extract DNS zones from LDAP trees Closes: 540293 540673 Changes: ldap2zone (0.1-2) unstable; urgency=low . * Converted to new ldap api (Closes: #540293) * Corrected binary-arch target (Closes: #540673) Checksums-Sha1: 758fe37bf9d9ab2383e8084606f722673b76051a 1006 ldap2zone_0.1-2.dsc c5ab59965b750b19a44f222121540ce10a505723 11931 ldap2zone_0.1-2.tar.gz 658d6d0bab6f6de29aef08a3df7767a464a857e8 8290 ldap2zone_0.1-2_i386.deb Checksums-Sha256: bd49c9fc9670739246bc92993a0cb7ba798eb681b5d2b4063ddc27b8085a9f23 1006 ldap2zone_0.1-2.dsc 33ec2239a69af8b6f32c11dc0fb737a4a237199e47c5d6067f810a4f278ac8fb 11931 ldap2zone_0.1-2.tar.gz 754161a3264508ac38b8df5d707243c71b44b0b53bb8ec46e4c4ee74c34fa4ff 8290 ldap2zone_0.1-2_i386.deb Files: dc4476f0baddcda64771e86c5682b936 1006 utils optional ldap2zone_0.1-2.dsc d96bc01b270d134daf6c4942f2e2a22e 11931 utils optional ldap2zone_0.1-2.tar.gz e83829b8fbbb0f9256729ea8da426b3a 8290 utils optional ldap2zone_0.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKgnaetyibJ/7Y+CYRAhKvAJsES4Jxgc9lv+7tUW5Whu5WBz5VjwCgo3MB cIfTgWSj9YDc7lg4ygIPl4Q= =6WAi -END PGP SIGNATURE- Accepted: ldap2zone_0.1-2.dsc to pool/main/l/ldap2zone/ldap2zone_0.1-2.dsc ldap2zone_0.1-2.tar.gz to pool/main/l/ldap2zone/ldap2zone_0.1-2.tar.gz ldap2zone_0.1-2_i386.deb to pool/main/l/ldap2zone/ldap2zone_0.1-2_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted docbookwiki 0.9.1cvs-11 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 20 Jul 2009 17:59:41 +0800 Source: docbookwiki Binary: docbookwiki Architecture: source all Version: 0.9.1cvs-11 Distribution: unstable Urgency: low Maintainer: Jeremy Malcolm termi...@debian.org Changed-By: Jeremy Malcolm termi...@debian.org Description: docbookwiki - a Web application to display and edit DocBook documents online Closes: 519599 531041 537068 537533 Changes: docbookwiki (0.9.1cvs-11) unstable; urgency=low . * Substituted svn-load dependency for undistributable svn_load_dirs.pl script (Closes: #519599) * Updated Czech, Spanish and Galician translations (Closes: #531041, #537068, #537533) Checksums-Sha1: aeb358c25cf4433506347fb965485d68241c4475 1028 docbookwiki_0.9.1cvs-11.dsc dd5fa48263b5696a37e6aa079a64e829973a45a4 17732 docbookwiki_0.9.1cvs-11.diff.gz 2d9765ff9b9e1dbf4edd44551cff5811ce416bed 912074 docbookwiki_0.9.1cvs-11_all.deb Checksums-Sha256: 11c94ef15dc993a1d35e35723f68414874fc71b5aaa060286381d39222ef378f 1028 docbookwiki_0.9.1cvs-11.dsc 1974a94dc87144460a156fb82a8df4c4529f9cd76ef469ea6029978aefd8c0a6 17732 docbookwiki_0.9.1cvs-11.diff.gz 918d1ef7b28f47702778763e98e3eab86fd9ad9419cdf1288fba05126e188bd4 912074 docbookwiki_0.9.1cvs-11_all.deb Files: a4700551dc107fee9669887580c011fc 1028 non-free/web extra docbookwiki_0.9.1cvs-11.dsc 534fea230cee81f4f19b91fe22f13c63 17732 non-free/web extra docbookwiki_0.9.1cvs-11.diff.gz 02a4dd6f66aa312d3572bb5578781352 912074 non-free/web extra docbookwiki_0.9.1cvs-11_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKd+3u9nWq4tKrIiARAgCBAKCztfwa6Gfa8swL67hnQ597GuckrQCg166d 81luPq2ErWArWVhX+hRcelk= =2f80 -END PGP SIGNATURE- Accepted: docbookwiki_0.9.1cvs-11.diff.gz to pool/non-free/d/docbookwiki/docbookwiki_0.9.1cvs-11.diff.gz docbookwiki_0.9.1cvs-11.dsc to pool/non-free/d/docbookwiki/docbookwiki_0.9.1cvs-11.dsc docbookwiki_0.9.1cvs-11_all.deb to pool/non-free/d/docbookwiki/docbookwiki_0.9.1cvs-11_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted zope2.10 2.10.9-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 09 Aug 2009 15:58:49 +0200 Source: zope2.10 Binary: zope2.10 zope2.10-sandbox Architecture: source amd64 all Version: 2.10.9-1 Distribution: unstable Urgency: high Maintainer: Jonas Meurer m...@debian.org Changed-By: Jonas Meurer m...@debian.org Description: zope2.10 - Open Source Web Application Server zope2.10-sandbox - sandbox instance for the zope2.10 web application server Closes: 540159 540464 Changes: zope2.10 (2.10.9-1) unstable; urgency=high . * New upstraem release, fixes two vulnerabilities in the ZEO network protocol: CVE-2009-0668 and CVE-2009-0669. (closes: #540464) * Add support to start a particular instance to initscript. * Bump pre-depends on zope-common to 0.5.49 and build-depends on debhelper to 0.3.14 to use invoke-rc.d in maintainer scripts. (closes: #540159) * Set urgency=high as this upload fixes two serious bugs. Checksums-Sha1: 8b16815dc1a28b2ea3f71cc8e03b7dfc45fae803 1425 zope2.10_2.10.9-1.dsc 96271ad13372e2f7db1413805a23b76772a7af86 7175300 zope2.10_2.10.9.orig.tar.gz bf85d21d8713f26e8400f0f4c590de2aad0a681d 14618 zope2.10_2.10.9-1.diff.gz 5e5c572052fd8050fe1a98fa0fe8933c2b68785e 7068002 zope2.10_2.10.9-1_amd64.deb 6d9c069261bb13b6085266eb395647dd6e14cd44 182008 zope2.10-sandbox_2.10.9-1_all.deb Checksums-Sha256: eeed2727ec648d103ad48f96eb6b8faf0dff5bdeb0f4ffd9199fb757e6e7efb3 1425 zope2.10_2.10.9-1.dsc 7c513425f5181c8c142eee5bce15813e5f6830fba499255d51b603626dffa990 7175300 zope2.10_2.10.9.orig.tar.gz 37aafb37203777edc5d045a5cc15b02527cce3e424f122c33b70af58b69096a4 14618 zope2.10_2.10.9-1.diff.gz 94ea7e7b87ce0eb2d02021e9baf62d646d870d52295139a70780a31ee6071ae3 7068002 zope2.10_2.10.9-1_amd64.deb 9519bfb52ac080b92df403c2c56a9b68bec5adee11f2bf93dcc2bcbb0747dbbc 182008 zope2.10-sandbox_2.10.9-1_all.deb Files: 672c170159850e799aed63d004561956 1425 zope optional zope2.10_2.10.9-1.dsc e9d87f7f048eeeaf39bb1cdebb5ba634 7175300 zope optional zope2.10_2.10.9.orig.tar.gz b4eb5d6ebae7087b800bbd9026af7675 14618 zope optional zope2.10_2.10.9-1.diff.gz 3d59f8c1166605b84f014c5bef4e68fe 7068002 zope optional zope2.10_2.10.9-1_amd64.deb 23eedee598275fd75934851a0f6d888c 182008 zope optional zope2.10-sandbox_2.10.9-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCkK0ACgkQd6lUs+JfIQJUywCfWmtlATFmWgWUDeH14D5i4Udr qcIAnjcBV1RCaFGd+p+DXCm0nuwkiamc =q10d -END PGP SIGNATURE- Accepted: zope2.10-sandbox_2.10.9-1_all.deb to pool/main/z/zope2.10/zope2.10-sandbox_2.10.9-1_all.deb zope2.10_2.10.9-1.diff.gz to pool/main/z/zope2.10/zope2.10_2.10.9-1.diff.gz zope2.10_2.10.9-1.dsc to pool/main/z/zope2.10/zope2.10_2.10.9-1.dsc zope2.10_2.10.9-1_amd64.deb to pool/main/z/zope2.10/zope2.10_2.10.9-1_amd64.deb zope2.10_2.10.9.orig.tar.gz to pool/main/z/zope2.10/zope2.10_2.10.9.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted zope2.11 2.11.4-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 09 Aug 2009 16:00:28 +0200 Source: zope2.11 Binary: zope2.11 zope2.11-sandbox Architecture: source amd64 all Version: 2.11.4-1 Distribution: unstable Urgency: high Maintainer: Jonas Meurer m...@debian.org Changed-By: Jonas Meurer m...@debian.org Description: zope2.11 - Open Source Web Application Server zope2.11-sandbox - sandbox instance for the zope2.11 web application server Closes: 540158 540463 Changes: zope2.11 (2.11.4-1) unstable; urgency=high . * New upstream release, fixes two vulnerabilities in the ZEO network protocol: CVE-2009-0668 and CVE-2009-0669. (closes: #540463) * Add support to start a particular instance to initscript. * Bump pre-depends on zope-common to 0.5.49 and build-depends on debhelper to 0.3.14 to use invoke-rc.d in maintainer scripts. (closes: #540158) * Set urgency=high as this upload fixes two serious bugs. Checksums-Sha1: 04e388fdcd815c03040af4c6904bfa7373280ed9 1425 zope2.11_2.11.4-1.dsc 5073e6b02c2578ea0dd9f0dc8d35b8982bfb280b 7209105 zope2.11_2.11.4.orig.tar.gz 614cef2fae7264f245db2aab6ad2a2f22ea7f63a 14891 zope2.11_2.11.4-1.diff.gz 79e1d541984f61b84cd1de2a6066b5d01308ecda 7153750 zope2.11_2.11.4-1_amd64.deb 351c2742314bda8048114b1a23160a1b44700a1d 70728 zope2.11-sandbox_2.11.4-1_all.deb Checksums-Sha256: 6dd084c1769409576c37c09dc035e92424e94bd39c7cf28482b5b09c318e2491 1425 zope2.11_2.11.4-1.dsc 3a58da649e8a558eda82ed61d2417a4f48b6d7562a9f0c71a24f8a870178e220 7209105 zope2.11_2.11.4.orig.tar.gz 7bf28b997b9178a6a92244484b200c874c2f72285730caac9f06507d841e1830 14891 zope2.11_2.11.4-1.diff.gz a2bcd06ef04457097cce6182ec98eae08ef697d5ca46325f105c44382d79 7153750 zope2.11_2.11.4-1_amd64.deb 66c6896365273001c804ef968752f0bf8472432d0d4a3f3ca56713583d296c06 70728 zope2.11-sandbox_2.11.4-1_all.deb Files: 193b967599aa2e9186af311a1b542e20 1425 zope optional zope2.11_2.11.4-1.dsc b6ebe2c09ad69e288f90dcdaddd3fd5c 7209105 zope optional zope2.11_2.11.4.orig.tar.gz 103c646de582634c6ab6fe6fec5f6d1f 14891 zope optional zope2.11_2.11.4-1.diff.gz 4714917a65efd9b9a8666d1f7a9b1e56 7153750 zope optional zope2.11_2.11.4-1_amd64.deb 5094f604c214ae4f206a64f2c44089a3 70728 zope optional zope2.11-sandbox_2.11.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCkLQACgkQd6lUs+JfIQIBHgCgmlqUQu1qCrWCHi9I8WlYh8r1 t0AAoIegJZ8igski3UcoPw2OLMT5/Dg8 =chBr -END PGP SIGNATURE- Accepted: zope2.11-sandbox_2.11.4-1_all.deb to pool/main/z/zope2.11/zope2.11-sandbox_2.11.4-1_all.deb zope2.11_2.11.4-1.diff.gz to pool/main/z/zope2.11/zope2.11_2.11.4-1.diff.gz zope2.11_2.11.4-1.dsc to pool/main/z/zope2.11/zope2.11_2.11.4-1.dsc zope2.11_2.11.4-1_amd64.deb to pool/main/z/zope2.11/zope2.11_2.11.4-1_amd64.deb zope2.11_2.11.4.orig.tar.gz to pool/main/z/zope2.11/zope2.11_2.11.4.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted kaffeine 1.0~pre2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 02:23:50 +0200 Source: kaffeine Binary: kaffeine kaffeine-dbg Architecture: source amd64 Version: 1.0~pre2-1 Distribution: experimental Urgency: low Maintainer: Fathi Boudra f...@debian.org Changed-By: Fathi Boudra f...@debian.org Description: kaffeine - versatile media player for KDE kaffeine-dbg - debugging symbols for kaffeine Changes: kaffeine (1.0~pre2-1) experimental; urgency=low . * New upstream release (KDE 4 version). * Bump debian/compat to 7. * Update debian/control: - Move kaffeine to section video. - Cleanup build depencies for the KDE 4 version. - Update Homepage field. - Cleanup dependencies for the KDE 4 version. - Update description. * Rewrite debian/copyright file (KDE 4 version). * Cleanup debian/kaffeine.docs file. * Add debian/kaffeine.install file. * Convert debian/rules to dh usage. Checksums-Sha1: 37b2e94f4a29e8764e1fb772470eabbd8d876b1f 1443 kaffeine_1.0~pre2-1.dsc 6ba1d910980c0997da95fa4b56ff3d7d3cf69ec6 286714 kaffeine_1.0~pre2.orig.tar.gz 7caf4264b59290ed2466c4230cdb125901a27600 11840 kaffeine_1.0~pre2-1.diff.gz ffcf56c0932d9a2638cf7669432556263409c2c0 399452 kaffeine_1.0~pre2-1_amd64.deb 5517779eea060f06a0229e34b54963a8de694c05 1591122 kaffeine-dbg_1.0~pre2-1_amd64.deb Checksums-Sha256: 7b48b57f036b6d94392fcf9f3a3543aeea40ffc4816e97fb9573e69c44a6d232 1443 kaffeine_1.0~pre2-1.dsc c1c22761e594364baa65e145d4451a07edefa3471ad7f8650756e4eadf7c303b 286714 kaffeine_1.0~pre2.orig.tar.gz 3d4a61f046d16769404a403440fbcf4c48cec8f8e9f6d083de17c724097f63d4 11840 kaffeine_1.0~pre2-1.diff.gz 1eba7a06056d61a5a292284fb0d11338f5aac4fdc30cbc411c05b86268ff06a8 399452 kaffeine_1.0~pre2-1_amd64.deb 37025e9434d107a204197d192b9fb24a9a9a8fa64057362cde5385e5a5aefb3d 1591122 kaffeine-dbg_1.0~pre2-1_amd64.deb Files: 8caa3d822a94d93098800127bc298828 1443 video optional kaffeine_1.0~pre2-1.dsc 2de344220358815679be3358139738da 286714 video optional kaffeine_1.0~pre2.orig.tar.gz 2206458e58728d2efb3821c7cb03ca8e 11840 video optional kaffeine_1.0~pre2-1.diff.gz c18593dd7c81f8836e377ecabdca5f14 399452 video optional kaffeine_1.0~pre2-1_amd64.deb 3eeb6fbd1e07d0c2fa26ce65c7742dbd 1591122 debug extra kaffeine-dbg_1.0~pre2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iJwEAQECAAYFAkqCk00ACgkQjPU19mqlcvejxQP+O/E5+nitB9SeXIQ590B+eIKF MLVsCXP3qtAEg/o0oeKqylVcW22trfW13b+kcyKhWqyZrif/cVpuUPTX8N0Flf+1 rA2ETo1xyInRt9nXMbVD3/+73GmoVHsZ2BGMH55eAWGe3r7KptfcSIudXDvjEp2W F5ZJw7ku6RiokO1M9ZI= =1qz6 -END PGP SIGNATURE- Accepted: kaffeine-dbg_1.0~pre2-1_amd64.deb to pool/main/k/kaffeine/kaffeine-dbg_1.0~pre2-1_amd64.deb kaffeine_1.0~pre2-1.diff.gz to pool/main/k/kaffeine/kaffeine_1.0~pre2-1.diff.gz kaffeine_1.0~pre2-1.dsc to pool/main/k/kaffeine/kaffeine_1.0~pre2-1.dsc kaffeine_1.0~pre2-1_amd64.deb to pool/main/k/kaffeine/kaffeine_1.0~pre2-1_amd64.deb kaffeine_1.0~pre2.orig.tar.gz to pool/main/k/kaffeine/kaffeine_1.0~pre2.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted gnunet 0.8.0c-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 12:34:42 +0200 Source: gnunet Binary: gnunet gnunet-client gnunet-common gnunet-dbg gnunet-server gnunet-dev gnunet-tools Architecture: source all i386 Version: 0.8.0c-4 Distribution: unstable Urgency: low Maintainer: Debian GNUnet Maintainers gnu...@lists.debian-maintainers.org Changed-By: Daniel Baumann dan...@debian.org Description: gnunet - secure, trust-based peer-to-peer framework (meta) gnunet-client - secure, trust-based peer-to-peer framework (client) gnunet-common - secure, trust-based peer-to-peer framework (common) gnunet-dbg - secure, trust-based peer-to-peer framework (debug) gnunet-dev - secure, trust-based peer-to-peer framework (development) gnunet-server - secure, trust-based peer-to-peer framework (server) gnunet-tools - secure, trust-based peer-to-peer framework (tools) Changes: gnunet (0.8.0c-4) unstable; urgency=low . * Removing gnunet-update call in gnunet-server postinst, it's not required anymore. Checksums-Sha1: 0c51970888a59a1b633634420bcf6dd81d6504d0 1592 gnunet_0.8.0c-4.dsc e8d105d1c362fb02b7abae02530a740835f04a89 22302 gnunet_0.8.0c-4.diff.gz 88f7bdc662de4c8cb74bd00ac1406858d0f120dc 42064 gnunet_0.8.0c-4_all.deb 070526b1c2829ebfa8d1c2f2072cdd822ae036ac 224156 gnunet-client_0.8.0c-4_i386.deb 2f2ec732d8e5fef7ff2b092638780a4b0043c060 218138 gnunet-common_0.8.0c-4_i386.deb 108d5476dfb02e677c63d882b4412ef03740e2ee 1147396 gnunet-dbg_0.8.0c-4_i386.deb a6bb5f56e03d7719f72948dec8fc19295646d4ea 308086 gnunet-server_0.8.0c-4_i386.deb c208e5e1f7fef91e5101c7f0e6c580597a51b9c2 134262 gnunet-dev_0.8.0c-4_i386.deb 5d8b6523de2e4fc21c35eaedf1eda1bfb633fd06 254824 gnunet-tools_0.8.0c-4_i386.deb Checksums-Sha256: f2790f281c934b462118a496fe831ebb3a09f5a8afe5bdaf07f7430678f04e01 1592 gnunet_0.8.0c-4.dsc c582d9f32dfb7fd213ebd85fd864c4b31a35c19ba08e1907b63838c6b89508ef 22302 gnunet_0.8.0c-4.diff.gz 3034cf03f90331618248b8bcb585f20d949a8770e71c5155f357feaf5ea02e57 42064 gnunet_0.8.0c-4_all.deb aaad85a32e11a2518d58ee9a6040813fadef911272d34d4c72b25e59eba2735f 224156 gnunet-client_0.8.0c-4_i386.deb 6af974709de0966b8993537438256a588848bbbd98f87ab372a8488c01cc69f2 218138 gnunet-common_0.8.0c-4_i386.deb a0c48f35ac76a0e79b8e16de69f3cb0a0587f96a94af7a962b8d7d0cce7710fc 1147396 gnunet-dbg_0.8.0c-4_i386.deb c88253b777dae27cca4966c5d374e472d770564e9065bb2e3fd5a61391c5ef60 308086 gnunet-server_0.8.0c-4_i386.deb b2d66cb81d4d0bf48e3109b840fe1a6bf91b246755fbd20e6862ba9a6a740ac9 134262 gnunet-dev_0.8.0c-4_i386.deb 67e7c75a2031cebc1437c82991dc11787d20c54044c1aff6f9e3bbe0a4992a1c 254824 gnunet-tools_0.8.0c-4_i386.deb Files: 7e46fddc364a4fb33b47bb3eb94afa92 1592 net optional gnunet_0.8.0c-4.dsc 2cbae998a233caa986f145bd9615f1d8 22302 net optional gnunet_0.8.0c-4.diff.gz 5c6e2d30a122efdc4ef34b104eca9b20 42064 net optional gnunet_0.8.0c-4_all.deb de7b2b5e11550fd2b862ec4ecfb68cd5 224156 net optional gnunet-client_0.8.0c-4_i386.deb 694f7ebe67738b461bd72dce74913fe8 218138 net optional gnunet-common_0.8.0c-4_i386.deb 8541173cb3511962298ecf9f046a7fde 1147396 debug extra gnunet-dbg_0.8.0c-4_i386.deb e8917d0802d1abb10b2170d3e731457b 308086 net optional gnunet-server_0.8.0c-4_i386.deb 5c0f78ce1db4047e38282ef8382fde7d 134262 libdevel optional gnunet-dev_0.8.0c-4_i386.deb c8a7ea7bb3af3fd03119643a4a9c9f0e 254824 net optional gnunet-tools_0.8.0c-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCm+wACgkQ+C5cwEsrK57e4ACfSZ6oV0nrinzXDOsYgtioTqrL jAoAoITbeT42dZTMqJ6BSaFQbCjYi+ew =XUlP -END PGP SIGNATURE- Accepted: gnunet-client_0.8.0c-4_i386.deb to pool/main/g/gnunet/gnunet-client_0.8.0c-4_i386.deb gnunet-common_0.8.0c-4_i386.deb to pool/main/g/gnunet/gnunet-common_0.8.0c-4_i386.deb gnunet-dbg_0.8.0c-4_i386.deb to pool/main/g/gnunet/gnunet-dbg_0.8.0c-4_i386.deb gnunet-dev_0.8.0c-4_i386.deb to pool/main/g/gnunet/gnunet-dev_0.8.0c-4_i386.deb gnunet-server_0.8.0c-4_i386.deb to pool/main/g/gnunet/gnunet-server_0.8.0c-4_i386.deb gnunet-tools_0.8.0c-4_i386.deb to pool/main/g/gnunet/gnunet-tools_0.8.0c-4_i386.deb gnunet_0.8.0c-4.diff.gz to pool/main/g/gnunet/gnunet_0.8.0c-4.diff.gz gnunet_0.8.0c-4.dsc to pool/main/g/gnunet/gnunet_0.8.0c-4.dsc gnunet_0.8.0c-4_all.deb to pool/main/g/gnunet/gnunet_0.8.0c-4_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted spell 1.0-23 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 13:28:25 +0200 Source: spell Binary: spell Architecture: source amd64 Version: 1.0-23 Distribution: unstable Urgency: low Maintainer: Giacomo Catenazzi c...@debian.org Changed-By: Giacomo Catenazzi c...@debian.org Description: spell - GNU Spell, a clone of Unix `spell' Changes: spell (1.0-23) unstable; urgency=low . * Adopting the package (Closes: #) * Added Homepage field in debian/control * Added again debian/watch Checksums-Sha1: c1b0d4b15a2fcf9dc6a8c8388047297e2d0f5fa2 981 spell_1.0-23.dsc 5936dfa0e5dc652721c68369f10c928ddae45318 8925 spell_1.0-23.diff.gz 4cab86375fc02b9a93168a6a2c0ad948fea07fba 15026 spell_1.0-23_amd64.deb Checksums-Sha256: 992bd8141c632796da11de8c74a9ff048fe7b78907cea9ddd93bcec7e77433a0 981 spell_1.0-23.dsc 8b1c6eb13b2484b99864ab26e23ce926ee55e25514c6821621b188aeb97c50cf 8925 spell_1.0-23.diff.gz 5b910cd34845655534006dd9d68753c73fd216f4b80f7770f4673e003bc7bf3c 15026 spell_1.0-23_amd64.deb Files: 99aa82efc7623e2a74d7f75ddfa6127e 981 text optional spell_1.0-23.dsc fb8bdb2c201dbd860497629e82bb483d 8925 text optional spell_1.0-23.diff.gz be1a32cb23a6c8bb427ace9d3be9e07d 15026 text optional spell_1.0-23_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCqQEACgkQ+ZNUJLHfmldusgCcCMZGTXKibNzO9xq+IUxaYDu0 xLwAnRBkmr3pi8FDGZJyNkdAxfs2ldV1 =AL8t -END PGP SIGNATURE- Accepted: spell_1.0-23.diff.gz to pool/main/s/spell/spell_1.0-23.diff.gz spell_1.0-23.dsc to pool/main/s/spell/spell_1.0-23.dsc spell_1.0-23_amd64.deb to pool/main/s/spell/spell_1.0-23_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted padre 0.42-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 14:44:55 +0300 Source: padre Binary: padre libwx-perl-dialog-perl Architecture: source all Version: 0.42-1 Distribution: unstable Urgency: low Maintainer: Damyan Ivanov d...@debian.org Changed-By: Damyan Ivanov d...@debian.org Description: libwx-perl-dialog-perl - abstract dialog class for simple dialog creation padre - Perl Application Development and Refactoring Environment Changes: padre (0.42-1) unstable; urgency=low . * New Upstream Version + add explicit dependency on libtest-simple-perl (= 0.88) + rules: use dh --with quilt (and bump quilt build-dependency to 0.46-7) + rules: no need to re-generate .mo files from .po. Upstream does it now + copyright: describe share/icons/padre/16x16/logo.png - describe share/icons/padre/16x16/toggle-comments.png - Padre license is the same as Perl (i.e. not Perl 5) - update list of copright holders - also list translators + drop libtest-most-perl from build-dependencies + add liblocale-msgfmt-perl to build-dependencies + add libcapture-tiny-perl to (build-)dependencies + add libfile-remove-perl (= 1.42) to (build-)dependencies + drop libmodule-inspector-perl from (build-)dependencies + add libppix-editortools-perl to (build-)dependencies + add libparse-exuberantctags-perl to (build-)dependencies + patches: - drop lower-wx-requirement-to-2.8.7.patch and replace it with SKIP_WXWIDGETS_VERSION_CHECK=1 when configuring adjust README.debian accordingly - refresh disable-tcp-server.patch - drop don't-require-new-file-path.patch (applied upstream) - rework fix-pod2-errors.patch (new release, new errors :)) * add fix-perl-interpreter-path.patch fixing the path to the perl interpreter in three examples (thanks lintian) * add more lintian overrides about script-not-executable for scripts that are treated as examples/templates * add fix-whatis.patch fixing the whatis entry of Padre::Wx * add menu and .desktop file Checksums-Sha1: cf0352e4e9c493d52b0455a6c5ebd038a45c408a 2596 padre_0.42-1.dsc e313e62430b54a1a5440ba2d0fa023af561511fc 579114 padre_0.42.orig.tar.gz bbc8a2782c91c4403f95e8a4565a583dfa832c3d 16926 padre_0.42-1.diff.gz 92c13cb96c491fbb9e400087f19ec196c12eed40 926592 padre_0.42-1_all.deb 118f9409196e02e05dda16469b1a273bc86de347 44516 libwx-perl-dialog-perl_0.42-1_all.deb Checksums-Sha256: 305688946908db7d4714b01963bb0c54b3f9c44ea29b398beaf82bb06fa7ccd2 2596 padre_0.42-1.dsc 36df4a0b82011db57e2e22181fb6f19296293cf3e5d5e0f2d28b785eb777d95a 579114 padre_0.42.orig.tar.gz 3124343f89a9bd4341497ec8d83f6a72d52c8ca8dae3c6d86eabdced7111b7f7 16926 padre_0.42-1.diff.gz 4cd50199fc5edf4f31647831e9d35892f1b85144ebe8dd4b4d6a62c3abdd42e8 926592 padre_0.42-1_all.deb f1828c7d2c1fb6f61edb13c87292116cd241b95989dd764ad45982c11ed2edaa 44516 libwx-perl-dialog-perl_0.42-1_all.deb Files: e491d8f8b994361442046a880623c549 2596 perl optional padre_0.42-1.dsc 27ea05b6dfcb9c764b9a12821b6f90fe 579114 perl optional padre_0.42.orig.tar.gz f52f8470db5a98f4e8ebb88e26ccdcb2 16926 perl optional padre_0.42-1.diff.gz a83821efbe227c2b1765284534a82779 926592 perl optional padre_0.42-1_all.deb 6db1acd3e05cc29527e6d85f304ee366 44516 perl optional libwx-perl-dialog-perl_0.42-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCq9IACgkQHqjlqpcl9jtccQCgupEba2DTzIfADn6TBPZcEFqB FKcAn231xU+PP/sxhg3H2/0/MAp1CT9b =Obc8 -END PGP SIGNATURE- Accepted: libwx-perl-dialog-perl_0.42-1_all.deb to pool/main/p/padre/libwx-perl-dialog-perl_0.42-1_all.deb padre_0.42-1.diff.gz to pool/main/p/padre/padre_0.42-1.diff.gz padre_0.42-1.dsc to pool/main/p/padre/padre_0.42-1.dsc padre_0.42-1_all.deb to pool/main/p/padre/padre_0.42-1_all.deb padre_0.42.orig.tar.gz to pool/main/p/padre/padre_0.42.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted libcitadel 7.61-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 12:56:51 +0200 Source: libcitadel Binary: libcitadel2 libcitadel2-dbg libcitadel-dev Architecture: source amd64 Version: 7.61-1 Distribution: unstable Urgency: low Maintainer: Debian Citadel Team pkg-citadel-de...@lists.alioth.debian.org Changed-By: Michael Meskes mes...@debian.org Description: libcitadel-dev - Development files for libcitadel2 libcitadel2 - Citadel toolbox libcitadel2-dbg - Debugging symbols for libcitadel2 Changes: libcitadel (7.61-1) unstable; urgency=low . * New upstream version. Checksums-Sha1: 1e3a0adef3e0d47681fe71ed6bc4e9f4698a0a29 1342 libcitadel_7.61-1.dsc 594e4d01203787b2bc37594c4bb3cc7acb136254 517979 libcitadel_7.61.orig.tar.gz 8e20c36cf0a8c4bc9a6dea70171abd68b35c440f 6688 libcitadel_7.61-1.diff.gz cda3ce6700cc8ae46bf2b501784404f09b7b0bb9 59936 libcitadel2_7.61-1_amd64.deb 0e953a1e06805bb2fafaf2a78aa90ed9f5b18b88 93374 libcitadel2-dbg_7.61-1_amd64.deb fa9e9133d130cd6f926b9bcbf9eae44c45710712 70144 libcitadel-dev_7.61-1_amd64.deb Checksums-Sha256: 3e6e8d2921c27c6df8af916f5e53743bc70e2d123192fa5766e292ed925d352c 1342 libcitadel_7.61-1.dsc 9697eb868342ce8e86529b77440231e70ff8d6f21a9d9e355473a02e66becfd3 517979 libcitadel_7.61.orig.tar.gz b4b3720f0a564c91c3bc89fe6dedf0f4fd77365f994a37a894ff36b03d156293 6688 libcitadel_7.61-1.diff.gz 42e43f67d1a4501dab1f29ff3e2602acadf04a0a55e118183d770e056285483e 59936 libcitadel2_7.61-1_amd64.deb b08d7db4e98fafdd37ea64fe4f6df0756203874a1ca3659adf30173bc3472645 93374 libcitadel2-dbg_7.61-1_amd64.deb aa274436f2283476944c7bce97036d430cf18f93ce317445501d3dbc54c50fe4 70144 libcitadel-dev_7.61-1_amd64.deb Files: e3764ee3ba086586cb55536b10d76170 1342 libs extra libcitadel_7.61-1.dsc ba88587b54b3b174f9865a4708494e4a 517979 libs extra libcitadel_7.61.orig.tar.gz 6d228073d42d62e527b3862a320293a2 6688 libs extra libcitadel_7.61-1.diff.gz 1736f40a5156f0eba9df101b1b626fe0 59936 libs extra libcitadel2_7.61-1_amd64.deb 1abd99ddacb631afcb85eb41d331514c 93374 debug extra libcitadel2-dbg_7.61-1_amd64.deb 7150ee420f3cb3f070794f08468f4822 70144 libdevel extra libcitadel-dev_7.61-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKgrYbVkEm8inxm9ERAopkAJ4nn/1QF2D5hXJNNJ5l7ZWbrbqeSgCfXsgO wTt0EPvwD9To3XU2Qil28sA= =jDpS -END PGP SIGNATURE- Accepted: libcitadel-dev_7.61-1_amd64.deb to pool/main/libc/libcitadel/libcitadel-dev_7.61-1_amd64.deb libcitadel2-dbg_7.61-1_amd64.deb to pool/main/libc/libcitadel/libcitadel2-dbg_7.61-1_amd64.deb libcitadel2_7.61-1_amd64.deb to pool/main/libc/libcitadel/libcitadel2_7.61-1_amd64.deb libcitadel_7.61-1.diff.gz to pool/main/libc/libcitadel/libcitadel_7.61-1.diff.gz libcitadel_7.61-1.dsc to pool/main/libc/libcitadel/libcitadel_7.61-1.dsc libcitadel_7.61.orig.tar.gz to pool/main/libc/libcitadel/libcitadel_7.61.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted polyglot 1.4.36b-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 12 Aug 2009 09:27:24 +0200 Source: polyglot Binary: polyglot Architecture: source amd64 Version: 1.4.36b-1 Distribution: unstable Urgency: low Maintainer: Oliver Korff o...@xynyx.de Changed-By: Oliver Korff o...@xynyx.de Description: polyglot - chess engine protocol adaptor, connects UCI engines to xboard Changes: polyglot (1.4.36b-1) unstable; urgency=low . * Bugfix Upload, new upstram release. * polyglot had problems to open .ini files, this was fixed by upstream, see changelog for details * The sourcecode was repackaged to get rid of the old debian directory, It is included as debian-orig.tar.gz Checksums-Sha1: f77735c2ef07a9a928f2a49c1072b5c18da5900c 1034 polyglot_1.4.36b-1.dsc d65fd52df142236baba243b37bd76f4611716dd0 259682 polyglot_1.4.36b.orig.tar.gz 198196910d083af4d055af6c80da6b942aa74bed 6038 polyglot_1.4.36b-1.diff.gz 16bb5c89843aa353cf0e031dabcb72f033a19d03 114206 polyglot_1.4.36b-1_amd64.deb Checksums-Sha256: b9f52bf4bd61e416c36de7f6a907df9e645cc461529b9a5f47db133f4fa36765 1034 polyglot_1.4.36b-1.dsc f3d6b87620c3302bac8a7acc374b590f0eb4714e8c8d5b3229f10ca4e1b9a45c 259682 polyglot_1.4.36b.orig.tar.gz 189325cfff8788a0b83372d04e3288705f6e5b40e87b0cbe13ce1f091569e5ce 6038 polyglot_1.4.36b-1.diff.gz 5452d61dc8eecd028d571daed8f442ecc5817f22db8f43245a0eebb0812ac272 114206 polyglot_1.4.36b-1_amd64.deb Files: 698cb94a35ce447a6fbfa2db00c99b33 1034 games optional polyglot_1.4.36b-1.dsc 46080905c1ee2a01f8b937f33e6fe6e0 259682 games optional polyglot_1.4.36b.orig.tar.gz 81a76e0d7e1db89fd5e97fe7635020c8 6038 games optional polyglot_1.4.36b-1.diff.gz be1c08cdcb248fa5214788b3eab7d9c2 114206 games optional polyglot_1.4.36b-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCtGQACgkQxa93SlhRC1pOqACgrHzwrjYM06yzioCENgDFGIV8 JecAoK9oqC1BCllJ967oM/hYdj8i7L1d =CEaj -END PGP SIGNATURE- Accepted: polyglot_1.4.36b-1.diff.gz to pool/main/p/polyglot/polyglot_1.4.36b-1.diff.gz polyglot_1.4.36b-1.dsc to pool/main/p/polyglot/polyglot_1.4.36b-1.dsc polyglot_1.4.36b-1_amd64.deb to pool/main/p/polyglot/polyglot_1.4.36b-1_amd64.deb polyglot_1.4.36b.orig.tar.gz to pool/main/p/polyglot/polyglot_1.4.36b.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
