Re: StrongARM tactics
Anthony Towns aj@azure.humbug.org.au writes: On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote: I can do the analyzing, but what should I do with the results? Put them on a webpage so anyone can see them, and if you don't find someone who'll give you an immediate response, track the issues over time so you can trivially demonstrate how big a benefit there would be if people would start paying attention. If you're using the BTS (by filing, analysing or fixing FTBFS bugs, eg), tracking the bugs with a usertag might be convenient and useful. (I don't know what the actual/perceived problem here is to give more detailed suggestions, sorry) Cheers, aj What is required is a buildd-give-back package_version (or whatever you called the alias for wanna-build --give-back). The buildd admin won't look at a webpage listing packages that need to be handled any more than he is looking at the list of packages left dangling without action. There is a big difference between packages that fail with some error and packages that fail with missing depends. I realy don't think users can do anything productive for the later unlike the real FTBFS errors where one can debug the problem, write a patch, submitt a bugreport and so on. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
[EMAIL PROTECTED] (Aaron M. Ucko) writes: Thomas Viehmann [EMAIL PROTECTED] writes: +pcsx: i386 # i386 assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. Write patch. At a minimum the package should be i386 amd64. In general anything with Arch: i386 should add amd64. Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because: [EMAIL PROTECTED]:~% zcat /mnt/mirror/debian/dists/sid/contrib/source/Sources.gz| grep-dctrl pcsx Package: pcsx Binary: pcsx Version: 1.6df-1 Priority: optional Section: contrib/games Maintainer: Ryan Schultz [EMAIL PROTECTED] Build-Depends: debhelper (= 4.0.0), x11proto-core-dev | x-dev, libgtk2.0-dev, zlib1g-dev | libz-dev Architecture: i386 Standards-Version: 3.6.2 Format: 1.0 Directory: pool/contrib/p/pcsx Files: 972b029160bdc0a1c6316d27280fe7ec 619 pcsx_1.6df-1.dsc c688e5da5ee3aa6a1b2377545d97a4e1 317340 pcsx_1.6df.orig.tar.gz 006f2f71b0dcc24ec2c76821504f03ec 2540 pcsx_1.6df-1.diff.gz wanna-build already filters the Architecture field of sources. The package will automaticaly only appear on i386. When more archs (or any) appear there wanna-build will pick it up for those archs automatically. MfG Goswin PS: policy dictates that where possible all archs has to be supported -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Bill Allombert [EMAIL PROTECTED] writes: Making buildd admin a purely administrative task while porters are not even trusted to do a binary upload is not going to work because you will never find volunteers accepting to work under theses terms. Thanks. My sentiment exactly. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
On Wed, Dec 07, 2005 at 04:48:24PM -0600, Bill Allombert wrote: On Tue, Dec 06, 2005 at 01:14:00AM -0800, Steve Langasek wrote: Saying that's the buildd admin's job about tasks that don't *need* to be done by the buildd admin is a pretty effective way of encouraging the problems that the Vancouver proposal sought to address, where two or three people end up carrying all the ports, and all their time is eaten up by maintaining the buildds and giving back failed packages with no time for following through on the permanent failures (which, even though they sometimes represent a minority of Maybe-Failed packages usually account for a majority of the actual work needing done). This go against the two basic rules for a volunteer organisation. 1) Volunteers doing the job should be people interested in doing it. 2) Responsibility should go to people that are going to do the job. Which translates here to: 1) Buildd admin should be people interested in supporting the port. 2) People that are going to support the port must get the responsibility. Which is great as a statement of principle, but it doesn't seem to offer much as a practical recommendation; you don't get to be a buildd maintainer by telling the current folks you aren't taking the right amount of pleasure in this -- better let me do it, you get there by working with the current folks and building a relationship with them and showing that you know what you're doing. Sorry, with a project that's a thousand strong, if they *do* care about the task, not too many people are going to turn it over to someone they don't know without first assuring themselves that they can handle it; and note that I never suggested the current buildd maintainers don't *care* about the ports they're helping with, they just don't have unlimited amounts of time to spend on single-handedly ensuring that ports keep up. BTW, I have no reason to believe that buildd maintenance in general is any more exciting or intrinsically rewarding than filing bugs on failed packages (and providing fixes for the same); so if people are going to balk at the latter task even though this is an area of porting that definitely (in some cases desperately) needs attention, what reason is there to think they're well-suited to being buildd maintainers either? Making buildd admin a purely administrative task while porters are not even trusted to do a binary upload is not going to work because you will never find volunteers accepting to work under theses terms. It seems like you're assuming that buildd admins and porters are two non-overlapping sets. On 6 of 11 architectures, at least one buildd admin is also a porter for that arch under the release requalification guidelines; on 7 of 11 architectures, at least one of the porters has wanna-build access for that arch. So it's certainly not the case that no porters are trusted to do binNMUs. If what you're arguing is that *all* porters should have wanna-build/buildd access (which is the best way to do binNMUs so that we get log files and consistent build envs), then I disagree. There's a heck of a lot of other work that porters would be better off spending their time on -- like, for instance, the unresolved build failures of perl on arm. I mean, it's possible you're right that porters are going to feel slighted if they don't have buildd access; but shouldn't porters' primary motivation be to make sure etch releases with a kick-ass Debian port for their architecture of choice? Should this really be about who holds the keys to the buildds? Isn't being a Debian porter already something to take pride in? If the Vancouver proposal is the constatation that the old model did not work the solution is to change the model, not to expect that people will suddenly accept it. Unless you are just looking at an excuse to remove ports, obviously. Fortunately there are no external organisations forcing the old model upon us, so there is no reason not to change it. All I really see here is that you've asserted that other (unspecified) porters should be given access to buildds that they don't necessarily want or need. Is this the new model you're referring to, or have I missed something? To be honest, it doesn't seem like much of a new model to me, just new people in the same roles. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
bugs.debian.org refusing mail?
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 The mail that I tried to send is as follows: * Return-Path: [EMAIL PROTECTED] Received: from localhost ([130.60.169.219]) by idmailgate1.unizh.ch (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id jB89ifPJ015483; Thu, 8 Dec 2005 10:44:44 +0100 Received: from localhost ([127.0.0.1] helo=localhost.localdomain ident=frank) by localhost with esmtp (Exim 4.50) id 1EkIKx-0006C2-8h; Thu, 08 Dec 2005 10:45:15 +0100 To: Arias Hung [EMAIL PROTECTED]; Cc: [EMAIL PROTECTED], Blars Blarson [EMAIL PROTECTED] Subject: Re: [SPAM?]: Bug#341827: same problem here X-Attribution: fant X-Ehrenamt: http://www.langau.de In-Reply-To: [EMAIL PROTECTED] (Hilmar Preusse's message of Thu, 8 Dec 2005 10:14:14 +0100) References: [EMAIL PROTECTED] [EMAIL PROTECTED] From: Frank Küster [EMAIL PROTECTED] Date: Thu, 08 Dec 2005 10:45:14 +0100 Message-ID: [EMAIL PROTECTED] User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-Virus-Scanned: by amavisd-new tags 341827 moreinfo tags 341922 moreinfo thanks Hilmar Preusse [EMAIL PROTECTED] wrote: On 08.12.05 Blars Blarson ([EMAIL PROTECTED]) wrote: Hi, I had the same problem. My /tmp/tetex.postinst.XX* file attached. 1. Thanks for the debug output. 2. What makes you believe, you're seeing the same bug? [...] on your installation only the LaTeX stuff fails. Unfortunately we can't investigate further until Arias send his log file. Ah, I didn't notice. So perhaps there are two separate issues. Maybe what Blars found is a real bug, but I think probably Arias has simply misconfigured his system badly - he also reported that he is unable to build the package, while it builds just fine on the buildds. Arias, without more input we won't be able to sort this out, I'm tagging the bugs moreinfo. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer * Any ideas what is going on? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: StrongARM tactics
On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: Thomas Viehmann [EMAIL PROTECTED] writes: +pcsx: i386 # i386 assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. Write patch. At a minimum the package should be i386 amd64. In general anything with Arch: i386 should add amd64. And is that certain to give a working 64-bit binary on amd64, or are you suggesting that we ship extra copies of 32-bit binaries for both i386 and amd64? Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because: [EMAIL PROTECTED]:~% zcat /mnt/mirror/debian/dists/sid/contrib/source/Sources.gz| grep-dctrl pcsx Package: pcsx Binary: pcsx Version: 1.6df-1 Priority: optional Section: contrib/games Maintainer: Ryan Schultz [EMAIL PROTECTED] Build-Depends: debhelper (= 4.0.0), x11proto-core-dev | x-dev, libgtk2.0-dev, zlib1g-dev | libz-dev Architecture: i386 Standards-Version: 3.6.2 Format: 1.0 Directory: pool/contrib/p/pcsx Files: 972b029160bdc0a1c6316d27280fe7ec 619 pcsx_1.6df-1.dsc c688e5da5ee3aa6a1b2377545d97a4e1 317340 pcsx_1.6df.orig.tar.gz 006f2f71b0dcc24ec2c76821504f03ec 2540 pcsx_1.6df-1.diff.gz wanna-build already filters the Architecture field of sources. No, it does not. It goes to the buildds with every sourceful upload, and fails when sbuild checks the architecture list. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
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]
buildd administration [was Re: StrongARM tactics]
Le jeudi 08 décembre 2005 à 02:03 -0800, Steve Langasek a écrit : Which translates here to: 1) Buildd admin should be people interested in supporting the port. 2) People that are going to support the port must get the responsibility. Which is great as a statement of principle, but it doesn't seem to offer much as a practical recommendation; you don't get to be a buildd maintainer by telling the current folks you aren't taking the right amount of pleasure in this -- better let me do it, you get there by working with the current folks and building a relationship with them and showing that you know what you're doing. Sorry, with a project that's a thousand strong, if they *do* care about the task, not too many people are going to turn it over to someone they don't know without first assuring themselves that they can handle it; and note that I never suggested the current buildd maintainers don't *care* about the ports they're helping with, they just don't have unlimited amounts of time to spend on single-handedly ensuring that ports keep up. As a result, no one can help with buildd maintenance as the current buildd admins won't let anyone help them, however overloaded they can be. They refuse to delegate any part of their powers because people aren't skilled enough, and people aren't skilled enough because they aren't allowed to help. I started my implication in the project four years ago. For four years, there have been problems with keyring maintenance and buildd administration. For four years, people responsible for these tasks have refused help on these matters. For four years, everything that was suggested on these topics haven't lead to any result, because these same people have simply ignored the suggestions. Can someone tell me when this nightmare is going to end? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Installation directory for modules
On Fri, Nov 25, 2005 at 07:05:48AM +, John Talbut wrote: When I run the Makefile below it installs the module in : /lib/modules/$(KERNELRELEASE)/extra As far as I can find out, this is the expected behaviour from the kbuild Makefiles. However, modprobe looks for modules in /lib/modules/`uname -r`. How can I get the modules to install in this directory? (Old thread, but I've just started a new job...) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330081 -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpdLOxmL4P1Y.pgp Description: PGP signature
Re: Bug#339658: should not call update-modules for module-init-tools
On Dec 05, Joey Hess [EMAIL PROTECTED] wrote: Anyway, if you add a depmod call to update-modules then debhelper could just run it and not worry about needing to run depmod. If OTOH you do want to eventually remove update-modules from module-init-tools then we will have to live with debhelper running depmod, possibly redundantly. Considering that nobody had better ideas, I'd rather remove the update-modules debianism in the future. Running depmod two times will not be a problem if you use -A, which checks the files timestamps before reading them. -- ciao, Marco signature.asc Description: Digital signature
Re: bugs.debian.org refusing mail?
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. 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. 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? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
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: buildd administration [was Re: StrongARM tactics]
On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote: As a result, no one can help with buildd maintenance as the current buildd admins won't let anyone help them, however overloaded they can be. They refuse to delegate any part of their powers because people aren't skilled enough, How do you know this is true? (Hint: I know it's not.) and people aren't skilled enough because they aren't allowed to help. Er, did you even *read* this thread? We got on the topic of buildds because *someone refused to help diagnose build failures because they consider it the buildd admin's job*. This is a concrete and specific task which needs attention, which doesn't require special access in order to work on, and by means of which developers can demonstrate their trustworthiness to buildd maintainers. Instead, people are telling me this is the buildd maintainer's job, and that no one is going to volunteer to do any porting work unless they are given the keys to the buildds in the process. The buildd maintainers are stopping people from helping? Like, WTF? I started my implication in the project four years ago. For four years, there have been problems with keyring maintenance and buildd administration. What problems are there today with buildd administration, please? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: buildd administration
[Josselin Mouette] I started my implication in the project four years ago. For four years, there have been problems with keyring maintenance and buildd administration. For four years, people responsible for these tasks have refused help on these matters. For four years, everything that was suggested on these topics haven't lead to any result, because these same people have simply ignored the suggestions. Can someone tell me when this nightmare is going to end? Perhaps it is time for a replacement buildd network, and a new delegation from the DPL for keyring maintenence? Setting up a buildd system do not require extra privileges from the Debian project, as far as I know. Any Debian developer with his public key in the keyring can sign uploads. The only privileges required to join the current buildd network is access to the build status database, and this make it hard for people on the outside of the current group of buildd maintainers to set up buildd machines in the existing buildd system out without help from the current buildd admins. But setting up ones own database is not only possible, it has been done in the past. Doing keyring maintenence on the other hand require special privileges from the Debian project, as there can be only one authorativ source for DD public keys, and it is not really useful for a separate entity to maintain another list of public keys. Because of this, a delegation from the DPL make sense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration [was Re: StrongARM tactics]
I don't know what's wrong but I think there is on principle, which shouldn't be forgotten. Try to understand first and then to be understood. I'd like to help, but may be I can't. Read Stephen Covey books. 2005/12/8, Steve Langasek [EMAIL PROTECTED]: On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote: As a result, no one can help with buildd maintenance as the current buildd admins won't let anyone help them, however overloaded they can be. They refuse to delegate any part of their powers because people aren't skilled enough, How do you know this is true? (Hint: I know it's not.) and people aren't skilled enough because they aren't allowed to help. Er, did you even *read* this thread? We got on the topic of buildds because *someone refused to help diagnose build failures because they consider it the buildd admin's job*. This is a concrete and specific task which needs attention, which doesn't require special access in order to work on, and by means of which developers can demonstrate their trustworthiness to buildd maintainers. Instead, people are telling me this is the buildd maintainer's job, and that no one is going to volunteer to do any porting work unless they are given the keys to the buildds in the process. The buildd maintainers are stopping people from helping? Like, WTF? I started my implication in the project four years ago. For four years, there have been problems with keyring maintenance and buildd administration. What problems are there today with buildd administration, please? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDmB/jKN6ufymYLloRAsn/AKChEi2vi3Kr1GbDEhwZbqVa19kbiACfeZxy KAWdD+XhpAEVMfS7G/rfdKU= =f1o5 -END PGP SIGNATURE-
Re: buildd administration
Steve Langasek [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote: I started my implication in the project four years ago. For four years, there have been problems with keyring maintenance and buildd administration. What problems are there today with buildd administration, please? One obvious problem is that there is no documented contact address (just search for buildd on http://www.debian.org/intro/organization). One has to know by some magic who is responsible for which architecture. One recent example where I had problems with buildd administration is http://bugs.debian.org/340279 First mail to [EMAIL PROTECTED] (which is the addres on the buildd logs) on Nov. 22, mail to debian-admin with Cc to debian-hppa on the same day, a mail to debian-admin with further information on Nov 25, one more on Nov 27. No visible reaction whatsoever, just the problems went away. Either someone fixed the buildd. If this has happened, he should have told us that we need not wait for the debug info we requested, but instead can close the RC bug on our package (or not, we don't know what the reason was). Or the problem went away by itself. In the latter case, I must assume it was a hardware problem, and it's only a question of time until the next package fails, and of some more time until sarti becomes unavailable completely. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: StrongARM tactics
Steve Langasek [EMAIL PROTECTED] writes: On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: Thomas Viehmann [EMAIL PROTECTED] writes: +pcsx: i386# i386 assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. Write patch. At a minimum the package should be i386 amd64. In general anything with Arch: i386 should add amd64. And is that certain to give a working 64-bit binary on amd64, or are you suggesting that we ship extra copies of 32-bit binaries for both i386 and amd64? The later if the former is not working. Since we have no multiarch yet and acceptance of patches leading up to it is going very slowly it looks like etch will remain without multiarch. So we need the extra copy to have something working. Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because: ... wanna-build already filters the Architecture field of sources. Small correction, quinn-diff does the actual filtering (here). No, it does not. It goes to the buildds with every sourceful upload, and fails when sbuild checks the architecture list. Hmm, must be just me then. Here quinn-diff already filters it out so it doesn't reaches wanna-build itself. But that might just be one of the several small differences to the official buildd suite. [EMAIL PROTECTED]:~/t% quinn-diff 21 | grep pcsx [quinn-diff]: ignoring: pcsx has an architecture field of i386 which doesn't include amd64. Makes no sense to include a source not for this arch. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Thu, Dec 08, 2005 at 01:39:27PM +0100, Frank Küster wrote: What problems are there today with buildd administration, please? One obvious problem is that there is no documented contact address (just search for buildd on http://www.debian.org/intro/organization). One has to know by some magic who is responsible for which architecture. Well, there are mail aliasses for each arch following the [EMAIL PROTECTED] scheme, but don't expect miracles from it (beside that sometimes problems seem to just go away silently ;)). Another possible resource might be http://www.buildd.net/ /adv ;) - I try to keep the information there as uptodate as possible, but it depends on the will to cowork with the buildd admins/porters, too. So, if someone has more information about buildds or other valueable information that is missed on buildd.net, just drop me a note... -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc signature.asc Description: Digital signature
Re: buildd administration
Steve Langasek [EMAIL PROTECTED] writes: On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote: and people aren't skilled enough because they aren't allowed to help. Er, did you even *read* this thread? We got on the topic of buildds because *someone refused to help diagnose build failures because they consider it the buildd admin's job*. This is a concrete and specific task which needs Did we? I remeber a maintainer checking his package wasn't build, the buildd log showing a trivial missing Build-Depends and requesting the package to be rescheduled for building. Or was that another thread with the same topic? attention, which doesn't require special access in order to work on, and by means of which developers can demonstrate their trustworthiness to buildd maintainers. Instead, people are telling me this is the buildd maintainer's job, and that no one is going to volunteer to do any porting work unless they are given the keys to the buildds in the process. Rescheduling a job that failed with a missing build-depends is the buildd admins job. Only people with wanna-build access can do that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Petter Reinholdtsen [EMAIL PROTECTED] writes: Setting up a buildd system do not require extra privileges from the Debian project, as far as I know. Any Debian developer with his public key in the keyring can sign uploads. The only privileges Upload of autobuild packages from inofficial buildds is forbidden and binary uploads of packages highly deprecated (autobuildability must be there or security support becomes a nightmare). Ever since the big flame last year when there was an inofficial network helping with the backlog for alpha, mips, mipsel, m68k and arm. required to join the current buildd network is access to the build status database, and this make it hard for people on the outside of the current group of buildd maintainers to set up buildd machines in the existing buildd system out without help from the current buildd admins. But setting up ones own database is not only possible, it has been done in the past. Two things are restricted: wanna-build - if you run your own then packages will be doubly build incoming.debian.org - Packages/Sources files are only available with user/pass That means that if you run your own w-b all of that arch has to switch. And without incoming access you add another 24h delay to builds. And you still have convince the same people giving buildd access that your network is trustworthy and may upload debs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master.debian.org bounces your mail
On Thu, 8 Dec 2005 08:07:36 +0100, Lionel Elie Mamane wrote: On Thu, Dec 08, 2005 at 01:39:15AM +0100, Wouter Verhelst wrote: On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote: I hope this is closer to a consensus... Afraid not. This proposal basically creates a second class of people -- those who we want to sign NDA's to be able to read stuff. That's even further away from 'openness and transparency' than the status quo. The idea that developers sometimes have private things to say is at least defendable; the idea that Debian is joining the NDA crap is not, IMNSHO. NDA's have a bad reputation in our community; sometimes they make sense. That's certainly true. However, given the context it would be good to investigate _why_ they have a bad reputation. The reason is that an NDA does not promote either transparency or openness; instead, it promotes obscurity and creates a lot of questions. In itself, there's nothing wrong with that; indeed, in some cases it would make sense to ask that some things are not disclosed---after all, there already is an NDA on -private, and that does make sense. However, if the intent is to promote openness and transparency, one should aim for less NDA's, not more; thus, I do not think it will promote openness and transparency if you allow another select group of people to read the archives, but do not allow them to share the information they have read. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- 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 04:39:46PM +0100, Jeroen van Wolffelaar wrote: When an exim mailserver is really bogged down under mail load, attempts can be made even less often. It's ben pointed out to me that my mail through master is also bouncing at times. I also have an IPv6 MX, so it could be related. However, another datapoint (and relevant to the above): top - 07:38:12 up 293 days, 15:52, 8 users, load average: 5.92, 5.39, 5.12 Tasks: 288 total, 6 running, 280 sleeping, 1 stopped, 1 zombie Cpu(s): 29.9% user, 18.9% system, 0.5% nice, 50.7% idle Mem: 2069780k total, 1981968k used,87812k free, 268648k buffers Swap: 284k total,35744k used, 1964340k free, 1132708k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 18353 clamav16 0 19560 18m 9672 R 33.9 0.9 12:20.88 clamd 18120 clamav16 0 19560 18m 9672 R 30.9 0.9 55:56.78 clamd 18360 clamav16 0 19560 18m 9672 R 30.9 0.9 2:33.51 clamd 31657 clamav15 0 19560 18m 9672 R 30.9 0.9 8:39.73 clamd 8251 clamav15 0 19560 18m 9672 R 14.7 0.9 0:02.64 clamd 14004 wouter16 0 1416 1416 1060 R 10.3 0.1 0:00.15 top 13930 Debian-e 10 0 3184 3176 2820 S 4.4 0.2 0:00.06 exim4 14010 root 11 0 3184 3176 3036 S 4.4 0.2 0:00.05 exim4 4562 root 9 0 31148 30m 8564 S 1.5 1.5 279:23.32 named 18357 clamav 9 0 19560 18m 9672 S 1.5 0.9 27:43.19 clamd 12311 www-data 9 0 4936 4160 3968 S 1.5 0.2 0:00.02 apache 12826 www-data 9 0 000 Z 1.5 0.0 0:00.02 apache defunct 14030 root 16 0 3164 3156 3036 S 1.5 0.2 0:00.01 exim4 14031 Debian-e 16 0 3232 3224 3052 D 1.5 0.2 0:00.01 exim4 1 root 8 0 472 440 420 S 0.0 0.0 243:01.96 init 2 root 9 0 000 S 0.0 0.0 0:01.57 keventd 3 root 19 19 000 S 0.0 0.0 0:13.91 ksoftirqd_CPU0 4 root 19 19 000 S 0.0 0.0 0:14.97 ksoftirqd_CPU1 5 root 9 0 000 S 0.0 0.0 3029:45 kswapd 6 root 9 0 000 S 0.0 0.0 60:08.08 bdflush That's on master. I've been watching it for about 5 minutes, and never saw the load drop below 3.80-ish. Could it be that master is simply imploding on the amount of mail received? -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master mail problems -- help needed
Wouter Verhelst [EMAIL PROTECTED] writes: That's on master. I've been watching it for about 5 minutes, and never saw the load drop below 3.80-ish. Could it be that master is simply imploding on the amount of mail received? It's always been like that (if not worse). -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Thu, Dec 08, 2005 at 02:04:28PM +0100, Goswin von Brederlow wrote: Rescheduling a job that failed with a missing build-depends is the buildd admins job. Only people with wanna-build access can do that. Correct, and the release managers don't consider this to be a problem at the moment. So nothing to see here, please move along. kthxbye, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Thu, Dec 08, 2005 at 01:01:10PM +0100, Petter Reinholdtsen wrote: [Josselin Mouette] I started my implication in the project four years ago. For four years, there have been problems with keyring maintenance and buildd administration. For four years, people responsible for these tasks have refused help on these matters. For four years, everything that was suggested on these topics haven't lead to any result, because these same people have simply ignored the suggestions. Can someone tell me when this nightmare is going to end? Perhaps it is time for a replacement buildd network, and a new delegation from the DPL for keyring maintenence? Anything else, while we're at it? Maybe you have missed something, so let's reiterate: The main problem of the arm port is *not* the buildd maintenance, but rather the lack of people fixing actual bugs, which is *not* the job of the buildd admin but of the porters. (as Steve pointed out, in some cases those sets overlap, but that just means the buildd guy gets to fix bugs with his porter hat on) I guess nobody says the buildd network does not have any issues, but they wane when compared to the lack of porting. Unfortunately, you do not seem to trust James' opinion on this, but why do you not trust our beloved Release Manager, either, who said he knew of no serious issues with buildd maintenance right now? Now, for the keyring stuff, please post to -project, as this is seems to be off-topic here. thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Em Qui, 2005-12-08 às 00:08 +0100, Gaudenz Steinlin escreveu: On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote: The first type of publication could embrace the entire content of debian-private, but restrictions will be applied for those who want to read, basically, the need of identification of the reader and the agreement to a NDA on the same terms applied to every debian developer about the privacy of the mailing list. One of the main goals of the original GR was to make the archives available for research. How will you be able to publish the results of such research if you agreed to an NDA. One of the main principles of scientific research is to make your results reproducible by others. This is impossible if you base your research on data which is only available under an NDA. As a Social Scientist, I must say that it's completely normal to make researchs using confidential resources. This only tells you that you should respect the privacy, but still lets you understand better the object of your research. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Em Qui, 2005-12-08 às 01:39 +0100, Wouter Verhelst escreveu: On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote: I hope this is closer to a consensus... Afraid not. This proposal basically creates a second class of people -- those who we want to sign NDA's to be able to read stuff. Well, if you're going to get access to information that if published could damage people, that's not surprise. There's a lot of personal information inside debian-private, which can be usefull for someone doing a research, but even then, should not be available to general public. That's even further away from 'openness and transparency' than the status quo. The idea that developers sometimes have private things to say is at least defendable; the idea that Debian is joining the NDA crap is not, IMNSHO. Well, Debian Developers today agree to a non-formal NDA about debian-private. I'm just suggesting that this could be extended for others who want to get access to the debian-private archive. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Em Qui, 2005-12-08 às 08:07 +0100, Lionel Elie Mamane escreveu: On Thu, Dec 08, 2005 at 01:39:15AM +0100, Wouter Verhelst wrote: On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote: The first type of publication could embrace the entire content of debian-private, but restrictions will be applied for those who want to read, basically, the need of identification of the reader and the agreement to a NDA on the same terms applied to every debian developer about the privacy of the mailing list. Well, if we let anybody read it, it has absolutely no point asking for an NDA. Your proposal says that anybody can get read it, if he signs an NDA. This procedure could be a useful tool if we restricted it to, say, people like Biella Coleman that have a real use, sanctioned by Debian and all, out of the_whole_ archive. (This should not keep us from opening up nearly everything else.) Well, I just wanted to keep my hands off judging for who we want to show it, I'm just saying hey, if you want to read, you can, as long as you respect the privacy of the mailing-list as every debian developer. But I want to remember that there is still the second form of publication, in which we select which content will be made public, and this will be available to anonymous readers. I hope this is closer to a consensus... Afraid not. This proposal basically creates a second class of people -- those who we want to sign NDA's to be able to read stuff. That's even further away from 'openness and transparency' than the status quo. The idea that developers sometimes have private things to say is at least defendable; the idea that Debian is joining the NDA crap is not, IMNSHO. NDA's have a bad reputation in our community; sometimes they make sense. They are just a formal version of yes, I understand the information I get is confidential; I will treat it as such. I think it makes sense for very selected readers that have a good use of the whole archive. It is indeed a bit silly if anyone can just sign it and get access. Why? I'm just saying it will be kept private, I mean, not going to be indexed by google, not appearing in a newspaper and, this way, protecting the authors. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Thu, Dec 08, 2005 at 01:01:10PM +0100, Petter Reinholdtsen wrote: [Josselin Mouette] I started my implication in the project four years ago. For four years, there have been problems with keyring maintenance and buildd administration. For four years, people responsible for these tasks have refused help on these matters. For four years, everything that was suggested on these topics haven't lead to any result, because these same people have simply ignored the suggestions. Can someone tell me when this nightmare is going to end? Uh, except for arm, m68k and hurd-i386; all the ports have sustained over 98% up-to-dateness for almost the entirety of the past month -- that was the major issue that made the Vancouver Nybbles document limit release architectures to i386, ppc and ia64. Steve's recent binNMUs of KDE for library transitions has pushed that down to 97% for a couple of architectures, and 96% for hppa, but if you go back just a few months, ia64, sparc, alpha, and s390 were all having problems staying above 95%, which has been the cut-off for consideration in testing for years now, with hppa even dropping below 90%. If you want the nightmare to end, I'd suggest you try opening your eyes. Perhaps it is time for a replacement buildd network, and a new delegation from the DPL for keyring maintenence? Whatever for, exactly? The buildd network's working better today than it has since woody released, IMO. I also see the keyring's been updated earlier this week, including both a replacement key for Horms from late last month, and Chip's requested updates. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
Le jeudi 08 décembre 2005 à 14:38 +0100, Michael Banck a écrit : Unfortunately, you do not seem to trust James' opinion on this, but why do you not trust our beloved Release Manager, either, who said he knew of no serious issues with buildd maintenance right now? Maybe because release managers said the same thing just before the expected sarge release, which was delayed several extra weeks because the security buildd network wasn't ready? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Bug#342547: ITP: asterisk-prompt-es -- Spanish prompts for the Asterisk PBX
Package: wnpp Severity: wishlist Owner: Victor Seva [EMAIL PROTECTED] * Package name: asterisk-prompt-es Version : x.y.z Upstream Author : Name [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Spanish prompts for the Asterisk PBX These are Spanish voicemail prompts for use with the Asterisk PBX, courtesy of Capatres Company. -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (900, 'stable'), (400, 'testing'), (300, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-386 Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration [was Re: StrongARM tactics]
Steve Langasek wrote: Er, did you even *read* this thread? We got on the topic of buildds because *someone refused to help diagnose build failures because they consider it the buildd admin's job*. Maybe it's not entirely impossible that the other subthread starting at | Wonderful. Nice to see that you think P-a-s entries are somebody | else's problem that should be handled centrally. and containing a few reports similar to Thiemo's | FWIW, I started to send mips patches for P-a-s, following the | procedure outlined at the top of this file. There was neither a | response nor any other discernable action. could have contributed to the buildd administration complaints? The reaction to my (admittedly less than optimal) attempt at an analysis that followed was not oh, do check these with porters and maintainers and then get back to me from someone who could then change the file, but half dozen people saying something to the effect I'm a porter/maintainer and were utterly unsucessful at my attempts to get anything done. I do appreciate your comments of proposed P-a-s additions that you think problematic but the rest of the thread rather spells don't bother. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Ingo Juergensmann [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 01:39:27PM +0100, Frank Küster wrote: What problems are there today with buildd administration, please? One obvious problem is that there is no documented contact address (just search for buildd on http://www.debian.org/intro/organization). One has to know by some magic who is responsible for which architecture. Well, there are mail aliasses for each arch following the [EMAIL PROTECTED] scheme, but don't expect miracles from it (beside that sometimes problems seem to just go away silently ;)). http://bugs.debian.org/342548 Why hasn't that been done before? Where else should this be documented? Another possible resource might be http://www.buildd.net/ /adv ;) - I try to keep the information there as uptodate as possible, but it depends on the will to cowork with the buildd admins/porters, too. Ah, that's even better, there's actual names behind the buildd's. I'll add that to the patch. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: StrongARM tactics
2005/12/8, Goswin von Brederlow [EMAIL PROTECTED]: Anthony Towns aj@azure.humbug.org.au writes:What is required is abuildd-give-back package_version(or whatever you called the alias for wanna-build --give-back). Following this train of thought, wouldn't it be reasonable to have a control @ buildd.debian.net that took simple commands like: give-back package version It could accept any email signed by a debian maintainer. Basic stuff like this is doesn't need to be restricted to just a few people.
Re: buildd administration
On Thu, Dec 08, 2005 at 04:35:14PM +0100, Frank Küster wrote: What problems are there today with buildd administration, please? One obvious problem is that there is no documented contact address (just search for buildd on http://www.debian.org/intro/organization). One has to know by some magic who is responsible for which architecture. Well, there are mail aliasses for each arch following the [EMAIL PROTECTED] scheme, but don't expect miracles from it (beside that sometimes problems seem to just go away silently ;)). http://bugs.debian.org/342548 Why hasn't that been done before? Where else should this be documented? Well, Steve wrote lately about the [EMAIL PROTECTED] mails: AIUI, the arch@buildd.debian.org addresses have a ridiculously low S:N ratio due to spam; moreover, they already receive build logs for each failed package build, and are generally quite capable of figuring out the source of a failure on their own, so receiving a second mail about a failure that's still in their inbox isn't necessarily all that useful. (http://lists.debian.org/debian-release/2005/12/msg00021.html) Another possible resource might be http://www.buildd.net/ /adv ;) - I try to keep the information there as uptodate as possible, but it depends on the will to cowork with the buildd admins/porters, too. Ah, that's even better, there's actual names behind the buildd's. I'll add that to the patch. OTOH, some people seem to disagree with you: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265142 I think that people should choose theirselves what they think is the best resource for them to find the needed information... ;) -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc signature.asc Description: Digital signature
Bug#342571: general: Apache1.3 and mod-php4: getlastmod() is broken
Package: general Severity: normal getlastmod() returns always the current time, filemtime() works as expected. php.net says: Apache and PHP have been compiled with the same value for -DFILE_OFFSET_BITS Perhaps this is the reason? -- System Information: Debian Release: 3.1 Architecture: i386 (i586) Kernel: Linux 2.4.27 Locale: LANG=de_DE, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 342571 to libapache-mod-php4
Processing commands for [EMAIL PROTECTED]: reassign 342571 libapache-mod-php4 Bug#342571: general: Apache1.3 and mod-php4: getlastmod() is broken Bug reassigned from package `general' to `libapache-mod-php4'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Ingo Juergensmann [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 04:35:14PM +0100, Frank Küster wrote: What problems are there today with buildd administration, please? One obvious problem is that there is no documented contact address (just search for buildd on http://www.debian.org/intro/organization). One has to know by some magic who is responsible for which architecture. Well, there are mail aliasses for each arch following the [EMAIL PROTECTED] scheme, but don't expect miracles from it (beside that sometimes problems seem to just go away silently ;)). http://bugs.debian.org/342548 Why hasn't that been done before? Where else should this be documented? Well, Steve wrote lately about the [EMAIL PROTECTED] mails: AIUI, the arch@buildd.debian.org addresses have a ridiculously low S:N ratio due to spam; This is a problem, but IMO not a justification for simply saying: No, we don't provide any contact address. moreover, they already receive build logs for each failed package build, and are generally quite capable of figuring out the source of a failure on their own, so receiving a second mail about a failure that's still in their inbox isn't necessarily all that useful. That's a problem either of educating the people that want to contact buildd admin's (to only do it when necessary), or of having enough persons behind that role account [EMAIL PROTECTED] Remember that we all receive superfluos mails as maintainers, like Hey, I also found out that your package cannot be installed, and I'm the 3rd one of them who doesn't check whether a bug has already been filed. I assume if appropriate information is available, people caring about buildd failures are more likely to understand when it's time to contact the buildd admin, then random users when to report a bug. Moreover, even if the admins are capable to figure out problems on their own, the maintainer and porters also deserve information. It's demotivating to not get any response when you ask for help a couple of times, try to reproduce the error in your environment without success, and not even be notified how the problem has finally been solved by the buildd admin. Another possible resource might be http://www.buildd.net/ /adv ;) - I try to keep the information there as uptodate as possible, but it depends on the will to cowork with the buildd admins/porters, too. Ah, that's even better, there's actual names behind the buildd's. I'll add that to the patch. OTOH, some people seem to disagree with you: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265142 I don't understand - this was about adding a link to buildd net to developer.php, I'm talking about documenting buildd admin's contact addresses in intro/organization. I think that people should choose theirselves what they think is the best resource for them to find the needed information... ;) I do think that too, but in order to allow that those resources must be made public. I haven't found buildd.net useful for me in the past, either, but I didn't know that it's the only place to get the names and e-mail of buildd admin's. The latter information should be available at some other place than buildd.net itself; maybe not only intro/organization, but also the developer's reference. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: StrongARM tactics
On Thursday 08 December 2005 04:41 am, you wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: Thomas Viehmann [EMAIL PROTECTED] writes: +pcsx: i386 # i386 assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. Write patch. At a minimum the package should be i386 amd64. In general anything with Arch: i386 should add amd64. PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even on i386. I don't know about amd64, but my other partially-ASM (using NASM like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that the same is true here -- I'll change it if someone can confirm that it will build and work. -- Ryan Schultz YOU RPN LOVE IF THEN HONK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Ryan Schultz [EMAIL PROTECTED] writes:
PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even
on i386. I don't know about amd64, but my other partially-ASM (using NASM
like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that
the same is true here -- I'll change it if someone can confirm that it will
build and work.
It built on my AMD64 system with a crude patch (attached, along with
the resulting log) that drops the CPU setting unconditionally, but I
haven't actually tested the result -- I built it mainly because I'm a
packrat. ;-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
diff -u pcsx-1.6df/debian/control pcsx-1.6df/debian/control
--- pcsx-1.6df/debian/control
+++ pcsx-1.6df/debian/control
@@ -6,7 +6,7 @@
Standards-Version: 3.6.2
Package: pcsx
-Architecture: i386
+Architecture: any
Depends: ${shlibs:Depends}
Recommends: psemu-sound, psemu-input, psemu-drive, psemu-video
Description: Sony PlayStation emulator
diff -u pcsx-1.6df/debian/changelog pcsx-1.6df/debian/changelog
--- pcsx-1.6df/debian/changelog
+++ pcsx-1.6df/debian/changelog
@@ -1,3 +1,12 @@
+pcsx (1.6df-1.0) unstable; urgency=low
+
+ * NMU of sorts (though no actual upload intended.)
+ * debian/control: Change architecture from i386 to any.
+ * Linux/Makefile: don't force CPU to ix86 (should be done conditionally
+in debian/rules).
+
+ -- Aaron M. Ucko [EMAIL PROTECTED] Mon, 28 Nov 2005 10:42:36 -0500
+
pcsx (1.6df-1) unstable; urgency=low
* Initial release Closes: #137355
only in patch2:
unchanged:
--- pcsx-1.6df.orig/Linux/Makefile
+++ pcsx-1.6df/Linux/Makefile
@@ -7,7 +7,7 @@
all: pcsx
-CPU = ix86
+# CPU = ix86
OPTIMIZE = -O2 -fomit-frame-pointer -finline-functions -ffast-math
FLAGS = -D__LINUX__ -DPCSX_VERSION=\${VERSION}\ -DPACKAGE=\pcsx\
dpkg-buildpackage: source package is pcsx
dpkg-buildpackage: source version is 1.6df-1.0
dpkg-buildpackage: source changed by Aaron M. Ucko [EMAIL PROTECTED]
dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh_testdir
# Add here commands to configure the package.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux ./configure --bindir=/usr/games
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for strip... strip
checking for rm... rm
checking for rmdir... rmdir
checking gtk+2... checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2.0 2.0.0... yes
checking GTK_CFLAGS... -DXTHREADS -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include
checking GTK_LIBS... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangoxft-1.0 -lpangox-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0
configure: creating ./config.status
config.status: creating Makefile.cfg
touch configure-stamp
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux /usr/bin/make clean
make[1]: Entering directory `/home/amu/src/pcsx/pcsx-1.6df/Linux'
rm -f Makefile.cfg
rm -f *.o ../*.o ..//*.o pcsx
rm -f config.*
make[1]: Leaving directory `/home/amu/src/pcsx/pcsx-1.6df/Linux'
dh_clean
dpkg-source -i -b pcsx-1.6df
dpkg-source: building pcsx using existing pcsx_1.6df.orig.tar.gz
dpkg-source: building pcsx in pcsx_1.6df-1.0.diff.gz
dpkg-source: building pcsx in pcsx_1.6df-1.0.dsc
debian/rules build
dh_testdir
# Add here commands to configure the package.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux ./configure --bindir=/usr/games
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of
Re: buildd administration
On Thu, Dec 08, 2005 at 06:45:09PM +0100, Frank Küster wrote: http://bugs.debian.org/342548 Why hasn't that been done before? Where else should this be documented? Well, Steve wrote lately about the [EMAIL PROTECTED] mails: AIUI, the arch@buildd.debian.org addresses have a ridiculously low S:N ratio due to spam; This is a problem, but IMO not a justification for simply saying: No, we don't provide any contact address. Sure, there's always something that is not as well documented as it should be... ;) moreover, they already receive build logs for each failed package build, and are generally quite capable of figuring out the source of a failure on their own, so receiving a second mail about a failure that's still in their inbox isn't necessarily all that useful. That's a problem either of educating the people that want to contact buildd admin's (to only do it when necessary), or of having enough persons behind that role account [EMAIL PROTECTED] Remember that we all receive superfluos mails as maintainers, like Hey, I also found out that your package cannot be installed, and I'm the 3rd one of them who doesn't check whether a bug has already been filed. I assume if appropriate information is available, people caring about buildd failures are more likely to understand when it's time to contact the buildd admin, then random users when to report a bug. That's one part I try to achieve with buildd.net: to give as much information as possible about the buildd process. The main focus is the buildd itself: is it down, when will be my package built, etc... When you do a package search on buildd.net there are some links to other sites to give you easy access to even more information. If someone writes a nice paper about buildds, common problems or such (or sends me a pointer to such things), I'll happily include that on buildd.net. Moreover, even if the admins are capable to figure out problems on their own, the maintainer and porters also deserve information. It's demotivating to not get any response when you ask for help a couple of times, try to reproduce the error in your environment without success, and not even be notified how the problem has finally been solved by the buildd admin. True. There is much space for improvements on both sides. Another possible resource might be http://www.buildd.net/ /adv ;) - I try to keep the information there as uptodate as possible, but it depends on the will to cowork with the buildd admins/porters, too. Ah, that's even better, there's actual names behind the buildd's. I'll add that to the patch. OTOH, some people seem to disagree with you: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265142 I don't understand - this was about adding a link to buildd net to developer.php, I'm talking about documenting buildd admin's contact addresses in intro/organization. Well, I was aiming towards the point that some persons might dislike me and therefore refuse to add links to buildd.net. ;) I think that people should choose theirselves what they think is the best resource for them to find the needed information... ;) I do think that too, but in order to allow that those resources must be made public. I haven't found buildd.net useful for me in the past, Feature requests and other things are always welcome! I can't know what you want until you tell it to me. ;) either, but I didn't know that it's the only place to get the names and e-mail of buildd admin's. I would be happy when I could get updates about buildds, buildd admins and such from time to time. Information is only good when it is acurate and uptodate. Take the machines.cgi on db.d.o for example. It is quite often outdated, which is why I tried to work around that problem by using dynamic status updates via a small scripts from the buildds. But that's a different story. The point is: when someone knows the information on buildd.net is wrong, please let me know! The latter information should be available at some other place than buildd.net itself; maybe not only intro/organization, but also the developer's reference. After a talk with Christoph Berg, we agreed that I'll add (somewhen ;) a new search page on buildd.net that will be linked on the developer.php page. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc signature.asc Description: Digital signature
Re: buildd administration
Steve Langasek [EMAIL PROTECTED] writes: Er, did you even *read* this thread? We got on the topic of buildds because *someone refused to help diagnose build failures because they consider it the buildd admin's job*. NO. We got on the topif of this because I said that I was not interested in diagnosing build failures, since when I had done so in the past, my diagnoses seemed to be ignored, and the diagnosing seems to have been entirely wasted work. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
On Thursday 08 December 2005 01:44 pm, Aaron M. Ucko wrote: Ryan Schultz [EMAIL PROTECTED] writes: PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even on i386. I don't know about amd64, but my other partially-ASM (using NASM like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that the same is true here -- I'll change it if someone can confirm that it will build and work. It built on my AMD64 system with a crude patch (attached, along with the resulting log) that drops the CPU setting unconditionally, but I haven't actually tested the result -- I built it mainly because I'm a packrat. ;-) I can't get a clean pdebuild[1] on i386 with that setting dropped, which seems unusual -- it fails during linking. I'll hack something up for the rules file, in any case, and contact my sponsor; I have a new upload ready anyway. [1] ../PsxMem.o: In function `psxMemWrite8':PsxMem.c:(.text+0x530): undefined reference to `psxRecLUT' ../PsxMem.o: In function `psxMemWrite16':PsxMem.c:(.text+0x5b1): undefined reference to `psxRecLUT' ../PsxMem.o: In function `psxMemWrite32':PsxMem.c:(.text+0x656): undefined reference to `psxRecLUT' :PsxMem.c:(.text+0x691): undefined reference to `psxRecLUT' ../Misc.o: In function `RecvPcsxInfo':Misc.c:(.text+0x1856): undefined reference to `psxRec' ../R3000A.o: In function `psxInit':R3000A.c:(.text+0x1c): undefined reference to `psxRec' Gtk2Gui.o: In function `OnCpu_Ok':Gtk2Gui.c:(.text+0x1af6): undefined reference to `psxRec' -- Ryan Schultz YOU RPN LOVE IF THEN HONK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
circular (source) dependencies!?
I'm trying to build autoconf/automake on my semi woody... But that isn't going to well (to say the least). I really hate these two programs. It's always a mess to build them if you don't follow the latest and greatest (probably no faults to the maintainers though!)... Any idea how to get around this (easily)? Can this be fixed in the packages? - s n i p - Aurora/WOODY# debuild -uc -us -sa dpkg-buildpackage: source package is automake1.8 dpkg-buildpackage: source version is 1.8.5-3 dpkg-buildpackage: source maintainer is Eric Dorland [EMAIL PROTECTED] dpkg-buildpackage: host architecture is sparc dpkg-checkbuilddeps: Unmet build dependencies: autoconf (= 2.59), debhelper (\ = 4.1.0), texinfo (= 4.2) dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: (Use -d flag to override.) debuild: fatal error at line 456: dpkg-buildpackage failed! Aurora/WOODY# debuild -uc -us -sa dpkg-buildpackage: source package is autoconf dpkg-buildpackage: source version is 2.59a-7 dpkg-buildpackage: source maintainer is Ben Pfaff [EMAIL PROTECTED] dpkg-buildpackage: host architecture is sparc dpkg-checkbuilddeps: Unmet build dependencies: texinfo (= 4.6), automake1.9 dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: (Use -d flag to override.) debuild: fatal error at line 456: dpkg-buildpackage failed! Aurora/WOODY# debuild -uc -us -sa dpkg-buildpackage: source package is automake1.9 dpkg-buildpackage: source version is 1.9.6-1 dpkg-buildpackage: source maintainer is Eric Dorland [EMAIL PROTECTED] dpkg-buildpackage: host architecture is sparc dpkg-checkbuilddeps: Unmet build dependencies: autoconf (= 2.59), debhelper (\ = 4.1.0), texinfo (= 4.2) dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: (Use -d flag to override.) debuild: fatal error at line 456: dpkg-buildpackage failed! - s n i p - -- North Korea 767 explosion Ortega Clinton class struggle attack [Hello to all my fans in domestic surveillance] Rule Psix kibo security 747 BATF Saddam Hussein CIA [See http://www.aclu.org/echelonwatch/index.html for more about this] [Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf] If neither of these works, try http://www.aclu.org and search for echelon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mailing list administration - add default Mail-Followup-To automatically
On Thu, Dec 08, 2005 at 07:36:34PM +0100, Simon Josefsson wrote: When using the Debian mailing lists, please follow these rules: . When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied. Couldn't the list manager add the proper Mail-Followup-To, if it is not already present? I'm reading this mailing list through gmane.org. It is not scalable to manually check all the rules of various groups, even if doing so would be courteous. Maybe; I don't know if that would cause any problems. In case anyone thinks this is a good idea and wants to implement it (or if anyone less ambivalent than me wants to push for it), I'll CC to d-devel. That rule is problematic if non-members post to the list, either directly or accidentally by participating in a cross-posted discussion. I think people tend to give more leeway when a discussion is being cross- posted and they get unwanted CCs. (People are usually busy just making sure the conversation stays on both lists.) It's a more reasonable default on most lists: usually, most people in a discussion are subscribed. It makes more sense to me to require that the few people posting to a list unsubscribed set a header saying so, than the majority of people posting subscribed do so. -- Glenn Maynard -- 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 03:00:58PM +0100, Romain Francoise wrote: Wouter Verhelst [EMAIL PROTECTED] writes: That's on master. I've been watching it for about 5 minutes, and never saw the load drop below 3.80-ish. Could it be that master is simply imploding on the amount of mail received? It's always been like that (if not worse). Not that I recall. But then, I'm not really all that familiar with master, so let's assume it's indeed something else. 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. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- 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 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 :) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Ingo Juergensmann [EMAIL PROTECTED] wrote: I think that people should choose theirselves what they think is the best resource for them to find the needed information... ;) I do think that too, but in order to allow that those resources must be made public. I haven't found buildd.net useful for me in the past, 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... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: master mail problems -- help needed
* 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
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. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc signature.asc Description: Digital signature
Re: buildd administration
Michael Banck wrote: The main problem of the arm port is *not* the buildd maintenance, but rather the lack of people fixing actual bugs, which is *not* the job of the buildd admin but of the porters. Saying it doesn't make it true. In fact, people who have volunteered to diagnose bugs in the past -- specifically Thomas Bushnell BSD -- have stated that they have become dispirited and unwilling to do so *because* of the behavior of the buildd maintainers; to wit, ignoring their diagnosis work. So, provide better evidence for your claim please. Unfortunately, you do not seem to trust James' opinion on this, but why do you not trust our beloved Release Manager, either, who said he knew of no serious issues with buildd maintenance right now? Why should either of them know, to be perfectly frank? This is argument by authority, not an actual argument. -- Nathanael Nerode [EMAIL PROTECTED] Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Petter Reinholdtsen wrote: Perhaps it is time for a replacement buildd network, and a new delegation from the DPL for keyring maintenence? Anthony Towns wrote: Whatever for, exactly? Transparency. You understand transparency, I know, since you practice a great deal of transparency in your own Debian work, as is clear from your blog. Many kudos to you for that. Another developer who practices transparency to a great degree is Steve Langasek, who *always* seems to have time to answer a question -- or even to respond to a comment, which is actually more than is needed. When things go wrong, there is no useful contact address for the buildd maintainers or admins. There is also no feedback from buildd maintainers/admins or keyring maintainers regarding whether a request has been receieved. It's like dropping wishes into a wishing well and then waiting to see whether they come true. The fact that the wishing well appears to be working unusually well at the moment is almost beside the point. The buildd network's working better today than it has since woody released, IMO. Yes. I wonder why? There's no way to tell what's changed, who's done it, or when it will stop being true. Meanwhile, buildd.debian.org *still* isn't using Ingo Juergesmann's much-much-better buildd.net status scripts. For no apparent reason. Certain buildd admins aren't cooperating with the buildd status lines on that site either. For no apparent reason. There's nobody to contact to explain why, because the contact points for these things act like wishing wells. To respond preemptively to one expected reply: I don't have time to answer these questions is not a reasonable excuse, because if they don't have time, they need to ask for help. If they don't think that anyone is skilled or trustworthy enough to help with the work they're already doing, then (a) they're probably wrong, and (b) at any rate there is certainly someone skilled and trustworthy enough to act as 'press secretary' for them, collecting all the questions from the outside and returning the answers to the outside! I also see the keyring's been updated earlier this week, including both a replacement key for Horms from late last month, and Chip's requested updates. Indeed, complaining on debian-devel appears to get results, doesn't it? At least, that's the conclusion that a rational outside observer would come to. If that's an inaccurate conclusion, it indicates that there's something seriously wrong in the transparency of the processes. -- Nathanael Nerode [EMAIL PROTECTED] Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
CC:ing you because this is sufficiently important I want to make sure you notice that I'm actually answering what may have been a rhetorical question. What problems are there today with buildd administration, please? No clearly-documented contact addresses for buildd administrators (as noted upthread). Mail to any of the apparent contact addresses receives no replies. Accordingly, there is no way to tell whether a message has been heard. If a package is requeued (or whatever) there is no way to tell which of the several addresses you sent mail to had an effect, or if it happened on its own. If nothing happens, there is no way to tell whether your mail was lost in transit, or whether the buildd administrator retried it and found some problem without telling you, or whether the package is in some kind of dependency-wait state for reasons you don't know about. This lack of transparency and lack of contact addresses is particularly annoying for packages which have built and not been uploaded, which should be trivial to deal with, but aren't. Plus, no useful contact address for buildd.debian.org, and effectively no way to get any improved scripts moved onto it. That enough problems for you? :-P Contrast to the incredibly transparent operations of debian-release, or the ease of getting patches added to the PTS (packages.qa.debian.org) scripts. Or indeed the less-transparent but still fairly responsive BTS maintainers. It is of course possible that for you, all the correct email addresses are known, and all the people at them reply to you. If so, please know that that is not how it is working for most people. The only replies I've ever received from contacting (what I thought was) a buildd admin address were Sorry, I'm not the buildd admin. Apologies for the thread-breaking, I'm reading on the web pages again. :-/ -- Nathanael Nerode [EMAIL PROTECTED] Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel notebooks for needy developers in developing countries
I can´t belive... this is true...2005/12/8, Andreas Schuldei [EMAIL PROTECTED]: Intel is so generous to provide Debian with ten notebooks (besidessome server hardware), which we would like to give to developersin developing countries who- are technically able,- are dedicated to Debian, - would be able to contribute more/better to Debian with thishardware- would not be able to afford a computer, otherwise.If you know such a person, please let me know ASAP. I would liketo have recommendations from others about this person and would need a list of things that person works on in Debian. Given thethin web of trust in those parts of the world it would not berequired for this person to be a Debian Developer, eventhough itwould help. The shipment would happen domestically, so no customs would needto be payed. Please provide the full shipping address, along withthe recommendation.If we receive more then ten recommendations (which i hope for) the Intel representative responsible for Debian would select thereceipients of the notebooks.-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2 (GNU/Linux)iD8DBQFDmJLa8g+sC3uDV+URAjlvAJ9HYugEki5cp5Nwu5Fa2tCdbnShBgCfQEx4 BUj8jNX7sLnlgEwImLNTxkI==tCBO-END PGP SIGNATURE--- ICQ 156652591lucas souza fernandes
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, I don't think so. and would you notice the bounces? I wouldn't get bounces, people sending me mail on [EMAIL PROTECTED] would. You also have one IPv4-only MX, No, I don't. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master mail problems -- help needed
* Lionel Elie Mamane: You also have one IPv4-only MX, No, I don't. But Exim 4 thinks so: [EMAIL PROTECTED] router = dnslookup, transport = remote_smtp host capsaicin.mamane.lu [2001:888:19f0::2] MX=9 host capsaicin.mamane.lu [2001:888:19f0:2::2] MX=9 host quorn.mamane.lu [213.84.114.29] MX=10 host tofu.mamane.lu [2001:888:19f0:0:210:5aff:fe45:9b17] MX=11 host a.mx.conuropsis.org [2001:838:300:241::2]MX=30 host a.mx.conuropsis.org [217.115.192.216]MX=30 My local BIND omits a few records from the answer to mamane.lu/IN/MX to bring it below the 512 byte limit (it may do so, after all it's just the addtitional section). I would have thought that Exim queried for records if necessary, but this seems to be wrong. -- 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 11:57:58PM +0100, Florian Weimer wrote: * Lionel Elie Mamane: You also have one IPv4-only MX, No, I don't. But Exim 4 thinks so: [EMAIL PROTECTED] router = dnslookup, transport = remote_smtp host capsaicin.mamane.lu [2001:888:19f0::2] MX=9 host capsaicin.mamane.lu [2001:888:19f0:2::2] MX=9 host quorn.mamane.lu [213.84.114.29] MX=10 host tofu.mamane.lu [2001:888:19f0:0:210:5aff:fe45:9b17] MX=11 host a.mx.conuropsis.org [2001:838:300:241::2]MX=30 host a.mx.conuropsis.org [217.115.192.216]MX=30 I see. My local BIND omits a few records from the answer to mamane.lu/IN/MX to bring it below the 512 byte limit (it may do so, after all it's just the addtitional section). I would have thought that Exim queried for records if necessary, but this seems to be wrong. Well, I've dropped tofu from the MX list now, so maybe quorn's record will make it back in (after TTL expires)? -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel notebooks for needy developers in developing countries
On Thu, Dec 08, 2005 at 09:08:58PM +0100, Andreas Schuldei wrote: Intel is so generous to provide Debian with ten notebooks (besides some server hardware), which we would like to give to developers in developing countries who What exacly did you mean writing about 'developing countries'? regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: StrongARM tactics
Ryan Schultz [EMAIL PROTECTED] writes: On Thursday 08 December 2005 04:41 am, you wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: Thomas Viehmann [EMAIL PROTECTED] writes: +pcsx: i386# i386 assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. Write patch. At a minimum the package should be i386 amd64. In general anything with Arch: i386 should add amd64. PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even on i386. I don't know about amd64, but my other partially-ASM (using NASM like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that the same is true here -- I'll change it if someone can confirm that it will build and work. They will if you do it right. Look at lilo, grub or that other bootloader amd64 has. Basicaly you just have to use gcc -m32 for the C/asm code you compile with gcc. nasm should always make 32bit code I think. You will need any libs you use (apart from libc6, zlib and a few more X libs that ia32-libs has already) as 32bit version though, if any. It probably will need some work to get it to build but it would be worth it. Ask on debian-amd64 for someone to help porting if you are willing to support this in the future. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel notebooks for needy developers in developing countries
* Bartosz Fenski aka fEnIo [EMAIL PROTECTED] [2005-12-09 00:30:09]: On Thu, Dec 08, 2005 at 09:08:58PM +0100, Andreas Schuldei wrote: Intel is so generous to provide Debian with ten notebooks (besides some server hardware), which we would like to give to developers in developing countries who What exacly did you mean writing about 'developing countries'? i meant countries/persons who can not have a hope of buying a computer (but only use one in the computer room in their university or their neighbour's for their debian work) and who's income is so low that they would need many months savings of their complete income to be able to afford a cheap one. i can try to come up with a list of countries if it helps. signature.asc Description: Digital signature
Re: StrongARM tactics
On Thu, Dec 08, 2005 at 01:52:51PM +0100, Goswin von Brederlow wrote: Steve Langasek [EMAIL PROTECTED] writes: On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: Thomas Viehmann [EMAIL PROTECTED] writes: +pcsx: i386 # i386 assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. Write patch. At a minimum the package should be i386 amd64. In general anything with Arch: i386 should add amd64. And is that certain to give a working 64-bit binary on amd64, or are you suggesting that we ship extra copies of 32-bit binaries for both i386 and amd64? The later if the former is not working. Since we have no multiarch yet and acceptance of patches leading up to it is going very slowly it looks like etch will remain without multiarch. So we need the extra copy to have something working. And for this you want to add hackish patches to console emulator packages? I think the amd64 port can live for a while without a Playstation emulator while we sort out how to cope with cross-installing of i386 packages. Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because: ... wanna-build already filters the Architecture field of sources. Small correction, quinn-diff does the actual filtering (here). No, it does not. It goes to the buildds with every sourceful upload, and fails when sbuild checks the architecture list. Hmm, must be just me then. Here quinn-diff already filters it out so it doesn't reaches wanna-build itself. But that might just be one of the several small differences to the official buildd suite. [EMAIL PROTECTED]:~/t% quinn-diff 21 | grep pcsx [quinn-diff]: ignoring: pcsx has an architecture field of i386 which doesn't include amd64. Right; it is quinn-diff that does the filtering; and the quinn-diff on buildd.d.o does not filter on the package-provided Architecture: list. Makes no sense to include a source not for this arch. On the contrary, I think it's a bad idea for quinn-diff to look at package Architecture: fields directly, just like it would be a bad idea for dak to let maintainers change Section: values directly. You want porter oversight of the list of packages that are being excluded on an arch, and having these show up as build failures gives you that oversight. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
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]
Re: cvs loginfo configuration for alioth?
Hi, I'm looking for a 'loginfo' file configuration that works for alioth. I thought I have found a solution few days ago, but when I came back, it no longer seems to work correctly: The script used in debian-gis repo (pkg-grass) works like a charm. Feel free to use it... I also looked around a bit to have a working program after alioth upgrade. It seems to come with zero documentation, but the required configuration seems to be 1. copy the file log_accum.pl into CVSROOT/ 2. add the following kind of entry to CVSROOT/loginfo # default behavior: send commit logs to tokyodebian-commits DEFAULT $CVSROOT/CVSROOT/log_accum.pl -u $USER %s # log_accum.pl needs to be added, and checkoutlist be updated 3. edit CVSROOT/log_accum.pl so that it has proper mail address 4. mkdir $CVSROOT/commitlogs (in the repository) for commit logs It looks like it's working. Thanks for the info. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel notebooks for needy developers in developing countries
Andreas Schuldei wrote: * Bartosz Fenski aka fEnIo [EMAIL PROTECTED] [2005-12-09 00:30:09]: On Thu, Dec 08, 2005 at 09:08:58PM +0100, Andreas Schuldei wrote: Intel is so generous to provide Debian with ten notebooks (besides some server hardware), which we would like to give to developers in developing countries who What exacly did you mean writing about 'developing countries'? i meant countries/persons who can not have a hope of buying a computer (but only use one in the computer room in their university or their neighbour's for their debian work) and who's income is so low that they would need many months savings of their complete income to be able to afford a cheap one. i can try to come up with a list of countries if it helps. Is not about the country. Is the fact that some people can't have the option to choose from a $1200 to a $100 computer. Or maybe, not even that. Don't generalize by saying the name of a country. .Alejandro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Followups set to -vote; can we please keep this on the list that's designed for these discussions? On Thu, Dec 08, 2005 at 11:24:52AM -0300, Daniel Ruoso wrote: There's a lot of personal information inside debian-private, There is? I got 36 of 494 messages (7%) for the month I did, with an additional 55 odd spam messages (11%). See master:~ajt/d-p.200211 and d-p.200211.boring. I'd love to see a second take on that sort of analysis, either for the same month or different ones. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote: Petter Reinholdtsen wrote: Perhaps it is time for a replacement buildd network, and a new delegation from the DPL for keyring maintenence? Anthony Towns wrote: Whatever for, exactly? Transparency. 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. When things go wrong, there is no useful contact address for the buildd maintainers or admins. Well, the question is are things wrong ? AFAICS, they aren't -- and when I suggested building a webpage tracking the complaints, the only response was ha, what a waste of time. I don't really understand the viewpoint that says fixing the problem isn't a response to pointing out a problem. The buildd network's working better today than it has since woody released, IMO. Yes. I wonder why? It started working well in the same week we did the etch requalification process. There's no way to tell what's changed, who's done it, or when it will stop being true. TTBOMK, porters started taking their ports more seriously. Meanwhile, buildd.debian.org *still* isn't using Ingo Juergesmann's Ingo's burnt a fair number of bridges wrt buildd issues; I'm sorry, but I don't really care if volunteers decline to work with people who're obnoxious and rude. To respond preemptively to one expected reply: I don't have time to answer these questions is not a reasonable excuse, because if they don't have time, they need to ask for help. That's not a productive attitude. If they don't have time to answer questions, they almost certainly don't have time to ask for help, either. When that cirucmstance has arisen, the only way out is for others to work out what help's actually needed and wanted and to provide it. That's kinda hard, but no one promised taking over the world would be easy. I also see the keyring's been updated earlier this week, including both a replacement key for Horms from late last month, and Chip's requested updates. Indeed, complaining on debian-devel appears to get results, doesn't it? No, it doesn't. At least, that's the conclusion that a rational outside observer would come to. No, it's the conclusion a simplistic outside observer would come to, who failed to consider the possibility that the results may have come due to independent processes in spite of the hysterical complaints on debian-devel. It may be rational to note that that conclusion is being irrationally drawn, and start responding to hysterical complaints by delaying activities that'd otherwise be undertaken, of course. I'm idealistic enough to dislike that conclusion, but, well *shrug*. Cheers, aj signature.asc Description: Digital signature
Re: cvs loginfo configuration for alioth?
It seems like folks have found good solutions for their problems already, but just for the hell of it, I thought I'd mention that I maintain a CVS commit reporting script mostly because the other ones I'd found didn't seem to do quite enough or were poorly documented. It's at: http://www.eyrie.org/~eagle/software/cvslog/ and while I've not used it specifically with Alioth, I'd be happy to respond to any reports of issues or requests for additional features. (I know the option handling needs some improvement; I plan on rewriting it shortly to use the same approach that my similar svnlog program for Subversion uses.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
thank GOD I found you! How do I get them?
iih
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: 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. That tells us what the buildds are doing. It doesn't tell us anything about what the buildd admins are doing. Well, the question is are things wrong ? AFAICS, they aren't -- and when I suggested building a webpage tracking the complaints, the only response was ha, what a waste of time. Can you explain then why my recent request went unanswered for a month? Ingo's burnt a fair number of bridges wrt buildd issues; I'm sorry, but I don't really care if volunteers decline to work with people who're obnoxious and rude. I do. For some positions in Debian, we need people who will work with everyone in the project. When we have set things up so that there is a single point of failure for a task, it is important to make sure that one of the skills that single-point has is a very thick skin and a willingness to work with people who are obnoxious and rude. If we *cannot* find such a person, we might have to settle for second best. But let's look for one first. That's not a productive attitude. If they don't have time to answer questions, they almost certainly don't have time to ask for help, either. Hogwash. What seems to be absent from the mind of the people responsible is that when they don't have time, they can say I don't have time to do this job anymore; I'm sorry, but I really would like to step down. We are a mature project, we can find volunteers for these tasks. Nobody is doing a task in Debian which only they could do. Nothing anyone does is so special and magic that nobody else could figure it out. What I think we have is *fiefdoms* in which people have tied their ego together with doing certain tasks, and they are desperate to continue to control those tasks, even if their ability to do them efficiently has long since left the building. I had hope that when we elected the current DPL and DPL team that some of this would change. Instead, we have the same damn problem. Fiefdoms, unaccountability, and DPL inaction. It may be rational to note that that conclusion is being irrationally drawn, and start responding to hysterical complaints by delaying activities that'd otherwise be undertaken, of course. I'm idealistic enough to dislike that conclusion, but, well *shrug*. It is clear that some of the fiefdoms are run by people who adopt this attitude: If you criticize me publicly, then I will slow-pedal your requests. This is an infantile and counterproductive attempt to maintain control and a sense of superiority. It has no place in a project such as ours. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need pain pills?please tell me how w/out prescri.
Work-needing packages report for Dec 9, 2005
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 188 (new: 4) Total number of packages offered up for adoption: 91 (new: 1) Total number of packages requested help for: 21 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: cpbk (#341724), orphaned 6 days ago Description: a mirroring utility for backing up your files Installations reported by Popcon: 39 elvis (#341821), orphaned 5 days ago Description: powerful clone of the vi/ex text editor Reverse Depends: elvis-tools elvis-console elvis Installations reported by Popcon: 136 gtk-engines-begtk (#342454), orphaned yesterday Installations reported by Popcon: 358 qps (#341907), orphaned 5 days ago Description: Qt based process status Installations reported by Popcon: 65 184 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: rscheme (#341874), offered 5 days ago Description: Threaded, persistent, OO, scheme interpreter and compiler Installations reported by Popcon: 12 90 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: aboot (#315592), requested 168 days ago Description: Alpha bootloader: Looking for co-maintainers Reverse Depends: aboot-cross ltsp-server dfsbuild aboot Installations reported by Popcon: 50 athcool (#278442), requested 408 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 202 debtags (#321654), requested 124 days ago Description: Enables support for package tags Reverse Depends: debtags-edit Installations reported by Popcon: 422 dselect (#282283), requested 383 days ago Description: a user tool to manage Debian packages fetchmail (#331642), requested 65 days ago Description: SSL enabled POP3, APOP, IMAP mail gatherer/forwarder Reverse Depends: fetchmail-ssl fetchmailconf webmin-fetchmail Installations reported by Popcon: 2476 grub (#248397), requested 577 days ago Description: GRand Unified Bootloader Reverse Depends: webmin-grub grubconf replicator dfsbuild grub-splashimages Installations reported by Popcon: 6379 gtkpod (#319711), requested 137 days ago Description: manage songs and playlists on an Apple iPod Installations reported by Popcon: 212 gutenbrowser (#331203), requested 67 days ago Description: Project Gutenberg Etext reader Installations reported by Popcon: 53 lib (#329966), requested 75 days ago Description: Perl interfaces to the Gtk and Gnome libraries lsdvd (#316922), requested 157 days ago Description: read the contents of a DVD Installations reported by Popcon: 678 mwavem (#313369), requested 178 days ago (non-free) Description: Mwave/ACP modem support software Installations reported by Popcon: 5 openssl (#332498), requested 63 days ago Description: Secure Socket Layer (SSL) binary and related cryptographic tools Reverse Depends: openssh-server-udeb libaqbanking0c2a libopensc-openssl libecpg-compat2 nsd apache-ssl pound webmin aqbanking-tool avscan bzflag-server wpasupplicant dsniff libneon24 fetchmail slapd libnet-ssleay-perl liblasso3 ultrapossum-tls ssmtp sqlrelay-sqlite cacti-cactid d4x sylpheed hplip sylpheed-claws-gtk2 sylpheed-gtk1 libapache-mod-php4 php4-cgi postgresql-contrib-8.1 libpq3 libaqbanking-ofx0 sylpheed-claws-gtk2-clamav libldap-2.2-7 lwresd newpki-server hula davfs2 xine-ui heartbeat-2 libaqgeldkarte0 php5-cli ohphone-basic libecpg-dev racoon postfix cyrus21-common t38modem pyca ftpd-ssl fireflier-server siege nagios-plugins-basic bibletime libpq4 libyaz sylpheed-claws-spamassassin pantomime-dev libzorpll-dev grip usermin libpam-mount python2.3-sqlrelay apache2-mpm-prefork mozilla-opensc kannel-extras aria libkeynote0 sslwrap simph323 libsope-ldap4.4 postgresql-7.4 conserver-client libwvstreams4.2-extras xsupplicant xmms-scrobbler proftpd newpki-client tellico webauth-utils ca-certificates italc-client libopensc1-dev dovecot-pop3d libsnmp9-dev isync nmap dovecot-imapd libpam-musclecard proftpd-mysql postgresql-client-8.1 libc-client-dev libaws-dev ipopd gambas-gb-net-curl libopensc1
Accepted dpkg-cross 1.26 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sat, 3 Dec 2005 23:39:29 +0300
Source: dpkg-cross
Binary: dpkg-cross
Architecture: source all
Version: 1.26
Distribution: unstable
Urgency: low
Maintainer: Nikita V. Youshchenko [EMAIL PROTECTED]
Changed-By: Nikita V. Youshchenko [EMAIL PROTECTED]
Description:
dpkg-cross - tools for cross compiling Debian packages
Closes: 334282 336080
Changes:
dpkg-cross (1.26) unstable; urgency=low
.
* Update default paths and prefixes, to match changes in debian
toolchain. Mostly by adding '-gnu' here and there.
* Now dpkg-cross adds additional provides-depends logic to generated
-$arch-cross packages, to avoid -$arch-cross packages generated
prior to path changes to satisfy deps of packages generated post
those changes.
* Updated list of dpkg-architecture variables to set when
cross-compiling, to match current dpkg-architecture.
* dpkg-shlibdeps: addded elf64-x86-64 and elf64-powerpc to
@crosslib64formats, as GOTO Masanori [EMAIL PROTECTED] requested.
* Added objdump and objcopy wrappers similar to strip wrapper. Seem to
be needed by dh_strip calls from gcc-4.0 package builds.
* Added armeb architecture support (Closes: #336080).
* Fixed a typo in dpkg-buildpackage (Closes: #334282).
* Added gcc-*-base to keepdeps in default /etc/dpkg-cross/cross-compile.
* Removed any reference to unused 'crossinfo' variable.
* Added cross-config.{arm,armeb}, created by Lennert Buytenhek
[EMAIL PROTECTED].
* If dpkg-deb -b fails, show it's output even if not verbose.
* When merging .changes files, remove 'source' from arch field of the
merged file name. See #322926 for details.
* Set Maintainer to my debian.org e-mail.
* Bumped Standards-Version to 3.6.2, no changes needed.
Files:
c880093b7972f1c3fa6c65aafdedd0f5 522 utils extra dpkg-cross_1.26.dsc
63debe122e40669da34d08f8f003d30f 69259 utils extra dpkg-cross_1.26.tar.gz
cd0726dcae43fa3778ea93b2acdd3205 63542 utils extra dpkg-cross_1.26_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDl+EQv3x5OskTLdsRAibIAKDTpeNaZkybAC3fD14Ry6dDYKMwigCglHph
lvH1vTeS1MJoR9j4fvnd0aI=
=Ff/5
-END PGP SIGNATURE-
Accepted:
dpkg-cross_1.26.dsc
to pool/main/d/dpkg-cross/dpkg-cross_1.26.dsc
dpkg-cross_1.26.tar.gz
to pool/main/d/dpkg-cross/dpkg-cross_1.26.tar.gz
dpkg-cross_1.26_all.deb
to pool/main/d/dpkg-cross/dpkg-cross_1.26_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libccrtp 1.3.5-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 08:19:53 + Source: libccrtp Binary: libccrtp1-1.3-0 libccrtp-dev Architecture: source i386 Version: 1.3.5-3 Distribution: unstable Urgency: low Maintainer: Mark Purcell [EMAIL PROTECTED] Changed-By: Mark Purcell [EMAIL PROTECTED] Description: libccrtp-dev - Common C++ class framework for RTP packets libccrtp1-1.3-0 - Common C++ class framework for RTP packets Changes: libccrtp (1.3.5-3) unstable; urgency=low . * Bump Build-Depends: libcommoncpp2-dev to (= 1.3.21-2) Files: bb4e1aaf84eea638bb4bc9fb83c2f9d6 638 devel optional libccrtp_1.3.5-3.dsc 7d3b4b83b7cb7a30d26de06037246e39 19255 devel optional libccrtp_1.3.5-3.diff.gz 5205d746b844bdcef9c61f9c3b1d3563 711002 libdevel optional libccrtp-dev_1.3.5-3_i386.deb 88db28f6e37ffe781711ed94f782cc65 62386 libs optional libccrtp1-1.3-0_1.3.5-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDl+14oCzanz0IthIRAjCVAJ9IBLn2MoKWb/G2m6gB8+kuq8q70QCeMa28 WRKvK0J3sF4xyHG75HgukFM= =d39y -END PGP SIGNATURE- Accepted: libccrtp-dev_1.3.5-3_i386.deb to pool/main/libc/libccrtp/libccrtp-dev_1.3.5-3_i386.deb libccrtp1-1.3-0_1.3.5-3_i386.deb to pool/main/libc/libccrtp/libccrtp1-1.3-0_1.3.5-3_i386.deb libccrtp_1.3.5-3.diff.gz to pool/main/libc/libccrtp/libccrtp_1.3.5-3.diff.gz libccrtp_1.3.5-3.dsc to pool/main/libc/libccrtp/libccrtp_1.3.5-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asterisk 1:1.2.1.dfsg-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Dec 2005 21:59:20 + Source: asterisk Binary: asterisk-sounds-main asterisk-h323 asterisk-web-vmail asterisk asterisk-config asterisk-dev asterisk-doc Architecture: source all i386 Version: 1:1.2.1.dfsg-1 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Mark Purcell [EMAIL PROTECTED] Description: asterisk - open source Private Branch Exchange (PBX) asterisk-config - config files for asterisk asterisk-dev - development files for asterisk asterisk-doc - documentation for asterisk asterisk-h323 - asterisk H.323 VoIP channel asterisk-sounds-main - sound files for asterisk asterisk-web-vmail - Web-based (CGI) voice mail interface for Asterisk Closes: 342463 Changes: asterisk (1:1.2.1.dfsg-1) unstable; urgency=low . * New upstream release - Please package asterisk 1.2.1 (Closes: #342463) * Temporary disable bristuff for upstream release * sip-1.914.dpatch merged upstream Files: 0aae1582525fa78bc600d820dfed8a28 1314 comm optional asterisk_1.2.1.dfsg-1.dsc ba907c626e534cf64c6cac6e9ccf8493 3856009 comm optional asterisk_1.2.1.dfsg.orig.tar.gz a78c25d48abdca1b97ea4dbdfe077f1f 95244 comm optional asterisk_1.2.1.dfsg-1.diff.gz bbeebaf2cf71504f32e694676da32709 17796130 doc optional asterisk-doc_1.2.1.dfsg-1_all.deb 61c950cfe68c606fdda3d37667f73bda 127836 devel optional asterisk-dev_1.2.1.dfsg-1_all.deb c14432a380dc6c80940d16bdf461e433 1460536 comm optional asterisk-sounds-main_1.2.1.dfsg-1_all.deb 72c71961c381e599a3a9c49046ec1a94 8 comm optional asterisk-web-vmail_1.2.1.dfsg-1_all.deb 55e1f0fc59ebd1a23009272ca773f5ef 87252 comm optional asterisk-config_1.2.1.dfsg-1_all.deb 589aae7323ea86b4d76a116593fc9663 1730266 comm optional asterisk_1.2.1.dfsg-1_i386.deb 4229a4b89fb28c3e56c75292ac7abd2b 26200 comm optional asterisk-h323_1.2.1.dfsg-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDl+d8oCzanz0IthIRAoYBAJ9mi6/HSEXcfWwpwrLlK+nl1XFHhACgmwbr KAZ+Zy+RZ/sKnIQJsySQs44= =zc+y -END PGP SIGNATURE- Accepted: asterisk-config_1.2.1.dfsg-1_all.deb to pool/main/a/asterisk/asterisk-config_1.2.1.dfsg-1_all.deb asterisk-dev_1.2.1.dfsg-1_all.deb to pool/main/a/asterisk/asterisk-dev_1.2.1.dfsg-1_all.deb asterisk-doc_1.2.1.dfsg-1_all.deb to pool/main/a/asterisk/asterisk-doc_1.2.1.dfsg-1_all.deb asterisk-h323_1.2.1.dfsg-1_i386.deb to pool/main/a/asterisk/asterisk-h323_1.2.1.dfsg-1_i386.deb asterisk-sounds-main_1.2.1.dfsg-1_all.deb to pool/main/a/asterisk/asterisk-sounds-main_1.2.1.dfsg-1_all.deb asterisk-web-vmail_1.2.1.dfsg-1_all.deb to pool/main/a/asterisk/asterisk-web-vmail_1.2.1.dfsg-1_all.deb asterisk_1.2.1.dfsg-1.diff.gz to pool/main/a/asterisk/asterisk_1.2.1.dfsg-1.diff.gz asterisk_1.2.1.dfsg-1.dsc to pool/main/a/asterisk/asterisk_1.2.1.dfsg-1.dsc asterisk_1.2.1.dfsg-1_i386.deb to pool/main/a/asterisk/asterisk_1.2.1.dfsg-1_i386.deb asterisk_1.2.1.dfsg.orig.tar.gz to pool/main/a/asterisk/asterisk_1.2.1.dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcatalyst-engine-apache-perl 1.02-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 09:49:29 +0100 Source: libcatalyst-engine-apache-perl Binary: libcatalyst-engine-apache-perl Architecture: source all Version: 1.02-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libcatalyst-engine-apache-perl - Base class for Apache 1.99x and 2.x Catalyst engines Changes: libcatalyst-engine-apache-perl (1.02-1) unstable; urgency=low . * New upstream release Files: 185b3094af6b8bba5cfc2ef599406616 865 perl optional libcatalyst-engine-apache-perl_1.02-1.dsc 923e1797d28b35ce7f1f3e92e767956a 18881 perl optional libcatalyst-engine-apache-perl_1.02.orig.tar.gz 6008ccf8acb1a6b69d5ba49c57eba2b4 2416 perl optional libcatalyst-engine-apache-perl_1.02-1.diff.gz 8d4b7aef0556d0e2ac2b6c57031268e5 20204 perl optional libcatalyst-engine-apache-perl_1.02-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDl/P7+NMfSd6w7DERAth+AKCvWVMHTXr5SpIuFnGZNVSLc0UEegCeKTJL ohbbTKPMS06APAXrWU9UVpE= =N9EE -END PGP SIGNATURE- Accepted: libcatalyst-engine-apache-perl_1.02-1.diff.gz to pool/main/libc/libcatalyst-engine-apache-perl/libcatalyst-engine-apache-perl_1.02-1.diff.gz libcatalyst-engine-apache-perl_1.02-1.dsc to pool/main/libc/libcatalyst-engine-apache-perl/libcatalyst-engine-apache-perl_1.02-1.dsc libcatalyst-engine-apache-perl_1.02-1_all.deb to pool/main/libc/libcatalyst-engine-apache-perl/libcatalyst-engine-apache-perl_1.02-1_all.deb libcatalyst-engine-apache-perl_1.02.orig.tar.gz to pool/main/libc/libcatalyst-engine-apache-perl/libcatalyst-engine-apache-perl_1.02.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted po-debconf 0.9.1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 10:26:40 +0100 Source: po-debconf Binary: po-debconf Architecture: source all Version: 0.9.1 Distribution: unstable Urgency: low Maintainer: Denis Barbier [EMAIL PROTECTED] Changed-By: Denis Barbier [EMAIL PROTECTED] Description: po-debconf - manage translated Debconf templates files with gettext Closes: 337750 Changes: po-debconf (0.9.1) unstable; urgency=low . * Remove debconf2po-update.1, this program has been renamed three years ago, so the transition phase is over. . * Add Russian man pages. Closes: #337750 Many thanks to Yuri Kozlov. . * debian/control: Drop dependencies on libmime-base64-perl, this package had been merged with perl in sarge. Files: d85a1062d056bb16027216773b9ea982 513 devel optional po-debconf_0.9.1.dsc 215753162ac6360a4327a4b509a92d39 109051 devel optional po-debconf_0.9.1.tar.gz cdfad29c7ef0c45647624b4dea641461 101064 devel optional po-debconf_0.9.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmAXB8Ri1lR4WGvsRAqaxAKC7CHkv4IO/yna6eZ0gX6zWxRLvxACdGqz1 XAVtsYfHXFzjj6MM1d4I06U= =Ssh1 -END PGP SIGNATURE- Accepted: po-debconf_0.9.1.dsc to pool/main/p/po-debconf/po-debconf_0.9.1.dsc po-debconf_0.9.1.tar.gz to pool/main/p/po-debconf/po-debconf_0.9.1.tar.gz po-debconf_0.9.1_all.deb to pool/main/p/po-debconf/po-debconf_0.9.1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted uni2ascii 2.7-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 10:11:25 +0100 Source: uni2ascii Binary: uni2ascii Architecture: source i386 Version: 2.7-1 Distribution: unstable Urgency: low Maintainer: Florian Ernst [EMAIL PROTECTED] Changed-By: Florian Ernst [EMAIL PROTECTED] Description: uni2ascii - convert UTF-8 into 7-bit ASCII and vice versa Changes: uni2ascii (2.7-1) unstable; urgency=low . * New upstream release Files: c98afbe39e0841a77bdad4155a59d912 574 text optional uni2ascii_2.7-1.dsc 6fc30cb374f448530d4d4778daa88b15 80621 text optional uni2ascii_2.7.orig.tar.gz f01e5506a264e015da4c0df441103f7d 2424 text optional uni2ascii_2.7-1.diff.gz ec5c3e6aea139d3bb869161d4fbb1ea8 16368 text optional uni2ascii_2.7-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDl/pus3U+TVFLPnwRAmg9AJ4sAe0ThBFRX7FJvgWQjderZjX3AACfd8LQ rCCqYc/8gUmKD+wdvo6tw98= =X9rl -END PGP SIGNATURE- Accepted: uni2ascii_2.7-1.diff.gz to pool/main/u/uni2ascii/uni2ascii_2.7-1.diff.gz uni2ascii_2.7-1.dsc to pool/main/u/uni2ascii/uni2ascii_2.7-1.dsc uni2ascii_2.7-1_i386.deb to pool/main/u/uni2ascii/uni2ascii_2.7-1_i386.deb uni2ascii_2.7.orig.tar.gz to pool/main/u/uni2ascii/uni2ascii_2.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmms-crossfade 0.3.10-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 10:38:42 +0100 Source: xmms-crossfade Binary: bmp-crossfade xmms-crossfade Architecture: source i386 Version: 0.3.10-1 Distribution: unstable Urgency: low Maintainer: Florian Ernst [EMAIL PROTECTED] Changed-By: Florian Ernst [EMAIL PROTECTED] Description: bmp-crossfade - Beep-Media-Player Plugin for Crossfading / Continuous Output xmms-crossfade - XMMS Plugin for Crossfading / Continuous Output Changes: xmms-crossfade (0.3.10-1) unstable; urgency=low . * New upstream release Files: ecd1ae59b83ebb7989771d8de5c68c06 672 sound optional xmms-crossfade_0.3.10-1.dsc 43c53b522545253e2bfeee7a0c0dfde3 476290 sound optional xmms-crossfade_0.3.10.orig.tar.gz fe3266982c6d5c2a49703bd94e989da3 4454 sound optional xmms-crossfade_0.3.10-1.diff.gz eec96c009ce1f1c114e263deee6caa0f 93596 sound optional xmms-crossfade_0.3.10-1_i386.deb 33b1647ef27ae2be55cbfe4255ae11d9 93558 sound optional bmp-crossfade_0.3.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmAIEs3U+TVFLPnwRAlPUAJ4yc73vEXgx6wh/0SWShPoGaSXFEwCdGudi UscUFNr9VeIx4QqlYyQWNrk= =26u7 -END PGP SIGNATURE- Accepted: bmp-crossfade_0.3.10-1_i386.deb to pool/main/x/xmms-crossfade/bmp-crossfade_0.3.10-1_i386.deb xmms-crossfade_0.3.10-1.diff.gz to pool/main/x/xmms-crossfade/xmms-crossfade_0.3.10-1.diff.gz xmms-crossfade_0.3.10-1.dsc to pool/main/x/xmms-crossfade/xmms-crossfade_0.3.10-1.dsc xmms-crossfade_0.3.10-1_i386.deb to pool/main/x/xmms-crossfade/xmms-crossfade_0.3.10-1_i386.deb xmms-crossfade_0.3.10.orig.tar.gz to pool/main/x/xmms-crossfade/xmms-crossfade_0.3.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted git 4.3.20-8 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Oct 2005 21:11:44 +0100 Source: git Binary: git Architecture: source i386 Version: 4.3.20-8 Distribution: unstable Urgency: low Maintainer: Ian Beckwith [EMAIL PROTECTED] Changed-By: MJ Ray (Debian) [EMAIL PROTECTED] Description: git- GNU Interactive Tools, a file browser/viewer and process viewer/k Closes: 316676 326356 Changes: git (4.3.20-8) unstable; urgency=low . * Renamed /usr/bin/git to gitfm (Closes: #316676): + Added NEWS.Debian with further explanation. + Added git.transition to warn users. + Use update-alternatives to manage /usr/bin/git, so admins can finish transition early. + Updated documentation. + Changed all instances of [GIT-* in config files to [GITFM-*. + Updated code to use [GITFM- sections, but accept old [GIT- sections too. * gitps: fixed segfault on refresh when selected process has been killed. * debian/control: + Tightened Build-Depends to libreadline5-dev (Closes: #326356). + Added my sponsor, MJ Ray, to Uploaders. + Bumped Standards-Version to 3.6.2 (No changes). * debian/copyright: Updated FSF address. * debian/changelog: added fake dates to earliest two entries to silence linda. Files: eb8f07edd03887c324d1d1d33a55b36d 651 utils optional git_4.3.20-8.dsc f22695fe791dc6b53a6de28d19028b23 387751 utils optional git_4.3.20-8.diff.gz 2e16a2959c225d1cf465ce5c230ec312 265654 utils optional git_4.3.20-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDmAuBmUY5euFC5vQRApfyAKCAVE83eoQEks0O5wMBlfEEDnK6jgCglU83 rP7D+J17pQmLbDywlf+WR2s= =y9fq -END PGP SIGNATURE- Accepted: git_4.3.20-8.diff.gz to pool/main/g/git/git_4.3.20-8.diff.gz git_4.3.20-8.dsc to pool/main/g/git/git_4.3.20-8.dsc git_4.3.20-8_i386.deb to pool/main/g/git/git_4.3.20-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rapidsvn 0.9.0-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 03:32:23 +0100 Source: rapidsvn Binary: libsvncpp-dev libsvncpp0c2a rapidsvn Architecture: source i386 Version: 0.9.0-2 Distribution: unstable Urgency: low Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: libsvncpp-dev - Subversion C++ library (development files) libsvncpp0c2a - Subversion C++ shared library rapidsvn - A GUI client for subversion Closes: 342489 Changes: rapidsvn (0.9.0-2) unstable; urgency=low . * Fix typo in conflicts/replaces (closes: #342489). Files: 9ba568a81948f38cdcab3bb11d055b04 689 x11 optional rapidsvn_0.9.0-2.dsc d1670e38db779b7049cfa94af3e340ae 5909 x11 optional rapidsvn_0.9.0-2.diff.gz d23a8b5ef58f23168e2bf7c8980d0d97 228898 x11 optional rapidsvn_0.9.0-2_i386.deb 43d306d6c00d33bb46e963c529b8e5c1 57978 libs optional libsvncpp0c2a_0.9.0-2_i386.deb 9778022f1422c3bebd99adce7bbe45cc 195810 libdevel optional libsvncpp-dev_0.9.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmAK6StlRaw+TLJwRAooMAJ9o39sa3CNAtVUKs/7qAskLywF84wCffDWw n7T+jGTrpR9hWyt/J2VsEwk= =eqHM -END PGP SIGNATURE- Accepted: libsvncpp-dev_0.9.0-2_i386.deb to pool/main/r/rapidsvn/libsvncpp-dev_0.9.0-2_i386.deb libsvncpp0c2a_0.9.0-2_i386.deb to pool/main/r/rapidsvn/libsvncpp0c2a_0.9.0-2_i386.deb rapidsvn_0.9.0-2.diff.gz to pool/main/r/rapidsvn/rapidsvn_0.9.0-2.diff.gz rapidsvn_0.9.0-2.dsc to pool/main/r/rapidsvn/rapidsvn_0.9.0-2.dsc rapidsvn_0.9.0-2_i386.deb to pool/main/r/rapidsvn/rapidsvn_0.9.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-ppcre 1.2.13-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Dec 2005 11:53:05 +0100 Source: cl-ppcre Binary: cl-ppcre Architecture: source all Version: 1.2.13-1 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-ppcre - Portable Regular Express Library for Common Lisp Changes: cl-ppcre (1.2.13-1) unstable; urgency=low . * New upstream Files: 9953fdd5c404a3ce472ac12031d80c42 589 devel optional cl-ppcre_1.2.13-1.dsc a264b19b789f73dba4e775a11f602c51 167575 devel optional cl-ppcre_1.2.13.orig.tar.gz 02f1466db31e5fc26b7b431cc6c51fd1 2984 devel optional cl-ppcre_1.2.13-1.diff.gz 98d9ec24dde9ac9c3b835cb0d989ae24 98688 devel optional cl-ppcre_1.2.13-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlsBA11ldN0tyliURAqSgAJ9+S/RIR5zvLTqB7APJUsFRKRXzvACcDVce Dtg/IgKqZwSj3SJlmYGJEv4= =yh+y -END PGP SIGNATURE- Accepted: cl-ppcre_1.2.13-1.diff.gz to pool/main/c/cl-ppcre/cl-ppcre_1.2.13-1.diff.gz cl-ppcre_1.2.13-1.dsc to pool/main/c/cl-ppcre/cl-ppcre_1.2.13-1.dsc cl-ppcre_1.2.13-1_all.deb to pool/main/c/cl-ppcre/cl-ppcre_1.2.13-1_all.deb cl-ppcre_1.2.13.orig.tar.gz to pool/main/c/cl-ppcre/cl-ppcre_1.2.13.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted common-lisp-controller 4.27 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Dec 2005 07:48:59 +0100 Source: common-lisp-controller Binary: common-lisp-controller Architecture: source all Version: 4.27 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: common-lisp-controller - This is a Common Lisp source and compiler manager Changes: common-lisp-controller (4.27) unstable; urgency=low . * clisp changed a posix function. Files: f5357d5212c43f34b33d6315d6d23e1e 587 devel optional common-lisp-controller_4.27.dsc e984b1f68bac814daabb6db7b8af5baf 27636 devel optional common-lisp-controller_4.27.tar.gz 1ee3e17c678b91abc36b1565fa8c0b48 26168 devel optional common-lisp-controller_4.27_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlp6511ldN0tyliURAvHiAKDJ5lFWhz4MIRpI4sly7Nr8TadRsACgx10x 5UyueLMKhmgorX1ebT0ciuQ= =fxea -END PGP SIGNATURE- Accepted: common-lisp-controller_4.27.dsc to pool/main/c/common-lisp-controller/common-lisp-controller_4.27.dsc common-lisp-controller_4.27.tar.gz to pool/main/c/common-lisp-controller/common-lisp-controller_4.27.tar.gz common-lisp-controller_4.27_all.deb to pool/main/c/common-lisp-controller/common-lisp-controller_4.27_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-fad 0.3.3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 6 Dec 2005 18:12:13 +0100 Source: cl-fad Binary: cl-fad Architecture: source all Version: 0.3.3-1 Distribution: unstable Urgency: low Maintainer: René van Bevern [EMAIL PROTECTED] Changed-By: René van Bevern [EMAIL PROTECTED] Description: cl-fad - portable pathname library for Common Lisp Changes: cl-fad (0.3.3-1) unstable; urgency=low . * New upstream version with fixes for OpenMCL . * debian/control: + Add cdbs and debhelper to Build-Depends, they are used in the clean target + Indent Homepage field in description Files: 446914ff9990139510dc0a051a446a81 622 devel optional cl-fad_0.3.3-1.dsc 0925d30ef5d341b6b6e6672d819a0624 9931 devel optional cl-fad_0.3.3.orig.tar.gz 8334f8f120250e49f49682f34b576294 2551 devel optional cl-fad_0.3.3-1.diff.gz 9e18cab5044da92a0950b1736e611f0c 13028 devel optional cl-fad_0.3.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlqxv11ldN0tyliURAiU0AJ0QwvR1Dh6hLN4CJSTgvgsQhRw1MwCgpLCa jYba1QT+Zil887eCa4TLBi0= =3Y1N -END PGP SIGNATURE- Accepted: cl-fad_0.3.3-1.diff.gz to pool/main/c/cl-fad/cl-fad_0.3.3-1.diff.gz cl-fad_0.3.3-1.dsc to pool/main/c/cl-fad/cl-fad_0.3.3-1.dsc cl-fad_0.3.3-1_all.deb to pool/main/c/cl-fad/cl-fad_0.3.3-1_all.deb cl-fad_0.3.3.orig.tar.gz to pool/main/c/cl-fad/cl-fad_0.3.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgphoto2 2.1.6-6 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 12:02:29 +0100 Source: libgphoto2 Binary: libgphoto2-port0 libgphoto2-2-dev libgphoto2-2 Architecture: source i386 Version: 2.1.6-6 Distribution: unstable Urgency: low Maintainer: Frederic Peters [EMAIL PROTECTED] Changed-By: Frederic Peters [EMAIL PROTECTED] Description: libgphoto2-2 - gphoto2 digital camera library libgphoto2-2-dev - gphoto2 digital camera library (development files) libgphoto2-port0 - gphoto2 digital camera port library Closes: 334578 341083 342279 342282 Changes: libgphoto2 (2.1.6-6) unstable; urgency=low . * Acknowledge NMUs, thanks to all. * debian/hotplug: changed hotplug script to support new udev and kernel versions (thanks to Aleksey Kliger) (closes: #341083, #342279, #342282) * debian/libgphoto2-2.postinst: don't generate udev rules if udev directory doesn't exist (closes: #334578) Files: 22486dfec96be9ebad9c4fc50f46d194 892 libs optional libgphoto2_2.1.6-6.dsc 527bdf4fb42e4b57235b724f1a3aad91 11230 libs optional libgphoto2_2.1.6-6.diff.gz 7bd39891c4dcfad525715fba74729eeb 549656 libdevel optional libgphoto2-2-dev_2.1.6-6_i386.deb 2dd4b0f481407c5c813ef7b79e3c434d 97026 libs optional libgphoto2-port0_2.1.6-6_i386.deb 2699535ba9e6d6c8b843fb3ca74f54de 934332 libs optional libgphoto2-2_2.1.6-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmBWgoR3LsWeD7V4RApECAJ9Z5zE11NBwso8dM63Nrhc/eHpJvACfc/1o EgboNHdDCZanG6vl7O8+AjU= =EXKg -END PGP SIGNATURE- Accepted: libgphoto2-2-dev_2.1.6-6_i386.deb to pool/main/libg/libgphoto2/libgphoto2-2-dev_2.1.6-6_i386.deb libgphoto2-2_2.1.6-6_i386.deb to pool/main/libg/libgphoto2/libgphoto2-2_2.1.6-6_i386.deb libgphoto2-port0_2.1.6-6_i386.deb to pool/main/libg/libgphoto2/libgphoto2-port0_2.1.6-6_i386.deb libgphoto2_2.1.6-6.diff.gz to pool/main/libg/libgphoto2/libgphoto2_2.1.6-6.diff.gz libgphoto2_2.1.6-6.dsc to pool/main/libg/libgphoto2/libgphoto2_2.1.6-6.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted meta-gnustep 4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 12:24:49 +0100 Source: meta-gnustep Binary: gnustep-games gnustep gnustep-devel gnustep-core gnustep-core-doc gnustep-core-devel Architecture: source all Version: 4 Distribution: unstable Urgency: low Maintainer: Gürkan Sengün [EMAIL PROTECTED] Changed-By: Gürkan Sengün [EMAIL PROTECTED] Description: gnustep- The GNUstep Development Environment -- user applications gnustep-core - The GNUstep Development Environment -- core gnustep-core-devel - The GNUstep Development Environment -- core development gnustep-core-doc - The GNUstep Development Environment -- core documentation gnustep-devel - The GNUstep Development Environment -- development tools gnustep-games - The GNUstep Development Environment -- games Closes: 342519 342520 Changes: meta-gnustep (4) unstable; urgency=low . * Updated dependencies. - terminal.app (closes: #342519) - projectcenter.app (closes: #342520) * Bump standards version. * Added more suggests/recommends. Files: c6f53494094596f9f007dff5d283f8ea 711 x11 optional meta-gnustep_4.dsc de8927c4a51ae8fff828c1916a067432 3207 x11 optional meta-gnustep_4.tar.gz a22c3f271b804ac7b2b774c0067c8124 2454 x11 optional gnustep-core_4_all.deb d3b999f9c225d052a6dbea76018ad139 1996 x11 optional gnustep-core-devel_4_all.deb 940a74bc33aa2462db2586af23ff24f8 1978 x11 optional gnustep-core-doc_4_all.deb f86735f9b8d76b0f08b3f84f4b34af58 2268 x11 optional gnustep_4_all.deb eb35cd42a08538354c6376deed8c995e 2006 x11 optional gnustep-games_4_all.deb 2c631ab4394960da8c8d4c556e7a9b11 2038 x11 optional gnustep-devel_4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDmB5+xa93SlhRC1oRAp/xAJ9r/foZuC2zw/hxO+MFLJOAD9l+IQCgqMsb d+i/QNsWyTxorDIuzVX0dTY= =vAaV -END PGP SIGNATURE- Accepted: gnustep-core-devel_4_all.deb to pool/main/m/meta-gnustep/gnustep-core-devel_4_all.deb gnustep-core-doc_4_all.deb to pool/main/m/meta-gnustep/gnustep-core-doc_4_all.deb gnustep-core_4_all.deb to pool/main/m/meta-gnustep/gnustep-core_4_all.deb gnustep-devel_4_all.deb to pool/main/m/meta-gnustep/gnustep-devel_4_all.deb gnustep-games_4_all.deb to pool/main/m/meta-gnustep/gnustep-games_4_all.deb gnustep_4_all.deb to pool/main/m/meta-gnustep/gnustep_4_all.deb meta-gnustep_4.dsc to pool/main/m/meta-gnustep/meta-gnustep_4.dsc meta-gnustep_4.tar.gz to pool/main/m/meta-gnustep/meta-gnustep_4.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted clisp 1:2.36-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 08:16:40 +0100 Source: clisp Binary: clisp-dev clisp clisp-doc Architecture: source all i386 Version: 1:2.36-1 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: clisp - GNU CLISP, a Common Lisp implementation clisp-dev - GNU CLISP, a Common Lisp implementation (development files) clisp-doc - GNU CLISP, a Common Lisp implementation (documentation) Closes: 62116 64853 162019 340274 340274 340646 341850 Changes: clisp (1:2.36-1) unstable; urgency=low . * New upstream version. * Improved errorchecking during installation, made removal more failsave. Closes: #340274 * Improved error propagation during installation, should signal all errors to clc now. Should fix these strange problems we've been seeing. Closes: #340274, #340646 * Try gcc on sparc, could Closes: #341850 * Could not get it to work on m68k. Upstream also does not test anymore on this architecture, so for all pratical purposes the port is dead. Patches welcome. Closes: #162019, #62116, #64853 * Improved package descriptions. Files: bd70ffe32aad77b1a52422ff3a7361ef 730 interpreters optional clisp_2.36-1.dsc 7b2dbbcefae96fc8e7e8d01ec9d03c7c 10124597 interpreters optional clisp_2.36.orig.tar.gz 5debc73dd7b6cd03053ef273a096a16a 83090 interpreters optional clisp_2.36-1.diff.gz 74ee18678353178b1e91bbc5565b923c 2886678 interpreters optional clisp_2.36-1_i386.deb 8ad2d8f395b08f416c2a9549ac471b07 1260888 devel optional clisp-dev_2.36-1_i386.deb ac600d5d1ea89dceebcfb0b9d5ac4457 1009634 doc optional clisp-doc_2.36-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmBNo11ldN0tyliURAmfQAJ0XjCXDIZjzMf37uRCu5RMvbnHqNQCdE9xZ ora3rXs0F1z05P77KJeHWy4= =BERK -END PGP SIGNATURE- Accepted: clisp-dev_2.36-1_i386.deb to pool/main/c/clisp/clisp-dev_2.36-1_i386.deb clisp-doc_2.36-1_all.deb to pool/main/c/clisp/clisp-doc_2.36-1_all.deb clisp_2.36-1.diff.gz to pool/main/c/clisp/clisp_2.36-1.diff.gz clisp_2.36-1.dsc to pool/main/c/clisp/clisp_2.36-1.dsc clisp_2.36-1_i386.deb to pool/main/c/clisp/clisp_2.36-1_i386.deb clisp_2.36.orig.tar.gz to pool/main/c/clisp/clisp_2.36.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnupg2 1.9.19-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Changed-By: Matthias Urlichs [EMAIL PROTECTED] Date: Sat, 22 Oct 2005 14:33:33 +0200 Version: 1.9.19-1 Distribution: unstable Source: gnupg2 Urgency: low Maintainer: Matthias Urlichs [EMAIL PROTECTED] Binary: gnupg-agent gnupg2 gpgsm Architecture: i386 source Changes: gnupg2 (1.9.19-1) unstable; urgency=low . * Merged with 1.9.19. * Re-enable gpgv2 package. Description: gpgsm - GNU privacy guard - password agent gnupg-agent - GNU privacy guard - password agent gnupg2 - GNU privacy guard - a free PGP replacement Files: 2e98fadb7c0e5ca2bc0940404a804547 726392 utils extra gnupg2_1.9.19-1_i386.deb 9ac2974f1aae8de3b657ce05862922f1 287630 utils optional gpgsm_1.9.19-1_i386.deb 342b919e19664bfb7bcb67df7ca9acfd 167978 utils optional gnupg-agent_1.9.19-1_i386.deb 9fa756efe67a69cf27b9d565f2e5d484 330035 utils optional gnupg2_1.9.19-1.diff.gz dd95cd4d83d093fb194fe3eaf1be9bae 857 utils optional gnupg2_1.9.19-1.dsc 997a54bd9840c108d2cf3bfc4e9e6b5c 2110476 utils optional gnupg2_1.9.19.orig.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDmCoC8+hUANcKr/kRAif+AJ9r4OYcilGFv0Qqx5Rl1atZ+v8ZoACfYlGI WWk549D94Qu6YX5IOP2mAnU= =zWTt -END PGP SIGNATURE- Accepted: gnupg-agent_1.9.19-1_i386.deb to pool/main/g/gnupg2/gnupg-agent_1.9.19-1_i386.deb gnupg2_1.9.19-1.diff.gz to pool/main/g/gnupg2/gnupg2_1.9.19-1.diff.gz gnupg2_1.9.19-1.dsc to pool/main/g/gnupg2/gnupg2_1.9.19-1.dsc gnupg2_1.9.19-1_i386.deb to pool/main/g/gnupg2/gnupg2_1.9.19-1_i386.deb gnupg2_1.9.19.orig.tar.gz to pool/main/g/gnupg2/gnupg2_1.9.19.orig.tar.gz gpgsm_1.9.19-1_i386.deb to pool/main/g/gnupg2/gpgsm_1.9.19-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cupsys 1.1.99.b1.r4876-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 8 Dec 2005 21:26:22 +0900
Source: cupsys
Binary: cupsys-bsd libcupsys2-dev libcupsys2 cupsys libcupsys2-gnutls10
libcupsimage2-dev libcupsimage2 cupsys-client
Architecture: source i386 all
Version: 1.1.99.b1.r4876-1
Distribution: experimental
Urgency: low
Maintainer: Debian CUPS Maintainers [EMAIL PROTECTED]
Changed-By: Kenshi Muto [EMAIL PROTECTED]
Description:
cupsys - Common UNIX Printing System(tm) - server
cupsys-bsd - Common UNIX Printing System(tm) - BSD commands
cupsys-client - Common UNIX Printing System(tm) - client programs (SysV)
libcupsimage2 - Common UNIX Printing System(tm) - image libs
libcupsimage2-dev - Common UNIX Printing System(tm) - image development files
libcupsys2 - Common UNIX Printing System(tm) - libs
libcupsys2-dev - Common UNIX Printing System(tm) - development files
libcupsys2-gnutls10 - Common UNIX Printing System(tm) - dummy libs for
transition
Changes:
cupsys (1.1.99.b1.r4876-1) experimental; urgency=low
.
[ Martin Pitt ]
* debian/local/{enable_browsing,browsing_status}: Adapt configuration file
locations to new conf.d structure.
* debian/cupsys.templates: Fix default value for cupsys/browse: 'yes' is an
invalid bool option, change to true.
* debian/cupsys.init.d: Use LSB init functions. Add lsb-base package
dependency.
* debian/cupsys.postinst: Wait a second between kill -9'ing cupsys and
checking if the process still exists to avoid false positives and upgrade
failures.
* Clean up support for /etc/cups/conf.d:
- Add debian/patches/08_cupsd.conf.conf.d.dpatch: Add include commands to
default cupsd.conf file.
- debian/cupsys.postinst: Remove fiddling with cupsd.conf.
- This will ensure that cupsd.conf will remain an unchanged conffile.
* debian/rules: Remove empty debian/patched on clean.
* debian/patches/10_cupsd.conf2.dpatch: Re-enable listening to localhost to
make the web interface work.
* debian/patches/44_fixconfdirperms.dpatch:
- Put configuration files into group root instead of nobody to avoid
privilege escalation of nobody/nogroup and comply to Debian standards.
- Use CUPS_DEFAULT_GROUP instead of 'nobody' as the default group for
setgid'ing to and conffiles which must be writable for cupsd.
- Disable changing permissions of cupsd.conf conffile.
* Add debian/patches/09_runasuser_fixes.dpatch:
- scheduler/main.c: Generate a certificate even when running as user, just
as in 1.1.x; this unbreaks local certificate authorization for cupsd
when it runs as normal user.
- scheduler/main.c: When running as non-root, call initgroups() instead of
setgroups() to allow auxiliary groups. These are required to access
different device types (lp for USB/parallel printers, dialout for serial
printers, etc.)
.
[ Kenshi Muto ]
* New SVN release taken from r4876.
Files:
5894fa0d87e655e28ba09152e5461543 1045 net optional cupsys_1.1.99.b1.r4876-1.dsc
8b8ca2007e2fb3221039348ef0dee4c9 6700706 net optional
cupsys_1.1.99.b1.r4876.orig.tar.gz
f02d762f944393393af428d1ae9f27a3 1474155 net optional
cupsys_1.1.99.b1.r4876-1.diff.gz
b01a3ada87ae1c95f5e7cc74ae14abae 996 libs optional
libcupsys2-gnutls10_1.1.99.b1.r4876-1_all.deb
59c1e5805bc278f62ecae290317502af 1676912 net optional
cupsys_1.1.99.b1.r4876-1_i386.deb
d91328759197b3da3d3daf431aa65cad 72896 net optional
cupsys-client_1.1.99.b1.r4876-1_i386.deb
04f5d6fa35f0ade45d395dbd26096605 97738 libs optional
libcupsys2_1.1.99.b1.r4876-1_i386.deb
2eabae6a157b1185745df8bc1e5bcb3b 114590 libdevel optional
libcupsys2-dev_1.1.99.b1.r4876-1_i386.deb
ec28ccdac7f1cb2b515a0226211cf7ff 61082 libs optional
libcupsimage2_1.1.99.b1.r4876-1_i386.deb
629ddb67f75ec62f53c0977928ebb1c8 50434 libdevel optional
libcupsimage2-dev_1.1.99.b1.r4876-1_i386.deb
86dc408d10df71ac98fe2fa42c7ce80d 33894 net extra
cupsys-bsd_1.1.99.b1.r4876-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iEYEARECAAYFAkOYJ7gACgkQQKW+7XLQPLHZtQCfS5Qy8ofHU3HYm3Jzo60ZsDip
ROsAnidJQB8tTZ0IkGyuzFhL7isRyuso
=uUB9
-END PGP SIGNATURE-
Accepted:
cupsys-bsd_1.1.99.b1.r4876-1_i386.deb
to pool/main/c/cupsys/cupsys-bsd_1.1.99.b1.r4876-1_i386.deb
cupsys-client_1.1.99.b1.r4876-1_i386.deb
to pool/main/c/cupsys/cupsys-client_1.1.99.b1.r4876-1_i386.deb
cupsys_1.1.99.b1.r4876-1.diff.gz
to pool/main/c/cupsys/cupsys_1.1.99.b1.r4876-1.diff.gz
cupsys_1.1.99.b1.r4876-1.dsc
to pool/main/c/cupsys/cupsys_1.1.99.b1.r4876-1.dsc
cupsys_1.1.99.b1.r4876-1_i386.deb
to pool/main/c/cupsys/cupsys_1.1.99.b1.r4876-1_i386.deb
cupsys_1.1.99.b1.r4876.orig.tar.gz
to pool/main/c/cupsys/cupsys_1.1.99.b1.r4876.orig.tar.gz
libcupsimage2-dev_1.1.99.b1.r4876-1_i386.deb
to pool/main/c/cupsys/libcupsimage2-dev_1.1.99.b1.r4876-1_i386.deb
libcupsimage2_1.1.99.b1.r4876-1_i386.deb
to
Accepted kdemultimedia 4:3.4.3-5 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Dec 2005 15:43:05 -0500 Source: kdemultimedia Binary: kdemultimedia-kappfinder-data libarts1-audiofile krec kdemultimedia-kfile-plugins kdemultimedia-doc-html kdemultimedia mpeglib akode kmid kmix kaudiocreator libarts1-mpeglib libarts1-xine libkcddb1 kdemultimedia-dev artsbuilder noatun juk kaboodle kdemultimedia-kio-plugins kscd Architecture: source i386 all Version: 4:3.4.3-5 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org Changed-By: Christopher Martin [EMAIL PROTECTED] Description: akode - plugin for aRts artsbuilder - synthesizer designer for aRts juk- music organizer and player for KDE kaboodle - light, embedded media player for KDE kaudiocreator - CD ripper and audio encoder frontend for KDE kdemultimedia - multimedia apps from the official KDE release kdemultimedia-dev - development files for the KDE multimedia module kdemultimedia-doc-html - KDE multimedia documentation in HTML format kdemultimedia-kappfinder-data - multimedia data for kappfinder kdemultimedia-kfile-plugins - au/avi/m3u/mp3/ogg/wav plugins for kfile kdemultimedia-kio-plugins - enables the browsing of audio CDs under Konqueror kmid - MIDI/karaoke player for KDE kmix - sound mixer applet for KDE krec - sound recorder utility for KDE kscd - audio CD player for KDE libarts1-audiofile - audiofile plugin for aRts libarts1-mpeglib - mpeglib plugin for aRts, supporting mp3 and mpeg audio/video libarts1-xine - aRts plugin enabling xine support libkcddb1 - CDDB library for KDE mpeglib- mp3 and mpeg I audio and video library noatun - media player for KDE Changes: kdemultimedia (4:3.4.3-5) unstable; urgency=low . +++ Changes by Christopher Martin: . * Fix the mpeglib noexecstack patch to work on arm, resolving the FTBFS on that architecture. Files: 4b4809ef52603c68217c78362790fe84 1623 kde optional kdemultimedia_3.4.3-5.dsc 126154ee06bd815b42bb40c232f7443e 204132 kde optional kdemultimedia_3.4.3-5.diff.gz 36b8c47c54e1c476ec259b82a88c2596 18288 kde optional kdemultimedia_3.4.3-5_all.deb 183d6da2fbf643710598a51f43c8adca 215140 doc optional kdemultimedia-doc-html_3.4.3-5_all.deb 766c8ee6aab0d3080cd3f2e631ea9c72 190798 devel optional kdemultimedia-dev_3.4.3-5_i386.deb 67cfa44ae0af0492afe303f5bc0734dd 225698 sound optional akode_3.4.3-5_i386.deb e91b8dbca1a77acdf90b771391d4ef9e 2076396 sound optional artsbuilder_3.4.3-5_i386.deb 4afa58a7295e589bfd45256a898693c1 690808 sound optional juk_3.4.3-5_i386.deb a8c507c8c57742fd0232a54b277e9d82 140640 sound optional kaboodle_3.4.3-5_i386.deb 21f08c32b804a9a529d0992c84d4823b 146600 sound optional kaudiocreator_3.4.3-5_i386.deb bbfc5a13257490ed98d8763b56113a06 116180 kde optional kdemultimedia-kfile-plugins_3.4.3-5_i386.deb a63833a81984d5e6806b34b1adafaf89 28692 kde optional kdemultimedia-kappfinder-data_3.4.3-5_i386.deb 0035c6de310c20f75534b729025c1118 128202 kde optional kdemultimedia-kio-plugins_3.4.3-5_i386.deb c61a9673beb1beadf5784c7dd735cd20 266282 sound optional kmid_3.4.3-5_i386.deb d072b303adecf33f8e87064f122afc48 357376 sound optional kmix_3.4.3-5_i386.deb be65028b2f01fbdfa7dd25eea5d2536a 346722 sound optional krec_3.4.3-5_i386.deb 96a232b3dec4c839d8f17d8c8225cebf 415946 sound optional kscd_3.4.3-5_i386.deb bbf98ba7a53da16ea27e3ad19588748c 47646 libs optional libarts1-audiofile_3.4.3-5_i386.deb eddfc6927f31eed0b22e60ab7c7731bd 210212 libs optional libarts1-mpeglib_3.4.3-5_i386.deb b3f3ba62611072a51bc71b8c79a7b806 92812 libs optional libarts1-xine_3.4.3-5_i386.deb bdab00e77cd41981ae6e1483fceef718 131008 libs optional libkcddb1_3.4.3-5_i386.deb 2f58789f7a2f8d41889c6a07198b68d2 242394 libs optional mpeglib_3.4.3-5_i386.deb 10dc4e162e43b26d2a2ebe43b039ff94 2605960 sound optional noatun_3.4.3-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Signed by Christopher Martin [EMAIL PROTECTED] iD8DBQFDmCtmU+gWW+vtsysRAoz2AJ9qEshFz+ZppcT95LSu/NNOQIR5KACcD4+n 1WFIA4cQJ37Os90SKuiw1pM= =vh8u -END PGP SIGNATURE- Accepted: akode_3.4.3-5_i386.deb to pool/main/k/kdemultimedia/akode_3.4.3-5_i386.deb artsbuilder_3.4.3-5_i386.deb to pool/main/k/kdemultimedia/artsbuilder_3.4.3-5_i386.deb juk_3.4.3-5_i386.deb to pool/main/k/kdemultimedia/juk_3.4.3-5_i386.deb kaboodle_3.4.3-5_i386.deb to pool/main/k/kdemultimedia/kaboodle_3.4.3-5_i386.deb kaudiocreator_3.4.3-5_i386.deb to pool/main/k/kdemultimedia/kaudiocreator_3.4.3-5_i386.deb kdemultimedia-dev_3.4.3-5_i386.deb to pool/main/k/kdemultimedia/kdemultimedia-dev_3.4.3-5_i386.deb kdemultimedia-doc-html_3.4.3-5_all.deb to pool/main/k/kdemultimedia/kdemultimedia-doc-html_3.4.3-5_all.deb kdemultimedia-kappfinder-data_3.4.3-5_i386.deb to pool/main/k/kdemultimedia/kdemultimedia-kappfinder-data_3.4.3-5_i386.deb kdemultimedia-kfile-plugins_3.4.3-5_i386.deb to
Accepted gfcui 2.3.1-6 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 10:11:33 -0200 Source: gfcui Binary: libgfcui-2.0-0c2a-dbg libgfcui-2.0-0c2a gfc-examples libgfcui-doc libgfcui-dev Architecture: source i386 all Version: 2.3.1-6 Distribution: unstable Urgency: low Maintainer: Goedson Teixeira Paixao [EMAIL PROTECTED] Changed-By: Goedson Teixeira Paixao [EMAIL PROTECTED] Description: gfc-examples - GTK+ Foundation Classes Examples libgfcui-2.0-0c2a - GTK+ Foundation Classes UI - shared libraries libgfcui-2.0-0c2a-dbg - GTK+ Foundation Classes UI - debug symbols libgfcui-dev - GTK+ Foundation Classes UI - development files libgfcui-doc - GTK+ Foundation Classes UI - API reference documentation Changes: gfcui (2.3.1-6) unstable; urgency=low . * debian/control: updated libgfccore-dev build-depends to 2.3.1-6 so that it will build against the right version. Files: 86b816cc45e3764ad419ca003806959a 739 libs optional gfcui_2.3.1-6.dsc 104855a2682f07e9ed5a1d78dd1bb240 158101 libs optional gfcui_2.3.1-6.diff.gz e024bd90b585f015c182591110185320 3751448 doc optional libgfcui-doc_2.3.1-6_all.deb 04046c99168ef03595824c271451f649 1629408 libdevel optional libgfcui-dev_2.3.1-6_i386.deb 6f9a4c14c6a48d50f6cee1395d0c42eb 6268732 libdevel optional libgfcui-2.0-0c2a-dbg_2.3.1-6_i386.deb 1ae31a4bc30604f958981403a1135f56 644012 libs optional libgfcui-2.0-0c2a_2.3.1-6_i386.deb 977721032579d2681ce883bb39539406 344040 devel optional gfc-examples_2.3.1-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmDae7tjUzB3rjq4RAgSxAKCOM9scNFJKxMBZEd5KMhWLNwpK5gCdFklD h8wBG1ahqS7EWy8a54HI0Is= =Cv11 -END PGP SIGNATURE- Accepted: gfc-examples_2.3.1-6_i386.deb to pool/main/g/gfcui/gfc-examples_2.3.1-6_i386.deb gfcui_2.3.1-6.diff.gz to pool/main/g/gfcui/gfcui_2.3.1-6.diff.gz gfcui_2.3.1-6.dsc to pool/main/g/gfcui/gfcui_2.3.1-6.dsc libgfcui-2.0-0c2a-dbg_2.3.1-6_i386.deb to pool/main/g/gfcui/libgfcui-2.0-0c2a-dbg_2.3.1-6_i386.deb libgfcui-2.0-0c2a_2.3.1-6_i386.deb to pool/main/g/gfcui/libgfcui-2.0-0c2a_2.3.1-6_i386.deb libgfcui-dev_2.3.1-6_i386.deb to pool/main/g/gfcui/libgfcui-dev_2.3.1-6_i386.deb libgfcui-doc_2.3.1-6_all.deb to pool/main/g/gfcui/libgfcui-doc_2.3.1-6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jabberoo 1.9.4+cvs20040709-7 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 11:51:23 -0200 Source: jabberoo Binary: libjabberoo0c2a-dbg libjabberoo0c2a libjabberoo-dev Architecture: source i386 Version: 1.9.4+cvs20040709-7 Distribution: unstable Urgency: low Maintainer: Goedson Teixeira Paixao [EMAIL PROTECTED] Changed-By: Goedson Teixeira Paixao [EMAIL PROTECTED] Description: libjabberoo-dev - library to interact with Jabber libjabberoo0c2a - library to interact with Jabber libjabberoo0c2a-dbg - library to interact with Jabber Closes: 339189 Changes: jabberoo (1.9.4+cvs20040709-7) unstable; urgency=low . * debian/control: fixed dependencies for libjabberoo-dev (Closes: #339189). Files: f40b64b25f7345aa134c8ad8005b8c0b 722 libs optional jabberoo_1.9.4+cvs20040709-7.dsc 0e1b476902e727a788d0c5f87d108b75 294426 libs optional jabberoo_1.9.4+cvs20040709-7.diff.gz d5d6c7add87ad2650f06b685c6762c12 283954 libdevel optional libjabberoo-dev_1.9.4+cvs20040709-7_i386.deb 2f1ae5788cdafa2af8f212a2b3d94490 189960 libs optional libjabberoo0c2a_1.9.4+cvs20040709-7_i386.deb 01cf21f616099196a874e57c77281101 36774 libdevel optional libjabberoo0c2a-dbg_1.9.4+cvs20040709-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmDxb7tjUzB3rjq4RAkjsAJ0UuLymVpGOwFGSjQ8mn5hGY8HdqACgi6Gl bdxkCptfZkgCHtGlnncw84o= =y/YF -END PGP SIGNATURE- Accepted: jabberoo_1.9.4+cvs20040709-7.diff.gz to pool/main/j/jabberoo/jabberoo_1.9.4+cvs20040709-7.diff.gz jabberoo_1.9.4+cvs20040709-7.dsc to pool/main/j/jabberoo/jabberoo_1.9.4+cvs20040709-7.dsc libjabberoo-dev_1.9.4+cvs20040709-7_i386.deb to pool/main/j/jabberoo/libjabberoo-dev_1.9.4+cvs20040709-7_i386.deb libjabberoo0c2a-dbg_1.9.4+cvs20040709-7_i386.deb to pool/main/j/jabberoo/libjabberoo0c2a-dbg_1.9.4+cvs20040709-7_i386.deb libjabberoo0c2a_1.9.4+cvs20040709-7_i386.deb to pool/main/j/jabberoo/libjabberoo0c2a_1.9.4+cvs20040709-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xlife 5.0-6 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 10:21:52 + Source: xlife Binary: xlife Architecture: source i386 Version: 5.0-6 Distribution: unstable Urgency: low Maintainer: Goswin von Brederlow [EMAIL PROTECTED] Changed-By: Goswin von Brederlow [EMAIL PROTECTED] Description: xlife - John Conway's Game of Life, for X11 Closes: 302510 Changes: xlife (5.0-6) unstable; urgency=low . The 'I have an etch to scratch' release: * Acknowledge NMU (should have been sponsored upload) * Adjust Build-Depends for split X libs * Increase DH_COMPAT to 4 * Add -W for CFLAGS - Fix comparison between signed and unsigned - Fix may be used uninitialized - Fix unused parameter - Fix type defaults to 'int * xlife.man: indent example for Owner * Add typos patch from A Costa [EMAIL PROTECTED] (Closes: #302510) Files: 675d2509df1fb3fc95a412adbe9051cb 695 games optional xlife_5.0-6.dsc 805d900de751ff36ac3f3c17ce5d1478 46361 games optional xlife_5.0-6.diff.gz 89f918e2aa97806e0f20c2056f70ef1d 230586 games optional xlife_5.0-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDmEUiriZpaaIa1PkRAhxHAKDS09LP8/w3enRC7h2derydCJkPZQCeNAQ+ U99PiNB3V7xCDX5SAF7jT/s= =Ehc0 -END PGP SIGNATURE- Accepted: xlife_5.0-6.diff.gz to pool/main/x/xlife/xlife_5.0-6.diff.gz xlife_5.0-6.dsc to pool/main/x/xlife/xlife_5.0-6.dsc xlife_5.0-6_i386.deb to pool/main/x/xlife/xlife_5.0-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gibraltar-bootcd 0.53 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 05 Dec 2005 23:21:50 + Source: gibraltar-bootcd Binary: mkinitrd-cd gibraltar-bootsupport Architecture: source i386 Version: 0.53 Distribution: unstable Urgency: low Maintainer: Rene Mayrhofer [EMAIL PROTECTED] Changed-By: Rene Mayrhofer [EMAIL PROTECTED] Description: gibraltar-bootsupport - Boot support for Gibraltar live CD-ROM mkinitrd-cd - Creates an initrd image for booting from a live CD-ROM or USB dev Closes: 339859 Changes: gibraltar-bootcd (0.53) unstable; urgency=low . * Also support squashfs images from USB/CF media in addition to the older cramfs images. squashfs has a better compression and thus produces smaller images and does not have the restriction to roughly 256 MB of uncompressed file system size. * Support (nearly atomic) update of the USB/CF image with a single reboot and option for fallback. This should make failed firmware upgrades (nearly) impossible. * Changed the old serial port speed of 9600 to a more contemporary 38400. * Change priority from optional to extra to match the override file. * mkinitrd-cd: Use the word matching option to grep when trying to figure out if a kernel module should be copied or not. This fixed the useless copying of some otherwise useless modules (e.g. st). * gibraltar-bootsupport: Also deal with interface names ath* in setup.d/01set-ip-addresses (these are used by the madwifi driver). * gibraltar-bootsupport: Updated var-defaults.tar.gz again. * mkinitrd-cd: Rise the RAM disk size in syslinux.cfg from 4096 to 4608 kB to provide more space for the (now larger) initrd images. * mkinitrd-cd: Add more aliases to syslinux.cfg for various appliances and the different stages of failed update attempts. * gibraltar-bootsupport: Depend on iputils-arping, which is needed for checking for IP address conflicts upon first bootup. * gibraltar-bootsupport: Depend on xdelta, which is needed for the patching scripts. * Implement beepconsole with the beep utility even if we are not running on a Linux console (but e.g. over serial). This is necessary for appliances with serial console to beep during bootup. * gibraltar-bootsupport: Add new utilities status-led and lan-bypass to control hardware features of the iBASE FWA7204 appliance. Also include a binary for checking if it is running on an iBASE appliance: check-ibase. * gibraltar-bootsupport: Add a new setup.d script for configuring kernel modules for the iBASE appliance: modules-ibase. * gibraltar-bootsupport: Use /etc/iftab now for renaming interfaces instead of /etc/network/interfaces. This avoids problems with interface order, e.g. when using bridge interfaces. * mkinitrd-cd: Don't include the discover binary in the min initrd images (intended for 1.44 MB floppies) anymore. It just doesn't fit with newer kernels. * mkinitrd-cd: Depend on discover1-data | discover-data now, since the package has been renamed for unstable. Closes: #339859: gibraltar-bootcd: FTBFS: C compiler cannot create executables / * mkinitrd-cd: Fix the regular expression for extracting the module name from the file name (and consequently to check if it needs to be copied to the initrd image). Thanks to Andy Chittenden from BlueArc for finding that issue. * mkinitrd-cd: Add the isofs module to IDE_CD_MODS and SCSI_CD_MODS in probe-devs.sh and cdboot_required_modules in mkinitrd-cd.conf. This makes booting from CD work when the iso9660 filesystem has been compiled as a module (like for the default Debian kernels) instead of statically. Again thanks to Andy Chittenden from BlueArc for pointing that out. * mkinitrd-cd: Fix the shell globbing to be able to deal with an empty list of copied modules (e.g. when the kernel has been statically linked with all required drivers). Thanks to Berk Akinci from Sun for spotting this problem and suggesting the elegant fix of using shopt -s nullglob. * gibraltar-bootcd: Fixed saving the configuration data to the same image that was used for booting the system. The problem was that, when the media was already mounted, it did not get remounted even when it was originally mounted with option ro. Now, when saving to an already mounted partition, it is remounted rw before and again ro after saving the configuration so that this special case will work. Files: 04652642288d7f03a78a239ec0c16591 615 admin extra gibraltar-bootcd_0.53.dsc f59716dc162b9d4b911b9da57bf68445 9011234 admin extra gibraltar-bootcd_0.53.tar.gz 8377da249a10e94894f767b0424c64fa 231642 admin extra mkinitrd-cd_0.53_i386.deb 98f7f997f960322c4e5b427f64bfa83c 89436 admin extra gibraltar-bootsupport_0.53_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux)
Accepted muse 0.7.1+0.7.2pre3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 13:50:08 +0100 Source: muse Binary: muse Architecture: source i386 Version: 0.7.1+0.7.2pre3-1 Distribution: unstable Urgency: low Maintainer: Daniel Kobras [EMAIL PROTECTED] Changed-By: Daniel Kobras [EMAIL PROTECTED] Description: muse - Qt-based midi/audio sequencer Closes: 325064 333198 Changes: muse (0.7.1+0.7.2pre3-1) unstable; urgency=low . * New upstream version. + Includes fix for timer-related crashes. Closes: #325064 * Updated patches: + [30_deleted_signal_64bit_fix] Rediffed for 0.7.2pre3. * Removed patches: + [10_checkbox_fix] + [10_html_doc_cleanup] Both merged upstream. * debian/po/sv.po: Added Swedish translation of of debconf template. Closes: #333198 Files: 87a98cfd2b60f474b7065c8c04329f37 760 sound optional muse_0.7.1+0.7.2pre3-1.dsc 5b465cb2b6d0e9c6697a587820658fbf 2206973 sound optional muse_0.7.1+0.7.2pre3.orig.tar.gz 88b63d0f8c5ac8896c9b9ddce3b4de23 26233 sound optional muse_0.7.1+0.7.2pre3-1.diff.gz b5a2ca79d296640260af74f1d2b0da0e 5232270 sound optional muse_0.7.1+0.7.2pre3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmEVCpOKIA4m/fisRAvSRAKCFx8fdZGU1eCQKzMAA9h20ZbO9iwCfeUnG kDh1IaTA6FsLGSlCmo1KvbU= =9Esp -END PGP SIGNATURE- Accepted: muse_0.7.1+0.7.2pre3-1.diff.gz to pool/main/m/muse/muse_0.7.1+0.7.2pre3-1.diff.gz muse_0.7.1+0.7.2pre3-1.dsc to pool/main/m/muse/muse_0.7.1+0.7.2pre3-1.dsc muse_0.7.1+0.7.2pre3-1_i386.deb to pool/main/m/muse/muse_0.7.1+0.7.2pre3-1_i386.deb muse_0.7.1+0.7.2pre3.orig.tar.gz to pool/main/m/muse/muse_0.7.1+0.7.2pre3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted r-cran-bayesm 2.0-3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 09:04:51 -0500 Source: r-cran-bayesm Binary: r-cran-bayesm Architecture: source i386 Version: 2.0-3-1 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-bayesm - GNU R package for Bayesian inference Changes: r-cran-bayesm (2.0-3-1) unstable; urgency=low . * New upstream release Files: 0bfc3dd0026950a9b2d1389be2a90c37 618 math optional r-cran-bayesm_2.0-3-1.dsc 6a90675885add634f8e1cfcb2f8f5e59 1164351 math optional r-cran-bayesm_2.0-3.orig.tar.gz 6a79b0df770cdce517423ec4976f6ae6 2030 math optional r-cran-bayesm_2.0-3-1.diff.gz 8e95c0c1a5a2d6302a8cbe00f68389be 1295992 math optional r-cran-bayesm_2.0-3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmFj82wQKE6PXubwRAtyPAKCab+V2tjcC4Qn7KZxuDbHMo6sCZwCfVXSi YaUs0GVLFHH5wdIft0v1iuc= =BWCy -END PGP SIGNATURE- Accepted: r-cran-bayesm_2.0-3-1.diff.gz to pool/main/r/r-cran-bayesm/r-cran-bayesm_2.0-3-1.diff.gz r-cran-bayesm_2.0-3-1.dsc to pool/main/r/r-cran-bayesm/r-cran-bayesm_2.0-3-1.dsc r-cran-bayesm_2.0-3-1_i386.deb to pool/main/r/r-cran-bayesm/r-cran-bayesm_2.0-3-1_i386.deb r-cran-bayesm_2.0-3.orig.tar.gz to pool/main/r/r-cran-bayesm/r-cran-bayesm_2.0-3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted zelig 2.4-5-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 08:41:42 -0500 Source: zelig Binary: r-other-gking-zelig r-cran-zelig Architecture: source all Version: 2.4-5-1 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-zelig - GNU R package providing a unified front-end for estimating statis r-other-gking-zelig - Dummy (transition) package for r-cran-zelig Changes: zelig (2.4-5-1) unstable; urgency=low . * New upstream release. Files: 0976012a0a790a05e70ba07f879fab02 670 math optional zelig_2.4-5-1.dsc 304df277c0a993aef45576446df8225b 315597 math optional zelig_2.4-5.orig.tar.gz 6edd1ab681c4ecf6b7eda7bd5441c11f 3083 math optional zelig_2.4-5-1.diff.gz ee3d6e6a88a4374d02e03d152eb8d5bc 406220 math optional r-cran-zelig_2.4-5-1_all.deb 248e282103f71e134f9ac651f033bf65 4808 math optional r-other-gking-zelig_2.4-5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmFmf2wQKE6PXubwRAn4QAJ4oTRh7iYN9m79iwY+UQtY3qr7F2wCgvmcA dI8IvgETtKnFHnf1gwpQj4I= =vqcG -END PGP SIGNATURE- Accepted: r-cran-zelig_2.4-5-1_all.deb to pool/main/z/zelig/r-cran-zelig_2.4-5-1_all.deb r-other-gking-zelig_2.4-5-1_all.deb to pool/main/z/zelig/r-other-gking-zelig_2.4-5-1_all.deb zelig_2.4-5-1.diff.gz to pool/main/z/zelig/zelig_2.4-5-1.diff.gz zelig_2.4-5-1.dsc to pool/main/z/zelig/zelig_2.4-5-1.dsc zelig_2.4-5.orig.tar.gz to pool/main/z/zelig/zelig_2.4-5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted matchit 2.2-5-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 08:45:23 -0500 Source: matchit Binary: r-other-gking-matchit r-cran-matchit Architecture: source all Version: 2.2-5-1 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-matchit - GNU R package of nonparametric matching methods r-other-gking-matchit - GNU R package of nonparametric matching methods (dummy package) Changes: matchit (2.2-5-1) unstable; urgency=low . * New upstream release Files: 2cf8afce94d578513b660747d0f89bf9 653 math optional matchit_2.2-5-1.dsc 6b42a573c50f80fed19d165e029e2fea 31918 math optional matchit_2.2-5.orig.tar.gz 199105e5cbd21e94d7f5ed9804c7858a 2217 math optional matchit_2.2-5-1.diff.gz 985b1b8581dbc4d6e87a18bbf9623a2e 64070 math optional r-cran-matchit_2.2-5-1_all.deb e5c1440af602cf5f61e5206b65c72a42 2234 math optional r-other-gking-matchit_2.2-5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmFjw2wQKE6PXubwRAqmXAKDDwM6VwdAfKO8WYjoOJDzF6OOA9wCgs3HH 7M8BGYPwSDdb9iTNTtGQlH8= =ehmW -END PGP SIGNATURE- Accepted: matchit_2.2-5-1.diff.gz to pool/main/m/matchit/matchit_2.2-5-1.diff.gz matchit_2.2-5-1.dsc to pool/main/m/matchit/matchit_2.2-5-1.dsc matchit_2.2-5.orig.tar.gz to pool/main/m/matchit/matchit_2.2-5.orig.tar.gz r-cran-matchit_2.2-5-1_all.deb to pool/main/m/matchit/r-cran-matchit_2.2-5-1_all.deb r-other-gking-matchit_2.2-5-1_all.deb to pool/main/m/matchit/r-other-gking-matchit_2.2-5-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mcmcpack 0.6-6-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 08:59:17 -0500 Source: mcmcpack Binary: r-cran-mcmcpack Architecture: source i386 Version: 0.6-6-1 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-mcmcpack - GNU R routines for Markov chain Monte Carlo model estimation Changes: mcmcpack (0.6-6-1) unstable; urgency=low . * New upstream release. Files: a14176aa410edf9ae1eff4ad44537d8b 648 math optional mcmcpack_0.6-6-1.dsc 9296e81d33c4297fdeac44486c27c665 281246 math optional mcmcpack_0.6-6.orig.tar.gz 4c6ba51dcdd0db25035675bc9d36cf8f 4010 math optional mcmcpack_0.6-6-1.diff.gz e7bd1f27dbac783a21a5a17d0c8b8045 525538 math optional r-cran-mcmcpack_0.6-6-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmFj22wQKE6PXubwRAvrlAKDWx00QBvaSjCGE+caiDJXlVLY5gACgv7on aoT+LRQk8jxJJaOSx8gKYoA= =A2bm -END PGP SIGNATURE- Accepted: mcmcpack_0.6-6-1.diff.gz to pool/main/m/mcmcpack/mcmcpack_0.6-6-1.diff.gz mcmcpack_0.6-6-1.dsc to pool/main/m/mcmcpack/mcmcpack_0.6-6-1.dsc mcmcpack_0.6-6.orig.tar.gz to pool/main/m/mcmcpack/mcmcpack_0.6-6.orig.tar.gz r-cran-mcmcpack_0.6-6-1_i386.deb to pool/main/m/mcmcpack/r-cran-mcmcpack_0.6-6-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted r-cran-coda 0.10-2-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 10:58:49 -0500 Source: r-cran-coda Binary: r-cran-coda Architecture: source all Version: 0.10-2-1 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-coda - Output analysis and diagnostics for MCMC simulations in R Changes: r-cran-coda (0.10-2-1) unstable; urgency=low . * New upstream release. * Depend on r-cran-lattice. Files: 973f2ef0e866fec578bdb976e3a9750e 627 math optional r-cran-coda_0.10-2-1.dsc 1144705422a4eef271d4ff3323167ec9 69866 math optional r-cran-coda_0.10-2.orig.tar.gz 52330ce6d6539acd28d72252494947af 2687 math optional r-cran-coda_0.10-2-1.diff.gz 874447f2ca4a2820072642c43b19abe0 173216 math optional r-cran-coda_0.10-2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmFkF2wQKE6PXubwRAnHXAJ9aYXl2u701/NTQfci/Zw0AIk9Y0ACggJb9 XvJpycQk3XPMWJYqC4+3K3k= =mGaS -END PGP SIGNATURE- Accepted: r-cran-coda_0.10-2-1.diff.gz to pool/main/r/r-cran-coda/r-cran-coda_0.10-2-1.diff.gz r-cran-coda_0.10-2-1.dsc to pool/main/r/r-cran-coda/r-cran-coda_0.10-2-1.dsc r-cran-coda_0.10-2-1_all.deb to pool/main/r/r-cran-coda/r-cran-coda_0.10-2-1_all.deb r-cran-coda_0.10-2.orig.tar.gz to pool/main/r/r-cran-coda/r-cran-coda_0.10-2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jnettop 0.11.0-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.7 Date: Thu, 8 Dec 2005 10:53:55 -0500 Source: jnettop Binary: jnettop Architecture: source i386 Version: 0.11.0-2 Distribution: unstable Urgency: low Maintainer: Ari Pollak [EMAIL PROTECTED] Changed-By: Ari Pollak [EMAIL PROTECTED] Description: jnettop- View hosts/ports taking up the most network traffic Closes: 326568 Changes: jnettop (0.11.0-2) unstable; urgency=low . * Apply patch from Laszlo Kupor to fix a typo that caused remote host+port aggregation not to work properly (Closes: #326568) Files: c0829e4202cf52a9d68c0f31d7815316 610 net extra jnettop_0.11.0-2.dsc 6c8ac218913a80c580a02f2950bd05e8 27672 net extra jnettop_0.11.0-2.diff.gz 6d05207e4681042f213d707d167b0ad9 32272 net extra jnettop_0.11.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmF1DwO+u47cOQDsRA/npAJ9nqwAGgI9LvUrz3C8yVZhRTRmztACfXb4t 3UeTG95IH7ZYeYWOaGR1U5U= =Gihx -END PGP SIGNATURE- Accepted: jnettop_0.11.0-2.diff.gz to pool/main/j/jnettop/jnettop_0.11.0-2.diff.gz jnettop_0.11.0-2.dsc to pool/main/j/jnettop/jnettop_0.11.0-2.dsc jnettop_0.11.0-2_i386.deb to pool/main/j/jnettop/jnettop_0.11.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
