Re: Package: splix
On Wed, Mar 26, 2008 at 06:59:01PM +0100, Patrick Ringl wrote: Hello, the last upload of that package was at the beginning of 2007 - meanwhile there have been 4 upstream releases since that time. I'd like to know what happened to the package and in case the maintainer is not responding in time, and if nobody objects - I'd like to take the package over. Go ahead, I added it because I own such printer, but the bugs that were reported were with different models I could not test myself. The upstream package 1.0.1-1 unfortunately was missing some generated files, I'm not sure whether that's fixed now (and cups-ddk, #468911, was not packaged back then, so I couldn't do the stuff the Debian way). If you'd also be able to get cups-ddk in, to make the package more like the Debian way and regenerate all generated files, that'd be extra great. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted splix 1.0.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 2 Jun 2007 15:31:48 +0200 Source: splix Binary: splix Architecture: source i386 Version: 1.0.1-1 Distribution: unstable Urgency: low Maintainer: Jeroen van Wolffelaar [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: splix - Driver for Samsung's SPL2 (bw) and SPLc (color) laser printers Closes: 411167 Changes: splix (1.0.1-1) unstable; urgency=low . * Introduce Splix to Debian, based on Ubuntu package (thanks Till!) (Closes: #411167) * Added patch by Joost van Blokland to enable page logging * Fix debian/rules clean to also remove produced binary Files: 74baf85ccff7c765a0a5c0462894fa66 675 text optional splix_1.0.1-1.dsc 5dc1fc4b1e0208b85e3d6b549fd307e8 97886 text optional splix_1.0.1.orig.tar.gz 8d346fac63ed8e1af81fe444848d9660 3162 text optional splix_1.0.1-1.diff.gz 7fdf305d2315a5d7df43dd50c98c4f6b 47354 text optional splix_1.0.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFGYXa/l2uISwgTVp8RAj09AJ9Gqz3WynTdtHJmJ5FShAXhXglQywCeLcVF EAQ68eqPziPfSPkxcmj7F2E= =5UXJ -END PGP SIGNATURE- Accepted: splix_1.0.1-1.diff.gz to pool/main/s/splix/splix_1.0.1-1.diff.gz splix_1.0.1-1.dsc to pool/main/s/splix/splix_1.0.1-1.dsc splix_1.0.1-1_i386.deb to pool/main/s/splix/splix_1.0.1-1_i386.deb splix_1.0.1.orig.tar.gz to pool/main/s/splix/splix_1.0.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The number of etch installations is rocketing...
On Thu, Apr 12, 2007 at 01:13:55PM +0200, Thijs Kinkhorst wrote: On Thu, 2007-04-12 at 05:29 -0400, Joey Hess wrote: I wonder if it would be reasonable to make d-i hit one of two urls depending on whether the user chose to enable popcon, and count the results. Since there are some potential drawbacks to this functionality, what concrete gain would the project have for collecting that information? As suggested by a Linux.com article about what Fedora did[1], you can use it to be more convincing towards others. For example, when trying to convince a software supplier to change license terms to be DFSG-free, it will sound more convincing if we can actually give some better estimate on how many users Debian has than eh, no idea actually. To quote the article: | The metrics gleaned from Fedora's data collection amount to more than | just a chance for developers to pat themselves on the back, however. | They also provide the opportunity to show the growing number of Linux | users within the computing community which, in turn, may goose hardware | vendors into offering more Linux-friendly goods and services. | | This provides objective data that helps prove Linux is growing and it | helps build a case for Linux in general says Spevack. Also, we always | say we wish hardware vendors had more [Linux-capable] drivers. Well, if | you can go to them and say, 'Hey, there's millions of people using | this,' then maybe they will listen. In the real world, you need data to | prove your case. Well, here it is. --Jeroen [1] http://www.linux.com/article.pl?sid=07/01/15/2137215 -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFO: duplicity
On Fri, Apr 06, 2007 at 07:50:28PM +0200, Martin Wuertele wrote: Hi! Since I hardly use it myself and I currently have less time for debian due to job change duplicity is up for adoption. I have some patches that need a bit of adjustment closing most of the open bugs but I currently lack the time to throw them all matching togeather. Can you please file an ITA about this into the BTS? Or if you cannot maintain it for the time being, even an O:? This way, this mail will not be lost. See http://www.debian.org/devel/wnpp/ for details. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Attempted summary and thoughts
On Tue, Mar 27, 2007 at 06:43:03PM -0700, Russ Allbery wrote: Don Armstrong [EMAIL PROTECTED] writes: On Wed, 28 Mar 2007, Charles Plessy wrote: The maintainer is not MIA, but does not actively develop anymore. Packages like this should have a message to the current maintainer with a proposal to co-maintain or orphan+adopt followed by an ITH (intent to hijack) if there is no response within a reasonable period of time.[1] If no one is interested in stepping forward to do this and deal with the package, then the status quo is the best that can be done. While it is suboptimal, it's the best we can do until someone wants to take over. So, here's a possibly weird proposal. What if we had some mechanism whereby people could indicate interest in maintaining a package should anything happen to the current maintainer? Have it be as non-confrontational as possible by having it not indicate any feeling about whether the package is currently maintained well, just a willingness to help should the current maintainer be unable to continue for some reason. I don't think this will work. Why not? Because I don't think we'll ever get anywhere near adequate 'subscriptions' of showed interest. But well, that's my projection, we won't know for sure without actually trying. It is a huge task to undertake though, and requires a lot of time from anyone potentially interested to what packages one is interested in, while in 99% of the cases, nothing will get done with that information -- and then it'll also run stale. I also think you'll see that for example the cool sounding package names like standard and higher priority ones, will get quite some interest from relatively new or prospective developers, while in practice, if such a package would get orphaned, someone who would be a pretty good adopter would not have listed himself at that moment. To just take a totally random example, if such a system would have existed, would Kurt Roeckx have listed himself as 'interested in libtool' before it got orphaned? It took a while, but he did in the end adopt it. To address the original question, I don't believe any potential adoption will be 'urgent' from one day to the other. For urgent fixes, one can NMU, who's the maintainer is something that IMHO requires a bit more care. I can't come up with a single example when it'd really be essential that a package gets adopted within 2 weeks. So, I think the best way forward (and the way it happens a lot), is that if someone or some team of people feel they'd be better at maintainer a certain package than it currently is, one can politely mail the maintainer about cooperation or possibly even adoption. I think in the majority of cases you'll find that this works just fine. Where it doesn't, in the case of unresponsive or totally overworked maintainers, the mia team can be of assistance. Such stuff cannot really be dealt with properly in an automated fasion anyway. I think it'd make most sense to enlarge the MIA team a bit and possible rename it. Matchmaking In Action (matching between packages and maintainers)? In any case, take the task of the team a bit broader than it currently is (it already does its share of beyond-true-mianess action), but for that to work out, its task would need to be a bit better defined. Perhaps the team could also do with some medium amount of official power in terms of giving over maintainance, although the status quo works reasonably well so far -- and there's the tech-ctte who could rule in cases where it doesn't work out. In practice, when the MIA team decided to orphan certain packages, that decision gets respected, with only one exception I can recollect. But again, in the majority of cases, some solution can be found in constructive talks, and that's preferable anyway. The cases where there's really some good candidate to take over and the maintainer is not willing to let go of maintainership are pretty rare as far as I can see. I think it's a better expenditure of overall time to only really 'mediate' where that's really required. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted up-imapproxy 1.2.4-10.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Mar 2007 04:04:55 +0200 Source: up-imapproxy Binary: imapproxy Architecture: source i386 Version: 1.2.4-10.1 Distribution: unstable Urgency: high Maintainer: Jose Luis Tallon [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: imapproxy - IMAP protocol proxy Closes: 415954 Changes: up-imapproxy (1.2.4-10.1) unstable; urgency=high . * NMU to fix RC bug . [ Jose Luis Tallon ] * Re-starting imapproxy failed when it was already running. - Fixed imapproxy to write a pidfile itself Start-stop-daemon can now interact with it properly (Closes: #415954) . [ Jeroen van Wolffelaar ] * Document -p in manpage * Patch cleanup * Add code to initscript to not attempt to start a second version if already running, and to not fail if imapproxy is no longer running (also #415954) Files: ee40219518d1d3848b647bb31ee693f3 741 mail optional up-imapproxy_1.2.4-10.1.dsc 1b7fd8126da9666f425a6b0a85ae18fb 61716 mail optional up-imapproxy_1.2.4-10.1.diff.gz 893bf0a231cdf7ae6695d72a5f9a8915 54390 mail optional imapproxy_1.2.4-10.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFGCc/Jl2uISwgTVp8RAkKrAJ4x+TmhN8zvDRUM375OmCSx9L00kACeIGZd AroEHNLbHjI2eLfR3Ef/e+w= =KY4P -END PGP SIGNATURE- Accepted: imapproxy_1.2.4-10.1_i386.deb to pool/main/u/up-imapproxy/imapproxy_1.2.4-10.1_i386.deb up-imapproxy_1.2.4-10.1.diff.gz to pool/main/u/up-imapproxy/up-imapproxy_1.2.4-10.1.diff.gz up-imapproxy_1.2.4-10.1.dsc to pool/main/u/up-imapproxy/up-imapproxy_1.2.4-10.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: co-mentor for a GSoC proposal wanted: debbugs web submission
On Thu, Mar 15, 2007 at 04:49:36PM -0700, Steve Langasek wrote: Now you've reimplemented bugzilla, congratulations; and it's still inferior to reportbug because the website can't automatically gather information about the package status on your system when you submit a bug. I think with ActiveX we can get pretty far. Anyway, I agree on the submitting, but for manipulating bug status, a web interface can be in some ways and for some people be an productivity improvement. I might even be interested in mentoring someone who's interested in working on that, provided that this potential GSoC student's ideas on the subject are not too far away from what I have in mind. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xlockmore 1:5.22-1.2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 17 Jan 2007 01:49:41 +0100 Source: xlockmore Binary: xlockmore xlockmore-gl Architecture: source i386 Version: 1:5.22-1.2 Distribution: unstable Urgency: high Maintainer: Michael Stone [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: xlockmore - Lock X11 display until password is entered. xlockmore-gl - Lock X11 display until password is entered -- GL version Changes: xlockmore (1:5.22-1.2) unstable; urgency=high . * Non-Maintainer Upload to address RC bug * Add conflicts on libpam-opie and libpam-p11, mitigating a potential security issue (addressing: #318123, #399003) Files: a5a3e268e35ac4a0f08dc02a475b850a 760 x11 optional xlockmore_5.22-1.2.dsc c5d3ed44ee124dae9aad1c16c3ca0142 13285 x11 optional xlockmore_5.22-1.2.diff.gz 4cc641875047f7597cd0e5745fa4b445 1078324 x11 optional xlockmore-gl_5.22-1.2_i386.deb 234b30bc88fc6a18810ea87c449da3de 606226 x11 extra xlockmore_5.22-1.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFrXhMl2uISwgTVp8RAq0sAJ0almohSdg5zrZ3Lto0ovzdonmuRACdEB1z El+xM4Xph9hSq917UrTT0GU= =/0wI -END PGP SIGNATURE- Accepted: xlockmore-gl_5.22-1.2_i386.deb to pool/main/x/xlockmore/xlockmore-gl_5.22-1.2_i386.deb xlockmore_5.22-1.2.diff.gz to pool/main/x/xlockmore/xlockmore_5.22-1.2.diff.gz xlockmore_5.22-1.2.dsc to pool/main/x/xlockmore/xlockmore_5.22-1.2.dsc xlockmore_5.22-1.2_i386.deb to pool/main/x/xlockmore/xlockmore_5.22-1.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.3
On Fri, Dec 22, 2006 at 12:38:05AM +0100, Matthias Klose wrote: An explicitely stated goal of the release team was to reduce the number of supported python versions for the next stable release. We did include three python versions for sarge (2.[123]). Actually, four: 2.4 is also in sarge (maintained by you). To reduce that count we do have to drop 2.3 (prefering 2.5 over 2.3). The count is already reduced by one, but I agree it'd be nice to drop one more version from etch when the opportunity is there. At the moment though, that'd still require python-defaults to migrate, along with packages like abiword and gnucash. I'm disinclined to remove python2.3 from unstable just yet, because that might block a new revision of (for example) abiword coming into etch via unstable. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apache2 2.2.3-1~exp.r170 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 Aug 2006 16:17:33 +0200 Source: apache2 Binary: apache2-utils apache2-prefork-dev apache2 apache2-mpm-prefork apache2-doc apache2-mpm-event apache2-mpm-worker apache2-threaded-dev apache2-common apache2-mpm-perchild Architecture: source all i386 Version: 2.2.3-1~exp.r170 Distribution: experimental Urgency: low Maintainer: Debian Apache Maintainers debian-apache@lists.debian.org Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: apache2- Next generation, scalable, extendable web server apache2-common - Next generation, scalable, extendable web server apache2-doc - documentation for apache2 apache2-mpm-event - Event driven model for Apache HTTPD 2.1 apache2-mpm-perchild - Transitional package - please remove apache2-mpm-prefork - Traditional model for Apache HTTPD 2.1 apache2-mpm-worker - High speed threaded model for Apache HTTPD 2.1 apache2-prefork-dev - development headers for apache2 apache2-threaded-dev - development headers for apache2 apache2-utils - utility programs for webservers Closes: 236193 238586 241223 273929 285337 337817 340538 340955 341460 343467 344072 348189 353443 368497 379015 Changes: apache2 (2.2.3-1~exp.r170) experimental; urgency=low . [ Jeroen van Wolffelaar ] * Staging upload to experimental of subversion revision r170 . [ Thom May, Tollef Fog Heen, Fabio M. Di Nitto and Adam Conrad ] * New Upstream Release. Closes: #344072 http://httpd.apache.org/docs/2.2/new_features_2_2.html has a list of new features and changes. - Fixes LFS support. Closes: #341460, #285337, #241223 - Fixes off-by-one error in mod_rewrite ldap schema handling (CVE-2006-3747) - Fixes XSS issue in mod_imap/mod_imagemap (CVE-2005-3352). Closes: #343467. - mpm_perchild no longer exists, so closing bugs for perchild. Closes: #236193, #238586 - Fixes PHP POST with SSLVerifyClient. Closes: 353443 * Build-depend on lsb-release and pick up the branding from there. * Build-depend on apr-util 1.0 which is now in a separate source package. * Mangle the Debian layout to be more FHS compatible * No longer build-conflict with libgdbm-dev * Use external PCRE * Make apache2-utils stop providing apache2-utils. Also make it stop conflicting with itself. * Rename default site from default-site to just default. * Try to migrate modules which used to be built-in:, alias, mime, authz_host, autoindex, dir, env, negotiation, setenvif, status. * Mod imap has been renamed to imagemap, ditto for auth_ldap = authnz_ldap. Cope with that in postinst. * Stop globbing in apache2.conf. Closes: #337817, #340955, #348189, #379015, #368497 * Don't install CHANGES into the apache2 package. It's just a metapackage. * Add rudimentary rdeps handling to a2dismod. Closes: #273929 * Stop providing apache-utils. * Cope with /var/run and /var/lock on tmpfs. * Remove all subdirs in srclib as we are using external libraries for those anyway. Also remove test/zb.c. Closes: 340538 * Make ssl.conf not block on /dev/random, but rather use /dev/urandom. * Make apache2-common depend on lsb-base, thanks to Gleb Arshinov Files: 45b11ad4ca823b957b9d8bbb8df800a0 1097 web optional apache2_2.2.3-1~exp.r170.dsc f72ffb176e2dc7b322be16508c09f63c 6342475 web optional apache2_2.2.3.orig.tar.gz 1bf636424322000f72e03550a0bed367 66158 web optional apache2_2.2.3-1~exp.r170.diff.gz 8ccb6b58913b94f15bab59293d3a4c16 902646 web optional apache2-common_2.2.3-1~exp.r170_i386.deb b241f06fb9dfe091594bb4cf44270e55 418254 web optional apache2-mpm-worker_2.2.3-1~exp.r170_i386.deb ee68b4d592484cd5b51b27763a1d171d 414078 web optional apache2-mpm-prefork_2.2.3-1~exp.r170_i386.deb c47cdc5634e71e22fc3c95d007396f10 418592 web optional apache2-mpm-event_2.2.3-1~exp.r170_i386.deb d12b9c32988a5536a3b7bf2b0a0ae623 335904 web optional apache2-utils_2.2.3-1~exp.r170_i386.deb 56786918524ad1358d3385657e94bb6c 400930 devel optional apache2-prefork-dev_2.2.3-1~exp.r170_i386.deb 19c2112739452d5ec235253f95d68049 401552 devel optional apache2-threaded-dev_2.2.3-1~exp.r170_i386.deb 7653dad9593b624ee7f6f8c34ab6d1c9 269588 web optional apache2-mpm-perchild_2.2.3-1~exp.r170_all.deb f911370b4f059eb32b379c23aee283f8 36190 web optional apache2_2.2.3-1~exp.r170_all.deb 0c3513c1beb88ffe8e1befc8c993962f 2398138 doc optional apache2-doc_2.2.3-1~exp.r170_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFE4edHl2uISwgTVp8RAp5CAJ41K4n3yAuZPetFc3sVWRXkriR2YQCfbz9T 5CF91F/2NC/dfamYc5g6kiY= =ODdi -END PGP SIGNATURE- Accepted: apache2-common_2.2.3-1~exp.r170_i386.deb to pool/main/a/apache2/apache2-common_2.2.3-1~exp.r170_i386.deb apache2-doc_2.2.3-1~exp.r170_all.deb to pool/main/a/apache2/apache2-doc_2.2.3-1~exp.r170_all.deb
Accepted kaffe 2:1.1.7-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 16 Aug 2006 03:25:31 +0200
Source: kaffe
Binary: kaffe-dev kaffe-common kaffe-pthreads kaffe-doc kaffe jikes-kaffe
kaffe-jthreads
Architecture: source all i386
Version: 2:1.1.7-4
Distribution: unstable
Urgency: low
Maintainer: Debian Java Maintainers
pkg-java-maintainers@lists.alioth.debian.org
Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED]
Description:
jikes-kaffe - Wrapper for jikes using Kaffe classes
kaffe - A JVM to run Java bytecode
kaffe-common - Files shared between all Kaffe VM versions
kaffe-dev - Header files and other resources for building against Kaffe
kaffe-doc - Documentation for the Kaffe VM
kaffe-jthreads - A green threads enabled version of the Kaffe VM
kaffe-pthreads - A POSIX threads enabled version of the Kaffe VM
Closes: 369877 374689 376336
Changes:
kaffe (2:1.1.7-4) unstable; urgency=low
.
* Use default gcc again for ia64
* Added 04_gcc4.1_amd64.patch: patch by Kurt Roeckx [EMAIL PROTECTED] to
fix
kaffe with gcc-4.1 on amd64 (Closes: #374689, might also fix: #375835):
+ kaffe/kaffevm/systems/unix-{p,j}threads/signal.c: Add more volatile
modifiers to remove optimizations.
* Added 05_gcc4.1_x86.patch: patch by Dalibor Topic [EMAIL PROTECTED] to
fix kaffe for gcc 4.1 (Closes: #376336):
+ config/i386/jit.h (FIRSTFRAME): Don't use
__builtin_frame_address, as that behaves differently
under -O0 and -O1 under gcc 4.1.x. Use a small bit
of assembler instead.
+ configure.ac: Ensure that -fno-strict-aliasing and
-fno-omit-frame-pointer are set for gcc.
* Added 06_atomic_ia64.patch: Fix compilation on ia64 by updating atomic.h to
glibc 2.4.0 version, thanks to Dalibor Topic [EMAIL PROTECTED] for the
fix, and thanks to Bill Allombert for reporting (Closes: #369877)
Files:
a14ec75a0eb3df355384988470b3e24c 1351 interpreters optional kaffe_1.1.7-4.dsc
9e539dfa7c868219c3f40ed78ddf0d08 39733 interpreters optional
kaffe_1.1.7-4.diff.gz
ddd3f51aa7090dccac619d790553da3c 85452 interpreters optional
kaffe_1.1.7-4_all.deb
fbef8c55c920b1fbf7c943d3cc82dc53 8006382 interpreters optional
kaffe-common_1.1.7-4_all.deb
c681d91a38b8534a34eeca614b312889 100914 interpreters optional
kaffe-dev_1.1.7-4_all.deb
80c4ab98c797b08248d7211170c58b3d 83830 interpreters optional
jikes-kaffe_1.1.7-4_all.deb
9c208f7b39b49c6580efce9decfbf219 171488 interpreters optional
kaffe-doc_1.1.7-4_all.deb
b4a45eca728efaa0468a1670a975a6e6 613206 interpreters optional
kaffe-jthreads_1.1.7-4_i386.deb
a8c4dc1fd7860ed929fd2972e26645d4 665730 interpreters optional
kaffe-pthreads_1.1.7-4_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED]
iD8DBQFE4oIvl2uISwgTVp8RArQWAJ90AUT8DtNQZjca0WlW3ucQ365hIwCgtXzD
HFk22Bzdh5EAu0t86KOblaw=
=gUTB
-END PGP SIGNATURE-
Accepted:
jikes-kaffe_1.1.7-4_all.deb
to pool/main/k/kaffe/jikes-kaffe_1.1.7-4_all.deb
kaffe-common_1.1.7-4_all.deb
to pool/main/k/kaffe/kaffe-common_1.1.7-4_all.deb
kaffe-dev_1.1.7-4_all.deb
to pool/main/k/kaffe/kaffe-dev_1.1.7-4_all.deb
kaffe-doc_1.1.7-4_all.deb
to pool/main/k/kaffe/kaffe-doc_1.1.7-4_all.deb
kaffe-jthreads_1.1.7-4_i386.deb
to pool/main/k/kaffe/kaffe-jthreads_1.1.7-4_i386.deb
kaffe-pthreads_1.1.7-4_i386.deb
to pool/main/k/kaffe/kaffe-pthreads_1.1.7-4_i386.deb
kaffe_1.1.7-4.diff.gz
to pool/main/k/kaffe/kaffe_1.1.7-4.diff.gz
kaffe_1.1.7-4.dsc
to pool/main/k/kaffe/kaffe_1.1.7-4.dsc
kaffe_1.1.7-4_all.deb
to pool/main/k/kaffe/kaffe_1.1.7-4_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another weird tar issue (100 character filenames)
On Tue, Jun 27, 2006 at 09:07:03AM +0100, Roger Leigh wrote: Russ Allbery [EMAIL PROTECTED] writes: I just built new xml-security-c packages to fix the current FTBFS bug, and lintian returned the following error message: E: libxml-security-c-doc: deb-created-with-broken-tar file: /usr/share/doc/libxml-security-c-doc/c/apiDocs/winutils_2XSECBinHTTPURIInputStream_8hpp-source.html N: N: The binary package was created with a broken version of tar. Some N: versions of tar contain a bug, which make the resulting .deb broken. N: On unpack, some filenames are going to be corrupted. N: N: This package was build with such a version of tar, and the mentioned N: filename is corrupted. Refer to Debian bug #230910 for more N: information, or simply update your tar-version and rebuild. (along with several other files). These filenames are indeed exactly 100 characters long, as mentioned in the referenced bug. The bug, however, indicates that this may not have really been a bug in tar but rather was a bug in dpkg with its inability to handle filenames that were exactly 100 characters (apparently one isn't supposed to nul-terminate in that case). It sounds like a bug that dpkg is using the old v7 tar format which had that 99 char limitation.s Actually dpkg could and can deal fine with long filenames, dpkg just had(?) a bug that a weird way of storing exactly-100-character-long filenames were not extracted properly. At some point tar created such tar archives, and dpkg went haywire on resulting .debs. It looks like this issue returned, the question is whether the bug in dpkg was fixed in sarge or not, since by now woody's version of dpkg doesn't really matter that much anymore. But on the other hand, according to the 'be strict in what you send, liberal in what you accept' mantra, it makes sense for tar to not create tarfiles which in the past have caused issues for certain programs while there's a perfectly fine way to create tarfiles which cannot trigger such bugs. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cgiirc Hijacking
On Wed, Jun 21, 2006 at 08:07:28AM +0200, Mario 'BitKoenig' Holbe wrote: Joe Smith [EMAIL PROTECTED] wrote: As I understand it, there is no good reason to have s.d.o in my sources list, as the packages in there are for sarge, and may not be compatible with the current sid ABI. This is nonsense. If this should really be the way you understand it, please ask yourself why a package's version on s.d.o which overrides a version in unstable (i.e. the version on s.d.o is bigger than the version in unstable) should ever have a less compatible ABI than the (smaller) version in unstable. You should not mix suites (releases) in your sources.list generally, espcially not stable with testing/unstable. Security.d.o for stable might have packages that are no longer present in testing/unstable, which would make it undesirable to install the security.d.o versions, also, if there's something really worthwhile in security.d.o for stable, that should also be made available in appropriate form for testing/unstable. It's the job of the maintainer(s) to oversee this, and ensure that it happens. There is no reason a user should (need to) add stable security for his/her unstable machine. Elsewhere in this thread there's already discussion about the technical details why it didn't happen yet in this case and how it should happen, I'm not repeating that discussion here. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cgiirc Hijacking
On Tue, Jun 20, 2006 at 10:45:27PM +0200, Thijs Kinkhorst wrote: On Tue, 2006-06-20 at 13:18 -0300, Margarita Manterola wrote: Who told you that the sarge fix would propagate? Packages don't *propagate* from stable. If you want a package that was uploaded to stable to go to unstable, an upload is needed. You should have asked for a sponsor. Well, at least this used to work in the past. If the version in stable was greater than that in unstable or testing, that version would also propagate there. This is not only convenient for security updates to packages with the same version in stable as in unstable, but also makes sure the condition stable = testing = unstable remains valid. Appearently this didn't happen here, but as far as I understand it, that's a bug. The package isn't in sarge/stable on ftp-master/all mirrors, only on security.d.o, that's why. Not a bug, but a 'feature' -- the package hasn't been approved yet for stable[1], so neither propagated to testing/unstable. --Jeroen [1] Due to infractructure not being ready yet, mostly -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with standards version lintian
On Sun, Jun 04, 2006 at 06:38:40PM +0200, Nico Golde wrote: Hi, one of my packages hast the lintian warning that the standards version it uses it newer. Yacpi has standards version 3.7.2 and at the time of uploading yacpi this version of the debian-policy was released. http://packages.qa.debian.org/d/debian-policy.html shows 2006-05-04 as date for debian-policy and http://packages.qa.debian.org/y/yacpi.html shows 2006-05-25 as date for yacpi. http://lintian.debian.org/reports/mNico_Golde.html#yacpi Shows W: yacpi source: newer-standards-version 3.7.2 If I look at http://lintian.debian.org/reports/Tnewer-standards-version.html it seems that there is a huge set of packages which have this problem. What is the problem here? lintian.debian.org is running an older lintian version not yet aware of the newer policy. This is to be resolved as soon as possible, but might take a bit longer still. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[draft] Re: Sun Java available from non-free
, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from (i) the use or distribution of your Operating System, or any part thereof, in any manner, or (ii) your use or distribution of the Software in violation of the terms of this Agreement or applicable law. I'm really not entirely sure what this clause is getting at, but it seems that the intention is that Debian needs to indemnify Sun for any litigation resulting by users of the package of Sun's JDK which Debian has distributed, even if Sun is grossly negligent.[2] I'm not an expert at all on indemnification, that's to the best of my knowledge quite US-centric. Pass on this one. 4. COMPATIBILITY. If you exercise the license in Section 2, and Sun or a licensee of the Software (under section 4(b)) notifies you that there are compatibility issues [...] caused by the interaction of the Software with your Operating System, then within ninety (90) days you must either: (a) modify the Operating System in a way that resolves the compatibility issue (as determined by Sun) and make a patch or replacement version available [...] Oh, right... so if the Sun JDK is buggy, we have to modify our operating system to make it unbuggy in some way that makes Sun happy. Makes sense to me. Or option (b), remove the Sun packages. If we were to face this situation, there's always this option if there isn't a better one. We'll definitely not let us be blackmailed into doing changes to Debian that we do not want to make -- I'm happy that we can provide these packages as a service to our users, but not all at the cost of being forced into making other changes against our will. Speaking realistically, such a move of Sun would be spectacularly bad PR for them esp. considering their statements about future Java licensing efforts they have committed to. 14. MISCELLANEOUS. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. A yeah! Now everyone gets to suffer! The infamous choice of venue type clause. As I understand it of doubtful legal applicability and consequences, but I don't know much about it, so pass. It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. Just in case you had any questions about the total uselessness of the license FAQ, the above clause should put that to rest. I'm not familiar with US law, but I think this one is very hard if not impossible to hold up in court. Anyway, this clause is not relevant indeed if you look at the license on its own merits. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
On Thu, May 18, 2006 at 05:27:23PM -0300, Margarita Manterola wrote: During some tests I've performed, I've found that making the init scripts run with dash as default shell instead of bash makes the boot time a 10% faster (6 seconds in a 60 second boot). To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash 2. Change #!/bin/sh for #!/bin/dash in the scripts There are arguments for and against both of them. I'm summarizing what I've gathered during Debconf, but I do want to hear other people's opinions. Option (1) implies making dash base and Essential: yes (currently dash is optional), and that would imply that until no Essential package depends on bash, we would have two shells in Essential. Moving bash out of Essential would probably imply two release cycles (i.e. it couldn't be out of Essential until etch+2). This option also might imply some extra bugs, but it's believed that not so many, since there are already quite a number of people with /bin/sh - /bin/dash, and they do file bugs when bashisms appear. It's also influencing the whole system, including any #!/bin/sh scripts that anyone might have installed locally. It's very easy to make a bashism that then will fail to work with /bin/sh, I think the risk of breaking things of users is way too high for me to consider this. Bash is a very decent all-round shell. Option (2), on the other hand, implies that package maintainers have to manually edit init scripts (or apply patches) and add the correct dependency. This would mean quite a number of uploads, that might take quite a lot of time. initscripts are only a very small subset of shellscripts anywhere, and especially a controllable and overseeable subset. Despite the fact that it requires changes to all packages having init scripts, I think this is worth the effort. It ensures that these tweaks for startup improvements are really confined to the init scripts, and also, bugs will be found very quickly this way, because everyone will be using dash for those scripts then. Of course, all the packages in question must then depend on dash, but that's not really a problem IMHO. The only problem I do see is that dash currently asks a question upon installation, which I think it should simply stop doing so, administrators who want this change can really do update-alternatives themselves, the default is IMHO sane (keep bash as /bin/sh). For most applications the speed improvement is neglectable anyway, and IMHO we should only optimise where a speed gain is really significantly present (as in this case). So, mainly the question that I want to ask of the rest of the Debian community is if there are more arguments for or against these options, and what do you think would be the best route on implementing this. Afaik, there isn't really a widely recognised decision of any sort on this. I think what should happen now is for you to publish on this list your benchmark results about the speed gain w.r.t. dash, and consequently getting policy changed to get it to state that init scripts should use #!/bin/dash. Then lintian can gain a warning about scripts not complying, and bugs with patches can be filed on all relevant packages, and eventually NMUd where needed (but I don't think it'll be often needed once the policy change is accepted by the policy making process). Your alternative (1) proposal is also more complicated to get done, and does not allow users to have bash as /bin/sh, but still the bootup time improvements. Without this possibility, I'm myself at least not in favour of going this way at all. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The necessity of running depmod at boot time
On Thu, May 18, 2006 at 07:21:33PM -0300, Margarita Manterola wrote: Continuing on the goal of optimizing boot time, quite a number of seconds (specially in old machines) can be saved by not running depmod at boot time. Currently it is run by these packages' postinst: * [long list] It looks like it's quite safe to stop running depmod during boot time, since both new kernels and new modules run it at install time. If there are modules that don't run depmod on installation, they should do it. I think one of the issues here is that it depends on what kernel you currently use, and iirc there can be a situation where one does not want to run depmod at installation time, or when that might give wrong results. What I think would be best is to have every packages that now requires running depmod at boot time, will touch a file in /lib/modules/kernel-api when it has changed the kernel (or modules) significantly so that it is needed to be run, and at boot time only run depmod if that touched file exists (and have the file removed after having run depmod succesfully). This way, depmod at boot is only run after changes in kernel or modules once for each given kernel API that's booted. If the package code in each package for this (for the bit to conditionally run depmod at installation time too) is not trivial, it might be worth having a bit about this in some dh_* script, so that the code in question is only written once. I'm not sure here though, I don't think it's needed as the majority of the code can be in the package providing depmod. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why not making /sbin/sendmail a mantadory component for mail operation?
On Wed, May 17, 2006 at 03:16:35PM -0500, Ron Johnson wrote: Ignorance, fear of becoming an open relay and years of learning will have to be overcome before Most Users will config Debian to use a relayhost. It's not very difficult to have exim, the default MTA, simply not launch an smtp listener. If it's only running queues and providing the /usr/sbin/sendmail interface, you cannot possibly be a mail relay, since nothing even listens on port 25. The configuration file to edit for this is /etc/default/exim4 --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted usbmount 0.0.14-0.1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 30 Apr 2006 23:45:57 + Source: usbmount Binary: usbmount Architecture: source all Version: 0.0.14-0.1 Distribution: unstable Urgency: low Maintainer: Martin Dickopp [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: usbmount - automatically mount and unmount USB mass storage devices Closes: 361351 365225 Changes: usbmount (0.0.14-0.1) unstable; urgency=low . * Non-Maintainer Upload * Change path of vol_id of udev to the new location in /lib/udev. Thanks to Eric Evans for the patch (Closes: #361351) - Minimum udev dependency now 0.084-2, first version to ship vol_id in that location * Fix udev rule syntax, patch by Eric Evans (Closes: #365225) Files: e75cf4de2189f2271fea17ca6a034b51 571 admin extra usbmount_0.0.14-0.1.dsc 2905ac6024bc2a6e2d9e863d8307119b 8607 admin extra usbmount_0.0.14-0.1.tar.gz 1b74998193fe32a6e05eca5232e605db 10494 admin extra usbmount_0.0.14-0.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEVVTnl2uISwgTVp8RAneUAKCqvH98Ky2i+qgLJEcg4TEOd6640QCdH4Nj mnX9vIot88FfIDHeaqfMkYw= =6ScG -END PGP SIGNATURE- Accepted: usbmount_0.0.14-0.1.dsc to pool/main/u/usbmount/usbmount_0.0.14-0.1.dsc usbmount_0.0.14-0.1.tar.gz to pool/main/u/usbmount/usbmount_0.0.14-0.1.tar.gz usbmount_0.0.14-0.1_all.deb to pool/main/u/usbmount/usbmount_0.0.14-0.1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Missing firefox source and unofficial debian-amd64 breakage
On Sun, Apr 23, 2006 at 09:57:32PM +0200, Mike Hommey wrote: On Sun, Apr 23, 2006 at 09:49:29PM +0200, Mike Hommey [EMAIL PROTECTED] wrote: On Sun, Apr 23, 2006 at 02:46:47PM +0200, Goswin von Brederlow [EMAIL PROTECTED] wrote: Hi, as some might have noticed the Debian archive is missing /debian/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.2.orig.tar.gz The missing file has a sideeffect for the debian-amd64 archive because the sync-script detects an inconsistency and stops. Since it goes alphabeticaly and package after firefox won't be updated to the latest version anymore. From my irc backlog this looks like a DAK screwup and not the maintainers fault and is probably being investigated already. But that doesn't help the rest of the world in the short run. AFAIK, the breakage is due to the fact that 1.5.dfsg+1.5.0.2-1 is sitting in the NEW queue. I guess Eric didn't make a sourceful upload for 1.5.dfsg+1.5.0.2-2, thus the missing orig.tar.gz file. Better than that. Eric DID a sourceful upload which got rejected because the .orig.tar.gz was in the NEW queue. Then he uploaded without the source and that's what got into the archive. Now, 1.5.dfsg+1.5.0.2-1 has been rejected, without any reason given. There should have been a reason in the reject mail, and even if not, the footer asks to reply if you don't understand. Anyway, the reason was that currently 1.5.dfsg+1.5.0.2-2 is in unstable, and 1.5.dfsg+1.5.0.2-1 is smaller, so cannot be anything else than rejected. You can of course re-upload to NEW with a higher version number. Anyway, the .orig.tar.gz is now restored and should be on your local mirror around nowish. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Missing firefox source and unofficial debian-amd64 breakage
On Sun, Apr 23, 2006 at 07:10:44PM -0400, Eric Dorland wrote: Should I file a bug somewhere about this? Clearly I hit a corner case that dak doesn't handle quite right. About the empty mail, eh, I see #300599, seems I noticed it before. Amazing how fast time goes though -- guess I really should dedicate some time on hacking on dak, for example during DebCamp. I should follow Joey Hess' advice :)[1], after all, I have 'only' 183 outstanding bugs. About the .orig.tar.gz, it's related to #232730, but subtly different, the root cause is that .orig.tar.gz handling in combination with queues (like the NEW queue) is inadequate, and the current design has way too many corner cases. There are plans to overhaul the queue handling, but it's a bit a long-term project, unfortunately. And the current setup works mostly, except there'll probably always be some corner cases left, esp. with also new features getting implemented (like the security queue overhaul, the proposed-updates queue stuff, etc). You can file a bug on 'dak', but the inadequate .orig.tar.gz handling is a well known issue, so it's not really needed either. --Jeroen [1] http://kitenet.net/~joey/blog/entry/check_your_bugs_day.html -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tagcoll 1.6.2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 20 Apr 2006 15:35:10 +0200 Source: tagcoll Binary: libtagcoll-dev tagcoll Architecture: source i386 Version: 1.6.2-1 Distribution: unstable Urgency: low Maintainer: Enrico Zini [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: libtagcoll-dev - Functions used to manipulate tagged collections (development vers tagcoll- Commandline tool to perform operations on tagged collections Closes: 358493 Changes: tagcoll (1.6.2-1) unstable; urgency=low . * New upstream * Fix oversight in testsuite causing tests to wrongly fail (Closes: #358493) * Added myself to uploaders Files: 9b6942378c6d230e4b7a505c2199a265 814 libdevel optional tagcoll_1.6.2-1.dsc 59101c19d9b9b6e8d6f6166c43ed2d6e 812066 libdevel optional tagcoll_1.6.2.orig.tar.gz ed06404d1e60dfa0577cb634aacb91d4 4378 libdevel optional tagcoll_1.6.2-1.diff.gz ec3a48f6805db8ef85538f0e5d6f098a 856894 misc optional tagcoll_1.6.2-1_i386.deb 1923a23a2df06f15bfde915502dcd1aa 2426060 libdevel optional libtagcoll-dev_1.6.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFER6Yel2uISwgTVp8RAu2vAJ9/CPrFArZlTc8qytyUPsqJygXwQgCfWSa5 NHvKIv2NRs6w3tVLsb5B5Ig= =JSmM -END PGP SIGNATURE- Accepted: libtagcoll-dev_1.6.2-1_i386.deb to pool/main/t/tagcoll/libtagcoll-dev_1.6.2-1_i386.deb tagcoll_1.6.2-1.diff.gz to pool/main/t/tagcoll/tagcoll_1.6.2-1.diff.gz tagcoll_1.6.2-1.dsc to pool/main/t/tagcoll/tagcoll_1.6.2-1.dsc tagcoll_1.6.2-1_i386.deb to pool/main/t/tagcoll/tagcoll_1.6.2-1_i386.deb tagcoll_1.6.2.orig.tar.gz to pool/main/t/tagcoll/tagcoll_1.6.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upload getting lost
On Wed, Apr 12, 2006 at 01:10:39AM +0200, Lionel Elie Mamane wrote: Hi, I'm trying to upload a new mailman package, but this is failing utterly. Could someone please help me? Thanks in advance. I'm uploading the exact packages at http://people.debian.org/~lmamane/mailman/ with dput to the anonymous queue on ftp-master. The upload goes well, I see them if I ftp in at ftp-master, and they disappear after the next debianqueud run. So far, so good. But normally, when a package disappears from the anonymous upload queue, I get an email about it, and it appears on http://incoming.debian.org . Not this time, I get nothing. The upload seems to just vanish. I've tried uploading again, no result. You can mail [EMAIL PROTECTED] for inquiries about upload issues, -devel isn't read by all ftpmaster@ people, and not a reliable way of contact. Could someone with a better understanding than me (or an access to the logs) check this out, please? This upload fixes a bug of severity critical (and also a security problem), so it is quite urgent / important. Rejected: !!WARNING!! tainted signature filename: 'mailman_2.1.7:2.1.8rc1-1_sparc.changes'. I've got no idea (yet) what this means, but looks like a funky signature. Since this is the first time I see this, I guess the problem is on your end. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When to drop/split/summ changelog files
On Mon, Mar 27, 2006 at 08:13:24PM +0200, Adrian von Bidder wrote: Rather arbitrarily, just feels more or less safe: cut everything from before oldstable release. Based on the assumption that oldstable - stable updates occur more or less over the whole stable+1 development circle. So currently, I'd cut everything that pre-dates woody release - probably nobody will do a potato - woody upgrade. I think one should keep the whole changelog. Most of them won't be really big anyway, and take a neglectable amount of diskspace. It can be relevant for other reasons that seeing differences between two certain versions: To see why (or that) a certain change was made, perhaps in response to which bug. This is what I use changelogs for mostly, only in a small minority of cases I really want to know when a certain change was made (and even then, it matter whether you can confirm the change was made $long_ago, or perhaps just not documented and might be made unmentioned later on). I don't see why one would drop such historical information, even if only interesting for just that -- historical information. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lintian 1.23.16 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 26 Mar 2006 15:38:37 +0200
Source: lintian
Binary: lintian
Architecture: source all
Version: 1.23.16
Distribution: unstable
Urgency: low
Maintainer: Debian Lintian Maintainers [EMAIL PROTECTED]
Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED]
Description:
lintian- Debian package checker
Closes: 249435 322288 344269 344421 344998 347510 349272 349273 349614 349616
349792 350228 350653 351324 351624 352606 353294 353770 354890 357541 358523
Changes:
lintian (1.23.16) unstable; urgency=low
.
The What's this Russ guy up to? release
.
* checks/binaries{.desc,}:
+ [RA] Add a check for the new Invalid operation error from
objdump -T. Skip shared-lib-without-dependency-information for
files in /usr/lib/debug.
* checks/changelog-file:
+ [FL] Add line number to output of wrong-bug-number-in-closes.
Inspired by #349761 from Steinar H. Gunderson.
* checks/common_data.pm:
+ [FL] Add armeb to %non_standard_archs as requested by
Martin Michlmayr. (Closes: #350653)
* checks/debconf:
+ [RA] Packages that depend on dbconfig-common are allowed to have
config scripts without templates or an explicit debconf dependency.
Reported by Marcus Better. (Closes: #344421)
* checks/debconf.desc:
+ [RA] Clarify the necessary dependencies for packages using SETTITLE.
(Closes: #349616)
* checks/debhelper:
+ [RA] Recognize setting DH_COMPAT with := in addition to = in
debian/rules. (Closes: #349272)
+ [RA] CDBS sets DH_COMPAT to 4 but doesn't export it. It does create
debian/compat with that value if none was present. Reflect this
behavior to avoid spurious compat level warnings when using CDBS.
Based on a patch by Jay Berkenbilt. (Closes: #350228)
* checks/fields:
+ [RA] Allow a quilt build-dependency for arch-independent packages if
the quilt makefile rules are included. (Closes: #349273)
+ [RA] If clean depends on a rule that calls dh_clean rather than
calling it directly, still allow debhelper in Build-Depends for
arch-independent packages. Reported by Michael Stilkerich.
+ [JvW] Commented that Uploaders no longer will hit the multiline field
issue, updated testsuite accordingly
* checks/manpages:
+ [FL] Ignore more warnings (cannot adjust line, can't break
line) in non-English manpages. (Closes: #349792)
+ [RA] cd into the parent directory before checking man pages with man
so that .so inclusions are processed correctly. Based on a patch by
Nicolas François. (Closes: #349614)
* checks/menu-format:
+ [RA] Look for binaries in /usr/X11R6/bin, not /usr/bin/X11, per
Policy 11.8.7. Thanks, Matej Vela. (Closes: #354890)
* checks/menu-format.desc:
+ [RA] Use menu manual rather than menu for references to more
clearly distinguish from the Debian Menu Policy. (Closes: #347510)
* checks/po-debconf:
+ [RA] If there are template files in debian, assume the package uses
debconf; don't require a dependency or config script. Patch by
Thomas Huriaux. (Closes: #353294)
* checks/scripts:
+ [RA] Allow /tmp in variable settings. It's likely to be a false
positive. Reported by Frank Küster. (Closes: #344998)
+ [RA] Make the syntax checking of shell scripts more robust against
filenames containing shell metacharacters. Reported by Michael
Stilkerich.
+ [RA] Add fish and expectk to the list of valid interpreters.
(Closes: #351624, #353770)
+ [RA] /usr/bin/tcl is provided by tclx8.3, not tcl. Reported by
James R. Van Zandt. (Closes: #351324)
+ [RA] Allow more variations on leading magic to invoke some
interpreter rather than then shell. Bypass the ELF magic check for
scripts using magic that relies on having no leading #! line.
Reported by Frank Küster. (Closes: #344269)
+ [JvW] Add check against package suffering from debhelper bug #337664,
per Joey Hess, which had broken error detection (Closes: #358523)
* checks/shared-libs:
+ [JvW] Fix postinst-must-call-ldconfig to also get emitted when there is
no postinst at all, instead of just one lacking a ldconfig call
+ [JvW] Implement checks for udeb: lines in shlibs files
(Closes: #357541)
+ [JvW] Consider also the soname version for shlibs checking, preventing
some bogus 'duplicate' warnings, and actually throw a warning when
soname version doesn't match
+ [JvW] Added error when udeb postinst calls ldconfig, that must never
happen (thanks to Frans Pop for noticing, see #203056)
.
* debian/{control,copyright}:
+ [RA] Add Russ Allbery to Uploaders and copyright.
+ [JvW] Version dpkg-dev requirement to = 1.13.17, for
unpack/unpack-srcpkg-l2
.
* frontends/lintian-info
Re: one binary package created by different source packages, will the old source package disappear?
On Mon, Mar 20, 2006 at 12:03:13PM +0100, Frank Küster wrote: Hi, assume the following scenario: - Source package foo creates binary packages libfoo1 and libfoo-dev - source package foo2 creates binary packages libfoo2 and libfoo2-dev Since both versions are API-compatible, libfoo2-dev is renamed to foo-dev, replacing the old binary package from source package foo. Will the complete source package foo have to disappear, or will foo and the binary package libfoo1 continue to be available? If foo2 didn't exist yet, you'd most likely want to start your transition by having a new 'foo' instead, creating libfoo2 and libfoo-dev. (ABI/SONAME change, but no API change, so -dev remains named the same). Transition can be done mostly/totally via binnmu's, and libfoo1 will be semi-automatically dropped. If foo2 already exists, I'd still go for that solution, but you'll then need to ask for foo2 removal via a bug to ftp.debian.org. Because there is API compatibility, I'm assuming here it makes not much sense to keep both libraries in at the same time. If you want to keep libfoo1 available (would need a somewhat decent reason, ideally), you'll need separate source package names (indeed foo2 then), and will need to make a new upload of 'foo' stopping to provide a -dev package. Otherwise, ít'll be impossible to do security uploads without making those changes at that time -- however, libfoo1 will remain available, even lacking such upload. N.B.: Such questions are easier to answer (less guessing needed w.r.t. missing information) given a real example. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: users getting confused between mailing lists and forums?
On Sat, Mar 18, 2006 at 12:13:44AM -0500, kamaraju kusumanchi wrote: I might be acting a bit paranoid here but I am starting to feel that users are getting confused between multiple forms of support available - forums.debian.net and other mailing lists such as debian-user for example. [...] This could be a real problem in the long run if the procedure is adopted by many. For example, a user searching the archives in forums.debian.net might not find the answer even though the question has already been address to... What do you think? I don't think it's a real problem. #debian and [EMAIL PROTECTED] are separate too, and dozens if not hundreds of LUG-lists are also all separate from [EMAIL PROTECTED] On both forums.d.n and lists.d.o, people are requested to use google first, and google indexes both the forums and the list archives. On forums.debian.net, people should be redirected to [EMAIL PROTECTED] when they don't get an answer there, because debian-user has more 'powerusers' than forums.debian.net. The audiences of both support resources are reasonably separate, because people tend to either swear by forums, or by mailinglists, and not both. For the vast majority of questions, that doesn't matter, because on both there are plenty of people able answer the those most common type of questions. This is about support questions, not about development -- which doesn't take place at forums.debian.net. If possible, please integrate mailing lists and forums and just keep one of them so that users for sure will know where to post their questions. I agree that both have some advantages over the other. But having just a single place to post question is much much easier than 'deciding where to post' or 'posting in multiple places'. I don't think it'd be a good idea to inflict forum posts automatically to the debian-user mailinglist, if only because of the real different way of asking questions. Brevity (and lack of information, at times) of forums questions is somewhere in between #debian IRC and [EMAIL PROTECTED], for starters. But also technically, there's a lot of issues. People should post at the place where they feel most comfortable with. --Jeroen forums.debian.net admin -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Regarding the NEW queue (Was: Re: NEW queue backing up again -- ftpmasters, any explanation or comment?)
On Mon, Mar 13, 2006 at 01:39:04AM +0100, Steinar H. Gunderson wrote: On Sun, Mar 12, 2006 at 06:53:08PM -0500, Nathanael Nerode wrote: It looks approximately as though nothing has been examined since a month ago. Perhaps the ftpmasters are busy with the mirror split? Different people working on NEW vs mirror split. On Mon, Mar 13, 2006 at 07:52:07AM +0100, Petter Reinholdtsen wrote: [Steinar H. Gunderson] Perhaps the ftpmasters are busy with the mirror split? Could be, but I believe I heard that most NEW processing is done by one of the assistants while the mirror split is done by someone else. I guess that one person got busy or demotivated. I suspect NEW processing in Debian is work for more than one person over time, and that more people should be involved. More people *are* involved, it's just that I haven't done much NEW until yesterday because Joerg was doing a good job and keeping up with it, that I preferred spending my time elsewhere, where there was more need. I'm now helping out some more with NEW. On Mon, Mar 13, 2006 at 10:38:38AM +0100, martin f krafft wrote: The mirror split is a complicated endeavour. From what I understood, the NEW queue was put on hold on purpose until the split is complete. That's not true. On Mon, Mar 13, 2006 at 08:57:10AM +0100, Thijs Kinkhorst wrote: On Mon, March 13, 2006 01:39, Steinar H. Gunderson wrote: Perhaps the ftpmasters are busy with the mirror split? I don't think it's useful to second-guess what they're doing, so my question to Nathanael: when did you post this question to them directly and what was their answer? Nobody mailed ftpmaster@ about the size of the NEW queue. -devel isn't a contact address for ftp-master, at least speaking for myself, mailinglists have a much lower priority than things like ftpmaster mail, and when backlogged with mail, I tend to skip parts too, if it's too high-traffic at times. On Mon, Mar 13, 2006 at 10:47:32AM +0100, Ondrej Sury wrote: I posted question about mozilla-thunderbird-locale-cs to [EMAIL PROTECTED]: On Fri, 2005-12-30 at 12:28 +0100, Ondrej Sury wrote: [...] No reply so far. I saw your mail, but didn't reply as I wasn't normally doing NEW. I see nobody replied to it, for which I apologize. I'm not aware of anything wrong with it, but will take a look when ftp-master is reachable again (there seem to be routing issues today). On Mon, Mar 13, 2006 at 12:20:38PM +0200, Lars Wirzenius wrote: ma, 2006-03-13 kello 08:57 +0100, Thijs Kinkhorst kirjoitti: I don't think it's useful to second-guess what they're doing, so my question to Nathanael: when did you post this question to them directly and what was their answer? Is there a reason why the question should be made in private? It seems as if only problems and annoyances end up on mailinglists, and *not* to [EMAIL PROTECTED] The don't specifically need to be made private, but I don't think it'd be too much to ask for questions to ftpmaster to be mailed to the our published contact address? How would you feel if people complained about lacking piuparts updates on -devel, stating it's unaccepteable and the maintainer should've been recruiting a co-maintainer, without that person ever having contacted you? That's, roughly, what happens with ftp-master often. We do our best to answer all inquiries, but are not perfect. However, of those issues coming to some mailinglist, more often than not there's not even an attempt to mail ftp-master first, or at all. It's a kind of self-reenforcing loop if people don't think mailing helps, but then not even try, and mail -devel instead, making people think even more that mailing ftpmaster@ is futile. I do think N.N. formulated the question in a needlessly accusatory tone, but I don't think -devel was the wrong place. Transparency and openness are good for the project. I agree transparency and openness are good things. I just disagree with the implication that mailing -devel _instead_ of ftpmaster@ is a good way to address an issue with ftpmaster. If you have an issue, or a question, ask (to ftpmaster@). If you don't get a response within 2 weeks or so, mail again. Feel free to inquire with myself (jvw) on IRC too. On Mon, Mar 13, 2006 at 12:27:36PM +0100, Thijs Kinkhorst wrote: I'm surpassed by reality, since we now know that the FTP-masters didn't bother to answer Ondrej's mail... you're probably right that it wouldn't have made a difference. That's quite leaping to conclusion. Ondrej's mail was inquiring about one specific package, not inquiring about the NEW backlog. There have been numerous mails since inquiring about specific packages, which did get a reply. This one apparantly just slipped. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
On Mon, Mar 13, 2006 at 02:49:18PM +0100, Frank Küster wrote: Martin Michlmayr [EMAIL PROTECTED] wrote: * Pierre Habouzit [EMAIL PROTECTED] [2006-03-13 11:22]: The mirror split is a complicated endeavour. From what I understood, the NEW queue was put on hold on purpose until the split is complete. and of course such a useless information has been kept silent. As seen on IRC [...]: That's still quite silent, since not everybody reads every Debian-related IRC. Wait, you want some (false!) rumours that have only shown up on IRC until Pierre's mail like a few hours ago, be debunked on d-d-a or so? The only prior mention I saw of this rumour, it was directly rebutted by Ganneff/Joerg Jaspert in the same channel. If you were not reading that specific Debian-related IRC channel at that time, you probably wouldn't have known that (again, false) rumour in the first place. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
On Mon, Mar 13, 2006 at 03:23:29PM +0100, Thomas Viehmann wrote: Martin Michlmayr wrote: 20:38 Ganneff the archive grow too fast too big. so i should not process NEW so fast to not grow much more in a short term. something like that more. Well, if that's the reason, are updates to existing source packages still allowed? I'd really like to fix my RC bugs and sync with upstream at the same time but the latter would involve so-version changes. This is not the reason for any backlog, although it does limit amount of NEW accepts per day, but there's still plenty of room in each day to do a lot of NEW. The bigger bottleneck is simply human processing time. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] volunteers?
On Thu, Mar 09, 2006 at 07:16:58PM +0100, Eduard Bloch wrote: * Florian Haas [Thu, Mar 09 2006, 06:31:42PM]: That is fine and dandy, but how do you want to adress the underlying problem of the work ? We need a mediator - an official delegate who is responsible for finding a solution for personal/communication problems. I think this is a DPL task[1], and I've committed to do it if elected. --Jeroen [1] http://www.debian.org/vote/2006/platforms/jeroen#mediator -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Debian Backup Server
On Tue, Mar 07, 2006 at 09:33:50AM +0100, Frank Küster wrote: Martin Schulze [EMAIL PROTECTED] wrote: Joey Hess wrote: Are there any plans to add svn.debian.org / alioth to this set? No. Alioth will have its own backup facility. But svn.debian.org is costa.debian.org, just that the access controls work via alioth. Anyway, do you know who's caring about backing up alioth, or about the state of its backuping? I'm backupping svn.debian.org, cvs.alioth.debian.org, arch.debian.org and lists.alioth.debian.org archives on a daily basis, with increased-interval history[1], since halfway April 2005 (along with many regular debian.org services which now probably largely superseded by the official backup server). I started those after having talked to DSA members in Vancouver, and the consequent (there was no relation to that, though!) disk mayhem on gluck. About the alioth backups, I did at least talk about this with Wichert, and I thought I mailed about it with the alioth admins too, but I definitely mailed about it with DSA (which incidently also includes Wichert on the email address I used). --Jeroen [1] Roughly 7 different backups, spanning a month. -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: acceptance of morse-2.1 in unstable
On Sun, Mar 05, 2006 at 07:42:12PM +0100, Joop PG4I wrote: I have uploaded morse-2.1 about 2 weeks ago. Nothing heard if it will get accepted or not. Wondering what is going on Is ftp-master overloaded? NEW queue is actually a heap, and your package simply didn't reach the top yet. Please hang on. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please reject to rule on the ndiswrapper question
On Tue, Feb 28, 2006 at 02:05:16PM +0100, Wouter Verhelst wrote: The correct way to proceed would seem to be a ruling by a body authorized to make authoritative interpretations of the Social Contract, or, failing that (since I believe we have no such body), a General Resolution. You (or whoever feels strongly about this) could also provide a motivation to ftpmaster@ why you believe so, and ask for reconsideration. Everybody, even the ftp-master team, can make mistakes, or be persuadated to change mind provided with a good argumentation. I also note that the only ftp-master team member that spoke up in this thread seems to be inclined to prefer contrib over main for this package. There was no mail at all to ftpmaster@ about this, nor a bugreport filed/reassigned to the ftp.debian.org pseudopackage. Shouldn't overruling of any sort only happen after talking to the involved parties failed to yield a satisfactionary response? C.f. Constitution 6.3.6: | Technical Committee makes decisions only as last resort. | | The Technical Committee does not make a technical decision until efforts | to resolve it via consensus have been tried and failed, unless it has | been asked to make a decision by the person or body who would normally | be responsible for it. Of course, this paragraph only applies if one assumes the (initial) authority to make the main vs contrib decision is with ftp-master, but I believe it is. --Jeroen Another FTP-Team member, who doesn't yet have an opinion on this matter, but hasn't been asked for one either -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#349064: ITP: macromedia-flash-installer -- installer for Macromedia Flash Plugin
On Mon, Jan 30, 2006 at 07:49:09PM +0100, Bart Martens wrote: So, one conclusion is clear : Nobody wants a second installer for the Macromedia Flash Plugin. Efforts should go to flashplugin-nonfree. Thanks for the comments leading to this consensus. Less clear to me is what now. The maintainer of flashplugin-nonfree seems to be busy with other things. Would an NMU be appropriate now ? Yes, if you're following the procedures, a NMU would be fine, as long as you're not doing things against the (expressed or reasonably deduceable) wishes of the maintainer. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Sat, Jan 28, 2006 at 07:18:24PM +0100, Wouter Verhelst wrote: On Sat, Jan 28, 2006 at 07:14:45PM +0100, Josselin Mouette wrote: Le samedi 28 janvier 2006 à 18:55 +0100, Wouter Verhelst a écrit : Because python and ruby have (...) I disagree. (...) This is only (...) maniacs. (...) is better, because (...) Hah. A language that does not require a specific coding style is better, because it allows me to work as is the most efficient for me. I think we should instead make 'whitespace' essential: Irregardless of your coding style, it looks the same to the eye, so has the best of both worlds. --Jeroen P.S.: Can we please not go this way? -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
On Thu, Jan 12, 2006 at 09:52:13PM +0100, Andreas Barth wrote: * David Nusinow ([EMAIL PROTECTED]) [060112 21:47]: On Thu, Jan 12, 2006 at 09:35:18PM +0100, Andreas Barth wrote: However, on the other hand feel free to create a common maintained packages team that adopts such packages :) Isn't that pretty much what the qa team does? Not really. All qa-maintained packages are up for adoption or removal and are only maintained at a if it breaks too bad. Well, that's current practice, but nobody is stopping anyone to give a little bit more care into QA packages... That said, I do believe that if a package is unpopular enough that nobody picks up maintaining it, even while it's orphaned, what the prospects of the package are, and how much use it has to prolong its life extraordinary. If you're sufficiently committed to a certain package, you can just as well adopt it after all. Also, I am wondering how much success such a 'common maintained packages team' would have while there is a shortage of people caring for general QA of orphaned packages or just on the archive at all. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Wed, Jan 11, 2006 at 11:15:35AM +0100, Josselin Mouette wrote: Le mercredi 11 janvier 2006 à 10:10 +0100, Henning Glawe a écrit : a) explicitely forbid circular dependencies in policy At the very least, I think they should be treated like pre-depends, with a request on this list being mandatory before adding a circular dependency. Until now, all circular dependencies cases I have met were fixable. At first, some of them looked necessary and they required quite some work, but they were fixable. You know when you're adding a pre-depends. You're typing the word Pre-Depends in a debian/control file. You don't know when you're introducing a circular depends that easily, and it could be either of the packages in the circle that shouldn't have such a depends, not necessarily the last one that closed the circle should change. Now, I agree they should be avoided where possible. But I'm afraid that needs to happen by having skilled people having dealt with similar issues before detecting them by running repository-wide dependency analysis on a regular basis, and then advising how to fix it. This happens to be what's happing now, actually. It'd be nice if QA's debcheck could be extended to detect circular dependencies and list them. Let's start by filing a wishlist bug on qa.debian.org for that :). #347676 --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: slirp and slang-slirp
On Thu, Jan 05, 2006 at 03:53:01PM +0530, Kapil Hari Paranjape wrote: Hello, Apologies in advance if debian-devel is the wrong list. I think this is a bug but I don't know against which virtual package so I am posting it here in the hope that someone will see it. The slirp source package in testing has been taken-over by the Debian JED Group---but what they are packaging is slang-slirp which is an entirely different game---see below. Both packages.qa.debian.org and bugs.debian.org seem to have got these two mixed up as well not to mention the Debian pool which has them in the same directory. I don't subscribe to -devel yet so please reply to me directly as well. #339578. Still waiting for the maintainer or hijacker to repair this. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Wed, Dec 21, 2005 at 03:31:26PM +0100, Christian Fromme wrote: On 20.12. 08:36, Steve Greenland wrote: I'm still missing the incentive. Joey Hess wrote in his earlier message that It's now only marginally larger than nvi. It achieves that by removing many of the features that distinguish vim from nvi, to the point that my guess is that most of those who prefer vim will need to install the full vim anyway, while those that prefer nvi will just fell vaguely dissastified by the change. If the result of this is that a) base is not smaller, and b) vim users still have to install vim-nottiny, and c) nvi users now have to install nvi, I don't think it's a net win. As much as I personally prefer vim, I feel your arguments a) b) and c) are the strongest I've read so far in this thread and therefore I also have to agree on the conclusion: Keep nvi as default. I don't think it's easily possible to count on people contributing to this thread to be representative, but I do think (b) is certainly less than it seems: Even vim-tiny would I think be liked more than nvi -- because vim-tiny invoked as 'vim' can be configured easily to be pretty much like the real vim, only lacking such features as systax hilighting which you can do without easily, if you're working on a small-editor environment. Looking at popcon, vim has about twice the amount of users as nvi, while nvi is the default vi, and vim is merely optional. I think this is an excellent question to phrase with a few options in a devotee-poll, and have people vote on it -- results being purely advisory, the poll just being informative, and any results updated live, rather than only after a delay. I think it'd be good to representative polls on a reasonably regularly basis -- close to the same representativeness, and stil much much more lighter than a GR, so easier to just do when some people feel a more clear idea of what the average DD thinks is needed than what one can gather from a mailinglist thread. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Experiment: poll on switching to vim-tiny for standard vi?
(Please followup to -project if you're replying on the subject of holding polls like this -- the discussion on holding polls is not technical, so does not belong to -devel. For opinions on nvi versus vim, please reply elsewhere in the current thread, this subthread isn't the place for it) For the full discussion leading up to this, please start at http://lists.debian.org/debian-devel/2005/12/msg00796.html To repeat myself from http://lists.debian.org/debian-devel/2005/12/msg01066.html: On Wed, Dec 21, 2005 at 03:45:51PM +0100, Jeroen van Wolffelaar wrote: ] I don't think it's easily possible to count on people contributing to ] this thread to be representative, [...] Looking at popcon, vim has ] about twice the amount of users as nvi, while nvi is the default vi, ] and vim is merely optional. ] ] I think this is an excellent question to phrase with a few options in a ] devotee-poll, and have people vote on it -- results being purely ] advisory, the poll just being informative, and any results updated live, ] rather than only after a delay. I think it'd be good to representative ] polls on a reasonably regularly basis -- close to the same ] representativeness, and stil much much more lighter than a GR, so easier ] to just do when some people feel a more clear idea of what the average ] DD thinks is needed than what one can gather from a mailinglist thread. Because this is certainly not the first time I was curious on the opinion of the so called Silent majority (if such beast exists at all), I decided to simply try out this idea. Therefore, I've set up devotee (thanks to Manoj for writing it!) on [EMAIL PROTECTED], with results updated near realtime on http://master.debian.org/~jeroen/polls/. To participate in the context of the nvi vs vim-tiny discussion, please fill in the below ballot, sign it, and submit it to [EMAIL PROTECTED] It's currently only available to DD's, for practical reasons more than for any fundamental reason -- being a poll, I do think that opinions of non-DD's is certainly good to have too, possibly simply both tallied for DD only and for 'all'. This polling thingy works just like a real vote, except: - It is a poll, a query to the opinion of people. - As such, results will be public, - and updated in near realtime - There is no real deadline per se, as this is not intended as a decision making instrument, at best a decision-making support instrument. Some polls will simply stop being relevant at some point, or maybe will remain of continued relevance. I'm curious how this pans out. I intend to launch more polls when I get good idea's to hold one, so let me know if you have one. BALLOT (Also found on http://master.debian.org/~jeroen/polls/vi/ballot) This is an informal poll, conducted with DeVoteE much like the way GR's and elections are done. Do not erase anything between the lines below and do not change the choice names. Please fill in, and send to [EMAIL PROTECTED] - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- f811dfe7-4e13-423c-8062-8dae621caf0c [ ] Choice 1: Keep nvi as the default vi in base [ ] Choice 2: Replace nvi by vim-tiny [ ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- /BALLOT --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I did ask, Re: congratulations to our ftp-master team
On Mon, Dec 19, 2005 at 10:22:33AM +0100, A Mennucc wrote: Dear Jeroen and everybody, here attached is an email I sent in September. Yes, I did ask to ftp-masters clarifications about your proposal in http://lists.debian.org/debian-devel/2005/04/msg00997.html and never received a reply. Jeroen van Wolffelaar wrote: While you indeed haven't got a later mail, you also didn't ask for one to the best of my knowledge (my memory isn't infallible, so I might be wrong, if so, I'm sorry, please correct me)... yes, your memory failed :-) (you are in the CC of the attached email) Yes, and I got it via ftpmaster@ too. I indeed failed to answer this mail, and so did we as ftp-master team. I'm sorry for that, I do my best to reply to all mails that I can answer to, but september was an increadibly busy month for me. Only speaking for myself here, if you haven't recieved an answer for a month or so and you expected one, you're welcome to prod me via mail, repeating every month if needed, I don't mind that for genuine questions that are not written in an offensive way. I know it's not nice, but I get a lot of mail, and as time passes, chances decrease significantly I'll ever get around to replying old mail. Alternative ways to solve this like adding more hours to days have proven hard to implement. I'm wondering what bit of my last few lines in the quoted email were unclear. While I specifically noted that removing mpeg encoding stuff might or might not be required, I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. (sorry my english fails me here) Basicly: Drop mpeg encoding from mplayer source package - definitely less problems getting through NEW. As in all cases, final verdict on whether a package will pass NEW is made at the time it's sitting in NEW and being processed by an ftp-master team member Of course. This is what I have been waiting for. For 880 days, roughly. I suggest you upload stripping all the mpeg encoding stuff, pending answer to that difficult question. However, what you do, is your choice -- if you prefer to wait and are not planning to strip mpeg encoding support out of the source package, that's not something the ftp-master team will have any say on. To answer the questions from your mail of september: 1) can mplayer be included into Debian, possibly with some fixes, including removal of source from the mplayer...orig.tar.gz ? I'm not aware of any fundamental reason why mplayer couldn't be in Debian. 2) (if yes) do we need to remove MPEG decoding stuff? Encoding, I assume you mean. Unsure, as I explained above and in earlier mails. It's a very difficult question, and we don't have an answer on it yet. However, removing encoding stuff would bypass the main problem that we have with mplayer right now, and then the answer to this question can then be researched in parallel to an mplayer-with-only-mpeg-decoding being available from Debian. 3) what other problems should we fix ? (please read http://people.debian.org/~mjr/legal/mplayer.html to know what has been already fixed ) I don't know of any at this moment, but I also cannot promise there won't be any more problems that need fixing found between now and the package being checked in the NEW queue. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote: Much worse, there are a couple of cases where we had to NMU the packages, either because the maintainers where inactive, or in one case because he said no time here, just go ahead. Except for this one case this couldn't have been done with the packages in experimental, since failing to cooperate with a package in experimental isn't RC, is it? You can NMU for any bug in principle, not just for RC bugs. That's a common misconception, but the Developers Reference lists nothing about only RC bugs being candidates for NMU. Of course, on a typical BSP, those RC bugs are the focus, but especially bugs that will become RC in the future are worthwhile NMU candidates too. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Thu, Dec 15, 2005 at 05:08:07PM -0800, Russ Allbery wrote: When one doesn't know, the right thing to do is frequently both not make the problem worse and not overreact, meaning leaving ffmpeg in the archive and xvidcap in NEW until the situation is clearly understood and resolved is quite reasonable. Of course, we do need to eventually actually get the situation resolved and come to a conclusion, after which either both should be in the archive or neither should. But the current situation of having one in the archive and one not during a hazy patent/license issue is *not* evidence of someone doing a bad job. It is evidence of an incomplete job, which I think everyone, including the ftp-masters, would agree with. Quite well put. I'm hoping to get a resolution on this matter in the not too distant future (no guarantees). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Thu, Dec 15, 2005 at 05:54:34PM +0100, A Mennucc wrote: Jeroen van Wolffelaar wrote: On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: That would have been me: http://lists.debian.org/debian-devel/2005/04/msg00997.html at that time, you wrote/ / /So, adding these two tentative conclusions together, it seems likely that if mplayer were demonstrated with reasonable certainty to be free of MPEG-encoding code, it would be acceptable for inclusion in main as far as the FTP-masters are concerned (note: We're not (yet?) saying it's *required* to strip MPEG encoding stuff, but in my personal opinion, it seems likely that this is what it'll turn out to be. Don't take my words on too much value though, maybe stripping this won't be required after all, but in any case, if it isn't there, we don't need to think/discuss about it -- reinclusion of the encoding stuff can then later separately be discussed)./ I have indeed been waiting to know if /it's *required* to strip MPEG /ftp-master not responding, still waiting.. ftp-master not responding, still waitingftp-master not responding, still waiting.ftp-master not responding, still waiting.ftp-master not responding, still waitingftp-master not responding, still waiting While you indeed haven't got a later mail, you also didn't ask for one to the best of my knowledge (my memory isn't infallible, so I might be wrong, if so, I'm sorry, please correct me)... Anyway, status is still basicly the same. I'm wondering what bit of my last few lines in the quoted email were unclear. While I specifically noted that removing mpeg encoding stuff might or might not be required, I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. To the best of my knowledge, mpeg encoding stuff is nowhere near the core funcionality of mplayer anyway, isn't it? Of course, if this way is choosen and is turning out to work out, later inclusion of the mpeg encoding stuff in mplayer must be discussed with ftp-master prior to it happening -- we (as in, Debian users in general) just get to have a chance of a slightly crippled mplayer in the archive in the meanwhile. --Jeroen N.B.: As in all cases, final verdict on whether a package will pass NEW is made at the time it's sitting in NEW and being processed by an ftp-master team member -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: Petter Reinholdtsen wrote: But it is not doing a great job with processing a few old uploads. I consider it a problem that no decision have been taken on the few really old uploads (xvidcap, rte, mplayer). One of the FTP masters (I forgot who) once said that the best way to help get mplayer into the archive would be to present an overview of the patent situation surrounding MPEG and the like. ffmpeg has such an overview in README.patents, which might serve as a good basis, as the core library code of mplayer, ffmpeg and xvidcap is identical. (libavcodec/libavformat) That would have been me: http://lists.debian.org/debian-devel/2005/04/msg00997.html With the additional note that I now know the answer of [6], and iirc, it isn't even this thread, but an earlier one or two threads on the subject ago. Oh well. Mr. Ray has made an unofficial overview page at [1]. Anyway, there was no noteable response to my mail at all, specifically, I cannot remember any mail to myself or to ftpmaster with insights on the patent matter and/or efforts to simply drop it from mplayer (it seemed as if those were not really needed at all for its function? At least then the re-inclusion of it can be discussed later, while the less-controversion bits are in the archive...). --Jeroen [1] http://people.debian.org/~mjr/legal/mplayer.html -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
expansions, plus no selection for bullet mark, but that can be helped by writing .*, .- and .+ instead. It will also allow to extend to .1 (for numbered) and .o (for the o-bulleted) lists. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc build failure analysis (was Re: StrongARM tactics)
On Sun, Dec 11, 2005 at 12:35:26AM -0800, Steve Langasek wrote: On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote: FAILED But FAILED is an advisory state anyway; it doesn't directly benefit the port, at all, to have the package listed as Failed, this is just a convenience for folks sifting through the build failures (like the rarely used confirmed BTS tag is for maintainers). In the long-term, one of two things needs to happen with each of these build failures: the package needs to be added to P-a-s so the arch no longer tries to build it, or the package needs to be fixed -- via porter NMU if necessary. So as you have the list of these packages, as a porter you can proceed with figuring out which of the two categories each falls into, and take the necessary action without worrying about the Failed state, yes? Indeed, for practical buildd maintainance purposes, the distinction is not that important -- though 'Failed' is known to not benefit of a requeue, while 'Building:Maybe-Failed' might or might not, it's unkown, most archs should have enough surplus buildd power that retrying everything once in a while doesn't hurt. The major benefit is though to make it apparant for porters what to look into, without all the 'noise' in between of maybe-transient failures. One could also make sure that the FTBFS bugs are tagged (user-tagged) with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a nice overview of all the porting bugs. It'd make sense to synchronise this across all architectures, so that it is consistent. If that is done, and there would be some way for porters to easily tag the build failures themselves on what bug they correspond with, or not, and especially, what failures are new and are yet to be tagged, there'd be an easy and clear workflow for porters to work on failures. I don't think there has really been such a defined porter workflow for build failures, and nobody so far has built/defined one to the best of my knowledge. And this touches one of the core points Vancouver is intended to solve: *porters* need to work on *porting*, and help actively and actually fixing porting issues in the archive. If creating a better interface for people to work on this is a part of achieving it, so be it. I'll see whether I can hack up something together for this, extending buildd.d.o/~jeroen/status. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 09:43:36AM +0100, Frank Küster wrote: Ingo Juergensmann [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 10:32:40PM +0100, Frank Küster wrote: Feature requests and other things are always welcome! I can't know what you want until you tell it to me. ;) Nothing - these the questions I was mainly interested in regarding buildd's: - is my package already built everywhere, so that it can go into testing? - did it FTBFS, and do the logs give indication why? - How can I get information from inside a buildd, e.g. temporary files created during a failed build. The first two can be answered without buildd.net (and actually I never was very much interested in so when will it be built?), the latter needs, well, a buildd admin must contact me... A buildd admin doesn't see much more than what you can see in the build logs. Basically the build logs is all a buildd admin see. But the buildd admin for sure has read access to /tmp in the build chroot? Assuming that /tmp isn't cleared after each build, but just every couple of hours/days/whatever. Due to disk shoreage on a significant amount of buildd's, to the best of my knowledge, the build tree is removed quite immediately after the build finishes, and only a rebuild would be able to give you more info. But surely, a porter owns the hardware in question too, and can simply test-built it himself? *That* is work that any interested porter can do, in the process, debugging the problem, and ultimately filing a useful bugreport, hopefully with patch -- and maybe do a porter NMU later, even -- prefereable still with i386 or so so that it is verified that this time around, the buildd indeed is capable of building the package. Yes, there can be hardware or software (kernel) differences between the porter's machine and the buildd. If that is the case, indeed one should contact the buildd administrator in question if more info is needed, but generally, I'd expect porters to be able to know their hardware well enough to find out what the issue is anyway. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 05:48:13PM +0100, Josselin Mouette wrote: Le vendredi 09 décembre 2005 à 12:07 +1000, Anthony Towns a écrit : That's non-sensical. Everything the buildds do is logged pretty much immediately onto http://buildd.debian.org/, which also provides long running statistics on how effective the buildds are, and even a schedule of what the buildds will be working on next. There is absolutely zero documentation on how the buildd network works. You know, the things you have to be aware of if you want to give a hand. http://www.debian.org/devel/buildd/ The 3 html pages above contain about 3500 words of explanation about the buildd network. Plus there is the source, and quite a number of people with pretty good insight -- insight you too can become if you're starting to read up about what it is, reading various sources, talk to various people about it, etc. Ryan Murray didn't tell me much if anything about the buildd network when I was trying to understand it, because I had no reason to go ask him -- yes, documentation is certainly not perfect, but that's a general issue of most of the things in the free software world. Numerous people have shown that if you just try, you'll find plenty of information. What indeed really could be improved, and Frank Küster helpfully filed a wishlist bug for that on www.d.o, is listing somewhere contact addresses for the buildd admins in case there is a buildd-system related issue. Isn't it more productive anyway that if there's percieved lack of documentation to simply actively work on that, rather than complaining loudly? Or that if you think the process itself has flaws or is understaffed, to help productively, like Anthony Towns notes[1]? Because, hey, Anthony is right there. Let me tell you story of http://buildd.debian.org/~jeroen/status/ -- I noticed that sometimes due to system crashes, network downtime, or whatnot, a few packages might end up in state 'Building' for a prolonged time, and that there was no automated mechanism to unstuck it -- it needed someone to note that, and then the buildd admin requeued it. Instead of complaining loudly about that on the lists, I asked myself how this could be resolved. The first thing needed for that was detection of the issue itself, so I wrote the above-mentioned page. And I noted that the problem was much less than I thought. Anyway, Steve Langasek picked up actually looking at it regularly, and feeding back give-back suggestions to the buildd admins when needed. And after a while he was granted full wanna-build access to do it himself, because he has shown to understand how it works. A similar issue I noted in the past is the big number of build failures that don't get tagged 'Failed'. I tried working on classifying them, but got bored so increadibly fast that I gave up, and decided for myself this should be something the porters should rather look into. And thus I mailed in June about that[2]. I don't believe anyone picked up that, but I might be wrong, of course, my mail was hidden in a big thread about various stuff, just like this very mail is... Someone interested in porting (actually, I personally am myself not interested at all), should maybe mail to all arch-specific lists some request similar to Vince Sanders' request[3] regarding classifying arm failures. --Jeroen [1] http://lists.debian.org/debian-devel/2005/12/msg00323.html [2] http://lists.debian.org/debian-devel/2005/06/msg00674.html [3] http://lists.debian.org/debian-devel-announce/2005/12/msg2.html -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bugs.debian.org refusing mail?
On Thu, Dec 08, 2005 at 10:52:16AM +0100, Frank Küster wrote: Hi, I just got a strange response when I sent a mail to two addresses on b.d.o: The original message was received at Thu, 8 Dec 2005 10:44:44 +0100 from [130.60.169.219] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 550 Administrative prohibition) [EMAIL PROTECTED] (reason: 550 Administrative prohibition) - Transcript of session follows - ... while talking to bugs.debian.org.: DATA 550 Administrative prohibition 554 5.0.0 Service unavailable Weird, but why don't you ask the people who are dealing with debian.org mail? Their address in [EMAIL PROTECTED] They have access to things like logs and such, the only thing other people can do is make (educated or not) guesses. Anyway, the complete text of your mail seems irrelevant as the bounce seems to imply you get a 550 directly after DATA, before you sent the actual message, right? So you can debug a bit yourself too with telnet easily, to see what part caused this error (the MAIL FROM:, RCPT TO:, the HELO, simply what IP you're sending from, or whether it's maybe transitional...). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bugs.debian.org refusing mail?
On Thu, Dec 08, 2005 at 12:24:32PM +0100, Frank Küster wrote: Jeroen van Wolffelaar [EMAIL PROTECTED] wrote: Weird, fortunately not too weird - I just sent the same mail again, and this time it has been accepted. Right, so transitional probably. but why don't you ask the people who are dealing with debian.org mail? Their address in [EMAIL PROTECTED] They have access to things like logs and such, the only thing other people can do is make (educated or not) guesses. I would have sent the mail to [EMAIL PROTECTED] - how should I know the difference? And my experience with mail to debian-admin is kind of mixed, from prompt action plus answer to nothing at all, and these were more specific questions than Something seems to be wrong. Well, if you don't try, you're 100% sure to not get an answer, so I don't see how not mailing them helps :) -- and owner@ probably would've forwarded if they'd not have found it themselves. You could know the difference because DSA does email (it requires root), and the BTS people do the stuff once it leaves the MTA. Anyway, the complete text of your mail seems irrelevant as the bounce seems to imply you get a 550 directly after DATA, before you sent the actual message, right? So you can debug a bit yourself too with telnet easily, to see what part caused this error (the MAIL FROM:, RCPT TO:, the HELO, simply what IP you're sending from, or whether it's maybe transitional...). Sorry, I'm a DD, am I required to speak SMTP? Nope, it's just relatively common for people to know it a bit, but yeah, you can just mail DSA or so instead if you can't -- or try still try to debug using your normal mail program (perhaps from different hosts/accounts/etc). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master mail problems -- help needed
On Thu, Dec 08, 2005 at 10:33:54PM +0100, Florian Weimer wrote: * Lionel Elie Mamane: On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote: The fact that my primary MX is only available through IPv6, and that this is the case for other people who're having problems too might then be a better chance at being the problem. My primary MX is IPv6-only, too. I don't have detected a problem yet :) Do you receive lots of mail from master.debian.org, and would you notice the bounces? Mail from Debian mailing lists come directly from murphy.debian.org, which does not seem to have the problem. You also have one IPv4-only MX, which might be enough to prevent the Exim bug[1] from occurring. [1] I'm not sure if it's a Exim's fault, it's only a hunch. I've filed #342619 on the strong suspicion something fishy is going on in exim, even though I don't know for sure what's going on exactly. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted phpbb2 2.0.18-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 5 Dec 2005 19:40:11 +0100 Source: phpbb2 Binary: phpbb2-languages phpbb2-conf-mysql phpbb2 Architecture: source all Version: 2.0.18-2 Distribution: unstable Urgency: medium Maintainer: Jeroen van Wolffelaar [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: phpbb2 - A fully featured and skinnable flat (non-threaded) webforum phpbb2-conf-mysql - Automatic configurator for phpbb2 on MySQL database phpbb2-languages - phpBB2 additional languages Closes: 336623 341991 342081 Changes: phpbb2 (2.0.18-2) unstable; urgency=medium . * Fix compression of SQL schema's, which broke phpbb2-conf-mysql too (Closes: #341991) * Fix upgrade of /usr/share/doc/phpbb2/schemas from dir to symlink by removing the dir in preinst (Closes: #342081) * [TK] Russian translation fixes by Alexander Gerasiov (Closes: #336623). Files: 959cbadc29660a82a0d5b18d5a00d98f 760 web optional phpbb2_2.0.18-2.dsc 1f99eeebee02a16968cb6ca7f10a0759 70959 web optional phpbb2_2.0.18-2.diff.gz 24ab144dddb33357ebddb13cfb3e4bfe 534754 web optional phpbb2_2.0.18-2_all.deb 5f9f2e934da18f1ed237eb3f1a13901e 46544 web extra phpbb2-conf-mysql_2.0.18-2_all.deb d7065cf913526d7c86f200ed65ce9dab 2725162 web optional phpbb2-languages_2.0.18-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFDlJUZl2uISwgTVp8RAthFAKCvW46jnQBSwE9/jRCvh/pu63I5EACgnUqi Ubhv8POCkvW3blBf7WJsaGY= =w3LG -END PGP SIGNATURE- Accepted: phpbb2-conf-mysql_2.0.18-2_all.deb to pool/main/p/phpbb2/phpbb2-conf-mysql_2.0.18-2_all.deb phpbb2-languages_2.0.18-2_all.deb to pool/main/p/phpbb2/phpbb2-languages_2.0.18-2_all.deb phpbb2_2.0.18-2.diff.gz to pool/main/p/phpbb2/phpbb2_2.0.18-2.diff.gz phpbb2_2.0.18-2.dsc to pool/main/p/phpbb2/phpbb2_2.0.18-2.dsc phpbb2_2.0.18-2_all.deb to pool/main/p/phpbb2/phpbb2_2.0.18-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nload 0.6.0-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 29 Nov 2005 20:18:27 + Source: nload Binary: nload Architecture: source i386 Version: 0.6.0-3 Distribution: unstable Urgency: low Maintainer: Jeroen van Wolffelaar [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: nload - A realtime console network usage monitor Closes: 300267 Changes: nload (0.6.0-3) unstable; urgency=low . * Apply patch by Paul Brook [EMAIL PROTECTED] so that nload works correctly on 64-bit kernels (Closes: #300267) * Bump to policy 3.6.2 (no changes needed) * Bump debhelper from level 3 to 5 * Improve debian/copyright file * Add watch file Files: aac6fe1b21b6b08e1477bd3ffbedb762 642 net extra nload_0.6.0-3.dsc 63e3506fdbdf9eeb8203e84dba0f12d1 18872 net extra nload_0.6.0-3.diff.gz 83644955b490f99deeb6213c795dc626 31764 net extra nload_0.6.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFDjMJQl2uISwgTVp8RAnk9AJ9RBb2tSCWdoW7SggakWfDT7SDuqACeMKgz gSUNO6vGy5y6MamWj3bQMUA= =mfeN -END PGP SIGNATURE- Accepted: nload_0.6.0-3.diff.gz to pool/main/n/nload/nload_0.6.0-3.diff.gz nload_0.6.0-3.dsc to pool/main/n/nload/nload_0.6.0-3.dsc nload_0.6.0-3_i386.deb to pool/main/n/nload/nload_0.6.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted php-mail-mime 1.3.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 29 Nov 2005 22:53:23 +0100 Source: php-mail-mime Binary: php-mail-mime Architecture: source all Version: 1.3.1-1 Distribution: unstable Urgency: low Maintainer: Jeroen van Wolffelaar [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: php-mail-mime - PHP PEAR module for creating and decoding MIME messages Closes: 299547 Changes: php-mail-mime (1.3.1-1) unstable; urgency=low . * New upstream - Upstream fixed case-differences in encoding, dropping Debian patch * Bumped policy compliance to 3.6.2 (no changes) * Bumped debhelper compat level to 5 * Changed priority to optional (Closes: #299547) * Update debian/copyright to reflect new upstream contributions Files: 30115eb8a12c96a8f19e9bedf81be200 655 web optional php-mail-mime_1.3.1-1.dsc 0012fd2406597e60083bc4bce751cef2 16481 web optional php-mail-mime_1.3.1.orig.tar.gz 989c3d99acef74e8d6752a2575b392c3 2591 web optional php-mail-mime_1.3.1-1.diff.gz a97b959c9ddd979003bf82b85c17ab6e 18102 web optional php-mail-mime_1.3.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFDjNaOl2uISwgTVp8RAnpZAKCGsSd39iuKsZtWsTSLOR6b2hIOcwCfbbKc sNz7PTJJ1x9th0UPEwDLVV4= =gxLe -END PGP SIGNATURE- Accepted: php-mail-mime_1.3.1-1.diff.gz to pool/main/p/php-mail-mime/php-mail-mime_1.3.1-1.diff.gz php-mail-mime_1.3.1-1.dsc to pool/main/p/php-mail-mime/php-mail-mime_1.3.1-1.dsc php-mail-mime_1.3.1-1_all.deb to pool/main/p/php-mail-mime/php-mail-mime_1.3.1-1_all.deb php-mail-mime_1.3.1.orig.tar.gz to pool/main/p/php-mail-mime/php-mail-mime_1.3.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master mail problems -- help needed
On Sat, Nov 26, 2005 at 02:00:48PM +0100, Florian Weimer wrote: From time to time, master seems to bounce mail routed to mail.enyo.de with the following error message: [EMAIL PROTECTED] retry time not reached for any host after a long failure period Is anybody experiencing a similar problem? I tried to debug it myself, using the information I could access on master, but I couldn't gather enough evidence to present to the postmasters so far. But other DD's can also only do a limited amount of research, the only way to really find out is asking a postmaster -- this isn't a prosecution, so 'evidence' is not needed, I'd say (though, a copy of one bounce message with full headers would be the minimum I'd expect, because otherwise debugging is close to impossible). In general, this failure means that for 4 consecutive days the a connection attempt that happens roughly every 8 hours fails (connection refused, a timeout, HELO refused, stuff like that). Are you sure that this condition can never have happened? I see you only have one MX, for increased reliability and for cases when for example there's a routing problem somewhere between master and that one single MX, add a backup MX. When an exim mailserver is really bogged down under mail load, attempts can be made even less often. IIRC, when there are no prolonged connectivity problems, the error message is characteristic of a broken Exim retry configuration (no retry section at all, or something like that), but master's configuration seems to be fine in this regard. The host mail.enyo.de had some intermittent connectivity problems during the past few weeks (downtimes of about one hour every couple of days, nothing which should cause Exim to run past its configured retry limit). But this has been fixed, and the sporadic bounces continued. The other problem is a certain sluggishness when one of those botnets attempts to send spam to hundreds of message IDs, but these attacks last a couple of minutes only, and master should be able to cope with that. I'd really look into a secondary MX, but if it's indeed only there two problems at the frequency you say, it shouldn't really be possible that this is the cause. This problem has gained some unexpected urgency because I was kicked off the PTS due to these bounces (I think so, I haven't been shown one of the PTS bounces). On the other hand, it rules out my .procmailrc on master as an error source (because PTS mail gets sent to [EMAIL PROTECTED] directly). There is no automatic bounce handling for the PTS, that's still on the TODO... --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 05:19:01PM -0800, Steve Langasek wrote: Oh, and BTW, check the IPs of ftp-master.debian.org and keyring.debian.org... Well, at this moment those are distinct, because ftp-master is temporarily hosted on spohr.debian.org, and not on raff.debian.org, where keyring.d.o still is. But yes, they used to be the same and will again become the same. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: As I'm responsible for most of dpkg-sig's code (and planned to do some more work in the next two months) I'd like to know if anyone cares about using these binary signatures or if I can invest my time into something that's a bit more satisfying (== non-Debian stuff). As the ftp-masters and the dpkg maintainers seem to have no interest in the whole thing, I'm beginning to doubt that it's sensible to work on dpkg-sig. Just to provide some statistics about dpkg-sig usage, as I got curious about it too: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. I'm not going to interpret these numbers, as it's close to impossible to do so objectively. --Jeroen [1] Interested DD's can look into merkel:~jeroen/dpkg-sig how I got these numbers -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and orphan list
On Thu, Nov 10, 2005 at 03:23:08PM -0800, Chip Salzenberg wrote: Branden Robinson, the DPL, is aware of this organizational failure. But he has done nothing effective to repair it. He has suggested that another DD, Jeroen van Wolffelaar, has the authority to make keyring changes -- an odd situation, given the [EMAIL PROTECTED] alias, but no matter -- but Mr. van Wolffelaar has made no more progress than Mr. Troup has: that is to say, none. I'm sorry to hear that you think resigning is the only option. I don't actually have anything to do with keyring-maint, Branden just wasn't sure how to deal with your inquiry and asked me if I could help in some way. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs as submitter?
On Mon, Oct 17, 2005 at 02:09:06AM +0200, Jan C. Nordholz wrote: Dear list, I'd like to ask you if it is desired (and possible at all) that submitters close their own bugs if they have been fixed without the package maintainer's noticing. The informational pages on b.d.o don't state whether [EMAIL PROTECTED] is obeying commands from everyone, and whether or not such behaviour (meddling with bugs as non-maintainer) would be deemed appropriate. In my special case, the bug I've reported two weeks ago has apparently been fixed upstream, and the latest upload of the package to experimental has brought the fix into the archive. Now I'd like to save the maintainer some work and tag the bug fixed-in-experimental myself (together with a short explanatory message to the bug log), but am unsure whether I'm allowed to. Yes, you may do so -- if in doubt, simply write an explanatory mail to [EMAIL PROTECTED], and let the maintainer deal with it. If you're sure that what you're doing is correct, there is in general no reason to not do it. In order to prevent problems, I suggest being extra cautious changing the state of bugs if you're not completely sure how to undo any potential mistake you might make. In all cases, writing mail to [EMAIL PROTECTED] is always safe to do, and there should always be some maintainer somewhere who will read the message can can act on it appropriately. Thank you for your contribution (bugreports are also contributions in a way) to Debian! --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: can we do uploads of arch: amd64 yet?
On Sat, Oct 15, 2005 at 10:42:19AM -0400, sean finney wrote: On Fri, Sep 23, 2005 at 07:56:28PM +0100, Colin Watson wrote: On Fri, Sep 23, 2005 at 02:34:52PM -0400, sean finney wrote: can we build/upload amd64 binary packages to unstable yet? No, not yet. okay, thanks for letting me know. i guess the next question is do we have an estimate for when this will happen?. if i wanted to open a wishlist bug to track this, against what would i open a report? There is already such bug: #248043. It lacks a recent status update though. Be assured that both the release team and the FTP team are very well aware of the desirability to include amd64 as soon as reasonably possible in the archive -- the release team has made its inclusion a release blocker[1] even. --Jeroen [1] http://lists.debian.org/debian-devel-announce/2005/10/msg4.html -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#333844: override changes are not announced to the package maintainers
On Sat, Oct 15, 2005 at 05:39:06PM +0200, Henning Makholm wrote: Scripsit Jeroen van Wolffelaar [EMAIL PROTECTED] No, you misunderstand. Bastian means that if some binary packages are only built on some archs, not including the one the upload is taking place for, nobody will get an override disparity warning[1]. Is that even possible? The current unstable Sources file has no occurence of '[' in any Binary: line. Or is that not how such a situation is signalled? That is not how such a situation is signalled, rather, upon building on some archs, some packages simply will not produce certain binary packages. In my opinion, it'd be very desireable to *have* it signalled via the Binary: header, such that it can be used much more reliable in detecting misbuilds. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333844: override changes are not announced to the package maintainers
reassign 333844 dak severity 333844 wishlist thanks On Fri, Oct 14, 2005 at 04:00:15AM +0200, Matthias Klose wrote: override change are not announced to the package maintainers, _after_ a package is uploaded. Fwiw, they *are* listed on the PTS Package Tracking system, packages.qa.debian.org/$pkg) page of every package, so maintainers can know of them before upload (when they look at their own PTS page anyway). Indeed there currently is no notification when changes are made, typically this happens due to a manual email from the person doing the changes, who can then also explain why. This didn't happen here, my fault -- a large scale change didn't get completed, and hence not announced properly for the part that did get completed either yet. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#333844: override changes are not announced to the package maintainers
On Fri, Oct 14, 2005 at 01:55:30PM -0300, Guilherme de S. Pastore wrote: Em Sex, 2005-10-14 às 11:34 +0200, Bastian Blank escreveu: And he get only warnings for binary packages he uploaded, not for the packages which are only built by the autobuilders. Perhaps because the override check is all about Section and Priority, which are source package characterics, and because katie only performs the check on sourceful uploads? No, you misunderstand. Bastian means that if some binary packages are only built on some archs, not including the one the upload is taking place for, nobody will get an override disparity warning[1]. And he's correct, as override disparity warnings are only sent for sourceful uploads, and there is no disparity if you don't upload the binary package in question. Also, katie has overrides both for source packages and for binary packages. --Jeroen [1] This is an exception, the vast majority of all source packages do not differ what binary packages they produce based on the architecture -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatically sending test suite results from buildds to upstream
On Tue, Oct 11, 2005 at 08:32:51AM +0200, Jeroen Massar wrote: On Tue, 2005-10-11 at 02:13 +0200, Florian Ragwitz wrote: On Mon, Oct 10, 2005 at 08:07:52PM -0400, Daniel Jacobowitz wrote: SNIP or to include test results in the .deb files and retrieve them after the build. That latter is what the GCC packages do. I don't like that solution. Users of the package don't care about the test results so it's useless to bloat the packages with them. Stick the debug files into a seperate -debug package, which nobody will install anyway and just consumes some archive space. Packages that nobody will install should not be in the Debian archive. -debug packages only make really sense for a small number of the most high-profile packages. In this case, the extract results from buildd.d.o way is the way to go IMHO. It can be automated too if really needed if you make sure to output specific markers before after the tests run. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: major problem with gnome-games dependency]
On Tue, Oct 11, 2005 at 09:49:49PM +0200, Frans Pop wrote: On Tuesday 11 October 2005 21:34, Daniel Burrows wrote: No, because people like to turn off the installation of recommendations Or yes, because it offers more flexibility to people who have a basic idea of what they are doing. Those can simply install the pacakges they want. It isn't rocket science. and then file bugs when major functionality is missing from packages :-/. Bugs that result from stupidity or being clueless can be closed. Well, if the meta packages description is: Gives you the full GNOME suite with all associated programs, which is minus phrasing what the actual description is, then a recommends would simply by plainly wrong. If you don't want the The GNOME Desktop Environment, with extra components, don't install gnome. With today's size of a typical harddisk, for 99% of the people such a package would be exactly what they want. If you have specialized requirements, like the thread starter, you can put together your own set of packages. Or you can use debtags, to install desktop-environment::gnome !type::game (pseudo-syntax). The main things that this thread shows me, is that it is *not* immediately clear to people not too familiar with Debian that the removal of the 'gnome' package will not have *any* effect on what actual software is actually installed on your system. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Announcing wiki.debian.org
(please followup to debian-project@lists.debian.org) Hi all, The official Debian Wiki has now been set up on http://wiki.debian.org. The original wiki pages from wiki.debian.net have been converted and moved to wiki.debian.org. Thanks to Michael Ivey for hosting the previous wiki for the last four years and to Don Armstrong and various others for assisting in the migration. For those unfamiliar with the concept of a Wiki, please have a look at http://en.wikipedia.org/wiki/Wiki Happy Wiki'ing! --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl signature.asc Description: Digital signature
Re: Packages that need to be rebuilt agaisnt libssl0.9.8
On Thu, Oct 06, 2005 at 10:20:12PM +0200, Christoph Martin wrote: a lot of people bugged me about the new version and upstream only recommends this version. It also closes a grave security bug. Hm, that wasn't listed in the changelog. Anyway, there hasn't been a security advisory about openssl recently, did you backport a patch to the sarge version (and prefereably also, to the woody version) and informed the security team? I noticed you just requested help for maintaining openssl, so I can imagine that it's been hard to find to come up with a patch, but it would at least be beneficial to at least document such security issues, by informing security team, filing an RC bug on your own package, and mentioning the CVE ID (or at the very least, a short description of the bug fixed) in your changelog entry. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new source package producing old deb's is not regarded as NEW
On Tue, Oct 04, 2005 at 07:01:07PM +0200, Frank Küster wrote: this week I uploaded a new source package, libkpathsea3, that produces existing binary packages (libkpathsea3, libkpathsea-dev). I was surprised to learn that this package was not subject to NEW processing, but rather was simply treated as any existing package. Your observations are correct, this is indeed what happens. The override file, which determines what packages are allowed in and what packages get in NEW for manual review, is simply a list of allowed package names. The assumption is here indeed that only if a totally new name comes about, it should be manually checked. There is a list for binary package names and for source package names, currently source packages are allowed if they occur in *either* of those two lists. As it happens, due to some changes in the details of the override file handling, new source package names will soon make the package go to NEW too, even though there already exists a binary package by that name. That the new source package name already exists as binary package name is quite exceptional, but in this case indeed it matters. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder status update
On Sat, Oct 01, 2005 at 02:12:14PM -0400, Joey Hess wrote: Junichi Uekawa wrote: Yes, I don't have --resolve-deps, in the hope that priorities are fixed by ftp-masters. There needs to be a decision somewhere: 1. ignore priorities and go back to what it was before and make --resolve-deps the default in debootstrap 2. try to fix priorities/section AFAIK the plan is to not constantly bother the ftp masters with override changes, and only get them updated just before the stable release. Then stable will be installable without --resolve-deps. However, unstable will still need it. Fwiw, it's quite fine to get overrides changed throughout the release cycle -- it's even preferred because *if* there are issues, they are discovered early instead of last-minute. That said, I think it's good to use --resolve-deps by default for testing/unstable, so that override changes aren't that urgent (they don't break daily builds etc every other day), and can be batched up a bit, and processed when the dependency graph is a bit stable. Which may very well be only possible in the second half of a release cycle, but doing it really last-minute seems unwise to me. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, Sep 28, 2005 at 10:06:01AM +0200, Andreas Tille wrote: On Wed, 28 Sep 2005, Ricardo Mones wrote: I guess I have to set a further sudo permission here but for what program? It is 'sudo su' ? I would not really like this even if it is convinient. For /usr/bin/pdebuild, and invoke sudo pdebuild. Uhmm, why that? I do not want to run the whole process as root. This would immediately trigger the feeling I have to write a bug report. BTW, this question is more for d-mentors than for d-devel ;-) If your answer is really correct I'm happy that I posted it here for the sake of lazyness, because I'm not subscribed to d-mentors. IMHO package building should work with fakeroot and should not require root permissions. It works with fakeroot, the user the build runs at is configureable in /etc/pbuilderrc. The reason you require root for the whole thing is because of unpacking the chroot, chrooting itself, installing build dependencies, and purging the chroot again. Only the part between build dependencies and purging the chroot (the actual package building) can do without root privileges, and pbuilder will drop root appropriately in that stage, and use (by default) fakeroot where needed. See the BUILDSOURCEROOTCMD=fakeroot configuration entry in /etc/pbuilderrc. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: migrating wiki content from kwiki (w.d.net) to moinmoin (w.d.org)
On Tue, Sep 06, 2005 at 09:13:51PM -0400, Joey Hess wrote: Frans Pop wrote: It looks like this will take a while. Could the current wiki please have writing enabled again if that is the case? To elucidate on that, some of us are/were using the old wiki for a) planning real-life meetings b) day-to-day user support/breakage documentation c) release planning. Locking it long threatens to be disruptive. wiki.debian.net is read/write again, when conversion has been fleshed out, it'll be done on an updated dump. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: migrating wiki content from kwiki (w.d.net) to moinmoin (w.d.org)
On Sat, Sep 03, 2005 at 02:10:57PM +0200, Jeroen van Wolffelaar wrote: But anyway, what's needed is someone who uses some perl (or whatever) magic on that tarball, to get moin-compatible data/pages files that can be unpacked in the wiki.debian.org installation by a DSA member. I wonder whether with moin moin, there needs to happen anything else too, for example (index files rebuild or something?). Unfortunately I'm familiar with kwiki nor moin moin. I gave this a quick go, after finding the real location of the tarball. The result is at wiki.wolffelaar.nl, and the simple formatting works reasonable. The result can be found at wiki.wolffelaar.nl, the (dirty) source at http://www.wolffelaar.nl/~jeroen/kwiki2moinmoin And someone needs to come up with a way to deal with conflicts, though the best way would be to simply prevent them from happening -- i.e., do not create pages that already exist on wiki.debian.net. And, I noticed, selecting which pages to convert and which not to -- some are pure spam. Any help is appreciated -- improve formatting conversion, and finding bugs. For bugreports and patches, please mail me privately or address me on IRC (jvw). Once I'm reasonably content with the conversion, I'll prepare a tarball for DSA to install on wiki.debian.org, and then the rest can be done by normal wiki edits in cases where conversion went haywire. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)
On Sat, Sep 03, 2005 at 01:08:00PM +0200, Javier Fernández-Sanguino Peña wrote: On Sat, Sep 03, 2005 at 01:34:29AM +0200, Andreas Schuldei wrote: I did not find migration scripts between the two wikis. Do they exist? Is someone who is familiar with both wikis interested in writing one? Based on the text on the w.d.o frontpage it seems that Michael Ivey has provided the tar.gz with all the w.d.n contents. Which 404's at the moment. But anyway, what's needed is someone who uses some perl (or whatever) magic on that tarball, to get moin-compatible data/pages files that can be unpacked in the wiki.debian.org installation by a DSA member. I wonder whether with moin moin, there needs to happen anything else too, for example (index files rebuild or something?). Unfortunately I'm familiar with kwiki nor moin moin. And someone needs to come up with a way to deal with conflicts, though the best way would be to simply prevent them from happening -- i.e., do not create pages that already exist on wiki.debian.net. Note: I wasn't and still am not involved in any way with wiki.debian.org/ wiki.debian.net, but I simply would really like to see this transition happen smoothly, because the longer it takes, the harder it will get. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of {} shell wildcards in debian/rules
On Fri, Sep 02, 2005 at 03:17:30PM +0100, Toby White wrote: Since they are Makefiles, there is no convention (is there?) for specifying which shell should be used to execute commands. I use export SHELL=/bin/bash in the top of Makefiles where I use bashisms. I greatly prefer that over making the makefile harder to read by conforming to arcane POSIXisms. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Do we still need libc5?
Hi all, Debian unstable testing still carry around libc5, and some associated packages like altgcc, libdb1, ld.so and a few others. Is there nowadays still a use for these packages? Does the amount of usage warrant the efforts it take to maintain these rather outdated packages? I get a mixed reading from the popcon output, I don't know how to interpret it accurately. Fact is though that libc6 has been in Debian stable for over 7 years, since hamm was releaed mid-1998, and I think Debian is like the only living Linux distribution out there still shipping libc5. Thanks for your insight, --Jeroen - Forwarded message from Francesco Paolo Lovergine [EMAIL PROTECTED] - Date: Tue, 16 Aug 2005 17:56:36 +0200 From: Francesco Paolo Lovergine [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Cc: Matthias Klose [EMAIL PROTECTED], [EMAIL PROTECTED], David Engel [EMAIL PROTECTED], Francesco Paolo Lovergine [EMAIL PROTECTED], RISKO Gergely [EMAIL PROTECTED], Christian Hudon [EMAIL PROTECTED] Subject: Re: Bug#323139: RoM: please remove altgcc Message-ID: [EMAIL PROTECTED] On Tue, Aug 16, 2005 at 02:08:26PM +0200, Jeroen van Wolffelaar wrote: On Mon, Aug 15, 2005 at 01:14:45AM +0200, Matthias Klose wrote: Joey Hess writes: altgcc I didn't realize that this one still does exist. Please remove it from unstable. A number of libc5 related packages still depend on it though, and should be removed together. ld.so: The Linux dynamic linker and library for libc4 and libc5. libc: libc5 libdb: libdb1 libg++27: The GNU C++ libraries (libc5 version) regex: libc5 version of regex libs termcap-compat: Compatibility package for old termcap-based programs. What do you think of this? Based on popcon stats libc5, it's hard to say whether it's still really used, though I think it's pushing things to still ship this stuff with etch. I already proposed to remove the whole libc5 chaintools and dependencies before woody release. A few users complained because of a few old commercial programs (such as wordperfect and so) which depends yet on it. I asked on d-d at that time. Probably a survey could be conducted on d-u (I'm not subscribed) to know general suggestions by our users. I still have the same opinion, the old chaintool is now and always a pain to compile with every new release of the current one, and has a good deal of bugs. -- Francesco P. Lovergine - End forwarded message - -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libxalan2-java 2.6.0-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 17 Aug 2005 11:55:49 +0200 Source: libxalan2-java Binary: libxalan2-java libxalan2-java-doc libxsltc-java Architecture: source all Version: 2.6.0-4 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: libxalan2-java - XSL Transformations (XSLT) processor in Java libxalan2-java-doc - Documentation and examples for the Xalan-Java XSLT processor libxsltc-java - XSL Transformations (XSLT) compiler from Xalan-Java Closes: 323518 Changes: libxalan2-java (2.6.0-4) unstable; urgency=low . * Upload to get .orig.tar.gz back (got lost due to #232730) (Closes: #323518) * Reintroduce headless-building patch to get apidocs built again (accidently lost in -2) * Update policy compliance to 3.6.2 (no changes needed) Files: e84e87934841ea657b5fdbc23716c64e 1088 - optional libxalan2-java_2.6.0-4.dsc e7f7e8aea1cb024503e64cbe513db112 5875016 - optional libxalan2-java_2.6.0.orig.tar.gz 05519d2c5ac31a691a8bb073106925b4 6476 - optional libxalan2-java_2.6.0-4.diff.gz 01bf89a4de06f7f2efb1759707000c25 2945356 libs optional libxalan2-java_2.6.0-4_all.deb 86b09fc06b461b45a96d1be00654f422 1315330 libs optional libxsltc-java_2.6.0-4_all.deb a53f21ee8d8964658a3824b6c98061ac 3773770 doc optional libxalan2-java-doc_2.6.0-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFDAx6Zl2uISwgTVp8RAtVCAKCMNEHdBmzxG6ufSl76zy5JTZaPMQCeOb// W6DGxkL7CivUzwngfz4Tutk= =JTuU -END PGP SIGNATURE- Accepted: libxalan2-java-doc_2.6.0-4_all.deb to pool/main/libx/libxalan2-java/libxalan2-java-doc_2.6.0-4_all.deb libxalan2-java_2.6.0-4.diff.gz to pool/main/libx/libxalan2-java/libxalan2-java_2.6.0-4.diff.gz libxalan2-java_2.6.0-4.dsc to pool/main/libx/libxalan2-java/libxalan2-java_2.6.0-4.dsc libxalan2-java_2.6.0-4_all.deb to pool/main/libx/libxalan2-java/libxalan2-java_2.6.0-4_all.deb libxsltc-java_2.6.0-4_all.deb to pool/main/libx/libxalan2-java/libxsltc-java_2.6.0-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package tracking system issues
On Sat, Aug 13, 2005 at 01:40:04PM +0200, Raphael Hertzog wrote: Le vendredi 12 ao?t 2005 ? 18:32 +0200, Jeroen van Wolffelaar a ?crit : 1. The system warns that the bug tracking system contains patches, but there aren't any bugs with patches except one bug that has been closed for a long time and in fact will be archived in one day. There's a note about a patch from Ubuntu. Maybe it's counting that. Isn't supposed to, but this code isn't in CVS (yet). It does look like a bug indeed. Of course it's in CVS already ! I bet the problem is related to version tracking of the BTS. I'm running ~hertzog/bin/process-index.pl on merkel.debian.org. It scans ^ This file is not in CVS, at least not in its latest version, nor run from QA's crontab. That's what I intended to subtly refer to :). So in this file, the bug 258977 looks like open... and if I check http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=258977 it's marked as done but I don't see the mail closing the bug report (is that a new feature/bug of debbugs) ? This is very likely related to version tracking. I don't believe I know yet of version-tracking safe index files of the BTS, but then, I didn't look into it either, yet. Regardless, the /org/qa.debian.org/data/bts2ldap/fullindex is a more complete index of bugs, and it's also used by most other QA scripts in favour to the index.db file. The DDPO system extracts very similar data to the PTS from the bugindex, I think that in order to prevent double work here, those two scripts can probably best be merged -- also so that DDPO PTS don't have different bugcounts for, from the user point of view, very obscure reasons. Anyway, this isn't really ontopic for -devel at all, rather -qa... Let's continue there. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package tracking system issues
On Fri, Aug 12, 2005 at 10:59:09AM -0400, Jay Berkenbilt wrote: How does one report problems with the package tracking system? I followed the link on packages.qa.debian.org and got no response. I just added a link to the qa.d.o pseudopackage of the BTS to every individual page (can take up to 8 hours until every page is regenerated though). That's certainly not a complaint -- I don't necessarily expect to get a response right away, but I have no way of tracking this or knowing whether my comments have been received. There are three things that seem wrong about what's on the package tracking package for icu (http://packages.qa.debian.org/i/icu.html): 1. The system warns that the bug tracking system contains patches, but there aren't any bugs with patches except one bug that has been closed for a long time and in fact will be archived in one day. There's a note about a patch from Ubuntu. Maybe it's counting that. Isn't supposed to, but this code isn't in CVS (yet). It does look like a bug indeed. 2. PTS shows one release critical bug and shows that icu (source) is buggy in the testing status area. There aren't any release critical bugs against icu right now. Even clicking on the link from PTS doesn't show any. Also, the release critical bug report doesn't show any bugs against icu. There is a bug against icu28 which creates a binary package with the same name as one of icu's packages (this is the release critical bug). Maybe PTS is getting confused by that? This was still true with the latest run of the testing migration scripts, about which the PTS reports. You will see the same on every other source of this testing migration procedure, including the canonical one. See http://www.debian.org/devel/testing for further reading. 3. ICU has not been rebuilt on hppa (like anything else recently uploaded), m68k, or sparc, but PTS is not showing it to be out of date on those platforms. I thought it always showed that even when there were other issues such as the age being too low. Technically, it is not out of date. Due to a quirk in the script that ftp-masters use to remove obsolete packages, and because all binary:any packages were renamed, there are no outdated binaries left over in unstable. So this is not a blocking reason. It still won't propagate due to dependencies formerly depending on architectures of which now there is no icu version at all, but that's a different criterium. [EMAIL PROTECTED] madison -S icu -s unstable icu-doc | 3.4-1 | unstable | all libicu34 | 3.4-1 | unstable | alpha, arm, i386, ia64, mips, mipsel, s390 libicu34-dev | 3.4-1 | unstable | alpha, arm, i386, ia64, mips, mipsel, s390 icu | 3.4-1 | unstable | source [EMAIL PROTECTED] If anyone can shed some light on any of these, that would be helpful. It looks like PTS has had many recent improvements, which is great. If there are a few problems, I'd like to do my duty and report them so that they can get fixed while the changes are fresh. The first thing I did was look for a pseudopackage in the bug tracking system for PTS, but I couldn't find one. Perhaps I overlooked it? I hope my newest addition to each PTS page will make it clearer that qa.debian.org is also there for subdomains of qa.debian.org Thanks for the feedback, if you like, you can still report the first of the three points as bug. And if you have suggestions to clarify in the PTS about the second point being 3rd party output... go ahead :). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sword 1.5.7-7.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 6 Aug 2005 19:42:38 +0200 Source: sword Binary: libsword-dev libsword4c2 diatheke Architecture: source i386 Version: 1.5.7-7.1 Distribution: unstable Urgency: low Maintainer: Daniel Glassey [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: diatheke - CGI script for making bible website libsword-dev - Development files for libsword libsword4c2 - API/library for bible software Closes: 288586 Changes: sword (1.5.7-7.1) unstable; urgency=low . * Non-Maintainer Upload * C++ transition: libsword4 - libsword4c2 * Fix gcc4 compile error: Use intptr_t as type for pointers, not 'int' (Closes: #288586) * Debhelper compat level 4, to fix calls to ldconfig properly, and drop a lot of manual stuff * Run dh_makeshlibs *before* dh_installdeb * Fix broken dh_shlibs invocation Files: 246bc9a4b89fefbe9e5396c73c350d20 704 libs optional sword_1.5.7-7.1.dsc 938fc1f16ec383fad7718e358218047d 278177 libs optional sword_1.5.7-7.1.diff.gz a9123a74def5804fa0a58f959550da35 374580 libs optional libsword4c2_1.5.7-7.1_i386.deb e3559204d2e55d0b49f1df3fbafb57c3 701166 libdevel optional libsword-dev_1.5.7-7.1_i386.deb a395f29b4feebc8cf11bc39c5443fdc8 57440 web optional diatheke_1.5.7-7.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFC9lgll2uISwgTVp8RAhEsAJ9Ox6dlQUk4wYI515/vxVU0r3RvqwCgyTmZ lML/RgMw9cILJlqBm055RMI= =uMZ3 -END PGP SIGNATURE- Accepted: diatheke_1.5.7-7.1_i386.deb to pool/main/s/sword/diatheke_1.5.7-7.1_i386.deb libsword-dev_1.5.7-7.1_i386.deb to pool/main/s/sword/libsword-dev_1.5.7-7.1_i386.deb libsword4c2_1.5.7-7.1_i386.deb to pool/main/s/sword/libsword4c2_1.5.7-7.1_i386.deb sword_1.5.7-7.1.diff.gz to pool/main/s/sword/sword_1.5.7-7.1.diff.gz sword_1.5.7-7.1.dsc to pool/main/s/sword/sword_1.5.7-7.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kaffe 2:1.1.5-cvs20050808-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 8 Aug 2005 18:09:41 +0200 Source: kaffe Binary: kaffe-dev kaffe-common jikes-kaffe kaffe-pthreads-profile kaffe-pthreads kaffe kaffe-doc kaffe-jthreads Architecture: source all i386 Version: 2:1.1.5-cvs20050808-1 Distribution: experimental Urgency: low Maintainer: Debian Java Maintainers [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: jikes-kaffe - Wrapper for jikes using Kaffe classes kaffe - A JVM to run Java bytecode kaffe-common - Files shared between all Kaffe VM versions kaffe-dev - Header files and other resources for building against Kaffe kaffe-doc - Documentation for the Kaffe VM kaffe-jthreads - A green threads enabled version of the Kaffe VM kaffe-pthreads - A POSIX threads enabled version of the Kaffe VM kaffe-pthreads-profile - A POSIX threads and profiling enabled version of the Kaffe VM Changes: kaffe (2:1.1.5-cvs20050808-1) experimental; urgency=low . * Experimental snapshot hopefully fixing some arch-specific issues * Dropped all-but-one Debian-specific patches, the remaining one not being related to the code Files: 189fb8eaf531d7131cfb6e4304437eaa 1215 interpreters optional kaffe_1.1.5-cvs20050808-1.dsc 93901f9900b87b3e0149dc2303efc753 10345283 interpreters optional kaffe_1.1.5-cvs20050808.orig.tar.gz cd06dfc05e524ac4026e5dcaee980858 24270 interpreters optional kaffe_1.1.5-cvs20050808-1.diff.gz 9b57ce70682fbf77409601c0d5ec2a75 121820 interpreters optional kaffe_1.1.5-cvs20050808-1_all.deb 80805bc16d018fd1c62c50b113e74953 7002850 interpreters optional kaffe-common_1.1.5-cvs20050808-1_all.deb c7c85464af7569032a3692c0bd42aebd 138424 interpreters optional kaffe-dev_1.1.5-cvs20050808-1_all.deb 43e865620d7f45a1cdf008b180ab38ee 120858 interpreters optional jikes-kaffe_1.1.5-cvs20050808-1_all.deb b8adaac3bbb34b64c7eee31d5dff2120 203754 interpreters optional kaffe-doc_1.1.5-cvs20050808-1_all.deb 092ce7fa9198779dcc109dd0d5dcdce7 495754 interpreters optional kaffe-jthreads_1.1.5-cvs20050808-1_i386.deb bb029b582ba0beef97d19f84f42b6e10 595292 interpreters optional kaffe-pthreads_1.1.5-cvs20050808-1_i386.deb 86a747e142253aadc553c42939e81ecd 4861436 interpreters optional kaffe-pthreads-profile_1.1.5-cvs20050808-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFC9455l2uISwgTVp8RAkWfAJ97Ep7w+OS0IxvzKzomYmMBx/9shACgkuUt Zoe/78jQdDS7rxv52c1Bv9w= =a+gK -END PGP SIGNATURE- Accepted: jikes-kaffe_1.1.5-cvs20050808-1_all.deb to pool/main/k/kaffe/jikes-kaffe_1.1.5-cvs20050808-1_all.deb kaffe-common_1.1.5-cvs20050808-1_all.deb to pool/main/k/kaffe/kaffe-common_1.1.5-cvs20050808-1_all.deb kaffe-dev_1.1.5-cvs20050808-1_all.deb to pool/main/k/kaffe/kaffe-dev_1.1.5-cvs20050808-1_all.deb kaffe-doc_1.1.5-cvs20050808-1_all.deb to pool/main/k/kaffe/kaffe-doc_1.1.5-cvs20050808-1_all.deb kaffe-jthreads_1.1.5-cvs20050808-1_i386.deb to pool/main/k/kaffe/kaffe-jthreads_1.1.5-cvs20050808-1_i386.deb kaffe-pthreads-profile_1.1.5-cvs20050808-1_i386.deb to pool/main/k/kaffe/kaffe-pthreads-profile_1.1.5-cvs20050808-1_i386.deb kaffe-pthreads_1.1.5-cvs20050808-1_i386.deb to pool/main/k/kaffe/kaffe-pthreads_1.1.5-cvs20050808-1_i386.deb kaffe_1.1.5-cvs20050808-1.diff.gz to pool/main/k/kaffe/kaffe_1.1.5-cvs20050808-1.diff.gz kaffe_1.1.5-cvs20050808-1.dsc to pool/main/k/kaffe/kaffe_1.1.5-cvs20050808-1.dsc kaffe_1.1.5-cvs20050808-1_all.deb to pool/main/k/kaffe/kaffe_1.1.5-cvs20050808-1_all.deb kaffe_1.1.5-cvs20050808.orig.tar.gz to pool/main/k/kaffe/kaffe_1.1.5-cvs20050808.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mass bug filing on packages that are blocking use of cdebconf
On Sun, Aug 07, 2005 at 05:08:33PM -0300, Ben Armstrong wrote: On Tue, 2005-08-02 at 18:46 -0400, Joey Hess wrote: Ben Armstrong [EMAIL PROTECTED] xpilot I offered this for adoption a while back. Nobody took up my offer. I finally uploaded xpilot-ng today (see my 3-year-old ITP #141099) and plan to make it supercede xpilot (i.e. strip the contents of the old xpilot packages to turn them into dummy metas to assist with the upgrade). So, either wait for xpilot-ng's acceptance and its subsequent replacement of xpilot, or if you need this resolved sooner, go ahead and NMU xpilot with just the debconf fix. I won't have time for either until next weekend. Just curious: why not, in that case, upload xpilot-ng as xpilot? If the new upstream is actually the better one, it makes sense for it to go on under the label of xpilot in my opinion. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libxbase 2.0.0-7.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 6 Aug 2005 02:54:09 +0200 Source: libxbase Binary: libxbase2.0-0 libxbase2.0-bin libxbase2.0-dev Architecture: source i386 Version: 2.0.0-7.1 Distribution: unstable Urgency: low Maintainer: Michael Vogt [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: libxbase2.0-0 - xbase compatible C++ class library (shared libraries) libxbase2.0-bin - xbase compatible C++ class library (utilities) libxbase2.0-dev - xbase compatible C++ class library (development files) Changes: libxbase (2.0.0-7.1) unstable; urgency=low . * NMU for C++ transition * Rename libxbase2.0-0c102 to libxbase2.0-0 Files: 288aff22b9a1055f880495d2cd9e1629 682 - optional libxbase_2.0.0-7.1.dsc 0a2bb66a3e8fab8369cb19b414d6c932 71119 - optional libxbase_2.0.0-7.1.diff.gz 1ecbe360c932a53df8dd139f6146b961 208484 devel optional libxbase2.0-dev_2.0.0-7.1_i386.deb c8c4abe42d7f18853a6f7be2ca891d42 30682 libs optional libxbase2.0-bin_2.0.0-7.1_i386.deb 2487e1d0290c6151ff55091bbc8118d2 99438 libs optional libxbase2.0-0_2.0.0-7.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFC9BFhl2uISwgTVp8RAgQrAJ9WencHeU+yQejxugvajJvz0M71DwCgkymA xePTVtPJj0UYVtyBZUSNBRo= =d3Zz -END PGP SIGNATURE- Accepted: libxbase2.0-0_2.0.0-7.1_i386.deb to pool/main/libx/libxbase/libxbase2.0-0_2.0.0-7.1_i386.deb libxbase2.0-bin_2.0.0-7.1_i386.deb to pool/main/libx/libxbase/libxbase2.0-bin_2.0.0-7.1_i386.deb libxbase2.0-dev_2.0.0-7.1_i386.deb to pool/main/libx/libxbase/libxbase2.0-dev_2.0.0-7.1_i386.deb libxbase_2.0.0-7.1.diff.gz to pool/main/libx/libxbase/libxbase_2.0.0-7.1.diff.gz libxbase_2.0.0-7.1.dsc to pool/main/libx/libxbase/libxbase_2.0.0-7.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted squirrelmail-locales 1.4.5-20050713-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 5 Aug 2005 21:18:36 +0200 Source: squirrelmail-locales Binary: squirrelmail-locales Architecture: source all Version: 1.4.5-20050713-1 Distribution: unstable Urgency: low Maintainer: Jeroen van Wolffelaar [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: squirrelmail-locales - Translations for the SquirrelMail Webmail package Closes: 310711 Changes: squirrelmail-locales (1.4.5-20050713-1) unstable; urgency=low . * New upstream release + Including a Dutch translation typo fix, thanks Bart Cortooms (Closes: #310711) * Replace only the pre-locales-moved-away squirrelmail * Rebuild .mo files at build time, and don't ship .po files anymore * Add debian/watch file. * Update Standards-Version, no changes necessary. Files: 543e66a6ad5dad0d6d99c73123684452 776 web optional squirrelmail-locales_1.4.5-20050713-1.dsc 31575118d07fd994d9e812845d91b99d 3160830 web optional squirrelmail-locales_1.4.5-20050713.orig.tar.gz 002bfad1ff5115bc08f3dacb74de7274 2243 web optional squirrelmail-locales_1.4.5-20050713-1.diff.gz e3d1bf89fe0367a50af590fcb86e4ad9 1722640 web optional squirrelmail-locales_1.4.5-20050713-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFC89Y4l2uISwgTVp8RAp2jAKDPOsePIl8RBIMdJ0LrUS4pTC/dxgCgp5Cn XQX1hcIqw61MpOUQuuAd1aY= =JMDQ -END PGP SIGNATURE- Accepted: squirrelmail-locales_1.4.5-20050713-1.diff.gz to pool/main/s/squirrelmail-locales/squirrelmail-locales_1.4.5-20050713-1.diff.gz squirrelmail-locales_1.4.5-20050713-1.dsc to pool/main/s/squirrelmail-locales/squirrelmail-locales_1.4.5-20050713-1.dsc squirrelmail-locales_1.4.5-20050713-1_all.deb to pool/main/s/squirrelmail-locales/squirrelmail-locales_1.4.5-20050713-1_all.deb squirrelmail-locales_1.4.5-20050713.orig.tar.gz to pool/main/s/squirrelmail-locales/squirrelmail-locales_1.4.5-20050713.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DDPO: excuses broken? (Was: Re: bugs2ldap gateway down - wnpp, bts.turmzimmer.net broken)
On Thu, Jul 28, 2005 at 10:47:50PM +0200, Bartosz Fenski aka fEnIo wrote: I'll just use this thread for another question regarding qa.debian.org. What for? This only confuses people... This is not related at all. Could someone tell me why: http://qa.debian.org/developer.php?gpg_key=13FEFC40comaint=yes doesn't contain links to Excuses since... hmm... yesterday? Still related to recovery from: http://lists.debian.org/debian-devel-announce/2005/07/msg00013.html http://lists.debian.org/debian-devel-announce/2005/07/msg00018.html Please let -qa know if this still persists a few days after britney is running again. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted java-package 0.25 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 10 Jul 2005 18:50:40 +0200 Source: java-package Binary: java-package Architecture: source all Version: 0.25 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers [EMAIL PROTECTED] Changed-By: Jeroen van Wolffelaar [EMAIL PROTECTED] Description: java-package - utility for building Java(TM) 2 related Debian packages Closes: 313555 Changes: java-package (0.25) unstable; urgency=low . * Cope with dpkg's new way of expressing architectures (Closes: #313555) * Re-exec with fakeroot if needed (Closes: ##310132) Files: 20e218822a34327489d62ee37e4529dd 805 contrib/misc optional java-package_0.25.dsc 643c272eb43e7ec050d11d8fce849e97 18049 contrib/misc optional java-package_0.25.tar.gz 7230089131dd7b3b118f20fe876e38e1 19826 contrib/misc optional java-package_0.25_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Signed by Jeroen van Wolffelaar [EMAIL PROTECTED] iD8DBQFC0WPNl2uISwgTVp8RAqiWAKCW9IIEGLgjmXRcaegrLd2xSsAIDQCeIqEE bZre/YlfR012k5t9e3+hqrs= =5bFk -END PGP SIGNATURE- Accepted: java-package_0.25.dsc to pool/contrib/j/java-package/java-package_0.25.dsc java-package_0.25.tar.gz to pool/contrib/j/java-package/java-package_0.25.tar.gz java-package_0.25_all.deb to pool/contrib/j/java-package/java-package_0.25_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PTS keyword for [EMAIL PROTECTED] messages
Hi, Since the move of the BTS from master to spohr, the PTS keyword for control@ bugs messages accidently changed from 'bts-control' to 'bts'. Since nobody complained (afaik) for nearly 1.5 years, I guess this feature wasn't really used anyway, and I propose dropping it. People's bts keyword will be set to bts || bts-control, and bts-control will stop being a valid tag. Comments? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Mirror Problem
On Tue, Jul 05, 2005 at 05:02:56PM +0200, Johann Glaser wrote: Ok, great. Lets have a look. This is the output of my script checking our internal mirror. It searches all Packages files, filters the lines starting with Filename: and checks if these files are present. For a few weeks it complains about these missing files: At least some of them are of woody-proposed-updates, which got dropped from the database, and hence from pool. Indeed, the corresponding Packages.gz files on the mirrors didn't get dropped yet, which is a minor bug. woody-proposed-updates got dropped because there is no more point release of woody, so the proposed-updates of it simply are no longer relevant. Any files missing from other Packages files than these? If so, please list the Packages file that has a broken reference to a certain .deb. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Mirror Problem
On Tue, Jul 05, 2005 at 05:21:37PM +0200, Johann Glaser wrote: Jeroen wrote: woody-proposed-updates got dropped because there is no more point release of woody, so the proposed-updates of it simply are no longer relevant. I see. Thus, I simply have to wait until woody-proposed-updates is removed from the ./dists/ tree as well. Yes Any files missing from other Packages files than these? If so, please list the Packages file that has a broken reference to a certain .deb. See the attached file with a grep for all file names complaint as missing with their according Packages file. Most of them indeed are from woody-proposed-updates, but the first few are from sarge. The first few are not supposed to work with 'normal' sources.list entries, but with 'deb http://mirror/debian/dists/sarge/main/update-kernel ./'. So all cases are explained by this or by the woody-proposed-updates thingy. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Mirror Problem
On Tue, Jul 05, 2005 at 05:54:27PM +0200, Johann Glaser wrote: Is there a way to find out what the base path of a Packages file is supposed to be? No So all cases are explained by this or by the woody-proposed-updates thingy. When will the woody-proposed-updates Packages files be removed? Basicly, when it's ready^W^W someone gets around to it. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upload new version of gaim-extendedprefs
On Wed, Jun 29, 2005 at 12:42:45AM -0700, Steve Langasek wrote: On Tue, Jun 28, 2005 at 12:34:01PM +0200, Arjan Oosting wrote: If it really should not be done, maybe a check could be added to lintian and/or linda and CDBS and the policy should be updated. There *is* a lintian check for this, and there is no need for policy to be updated -- just for you to follow it. Well my package *is* lintian and linda clean, so I guess the check is broken or I am doing something awefully wrong ;) I will attach the debug output of lintian. $ echo 'E: foo source: depends-on-build-essential-package-without-using-version' | lintian-info E: foo source: depends-on-build-essential-package-without-using-version N: N: The package declares a depends on a build essential package without N: using a versioned depends. In general a package should not depend on N: build essential packages but if it must do so, the depends should have N: a version string. N: N: Refer to Policy Manual, section 4.2 for details. N: $ Yeah, so I don't know why this check isn't being triggered if it applies to your package. The version of gaim-extendedprefs in the archive doesn't seem to have any build-deps on build-essential packages, so I can't compare. The 'build-essential' package itself is not build-essential, it's a helper package depending 'accidently' on all build-essential packages. In the context of build-depends, a dependency on 'build-essential' is essentially a no-op, but this isn't catched by the above-mentioned lintian check. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Getting rid of circular dependencies
On Tue, Jun 28, 2005 at 11:57:25AM +0200, Adeodato Sim? wrote: I'd like to hear from ftpmaster (CC'ed) if, provided this solution gains some acceptance, they'd be willing to help with a mass-change in the override files (see numbers below), and/or with the creation of such new section. Sure, it seems logical to add some new sections, like for java, ruby and 'data' -- though keep in mind that nothing has been decided on this yet. When a set of new sections has been decided on, there will naturally be some mass-override-change to get existing packages in the correct section. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with unstable - testing package migration?
On Mon, Jun 27, 2005 at 08:33:26AM -0400, sean finney wrote: hey, about a week ago i uploaded a package with priority=high to unstable to fix a security-related bug. for some reason, that package hasn't yet made it into unstable: http://packages.qa.debian.org/c/cacti.html Following the link on 'check why', I see going in today: http://bjorn.haxx.se/debian/testing.pl?package=cacti Indeed, on next mirror pulse, cacti will be in testing. I didn't really look into this, but I assume the delay is related to the announced[1] ftp-master outage. Several services and scripts have been temporarily disabled due to this, including testing propagation. anyone know more about this? i also notice the policy 3.6.2 vs 3.6.1 problem that someone else reported earlier (iirc they were told it should be cleared up in 24 hours, and that was also around a week ago). The current policy version is 3.6.2, your package has 3.6.1. The notice is correct. $ grep ^Standard /org/ftp.debian.org/ftp/pool/main/c/cacti/cacti_0.8.6e-1.dsc Standards-Version: 3.6.1 $ --Jeroen [1] http://lists.debian.org/debian-devel-announce/2005/06/msg00016.html -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Upload new version of gaim-extendedprefs
On Mon, Jun 27, 2005 at 04:22:54PM +0200, Arjan Oosting wrote: But whether or not this is a good feature of CDBS, the real question is whether build dependencies on build-essential are only allowed when they are versioned? Well, they only make *sense* when versioned -- an unversioned depends on all build essential packages is already implied by policy, and as such it's only cruft on the build-depends line (but it doesn't hurt, so it's merely a cosmetic issue). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Why is PTS complaining about the new standards version?
On Tue, Jun 21, 2005 at 06:42:12PM -0400, Roberto C. Sanchez wrote: The PTS page [0] for toshset, a package I just adopted, show this: The package should be updated to follow the last version of Debian Policy (Standards-Version 3.6.1 instead of 3.6.2). Since version 3.6.2 of the Debian Policy was just released, Anibal (my sponsor) had me update the package to reflect the new version prior to uploading. Is the PTS just not caught up yet? Yeah, indeed. Should be fixed in about 12 hours from now, when all pages have updated. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Inconsistent handling of sourceless packages in main
On Sat, Jun 11, 2005 at 07:12:52AM +0200, Goswin von Brederlow wrote: Eduard Bloch [EMAIL PROTECTED] writes: Moin Goswin! Goswin von Brederlow schrieb am Donnerstag, den 19. Mai 2005: IMHO debian-installer in unacceptable as it causes GPL violations. Interlocking the debian-installer builds with the exact source ... Any ideas? Comments? Solutions? Relax, there is no problem. (The same was as there is no problem with boot-floppies, beeing in Woody without the correct source. Nobody did care in the last 3 years). Regards, Eduard. -- In the beginning was the word, and the word was content-type: text/plain I do care. But I also have no evil intention and won't sue. I mainly care for the bloat for ia32-libs and similar packages. Creating a 300MB ia32-OOo package and uploading that on each change was/is insane enough to release amd64/ia64 without it. But I can't in good faith fight for doing it the debian-installer way and build debs that will regulary be without source. It would be hard to convince ftp-master to do the wrong thing after they already decided to do the right thing anyway. That's why I'm looking for any idea to have binaries rebuild from debs in debian without risking them being sourceless. Maybe a patch for the DAK and an extra entry in the control file? Come on, spin your minds, think of something. :) The above is a bit sparce on details of what exactly is the issue here. debian-installer builds use udeb's, and work is underway to not only keep those udeb's used last, but the udeb's for all d-i builds on the mirror network. If a udeb or deb is on the mirrors, the corresponding source is too, that's already ensured. So what is exactly the problem? Are you referring to libraries taken from regular .deb's, mangled and used in the initrd's? That's indeed a point, but not (much) different from the static linking issue we're already facing with any normal library in Debian -- there is a copy-on-compile, so the library that was staticly linked to, might move on and gain new source lines/drop them. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Inconsistent handling of sourceless packages in main
On Mon, Jun 13, 2005 at 12:34:21PM +0200, Goswin von Brederlow wrote: Jeroen van Wolffelaar [EMAIL PROTECTED] writes: The above is a bit sparce on details of what exactly is the issue here. debian-installer builds use udeb's, and work is underway to not only keep those udeb's used last, but the udeb's for all d-i builds on the mirror network. If a udeb or deb is on the mirrors, the corresponding source is too, that's already ensured. How will you do that? Will that include the files copied from the build system into the D-I images? Can the same mechanism be used for ia32-libs and similar? Nothing decided yet, thinking about the raw-installer upload hook to do something terribly d-i specific to keep all the needed udeb's for the installed d-i images around in some special 'fake' suite. So what is exactly the problem? Are you referring to libraries taken from regular .deb's, mangled and used in the initrd's? That's indeed a point, but not (much) different from the static linking issue we're already facing with any normal library in Debian -- there is a copy-on-compile, so the library that was staticly linked to, might move on and gain new source lines/drop them. The point is that anything using prebuild binaries to build debs can end up without source. I previously mentioned the D-I images, ia32-libs and kernel-images / modules. Now you added static libs to it. Kernel-source takes great care to preserve old sources in new uploads so they are fine, D-I just becomes sourcesless and ia32-libs has to carry all sources and debs it uses insite its tar.gz. If you are working on something to fix this for D-I then please share some details and hopefully this is general enough to be used for more than just D-I. Quite likely not. d-i can also really diverge from the archive, while for other stuff, this shouldn't happen, and also, a rebuild should always be harmless and not change functionality -- while a d-i rebuild with uptodate udeb's really *can* change functionality in a very significant way. All above mentioned cases are quite unique, in fact... --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: namespace conflict != package Conflict?
On Mon, Jun 13, 2005 at 09:46:27AM -0600, Sebastian Kuzminsky wrote: Steve Greenland [EMAIL PROTECTED] wrote: On 12-Jun-05, 02:27 (CDT), Hamish Moffatt [EMAIL PROTECTED] wrote: From my reading of your package description for cogito, the name GIT (the version control system) doesn't seem to mean anything in particular. So renaming it would not be a big loss. The upstream name isn't going to change. There are probably already more users of GIT-the-VCS than GIT-the-tools. So if you rename git for Debian, we are very likely going to to be incompatible. Just Conflict with the git package. The overlapping user base is likely to be nil. There is at least one user that wants both... I got a bug report about this before I made cogito.deb Conflict with git.deb. (Then of course I was told that that was the wrong approach, so I _removed_ cogito's /usr/bin/git and removed the Conflict with git.deb.) But I agree totally with you. I'd much rather conflict with GNU Interactive Tools and have git-the-vcs be compatible with non-debian universe. That seems like the lesser of two evils. But everyone else on debian-devel seems to want it the other way so I gave in for now. More importantly, the policy forbids it, as was already noted before in this very same thread. This thread is running in circles... I hope everything has been said by now so people can move on with the C++ transition and such :)? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
