Bug#549407: ivtools 1.2.6-1 FTBFS on sparc
Package: ivtools Version: 1.2.6-1 Severity: serious Hi, this package FTBFS on sparc: make[2]: Entering directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6' depending for LINUX in /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src make[3]: Entering directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src' depending for LINUX in /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common make[4]: Entering directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common' depending for LINUX in /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX make[5]: Entering directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX' g++ -M -w -DMAKEDEPEND -Dcplusplus_2_1 -Wno-deprecated -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/.. -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/../.. -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/include -I/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/include/ivstd -I/usr/include -I/usr/local/include -UHAVE_ACE /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/../*.c Makefile.depend g++: /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/../*.c: No such file or directory g++: no input files make[5]: *** [depend] Error 1 make[5]: Leaving directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX' make[4]: *** [depend] Error 2 make[3]: *** [depend] Error 2 make[4]: Leaving directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common' make[3]: Leaving directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src' make[2]: *** [depend] Error 2 make[2]: Leaving directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6' make subdirs make[2]: Entering directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6' making all for LINUX in /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src make[3]: Entering directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src' making all for LINUX in /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common make[4]: Entering directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common' making all for LINUX in /build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX make[5]: Entering directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX' make[5]: *** No rule to make target `/build/buildd-ivtools_1.2.6-1-1-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX/../math.c', needed by `math.o'. Stop. make[5]: Leaving directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common/LINUX' make[4]: *** [all] Error 2 make[4]: Leaving directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src/IV-common' make[3]: *** [all] Error 2 make[3]: Leaving directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6/src' make[2]: Leaving directory `/build/buildd-ivtools_1.2.6-1-sparc-mqkrRP/ivtools-1.2.6' Please see https://buildd.debian.org/fetch.cgi?pkg=ivtoolsver=1.2.6-1arch=sparcstamp=1254553192file=log for the full build log. Cheers, Andi - End forwarded message - -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548009: qa.debian.org isn't updated for a while
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [090923 19:01]: Aba, what do you think? Do you want to continue to maintain bts2ldap, or should we switch to UDD? I think you should switch to soap. Anyways, bts2ldap is going to disappear sooner or later, so moving away from it seems sensible. Cheers, Andi -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dropping libxml1
* Moritz Muehlenhoff ([EMAIL PROTECTED]) [080410 23:31]: There are only three packages left, which build depend on libxml-dev (r-cran-xml and cadaver have only alternate libxml2-dev | libxml-dev deps) cheops-ng (#470011) - gnome 1 only, low popcon, last maintainer upload from Feb 2007 amaterus (#470009) - very low popcon (12), last maintainer upload from Jul 2004 koala (#470012) - very low popcon (6), last maintainer upload from Auf 2005 None of the bugs have been followed up during the last month. Can we move on and remove libxml1 and the three packages above out of Lenny? We can. Please make sure libxml either gets removed before, or has an RC grade bug. (And the last two packages should be checked for removal by QA anyways it seems to me). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
fixed cronjob on merkel / ftp
Hi, I fixed the cronjob now by disabling the rsync of Maintainers, and using a symlink to /org/ftp.d.o/ftp/indices/Maintainers - so we got rid of the rsync errors and don't need to care about it anymore. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#433469: PTS: please parse 'Homepage:' pseudo-header in the Descriptions...
* Stefano Zacchiroli ([EMAIL PROTECTED]) [070718 00:01]: I'm totally in favor of using a less broken standard for that, but we can easily start supporting the current state of the art, and then support both the current syntax and the new one. I don't see any reason why not start supporting both standards at the same time (and fixing developers-reference). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#433469: PTS: please parse 'Homepage:' pseudo-header in the Descriptions...
* Russ Allbery ([EMAIL PROTECTED]) [070718 01:27]: I suppose one open question is whether to use Homepage or use Url, as some packages do already have Url headers and none are currently using Homepage. RPM uses URL. URL seems to be better, but at the end, I don't mind. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Storing the bug summaries information in an SQL DB
* Lucas Nussbaum ([EMAIL PROTECTED]) [070313 15:59]: Since that was a prerequisite for DDPO by mail, I started playing with importing the BTS' *.summary files in a database. I hacked bugscan to insert data in a mysql db, and I also imported some info from the Sources files (binary/source packages, maintainers and uploaders) to be able to cross-reference all of that. Please don't use mysql, but sqlite, which makes it way easier to use the data on different machines. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389163: How to handle filename conflict aleph (Packages aleph, tetex-bin, texlive-bin)?
* Frank Küster ([EMAIL PROTECTED]) [061212 21:36]: The right solution to this would be to package the new upstream version of aleph, which changes the name to afnix. However, the aleph package has been orphaned (#374120), and the ITP afnix has not yet yielded a package. I wouldn't want to rely on that for etch (although this is the first time I contact Paul about this, so I might be wrong). If there'll be no afnix package in etch, the only other solution to this problem seems to be to remove aleph from testing - any NMUing won't make sense without doing the actual work of packaging afnix. To me it seems as if the current situation is better than having no aleph/afnix at all. However, it violates the release policy. What should we do? Why is it better than to drop aleph? If a package is way outdated, and RC buggy, and also aleph is practically unchanged since Sarge, I think that is still grounds for a removal. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deluser on purge (was: Piuparts testing status update)
* Russ Allbery ([EMAIL PROTECTED]) [061115 03:12]: Steve Langasek [EMAIL PROTECTED] writes: On Tue, Nov 14, 2006 at 09:35:12PM +0100, Frank Lichtenheld wrote: Hmm, I would read policy in a way that since a package can not rely on its dependencies being present during purge, their pure absence alone should not be a valid reason to fail. If this on the other hand is a valid excuse to leave cruft behind is not really clear to me. I would certainly prefer the package just printing a warning and exiting normal rather than failing but I can't really point out a specific policy reference right now to make this more than a personal preference. In the case of adduser, there is a strong case for not doing deluser at *all* on purge, because it's impossible to ensure that there are no off-line or remote resources referencing the uid/gid. This is something that I'd really like to see us sort out in policy, since I think we should be able to describe consistent behavior with regard to system users and package purging to our users. Right now, every maintainer is making their own decision in this area, and I think that provides an inferior experience for users. Agreed. Marc Haber started a wiki page summarizing reasons pro and contra and issues, http://wiki.debian.org/AccountHandlingInMaintainerScripts Perhaps we can use that page some day in future to put something in policy. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
XS-Vcs-field
Hi, in bug #391023, this description of this field is given: +tagttXS-Vcs-*/tt + item + (where emVcs/em is the acronym for emVersion Control System/em, + and tt*/tt stands for one of the Vcs supported by the package + tracking system: ttbzr/tt, ttcvs/tt, ttdarcs/tt, + ttgit/tt, tthg/tt, ttsvn/tt, tttla/tt) + p + Value of this field should be an URL pointing to where the repository of + the given package is available. The information is meant to be useful for + the final user of the package in case he is looking for the latest work + done on the package (e.g. for the patch fixing a bug tagged as + ttpending/tt in the bug tracking system). The URL should be meaningful + for the given Vcs and should better be version agnostic. If possible, the + URL should point to a resource accessible to the final user and from which + the latest repository snapshot can be easily obtained. + /p + p + In the following example, an instance of the field for a Subversion + repository of the packagevim/package package is shown. Note how the + URL is in the ttsvn:///tt scheme (instead of ttsvn+ssh:///tt) and + how it points to the filetrunk//file branch. + example + Source: vim + Section: editors + Priority: optional + lt;snipgt; + XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim + /example + /p +/item Is this desciption correct? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
testing recommendations?
Hi, can someone please take a look at bug #376590 (re how should packages be tested?)? Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
* Thijs Kinkhorst ([EMAIL PROTECTED]) [061018 11:34]: On Wed, 2006-10-18 at 11:16 +0200, Lucas Nussbaum wrote: Internet access was not available from the nodes. Are build scripts allowed to download files from the Internet during build ? Some perl modules do this in their tests. No, this is definately a bug. I've indeed encountered it a couple of times already in Perl test suites. It's a problem because: - It's a privacy concern - without being asked, some information about the system is being sent to a remote host; - I should be able to build a package on e.g. my disconnected laptop or on your disconnected cluster; - The test has a high probability to fail lateron because of the referenced host disappearing. Actually, in a test it *might* be ok. Usually, even if they're bugs, they're not RC. Access to a debian-mirror is necessary for some packages, but rather on a exception-basis - almost all packages need to build with the packages they got installed via build-dependencies. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330084: (forw) Re: xawtv-plugin-qt: segfaults on start recording
- Forwarded message from Erik Schanze [EMAIL PROTECTED] - From: Erik Schanze [EMAIL PROTECTED] To: Andreas Barth [EMAIL PROTECTED] Subject: Re: xawtv-plugin-qt: segfaults on start recording Date: Tue, 19 Sep 2006 20:53:37 +0200 Message-Id: [EMAIL PROTECTED] User-Agent: KMail/1.9.3 Content-Type: text/plain; charset=iso-8859-1 Hi Andreas, Andreas Barth Andreas Barth [EMAIL PROTECTED]: * Erik Schanze ([EMAIL PROTECTED]) [050925 13:13]: Please feel free to ask for more info. Can you try whether it works with the new version 3.95-4? Unforunately, I changed my PC into a notebook and I haven't a analogue TV-Card anymore. I gave the PC to my nephew and he runs Sarge on it, but I have very (time-)limited access and he has only a modem connection to the internet. How could I help? Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * - Linux-Info-Tag in Dresden, am 8. Oktober 2006 * Info: http://www.linux-info-tag.de/ * - End forwarded message - -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cool stuff at EDOS - collaboration ideas
Hi, we (Enrico, Martin (tbm) and Andi (aba)) visited the EDOS workshop at the Rencontres Mondiales du Logiciel Libre (RMLL) http://www.rmll.info/ on Thursday and Friday. Besides giving talks about how QA and release management work in Debian, and how easy it is to create Custom Debian Distributions, we heard a good many talks about what has happened in the EDOS project itself. Some funny things, some interesting and some not-so-interesting things we were told. One of the funny ones is the Debian weather, which represents the installability status of the packages in the form of the current weather (i.e. which percentage packages are uninstallable): http://brion.inria.fr/anla/health?bundle=Uarchitecture=i386 Some of the ideas we gathered about that was to combine that with RC bug status, and/or to put it up as applet in desktop environments (or perhaps also as something you can run at fortune time, or ...). Of course, the current weather could also be included at the web page or wherever. :) Another nice thing was that they converted our normal dependencies (which include conflicts, provides) to SAT, and put a normal SAT resolver on it. One nice side effect of that was that one can measure the SAT temperature, which means: how hard is it to resolve that formula. Most packages are pretty cool, but we have some hotspots. Actually, it might be interesting to use the sorted list as input to some other tasks (just one idea we had was co-installability testing on piuparts) - but there's definitly more to come. Or perhaps also sometimes later as hints for apt to use? It might be possible to add value from that to the testing scripts, status checkers etc - but that's not the first step of course. Also, they had some engine for package comparison and search (where the weather was one of the side spin-offs from it). This could help us to ask more question about package aspects, and they are waiting for inputs from us to have questions more in the way we like. The interface is at: http://brion.inria.fr/anla/ (and there is a more detailed CLI - but that currently generates a bit of load, and of course all of that is still alpha state). An extended package search is on http://ara.edos-project.org/ They also updated the debcheck package - now in the archive as edos-debcheck. Probably we should consider to use that on the qa.d.o-website. The dependency check people also provided some code to check which packages were co-installable in sarge and are no longer in etch. Please expect some mail from me about the details soon. (Well, I'm waiting on some mail from them, but they're apparently not in the office today. :) Some other idea was an apt with integrated rollback functionality. Though we were not so convinced how they did it (and, btw, they only did it for apt-rpm), it gave us an idea to integrate apt with some VCS for etc (eg. in order to role back configuration changes). Another idea we made up on our own was to create a second Packages file which could have minor information about packages - Bug status, temperature, popcon data, ... Might be nice for playing around, and we'll see how it's useful. There was also a group presenting about distro testing stuff. We're not as sure how far they are - but we'll try to give them some real life task to resolve (which would be useful for the release as well :). Ok, so much on what happened. The depedency people were very nice, helpful and open to suggestions from us, and invited me (aba) to come to Paris to continue discussion and integration. Perhaps someone else should come also - we need to sort that out. They also have already contact with Pierre (Madcoder). We definitly think there are good things to come and help us, so we're enthusiastic about working together with them. We encourage you to take a look at their web site and projects, and send useful ideas, suggestions and questions to the list. We will forward them to the EDOS people in order to start a discussion: weather: http://brion.inria.fr/anla/health?bundle=Uarchitecture=i386 package exploration: http://brion.inria.fr/anla/ package search: http://ara.edos-project.org/ distro testing: http://www.edos-project.org/qa/ main page: http://www.edos-project.org/xwiki/bin/Main/ Cheers, Andi, Enrico, Martin -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368546: (forw) Re: Bug#368546: sawfish-related system slowdown
- Forwarded message from Andreas Barth [EMAIL PROTECTED] - From: Andreas Barth [EMAIL PROTECTED] To: Tobias Stefan Richter [EMAIL PROTECTED] Subject: Re: Bug#368546: sawfish-related system slowdown Date: Wed, 21 Jun 2006 12:58:45 +0200 Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.5.9i * Tobias Stefan Richter ([EMAIL PROTECTED]) [060621 12:39]: now that this bug is no longer RC and sawfish no longer has the old maintainer, could you unblock sawfish again? According to popcon I am not the only one to still use it, so it would be a pity to miss it in etch. of course. dropped hint. Cheers, Andi -- http://home.arcor.de/andreas-barth/ - End forwarded message - -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
removing packages only in oldstable and in unstable
Hi, I propose to remove all packages only in oldstable and unstable, but not in testing. These are: projectb= select s.source from src_associations as sa, source as s, src_associations as sa1, source as s1 where sa.suite=4 and sa1.suite=5 and sa1.source=s1.id and sa.source=s.id and s.source=s1.source except select s.source from src_associations as sa, source as s where (sa.suite=2 or sa.suite=7) and sa.source=s.id; source -- barrendero bookview boot-floppies celestia cman configlet coq-doc crystalspace divine eroaster ext2resize falconseye gpsim-led gsnes9x interchange kernel-patch-ttl kernel-patch-uml l2tpd libopenobex mercury murasaki ploticus python-parted rootstrap scilab smail stella t-gnus tcltk8.0-ja user-mode-linux zmailer (boot-floppies might have the extra requirement to wait till woody is archived.) Comments? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing packages only in oldstable and in unstable
* Joey Hess ([EMAIL PROTECTED]) [060421 19:31]: Andreas Barth wrote: celestia Would be a pity to lose this IMHO. :-( The other possibility is always: Someone fixes it :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Oldest RC bugs affecting etch
* Martin Pitt ([EMAIL PROTECTED]) [060105 10:08]: Nathanael Nerode [2006-01-05 3:29 -0500]: 281893 -- patched uninstallable bug in libroken16-kerberos4kth Orphan package and make QA upload? Just my 2 cents: Is there any reason why we should keep krb4 in the first place? It's horribly old, out of date, and broken security-wise years ago. There was not much reason to use krb4 in Sarge or even woody, and much less to use it nowadays. IMHO it should just die and be removed from the archive eventually. This is already more or less decided on, and the transition is already being worked on. There was IIRC one issue with one of the rdepends, but it will happen in time for etch. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: About to be removed (#335488)
# please *do* *not* set etch-ignore without explizit approval tag 298909 - etch-ignore tag 337410 - etch-ignore tag 337416 - etch-ignore tag 337425 - etch-ignore tag 337427 - etch-ignore tag 337429 - etch-ignore -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status update for the Debian QA Meeting in Darmstadt, Germany
Hi, just some (more) last-minute information: Please bring with you: - a sleeping bag or whatever you prefer to use, - your inflatable mattress or whatever should be beyound you, - your towel, - anything else you need for the night, going to bed and getting up again (some of you are in an empty apartment that has exactly nothing), - power strip (Vielfachsteckdose), - switches (_not_ wireless, no access points) if you have one extra. See you all tomorrow. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports for removed packages
Hi, * Hamish Moffatt ([EMAIL PROTECTED]) [050820 10:33]: On Sat, Aug 20, 2005 at 09:27:24AM +0200, Andreas Barth wrote: Basically, there should be no reason to close any of the bug reports, as version tracking should be able to find out by its own that the package is gone. I don't know if that works. No sign that it does from http://bugs.debian.org/ipac . Well, frankly speaking, I expected that :) Actually, I think we all know that version-tracking is quite new, and that there are a lot of details that will need some polishing up. I guess this is one of them. Speaking of the new version tracking, how does done differ from 'notfound' in the latest version? Consider found more like a tag, something like foundtag +version, and notfound as foundtag -version, which removes a previously set foundtag. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports for removed packages
* Hamish Moffatt ([EMAIL PROTECTED]) [050819 17:36]: When is it ok to close bug reports package? My old package 'ipac' is only in oldstable now. There are 8 open bug reports. Is it appropriate for me to close them? It used to be ok to close bugs, but as we have now version tracking, you might want to only add appropriate version numbers (so that the bugs don't look closed in oldstable). Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The PTS should list Ubuntu patches
* Raphael Hertzog ([EMAIL PROTECTED]) [050720 00:26]: Le mardi 19 juillet 2005 à 11:46 -0400, Joey Hess a écrit : Why are changes made by one particular derived debian distribution so important that they should be singled out by the PTS? Because they're doing a good job and because those changes are done by DD ... and because the interest of both parties is to integrate their changes when it makes sense. well, but these patches should go into the debian BTS then. I agree with Joey here that showing oh, there is a ubuntu-patch is not the most appropriate thing. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The PTS should list Ubuntu patches
* Santiago Vila ([EMAIL PROTECTED]) [050720 12:45]: On Wed, 20 Jul 2005, Andreas Barth wrote: * Raphael Hertzog ([EMAIL PROTECTED]) [050720 00:26]: Le mardi 19 juillet 2005 à 11:46 -0400, Joey Hess a écrit : Why are changes made by one particular derived debian distribution so important that they should be singled out by the PTS? Because they're doing a good job and because those changes are done by DD ... and because the interest of both parties is to integrate their changes when it makes sense. well, but these patches should go into the debian BTS then. [...] No, just because there is an Ubuntu patch does not mean the patch should be in the BTS (there may be other reasons, but the mere existence of an Ubuntu patch should not be the only one). It should not be a bug to do things differently than Ubuntu. Agreed. But - when they are just done differently, there is no reason to listen them in the PTS. If they are valuable and should be picked up, they should be in BTS. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293801: qa.debian.org: please show packages with Uploaders header
* Bartosz Fenski aka fEnIo ([EMAIL PROTECTED]) [050205 21:55]: Would be great if http://qa.debian.org/developer.php could show also packages where I'm mentioned as uploader. That should work (well, it works at least for me and many others). Do you use different mail addresses / names there or so? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#273690: Adding PTS-tracked packages to qa.debian.org/developer.php
* Enrico Zini ([EMAIL PROTECTED]) [040927 19:40]: I recently gave up Debian maintenance of a package for which I'm upstream to another person, and I of course subscribed to the PTS for that package to keep touch with what happens. Now, after seeing the package disappear from my developer.php summary, I feel the need for seeing in it also the packages I'm subscribed in via the PTS. I don't think this is a good idea - I don't want that my subscriptions to be public. Forthermore, I think it's also difficult to do, at least for people who use different adresses for that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#273690: Adding PTS-tracked packages to qa.debian.org/developer.php
* Enrico Zini ([EMAIL PROTECTED]) [040927 20:25]: On Mon, Sep 27, 2004 at 07:53:16PM +0200, Andreas Barth wrote: Now, after seeing the package disappear from my developer.php summary, I feel the need for seeing in it also the packages I'm subscribed in via the PTS. I don't think this is a good idea - I don't want that my subscriptions to be public. Forthermore, I think it's also difficult to do, at least for people who use different adresses for that. Could developer.php have an own subscription mechanism, then, to add packages to one's page? That would probably work, yes. I'm sure you can see where this would be useful. No doubt about usefulnes. I would e.g. consider to do this for sponsored packages. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Hijacking / adopting ascii?
Hi, * Florian Ernst ([EMAIL PROTECTED]) [040921 22:40]: I seek permission to adopt the package ascii without having recieved positive feedback from the current maintainer as listed in the PTS (CCed), please see http://packages.qa.debian.org/ascii. I'd say: go ahead. He did only one upload in 2001, and didn't even manage to adopt correct (see the normal bug still open against the package). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: update frequency of ddpo
Hi Igor, * Igor Genibel ([EMAIL PROTECTED]) [040905 21:25]: About your approach, the solution I found is to check the Change time for the /org/ftp.root/debian/dists/sid/main/binary-i386/Packages.gz file and do the jobs if there is a difference. It seems to be a simple ways to proceede, isn't it ? Yes, it is. Thanks for that solution. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Uncommitted stuff in QA
* Martin Michlmayr ([EMAIL PROTECTED]) [040829 22:10]:
* Jeroen van Wolffelaar [EMAIL PROTECTED] [2004-08-27 14:10]:
data/cronjobs/ddpo{,.sigs}
data/cronjobs/ddpo was not modified by me (the added
/org/qa.debian.org/data/cronjobs/ftp-update call), same for sigs
(though I fail to see a difference there).
data/cronjobs/lintian-update
Also not by me, and only difference seems to be the cited cron entry.
data/ddpo/ldap2bugstxt
Only change of path; commited now.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
update frequency of ddpo
Hi, considering the current bug reports, it might be useful to check for changes of the the general information every hour, but really update them (and set a new timestamp on the webpage) only if there was a real change. That would gurantee that we won't have to change anything because of daylight saving times at the location of ftp-master. If there are no issues with this approach, I'm prepared to commit the changes. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: WNPP cleanup procedures
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [040809 22:55]: Andreas Barth [EMAIL PROTECTED] writes: Well, there is a list of ITA packages. Of course, you need to take a look into the bug report if you want to see whether it's O/ITA or RFA/ITA. Where is this list? See e.g. http://lists.debian.org/debian-qa/2003/07/msg00018.html http://lists.debian.org/debian-devel/2003/07/msg01502.html Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: WNPP cleanup procedures
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [040810 10:25]: Automatically generated web pages listing the packages that are ITP or ITA, sorted by the length of time the ITP or ITA has been set. Each page would be like the current page of orphaned packages with a non-QA address, indicating the suggested timelines to follow and giving a suggested procedure. This would enable the work to happen whenever someone gets the chance or the inkling, instead of depending on a person deciding to take the whole thing on all at once. I am happy to write suggested text, but it would take the people who manage qa.debian.org to actually put the web pages in place and such. Well, if you prepare text and code for it, I'll put it on the web page. But the issue there is IMHO: How can the program dectect when the title was changed? So, it needs to permanently track each bug. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: WNPP cleanup procedures
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [040809 22:25]: Andreas Barth [EMAIL PROTECTED] writes: I did take 6 months for an ITP, and one year for a RFP as lower limit for any action; however, if I saw good reason from the history of a bug report to not do anything, then I didn't write mail at all. By RFP you mean ITA? No, I meant: Request for Packages and Intend to Package. I think six months and a year is a really long time; the idea I have in mind is that after say a month it is reasonable to ask: how are things going? can we help? Well, generally, yes. But I had enough bugs to handle in either case, so I decided for this long time. ;) If someone is doing that more often, of course shorter times would be better. Also, a separate question: packages which transitioned from O to ITA are still officially orphaned, but we don't track them at http://qa.debian.org/orphaned.html, right? AFAICS, yes. We track them however at other places. Where? Well, there is a list of ITA packages. Of course, you need to take a look into the bug report if you want to see whether it's O/ITA or RFA/ITA. Finally, there seems to be a bug in the WNPP labels, because an ITA package could be either orphaned (and about to be adopted), or maintained with an RFA (and about to be adopted). Those are very different states from a QA standpoint; if it is RFA-ITA then the old and new maintainers have collective responsibility; but if it is O-ITA, then QA has the responsibility. Well, yes. But that's just the way it is. ;) (Do you have two new nice lables? If so, please tell.) Well, perhaps we could change RFA/ITA to RFT/ITT, which would mean Request for Transfer and Intent to Transfer? Well, I don't like Transfer, and I also don't like to change one of them away. Both would be better, as then one can see whether it's just an old bug report, or the new one. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: unnecessary adoption by QA-team
* Erik Schanze ([EMAIL PROTECTED]) [040806 23:25]: I have noticed that QA-team adopt the gif2png package. The QA group doesn't adopt packages, they are the _default_ owner of any package and bug if nobody is the current maintainer. So, as the package is currently orphaned, they are mentioned currently. A ready package, that solve this bug is already available. Why did QA-group adopt this package instead to sponsor my upload? Well, finding a sponsor is sometimes rather difficult. I'm sorry, but that's just the current situation. I know that it's rather frustrating (and I can well remember the time where it was frustrating for me, and I had to trap sponsors on IRC). I know that this answer is not as nice as it should be, and I feel sorry for this. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#262502: developer.php fails if dehsdb is not there
Package: qa.debian.org Version: 2004-07-31 Hi, the php-script fails if no dehs information is available. Sample: http://qa.debian.org/developer.php?login=tom%40trap.mtview.ca.us IMHO the page should just display an error, instead of stopping. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: developer.php getting a bit biiig
* Igor Genibel ([EMAIL PROTECTED]) [040728 14:25]: I added a feature to developer.php to keep in a cookie the appropriate settings about the columns display. You can look at http://qa.debian.org/developer2.php (I didn't commit the changes before having some feebacks). You need to allow cookies but if you don't want to use cookies, you can provide fields in the url. Although, these fields override the cookies values while they are also used to set the cookie. Hi, nice done. Some minor annotations: - Why are security versions and (less important IMHO) upstream versions split from the version information? - Is it possible to drop just the columns that have no information at all (if you look at the page for me, e.g. Exp is empty). - It might be nice to be able to only see the all bugs-number, but not the individual counts. - I don't like that my stored settings are change when I want to see something different once. Is it possible to store the new cookie only when a store new settings is selected? Thanks for doing this nice work. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: MIA: Lukasz Jachowicz ?
* Martin Michlmayr ([EMAIL PROTECTED]) [040727 18:10]: * Guillem Jover [EMAIL PROTECTED] [2004-07-25 22:51]: I don't have access to db.d.o anymore as I don't use a password. You can query LDAP from any .debian.org host. But the vacation information is not shown, at least according to my last tries. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: developer.php getting a bit biiig
* Martin Michlmayr ([EMAIL PROTECTED]) [040725 16:40]: * Peter Eisentraut [EMAIL PROTECTED] [2004-07-25 16:26]: This is all very nice, but now I need three monitors next to each other to see anything on the package overview page. Maybe this should be split up into several types of overview pages. I think the best thing would be to merge developer.php and the PTS. developer.php would basically show all packages of a person (but not much information about the package), and then link to the PTS for each package. The PTS could then contain all the information for the package. I'm quite happy with developer.php showing lots of information, because it gives me a good overview about the packaging capabilities of someone. What's about being able to select which information developer.php shows (also via a cookie), and a default set for someone who has no cookie / appropriate link? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: developer.php getting a bit biiig
* Igor Genibel ([EMAIL PROTECTED]) [040725 17:40]: Le dimanche 25 Juillet 2004 16:47, Andreas Barth a écrit : I'm quite happy with developer.php showing lots of information, because it gives me a good overview about the packaging capabilities of someone. What's about being able to select which information developer.php shows (also via a cookie), and a default set for someone who has no cookie / appropriate link? Instead of using cookies, why not put checkbox that show/hide columns and provides args to the url ? I would do both - with preferences to the url. But I want to see _my_ layout whenever I come to developer.php - independend from where. And if I e.g. follow a link from the PTS, developer.php just can't know my preferences what I want to see, unless there is a cookie. (Just take a look at bts.turmzimmer.net/details.php - if you edit a setting, you can set your user name to a cookie, and if it's set, it's used as default in future. Hm, you probably can't try this feature unless you add something to a bug report.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: developer.php getting a bit biiig
* Igor Genibel ([EMAIL PROTECTED]) [040725 17:40]: [...] some other idea: What about showing only the columns with contain more than a - (perhaps with some exception, as the sum of all bugs). That would also save some space, without hiding information. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: security related bug report - no maintainer reaction for 1 year
Hi Johannes, * Johannes Poehlmann ([EMAIL PROTECTED]) [040721 14:55]: I am working in the development projekt for the speak-freely package. (speak-freely.sourceforge.net) One Year and a day ago, i filed this bug report, saying that o There are security related bugs in the very outdated debian package o These bugs are fixed by new upstream sources o I integrated the sources in the new package and added a link in the bug report o Roman Hodek tried to upload the new package as a NMU which possibly got lost by the server problems or got cancelled by the maintainer. the current status is: This package is only available in woody, the current stable distribution. So, please feel free to upload it fresh to unstable if you want (but you'll need a sponsor for this). For woody (or any stable distribution), things are a bit outdated most times. That is the reason why it is called stable. If you can provide the security team with the necessary information about the nature of the bug, they can do a security upload. Please see http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security for details. For the other issues how to deal with new packages, please see http://www.debian.org/doc/debian-policy/ and http://www.debian.org/doc/developers-reference/ . Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#257995: O: libyahoo2 -- C library interface to Yahoo Messenger protocol (shared version)
* Gopal Narayanan ([EMAIL PROTECTED]) [040707 04:55]: Package: wnpp Severity: normal I would like to orphan the libyahoo2 package. It has several outstanding bugs in the BTS. Many of them are likely fixed in some latest activities in upstream CVS, but there is as yet no new release since January 04. The package description is: libyahoo2 is a library interface to the Yahoo! instant messaging protocol. It supports almost all current features of the protocol. libyahoo2 is used for instance by everybuddy. . libyahoo2 has more advanced functionality than the older libyahoo which is now discontinued as a project. . This package contains the shared library that you need to run programs that use the libyahoo2 library. I intend to do a QA-upload that fixes the RC-bugs in the next days, except if someone is adopting the package faster. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: What's with a non-released version in sarge?
[should we take that of -release?] * Andrew Pollock ([EMAIL PROTECTED]) [040627 09:55]: I can't think of a way forward here, that isn't going to make a mess for a group of users. [...] There is already a NMU (pending in delayed/3-day) by Jeroem which does revert to the last stable version, and which was also done in cooperation with Thijs Kinkhorst, upstream SquirrelMail developer. See e.g. http://bts.turmzimmer.net/delayed/3-day/squirrelmail_1.4.3a-0.1_i386.changes for the full changelog. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Maybe remove premail...
* Andrew Pollock ([EMAIL PROTECTED]) [040624 02:25]: premail has a few old, functional bugs open. It's in contrib, hasn't been changed since woody released, and I can't find it's upstream. I think you can achieve similar functionality with gnupg and mixmaster. Maybe we should just remove this package? Agreed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NCO maintainer MIA
Hi, * Charlie Zender ([EMAIL PROTECTED]) [040624 03:25]: I am now formally asking that Debian transition NCO maintainership to me and Rorik Peterson [EMAIL PROTECTED] over some reasonable timescale. Rorik and I are both Debian users. We implemented what we feel is a high-quality, up-to-date, Debian compliant, package for NCO and have been distributing from the NCO homepage: Yes, you can take over the maintainership. The problem is, however, that you need to find a debian developer who does the upload for you. For details, please see http://people.debian.org/~mpalmer/debian-mentors_FAQ.html We are very eager to begin regular updates of NCO to Sid. That's good. Thanks for that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NCO maintainer MIA
* Francesco P. Lovergine ([EMAIL PROTECTED]) [040624 11:55]: On Thu, Jun 24, 2004 at 09:22:29AM +0200, Andreas Barth wrote: Hi, * Charlie Zender ([EMAIL PROTECTED]) [040624 03:25]: I am now formally asking that Debian transition NCO maintainership to me and Rorik Peterson [EMAIL PROTECTED] over some reasonable timescale. Rorik and I are both Debian users. We implemented what we feel is a high-quality, up-to-date, Debian compliant, package for NCO and have been distributing from the NCO homepage: Yes, you can take over the maintainership. The problem is, however, that you need to find a debian developer who does the upload for you. For details, please see http://people.debian.org/~mpalmer/debian-mentors_FAQ.html We are very eager to begin regular updates of NCO to Sid. That's good. Thanks for that. Ok, you found one. I'll keep an eye over it ASAP. Martin, would you issue a WNPP O report for that? No need for an O-report. If you want, you can directly create an ITA. But even this is not required IMHO. The upload can just refer to this discussion, e.g. * new maintainers, see http://lists.debian.org/debian-qa/2004/06/... Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: plans on orphaning / removing packages not in testing
* Martin Michlmayr ([EMAIL PROTECTED]) [040620 14:25]: * Colin Watson [EMAIL PROTECTED] [2004-06-20 12:06]: If as maintainer you want your package not to be released but to remain in unstable, then file a serious bug on the package to that effect and tell the release team. Is there no cleaner solution so those RC bugs don't show up in the RC bug listing? Something like a remove foo hint without a specific version number. Another option would be a certain title style (like at the end [maintainer: not fit for release]), so that it's easy to sort them out - or a bug tag. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: plans on orphaning / removing packages not in testing
* Frank Lichtenheld ([EMAIL PROTECTED]) [040618 19:40]: On Fri, Jun 18, 2004 at 06:38:58PM +0200, Andreas Barth wrote: I'd consider it a good idea if we try to get rid of some of the packages that are in unstable, but not in the release of sarge (release as in: stable - sarge). I'm prepared to do the work for it, but would like to pre-warn the other developers in time. Therefor, I would e.g. like to send a mail like this to d-d-a: Hmm, I don't quite understand why this would be a good idea. The packages are not in testing so I would rather not waste more time on them _before_ the release but concentrate my work on the packages that are in testing but not ready for release. Or am I missing something? Well, I'm not speaking of investing any time now on them, but just to alert their maintainers and users that if the packages keep on being unfit for release, these packages will be removed after release. Of course, investing the time for reviewing before orphaning / removal should be done about release of sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: plans on orphaning / removing packages not in testing
* Michael Stone ([EMAIL PROTECTED]) [040618 23:10]: On Fri, Jun 18, 2004 at 08:27:14PM +0200, Andreas Barth wrote: Well, I'm not speaking of investing any time now on them, but just to alert their maintainers and users that if the packages keep on being unfit for release, these packages will be removed after release. Why? I'd actually like to see *more* packages that are unstable-only, rather than have mediocre or dead-end packages enter the stable release. There are a lot of packages whose upstream is a rapidly moving target and which there's frankly not a lot of point in packaging for a stable release that's got to survive for years. Two answers to that: 1. I really hope that we are able to release more often in future. Releasing only every four years is a dead end. 2. Please see exception below: Of course, if the maintainer considers his own package unfit for release because upstream is not stable enough, than this is ok. But - if the package was removed from testing because of FTBFS, and just didn't manage to re-enter, because this bug is still open, than the package really qualifies for removal / orphaning. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Inactive maintainers
* Andreas Metzler ([EMAIL PROTECTED]) [040614 20:55]: On 2004-06-14 Chris Hagar [EMAIL PROTECTED] wrote: The following maintainers are inactive, or at least aren't maintaining their packages properly. I noticed because the version of python2.3-mysqldb (Hoffleit) is very old and uses the library for the old (3.x) release of mysql, which I think is probably and unacceptable situation for release; Not really. The old mysql-library libmysqlclient10 is still used a lot in Debian simply because libmysqlclient12 is licensed under GPL instead LGPL, which makes it impossible to use in projects with GPL incomptabible licenses. Is there a problem with the exception at http://www.mysql.com/products/licensing/foss-exception.html | As a special exception to the terms and conditions of version 2.0 of | the GPL: | | You are free to distribute Derivative Works that are formed entirely | from works licensed under one or more of the licenses listed below | without affecting the license terms of the works, as long as: | |1. You obey the GNU General Public License in all respects for the |Program and the Derivative Work, except for identifiable sections |of that work which are not derived from the Program, and which can |reasonably be considered independent and separate works in |themselves, |2. You distribute all identifiable sections of the Derivative Work |which are not derived from the Program, and which can reasonably be |considered independent and separate works in themselves, subject to |one of the licenses listed below, |3. The Derivative Work does not include or aggregate any part of |the MySQL Server (SQL Engine) or any modifications, translations or |other derivatives thereof, |4. If the above conditions are not met, then the Program may only |be copied, modified, distributed or used under the terms and |conditions of the GPL or another valid licensing option from MySQL |AB. | | [A lot of licenses] Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: [EMAIL PROTECTED]: Advice on a certain maintainer]
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) [040611 12:55]: Nobody wants to comment? Nobody has an idea about how to handle this? Especially the copyright problems filed in 2002 that haven't had any maintainer reaction is IMHO a bit problematic, a maintainer should really do something about at least the legal stuff of his package. Of course, I'm not happy about this. But - what do you want to do about? I don't have any idea what the right thing[TM] would be. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Should we remove raidtools?
* Andrew Pollock ([EMAIL PROTECTED]) [040610 09:40]: Do we need to have three different RAID packages in sarge? From the package description, it's only necessary for unpatched 2.2 kernels. Given that we're trying to get rid of all 2.2 kernels, can we get rid of raidtools? AFAIK we won't be able to kick off 2.2 for sarge. IIRC 2.2 will probably be necessary for some m68k- and sparc-variants. I added debian-kernel, perhaps we get some comment of the kernel-maintainers whether they consider the raidtools to be necessary. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Roman Hodek MIA, NMU for mconfig
Hi, * Steinar H. Gunderson ([EMAIL PROTECTED]) [040608 00:10]: Roman Hodek ([EMAIL PROTECTED]) seems to be MIA; Echelon lists him as not being active on the lists since March, and mconfig, one of his packages (which has not seen an upload since April 2002) has had a trivial RC bug (with patch) open for 73 days. Did you ping him? Last time I pinged him he answered quite fast, though a bit under load. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
RC-bugcount at bts.turmzimmer.net/details.php revisited
Hi, I revisited this web page. New / additional features: - bugs tagged only sarge or sid can be ignored - pending, new, (upload to delayed / hinted for removal), (assigned to ftp.d.o/qa.d.o / claimed), contrib, non-free could be ignored - the appropriate removal string for the hints-file can optionally be displayed - the meaning of new can be configured, default is 14 days. If there are any issues (or new ideas), please don't hesitate to speak to me. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Packages with no users and not in testing yet
* Petter Reinholdtsen ([EMAIL PROTECTED]) [040601 05:40]: kernel-patch-2.2.17-vm-global kernel-patch-2.2.18-vm-global kernel-patch-2.2.20-arm kernel-patch-2.2.20-p3 These are already filed for removing. However, popcon is not really valid for kernel patches. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#250347: packages.qa.d.o reports testing migration problem when there isn't one
* Colin Watson ([EMAIL PROTECTED]) [040522 16:25]: On Sat, May 22, 2004 at 01:35:14PM +0200, Per Olofsson wrote: Package: qa.debian.org Severity: minor When I look at pcmcia-modules-2.4.26-i386 at packages.qa.d.o now it says: Problems # The package has not yet entered testing even though the 10-day delay is over. Check why. Testing Status # 10 days old (needed 10 days) # Valid candidate To say that there is a problem is a little misleading because the package will enter testing during the next run of the scripts. That's not guaranteed, mind you ... Valid candidate only means that it goes on to the next set of checks after the obvious and fast checks. Yes. However, it might be a good idea to show the warning only from the 11th day, not from the 10th (or more general from n+1 on, for non-low uploads). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
publishing /org/qa.d.o/data ?
Hi, Jeroen has requested more than once that we should allow direct web access to the qa-data, and I consider this a good idea. So, if there is no good reason against, I intend to give full web access to /org/qa.d.o/data on Sunday evening within the path http://qa.d.o/data. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Fresh bug info for PTS
* Raphael Hertzog ([EMAIL PROTECTED]) [040503 07:55]: Quoting Jeroen van Wolffelaar: Hi Raphaël, At http://www.wolffelaar.nl/~jeroen/pts.bugs.txt you can find fresh (pushed from spohr, directly regenerated) bug information for the PTS. New bugsummaries are moved over, so you should never get only a part of the file. Andreas Barth told me he knew where you fetched the bugstuff from, and wgetted the file to there on master, but it seems he's mistaken as the PTS pages have been updated, but still don't have fres bug information. I used to generate the stuff on merkel but somehow merkel web config doesn't allow me anymore to export the file via my account : http://merkel.debian.org/~hertzog/pts/bugs.txt That's because merkel doesn't know any account of the name hertzog, and as there is no such account, no cron jobs are run, and no user web pages are available. That's why the data are out of date ... I was too lazy to change it back again. Now, I have switched to your file but I'd like to have that on a .debian.org site for the longer term. I really believe efforts should be to 1. unrestrict merkel ASAP 2. commit all changes to cvs and create the documents out of /org/qa.d.o. I'll look into the second half of it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Newer bugs summary generating script
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) [040502 17:10]: Please find attached a newers bugs-summary generating script to be run for QA, which will generate bug summaries for the PTS, DDPO, and potentially further use. I cannot check whether this runs fine as-is on merkel of course, somebody else would need to check. Please make the generated files available via http. I'll look finalizing this script to the situation on merkel, and commit it to cvs, as soon as I can log into merkel again. Thank you for this script. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#246684: packages.qa.debian.org do not updating information about search-citeseer
* Martin Michlmayr ([EMAIL PROTECTED]) [040430 17:25]: * Andreas Barth [EMAIL PROTECTED] [2004-04-30 16:43]: After my last upload to unstable, the information about search-citeseer continue the same. This is not updated. Because of this, other issues like outdated developper information occour. reason for this is that the access to merkel is restricted, and so most cron jobs on merkel don't run any more. Access to merkel is restricted due to the last kernel bugs, and will be un-restricted Are you aware that packages.qa.debian.org is on master? Of course. But some / most of the data generation scripts have been moved to merkel. (And at least one is running with my user id, that currently does not exist on merkel.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#239703: About to remove kernel-patch-2.2.20-p3
* Camm Maguire ([EMAIL PROTECTED]) [040423 23:40]: Andreas Barth [EMAIL PROTECTED] writes: I agree on removing the package. So, if no-one disagrees, I'm going to reassign this bug to ftp.d.o next weekend. At least some of the functionality in my 4 packages appears to be missing from the latest 2.2 kernel. A simple cleanup would restore the patch against 2.2.25, and allow SSE instructions. I understand that the state of the art in kernel patch packages has changed, and version specific packages are deprecated in favor of some other mechanism. I will try to read up on this -- pointers appreciated. In short, I have no objection to the removal of the packages unless their presence would facilitate an update of the package contents to the latest kernel, which I would like to effect, at least in the p3 and raid cases. My question is really who needs this. 2.2 is probably going to be dropped on !m68k (so that the work for the security team is lower) and deprecated on m68k (only used for the subarchs that can't work with 2.4 and 2.6), so that the patch for PIII-processors could be dropped. Same is valid for the raid-patch. For the *vm-global*-patch: Well, even if this one is useful on that m68k-subarch (I can't judge), you need to upload a source package with another name. So, I'd like to reassign all bugs to ftp.d.o, and if the vm-global-patch is useful then please upload a kernel-patch-2.2.25-vm-global, or speak with the maintainer to incorporate that patch into kernel-source-2.2.25. Is that ok for you? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: jdom source package no more maintained
* Arnaud Vandyck ([EMAIL PROTECTED]) [040423 12:40]: Takashi changed the name of the source package but jdom still exists and provides a libjdom-java package. Shouldn't jdom removed from the archives? Changing the name of the source package means that the maintianers has to file a bug report against ftp.d.o asking for removal of the previous source package. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: gutenbrowser in non-US
* Emanuele Rocca ([EMAIL PROTECTED]) [040423 12:25]: * On 23-04-04 - 08:35, Andreas Tille [EMAIL PROTECTED] wrote: is there any reason that gutenbrowser is in non-US? If not I'd file a bug report to move it to main. The reason was unzip, which gutenbrowser depends on. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109400 But now that unzip is in main it should be moved too. gutenbrowser was uploaded to main yet: http://packages.qa.debian.org/g/gutenbrowser/news/1.html Why is it still in non-US? Because nobody removed it from non-US. For removing, a bug needs to be filed against ftp.d.o. Furthermore, even if it is removed, non-US is not processed at the moment, so it wouldn't change anything. Well, really problematic is IMHO that gutenbrowser is actually not part of main. Sorry that I can't tell you why at the moment, because access to merkel is currently restricted. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
developer.php is not updated for now
Hi, some of you might have it noticed: developer.php was not updated for more than 24 hours. Reason for this is that merkel is restricted, and so pushing the bugs-ldap-file to merkel does not work anymore. This will work automatically again after merkel becoming unrestricted. For the future, I'll add an additional cron job on merkel that does the updates via wget, if this file is too old. With this, we would have now only additional delays, but not being totally stalled. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Status of jed?
Hi, what's the status of jed? It has had one NMU and a RC-bug is open (means: a second one is to be expected quite soon). I'd be glad if you'd have the time to continue maintaining. Thank you for your effort you've put so far into jed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
about to remove kernel-patch-2.2-lids
Hi, I agree on removing the package. So, if no-one disagrees, I'm going to reassign this bug to ftp.d.o next weekend. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
About to remove kernel-patch-2.2.17-vm-global
Hi, I agree on removing the package. So, if no-one disagrees, I'm going to reassign this bug to ftp.d.o next weekend. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
About to remove kernel-patch-2.2.18-vm-global
Hi, I agree on removing the package. So, if no-one disagrees, I'm going to reassign this bug to ftp.d.o next weekend. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
About to remove kernel-patch-2.2.20-p3
Hi, I agree on removing the package. So, if no-one disagrees, I'm going to reassign this bug to ftp.d.o next weekend. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
About to remove kernel-patch-2.2.20-raid
Hi, I agree on removing the package. So, if no-one disagrees, I'm going to reassign this bug to ftp.d.o next weekend. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#243668: qa.debian.org: bugs on packages.qa.d.o not updated - packages.qa.d.o should move to merkel too
* Raphael Hertzog ([EMAIL PROTECTED]) [040415 08:55]: Quoting Colin Watson: Because packages.qa.d.o is on master, it uses master's bug mirror, and I guess that's the reason the bugcounts aren't updated anymore on packages.qa.d.o master's mirror is still being updated for the time being. However, I agree that packages.qa should move to merkel. Packages.qa is on master but it uses info from merkel, that's why it tries to download http://merkel.debian.org/~hertzog/pts/bugs.txt but this fails because the configuration of apache changed on merkel... if someone of debian-admin could fix that, I'd appreciate it. In the mean time, the PTS will continue to be out of date. What about pushing that data from merkel to master via rsync? I've done that for now in my private directory, and it's available at master:~aba/pts/, and updated every 15 minutes via cron, but I'm happy to either change that location, or to disable it if you have some other way. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#241652: binary packages refer @ packages.qa.debian.org = wishlist
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) [040414 12:10]: On Wed, Apr 14, 2004 at 11:17:48AM +0200, Andreas Barth wrote: * Jeroen van Wolffelaar ([EMAIL PROTECTED]) [040414 10:55]: This was and is a feature, that is currently missing, but I don't regret it... it was a heuristic anyways and as such promoted bad behaviour. Actually, it's not too difficult to get it really working again, and to always forward you to the _right_ source package. I'd like to have this feature again, and I'm willing to implement it right, if that is wanted. Source binary are different namespaces. (Hypothetical?) problem: source package xyz makes several binary packages, but source package abc makes the binary package xyz. But when looking at the Source: header in a binary package does the trick in all cases. Well, for that issue I'd give precedence to (in this order): - source packages - binary packages of sid - binary packages of experimental - binary packages of testing - binary packages of stable So, it's not heuristic anymore, and only breaks if the result is not well-defined. I think this is acceptable. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#241652: binary packages refer @ packages.qa.debian.org = wishlist
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) [040414 12:25]: On Wed, Apr 14, 2004 at 12:20:33PM +0200, Andreas Barth wrote: Well, for that issue I'd give precedence to (in this order): - source packages - binary packages of sid - binary packages of experimental - binary packages of testing - binary packages of stable So, it's not heuristic anymore, and only breaks if the result is not well-defined. I think this is acceptable. Contradictio in terminis :), It only breaks (...), this is acceptable implies heuristics. It only breaks if it was broken before is no heuristics. ;) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
www.d.o/devel/wnpp
Hi, one idea about this page: would it be good to add also a link to packages.qa.d.o (and not only packages.d.o)? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
removing qmail-*sv
Hi, you stated in the orphaning messages that you consider it best to remove these packages from Debian. Well, in this case I'd like to reassign these bug reports to ftp.d.o, if no one opposes. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
developers.php out of order
Hi, though merkel is up again, developers.php is out of order. I tried to solve that, but there are (at least for me) some problems: - ddpo.py is quite slow (seems to me because of the key lookups) - this makes debugging quite painfull - I got the following traceback: for security/stable... in section «main»... done. in section «contrib»...Traceback (most recent call last): File ./ddpo.py, line 551, in ? extract() File ./ddpo.py, line 475, in extract for line in fileinput.input(source_name): File /usr/lib/python2.1/fileinput.py, line 181, in __getitem__ line = self.readline() File /usr/lib/python2.1/fileinput.py, line 262, in readline self._buffer = self._file.readlines(self._bufsize) IOError: [Errno 21] Is a directory - well, and on trying the script in some home directory of me, I got output files, but it doesn't help to put them at the right place. - and I never did python before, and this is probably not the best way to learn it. Well, I'm now more or less away for easter (at least I try to ;). Sorry to tell bad news. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
(forw) Re: (forw) #175239: What are valid fax formats
Hi, I asked mgettys upstream. Please find Gerts answer below. IMHO the ghostscript installation doesn't count for us, as Debians ghostscript supports it. Cheers, Andi - Forwarded message from Gert Doering [EMAIL PROTECTED] - From: Gert Doering [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Andreas Barth [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: (forw) #175239: What are valid fax formats Date: Thu, 8 Apr 2004 22:17:09 +0200 Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.2.5i X-Spam-Score: / 0.0 Hi, On Thu, Apr 08, 2004 at 09:45:45PM +0200, Andreas Barth wrote: what do you think about that question? [..] Should this be regarded as a bug in tetex-bin? If yes, should we revert to the old form or provide a switch for both formats? Or is the format that efax understands (raw G3 data) deprecated? Thanks in advance, Frank P.S. raw G3 is produced with gs -q -dSAFER -sDEVICE=faxg3 -r$res -sOutputFile=$NAME-%03d.fax -sNOPAUSE - (where $res is, configurable, 204x196 or 204x98) group 3 fax is produced with gs -q -dSAFER -sDEVICE=dfaxhigh -sOutputFile=$NAME-%03d.fax -sNOPAUSE - (or replace dfaxhigh by dfaxlo) Mgetty's sendfax won't care (both output formats are understood). I have changed mgetty's faxspool to use faxg3 instead of dfaxhigh some years ago because most ghostscript installations have the faxg3 driver compiled in by default, and dfaxhigh needs to be enabled explicitely when compiling ghostscript. So from that point of view, I'd recommend to use faxg3. There are good arguments against faxg3, though - it has no header to store the actual resolution in, and some versions of the ghostscript drivers happen to create faxg3 files that are not 1728 pixels wide, which breaks faxing to standard compliant receivers (mgetty's g3cat fixes that on-the-fly). None of these points are strong enough, IMHO, to strongly recommend one format or the other. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] - End forwarded message - -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#242719: qa.debian.org unreachable
* Roland Stigge ([EMAIL PROTECTED]) [040408 12:40]: maybe you are already aware of the problem, but nobody reported it yet. For some (!) days now, qa.debian.org isn't reachable at all for me. That is known. merkel is down, see James mail. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Orphaning all packages by Matthias Kabel but gtk-gnutella.
* Andreas Metzler ([EMAIL PROTECTED]) [040402 16:40]: Martin Michlmayr [EMAIL PROTECTED] wrote: * Andreas Metzler [EMAIL PROTECTED] [2004-03-30 13:57]: Last upload: 2003-06-20 (0.9n-1) Latest maintainer contribution to the currently open (15+7) bugs: But he only seems to maintain gtk-gnutella. The others share ancient standard versions and bugs that are not commented on at all. Well, I'm all for orphaning it. [...] Ok. How does this continue, what is proper procedure? I'd say: You wait for some days if Matthias answer to any mail, and if not, submit O-bugs against WNPP. (Well, and of course: look into db if he is on vacation.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Moving qa away from klecker
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) [040401 01:55]: Err... you disabled too much, as the bugs.txt generation is still happening from your account. The script you use for that, isn't in CVS (yet); DDPO has stopped updating bug counts. If the script might be good inspiration for others, you could still commit it, even though eventually Andi Barth's script could take over (using ldap as input). That hasn't happened so far obviously. We tried that yesterday, but there were some small and nasty bugs in my script, so that we switched back to the current state (look at the cvs-checkins if you like ;). I hope that we manage it to change scripts ASAP. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#240829: packages.qa.debian.org: some package pages are empty
* Roland Stigge ([EMAIL PROTECTED]) [040329 16:40]: maybe you are already familiar with this issue, but here it goes: Some package pages are just empty, like http://packages.qa.debian.org/n/netcat.html. Others are OK, but unfortunately, I can't figure out which are empty and which are not. I guess that's caused by master running out of diskspace today, and that bugs.txt was not fully created. We're just about to change the script creating that bug list, and move that away from master. So, I guess we'll be able to finaly fix it in the next days. (But it's connected with creating a bts-backup at merkel, and updating the dns-records of qa, so it may take some days.) Thank you for bringing this problem to our attention. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: please upload ragel to close rc bug
* Martin Michlmayr ([EMAIL PROTECTED]) [040323 16:10]: * Andreas Barth [EMAIL PROTECTED] [2004-03-22 17:24]: i am the maintainer of ragel, but i am no dd so i can't upload new versions directly. my sponsor (csmall) is currently unavailable, so i would be happy if someone of you could upload the new version for me. this will (hopefully) close a ftbfs on some archs. files are at http://www.semistable.com/files debian-qa is probably not the best list for this request; however, if no-one else is faster, I'll do this upload this evening. I don't think this happened. Yes, there was one small issue left. I'm now satisfied with the package, but don't have access to my key right now, and will upload it in the evening (hopefully before dinstall run). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Orphaning lightning
* Andreas Metzler ([EMAIL PROTECTED]) [040323 20:10]: On 2004-03-23 Martin Michlmayr [EMAIL PROTECTED] wrote: * Andreas Metzler [EMAIL PROTECTED] [2004-03-23 18:51]: Marco Kuhlmann has retired from the project (see #230690) but lightning is not orphaned. Orphaned, thanks. I intend to make an upload to fix #219607. - Should I make a QA upload or a NMU? Technical speaking you make a QA upload, because as soon as you set the maintainer field to QA, bugs will be closed. So, I'd say: make a maintainer-upload, and do a -v1.1-2, so that the NMUed bug is also closed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Other script for creation of /org/qa.debian.org/data/ddpo/results/bugs.txt?
Hi,
I had the idea to create this file on master without the need to open
the summary files, because now all necessary information is stored in
the single file for ldap. Well, the following is a script by me as a
proof of concept; it needs less than 5 seconds for creation of that
file (and is certainly much optimizable ;). This is of course just an
idea, and open to discussion. And, one feature is missing: This code
does it on binary packages, not on source packages, as master is not
an ftp-mirror.
Cheers,
Andi
#! /usr/bin/perl -w
my %c=();
open(IN, /debian/home/aba/bts2ldap.new/data/fullindex) || die Cant open
data file;
while(IN) {
chomp ;
if (/^$/) {
addpackage;
%c=();
next;
}
if (/debbugsID: (.*)/) {
$c{'id'} = $1;
next;
}
if (/debbugsPackage: (.*)/) {
$c{'package'} = $1;
next;
}
if (/debbugsMerged: (.*)/) {
if ((!($c{'m'})) || ($c{'m'} $1)) {
$c{'m'}=$1;
}
next;
}
if ((/debbugsTag: fixed/) || (/debbugsTag: pending/)) {
$c{'fp'}=1;
next;
}
if (/debbugsSeverity: (.*)/) {
$c{'severity'}=$1;
next;
}
}
addpackage;
sub addpackage {
(%c) || (return);
if ($c{'severity'}=~ /critical|grave|serious/) {
$s=RC;
} elsif ($c{'severity'}=~ /important|normal/) {
$s=IN;
} elsif ($c{'severity'}=~ /minor|wishlist/) {
$s=MW;
} else {
die Unknow severity $c{'severity'} at package $c{'package'}
($c{'id'};
}
if ($c{'fp'}) {
$s=FP;
}
$global{$c{'package'}}{$s}++;
if ((!($c{'m'})) || ($c{'m'} $c{'id'})) {
$global{$c{'package'}}{$s.M}++;
}
}
foreach $i (keys %global) {
print $i:;
foreach $j ('RC', 'IN', 'MW', 'FP') {
$global{$i}{$j} += 0;
$global{$i}{$j.M} += 0;
print $global{$i}{$j}.(.$global{$i}{$j.M}.);
if ($j ne 'FP') {
print ;
}
}
print \n;
}
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: please upload ragel to close rc bug
* Robert Lemmen ([EMAIL PROTECTED]) [040322 17:10]: i am the maintainer of ragel, but i am no dd so i can't upload new versions directly. my sponsor (csmall) is currently unavailable, so i would be happy if someone of you could upload the new version for me. this will (hopefully) close a ftbfs on some archs. files are at http://www.semistable.com/files debian-qa is probably not the best list for this request; however, if no-one else is faster, I'll do this upload this evening. Thank you for your contribution to Debian. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Moving qa away from klecker
* Martin Michlmayr ([EMAIL PROTECTED]) [040322 15:40]: I intend to move qa from klecker to merkel in the near future. klecker is restricted now, which is kind of awkward, especially for the MIA database. merkel has plenty of RAM (for debcheck), enough disk space (unlike klecker, which runs out of disk constantly), and has the benefits of having a local FTP and BTS mirror. During this move, I intend to move all QA cron jobs to a dedicated qa user. I just started to mirror the bts LDAP-data to merkel:~aba/bts2ldap/data/fullindex to allow access to a fuller index (without so many read operations on different files). As merkel is also a mirror, I can quite easily change the script I posted yesterday to create bugs.txt, and run it after each bts-LDAP-mirror push. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: BSP Coordination
* Frank Lichtenheld ([EMAIL PROTECTED]) [040316 14:25]: As noted in the announcement there is currently no central BSP coordination page for bug squashing parties. Currently I see two ways to implement one again: 1) revive the claims.cgi page. This would probably require syncing a file from a nonrestricted host to spohr. (Or perhaps setting up the script to use the synced BTS indices on master?) 2) write a new claims page that is independent from access to the BTS index files, perhaps with the recreated bts2ldap gateway? This should be rather simple and I would volunteer to do it until friday. This sounds like a good idea. However, at the moment, the bts2ldap-Gateway is using the indexes at master and only recreating data once an hour. I can however set this intervall shorter if useful during the bsp-party and/or move that gateway to spohr if I get access to spohr. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Hanno Wagner MIA?
* Nathanael Nerode ([EMAIL PROTECTED]) [040315 01:40]: One package (qps), last maintainer upload in the year 2000. This package is still a qt2 package compiled with gcc-2.95 (despite what it says in some of the NMUs). It has a standards version of 2.5.0 and the postinst sets a /usr/doc symlink. Hanno is still alive. I'm going to contact him. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
getting /devel/wnpp current again
Hi, I'd like to get /devel/wnpp current again. What's the recommended way to do this? I'm quite willing to write the needed code, set up cron jobs etc, but how to put the result on the web site? Cheers, Andi PS: Please Cc me or debian-qa (or both) on answers. -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Future of netjuke?
Hi Sam, how do you plan the future of netjuke? That package has a RC-bug; this should be fixed ASAP. Futhermore, Stefan has packaged the next version and put them at http://home.arcor.de/sfr/debian/ I'd really be happy if you are able to continue the maintenance of this package, perhaps together with Stefan (well, I didn't ask Stefan if he'd like that). However, I care even more that the RC-bug is solved rather soon now. Best would be in my opinion if you get together with Stefan to a solution. If I can help in any way (including sponsoring an upload, if your new key isn't added to the keyring till now), then please don't hesitate to tell me. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#236131: developer.php: PGP keys from public keyserver not found
* Igor Genibel ([EMAIL PROTECTED]) [040304 18:55]: Currently the ddpo backend uses keyserver.debian.net for gathering gpg keys for non-debian-keyring present developer. But this server is a round-robbin link to keyserver.fabbione.net and keyserver.noreply.org that currently do not have the same html rendering than the previous keyserver it used (wwwkeys.us.pgp.net). So I need to rewrite this part in order to take care of the keyserver html rendering. Would it not be sensible to use the same protocol as gpg uses with --recv-keys? Than it won't matter which keyserver is used. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Status of muffin?
Hi, what's the status of muffin in Debian? According to http://packages.qa.debian.org/m/muffin.html the last upload was in 2001, and the package seems to be dead upstream. Is this right? If so, how useful is this package now? If it is not too useful, I'd consider removing it from Debian. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible MIAs/ proposed forced orphanings
* Martin Michlmayr ([EMAIL PROTECTED]) [040228 15:55]: * Nathanael Nerode [EMAIL PROTECTED] [2004-02-23 14:18]: Roman Hodek [EMAIL PROTECTED] -- not maintaining or responding to bug reports for atari-bootstrap -- suggest orphaning atari-bootstrap *grr* He always claims how low maintenance his packages are because they don't change anyway, but he doesn't fix at least the RC bugs. Sent yet another mail. I'll probably also mail the m68k list. Roman was quite responsive as I asked him about the upload queue at uni-erlangen.de, so he is not really MIA. (He also said that they had a bit of trouble due to new hardware there.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
/org on klecker was full
Hi, I just noticed (due to being hinted in irc) that /org on klecker is out-of-space. As a first step weasel removed some old (i.e. pre-compromise) data, so it works again now. On looking more closely, I saw that /org/home large but due to the fact that klecker is restricted probably not useful to most developers anymore, so this could be a candidate for removal / moving to another machine. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Remove pgeasy from testing
* Martin Pitt ([EMAIL PROTECTED]) [040225 11:10]: So I would vote for removing it from testing, but to keep it in unstable for a while. What do you think? What shall I do in this case? Bug Report against ftp.d.o or qa.d.o? Normally: Speak with the release-team on [EMAIL PROTECTED] In this case, I just spoke with them on IRC. It's necessary to update postgresql in testing first, because otherwise removing pgeasy from testing is only possible with removing postgresql from testing, and that would not really be a good idea. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#204045: Bug#219143: remove packages from testing
* Frank Lichtenheld ([EMAIL PROTECTED]) [040223 00:40]: On Wed, Feb 18, 2004 at 11:00:52PM +0100, Andreas Barth wrote: mozart 204045 orphaned RC-bug since 2003-11-04, patch since 2003-11-12, nobody seems to care enough As the version in testing is lower than that in stable (security update) I would really recommend to remove this from testing. The problem is stated to be fixed in the upstream CVS but after a little digging into the upstream BTS I found it too much of work to do it in a QA Upload. (mozart-stdlib and mozart-gtk, the only packages that depend on it aren't even in testing) It's orphaned for three months now. We should even consider removing this from unstable soon. Well, that would be a pity, but if noone stands up, this could be the right thing to do. (I changed the To and Cc to send mail to QA, and added the former maintainer so that he gets a copy.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#219143: remove packages from testing
* Frank Lichtenheld ([EMAIL PROTECTED]) [040223 00:40]: On Wed, Feb 18, 2004 at 11:00:52PM +0100, Andreas Barth wrote: mozart 204045 orphaned RC-bug since 2003-11-04, patch since 2003-11-12, nobody seems to care enough As the version in testing is lower than that in stable (security update) I would really recommend to remove this from testing. The problem is stated to be fixed in the upstream CVS but after a little digging into the upstream BTS I found it too much of work to do it in a QA Upload. (mozart-stdlib and mozart-gtk, the only packages that depend on it aren't even in testing) It's orphaned for three months now. We should even consider removing this from unstable soon. Well, that would be a pity, but if noone stands up, this could be the right thing to do. (I changed the To and Cc to send mail to QA, and added the former maintainer so that he gets a copy.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#219143: remove drupal from testing?
Hi, what's the status of this RC-bug report? I suppose, we all want to get sarge out of the door rather soon now, and we need to reduce the number of RC-bugs for that. On the other hand, if this package is not fit for release, I think we should consider removing it from testing. So, I'll plead for that, if no fix is upload in the next 14 days. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#204045: remove mozart from testing?
Hi, what's the status of this RC-bug report? I suppose, we all want to get sarge out of the door rather soon now, and we need to reduce the number of RC-bugs for that. On the other hand, if this package is not fit for release, I think we should consider removing it from testing. So, I'll plead for that, if no fix is upload in the next 14 days. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
