Accepted minirok 2.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 15 Oct 2009 02:29:11 +0100 Source: minirok Binary: minirok Architecture: source all Version: 2.1-1 Distribution: unstable Urgency: low Maintainer: Adeodato Simó d...@net.com.org.es Changed-By: Adeodato Simó d...@net.com.org.es Description: minirok- a small music player written in Python and inspired by Amarok Closes: 507484 544230 548570 549538 Changes: minirok (2.1-1) unstable; urgency=low . * New upstream release: + allows to enqueue/dequeue tracks with a shortcut. (Closes: #507484) + does not segfault when using File-Open directory if no directory has ever been opened in the tree view. (Closes: #544230, #549538) + does not crash on startup due to an incompatible change in PyQt 4.6. (Closes: #548570) . * debian/control: + add python-psutil to Recommends. + bump required Python version to 2.5. + ensure json or simplejson are available. + drop lastfmsubmitd from Suggests (submissions are done by Minirok itself now). Checksums-Sha1: 4ebade7f14f32c02f113c11a3e69dbe465b3ac6c 1065 minirok_2.1-1.dsc 943acc5f64f49be8b47aec2e1543d171385e360b 71508 minirok_2.1.orig.tar.gz 7bde7654ab2a1e2f6a96159aafd3ac2d98cdce21 3959 minirok_2.1-1.diff.gz fc0ff35e67ac6ef43f5a569fe81ca8cc0ea3e0a3 74524 minirok_2.1-1_all.deb Checksums-Sha256: 59981eadd9f7357fdea25d42ace9d2d862cfd71506e1231aea89ab19936adecc 1065 minirok_2.1-1.dsc 3c4d5143e9b06b302ee4e6cd879ab2275eca5da375ee2fa8c290f93d1aa8eb0e 71508 minirok_2.1.orig.tar.gz 5869b9e5a873cfc0389267121982b0a57c65b2ed738d400d14a2be7b43697653 3959 minirok_2.1-1.diff.gz 982a56a88c6c92ade6bf5f9cec65eccca0b6ee0e21ae6dc1fbf6017a1f328ca3 74524 minirok_2.1-1_all.deb Files: f2748a0892b8669e99450b4fd7e3693c 1065 kde optional minirok_2.1-1.dsc 500da291eb011ff674c9968f822ab5db 71508 kde optional minirok_2.1.orig.tar.gz 64ce540d138d183b116321a694568513 3959 kde optional minirok_2.1-1.diff.gz 27049d65c16047489bd2e44587bdabb3 74524 kde optional minirok_2.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkrXvJQACgkQOzsxEBcMRN2MVwCg43bY4zONO/cHMTanJVL9Qkp+ wRAAoLqJa66/YvsPPo/zywr/xEFz/qrl =rxmI -END PGP SIGNATURE- Accepted: minirok_2.1-1.diff.gz to pool/main/m/minirok/minirok_2.1-1.diff.gz minirok_2.1-1.dsc to pool/main/m/minirok/minirok_2.1-1.dsc minirok_2.1-1_all.deb to pool/main/m/minirok/minirok_2.1-1_all.deb minirok_2.1.orig.tar.gz to pool/main/m/minirok/minirok_2.1.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 librmail-ruby 0.17-1.1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 12 Jul 2009 10:24:45 +0200 Source: librmail-ruby Binary: librmail-ruby-doc librmail-ruby1.8 Architecture: source all Version: 0.17-1.1 Distribution: unstable Urgency: low Maintainer: Shugo Maeda sh...@debian.org Changed-By: Adeodato Simó adeod...@debian.org Description: librmail-ruby-doc - lightweight mail library for Ruby (documentation) librmail-ruby1.8 - lightweight mail library for Ruby 1.8 Changes: librmail-ruby (0.17-1.1) unstable; urgency=low . * Non-maintainer upload. . * Apply patch from upstream BTS to avoid quoting existing parameters twice in Header::set_boundary(). Addresses part of #431557, which requested for all patches in upstream BTS to be applied to the package. . * Add a build-dependency on quilt and the 3-line magic in debian/rules to apply the above patch. Checksums-Sha1: 34b0fa8329a45a40fcc1c37ce9aabde34fecc62b 1104 librmail-ruby_0.17-1.1.dsc 4b1cf5ae274978d62b50f118d43befb9c86c0c07 2535 librmail-ruby_0.17-1.1.diff.gz e2280d661824e59faaa31373a1e4f2152ed17fce 102982 librmail-ruby-doc_0.17-1.1_all.deb 680b1fd47da712d0a4b07121cdf3fe806a0563d6 35408 librmail-ruby1.8_0.17-1.1_all.deb Checksums-Sha256: 7bcb54ac52ca469deceb00d577bf3361551f941575d35ea998ec856107fe0957 1104 librmail-ruby_0.17-1.1.dsc 8b6b23e7b2debcc07156f610abd58ffca732fab1c947fc42a07d5f645e7731a7 2535 librmail-ruby_0.17-1.1.diff.gz e8ea8663cf3fe14e7012217b21931becbc0b954a010c2f2585ccd30c25bb9e1a 102982 librmail-ruby-doc_0.17-1.1_all.deb 963dea713b75dbaf78fe39ad73bea9dd1299034b8807ad66b771e8f5bb1c7623 35408 librmail-ruby1.8_0.17-1.1_all.deb Files: f1933380d12d13c4e04773951cd86b2c 1104 interpreters optional librmail-ruby_0.17-1.1.dsc 5d5544557dead08db59298489b3db00f 2535 interpreters optional librmail-ruby_0.17-1.1.diff.gz cd5020fdc7e55400b4449aca5f9cfa5e 102982 interpreters optional librmail-ruby-doc_0.17-1.1_all.deb 5b7222a71dc3ff267259f558cbff0106 35408 interpreters optional librmail-ruby1.8_0.17-1.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkpZnsEACgkQOzsxEBcMRN0WNQCgu9yozB+xXO8j6ZoVWXBsvUr6 RSMAn0uNnXyHUs6Q9N5YvD4/SGFRfl6j =YdGb -END PGP SIGNATURE- Accepted: librmail-ruby-doc_0.17-1.1_all.deb to pool/main/libr/librmail-ruby/librmail-ruby-doc_0.17-1.1_all.deb librmail-ruby1.8_0.17-1.1_all.deb to pool/main/libr/librmail-ruby/librmail-ruby1.8_0.17-1.1_all.deb librmail-ruby_0.17-1.1.diff.gz to pool/main/libr/librmail-ruby/librmail-ruby_0.17-1.1.diff.gz librmail-ruby_0.17-1.1.dsc to pool/main/libr/librmail-ruby/librmail-ruby_0.17-1.1.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted minirok 2.0-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 01 Jun 2009 23:09:20 +0200 Source: minirok Binary: minirok Architecture: source all Version: 2.0-1 Distribution: unstable Urgency: low Maintainer: Adeodato Simó d...@net.com.org.es Changed-By: Adeodato Simó d...@net.com.org.es Description: minirok- a small music player written in Python and inspired by Amarok Changes: minirok (2.0-1) unstable; urgency=low . * New upstream release, ported to KDE 4 now (see the NEWS file for details). . * Add postinst/postrm snippets to touch /usr/share/icons/hicolor, so that the icon cache gets rebuilt after installation, and Minirok icons become available. . * Drop lintian override file, now that script-not-executable does not apply to files under /usr/share. . * Bump Standards-Version to 3.8.1 (no changes required). Checksums-Sha1: 3ac960b51ce1b85193789e05ead8369ebdfdb795 1064 minirok_2.0-1.dsc 2c4144f511f1affcb12b27e57c5eb263e78746db 64813 minirok_2.0.orig.tar.gz 9e91a82a05790320e4525cb6d3b6e4ce23e00f53 3704 minirok_2.0-1.diff.gz ea128c29c3a701753ba31758e5334ac352ba04d2 67564 minirok_2.0-1_all.deb Checksums-Sha256: 1678b90177e13ef439a2d6e19b1c4d01fbd097829fa1db2d1b07367ecb921960 1064 minirok_2.0-1.dsc a40705f83499de84f52dcf7fcd69b660559a461094a57e4604795a3b5aaab5e5 64813 minirok_2.0.orig.tar.gz c6314d9451e9f402f41f03ea6912bf2ee4364bf742e44209ca4089124e72d2db 3704 minirok_2.0-1.diff.gz f56d502aae2b604be3c343ce60b130e35f206f4f337064a0c343948ceaf9a2c0 67564 minirok_2.0-1_all.deb Files: 063570aa87f819a532ae9e2ee99b8f82 1064 kde optional minirok_2.0-1.dsc eaa8412e88d83d1ad475d4a2d2813a15 64813 kde optional minirok_2.0.orig.tar.gz 9095d4f3c89eba4dcade825f1e7138d4 3704 kde optional minirok_2.0-1.diff.gz 1c6bb22b422932edf9d85ad435bb11eb 67564 kde optional minirok_2.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkokRCMACgkQOzsxEBcMRN25pwCfYJ58Tg3tZ0JBKz+TH/+SVHB0 vUAAoPe4mFQFvISxk2mNShfFteFpFoaR =0Rxt -END PGP SIGNATURE- Accepted: minirok_2.0-1.diff.gz to pool/main/m/minirok/minirok_2.0-1.diff.gz minirok_2.0-1.dsc to pool/main/m/minirok/minirok_2.0-1.dsc minirok_2.0-1_all.deb to pool/main/m/minirok/minirok_2.0-1_all.deb minirok_2.0.orig.tar.gz to pool/main/m/minirok/minirok_2.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
Re: fstrcmp
+ Peter Miller (Sun, 31 May 2009 11:49:37 +1000): Wouldn't it be great if when you typed apt-get build-deps gcc instead of saying E: Invalid operation build-deps it said something more useful, like E: Invalid operation build-deps, did you mean build-dep instead? I guess that's would be doable, since it'd involve calculating distances to all registered commands, which are only a handful. However: This goes for packages as well. Wouldn't it be great if apt-get install dns-utils instead of saying E: Couldn't find package dns-utils it said something more useful, like E: Couldn't find package dns-utils, did you mean dnsutils instead? I can't see how it'd work here, at least without the help of some on-disk structure, since we're talking about a space of 25,000 packages. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#531221: okular: Arbitrarily enforces DRM
+ John Goerzen (Sat, 30 May 2009 19:09:11 -0500): I'm CCing this to Debian-devel because I think it speaks to a larger issue. I just downloaded a PDF, and tried to copy and paste a bit of text from it. I used the selection tool, and Okular offered to speak it to me, but said Copy forbidden by DRM. pdftotext was able to convert the entire file to text format in an instant. So what I want to know is: why are people putting code into Debian that limits our freedom? Why are people putting such code into KDE? And can we please patch it to stop that? I see it's been pointed out in a comment in your blog post already, but I'll mention it here for the benefit of those reading along: obeying DRM is a configurable runtime option in Okular, so it's just a matter of going to the preferences dialog and unchecking the Obey DRM check box. Now I have no idea why it would default to obeying it (or, for that matter, why it would have such an option). I'm CC'ing Pino whom I'm sure will be able to help. (My guess would be that it protects upstream against some shit or whatever, at least by their reckoning, or the person that added it in the first place.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Raising minimum CPU requirement for i386 kernel
+ Bastian Blank (Sun, 24 May 2009 21:07:49 +0200): I would like to raise the minimum CPU requirement for the shipped Linux kernels in the i386 port to i686 (with cmov). For now I will not propose a change of the default machine type setting used by the compiler. As Philipp Kern mentioned, you should start by explaining why you want to do that. Maybe it's just to drop one flavour in the i386 builds, or maybe there are maintenance headaches associated with this flavour we're unaware of. That said, and agreeing with what has been said by others in this thread already, they'll have to be ver good reasons in order for such a loss to be acceptable. So, please do not go forward with this unless consensus has been reached. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Heads-up: KDE4 hitting testing tonight (UTC)
+ Jonathan Kaye (Mon, 18 May 2009 15:15:27 +0200): Yes, but sadly 4.2 is not hitting squeeze all at once. I got about 6 4.2 upgrades today with the results that a lot of my kde apps are no longer functional. The menu items along with their associated icons are gone: kpat, amarok, k3b are 3 of many apps to be affected. I guess this will get sorted in a couple of days but WHY?!? would they release packages piecemeal this way? We migrated most of the packages that were available for KDE4 already, and those available but that didn't migrate (like eg. kphotoalbum) are to follow soon. But for example k3b and amarok have not migrated to KDE4 yet in unstable, so it's impossible to have them in testing. Amarok has a KDE4 version in experimental, and it being there probably means the maintainer thinks KDE4 users are still better off with the KDE3 version, since the KDE4 one is probably unstable. Regarding kpat, if you still have the KDE3 version after upgrading, then you did not fully upgrade, since it was included in the initial migration to testing AFAICR. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitions Completed
+ Frans Pop (Thu, 21 May 2009 20:54:22 +0200): Adeodato Simó wrote: From: Debian Installer instal...@ftp-master.debian.org Although this usage probably predates D-I, I do find it quite confusing in practice, and for example when googling, that we currently have two completely unrelated usages of the term Debian Installer. Would the FTP master team consider changing the the name for this mail address? Alternative could be Archive Installer. Even Debian Archive Installer would remove much of the confusion. Adding ftpteam to the loop. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted amule 2.2.5-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 23 May 2009 10:45:57 +0200 Source: amule Binary: amule amule-common amule-utils amule-utils-gui amule-daemon Architecture: source amd64 all Version: 2.2.5-1 Distribution: unstable Urgency: low Maintainer: Adeodato Simó d...@net.com.org.es Changed-By: Adeodato Simó d...@net.com.org.es Description: amule - client for the eD2k and Kad networks, like eMule amule-common - common files for the rest of aMule packages amule-daemon - non-graphic version of aMule, a client for the eD2k and Kad netwo amule-utils - utilities for aMule (command-line version) amule-utils-gui - graphic utilities for aMule Changes: amule (2.2.5-1) unstable; urgency=low . +++ The Fido, Your Leash Is Too Long release. . * New upstream release. (Thanks, DEHS.) Checksums-Sha1: 342988b3c5b11fb6d089e6176430d5f5ad219be4 1402 amule_2.2.5-1.dsc 051d63884c1c0d00027df4e0beb37ac653b6c5eb 6033273 amule_2.2.5.orig.tar.gz de470e4dc74be115ebf61f6e743635c07870376f 22183 amule_2.2.5-1.diff.gz 7c500c1910d3877415302cf912ccb52116e5fbac 1866484 amule_2.2.5-1_amd64.deb 729675a1a6da16a980966a2dec1ea2b91d00576e 461266 amule-utils_2.2.5-1_amd64.deb c66c529140130f4564c094b54eecd67cc934fdca 1296704 amule-utils-gui_2.2.5-1_amd64.deb 340f1b8867ad57daf1744a82a07ee410d296c3c6 1209500 amule-daemon_2.2.5-1_amd64.deb 404ca9e9a0fcb21e28f85168c17aa4cb610968ac 2421550 amule-common_2.2.5-1_all.deb Checksums-Sha256: 0d7168556d52ad4c7ae6a6f7dd3676185e701f2bbace562923d5cdff5f32850c 1402 amule_2.2.5-1.dsc 4ccde8f46f3c57679fa47fa1ac94901894a85d9d1c743a8f5ad707d0b6b74bbf 6033273 amule_2.2.5.orig.tar.gz af9b1e776ea0c92ed6b4665bd151395d41a35d16b1266e7f450914acd9ba6ab6 22183 amule_2.2.5-1.diff.gz 3bcbcf7744fcde04ad01373c030fd91589f577964e79259bbd7b22ee1baa5fdd 1866484 amule_2.2.5-1_amd64.deb b78ec433956d69d30513ea6fac331168203fe961ca610afdecad4fe855e135e8 461266 amule-utils_2.2.5-1_amd64.deb d8d50d0f4b456f8a88f44a43ded84a0f582d8e2dffae8e365913ad9ed89deb82 1296704 amule-utils-gui_2.2.5-1_amd64.deb 70211aacb9f22cb4bc4081d73d3eb4d04ee5f126443676826d0c5c0157fd89ed 1209500 amule-daemon_2.2.5-1_amd64.deb be37e3df3f830a45063c4e5776774a5fc61a78f49c343761bf005b20fdfac036 2421550 amule-common_2.2.5-1_all.deb Files: 642b2bf4ccc7d4a7e3e949caa0be6bfc 1402 net optional amule_2.2.5-1.dsc 70f7e71196ebad12bbf647fb0f908b4e 6033273 net optional amule_2.2.5.orig.tar.gz ae863f0c6882d4b95991f88b4d6ee405 22183 net optional amule_2.2.5-1.diff.gz 636733db3f6dceff0208ab86b2735fd5 1866484 net optional amule_2.2.5-1_amd64.deb 8987d929cbc66d0c33c47a497a59ad7f 461266 net optional amule-utils_2.2.5-1_amd64.deb 3c9f7406612b8a6353cdb065f1a74e13 1296704 net optional amule-utils-gui_2.2.5-1_amd64.deb b37f3960256430da4d03b31de9b935f2 1209500 net optional amule-daemon_2.2.5-1_amd64.deb 9ebf62b1380dfa752781d91cc6e94497 2421550 net optional amule-common_2.2.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkoXwfgACgkQOzsxEBcMRN35HgCgjbu4PiWBXp7EePCpCsZnW+kl IPgAoPPqByIMynTil266xWESNxwgBoBT =27hE -END PGP SIGNATURE- Accepted: amule-common_2.2.5-1_all.deb to pool/main/a/amule/amule-common_2.2.5-1_all.deb amule-daemon_2.2.5-1_amd64.deb to pool/main/a/amule/amule-daemon_2.2.5-1_amd64.deb amule-utils-gui_2.2.5-1_amd64.deb to pool/main/a/amule/amule-utils-gui_2.2.5-1_amd64.deb amule-utils_2.2.5-1_amd64.deb to pool/main/a/amule/amule-utils_2.2.5-1_amd64.deb amule_2.2.5-1.diff.gz to pool/main/a/amule/amule_2.2.5-1.diff.gz amule_2.2.5-1.dsc to pool/main/a/amule/amule_2.2.5-1.dsc amule_2.2.5-1_amd64.deb to pool/main/a/amule/amule_2.2.5-1_amd64.deb amule_2.2.5.orig.tar.gz to pool/main/a/amule/amule_2.2.5.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
Bug#529871: Dependency mismatch for nautilus-filename-repairer and nautilus-image-converter
reopen 529871 clone 529871 -1 reassign -1 nautilus-image-converter severity -1 serious retitle -1 nautilus-image-converter: upload of experimental packages to unstable required reassign 529871 nautilus-filename-repairer severity 529871 serious retitle 529871 nautilus-filename-repairer upload of experimental packages to unstable required thanks + Michal Pomorski (Fri, 22 May 2009 00:55:07 +0200): Package: general Severity: important Cant install the these two nautilus plugins. All other plugins installed corerctly. I tried several mirrors. $ sudo aptitude install nautilus-filename-repairer nautilus-image-converter Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages are BROKEN: libnautilus-extension1 The following NEW packages will be installed: nautilus-filename-repairer nautilus-image-converter 0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 36.7kB of archives. After unpacking 258kB will be used. The following packages have unmet dependencies: libnautilus-extension1: Breaks: nautilus-filename-repairer ( 0.0.5-2) but 0.0.5-1 is to be installed. Breaks: nautilus-image-converter ( 0.3) but 0.2.1-2 is to be installed. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Who uses @packages.d.o mail?
I haven't done an exhaustive survey, but it seems pretty clear so far that the domain does not get any significant amount of legitimate mail from machines other than the debian.org hosts. As I understand it, pkg@packages.d.o is the standard way of contacting the maintainers of a package in an easy and efficient way. I use it all the time when eg. reassigning a bug (reassign mails are supposed to be CC'ed to the destination maintainers), rather than go up and look who's listed as maintainer and uploader and CC them all. Plus, fortunately, packages.d.o has been sending a copy to the PTS for some time now, so even interested people who are not listed as maintainer/uploader will be able to read them. Personally, I think we should keep it open. If it becomes unsustainable, we could require a whitelist header for mail sent from non debian.org machines, like the PTS does. But if we do that, we could ditch it altogether and just use the PTS (for me, one of the main advantages of packages.d.o is not having to include the whitelist header). Does somebody know if the PTS is mailing the maintainers already? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Fwd: Transitions Completed
Hello, dak is configured to send the Release Team a mail each time one of the transition blocks expires because the transition has been completed. I thought it could perhaps be a good idea to CC them to -devel. Does somebody think we shouldn't do that? (I'd send a patch to include the name of the transition in the Subject.) Cheers, - Forwarded message from Debian Installer instal...@ftp-master.debian.org - From: Debian Installer instal...@ftp-master.debian.org Date: Thu, 21 May 2009 15:28:29 + Subject: Transitions Completed The following transitions are complete and have been removed from the transitions list: The following transitions were removed: Looking at transition: gnome Source: gnome-desktop New Version: 2.26.1-1 Responsible: Adeodato Simo Description: GNOME transition almost ready Blocked Packages (total: 79): avant-window-navigator, awn-extras-applets, banshee, beagle, blam, brasero, control-center, deskbar-applet, desktop-data-model, dfo, eiciel, eog, epiphany-browser, epiphany-extensions, epiphany-extensions-more, evolution, evolution-data-server, evolution-exchange, f-spot, file-roller, galeon, gbrainy, gedit-plugins, gfax, giver, gksu, gnome-applets, gnome-desktop, gnome-desktop-sharp2, gnome-do, gnome-do-plugins, gnome-launch-box, gnome-mag, gnome-main-menu, gnome-mount, gnome-panel, gnome-python-desktop, gnome-rdp, gnome-screensaver, gnome-settings-daemon, gnome-sharp2, gnome-subtitles, gnome-system-tools, gnome-utils, gshare, gtkhtml3.14, gtranslator, gtwitter, gucharmap, hipo, last-exit, lat, libepc, libgnomekbd, meta-gnome2, monodevelop, monodevelop-boo, monodevelop-database, monodevelop-debugger-gdb, monodevelop-java, monodevelop-vala, muine, nautilus, nautilus-actions, nautilus-cd-burner, nautilus-open-terminal, nautilus-python, nautilus-sendto, quick-lounge-applet, rhythmbox, seahorse-plugins, shared-mime-info, smuxi, stardict, tasque, tomboy, totem, totem-pl-parser, tracker - End forwarded message - -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fwd: Transitions Completed
+ Jonathan Wiltshire (Thu, 21 May 2009 19:00:09 +0100): On Thu, May 21, 2009 at 07:54:52PM +0200, Adeodato Simó wrote: I thought it could perhaps be a good idea to CC them to -devel. Does somebody think we shouldn't do that? (I'd send a patch to include the name of the transition in the Subject.) Would -devel-changes be more appropriate? though I don't know how many maintainers are subscribed to it. No, I don't think so. The changes in packages in testing are already announced daily on debian-testing-changes or so, but this is more affecting development, so that there's an explicit notification the moment the block is lifted. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#529049: ITP: octave-bugfix-3.0.5 -- bug fixes for some functions of Octave 3.0.5
+ Rafael Laboissiere (Sun, 17 May 2009 15:31:51 +0200): Hello! * Package name: octave-bugfix-3.0.5 Version : 1.0 Upstream Author : The Octave Forge Community octave-...@lists.sf.net * URL : http://octave.sourceforge.net/bugfix-3.0.5 * License : GPL-3+ Programming Lang: Octave Description : bug fixes for some functions of Octave 3.0.5 This package overrides some functions included with the 3.0.5 release that contain minor bugs. (In this version, just a fixed version of intersect.m is included.) Out of curiosity, what's the use case for having this as a separate package? Would one ever want to run octave3.0 without these fixes? If not, why would you not ship them directly as patches in the octave3.0 source package? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Heads-up: KDE4 hitting testing tonight (UTC)
Hello, For those following testing, this is just a quick mail to let you know that KDE4 will become available in Squeeze with tonight's mirror pulse. (It's KDE 4.2.2, I'm told 4.2.3 will shortly be uploaded to unstable.) A note for compiz users: unfortunately it hasn't been possible to migrate to testing the new compiz, useable with KDE4, because it also depends on a newer GNOME. In order to upgrade to KDE4, you will have to temporarily uninstall compiz-kde, or grab compiz-kde and dependencies from unstable. Cheers, -- Adeodato Simó Debian Release Team -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: architecture wildcards, type-handling, etc.
+ Guillem Jover (Wed, 13 May 2009 20:55:00 +0200): The wildcards on the binary stanza Architecture fields have also been supported since the beginning. What wildcards? The linux-any and powerpc-any ones you mean? AFAIK, Phil was inquiring about good-old Build-Depends expressions like: Architecture: !hppa Is that supported in the binary stanzas? (I don't think it is, but just to clarify.) -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API
+ Ritesh Raj Sarraf (Wed, 06 May 2009 12:23:06 +0530): Hello!, and thanks for your interest in packaging new software for Debian. * Package name: inotifyx Version : 0.1.0 Upstream Author : Forest Bond for...@alittletooquiet.net * URL : http://www.alittletooquiet.net/software/inotifyx/ * License : MIT/X Programming Lang: C, Python Description : Simple Python binding to the Linux inotify file system event monitoring API inotifyx is a Python extension providing access to the Linux inotify file system event notification API. It is primarily written in C but has some Python window dressing. Could you please include in the description a few lines on why would one want to use inotifyx instead of the already available pyinotify bindings? By reading the upstream homepage, it already mentions: | Reasons you might choose inotifyx over pyinotify: | | * inotifyx is a C extension and does not use ctypes, making it faster | and less prone to subtle breakage due to changes in the inotify API. | | * inotifyx is a much thinner wrapper around inotify. pyinotify is more | complicated. It does provide features that inotifyx does not, but many | of them are not needed by most applications. | | * The API provided by pyinotify seems to change in incompatible ways on | a fairly regular basis and with little justification. inotifyx has a | simple API that will change rarely, if ever. Maybe that's a bit too long for the description, but it should be easy enough to summarize those arguments for the long description. By the way, do you have preview packages available already? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: blocked libtool
+ Thorsten Alteholz (Wed, 06 May 2009 13:22:53 +0200): Hi Adeodato, Hello, Thorsten (hope it's okay I'm quoting you in public). could you please tell me the reason for blocking libtool's transition from unstable to testing? I have a few packages that depend on libtool but don't want to disturb debian-release if there is still a reason for blocking it. Thorsten asks about this output in the migration pages: | Trying to update libtool from 1.5.26-4 to 2.2.6a-4 (candidate is 28 days old) | Not touching package, as requested by adeodato (contact debian-release if update is needed) I thought maybe more people are wondering about this, and I added an explanatory paragraph on my hint file [1], which I reproduce now: # == Performance blocks == # Block here some transitions so that britney runs faster. Even if any # of these packages is a candidate for migration itself (older than 10 # days, etc.), it doesn't mean it will be able to migrate, since all of # its reverse dependencies have to be ready as well. But britney chokes # rather badly on some of these packages, taking a lot of time to # process them and their reverse dependencies; because of this, and to # keep ftp-master free of spurious CPU churn (it's a host that sees # quite a lot of interactive use), we prevent britney from trying to # migrate some packages for as long as it wouldn't succeed anyway. (This # is determined by a human, but in general a package being blocked out # of this paragraph implies there's nothing else preventing migration # than waiting for the reverse dependencies to be ready.) block libtool block gnome-sharp2 block totem-pl-parser FWIW, this is only done for transitions that are big enough as to cause a noticeable slow down (libtool eg. involves around 600 Bin-NMUs), or transitions that britney really chokes on when calculating uninstallabilities (eg. totem-pl-parser, no idea why). Cheers, [1]: http://release.debian.org/britney/hints/adeodato -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Folder-less email management with ‘sup-mail ’ (was: ignoring the CoC in regards to cc:s)
+ Ben Finney (Wed, 29 Apr 2009 10:04:05 +1000): Caveat: I tried it and dropped it because its support for Unicode is currently broken (Bug#520374), and Ruby isn't a language I'm able to hack. #477366, really. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Webkit build issues
+ Stefano Zacchiroli (Tue, 28 Apr 2009 22:16:26 +0200):
On Tue, Apr 28, 2009 at 09:45:41PM +0200, Adeodato Simó wrote:
Anyway, the exact list of Bin-NMUs is rather uninteresting. More
interesting can be, I think, the current list of known transitions
against which the Release Team works, which you were pointed at on
IRC later:
https://buildd.debian.org/transitions/summary.html
Is that page linked from anywhere? I've looked into the most obvious
(to me) places (e.g., {buildd,release}.d.o), but I failed to find it.
I'm afraid I'm not very keen on touching the HTML on either of those
sites until we have something sane on them (say, an ikiwiki instance).
As a bonus, Google found this for me:
http://wiki.debian.org/OngoingTransitions which looks a bit
outdated.
I deleted all content on that page, and added a page to the new URL. At
least now it's linked from *somewhere* (apart from the /topic in #d-r). ;-)
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
+ Andrei Popescu (Wed, 29 Apr 2009 16:56:29 +0300): On Wed,29.Apr.09, 14:27:45, Darren Salt wrote: The list management software, OTOH, can [add] a Mail-Followup-To header, if one is not already present, containing the list address and, if the sender is not subscribed, his address. This could be very annoying for people reading the list via gmane, googlegroups or just the archives. They can add a Mail-Followup-To themselves indicating they don't wish for a copy, and that will be respected. Regarding Darren's proposal (see above), I had exactly the same idea myself, and thought of formally proposing it to listmaster. However, I don't feel inclined to defend it in front of those who will disagree, so I'll limit my pursuit to Bcc'ing this message to listmaster. One would have to investigate what's the actual behavior of different MUAs with respect the M-F-T header. And please, do not reply to this mail to say M-F-T makes baby Jesus cry or rapes babies or whatever. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
+ Mike Hommey (Tue, 28 Apr 2009 07:46:35 +0200): On Tue, Apr 28, 2009 at 11:53:12AM +1000, Ben Finney wrote: Noah Slater nsla...@tumbolia.org writes: Yes, I know the L command, but thanks for pointing it out! My argument is that I have to remember to use when I am replying to the Debian lists, which as you can see, doesn't happen very often. No, the point of a ‘reply to list’ command is you *don't* have to remember when to use it. Just use it every time you reply to any list, and it will DTRT because it uses the standard fields which are in just about every mailing list anywhere. The times when it doesn't will be the rare ones. There are notorious counter examples, such as the git mailing list, that *do* require people to Cc the people they reply to, while the mailing list software doesn't add Reply-To. Oh, and actually they get very annoyed if you send your mail with a Mail-Followup-To header that prevents their group-reply function from adding you to the recipient list. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About symbol versioning, soname bumps and symbols files.
+ Steve Langasek (Mon, 27 Apr 2009 22:13:57 -0700): On Sun, Apr 26, 2009 at 06:43:00PM +0200, Adeodato Simó wrote: I’m unsure why assigning VERS_1 to all symbols works for preserving compatibility, whereas old binaries use symbols not associated with any version node (i.e., @Base). Maybe the first defined version node gets to “answer” to all requests that come without a version node attached. :-) It’d be nice if somebody could explain. But, if that’s true, I don’t know why there have to exist both a @Base and @VERS_1 versions of sctp_connectx. I’ll also note that the @VERS_1 has a different prototype than the aliased function! Because the earlier library used unversioned symbols, any programs depending on this lib will have references to an unversioned sctp_connectx symbol, which will be resolved to an arbitrary symbol whose name matches. The explicit Base symbol, as provided by: __asm__(.symver __sctp_connectx, sctp_connectx@); ... is needed so that objects linked against the pre-versioned lib resolve deterministically. Yes, I understand that, and was what I thought initially. But then, I didn't understand why all other symbols were migrated to have one only version... in VERS_1. But my question quoted above what will make apps refering to unversioned symbols pick up the symbols from VERS_1 automatically still stands, though. :-) Oh, or maybe you answered already: an unversioned reference resolves to an arbitrary version, unless there's a version binded to @Base? Does this mean that, if another symbol was to be updated (into VERS_2, eg., or VERS_3), the same `.symver foo, f...@` would have to be used? What's the point of having every symbol on VERS_1, then, and why weren't they kept on @Base directly, adding only sctp_connectx to VERS_1? However, if the prototype for __sctp_connectx() doesn't match the prototype for sctp_connectx_orig(), then... I'm pretty sure that's a bug in the lib. Okay, we can send mail to the patch author later. 3.) Should I just update the symbols file as shown above and not worry? Well, at least this entry: sctp_conne...@base 1.0.10+dfsg is wrong, because that symbol was already present before, so (barring ABI bugs as mentioned above) the minimum version req for it shouldn't be bumped. But if every other symbol suddenly has a VERS_1 symbol version, then anything linking against those will be unhappy when run against the pre-versioned lib anyway (throwing warnings but not errors), so that's a minor point. Right. When reading the symbols file propsed by Michael, I thought something in the lines of ok, every symbol bumped because the new library is backwards but not forwards compatible, so it's kind of a shlibs bump. The sctp_conne...@base version just got lost in the noise of having every other symbol bumped, and it's (while incorrect) very minor indeed. (On other news, libsctp1 has exactly one reverse dependency, which comes from the same source package.) Thanks, Steve! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
+ Mike Hommey (Tue, 28 Apr 2009 20:52:36 +0200): Since I wouldn't dream of recommending anyone use a proprietary data silo like Google Mail, I invite you instead to look at the ‘sup’ package for a folder-less approach to organising email messages that many say is superior. Description: Software Upgrade Protocol implementation ? sup-mail is the chosen package name in Debian, given that sup was already taken. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
+ Frank Lin PIAT (Tue, 28 Apr 2009 22:54:07 +0200): If the sender of the previous email is subscribed to the list: [...] If the sender of the previous mail was NOT subscribed to the list. [...] And how does one (or their MUA) know which of these is the case? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff? (was: Re: phyml_20081203-1_powerpc.changes REJECTED)
+ Noah Slater (Mon, 27 Apr 2009 14:10:17 +0100): Yes, I know the L command, but thanks for pointing it out! My argument is that I have to remember to use when I am replying to the Debian lists I fully agree with this. I think having to remember which key one must use in each context for reply is lame. This is why I do in my ~/.muttrc: folder-hook . bind index r reply folder-hook . bind pager r reply folder-hook . bind index L list-reply folder-hook . bind pager L list-reply folder-hook =l/debian bind index r list-reply folder-hook =l/debian bind pager r list-reply folder-hook =l/debian bind index L reply folder-hook =l/debian bind pager L reply Where l/debian is the folder which contains Debian lists, and it allows to always use 'r' to reply to mail. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About symbol versioning, soname bumps and symbols files.
+ Michael Biebl (Tue, 21 Apr 2009 17:40:23 +0200):
[not sure if debian-mentors is the right list, but I try anyway]
[I’m moving to -devel in search of a wider audience, and dropping
-mentors via Bcc to avoid the crosspost. Hopefully interested -mentor
readers can move to -devel without much inconvenience.
I’ll also note I’m not that well versed on these matters, but since
there’s been no answer to date, I’ll provide with my understanding of
the matter, and hopefully can jump in if it’s horribly wrong.]
Hi,
I maintain the lksctp-tools package, which builds the libsctp1 binary
package. The package so fare has been fairly straight forward and for
version 1.0.9 I used a symbols file for libsctp1 which looks like
this:
libsctp.so.1 libsctp1 #MINVER#
sctp_bi...@base 1.0.6.dfsg
sctp_conne...@base 1.0.6.dfsg
sctp_freelad...@base 1.0.6.dfsg
sctp_freepad...@base 1.0.6.dfsg
sctp_getaddr...@base 1.0.7.dfsg
sctp_getlad...@base 1.0.6.dfsg
sctp_getpad...@base 1.0.6.dfsg
sctp_opt_i...@base 1.0.6.dfsg
sctp_peel...@base 1.0.6.dfsg
sctp_recv...@base 1.0.6.dfsg
sctp_s...@base 1.0.6.dfsg
sctp_send...@base 1.0.6.dfsg
Now, I started packaging the new upstream version 1.0.10. There were
some API incompatible changes to sctp_connectx in 1.0.10 (an
additional function argument was added).
(Just so that it’s noted: it’s an API *and* ABI incompatible change.)
Instead of simply bumping the soname, upstream did the following:
1.) he added a version script
VERS_1 {
global:
sctp_getpaddrs;
sctp_freepaddrs;
sctp_getladdrs;
sctp_freeladdrs;
sctp_getaddrlen;
sctp_bindx;
sctp_connectx;
sctp_opt_info;
sctp_peeloff;
sctp_recvmsg;
sctp_sendmsg;
sctp_send;
local:
*;
};
VERS_2 {
global: sctp_connectx;
} VERS_1;
2.) In the source code, he added
__asm__(.symver __sctp_connectx, sctp_connectx@);
__asm__(.symver sctp_connectx_orig, sctp_conne...@vers_1);
__asm__(.symver sctp_connectx_new, sctp_connectx@@VERS_2);
...
int __sctp_connectx(int fd, struct sockaddr *addrs, int addrcnt)
...
extern int sctp_connectx_orig (int)
__attribute ((alias (__sctp_connectx)));
...
int sctp_connectx_new(int fd, struct sockaddr *addrs, int addrcnt,
sctp_assoc_t *id)
This was done, to avoid bumping the soname while still allowing older
applications linking against the old interface afaiui. [1]
The generated, new symbols file looks something like:
libsctp.so.1 libsctp1 #MINVER#
ver...@vers_1 1.0.10+dfsg
ver...@vers_2 1.0.10+dfsg
sctp_bi...@vers_1 1.0.10+dfsg
sctp_conne...@base 1.0.10+dfsg
sctp_conne...@vers_1 1.0.10+dfsg
sctp_conne...@vers_2 1.0.10+dfsg
sctp_freelad...@vers_1 1.0.10+dfsg
sctp_freepad...@vers_1 1.0.10+dfsg
sctp_getaddr...@vers_1 1.0.10+dfsg
sctp_getlad...@vers_1 1.0.10+dfsg
sctp_getpad...@vers_1 1.0.10+dfsg
sctp_opt_i...@vers_1 1.0.10+dfsg
sctp_peel...@vers_1 1.0.10+dfsg
sctp_recv...@vers_1 1.0.10+dfsg
sctp_s...@vers_1 1.0.10+dfsg
sctp_send...@vers_1 1.0.10+dfsg
Note, the three different versions of sctp_connectx (Base, VERS_1, VERS_2).
Now, I've never seen this technique used like this before.
So I'd very much appreciate any advice.
My questions are:
1.) Is it fine to use symbol versioning like this to avoid bumping the
soname or is this crack? Does this approach have downsides?
Yes, if done correctly, it’s fine to use symbol version for this purpose
(and it’s actually cool that clued upstreams do :-). I guess one of the
downsides is having to maintain both/all versions of the function, but
that’s a matter for upstream.
2.) Why are *there* different versions of sctp_connectx (Base and
three
VERS_1 being and alias). I would have understood if there are two,
VERS_1 and VERS_2.
I’m unsure why assigning VERS_1 to all symbols works for preserving
compatibility, whereas old binaries use symbols not associated with any
version node (i.e., @Base). Maybe the first defined version node gets to
“answer” to all requests that come without a version node attached. :-)
It’d be nice if somebody could explain.
But, if that’s true, I don’t know why there have to exist both a @Base
and @VERS_1 versions of sctp_connectx. I’ll also note that the @VERS_1
has a different prototype than the aliased function!
3.) Should I just update the symbols file as shown above and not worry?
I’d wait a bit to see if somebody follows-up on -devel, and would go
ahead if not. I did a small test and (unsurprisingly) it works fine.
[1] http://sourceware.org/binutils/docs/ld/VERSION.html#VERSION
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Re: Linux-libre for Debian Lenny
+ Paul Wise (Thu, 23 Apr 2009 18:13:11 +0800): linux-libre goes further and removes even the request_firmware calls for non-free firmware: To an hypothetical person that would deeply care about not running non-free software, does that provide any real gain/benefit/improvement over running a kernel full of request_firmware() calls, and never installing a firmware package from non-free in their systems? Honest question. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#524834: ITP: syncmaildir -- Sync Mail Dir is a set of tools to synchronize Maildirs
Hello!, Enrico. (I’m adding -devel back in case there can be people interested on this.) On Mon, Apr 20, 2009 at 05:35:20PM +0200, Adeodato Simó wrote: So does it support (or will it support) using it in the “fetch from server, read/delete some stuff on client, maybe read some stuff on the server, push to server” mode, and it’ll do all the smart sync stuff (I’m told) OfflineIMAP does? Sorry, but I don't get it. I'll try to answer anyway... You have 2 commands: smd-pull that propagates chenges made on the server to the client, and smd-push that does the opposite. These changes include adding a message, deleting one, renaming, updaing the header... I usually pull more frequently than push, so the updating cycle you are describing is not strictly necessary in smd. In any case, the words server and client don't make any real sense here, it is very symmetric. Right. My question is what happens if I do, say: laptop% smd-push laptop% smd-pull # this brings message M as new laptop% read mail, including message M server% read mail, inclluding message M; flag message M laptop% smd-push laptop% smd-pull Are either laptop or server left with a duplicate copies of M (perhaps one flagged, one not)? Or, perhaps, you’ll see it more clearly if we say there is one server and to clients, eg. a desktop and a laptop, both of which should be useable to read mail independently. I must confess I’m not an OfflineIMAP user myself, but as I understood it, it can gracefully cope with such situation. I think I'll (I'm also the upstream) develop some sort while-true script that will iterate pull and push and eventually notify the user if something goes wrong with some modern eye-candy technology. AFAIK OfflineIMAP gives you (or will give you soon) something more called always-connected-with-ther-server-to-fetch-mail-ASAP option that smd does not provide right now (and that I really don't miss: since pulling is quite fast for the moment I'm not missing the while true script either...). Moreover OfflineIMAP is well tested, and smd is not beeing a *very* young software. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#524998: ITP: libmqdb-perl -- MappedQueryDB toolkit for federated databases
+ Charles Plessy (Tue, 21 Apr 2009 20:49:27 +0900): Files: debian/* Copyright: 2009, Charles Plessy ple...@debian.org License: PD Please treat this packaging work as if it were in public domain. Is such a wording actually appropriate for this, “as if”? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#524834: ITP: syncmaildir -- Sync Mail Dir is a set of tools to synchronize Maildirs
+ Enrico Tassi (Mon, 20 Apr 2009 10:10:35 +0200): Hola! Description : Sync Mail Dir is a set of tools to synchronize Maildirs Sync Mail Dir is a set of utilities to synchronize a pair of mail boxes in Maildir format, using SSH to transfer data. Unlike OfflineIMAP It requires no IMAP server to be installed on the remote host. Sync Mail Dir design is similar to the one Maildirsync, but is more efficient in terms of CPU cycles and disk I/O. So does it support (or will it support) using it in the “fetch from server, read/delete some stuff on client, maybe read some stuff on the server, push to server” mode, and it’ll do all the smart sync stuff (I’m told) OfflineIMAP does? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: One-time cron output?
+ Raphael Hertzog (Sun, 15 Mar 2009 09:31:45 +0100): IMHO the right thing to would be for mlocate (in locate mode, not in updatedb mode) to issue a warning if the DB was too old instead of the way you suggested. Sending the warning only when updatedb is skipped and when the DB is already quite old seems like a good compromise. This is actually a very good suggestion, and I’ve ended up doing exactly that, but limiting the warnings at one per week at most: if [ $ON_BATTERY -eq 1 ]; then DAYS_OLD=$(( (`date +%s` - `stat --printf=%Y $DATABASE`)/(3600*24) )) if [ $DAYS_OLD -ge 7 ] [ `date +%u` -eq 1 ]; then # Only on Mondays cat 2 -EOF mlocate: system on battery power, not updating database. mlocate: warning: database more than $DAYS_OLD days old. EOF exit 1 fi exit 0 # Don't let cron complain without a warning of what was wrong fi How does that sound? Why only in locate mode? It does this already AFAIK but it doesn't tell the user why it's old. It is findutil’s locate that does it, and not mlocate. I could submit a wishlist against mlocate upstream that they’d copy this behavior. For now, the above will have to suffice. Thoughts? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
+ William Pitcock (Fri, 17 Apr 2009 04:49:58 -0500): On Fri, 2009-04-17 at 16:25 +0800, Thomas Goirand wrote: Luk Claes wrote: I'm afraid it's too invasive to be included, though I would propose to upload it to backports.org. Then can the current broken version of yum be removed of Stable? It makes absolutely no sense to keep a software that doesn't work in the distribution. I call bollocks here. I am using the version of yum in stable right now to yield perfectly working virtual machine filesystems. How is it broken when it is working as expected on production servers? Please do not drop d-release from CC. How do you expect for the package not to be removed if you prevent relevant information from reaching the appropriate team? Omnipresent Release Managers? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/copyright verbosity
+ Ben Finney (Wed, 15 Apr 2009 08:44:48 +1000): Sune Vuorela nos...@vuorela.dk writes: How is your work on a useful summary of kdebase-workspace going ? I do wish this tiresome rhetorical non-argument would stop cropping up. Are we not able to discuss the purpose of ‘debian/copyright’ without the false dichotomy of “have you solved all the problems yet”? In my opinion, it makes no sense to discuss the purpose of debian/copyright in the abstract, that is, without having prominently in mind what is that *we* can *sensibly* achieve. Anything else is mental masturbation, and hopefully we’re not here for that. I realize this may not fit your view of how things should be done, and I understand such position, but at some point you’re going to need to realize that sometimes a project can use one following suit better than one’s own rightfulness. I know this by experience. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Getting Gnome installable again
+ Norbert Preining (Mon, 13 Apr 2009 17:23:07 +0200): Hi colleagues, I got my fixed laptop and wanted to re-install everything to continue TeX development. Ah, great to hear you’re back to that status. :-) Well, unfortunately it seems that gnome is not installable, due to a missing library everything depends on via libcanberra, the libltdl3. Strange enough it is present in squeeze, but NOT in sid. Bummer. Any idea how to circumvent that but wait forever and a day till new canberra goes through NEW and in the meantime many other things break? Uhm, just install libltdl3 from squeeze, of course. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition from libmysqlclient15 to libmysqlclient16
+ Norbert Tretkowski (Tue, 07 Apr 2009 11:05:05 +0200): Hi, Hello, Norbert. I plan to move MySQL 5.1 from experimental to unstable really soon now, MySQL 5.0 will be dropped from Debian at the same time. This means 215 packages need to be rebuild. There should be no changes necessary on these packages, a simple rebuild should do it. libmysqlclient15 and libmysqlclient16 come from different packages, so I guess this means mysql-dfsg-5.1 can migrate to testing while still having mysql-dfsg-5.0 there, making the transition not as painful. There is, however, the concern of libmysqlclient15 and libmysqlclient16 getting both loaded into a process’ space, oh well. Anyway, if the above is correct, please let us know when you’ve uploaded to unstable. If something’s wrong, please get back to us on that. By the way, it’s 118 source packages that need a rebuild, which is always the interesting figure, rather than the number of binary packages involved. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted amule 2.2.4-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 Apr 2009 15:11:18 +0200 Source: amule Binary: amule amule-common amule-utils amule-utils-gui amule-daemon Architecture: source amd64 all Version: 2.2.4-1 Distribution: unstable Urgency: low Maintainer: Adeodato Simó d...@net.com.org.es Changed-By: Adeodato Simó d...@net.com.org.es Description: amule - client for the eD2k and Kad networks, like eMule amule-common - common files for the rest of aMule packages amule-daemon - non-graphic version of aMule, a client for the eD2k and Kad netwo amule-utils - utilities for aMule (command-line version) amule-utils-gui - graphic utilities for aMule Changes: amule (2.2.4-1) unstable; urgency=low . +++ The Book of Love release. . * New upstream release. . * Bump Standards-Version to 3.8.1 (no changes needed). . * Drop version constraint in debhelper build-dependency, since the required version is in stable now. Checksums-Sha1: 6da1fef8180d53903082042002b7cbdd80c103fd 1402 amule_2.2.4-1.dsc ad44a965ef767740cce9566bf5cd4f4a8ac040bc 6032628 amule_2.2.4.orig.tar.gz 994426c2b900fe117de3c0f5c9fecfabf7b996e1 22136 amule_2.2.4-1.diff.gz a7ca396b924fb5ca7a64358e834546777df95746 1866238 amule_2.2.4-1_amd64.deb 9981bb4494e6c45eb560907b9c2cee8e275c0cda 461092 amule-utils_2.2.4-1_amd64.deb a57ae6a6cd1afa807b46c3eff9e162483980dbf4 1296680 amule-utils-gui_2.2.4-1_amd64.deb be3dcde028734bb0ab4079479f6c1278be0c447b 1209376 amule-daemon_2.2.4-1_amd64.deb bd317ceae02f4b0f53c55d9142c6f6ab6b11e163 2421752 amule-common_2.2.4-1_all.deb Checksums-Sha256: d9a7719fdf282f12b6c8804d501459ac14677786a50fea0c50ae89eb0cb8c008 1402 amule_2.2.4-1.dsc 469cb14a1170e189a4cd6d211ed912ccacbdd7aa2fd97447049dde97a0f5ecb3 6032628 amule_2.2.4.orig.tar.gz 1b0183a58452a710444dae6f39f6768286d31082acd8c5211c3ee857922b524b 22136 amule_2.2.4-1.diff.gz 8a501f3d9eb98c39a70fc65376b4637c0239ecdc97236f12dead83b3301bb600 1866238 amule_2.2.4-1_amd64.deb 27767a808cc9765063dbc0b8288fba2441e258cd3ff83231e75232809a32e50f 461092 amule-utils_2.2.4-1_amd64.deb d7a2b1aede74c307fdf1235b90ce180e286b5ce07c43d63631c11caf0c55cecd 1296680 amule-utils-gui_2.2.4-1_amd64.deb b35667a3a25d9dad583c5d70f82664ae7493d075eab16cbde6d474729b1ef19d 1209376 amule-daemon_2.2.4-1_amd64.deb 952579d45993bf15661672dd3e0639e69b5b874d04edef5e1ce094bee61086ae 2421752 amule-common_2.2.4-1_all.deb Files: a3948a303c53d3b29b45415b874c46dc 1402 net optional amule_2.2.4-1.dsc 04e4eceda3622d6d09ba79b29c07c7bf 6032628 net optional amule_2.2.4.orig.tar.gz 9ef85dfe01b9c8add910340e8e67088d 22136 net optional amule_2.2.4-1.diff.gz 0b889feb6f0410a3317341592065b2a2 1866238 net optional amule_2.2.4-1_amd64.deb f44eb0ae177a8e7aae5df9b3ebe1cdfa 461092 net optional amule-utils_2.2.4-1_amd64.deb 83b5748bb70ae9b4c1c7e721b58fbb43 1296680 net optional amule-utils-gui_2.2.4-1_amd64.deb 4adc08307075136e7661c1bb61cce164 1209376 net optional amule-daemon_2.2.4-1_amd64.deb 645a869cf64d3db1de1401ba61dc080e 2421752 net optional amule-common_2.2.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkneEBAACgkQOzsxEBcMRN3IFwCfa/iFhxyUtf4ZXImbVo/FTAvk 4MMAoOYm4gJFwNi3kt2Ko37B7qlCOwsm =OHja -END PGP SIGNATURE- Accepted: amule-common_2.2.4-1_all.deb to pool/main/a/amule/amule-common_2.2.4-1_all.deb amule-daemon_2.2.4-1_amd64.deb to pool/main/a/amule/amule-daemon_2.2.4-1_amd64.deb amule-utils-gui_2.2.4-1_amd64.deb to pool/main/a/amule/amule-utils-gui_2.2.4-1_amd64.deb amule-utils_2.2.4-1_amd64.deb to pool/main/a/amule/amule-utils_2.2.4-1_amd64.deb amule_2.2.4-1.diff.gz to pool/main/a/amule/amule_2.2.4-1.diff.gz amule_2.2.4-1.dsc to pool/main/a/amule/amule_2.2.4-1.dsc amule_2.2.4-1_amd64.deb to pool/main/a/amule/amule_2.2.4-1_amd64.deb amule_2.2.4.orig.tar.gz to pool/main/a/amule/amule_2.2.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
Re: Location of Packages and Translation files seem to have changed since yesterday
+ Andreas Tille (Wed, 08 Apr 2009 09:59:32 +0200): Hi, while building Blends tasks pages I used to parse the packages file http://ftp.debian.org/dists/unstable/main/binary-i386/Packages.gz this does not exist any more and I have to add a directory 'debian' http://ftp.debian.org/debian/dists/unstable/main/binary-i386/Packages.gz In every mirror, Debian stuff lives under /debian, and AFAIK that’s the way it’s always been. Mirrors normally carry many other stuff than Debian, and of course it wouldn’t make sense to get/ask for /dists and /pool in the top-level directory. For example, Ubuntu lives in /ubuntu, so if a mirror does both Debian and Ubuntu, /debian/dists and /ubuntu/dists can co-exist nicely. HTH, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby
+ Sebastien Delafond (Tue, 07 Apr 2009 13:08:17 -0700): On Apr/07, Mike Hommey wrote: Why do we need jruby1.0, jruby1.1 and now jruby1.2 ? so multiple versions of jruby can be simultaneously installed on a system, like with python2.x, ruby1.x, etc ? The question was, rather: why would a user want to install jruby1.0 or jruby1.1 instead of jruby1.2? What purpose does it serve having three different versions in the archive instead of one, or two at most? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Jack Audio Connection Kit transition
* Felipe Sateler [Tue, 31 Mar 2009 08:58:23 +1100]: * plan for libjack0.100.0-0: there are 11 source packages left with dependencies on this old library. No sourceful uploads are needed for this: once you’ve gotten back to me that the plan is good, I will provide you with a list of packages and schedule Bin-NMUs; then you can do some work of checking if they built successfully everywhere, filing bugs, etc. Once all of them have been rebuilt (which will make them depend on libjack0), please check with us that they’ve migrated to testing, and at that point libjack0.100.0-0 can be dropped. Sounds good? Amsynth will require a sourceful upload, since the dependency is not generated by dpkg-shlibdeps because it dlopens libjack. It is the only one I saw. I’ve scheduled Bin-NMUs for this, for all packages except amsynth. You can check for build-failures here: http://bit.ly/zLyiK, and for progress of their migration here: https://buildd.debian.org/transitions/summary.html. As mentioned above, please check with us before dropping the libjack0.100.0-0 package. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitions update: some done, some ready, some starting
We’ll be also doing some Bin-NMUs to get rid of dependencies on obsolete jack-audio-connection-kit transitional packages Should we file bugs against packages for build-depending on the wrong package, so that we can drop the Provides later? Or just let it be for the time being? You will need to file bugs at RC severity against jackbeat and gst-plugins-bad0.10 ASAP, as I already mentioned in the previous mail. For the rest, feel free to file bugs at minor severity; you’ll probably want to usertag them, and to include a mention that libjack-dev is in Lenny already. When there are no packages left in testing build-depending on the old name, you can drop the provides. Also, I think you can start the binNMUs now, since the shlibs file already point to the libjack0 package. Yes, I just need to find a bit of time to do it. I’ll get back to you once I’ve scheduled them, so that you can track failures, etc. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: demoting a dependency
* Paul Wise [Tue, 31 Mar 2009 22:42:32 +0800]: On Tue, Mar 31, 2009 at 9:21 PM, Marco d'Itri wrote: Is there a more elegant way to do this? Not sure if it would work with your case, but xchat used this to demote plugin dependencies to recommends: dh_shlibdeps -a -u'-dDepends debian/xchat/usr/bin/xchat -dRecommends' So the inverse should work too, as in: dh_shlibdeps -a -u'-dSuggests debian/inn2/usr/lib/news/bin/auth/passwd/auth_krb5 -dDepends' Which may be what Marco needs, so good suggestion. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitions update: some done, some ready, some starting
* Adeodato Simó [Tue, 31 Mar 2009 17:56:33 +0200]: * poppler, evolution-data-server/gnokii/metacity, libmtp/libgpod scheduled for this week, upload blocks in place (see attached) The complete list of packages is attached. Yeah, about that. Attached now. poppler === Michael Banck mba...@debian.org referencer Dave Beckett daj...@debian.org poppler (U) Michael Biebl bi...@debian.org tracker Ross Burton r...@debian.org poppler (U) Hubert Chathi uho...@debian.org popplerkit.framework (U) Arnaud Cornet acor...@debian.org ruby-gnome2 Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org evince Debian GNUstep maintainers pkg-gnustep-maintain...@lists.alioth.debian.org popplerkit.framework Debian Python Modules Team python-modules-t...@lists.alioth.debian.org python-poppler (U) Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org koffice Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org ruby-gnome2 (U) Debian TeX Maintainers debian-tex-ma...@lists.debian.org luatex texlive-bin Yavor Doganov ya...@gnu.org popplerkit.framework (U) Sebastian Dröge sl...@debian.org evince (U) Andrea Gasparini ga...@yattaweb.it python-poppler Philipp Kern pk...@debian.org pdf2svg Frank Küster fr...@debian.org luatex (U) texlive-bin (U) Ana Beatriz Guerrero Lopez a...@debian.org koffice (U) Loic Minier l...@dooz.org poppler Emilio Pozuelo Monfort po...@ubuntu.com evince (U) Josselin Mouette j...@debian.org evince (U) poppler (U) Yves-Alexis Perez cor...@debian.org epdfview Ari Pollak a...@debian.org gimp Norbert Preining prein...@debian.org luatex (U) texlive-bin (U) Wolfram Quester wo...@sigxcpu.org inkscape José L. Redrejo Rodríguez jredr...@debian.org gambas2 Michael Schutte m.schutte...@gmail.com ruby-gnome2 (U) Raúl Sánchez Siles rasas...@gmail.com koffice (U) Steve Stalcup vor...@ubuntu.com pdf2djvu Antonio Terceiro terce...@softwarelivre.org ruby-gnome2 (U) Paul van Tilburg pau...@debian.org ruby-gnome2 (U) Alexander Wirt formo...@debian.org pdfcube = evolution-data-server = Michael Banck mba...@debian.org libopensync-plugin-evolution2 libopensync-plugin-gnokii multisync Mirco Bauer mee...@debian.org evolution-sharp (U) monodevelop Laurent Bigonville bi...@debian.org empathy (U) Rob Bradford robs...@debian.org dates (U) Ross Burton r...@debian.org contact-lookup-applet dates tasks Marco Cabizza marc...@gmail.com control-center metacity Robert Collins robe...@robertcollins.net libopensync-plugin-evolution2 (U) libopensync-plugin-gnokii (U) Leo Costela cost...@debian.org gnokii LI Daobing lidaob...@gmail.com lunar-applet Debian CLI Libraries Team pkg-cli-libs-t...@lists.alioth.debian.org evolution-sharp Debian Evolution Maintainers pkg-evolution-maintain...@lists.alioth.debian.org evolution evolution-data-server evolution-exchange evolution-jescs evolution-webcal Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org cheese contact-lookup-applet (U) control-center (U) deskbar-applet ekiga (U) gnome-panel (U) gnome-python-desktop (U) metacity (U) totem-pl-parser Debian Hebrew Packaging Team debian-hebrew-pack...@lists.alioth.debian.org hdate-applet Debian Maemo Maintainers pkg-maemo-maintain...@lists.alioth.debian.org modest Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org librevolution-ruby (U) Debian Telepathy maintainers pkg-telepathy-maintain...@lists.alioth.debian.org empathy Debian X Strike Force debia...@lists.debian.org compiz Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr ekiga (U) Sebastian Dröge sl...@debian.org cheese (U) control-center (U) gnome-panel (U) gnome-python-desktop (U) metacity (U) totem-pl-parser (U) Baruch Even bar...@debian.org hdate-applet (U) Sean Finney sean...@debian.org compiz (U) Anthony Fok f...@debian.org lunar-applet (U) Pedro Fragoso em...@ubuntu.com evolution-data-server (U) Pedro Fragoso embe...@gmail.com evolution (U) Romain Francoise rfranco...@debian.org deskbar-applet (U) Pascal Giard pas...@debian.org mail-notification Oystein Gisnas oyst...@gisnas.net evolution (U) evolution-data-server (U) evolution-exchange (U) evolution-jescs (U) evolution-webcal (U) Dafydd Harries d...@debian.org eds-feed (U) empathy (U) Tollef Fog Heen tfh...@debian.org eweouz Heikki Henriksen heik...@gmail.com evolution (U) evolution-data-server (U) evolution-exchange (U) evolution-jescs (U) evolution-webcal (U) Lior Kaplan kap...@debian.org hdate-applet (U) Julian Andres Klode j...@jak-linux.org gnome-python-desktop (U) Kilian Krause kil...@debian.org ekiga Jonny Lamb jo...@debian.org empathy (U
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
* Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]: Hello, [-mentors only Bcc'ed to drop it from the discussion] Executive summary: concerns about ia32-apt-get raised, lesser hack proposed for comments. before Lenny ftpmaster asked us (ia32-libs maintainers) to do something about the mess that is ia32-libs. Specifically that it is a HUGE source duplication and a security nightmare. Unfortunaetly there wasn't enough time before the release to get a new solution (ia32-apt-get) into a stable state. Now that Lenny is out the problem can be attacked again. The major remaining problems are how to transition from ia32-libs to ia32-apt-get and how packages can depend on 32bit libs then. (Which actualy hinge on the same problem.) Has there been any public discussions about ia32-apt-get, and consensus that it is an acceptable solution? To be honest, I’m not sure at all it is actually a better solution than the 500 MB source package. For the benefit of others, so that they can comment, I’ll mention how it works. Mainly, ia32-apt-get dpkg-divert’s /usr/bin/apt-get and /usr/bin/dpkg-deb. For apt-get, it intercepts the “update” operation, calling apt-get.real first in an alternative root for the host arch (/var/lib/apt/native), then calling apt-get.real again for the foreign arch (/var/lib/apt/foreign), and then doing gross sed'ing over those to morph them into acceptable package lists for the host arch. Which are later available because the postinst goes ahead and duplicates all entries in sources.list. For dpkg-deb, it intercepts “--control” and “--fsys-tarfile”. The latter does all sorts of pretty things including moving files around (to /usr/lib32, eg.), changing the Architecture field, and amending the Depends field. I realize quite a lot of effort has been put into writing this and to make sure it works, but as said above, I’m unsure it’s an acceptable solution to this problem. As an amd64 user, I’d be disgusted to see such a hack forced down on my system, and disappointed in Debian for sanctioning such solution. The problem I see here is that ia32-libattr1, ia32-libx86-1, ia32-libpam0g, ... are not in main as far as DAK is concerned. They are not known at all in the Debian archive. As such I think [packages depending on ia32-lib*] could never transition from unstable to testing on [their] own. Actually they can, because britney can be told that some packages are available even if they are not in the Packages lists. However, and given my opinion above, I will refuse to do that unless there’s clear consensus among the active developers that this is an acceptable solution. Because of that, opinions welcome. I’d also be interested in hearing from ftpmaster their thoughts on the matter. Maybe a less fugly hack can be devised if the need to address the current ia32-libs mess is really strong. Mark Hymers has talked about providing a mechanism to ensure source packages stay on the pool when other stuff has been built from them (eg. kernel module packages). With this, ia32-libs could become a small source package containing scripts that would download the necessary binary packages at build time, and would encode in a header the employed versions; then, source for those versions would not be removed from the pool. And ia32-libs could be easily Bin-NMUed regularly, in order to pick up the latest libraries from testing. I know downloading stuff in the build process is not something we want to do, but we have packages with special needs that do it by design (eg. the installer). Thoughts? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Jack Audio Connection Kit transition
Maintainers: unless you’re jackbeat or gst-plugins-bad0.10, you need not
upload for this, though build-depending on libjack-dev in your next
upload would be nice.
---
Hello, Felipe. I finally found some time to look at your message. I’ve
moved -release to CC (thanks for the Bcc!), since it’s on-topic there.
Fellow developers and release team (bcc'ed),
The Debian Multimedia Maintainers would like to drop the versioned jack
library and development packages (that is, libjack0.100.0-{0,dev}). They were
introduced a long time ago (along with the appropriately renamed library) due
to perceived instability in the jack library's ABI. For a while now, this is
no longer necessary, and upstream has catalogued Debian packages of jack
broken because of that. The debian packages no longer change the soname of
the
library (starting with lenny), and the versioned packages are just dummy
ones.
We want to drop them now. The first thing to be done is to switch the
build-dependency from libjack0.100.0-dev to libjack-dev. After all packages
have been changed and uploaded, we can upload a jack without those
transitional packages (unless I overlooked something and we need the RT ack
first?).
Just to be clear: there is ABI/SONAME transition here. Packages that still
depend on libjack0.100.0-0 use the symlink provided by that package[1]. A
mere sed -i -e 's/libjack0.100.0/libjack/g' debian/control should be all
that people need to do.
I assume you mean “there is NOT ABI/SONAME transition here”, heh. So,
here are my comments on the matter:
* plan for libjack0.100.0-dev: you can make a j-a-c-k upload to
unstable dropping this development package immediately, provided
that you add a “Provides: libjack0.100.0-dev” line to the
libjack-dev package.
You will have to file two bugs at RC severity against jackbeat and
gst-plugins-bad0.10; these are the only packages that have a
*versioned* build-dependency on libjack0.100.0-dev, as far as I can
see.
I’ve also checked, and there is no pacakge with versioned
dependencies on libjack0.100.0-dev.
* plan for libjack0.100.0-0: there are 11 source packages left with
dependencies on this old library. No sourceful uploads are needed
for this: once you’ve gotten back to me that the plan is good, I
will provide you with a list of packages and schedule Bin-NMUs; then
you can do some work of checking if they built successfully
everywhere, filing bugs, etc. Once all of them have been rebuilt
(which will make them depend on libjack0), please check with us that
they’ve migrated to testing, and at that point libjack0.100.0-0 can
be dropped.
Sounds good?
[1] This actually surprised me. Could someone explain to me why are there
SONAMEs when they are not actually used?
% ldd /usr/bin/creox | grep jack
libjack-0.100.0.so.0 = /usr/lib/libjack-0.100.0.so.0
(0x7f943206f000)
% ls -l /usr/lib/libjack-0.100.0.so.0
lrwxrwxrwx 1 root root 12 2009-03-18 19:03 /usr/lib/libjack-0.100.0.so.0 -
libjack.so.0
% objdump -p /usr/lib/libjack-0.100.0.so.0 | grep SONAME
SONAME libjack.so.0
The SONAME that is recorded in the binary (do `objdump -p /usr/bin/creox |
grep NEEDED`, rather than ldd) is used to find the file. Once the file
is loaded, AFAIK nor the linker nor the application care what the
actuall SONAME of the loaded library is.
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
* Goswin von Brederlow [Mon, 30 Mar 2009 18:00:08 +0200]: The alternative solution is ia32-archive, which creates a local repository of converted packages on the users system. No wrappers needed and no ugly hacks but that comes at the cost of disk space and the need to configure what packages to convert (converting just everything would cost too much disk). Right, and I think that’s suboptimal from an useability POV: `apt-get install wine` should work on amd64 out of the box, without needing to do extra work, IMHO. Buildds don't have internet access in their build environment. ia32-libs may not download anything at build time. I guess when you replied to this you hadn’t gotten to the part where I said ia32-libs would be a “package with special needs”. Plus rebuilding would give widely unreproducible results. Would behave the same as other packages already do (linux modules, installer). Currently the size makes regular uploads too costly imho. And the security team is still not supporting ia32-libs. I even did prepare an security upload for etch last year that they only had to sponsor but never heard back from the team. With my proposed hack, the upload size would be just the binary packages, since the source would not be duplicated. Surely the Security Team can cope with that, if they so wish. (And/or if the package would have an arch:all package, eg. with scripts, you can get away with uploading only that one.) P.S.: In case it isn’t clear already, my only goal is that the hack we may have in place while we get multiarch, is an acceptable one. I would really like for it to be in place as little time as possible. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: grouping of alternative depends
* Holger Levsen [Sun, 29 Mar 2009 15:14:24 +0100]: Hi, Hey, On Sonntag, 29. März 2009, Emilio Pozuelo Monfort wrote: Doesn't this do what you want? Depends: pdns-backend-ldap | bind9, pdns-recursor | bind9 sure, that works and thats what I'm doing now. But it's ugly and redudant and potentially wrong: installing pdns-backend-ldap and bind9 satisfies that depends, but not my needs... Hm? Your original mail said you wanted: Depends: (pdns-backend-ldap + pdns-recursor) | bind9 How does installing bind9 plus pdns-backend-ldap not satisfy the above? Is it relevant whether pdns-backend-ldap is installed or not once bind9 has been installed? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Alioth - Convert SVN repo to Git
* Reinhard Tartler [Tue, 24 Mar 2009 18:03:42 +0100]: Then I've used git-svn to import the svn history in an extra repository, verified that everything is right, and pulled it from the repository created with git-import-dsc. As git-import-dsc uses the date from the changelog as commit date, this worked well enough for me. Probably needs some fine-tuning, but I hope that's something you can work on. Been there, done that, got frustrated. that approach will result in actually two trees: one with the exact history of uploads and one with the svn history. while you have the actuall contents now in your tree, the history information is not exatcly correct. E.g. now you cannot bisect the svn commits anymore (which was for me the point of the excercise). Right. I, too, wanted to go full-upstream-in-git when moving from only-debian-in-bzr, but at the same time wanted to keep the whole bzr history and not just a series of “Version 1.x-y imported” commits. I did it for the amule package. I *think* I tried to do it with grafts first and it wasn’t enough, but I could be wrong on that. I *certainly* ended up doing it with rebase --interactive, and it was so painful it’s not even funny. But I wanted it done really badly, and fortunately I do enough non-maintenance tasks nowadays as to ensure there was exacly *one* package where I wanted this procedure done. ;-) It should be possible to automate, I’m sure, but I don’t think anybody who could is going to care enough as to actually write the code. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Alioth - Convert SVN repo to Git
* sean finney [Tue, 24 Mar 2009 15:00:24 +0100]: On Tue, Mar 24, 2009 at 02:40:05PM +0100, Sandro Tosi wrote: Additionally, I'm looking for a post-commit hook that can send the commit diff via email to a ml + tagpending the bugs in the diff. I'm pretty sure someone out there has this script ready yet, so let's share :) i mentioned this on IRC, might as well share it here: i have something based on an earlier hook by adeodato, which does the former (commit msg+diff): http://git.debian.org/?p=users/seanius/vcs-hooks/git-post-receive-diff.git I have in my TODO list of doom looking at the patch you sent me so long ago. However, however, i've found that having the diff in the bug report is often just extra noise, I thought something related some time after you sent the patch. This (admittedly not without several flaws) hook of mine was intended for the use case of the typical “commit mailing lists”, through which other members of the (not necessarily packaging) team get to notice the work done by others, so really only the diff is needed. so i've been working on another one that sends a link to the patch in the VCS viewer url instead, along with doing a pending tag. i'll have to double check on the status of this guy before i send a link to it though. I think it’s better if it’s kept as a completely separate script, if you don’t mind much. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Proposed hook to tag bugs as pending
Hopefully this does what people wanted to do. Here: http://git.debian.org/?p=users/adeodato/git-hooks.git;a=blob;f=post-receive-tag-pending;hb=HEAD Sample output at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520017#17 -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposed hook to tag bugs as pending
* John Goerzen [Thu, 26 Mar 2009 13:37:51 -0500]: but it scans the git commit message and so can send a slightly more accurate report. I did it specifically parsing debian/changelog to address [1], because I actually often do the same (not writing Closes: #XXX in the commit message and only in debian/changelog). [1]: http://lists.debian.org/debian-devel/2009/03/msg01516.html If you put Closes: #xx in the commit message, the git-buildpackage tools can generate an appropriate changelog for you, Right, but my proposed script should cater for both workflows (letting the tools write your debian/changelog, or writing it by hand), since the bug closure will *always* be in debian/changelog. and you can automatically tag a bug pending when you git push. Possible as well with the other workflow now that I wrote my script. ;-) I can post the source if anyone's interested. Yes, I think that’d be definitely a good thing. I looked around searching for one this afternoon, and couldn’t find one. I was convinced Russ Allbery had written one, but doesn’t seem to be the case. Choice is always welcome. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposed hook to tag bugs as pending
* Clint Adams [Thu, 26 Mar 2009 19:22:31 +]: On Thu, Mar 26, 2009 at 08:12:29PM +0100, Adeodato Simó wrote: Right, but my proposed script should cater for both workflows (letting the tools write your debian/changelog, or writing it by hand), since the bug closure will *always* be in debian/changelog. That is not true; for those of us who are not mixing debian/changelog in with our commits, the bug closure will *not* be there until such time as the pending tag will be useless. “Oh.” I guess such workflow was already implied in John’s message, but I parsed his “git-buildpackage tools can generate an appropriate changelog for you” as to mean that they’d generate the corresponding debian/changelog entry *on each commit*, whereas he problably meant (or at least you are now, AIUI) generating the full debian/changelog before the upload, from all the existing commit messages since the last tag. This is a workflow I actually knew existed, but failed to recall today, hence my EPIC FAIL above. Now, if one wanted to write a hook that actually catered for both workflows, what would one do? Does anybody has suggestions? It is certainly doable to parse the commit message for Closes, and act only on those bugs if any, and if there are not any, look at the changelog. (I think it’s reasonable not looking at debian/changelog it the commit message mentions a bug number.) However, this will behave horribly when the run of git-dch or whatever tool is committed, since it will want to mark all the bugs as pending again; that’s the part where I need suggestions. I’d rather not have the hook need any configuration, and making it stateful is definitely out of questions. Maybe it should treat the bug numbers from debian/changelog as “untrusted”, and only send the message if they are not tagged pending already (by doing a SOAP request)? Thoughts? (And thanks for pointing out this.) -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: #520646: binNMU oprofile
Hello, Looks like oprofile needs a rebuild . $ opreport opreport: error while loading shared libraries: libbfd-2.18.0.20080103.so: cannot open shared object file: No such file or directory $ dpkg -L binutils | grep libbfd- /usr/lib/libbfd-2.19.1.so I’m told libbfd.so is a private/internal library of binutils that should not be dynamically linked against. A static version exists (libbfd.a), and packages should be using that AFAIK. Cc'ing -devel in case there’s a reason it should not be that way. If, on the contrary, nobody objects, I’ll file a wishlist against lintian so that an error (warning?) is emitted for packages that DT_NEED that library (and libopcodes/libiberty as well?) Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: #520646: binNMU oprofile
* Paul Wise [Wed, 25 Mar 2009 21:29:10 +0900]: On Wed, Mar 25, 2009 at 8:30 PM, Adeodato Simó wrote: I’m told libbfd.so is a private/internal library of binutils that should not be dynamically linked against. A static version exists (libbfd.a), and packages should be using that AFAIK. Cc'ing -devel in case there’s a reason it should not be that way. If, on the contrary, nobody objects, I’ll file a wishlist against lintian so that an error (warning?) is emitted for packages that DT_NEED that library (and libopcodes/libiberty as well?) Please ensure that the lintian warning says to get the package added to the Debian security team's embedded code copies documentation. A second idea came up in #debian-release; namely, making binutil’s shlibs file generate unsatisfiable dependencies, to signal that is not okay to dynamically link against those libraries. I’m putting the binutils maintainer on CC to see what he thinks about this idea. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm the GR process
* Kurt Roeckx [Tue, 24 Mar 2009 23:52:22 +0100]: On Tue, Mar 24, 2009 at 08:03:46PM +0100, Robert Millan wrote: I'd also like to complain about the title text of the initial GR. It is clearly manipulative, as it pretends to be merely describing the proposed changes when in fact it is asserting an opinion. I hope the Secretary will fix this. I think the title is also not the best one and just used Joerg's title. What about: General Resolution sponsorship requirements I’d suggest a minor variation: “Sponsorship requirements for General Resolutions”. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xine-lib transition: packages must depend on libxine1-x or libxine1-console, as needed
* Darren Salt [Mon, 23 Mar 2009 18:01:15 +]: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org pyxine We only build-dep on libxine-dev and depends are brought in by substvar, so a binNMU should be enough to update dependencies. No; you need to explicitly depend on libxine1-x or libxine1-console, or packages which depend on python-pyxine must depend on one of these. I think, if pyxine are just Python bindings for libxine, that it’s appropriate for it not to depend on either flavour, and indeed expect that packages using pyxine will add the appropriate flavoured dependency. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please make openbsd-inetd of priority Extra.
* Steve Langasek [Mon, 23 Mar 2009 02:19:58 -0700]: On Mon, Mar 23, 2009 at 10:14:24AM +0100, Pierre Habouzit wrote: Package: openbsd-inetd Version: 0.20080125-2 Tags: squeeze sid Severity: normal Following the thread on debian-devel, where people seemed to agree with such a move, could you please upload a new openbsd-inetd with its priority set to Extra instead of Standard ? This ought to be 'optional', not 'extra'; a number of the packages which depend on it are prio: optional, and this is still the preferred inetd implementation in Debian. For those reading along at home, #519718 was filed by Luk and fixed by ftpteam some days ago already (demoting openbsd-inetd and update-ined to optional). -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
* Adeodato Simó [Tue, 17 Mar 2009 18:25:10 +0100]: * Raphael Geissert [Mon, 16 Mar 2009 18:32:51 -0600]: Removing GNOME from testing because something depends on libfrufru1 isn't a win for testing's usability. It would only last until it is able to migrate without breaking anything. I think this is just a matter of deciding which way is less broken, i.e. broken because some packages are removed, or broken because you have multiple versions of the same libraries. IMHO the latter approach breaks testing more than the former, because it is a matter of availability vs duplicates (and if something goes wrong: installability). If you can’t see how keeping another library around is more useful for user than breaking half of their systems, I’d appreciate if you could think if over again. I’m very sorry, Raphael, I didn’t want to be harsh: please accept my apologies. Removing packages is certainly an option when they are not fixed, or unmaintained, or candidates for removal from unstable. But removing maintained and fixed and useful packages to make a transition does not particularly help our users: new users of testing won’t be able to install the package, and old users will end up (in the best case) with the two SONAMEs of the library installed [in the worst case, they won’t be able to upgrade]. So, in keeping the old library around is what apt co. is going to suggest to these users, I would say it’s appropriate to use it as a temporary solution to alleviate precisely that problem. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packaging a library when upstream does not build a .so
* Enrico Zini [Wed, 18 Mar 2009 11:42:58 +]: On Tue, Mar 17, 2009 at 03:03:22PM +, Simon Huggins wrote: Is there a reason you need this now and can't wait until you've managed to argue for the shared library from upstream and cajoule them into producing a .so? I had an upstream that wasn't very confident with soname changes and went through a long process explaining that and the benefits but ultimately it was worth it. Upstream will not be able to tackle shared libraries before an unpredictable amount of time, which could easily exceed one year or two. I am trying to help by sending him an up-to-date version of my libtool patch after every release, and making myself available for any other help that would be needed. However, he is not evil; he has other much more urgent things to work on. In the meantime, should I: - not package the library, which is however very useful, and needed by other software that I have written and want to package - package the library only as a -dev built with -fPIC (but no one has endorsed that option so far) - package a debian-only shared library, taking advantage of the fact that API and ABI are rather stable, and have been for a year. In that case, I need to figure out the best way to do it. I think you should go for #3, package a shared library with a Debian specific SONAME. My preference would be for libfoo.so.0d, libfoo.so.1d, ... (package names libfoo0d, libfoo1d, ...), but it’s probably not worth your time to investigate how to achieve that with libtool, so libfoo-0d.so.0, libfoo-1d.so.0, etc., also sound appropriate and easily achieved with the -release option for libtool as Roger Leigh hinted (keeping -version-info always at 0:0:0). Package names would be libfoo-0d-0, libfoo-1d-0, ... HTH, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
* Richard Atterer [Mon, 16 Mar 2009 13:34:17 +0100]: At the very least, there should be an auto-generated web page listing packages in testing that are currently unreleasable! http://lists.debian.org/debian-devel/2009/03/msg00836.html -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
* Raphael Geissert [Mon, 16 Mar 2009 18:32:51 -0600]: Removing GNOME from testing because something depends on libfrufru1 isn't a win for testing's usability. It would only last until it is able to migrate without breaking anything. I think this is just a matter of deciding which way is less broken, i.e. broken because some packages are removed, or broken because you have multiple versions of the same libraries. IMHO the latter approach breaks testing more than the former, because it is a matter of availability vs duplicates (and if something goes wrong: installability). If you can’t see how keeping another library around is more useful for user than breaking half of their systems, I’d appreciate if you could think if over again. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
* Steve Langasek [Sun, 15 Mar 2009 19:55:50 -0700]: Hello, Steve. On Sun, Mar 15, 2009 at 04:44:08PM +0100, Adeodato Simó wrote: Now, this has its own set of problems and caveats as well, since if you don’t pay attention and take care of later cleanup, you end up with packages in testing that do not belong to any source in testing, which is bad. Will there be reports produced on a regular basis of the stale libraries in testing, and their reverse-dependencies, so that people can easily pitch in to help with this later cleanup? There is a web page [1] that contains information about ongoing transitions, including those that are in need on cleanup (libdvdread at the moment). A list of packages is provided, and they are classified in two groups: “Pending migration” (that is, they’ve been successfully rebuilt in unstable), and “Not fixed in unstable”. The first group is the responsibility of the Release Team, and they’re most likely failing to migrate because of another transition (or, could be, because of RC bugs, but in that case removal at some point would be warranted). The second group (which is empty in the case of libdvdread) are the ones we can use help with. These will have RC bugs from day 0, and will be in the list of transition blockers (http://snipr.com/transition-blockers). Maybe once the transition is done, they should be moved to a separate list, I don’t know. Thoughts? Additionally, as I said in my original mail, the purpose of this is mainly to break ties between transitions once they are ready, and by definition a transition is not ready if still some packages are not rebuilt in unstable. Meaning, there will be really few packages allowed into this “second group”, if any, and removals from testing will be preferred in that case. Does this address your concerns? [1]: https://buildd.debian.org/transitions/summary.html (This page may move to release.debian.org eventually.) * Don Armstrong [Mon, 16 Mar 2009 00:48:22 -0700]: Hello, Don. On Sun, 15 Mar 2009, Steve Langasek wrote: On Sun, Mar 15, 2009 at 04:44:08PM +0100, Adeodato Simó wrote: Now, this has its own set of problems and caveats as well, since if you don’t pay attention and take care of later cleanup, you end up with packages in testing that do not belong to any source in testing, which is bad. Will there be reports produced on a regular basis of the stale libraries in testing, and their reverse-dependencies, so that people can easily pitch in to help with this later cleanup? Even better would be to turn this report into a set of bugs filed against the set of reverse dependencies which are made RC at the time that the transition migrates. As said above, failures to build against the new library are RC from day 0, and the intention is not to do transitions while those are open, other constraints permitting. As for packages that are rebuilt in unstable but not migrated, I don’t think RC bugs are approriate, since they’re not bugs in the package. We have the above mentioned list, which I think should be enough (since I don’t expect for those packages to remain without migrating for too long periods of time). [I'm personally slightly concerned about relaxing britney allowing testing to get into unreleasable states; a flag to re-enable the old behavoir late in release would probably be good.] In addition to what Steve explained about the inevitable necessity to bend the rules for entangled transitions, let me clear up that this is not any flag in britney that enables the behavior permanently or globally. This applies to a transition on a case-by-case basis, with a conscious decision and need for manual action. Also, it is my expectation that the need for this will mostly disappear once we get this first batch of transitions done. Sounds good? Thanks for your feedback, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Splitting of the gnome-python* source packages - MBF
Clement Lorteau northern_lig...@users.sourceforge.net gtkvncviewer I filed #518000 a while ago about this, heh. But the bug report needs updating to say that python-gconf exists on its own, and that gtkvncviewer should depend on that instead of python-gnome2. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: generating man pages from docbook
* Norbert Preining [Mon, 16 Mar 2009 18:24:15 +0100]: On Mo, 16 Mär 2009, Marco d'Itri wrote: On Mar 16, Hilmar Preusse hill...@web.de wrote: Hmm, weird. jadetex is architecture all and haven't changed for a while. Could you find out, why it can't be installed? I hoped that somebody here would tell me... Aehm sorry I lost this track completely. Can someone bring me on top what I should look into? jadetex is uninstallable on arches where texlive-bin is not available yet rebuilt against libpoppler4. Which is only s390, which is waiting for an upload. I’ve given back module-init-tools and set dep-waits as appropriate. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: One-time cron output?
As an extra idea, on IRC Peter Palfrader suggested never skipping the warning, but always sending it to syslog rather than stderr. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
A hack to alleviate transitions in Britney; now what?
Hello, this mail is to talk a bit about the current situation regarding transitions in unstable. In my opinion, it is unfortunate that the Release Team has had to insist on semi-serializing them, because that’s not the kind of development you want to have in unstable right after a release. Executive summary = We’ll manage to get Britney to be less of a PITA when dealing with transitions, which will hopefully enable us to do more of them concurrently if that’s what we want. This will be done by letting the old libraries stay in testing for a while after introducing the new one. Please still wait for an ACK from the Release Team before starting a transition. We’ll be handing them out more quickly now, but it’s very important that somebody checks whether reverse dependencies will rebuild fine or need patches, as to minimize the time core build infrastructure remains broken. Please find below the longer version. Part 1: explanations Let me start by explaining why it has been that way, the semi-serializing of transitions (you can skip the next two paragraphs if you already know how britney handles transitions). When a library package bumps its SONAME, it normally does so by creating a new package and dropping the old one from the same source package. When britney tries to migrate this change to testing, it wants to migrate at the same time both the creation of the new package, and the removal of the old one. But removal of the old one means rendering packages uninstallable (those depending on the old name), so this effectively means that all packages that depend on the old library in testing must get a new version of themselves migrated at the same time that the library itself migrates (they can’t migrate one at a time, because the new library would not be in testing yet). For obvious reasons it’s a bit complicated to get all packages in shape at the same time, but it’s certainly doable. The problem is when you have several transitions open, because they are bound to get tied via packages that depend on two or more of the disappeared libraries, which means that to update package P for transition T, you must do transition T2 at the same time, which brings in a whole lot of more packages to migrate at the same time. And that’s what increases the complexity of things, the ties between transitions. I’ve been thinking what to do about this, because I sincerely hate to be the guy that is blocking people from doing the work they’ve been waiting for so long already. You must believe me when I say I’m very unhappy about doing that. Should it have occurred to me earlier, I would probably have gone for making squeeze “hidden” from the public (i.e., no Packages.gz files), so that unstable could get very entangled and slowly converge. The thing is that a hidden testing allows you to break it, and a testing with permission to get broken converges much more quickly than a testing that must remain installable. But it’s now too late for that, and has a lot of disadvantages of its own, so I’ve revisited a way of doing transitions that has always been in the mind of the Release Team, but that britney does not support out of the box: allowing the old library package to stay in testing for a while. This means that not all packages have to migrate at once, because the ones that do not migrate won’t be uninstallable, since the old library stays. Now, this has its own set of problems and caveats as well, since if you don’t pay attention and take care of later cleanup, you end up with packages in testing that do not belong to any source in testing, which is bad. These partial migrations can also be problematic (AFAIK) if eg. a recompiled library against the new transition T migrates, and a binary depending on it and the old library of T doesn’t, whereas both the old T and the new T will get loaded into the process namespace. These concerns notwithstanding, I’ve decided to start using this method as a common procedure this early in the release cycle, but only as a means to break *ties* between transitions, and some hand-picked exceptions. I don’t want to systematically (ab)use it, because it’d be hard to clean afterwards. The consequence is that individual transitions will take approximately the same time to get ready themselves, but that once that happens it’ll be possible to migrate them without having to wait on some other transitions. I’ve already done that with libdvdread, which was tied to libraw1394 and ffmpeg via vlc and a couple others. This has been relieving, because having a transition ready in unstable but blocked for migration means that it will inevitably go back to “unready” after a while of waiting. As hinted above, britney does not support this procedure out of the box, and it has to be done with a gross hack and manual poking, but I’m willing to do that because I think it makes things significantly better. Additionally, britney2 does support it, and I’m hoping that
Re: Forcing version on dependency, how?
Hello, Jean-Yves. Please mail your questions about packaging to debian-ment...@lists.debian.org. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
One-time cron output?
Hello, I wanted to gather some opinions on this matter. I’ve recently applied to the mlocate package a patch I received to skip running the daily update of the database if the system is running on batteries. When that happens, the daily cron script emits a warning like “System on battery power, not running updatedb.” I think it’s going to be bad emitting that warning each time mlocate skips running updatedb, because it could be a lot of times. On the other hand, I don’t like the idea of being completely silent, because the database could go un-updated for a long time without the user ever knowing why. I’d like to make the script check for the existence of a file like /var/lib/mlocate/on_battery_warning_done.touch, and only emit the warning if it does not exist (and then touch it). (And possibly prefix the warning with the words “One-time warning:”.) Does this sound appropriate, or does it sound like an overkill? If it doesn’t sound appropriate, do you think always emitting the warning, or never emitting it, is more appropriate? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted brltty 3.10~r3724-1.1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 14 Mar 2009 11:09:53 +0100 Source: brltty Binary: brltty libbrlapi0.5 libbrlapi-dev libbrlapi-jni libbrlapi-java brltty-flite brltty-udeb brltty-x11 cl-brlapi python-brlapi Architecture: source amd64 all Version: 3.10~r3724-1.1 Distribution: unstable Urgency: medium Maintainer: Mario Lang ml...@debian.org Changed-By: Adeodato Simó d...@net.com.org.es Description: brltty - Access software for a blind person using a braille display brltty-flite - Access software for a blind person using a braille display brltty-udeb - Access software for a blind person using a braille display (udeb) brltty-x11 - Access software for a blind person using a braille display cl-brlapi - Common Lisp bindings for BrlAPI libbrlapi-dev - Library for communication with BRLTTY - static libs and headers libbrlapi-java - Java bindings for BrlAPI libbrlapi-jni - Java bindings for BrlAPI (native library) libbrlapi0.5 - braille display access via BRLTTY - shared library python-brlapi - Python bindings for BrlAPI Closes: 516240 Changes: brltty (3.10~r3724-1.1) unstable; urgency=medium . * Non-maintainer upload. * Apply patch from Samuel Thibault to fix FTBFS in unstable. (Closes: #516240) Checksums-Sha1: 14dd4d8acb46c3de4a326311e64fdd2516b82059 1572 brltty_3.10~r3724-1.1.dsc 1871c777b3bc386781dbd4234d5db7158b33036b 19523 brltty_3.10~r3724-1.1.diff.gz 125ea76252c93ce3723814b074de75596888e4ae 203704 brltty-udeb_3.10~r3724-1.1_amd64.udeb 127c6bb7c39d3cb6b64205a4e92dfe0b0b8f4a5e 1261466 brltty_3.10~r3724-1.1_amd64.deb 277dee82b87429e20da0ee582034f15647876a88 64928 libbrlapi0.5_3.10~r3724-1.1_amd64.deb e2ecb7e061e038927359463ec565774d32b2acaa 168152 libbrlapi-dev_3.10~r3724-1.1_amd64.deb 8b87a0f9bafd902d5edbba91ede99fea99f4d7a1 56086 libbrlapi-jni_3.10~r3724-1.1_amd64.deb a93be4ecac0ebec15d602bf1dc5a673b8cf54551 50030 brltty-flite_3.10~r3724-1.1_amd64.deb bc76a41683cd2939c1d764039ace24620a27b352 99812 brltty-x11_3.10~r3724-1.1_amd64.deb ed4d50a0ae8b1cb3faf6eda73b98b71d25a71090 84538 python-brlapi_3.10~r3724-1.1_amd64.deb 909a1b25875d06572d692d5a1d738c6fdd1f89f7 55994 libbrlapi-java_3.10~r3724-1.1_all.deb 18745d2455b8b4d213b1bf169d2cd36d4e28d5fb 50340 cl-brlapi_3.10~r3724-1.1_all.deb Checksums-Sha256: b1492a07772c5ea916e65190f865a1c954fdbe8ac6f71c11bfb4696ec370c262 1572 brltty_3.10~r3724-1.1.dsc 9a7d5b854b3f03ec6e4cd1ebdeeeba84d63fcc0801756c7bbb458e58f8836041 19523 brltty_3.10~r3724-1.1.diff.gz 5d3f61ea4a620f899f6fdc46735f2e90a169f4471824d00df05c8f1543dc2cf2 203704 brltty-udeb_3.10~r3724-1.1_amd64.udeb ec8a0efe34e557a012eafe3854cc99643de0e950f41255e179c0255993d9ce4d 1261466 brltty_3.10~r3724-1.1_amd64.deb dd44b615a95edd56bf0b80126bddbb3596b8318a3262502203a5b6de4d0c6ec6 64928 libbrlapi0.5_3.10~r3724-1.1_amd64.deb 6ae5d537f6587f13ba2cde72287250c2eb1749e42ba1a76eac7a71850a9b9ec7 168152 libbrlapi-dev_3.10~r3724-1.1_amd64.deb 8e17f612eccaf48fef18ef4678a75b0806c478ed777133cacc4c7c74d45df83d 56086 libbrlapi-jni_3.10~r3724-1.1_amd64.deb 16db20d85d3bc4d3d8ab5b9c51d76509f63b8838c2154bbd7b48bba4f74a8f68 50030 brltty-flite_3.10~r3724-1.1_amd64.deb 4facf6aa0499f94305bdcac80f2870ad49a8f14a95c75f33d6beb7b2435598d5 99812 brltty-x11_3.10~r3724-1.1_amd64.deb fde07354dcc4c8df0e7b0e707bd0f9b5b91c77808dbe57753fa2e196af88d5ea 84538 python-brlapi_3.10~r3724-1.1_amd64.deb fa4c220a5b2ba9b5b6b244ee8f0ca57a12b09333aad0f07f4e120499f394a4c5 55994 libbrlapi-java_3.10~r3724-1.1_all.deb b3a6ae9c29b42bd1706f9a281e5c0dc0cd201bca3127393bbf4bf5f3f32f664e 50340 cl-brlapi_3.10~r3724-1.1_all.deb Files: 4a34bd1c6267c90ab648f1825c8de977 1572 admin extra brltty_3.10~r3724-1.1.dsc 7a708794a0f54c2df3da6a19e071ba7a 19523 admin extra brltty_3.10~r3724-1.1.diff.gz 3977b8a2a4968034b71d9707cf5e55e1 203704 debian-installer extra brltty-udeb_3.10~r3724-1.1_amd64.udeb 968436260652070420ddf7aa33b2bce5 1261466 admin extra brltty_3.10~r3724-1.1_amd64.deb 69d66e08dd511585cfe4ab5fdd94aa27 64928 libs extra libbrlapi0.5_3.10~r3724-1.1_amd64.deb 0629789ee0483ce9214ff00ca187891b 168152 libdevel extra libbrlapi-dev_3.10~r3724-1.1_amd64.deb b49a6ca91492a5159a87e73560d9bbba 56086 libs extra libbrlapi-jni_3.10~r3724-1.1_amd64.deb 6e9bfe5c159d13001e5d0de04f1db805 50030 admin extra brltty-flite_3.10~r3724-1.1_amd64.deb 021f72429b44f3ced81351d2d6145e8b 99812 admin extra brltty-x11_3.10~r3724-1.1_amd64.deb 49fe44821628184496260620897dd586 84538 python extra python-brlapi_3.10~r3724-1.1_amd64.deb 16a84337ea556ab3ad324e5c7878c51e 55994 libs extra libbrlapi-java_3.10~r3724-1.1_all.deb a644082974582b15da9737243d893c24 50340 admin extra cl-brlapi_3.10~r3724-1.1_all.deb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkm7hEkACgkQOzsxEBcMRN0YIQCeNS0ckEVEjjBwWYT14WTc+qk2 jHMAoLciEoNAvSmnrNrvNmbg/YojurQg =LcKU -END PGP SIGNATURE- Accepted
Re: need help updating @debian.org email alias
I replied to him in private (because I wanted to mention his current emailForward setting). Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [luabind] Naming library with proper SONAME
* Roberto C. Sánchez [Tue, 10 Mar 2009 18:30:19 -0400]: I am curious as to what people generally think of how the libluabind SONAME will be going forward. I know that certain packages (like libssl) have the complete version in the SONAME, but I can't imagine that this is a really good idea. Is this a showstopper for having libluabind in Debian, or just for a stable release? Is this discouraged, but otherwise permissible? It’s certainly not desirable. Do you have an estimation of how many reverse dependencies libluabind will have? Goswin’s remark about API compatibility is also an important one. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [luabind] Naming library with proper SONAME
* Roberto C. Sánchez [Thu, 12 Mar 2009 17:34:20 -0400]: It’s certainly not desirable. Do you have an estimation of how many reverse dependencies libluabind will have? Goswin’s remark about API compatibility is also an important one. Currently, none of the luabind packages have reverse dependencies (except for stuff like libluabind-dbg depending on libluabind0). Yes, but I asked about an *estimation* of how many there *will* be. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: libpoppler3 missing in unstable
On Tue, Mar 10, 2009, Dirk Eddelbuettel wrote: Normally, we keep the lib$foo$N and add lib$foo$N+1. By withdrawing libpoppler3 you broke the buildability of hundreds of package with tex documentation. Was there a reason? Uploading libfoo2 and making libfoo1 disappear are actually done by different people. Removal of obsolete binaries is done by the ftpteam, I’m putting them on the loop via Bcc, and moving the discussion to -devel. ftpteam, would you be open to discussing a well-defined policy about removal of NBS libraries from unstable? Personally I couldn’t care less about installability problems on user’s machines running unstable: my take is that those machines should have testing in sources.list, period. However, rendering important parts of the toolchain uninstallable is something different. The problem is, of course, defining the “well-defined policy”. For most libraries an early removal has no big consequences. It would have been tempting to have guessed that there wouldn’t be any for poppler either, because the fact that decrufting poppler would render texlive uninstallable, upon which a lot of packages build-depend on, needs a bit of close looking in order to be noticed. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: tex-common with triggers support
* Norbert Preining [Wed, 11 Mar 2009 11:18:45 +0100]: Dear all, the Debian TeX Team has uploaded tex-common 1.15 to unstable which brings triggers support for font maps (calls to updmap-sys) and hyphenation patterns (calls to fmtutil-sys --byfmt). Great. \o/ Those packages shipping fonts, ie those package calling dh_installtex AND having some map files are advised to rebuild with tex-common 1.15 so that updmap-sys is not called two times (once from the postinst, once from the trigger). Shouldn’t the progress on this be tracked somehow? I’m not sure what would be best. There could be a mass bug filing using some usertag, but that may get out of sync if people make an upload without noticing the bug should be closed with it. Another option would be a lintian test that warns if the postinst calls updmap-sys but the package depends on text-common (= 1.15). This would give us the benefit of having an always correct list up on lintian.d.o. I don’t know if this is a fair use of lintian, though, and that’s why I’m Bcc'ing lintian-maint. (I say I’m not sure if this is a fair use of lintian becase, as I understand it, a newly rebuilt package would never trigger the warning, correct?) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: best practice for updating inetd.conf with a user-chosen port?
* Giacomo A. Catenazzi [Wed, 11 Mar 2009 16:56:20 +0100]: how to had new services in /etc/services database? By filing a bug like #353835 (against netbase). -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: tex-common with triggers support
* Stefano Zacchiroli [Wed, 11 Mar 2009 16:20:06 +0100]: On Wed, Mar 11, 2009 at 01:16:43PM +0100, Adeodato Simó wrote: There could be a mass bug filing using some usertag, but that may get out of sync if people make an upload without noticing the bug should be closed with it. Is that a reason for not using the MBF + usertag strategy? It looks to be the right tool to me. If people make an upload without noticing the bug report ... well, they are doing the wrong thing :-), it is not like we should refraining doing the right one for that fear. Practically, my guess is that the impact will be low and that who follows the transition will eventually notice that and close the bug. As usual. Well, my concern was that since this bug just fixes itself with any upload, the list of pending issues in the list would diverge from reality. A NMU would most likely miss closing this bug, eg. But your point is valid as well, though I’ll just get out of this discussion seeing as Norbert implied they have it under control. :-) -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: tex-common with triggers support
* Russ Allbery [Wed, 11 Mar 2009 11:06:41 -0700]: Adeodato Simó d...@net.com.org.es writes: Another option would be a lintian test that warns if the postinst calls updmap-sys but the package depends on text-common (= 1.15). This would give us the benefit of having an always correct list up on lintian.d.o. I don’t know if this is a fair use of lintian, though, and that’s why I’m Bcc'ing lintian-maint. (I say I’m not sure if this is a fair use of lintian becase, as I understand it, a newly rebuilt package would never trigger the warning, correct?) It's fair game to add a Lintian test for whether a program is called in postinst that isn't needed any more. If that's the case here, please do file a wishlist bug against Lintian with the details. (It's always possible that someone wasn't using debhelper, for example.) I think it’s indeed the case. I’ll leave it up to -tex-maint to decide whether they want to file the bug or not. I’d recommend for it, since it can’t hurt. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: To the aqualung NMUer....
* Adam Cécile (Le_Vert) [Tue, 10 Mar 2009 15:42:43 +0100]: I bet it won't work for a package in dak ;) http://incoming.debian.org http://packages.qa.debian.org/aqualung And, FFS, the ACCEPTED mail you get has you *and* the uploader in the To: line. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted kino 1.3.0-2.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 10 Mar 2009 12:23:47 + Source: kino Binary: kino Architecture: source amd64 Version: 1.3.0-2.2 Distribution: unstable Urgency: medium Maintainer: Paul Brossier p...@debian.org Changed-By: Adeodato Simó d...@net.com.org.es Description: kino - Non-linear editor for Digital Video data Closes: 517749 Changes: kino (1.3.0-2.2) unstable; urgency=medium . * Non-maintainer upload. * Ajust src/frame.h for the new location of ffmpeg includes. (Closes: #517749) Checksums-Sha1: 206c819a29dd42b0eaec8c602bd1c42d956f0bde 1704 kino_1.3.0-2.2.dsc 4ad677b7b6ca5bece1fbedccb8ad28317998ef32 19921 kino_1.3.0-2.2.diff.gz 294b6f23ad5b6bea4b401760498d39b6bb9cf59f 4757396 kino_1.3.0-2.2_amd64.deb Checksums-Sha256: 0cad4333a0bc9f0b750e85d340b65e96eff913896db70370250a04181adafa31 1704 kino_1.3.0-2.2.dsc 994c4c687ef5958559ff1b36b39f148a775c4ea8f8f81865420c4e0dc6d822cf 19921 kino_1.3.0-2.2.diff.gz 4da422d142d78c96237699c14efdfefc05ac7e7074177ed193fec800756c0dcb 4757396 kino_1.3.0-2.2_amd64.deb Files: 9ff9c367cd18759411232ec6de078460 1704 graphics extra kino_1.3.0-2.2.dsc 9d566310057f34811cd434c81f4177cc 19921 graphics extra kino_1.3.0-2.2.diff.gz 8f71fd59d274bf9843616de9f8de2672 4757396 graphics extra kino_1.3.0-2.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkm2XZEACgkQOzsxEBcMRN2ZcQCbBLQrvMHX6/1j3d0TFo4zu3F7 jhsAni6WRT+0JcKjizys7SNMTH85vH7l =TlIw -END PGP SIGNATURE- Accepted: kino_1.3.0-2.2.diff.gz to pool/main/k/kino/kino_1.3.0-2.2.diff.gz kino_1.3.0-2.2.dsc to pool/main/k/kino/kino_1.3.0-2.2.dsc kino_1.3.0-2.2_amd64.deb to pool/main/k/kino/kino_1.3.0-2.2_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 libmpcdec 1:1.2.2-2.1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 10 Mar 2009 15:22:20 +0100 Source: libmpcdec Binary: libmpcdec-dev libmpcdec3 Architecture: source amd64 Version: 1:1.2.2-2.1 Distribution: unstable Urgency: low Maintainer: Joe Wreschnig pi...@debian.org Changed-By: Adeodato Simó d...@net.com.org.es Description: libmpcdec-dev - Musepack (MPC) format library [development files] libmpcdec3 - Musepack (MPC) format library Changes: libmpcdec (1:1.2.2-2.1) unstable; urgency=low . * Non-maintainer upload by the Release Team (maintainer is in the LowThresholdNmu list). . * Reupload with bumped epoch to undo unannounced and uncoordinated SONAME bump by the libmpc package. Such transition would tie itself with several ongoing transitions, and would hit us particularly bad because it includes API changes that require porting. Checksums-Sha1: 941bdcbb0fd42ccce38d9e6a3b5c2f93f7867d0a 1045 libmpcdec_1.2.2-2.1.dsc 03914d5a40bc390c559fdd1d57c0c22776cb3171 28157 libmpcdec_1.2.2-2.1.diff.gz d3916b8b896517ea331e57a07b71995a46205e0f 146842 libmpcdec-dev_1.2.2-2.1_amd64.deb 5c8cb9aac36d10bfd14e0e0cd23e700f690abaf9 25982 libmpcdec3_1.2.2-2.1_amd64.deb Checksums-Sha256: b8c940f996a815a7dbfc5e367501635d8901507883524fd5cd126e7f8e220c02 1045 libmpcdec_1.2.2-2.1.dsc 9b535eaf98efe5a929f2718182a90ec739fee0930d2f40bacda18f9be69090ed 28157 libmpcdec_1.2.2-2.1.diff.gz 141ab6d885890362bff1cd3d9fd34d6166eef56982a71e77d0e63b8585ec0bac 146842 libmpcdec-dev_1.2.2-2.1_amd64.deb a51f91a74b650e12669038c68daf9ae9714d36e5e657310b574ee222805f0864 25982 libmpcdec3_1.2.2-2.1_amd64.deb Files: 17f2b45609887ab99cdea4154bcdee88 1045 - optional libmpcdec_1.2.2-2.1.dsc 4649556d8e31c69ad10a097d71c80716 28157 - optional libmpcdec_1.2.2-2.1.diff.gz 972273a45b280e9a89a8d7704b6b1884 146842 libdevel optional libmpcdec-dev_1.2.2-2.1_amd64.deb ba44021a80dddf20f63c439fcf465a6e 25982 libs optional libmpcdec3_1.2.2-2.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkm2hsEACgkQOzsxEBcMRN3W2ACfeweCgbJV6yoqV3Gg71wnAfeX qZMAn2zlA4Ag5tQX70KJvFZF3oo7P6rS =YW65 -END PGP SIGNATURE- Accepted: libmpcdec-dev_1.2.2-2.1_amd64.deb to pool/main/libm/libmpcdec/libmpcdec-dev_1.2.2-2.1_amd64.deb libmpcdec3_1.2.2-2.1_amd64.deb to pool/main/libm/libmpcdec/libmpcdec3_1.2.2-2.1_amd64.deb libmpcdec_1.2.2-2.1.diff.gz to pool/main/libm/libmpcdec/libmpcdec_1.2.2-2.1.diff.gz libmpcdec_1.2.2-2.1.dsc to pool/main/libm/libmpcdec/libmpcdec_1.2.2-2.1.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted xmms2 0.5DrLecter-2.1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 10 Mar 2009 15:02:58 + Source: xmms2 Binary: xmms2 xmms2-plugin-all xmms2-dev xmms2-core xmms2-et libxmmsclient4 libxmmsclient-dev libxmmsclient-glib1 libxmmsclient-glib-dev libxmmsclient++3 libxmmsclient++-dev libxmmsclient++-glib1 libxmmsclient++-glib-dev libxmmsclient-ruby libxmmsclient-ruby1.8 python-xmmsclient xmms2-client-cli xmms2-client-avahi xmms2-client-medialib-updater xmms2-plugin-curl xmms2-plugin-smb xmms2-plugin-mms xmms2-plugin-vorbis xmms2-plugin-flac xmms2-plugin-faad xmms2-plugin-modplug xmms2-plugin-mad xmms2-plugin-musepack xmms2-plugin-avcodec xmms2-plugin-wma xmms2-plugin-sid xmms2-plugin-oss xmms2-plugin-alsa xmms2-plugin-jack xmms2-plugin-id3v2 xmms2-plugin-icymetaint xmms2-plugin-daap xmms2-plugin-ices xmms2-plugin-lastfm xmms2-plugin-vocoder xmms2-plugin-ao xmms2-plugin-mp4 xmms2-plugin-xml xmms2-plugin-xspf xmms2-plugin-cdda xmms2-plugin-cue xmms2-plugin-pls xmms2-plugin-asx xmms2-plugin-rss xmms2-plugin-m3u xmms2-plugin-ofa xmms2-plugin-asf xmms2-plugin-normalize xmms2-plugin-pulse xmms2-plugin-karaoke xmms2-plugin-airplay xmms2-plugin-speex xmms2-plugin-gme xmms2-plugin-gvfs libaudio-xmmsclient-perl Architecture: source all amd64 Version: 0.5DrLecter-2.1 Distribution: unstable Urgency: medium Maintainer: Florian Ragwitz r...@debian.org Changed-By: Adeodato Simó d...@net.com.org.es Description: libaudio-xmmsclient-perl - XMMS2 - perl client library libxmmsclient++-dev - XMMS2 - client library for c++ - development files libxmmsclient++-glib-dev - XMMS2 - glib client library for c++ - development files libxmmsclient++-glib1 - XMMS2 - glib client library for c++ libxmmsclient++3 - XMMS2 - client library for c++ libxmmsclient-dev - XMMS2 - client library devel files libxmmsclient-glib-dev - XMMS2 - glib client library - development files libxmmsclient-glib1 - XMMS2 - glib client library libxmmsclient-ruby - XMMS2 - Ruby client library libxmmsclient-ruby1.8 - XMMS2 - Ruby bindings libxmmsclient4 - XMMS2 - client library python-xmmsclient - XMMS2 - Python bindings xmms2 - Client/server based media player system xmms2-client-avahi - XMMS2 - avahi client xmms2-client-cli - XMMS2 - cli client xmms2-client-medialib-updater - XMMS2 - medialib-updater client xmms2-core - XMMS2 - core package xmms2-dev - XMMS2 - plugin development files xmms2-et - XMMS2 - phone home package xmms2-plugin-airplay - XMMS2 - airplay output plugin xmms2-plugin-all - XMMS2 - all plugins xmms2-plugin-alsa - XMMS2 - ALSA output xmms2-plugin-ao - XMMS2 - libao output plugin xmms2-plugin-asf - XMMS2 - ASF plugin xmms2-plugin-asx - XMMS2 - ASX playlist plugin xmms2-plugin-avcodec - XMMS2 - avcodec decoder xmms2-plugin-cdda - XMMS2 - CDDA plugin xmms2-plugin-cue - XMMS2 - CUE playlist plugin xmms2-plugin-curl - XMMS2 - curl transport for HTTP xmms2-plugin-daap - XMMS2 - daap plugin xmms2-plugin-faad - XMMS2 - faad decoder xmms2-plugin-flac - XMMS2 - flac decoder xmms2-plugin-gme - XMMS2 - gme plugin xmms2-plugin-gvfs - XMMS2 - gvfs plugin xmms2-plugin-ices - XMMS2 - ogg streaming output xmms2-plugin-icymetaint - XMMS2 - shoutcast metadata plugin xmms2-plugin-id3v2 - XMMS2 - ID3v2 plugin xmms2-plugin-jack - XMMS2 - JACK output xmms2-plugin-karaoke - XMMS2 - karaoke plugin xmms2-plugin-lastfm - XMMS2 - Last.FM plugin xmms2-plugin-m3u - XMMS2 - M3U playlist plugin xmms2-plugin-mad - XMMS2 - libmad based mp3 decoder xmms2-plugin-mms - XMMS2 - MMS transport xmms2-plugin-modplug - XMMS2 - modplug decoder xmms2-plugin-mp4 - XMMS2 - MPEG-4 plugin xmms2-plugin-musepack - XMMS2 - mpc decoder xmms2-plugin-normalize - XMMS2 - Normalize plugin xmms2-plugin-ofa - XMMS2 - OFA plugin xmms2-plugin-oss - XMMS2 - OSS output xmms2-plugin-pls - XMMS2 - PLS playlist plugin xmms2-plugin-pulse - XMMS2 - pulseaudio output plugin xmms2-plugin-rss - XMMS2 - RSS podcast plugin xmms2-plugin-sid - XMMS2 - libsidplay2 based decoder xmms2-plugin-smb - XMMS2 - Samba transport xmms2-plugin-speex - XMMS2 - speex decoder xmms2-plugin-vocoder - XMMS2 - vocoder plugin xmms2-plugin-vorbis - XMMS2 - vorbis decoder xmms2-plugin-wma - XMMS2 - wma decoder xmms2-plugin-xml - XMMS2 - XML plugin xmms2-plugin-xspf - XMMS2 - XSPF playist plugin Closes: 517464 Changes: xmms2 (0.5DrLecter-2.1) unstable; urgency=medium . * Non-maintainer upload. * Fix FTBFS due to missing includes and changed location of ffmpeg headers. Patch by peter green and Cyril Brulebois. (Closes: #517464) Checksums-Sha1: c6aea0ea1ba9cad93ecf7b0bd0517fb2e3b15e77 3174 xmms2_0.5DrLecter-2.1.dsc 16f68b5504171895f9a1bea4f8a1f7f67836b175 13468 xmms2_0.5DrLecter-2.1.diff.gz b581b07c908969dac58c73f48072b7df08fdd420 12862 xmms2_0.5DrLecter-2.1_all.deb 3b4abcd21754dede9fa8f1b442580348990f3400 8240 xmms2-plugin-all_0.5DrLecter-2.1_all.deb 06bf6052458070f6e078219805b31e312ec4d4ec 24720 xmms2-dev_0.5DrLecter-2.1_all.deb
Re: To the aqualung NMUer....
I can't possibly say how annoyed I am. 1. Don't spam devel to contact just one person. 2. Read devel: http://lists.debian.org/debian-devel/2009/03/msg00034.html 3. Or you can also read d-d-a: http://lists.debian.org/debian-devel-announce/2009/03/msg0.html 4. Or you can just deal with your RC bugs in a timely manner 5. Or you can just mention in the bug report that you're working on a fix 6. Or you can state that you don't want NMUs 7. Or you could do as everybody else and actually thank people for NMUing you Best, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org La música es de los que la quieren escuchar y de nadie más. -- Andrés Calamaro -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: libphysfs 1.0.1
* Barry deFreese [Wed, 04 Mar 2009 13:13:40 -0500]: Hello, Second, and more importantly, I actually see no reason for the SONAME bump! Meaning, that as far as I can see, the list of symbols between libphysfs-1.0.so.1 and libphysfs-1.0.so.0 is identical. Do you know if there has been some other ABI change that does not entail symbols, and which would make the bump needed? If not, we'll need to talk about reverting it. It'd be great if you could check. I don't think there is. What I think actually happened was that the previous version actually had the wrong package name. Does it really require a reversion? 1.1.1 may suffer from the same issues. (Meaning it has another soname change upstream but I think the symbols are identical, but I need to verify that.). Well it appears that I was wrong about part of it. 1.0.0 isn't complaining about the package name, even though I think it probably should. 1.0.1 Does seem to be ABI compatible and is NOT a soname bump. I'm attaching objdump -T output from 1.0.0 and 1.0.1 just in case I missed something. 1.1.1 does appear to have some significant changes so that might be a bigger issue but I think I goofed on the 1.0.1 upload and there should be no issues. Sorry I should have clarified. libphysfs-1.0.0 SONAME is libphysfs-1.0.so.0 and libphysfs-1.0.1 is libphysfs-1.0.so.1. (Thanks to Julien for pointing that out). I've taken a look at the source. I think the 1.0.1 release gets the -version-info value for libtool wrong. AIUI, the attached patch should suffice if applied to 1.0.1. Meaning, it'll make 1.0.1 maintain the same SONAME as 1.0.0. It even is consistent with the instructions given in the configure.in file (http://paste.pocoo.org/show/106868/), but I think this upstream could use some education regarding these matters, and that the instructinons don't make much sense anyway. As a start, I think they should stop passing -release MAJOR.MINOR to libtool, and then use LT_CURRENT, LT_REVISION and LT_AGE appropriately (as explained in [1]). If anybody feels like fighting that battle, please do so. If somebody could work with Barry to see if the SONAME given by upstream for 1.1.1 is appropriate, that'd be great too. Barry, a good start would be the output of `nm -D` and `objdump -p` for the 1.1.1 library, plus the configure.in file. In the meantime, Barry, please upload 1.0.1-3 with the attached patch at your earliest convenience. Cheers, [1]: http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Radiohead - No Surprise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: libphysfs 1.0.1
--- libphysfs-1.0.1.orig/configure +++ libphysfs-1.0.1/configure @@ -1506,8 +1506,8 @@ MAJOR_VERSION=1 MINOR_VERSION=0 MICRO_VERSION=1 -INTERFACE_AGE=0 -BINARY_AGE=0 +INTERFACE_AGE=1 +BINARY_AGE=1 VERSION=$MAJOR_VERSION.$MINOR_VERSION.$MICRO_VERSION --- libphysfs-1.0.1-2.orig/configure.in +++ libphysfs-1.0.1-2/configure.in @@ -16,8 +16,8 @@ MAJOR_VERSION=1 MINOR_VERSION=0 MICRO_VERSION=1 -INTERFACE_AGE=0 -BINARY_AGE=0 +INTERFACE_AGE=1 +BINARY_AGE=1 VERSION=$MAJOR_VERSION.$MINOR_VERSION.$MICRO_VERSION AC_SUBST(MAJOR_VERSION)
Accepted potamus 0.9-1.1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 07 Mar 2009 11:19:44 +0100 Source: potamus Binary: potamus Architecture: source amd64 Version: 0.9-1.1 Distribution: unstable Urgency: medium Maintainer: Anibal Avelar (Fixxxer) aave...@cofradia.org Changed-By: Adeodato Simó d...@net.com.org.es Description: potamus- extremely lightweight GTK-based audio player Closes: 517148 Changes: potamus (0.9-1.1) unstable; urgency=medium . * Non-maintainer upload. * Change build-dependency on libvorbisfile3 into libvorbis-dev, to fix FTBFS. (Closes: #517148) * Additionally, fix libavcodec and libavformat includes to their new location. Checksums-Sha1: ae5e42a347d20a560ea66efff3659cd4ad0d6ba5 1252 potamus_0.9-1.1.dsc c918ffa8f7ddb2bc3ca682e090afbd591a54c869 4642 potamus_0.9-1.1.diff.gz 6368d27d428a3e1c73f1c4363f788c37e7b107eb 40778 potamus_0.9-1.1_amd64.deb Checksums-Sha256: 08138994266952920b0fa3a8bb0707c3ccfa110911e61a4f5cd6281bce4fb40d 1252 potamus_0.9-1.1.dsc d8639f9840cb7ebb1f96ad0c887407578e33757fdde7cda28e28e77ade8fb8f5 4642 potamus_0.9-1.1.diff.gz fc31ca0f27b659c20e0c00673f7ae26f499e4bbed0fd1e3084493571b562be04 40778 potamus_0.9-1.1_amd64.deb Files: 8551c2939d45c7ce18f6b4934dc26550 1252 gnome optional potamus_0.9-1.1.dsc e7f8f00656031de55efda71489229cb9 4642 gnome optional potamus_0.9-1.1.diff.gz 4fcdc55a39ad6bb274591547e22b1c72 40778 gnome optional potamus_0.9-1.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkmyS/YACgkQOzsxEBcMRN2SdgCeL/dDf2KIInvGmXzHHxTKUG56 kEUAnjs494YHApSk1AeHjUSPX3fMRtI2 =Ut+2 -END PGP SIGNATURE- Accepted: potamus_0.9-1.1.diff.gz to pool/main/p/potamus/potamus_0.9-1.1.diff.gz potamus_0.9-1.1.dsc to pool/main/p/potamus/potamus_0.9-1.1.dsc potamus_0.9-1.1_amd64.deb to pool/main/p/potamus/potamus_0.9-1.1_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Planet Debian ES: ¿com o lo hacemos?
* Carlos Galisteo [Fri, 06 Mar 2009 09:45:17 +0100]: 2009/3/5 Ana Guerrero a...@debian.org: b) El planet es para agregar contenidos de blogs personales en español relacionados con Debian y mayormente asuntos técnicos. No hay ningún problema con contenidos personales, pero evitando siempre contenido que pueda ser ofensivo a otras personas. Solo una apreciación estética. Yo cambiaría ese «mayormente» por «principalmente» o «mayoritariamente» si el texto se va a publicar en algún sitio. Mayormente era una palabra preciosa y selecta que sólo la leí de Umbral, hasta que llegó cierta serie a la televisión española... -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: The Postal Service - Such great heights -- To UNSUBSCRIBE, email to debian-devel-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “pro per manpage” for every command
* Charles Plessy [Tue, 03 Mar 2009 13:23:37 +0900]: Le Tue, Mar 03, 2009 at 12:10:09AM +, Roger Leigh a écrit : crap maintainer bloody lazy. I thought I was doing something good when writing manpages, now I realise what I am for not writing enough : « responsable de merde putain de feignant » (translated in my language). Thank you for opening my eyes. Well, I think writing missing manpages is commendable independently of what we may agree on calling those who won't do it. Have a nice day, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Oh my God, you're pimping me out for a new roof? - And windows! -- Andrew and Bree Van De Kamp -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Pristine source from upstream VCS repository
* Stefano Zacchiroli [Wed, 04 Mar 2009 11:25:23 +0100]: What you can do is probably have a 2 level architecture, with a VCS Debian-side which mirrors upstream VCS (easy with DVCS) but has in addition the deltas. The first time your tarball fetching tool will create the tarball and store its delta. The other times it will just use pristine-tar to check it out. I haven't used it in this way, but one should investigate if the need for the mirror VCS is needed at all. From the first paragraph in the manpage, it would seem that pristine-tar just wants a checkout of the appropriate revision, i.e. an unpacked tree. So you could checkout that from the upstream VCS, and store the delta in the debian-only VCS, if in fact your packaging VCS is debian-only. (Else, this point is moot. :-) I hope I explained myself clearly. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As scarce as truth is, the supply has always been in excess of the demand. -- Josh Billings -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ogle 0.9.2-5.3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 Mar 2009 09:52:16 + Source: ogle Binary: ogle ogle-mmx ogle-altivec Architecture: source amd64 Version: 0.9.2-5.3 Distribution: unstable Urgency: medium Maintainer: Alan Woodland awoodl...@debian.org Changed-By: Adeodato Simó d...@net.com.org.es Description: ogle - DVD player with support for DVD menus ogle-altivec - DVD player with support for DVD menus ogle-mmx - DVD player with support for DVD menus Closes: 516834 Changes: ogle (0.9.2-5.3) unstable; urgency=medium . * Non-maintainer upload. * Fix FTBFS when building against libdvdread 4.1.3. Patch sent in by peter green and obtained from the NetBSD project. (Closes: #516834) Checksums-Sha1: e44754868858297b7829a4f8a61d005409beef4d 1291 ogle_0.9.2-5.3.dsc 3a4bbe98e20b80dc8482984931cf025a58af28c6 363552 ogle_0.9.2-5.3.diff.gz fed9d6ce0f5955b965d04e901ff848683b6d26fb 241176 ogle_0.9.2-5.3_amd64.deb 045d41f2a939cc822710efc15b8e4734fa870081 241136 ogle-mmx_0.9.2-5.3_amd64.deb Checksums-Sha256: 1fd82eac222f8e5540c7a3e808ebd819c78fadfff16db08deb421089091c0e99 1291 ogle_0.9.2-5.3.dsc 9c0063da4d8683e5c96dcda4e9829cd1ed0cb242dae219d472c245ec02092a4b 363552 ogle_0.9.2-5.3.diff.gz bd6fac6ddaaf18ba38fefab7712eee3110a04631c3f946c3b781f797139721b7 241176 ogle_0.9.2-5.3_amd64.deb 38440c3970ce5461068848e7bb7cda38961b2d139377baa80438fd1cb903025f 241136 ogle-mmx_0.9.2-5.3_amd64.deb Files: 76eb139efbe4f54ede89cb3d28800a31 1291 graphics optional ogle_0.9.2-5.3.dsc f383fe32013a21101b869216bb573a4b 363552 graphics optional ogle_0.9.2-5.3.diff.gz 46da5089625ab8022c5ca5657cb8217f 241176 graphics optional ogle_0.9.2-5.3_amd64.deb 474dc37843072529ae8bd602ea4796b9 241136 graphics optional ogle-mmx_0.9.2-5.3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkmuUP4ACgkQOzsxEBcMRN2S2gCg0Hzy6TdfF/jy9p0bD2DBAFGa y6EAoIg0iaZ/iyacPQOklxN95WOMEbSa =7wou -END PGP SIGNATURE- Accepted: ogle-mmx_0.9.2-5.3_amd64.deb to pool/main/o/ogle/ogle-mmx_0.9.2-5.3_amd64.deb ogle_0.9.2-5.3.diff.gz to pool/main/o/ogle/ogle_0.9.2-5.3.diff.gz ogle_0.9.2-5.3.dsc to pool/main/o/ogle/ogle_0.9.2-5.3.dsc ogle_0.9.2-5.3_amd64.deb to pool/main/o/ogle/ogle_0.9.2-5.3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Up for adoption: Xiph.org and OpenEXR packages
Hello, (pkg-multimedia-maintainers and pkg-phototools-devel Bcc'ed). I have several packages (all libraries except one) I can no longer take proper care of, and I'd appreciate if somebody/group who knows how to maintain a library would step up and take them. They come in two groups: 1. Xiph.org packages * libao * libogg * libspiff * libtheora * libvorbis * uriparser * vorbis-tools I initiated some time ago a pkg-xiph project on Alioth to take care of all these packages. For some time I've been unable to work on them, and the person who has been doing all of the work since then has recently stepped down as well. Maybe pkg-multimedia would like/could take care of them? Or anybody else wants to adopt the pkg-xiph project? (I'm CC'ing Peter Samuelson, who expressed interest at some point.) 2. OpenEXR packages === * openexr * ilmbase These two library packages I RFA'ed quite some time ago (#494877 and #494878), but the person who expressed initial interest won't have time any time soon, and has indicated it's okay to search for somebody else. I have no idea if these would be appropriate for the pkg-phototools group, but I guess it's worth a try. I'm also CC'ing the maintainer of openexr-tools, Pino Toscano, in case he has particular interest in OpenEXR packages. I'll file RFA bugs in a week if this thread doesn't succeed, and fix RC bugs during that period. If they are many, at some point I will have to orphan them. Many thanks in advance, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- F. Nietzsche -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “pro per manpage” for every command
* brian m. carlson [Mon, 02 Mar 2009 19:45:22 +]: help2man is a fine starting point for a manpage, but unless the help messages are very verbose, it is not sufficient. A manpage needs to explain all the possibilities and interactions between different options that are usually not provided by --help output. An excellent example is gpg(1). help2man could provide a very basic starting point, but the resulting manpage would be woefully incomplete. This is true. Possibly the document around the man page requirement could point to help2man as a quick solution in case there is useful --help output but no man page. My concern is that people will solely use help2man instead of providing a real manpage. Debian requires manpages for a reason: to provide adequate documentation on how to use installed programs. Many times the problem is that upstreams do provide such adequate documentation... in other formats than man pages. What should the packager do in that case? Create a dummy man page pointing out to eg. /usr/share/doc/foopkg/html/fooprog.html? Copy over the contents of fooprog.html to fooprog.1? Other? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Ana Torroja - Les Murs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage
* Ben Hutchings [Mon, 02 Mar 2009 21:10:21 +]: On Mon, Mar 02, 2009 at 04:42:19PM +0100, Sylvain Rochet wrote: Hi, On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote: What does this have over PowerDNS? Probably nothing, else that I am using it and packaging it for my own and thought that it would be a good idea to contribute to Debian, is redundancy a problem ? Even if you're a perfectly responsible maintainer, a new package still requires some work by ftpmaster, the release team, possibly the security team, and so on. It also increases the number of options a user has to choose between. If the package is redundant, this is a waste of their time. This is true. However, while increasing the number of options a user has to choose from is a drawback, it's at the same time a benefit. Figuring out which software you want to use for a particular purpose is painful, because all suck in their own ways and you need to find the one that sucks less for you. And when you find it without having to get outside of your distribution's pool, you'll be thankful that somebody made that happen. Sadly, I don't think the decision of deciding which ones will suck less for users can be outsourced to the maintainers, at least not in an unopinionated distribution. Which is of course quite different from saying that we should not be setting a minimum quality bar for all packages, I'm all for that (but how?). So, if mydns is a reasonably fine piece of software, I see no reason why we shouldn't include it. We need less crap in the archive, not less good software as well.¹ Encouraging upstreams to work together is fine, but in practice very seldom will yield results, so I don't have anything against it being done, but I don't think it should be a substitute for packaging the software. (¹) I realize mydns could be complete crap, but the argument still holds. My off-the-top-of-my-heart 2¢, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A hacker does for love what other would not do for money. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted mlocate 0.21.1-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 02 Mar 2009 19:18:48 +0100 Source: mlocate Binary: mlocate Architecture: source amd64 Version: 0.21.1-2 Distribution: unstable Urgency: low Maintainer: Adeodato Simó d...@net.com.org.es Changed-By: Adeodato Simó d...@net.com.org.es Description: mlocate- quickly find files on the filesystem based on their name Closes: 504350 Changes: mlocate (0.21.1-2) unstable; urgency=low . * Do not let the cron job run if we detect we're running on battery. Patch from Ubuntu by Colin Watson. (Closes: #504350) . * Update Standards-Version to 3.8.0 (no changes needed). Checksums-Sha1: de4b3f2a6a6f6f223ea1a7b4eda94b64c9e83c32 1267 mlocate_0.21.1-2.dsc 89fb95761242a5dc3d267a0cfc4797ea06ea1c10 4606 mlocate_0.21.1-2.diff.gz 317302b851f816ec0b58cb886bd767fae82ab872 78696 mlocate_0.21.1-2_amd64.deb Checksums-Sha256: c25155675ed5ab265725d70d27810c00cbb8417e0ea6059806fbd32b9815d25e 1267 mlocate_0.21.1-2.dsc 3abbbd1531f9427047945f1995365690444afb118d948770fda20d1d6efe7fdb 4606 mlocate_0.21.1-2.diff.gz 47c7efa10b9e48107f8a56ad11568b59a877937ded94e70bc223e62c183ac0b6 78696 mlocate_0.21.1-2_amd64.deb Files: 22940a02ba3ef9ea5a6d2e4762dd4d47 1267 utils standard mlocate_0.21.1-2.dsc 0ac87b74c548fadc558230c2e79c5c18 4606 utils standard mlocate_0.21.1-2.diff.gz 16807fa0751db53647f6daa30fd5ebf9 78696 utils standard mlocate_0.21.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkmsI1gACgkQOzsxEBcMRN27YgCgzAbNf+1hRhbh+wkFRUdE0Kh7 yPUAoJEDBu1wjbNdT0sRtL2OUmOE9EFr =SvpP -END PGP SIGNATURE- Accepted: mlocate_0.21.1-2.diff.gz to pool/main/m/mlocate/mlocate_0.21.1-2.diff.gz mlocate_0.21.1-2.dsc to pool/main/m/mlocate/mlocate_0.21.1-2.dsc mlocate_0.21.1-2_amd64.deb to pool/main/m/mlocate/mlocate_0.21.1-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
New format for binNMU requests
I've updated http://wiki.debian.org/binNMU to include a pointer to the preferred format for binNMU requests, which supersedes the old one. The appropriate syntax is explained at: http://release.debian.org/wanna-build.txt Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: María del Monte - Vive -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RC bugs blocking transitions
Hello, We have a number of FTBFSes that are blockers for the current set of transitions going forward. I've gone ahead and tagged them with user:debian-rele...@lists.debian.org and usertag:transition-blocker. The list is here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tagusers=debian-rele...@lists.debian.orgdata=transition-blockerrepeatmerged=no Or if you prefer fancy: http://snipr.com/transition-blockers NMUs for any of these are welcome; I'm Bcc'ing pkg-multimedia-maintainers, since they said they'd start a NMU campaign, but I think they'll appreciate any help. If nobody objects, I'm going to permanently decrease the waiting period for bugs in the transition-blockers list (current or future) from 7 to 3 days. Just be civil and honour maintainer's wishes. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org «¡Pero si es tan español que debe de tener el cerebro en forma de botijo, con pitorro y todo!» -- Javier Cercas, “La velocidad de la luz” -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted amule 2.2.3-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 01 Mar 2009 14:16:29 +0100 Source: amule Binary: amule amule-common amule-utils amule-utils-gui amule-daemon Architecture: source all amd64 Version: 2.2.3-2 Distribution: unstable Urgency: low Maintainer: Adeodato Simó d...@net.com.org.es Changed-By: Adeodato Simó d...@net.com.org.es Description: amule - client for the eD2k and Kad networks, like eMule amule-common - common files for the rest of aMule packages amule-daemon - non-graphic version of aMule, a client for the eD2k and Kad netwo amule-utils - utilities for aMule (command-line version) amule-utils-gui - graphic utilities for aMule Closes: 418273 Changes: amule (2.2.3-2) unstable; urgency=low . * The I Think I Need a New Heart release. . * Upload to unstable. * Use xdg-open as default preview program instead of mplayer. (Closes: #418273) Checksums-Sha1: 473278f35c01b4c129f1d252e248d8ab7294ff5a 1415 amule_2.2.3-2.dsc cc8042d3bdc29e111bf8a5058ad6d326b74fe29e 22059 amule_2.2.3-2.diff.gz f4a800537e72522e4cb608a7268f148c06d02c33 2371514 amule-common_2.2.3-2_all.deb b7609016f2dc3e8f34b661dd0c15ab86672e9f85 1859114 amule_2.2.3-2_amd64.deb 78b823d608bcdbfc80715e94fe49ba5dc9542809 459400 amule-utils_2.2.3-2_amd64.deb 055c09e9e8fe10d0adfe9bdde65a51accdb449de 1293740 amule-utils-gui_2.2.3-2_amd64.deb a9178ecd887eae4bbe267770e61eb85abf09b5ac 1196034 amule-daemon_2.2.3-2_amd64.deb Checksums-Sha256: 59811961236597205f6b9347250311fe2533a93d8e66cc7d4992343968e086b1 1415 amule_2.2.3-2.dsc dfaeae2c7dbbd2a4d65c9b88199bc9fec551cbb97c700f5f5023d45bd6d9d97e 22059 amule_2.2.3-2.diff.gz 82fbeb5d4db832e32ea2b0b64373673c877e14f10b7a65d3c1681683cb05fdbd 2371514 amule-common_2.2.3-2_all.deb 4c560e4cc62e3e547c43c298de7fdcf3bc2cbcb809ff1dde1f2db3f20385faca 1859114 amule_2.2.3-2_amd64.deb c4419ea8f643bc568626e1f4e346acfa47de6d381af1da2f728983acb9d68b89 459400 amule-utils_2.2.3-2_amd64.deb 51cdd28336a584a84883c073934bfab3620cbb17626088be9ff4dde0d410a415 1293740 amule-utils-gui_2.2.3-2_amd64.deb a7fc92674eb43007c35670a082c0553d045a96ba679169ec8316d55bf3d25ef7 1196034 amule-daemon_2.2.3-2_amd64.deb Files: acd6eaeb0be59c0da0186cc38b7ec294 1415 net optional amule_2.2.3-2.dsc 9402883fb1efb52c23d6a425109ef855 22059 net optional amule_2.2.3-2.diff.gz 84a9be3b2bafff2de30644f214b0a5ad 2371514 net optional amule-common_2.2.3-2_all.deb 21a4d91affe2a856a815a3223cf9668a 1859114 net optional amule_2.2.3-2_amd64.deb 2337f847361de66100dddc5f10a5c7c5 459400 net optional amule-utils_2.2.3-2_amd64.deb df5036f3d4437f0b774b4d282fbc0dc8 1293740 net optional amule-utils-gui_2.2.3-2_amd64.deb be75671bea031b0cce2d149dcd70e55c 1196034 net optional amule-daemon_2.2.3-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Adeodato Simó d...@net.com.org.es iEYEARECAAYFAkmqlIoACgkQOzsxEBcMRN2d3QCgjSo4gBjetGfbqj6XC0gQEII6 w38An0OPtLQWkZpUr2lgHaypREK8Jo7O =6XFo -END PGP SIGNATURE- Accepted: amule-common_2.2.3-2_all.deb to pool/main/a/amule/amule-common_2.2.3-2_all.deb amule-daemon_2.2.3-2_amd64.deb to pool/main/a/amule/amule-daemon_2.2.3-2_amd64.deb amule-utils-gui_2.2.3-2_amd64.deb to pool/main/a/amule/amule-utils-gui_2.2.3-2_amd64.deb amule-utils_2.2.3-2_amd64.deb to pool/main/a/amule/amule-utils_2.2.3-2_amd64.deb amule_2.2.3-2.diff.gz to pool/main/a/amule/amule_2.2.3-2.diff.gz amule_2.2.3-2.dsc to pool/main/a/amule/amule_2.2.3-2.dsc amule_2.2.3-2_amd64.deb to pool/main/a/amule/amule_2.2.3-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
* Joerg Jaspert [Thu, 26 Feb 2009 21:07:35 +0100]: database libmysql* libdb4* I'm not sure these (and possibly *some* of the other lib* packages included in the listing) should be moved out of Section: libs. I can see how having a database section to browse can be useful, but I don't think support libraries have a place there, since they're something that's going to be installed because of dependencies, and not intentionally. Thoughts? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Luke Vibert - Synthax -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Old bug in ppmtofb is quite important
* Jaap Boender [Thu, 19 Feb 2009 13:47:01 +0100]: Hello, Jaap. The explanation: since ppmtofb conflicts with any python version strictly higher than 2.4, any package that depends on python-2.4 will not be installable together with ppmtofb, hence the 1591 packages (a full list, with for every package the dependency path that links it to python is available at http://www.pps.jussieu.fr/~boender/ppmtofb_conflicts.txt ). Thanks for this information. The package just needs to drop the conflict, it's buggy anyway. Additionally, maybe the package should be removed altogether (CC'ing -qa). It has popcon 5, and hasn't seen a real upload for 6 years. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Don't be irreplaceable, if you can't be replaced, you can't be promoted. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules being or not a makefile
* Julien Cristau [Tue, 17 Feb 2009 13:03:18 +0100]: On Tue, 2009-02-17 at 11:16 +0100, Loïc Minier wrote: On Mon, Feb 16, 2009, Russ Allbery wrote: Why would we want to sanction that when the same effect can be achieved by using a debian/rules of: #!/usr/bin/make -f %: dh $@ without risking breaking any existing assumptions or software? Which software would be affected? dpkg-source -b, for one. You can't put a symlink in the diff.gz. I thought exactly the same, but this could be a feature (the - dh symlink) that v3 source packages could use. However, I don't think it's a good idea at all, and hope it doesn't go forward. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If there is a sin against life, it consists perhaps not so much in despairing of life as in hoping for another life and in eluding the implacable grandeur of this life. -- Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Plea for library transition coordination
Please don't include a statement If nobody objects, I'll go ahead with this transition in a few days in your transition requests to debian-release. If you must absolutely do that, directly skip the mail. There are a lot of requested transitions already, and we're doing our best (unforeseen personal constraints permitting) to start allocating as many as possible at the same time, in a way that allows us to keep at least an ounze of sanity. Also, we're probably going to be a bit more greedy than initially planned, at the prize of possibly breaking selected packages in testing. I get that everybody is anxious to get their work done, and I'm sorry the Release Team is the bottleneck, but I don't think having your transition stuck in unstable for four months is going to be any funnier than waiting one. Thanks for your cooperation, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- F. Nietzsche -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
