salutation et cris au secour
Suis gradué en santé publique ,chomeur et orphelin laissé par ses 2 parents qui etaient des locataire.Je vis chez les voisins mais avec bcp de difficultés. Je suis Congolais particulierement au Sud Kivu où la guerre bas ses reccords,pas de paix. Veuillez nous assister car nous sommes en difficultés. Alain Kizungu +243810161735 ou +243997672728 Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez le ici !
Re: Réveillon s le bazar: un premier jet de statuts
On Fri, Dec 09, 2005 at 09:16:40AM +0100, Patrice Karatchentzeff wrote: 2005/12/8, Christian Perrier [EMAIL PROTECTED]: [...] Après le salon [EMAIL PROTECTED] où nou sétions avec Raphaël, j'ai personnellement ressenti un besoin de plus en plus fort de pouvoir donner à Debian une existence légale en France, ne serait-ce que pour que certains puissent parler non en tant qu'individus membres d'un projet flou mais en tant que représentant mandatés de l'entité Debian France. Assurer la visilité du projet en dehors de la communauté geekienne est un challenge important pour nous. J'avoue que j'ai un peu de mal à suivre... en quoi le projet Debian - et particulièrement en étant DD... - est « flou » ? Il a une existence juridique tout à fait légal, non ? Non, il y a SPI aux etats-unis, et l'association allemande, et Debian-UK, mais rien en France. Et Debian en tant que tel n'a aucune existance juridique. Amicalement, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Réveillon s le bazar: un premier jet de statuts
Après le salon [EMAIL PROTECTED] où nou sétions avec Raphaël, j'ai personnellement ressenti un besoin de plus en plus fort de pouvoir donner à Debian une existence légale en France, ne serait-ce que pour que certains puissent parler non en tant qu'individus membres d'un projet flou mais en tant que représentant mandatés de l'entité Debian France. Assurer la visilité du projet en dehors de la communauté geekienne est un challenge important pour nous. J'avoue que j'ai un peu de mal à suivre... en quoi le projet Debian - et particulièrement en étant DD... - est « flou » ? Il a une existence juridique tout à fait légal, non ? - Et Debian, c'est quoi ? -Un projet international de bénévoles ayant pour but de développer un système d'exploitation universel -Comment fait-on si on veut vous faire une donation? -Vous envoyez l'argent aux Etats-Unis, à Software in the Public Interest, en précisant que c'est pour le projet Debian -Ah bon, alors Debian c'est un projet américain? gros blanc :-) Donner une existence légale au projet en France servira à donner une meilleure réponse ici. Cela pourra aussi servir pour démarcher du support (financier, donations en matériels, etc) auprès d'entreprises française...ou d'entités publiques françaises (après [EMAIL PROTECTED], l'Education Nationale me vient à l'esprit). Le lobbying est plus facile quand on représente quelque chose de plus qu'une entité de droit étazunien...:-) Pareil un peu pour ce qui pourrait rapidement démarrer avec ce qui est en train de se mettre en place sous le nom Friends of Debian (http://wiki.debian.org/FriendsOfDebian) et qui a déjà donné les résultats suivants: http://lists.debian.org/debian-devel-announce/2005/12/msg3.html http://lists.debian.org/debian-devel-announce/2005/12/msg4.html J'ai eu une très longue conversation téléphonique avec A. Schuldei qui voulait savoir si des entreprises françaises pourraient être sollicitées autour de Friends of Debian. Pour l'instant, je pense que ce serait difficile tant que le projet n'existe pas dans notre pays autrement que via des individus (aussi brillants soient-ils...:-))) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Réveillon s le bazar: un premier jet de statuts
On Fri, Dec 09, 2005 at 10:51:26AM +0100, Christian Perrier wrote: Après le salon [EMAIL PROTECTED] où nou sétions avec Raphaël, j'ai personnellement ressenti un besoin de plus en plus fort de pouvoir donner à Debian une existence légale en France, ne serait-ce que pour que certains puissent parler non en tant qu'individus membres d'un projet flou mais en tant que représentant mandatés de l'entité Debian France. Assurer la visilité du projet en dehors de la communauté geekienne est un challenge important pour nous. J'avoue que j'ai un peu de mal à suivre... en quoi le projet Debian - et particulièrement en étant DD... - est « flou » ? Il a une existence juridique tout à fait légal, non ? - Et Debian, c'est quoi ? -Un projet international de bénévoles ayant pour but de développer un système d'exploitation universel -Comment fait-on si on veut vous faire une donation? -Vous envoyez l'argent aux Etats-Unis, à Software in the Public Interest, en précisant que c'est pour le projet Debian Remarque qu'il est plus interessant d'envoyer les donations a l'association allemande, qui est au moins une association europeenne, contrairement a SPI. Amicalement, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Réveillons le bazar: un premier jet de statuts
Le vendredi 09 décembre 2005 à 10:51 +0100, Christian Perrier a écrit : Donner une existence légale au projet en France servira à donner une meilleure réponse ici. Juste pour apporter mes deux euro-cents, je trouve en effet très bonne l'idée de créer une structure juridique. C'est quelquechose qui manque cruellement à mon sens (je m'étais déjà fait la réflexion il y a quelque temps d'ailleurs). Bon, je m'inscris de ce pas sur [EMAIL PROTECTED] ;) -- Alexis Sukrieh [EMAIL PROTECTED]
Re: Réveillons le bazar: un premier jet de statuts
Alexis Sukrieh a écrit : Le vendredi 09 décembre 2005 à 10:51 +0100, Christian Perrier a écrit : Donner une existence légale au projet en France servira à donner une meilleure réponse ici. Bonjour, Je suis Éric Mercier, et je participe aux développement des projets soutenus par la fraîche association S.L.I.S. ( Solutions Libres pour l'Informatique Scolaire - http://asso.slis.fr/ ). Particulièrement au développement de SLIS4 ( SLIS : Serveurs Linux pour l'Internet Scolaire http://www.slis.fr/ ). La version 4 de SLIS est sous Debian. (Il y a autour de 6000 / 7000 serveurs SLIS déployés dans les établissements scolaires, Collèges, Lycées, Ecoles) J'ai eu le plaisir de rencontrer Raphaël Hertzog et Christian Perrier à [EMAIL PROTECTED] Ce préambule pour affirmer, à mon tour, qu'une structure officielle et légale, pourra nous aider dans notre travail. En effet, on nous oppose souvent aux solutions professionnelles, et le manque de structure pour nous défendre et nous soutenir pourrait être à l'avenir fort pénalisant. Le *marché* potentiel que nous couvrons est convoité. Je ne sais pas sous quelles formes nous pourrions profiter de nos efforts respectifs. Bien cordialement -- Eric Mercier -- 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 10:32:40PM +0100, Frank Küster wrote: Feature requests and other things are always welcome! I can't know what you want until you tell it to me. ;) Nothing - these the questions I was mainly interested in regarding buildd's: - is my package already built everywhere, so that it can go into testing? - did it FTBFS, and do the logs give indication why? - How can I get information from inside a buildd, e.g. temporary files created during a failed build. The first two can be answered without buildd.net (and actually I never was very much interested in so when will it be built?), the latter needs, well, a buildd admin must contact me... A buildd admin doesn't see much more than what you can see in the build logs. Basically the build logs is all a buildd admin see. But the buildd admin for sure has read access to /tmp in the build chroot? Assuming that /tmp isn't cleared after each build, but just every couple of hours/days/whatever. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: State of gcc 2.95 use in Debian unstable
Dear Thiemo, we very much appreciate your work on the gcc-2.95 debian package. For us - and probably also for other users in the scientific community - the old compiler version is still of great value. We use gcc-2.95 to compile C/C++ code with very large mathematical expressions generated by computer algebra software. This involves very long (several thousand lines of code) functions to evaluate multi-variable polynomial expression resulting from perturbation theoretical solutions of physical problems. We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. The C/C++ codes generated from the computer algebra software are perhaps unusual but not broken. Since what we are doing is not so unusual in theoretical physics we are probably not alone with these kind problems. Please consider that even if no other debian packages would depend on gcc-2.95 many users may very much require it. Best regards, Heiko -- Dr. Heiko Mueller Englerstr. 28 Tel: +49 6221 89467-21 CEOS GmbH D-69126 Heidelberg Fax: +49 6221 89467-29 Germany http://www.ceos-gmbh.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 09:43:36AM +0100, Frank Küster wrote: Ingo Juergensmann [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 10:32:40PM +0100, Frank Küster wrote: Feature requests and other things are always welcome! I can't know what you want until you tell it to me. ;) Nothing - these the questions I was mainly interested in regarding buildd's: - is my package already built everywhere, so that it can go into testing? - did it FTBFS, and do the logs give indication why? - How can I get information from inside a buildd, e.g. temporary files created during a failed build. The first two can be answered without buildd.net (and actually I never was very much interested in so when will it be built?), the latter needs, well, a buildd admin must contact me... A buildd admin doesn't see much more than what you can see in the build logs. Basically the build logs is all a buildd admin see. But the buildd admin for sure has read access to /tmp in the build chroot? Assuming that /tmp isn't cleared after each build, but just every couple of hours/days/whatever. Due to disk shoreage on a significant amount of buildd's, to the best of my knowledge, the build tree is removed quite immediately after the build finishes, and only a rebuild would be able to give you more info. But surely, a porter owns the hardware in question too, and can simply test-built it himself? *That* is work that any interested porter can do, in the process, debugging the problem, and ultimately filing a useful bugreport, hopefully with patch -- and maybe do a porter NMU later, even -- prefereable still with i386 or so so that it is verified that this time around, the buildd indeed is capable of building the package. Yes, there can be hardware or software (kernel) differences between the porter's machine and the buildd. If that is the case, indeed one should contact the buildd administrator in question if more info is needed, but generally, I'd expect porters to be able to know their hardware well enough to find out what the issue is anyway. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Jeroen van Wolffelaar [EMAIL PROTECTED] wrote: On Fri, Dec 09, 2005 at 09:43:36AM +0100, Frank Küster wrote: Ingo Juergensmann [EMAIL PROTECTED] wrote: A buildd admin doesn't see much more than what you can see in the build logs. Basically the build logs is all a buildd admin see. But the buildd admin for sure has read access to /tmp in the build chroot? Assuming that /tmp isn't cleared after each build, but just every couple of hours/days/whatever. Due to disk shoreage on a significant amount of buildd's, to the best of my knowledge, the build tree is removed quite immediately after the build finishes, and only a rebuild would be able to give you more info. What do you mean with build tree? I assume it's the tree where the sources of the package are unpacked and dpkg-buildpackage is called? This is not what I want. In the case I am talking about, tetex-bin was installed as a build-dependency, but failed in its postinst. The other package FTBFS, and a bug was filed against tetex-bin. When tetex-bin's postinst fails as it did there, it leaves a temporary file in /tmp, and this file I wanted to investigate. Even if /tmp had been cleaned between the failed build and me sending the mail, the buildd admin could have remembered this when he found the next package FTBFS the same way (which happened in fact a couple of days later). Since I didn't know a contact address, I wrote to debian-admin, and for sure they would have been able to at least look into /var/debbuild/tmp/ and check whether our file was still there, but I didn't get a reply from them, either. And I still don't know whether there's a strange corner case where tetex-bin fails to configure, or it was just a fcked up /var/debbuild, or hardware problems on sarti. But surely, a porter owns the hardware in question too, and can simply test-built it himself? *That* is work that any interested porter can do, in the process, debugging the problem, and ultimately filing a useful bugreport, hopefully with patch -- and maybe do a porter NMU later, even -- prefereable still with i386 or so so that it is verified that this time around, the buildd indeed is capable of building the package. Since the package had been configured on hppa without problems previously, it wasn't a simple architecture problem, and simply installing it on hppa would not have revealed the bug. Either there is a bug, then it was a consequence of the specific order of installs, removals, purges, and upgrades in the sarti debbuild environment; in this case only looking at this environment could help to debug. Or sarti suffers from hardware problems. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Need pain pills?reply/ [EMAIL PROTECTED]
Re: buildd administration
On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote: 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. It tells you what the buildd admins are doing with the buildds. It doesn't tell you why they're doing that, of course, but if that's what you want to know you're better off creating an environment where folks are interested in talking to you. 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? No, because I've no idea what your request was or what its importance was compared to other pressing issues. If there was a page tracking such issues that I could follow -- like the one Jeroen set up for tracking and diagnosing removals needed from the archive prior to his inclusion in the ftpteam -- I might be able to do so, but I understand you're dismissive of that approach. 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. That's your choice. 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. Not at all. Indeed, that's happened in the past -- Joey and James tried to close new-maintainer in July 1999 insisting they needed help, and n-m continued in a crap state until October when James quit from new-maintainer outright. It nevertheless took until April 2000 before new maintainers began being accepted. And new-maintainer's not without it's continuing problems even after that process. I don't think that's a model that bears repeating, personally. You're welcome to your own opinion of course. 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. Perhaps you should talk to Nathaniel, who seems to think public criticism is effective in today's Debian, and work out some consensus reality. This is an infantile and counterproductive attempt to maintain control and a sense of superiority. I don't believe this is the case. If you believe you know the people involved better than I do, and your judgement is thus better informed, you are, again, welcome to it. How many more years are we going to waste time with this hysteria before realising it doesn't achieve anything but rapidly sucking the fun out of things? (BTW, I see #335981 and #336371 haven't received a response since late October; or has raptor been down that entire time, so that you haven't been able to diagnose it further -- it certainly seems down now?) Cheers, aj signature.asc Description: Digital signature
FYI, current mirror sizes
Hi, I got a bugreport requesting exected mirror sizes to be added to the debmirror documentation and I thought some of you might be intrested in them too. So heres the stats: Mirror size for a singe arch and binary only (in MiB): | sarge | etch | sid | all -+---+--+---+--- main | 8816 | 9126 | 10777 | 20577 contrib | 126 | 118 | 291 | 363 non-free | 282 | 345 | 464 | 666 d-i | 44 | 28 |31 |78 all | 9187 | 9536 | 11476 | 21502 Mirror size per arch (in MiB): | sarge | etch | sid | all -+---+--+---+--- source | 9339 | 9419 | 11495 | 30252 all | 4478 | 5047 | 6160 | 10459 alpha| 4256 | 3906 | 4732 | 9708 amd64| 3644 | 3635 | 4877 | 9152 arm | 3445 | 3193 | 3933 | 7845 hppa | 4112 | 3713 | 4541 | 9167 i386 | 4422 | 3979 | 5005 | 10477 ia64 | 4709 | 4489 | 5316 | 11043 m68k | 3372 | 3072 | 3664 | 7139 mips | 3631 | 3364 | 4099 | 8237 mipsel | 3560 | 3319 | 4049 | 8106 powerpc | 4208 | 3967 | 4742 | 9915 s390 | 3673 | 3452 | 4144 | 8489 sparc| 3761 | 3585 | 4390 | 8893 All numbers reflect the state of 2005 Dec 9th. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote: 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. And that is exactly what is wrong with Debian. This crash and burn attitude. Never ask for help even if you work yourself to death and have to ignore 50% of the problems. You have to ask for help before everything blows up. You have to ask for help at a time when you still have some spare resources to train extra help. Frankly for several key positions it seems way over due for a scream for more volunteers. On a practical side how should other people work out what help is needed if they are untrained and unable to even grasp what the actualy problems are? You can't help with a problem enclosed in a shroud of mystery. People are blindly guessing that something is wrong and all you are saying is: No that's not it, he said so. Guess again. 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*. Black Box science: Put X in, Y comes out. -- conclusion: Doing X produces Y. Take the lid of the box so people can see what it is actualy doing. == Transparency. Cheers, aj MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 11:49:05PM +1000, Anthony Towns wrote: On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote: 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. It tells you what the buildd admins are doing with the buildds. No, sorry, it tells you what the admins are doing with the build logs. I'm sure there's less of it nowadays than there used to be, but there's always been a certain amount of handholding in the buildd system configuration, et cetera. I'm not saying that this all needs to be publicly logged. I don't give a rat's ass whether it is or not. But please don't stand there saying that the process is completely transparent. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Steve Langasek [EMAIL PROTECTED] writes: 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. What about it is hackish? It can be as simple as just adding -m32 to CFLAGS on amd64 (and ia64) and adding the right Build-Depends on the 32bit devel libs (ia32-libs-dev). We already have this for lilo, grub, some other bootloader I can never remember. Other packages for this sort of thing are wine and if you want to go crazy even OOo. But again, what about it is hackish? 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. The quinn diff warning suites that fine. Just let the cron job report any differences in its stderr output. I fail to see how downloading the source, extracting the source, downloading and installing all Build-Depends, seeing there is nothing to do and cleaning it all up again is doing anything but waste valuable time. (Or does sbuild fail before the Build-Depends? Scratch those then.) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: circular (source) dependencies!?
Turbo Fredriksson [EMAIL PROTECTED] writes: 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? Use prebuild debs possibly with --force-depends. Alternatively build them manualy. Possibly even configure them on a sarge/etch/sid system and then compile on your semi woody. Once you have them in /usr/local force the build-depends. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342691: ITP: freetalk -- Freetalk is a console based Jabber client. It features a readline interface with completion of buddy names, commands and even ordinary English words! Freetalk is extensibl
Package: wnpp Severity: wishlist * Package name: freetalk Version : 0.5 Upstream Author : Anand Avati [EMAIL PROTECTED], et al. * URL : http://freetalk.nongnu.org * License : GPL Description : Freetalk is a console based Jabber client. Freetalk is a console based Jabber client. It features a readline interface with completion of buddy names, commands and even ordinary English words! Freetalk is extensible, configurable and scriptable through a Guile interface. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Heiko Müller [EMAIL PROTECTED] writes: We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. The C/C++ codes generated from the computer algebra software are perhaps unusual but not broken. Can you send in a few (hopefully short) examples that fail as bugreports? There is probably nothing to do about compile time and memory consuption but it should at least work. Maybe the compiled result is even faster. 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 04:52:31PM -0500, Nathanael Nerode wrote: 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. Where should I best complain for your NM application to be cancelled? 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]
Bug#342700: ITP: freehoo -- Freehoo is a free console based Yahoo! Messenger client.
Package: wnpp Severity: wishlist Owner: Baishampayan Ghose [EMAIL PROTECTED] * Package name: freehoo Version : 3.4.1 Upstream Author : Anand Babu [EMAIL PROTECTED], et al. * URL : http://freehoo.nongnu.org * License : GPL Description : Freehoo is a free console based Yahoo! Messenger client. Freehoo is a freely available GNU messenger for Yahoo! protocol. It is console based application with geeky readline and guile interfaces. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FYI, current mirror sizes
* Goswin von Brederlow: Mirror size per arch (in MiB): | sarge | etch | sid | all -+---+--+---+--- source | 9339 | 9419 | 11495 | 30252 This looks suspicious. I expected that the total number would be significantly less than the sum of the suites because some of the quite a few of the .orig.tar.gz files are shared. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Le vendredi 09 décembre 2005 à 16:27 +0100, Michael Banck a écrit : On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote: 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. Where should I best complain for your NM application to be cancelled? On what grounds? Oh, and this kind of threat makes me sick. It just feels like, for you, non-DD contributions are second-class contributions. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: buildd administration
Le vendredi 09 décembre 2005 à 12:07 +1000, Anthony Towns a écrit : That's non-sensical. Everything the buildds do is logged pretty much immediately onto http://buildd.debian.org/, which also provides long running statistics on how effective the buildds are, and even a schedule of what the buildds will be working on next. There is absolutely zero documentation on how the buildd network works. You know, the things you have to be aware of if you want to give a hand. 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. It isn't a response, because a problem you report isn't really fixed until you've been warned it has been fixed. How do you know when you can rely on the problem being fixed? How do you know whether the problem has just vanished - meaning in can appear again - or has been dealt with? How do you know whether your request has just been throwned to /dev/null or delayed for a few days? I have to wonder all these things every time I send an email to [EMAIL PROTECTED] 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. Why would it make his work not good for our use? The buildd.net software is obviously much superior to buildd.debian.org, but it hasn't been integrated; the fact his author is Ingo Juergesmann shouldn't matter. 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. Sorry, but it's simply not possible. When you don't have the required credentials, you can't do anything with the buildd network. When you don't know personally its internals, which are not documented, you don't even know where to start. I don't believe it's that easy to dig into them. 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. Then, will someone explain what happened to get things fixed? You seem to be fairly affirmative about this, so you probably know. Maybe you can take a few minutes of your precious time to explain what was done and by whom to the pitiful other developers. It could save a lot of time later, if people ask things correctly and to the right person instead of complaining and trolling in this mailing list. 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*. Oh right, there is no problem with waiting for 2 months for a keyring update. Tout va très bien, Madame la marquise. Haven't you noticed that while there can be obnoxious persons, most people start to complain only when things become really unbearable? And believe me or not, but the way some buildd administrators are treating email requests is not something acceptable, even for volunteers. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: buildd administration
Le vendredi 09 décembre 2005 à 23:49 +1000, Anthony Towns a écrit : How many more years are we going to waste time with this hysteria before realising it doesn't achieve anything but rapidly sucking the fun out of things? How many developer resignations will you need to understand inaction from people at key positions sucks the fun out of things in a worse way? If the responsibility position isn't fun enough for the work to be done, the person holding that position should resign. It probably required some courage from you do resign from being release manager, and you deserve credits for doing it instead of letting things rot. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: buildd administration
* Josselin Mouette [EMAIL PROTECTED] [2005:12:09 17:48 +0100]: Le vendredi 09 d?cembre 2005 ? 12:07 +1000, Anthony Towns a ?crit : 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. Why would it make his work not good for our use? The buildd.net software is obviously much superior to buildd.debian.org, but it hasn't been integrated; the fact his author is Ingo Juergesmann shouldn't matter. Where is the buildd.net software located? I poked around on the site but I couldn't find it except for the update-buildd.net script. -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Josselin Mouette [EMAIL PROTECTED] writes: Le vendredi 09 décembre 2005 à 12:07 +1000, Anthony Towns a écrit : That's non-sensical. Everything the buildds do is logged pretty much immediately onto http://buildd.debian.org/, which also provides long running statistics on how effective the buildds are, and even a schedule of what the buildds will be working on next. There is absolutely zero documentation on how the buildd network works. You know, the things you have to be aware of if you want to give a hand. There is documentation. Just not where you would normaly look. Try http://buildd.net/ 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. Sorry, but it's simply not possible. When you don't have the required credentials, you can't do anything with the buildd network. When you don't know personally its internals, which are not documented, you don't even know where to start. I don't believe it's that easy to dig into them. And when you try you get screamed at and flamed as witnessed in the huge buildd flame fest the last time. Iirc some 3000 packages were build outside the official buildd network across the involved archs at that time. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FYI, current mirror sizes
Florian Weimer [EMAIL PROTECTED] writes: * Goswin von Brederlow: Mirror size per arch (in MiB): | sarge | etch | sid | all -+---+--+---+--- source | 9339 | 9419 | 11495 | 30252 This looks suspicious. I expected that the total number would be significantly less than the sum of the suites because some of the quite a few of the .orig.tar.gz files are shared. Right. Thanks for noticing. According to du -m it takes 18409 MiB. The number comes from debmirror itself so there is something wrong adding up the amount of downloads. Another bug to hunt. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, 9 Dec 2005 12:07:11 +1000, Anthony Towns aj@azure.humbug.org.au said: 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. If they are too busy to ask for help (!!), then certainly the work they are tasked with is probably suffering as well; I mean, if they are too busy to ask for help, they are also likely to be too busy to do a good job. Add to that the situations where people can not very easily help all by themselves (for example, if critical information required to perform the task is unavailable to the unwashed masses), it seems to me that this is the purvey of the DPL, who ought to be looking to add people to the delegate team. Indeed, this is solidly one of the major tasks of the DPL, to ensure that the delegates are able to perform their delegated tasks, and to provide additional help when they are burning out are far too busy. Branden, isn't this issue of delegation one of the foundations of your platform? manoj -- A complex system that works is invariably found to have evolved from a simple system that worked. -- John Gall, _Systemantics_ Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, 9 Dec 2005 16:27:10 +0100, Michael Banck [EMAIL PROTECTED] said: On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote: 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. Where should I best complain for your NM application to be cancelled? Err, so if a NM candidate speaks as openly as some DD's do, they get threatened with having their applications cancelled because of them speaking their minds? What is this, a munich beer hall in 1933? manoj disgusted -- Miguel Cervantes wrote Donkey Hote. Milton wrote Paradise Lost, then his wife died and he wrote Paradise Regained. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
* Manoj Srivastava [EMAIL PROTECTED] [2005:12:09 12:47 -0600]: Err, so if a NM candidate speaks as openly as some DD's do, they get threatened with having their applications cancelled because of them speaking their minds? What is this, a munich beer hall in 1933? Isn't the point of NM to weed out people before they become problematic DDs? My impression was that this applied to overall personality / how well you play with others, as well as technical ability. Surely flaming people on mailing lists as a way to get things done is not something people want to encourage in NMs... right? Wouldn't Debian want to find people who can think of new and inventive ways to achieve goals rather than resorting to these measures? Especially since they *don't work*. -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 05:48:13PM +0100, Josselin Mouette wrote: Le vendredi 09 décembre 2005 à 12:07 +1000, Anthony Towns a écrit : That's non-sensical. Everything the buildds do is logged pretty much immediately onto http://buildd.debian.org/, which also provides long running statistics on how effective the buildds are, and even a schedule of what the buildds will be working on next. There is absolutely zero documentation on how the buildd network works. You know, the things you have to be aware of if you want to give a hand. http://www.debian.org/devel/buildd/ The 3 html pages above contain about 3500 words of explanation about the buildd network. Plus there is the source, and quite a number of people with pretty good insight -- insight you too can become if you're starting to read up about what it is, reading various sources, talk to various people about it, etc. Ryan Murray didn't tell me much if anything about the buildd network when I was trying to understand it, because I had no reason to go ask him -- yes, documentation is certainly not perfect, but that's a general issue of most of the things in the free software world. Numerous people have shown that if you just try, you'll find plenty of information. What indeed really could be improved, and Frank Küster helpfully filed a wishlist bug for that on www.d.o, is listing somewhere contact addresses for the buildd admins in case there is a buildd-system related issue. Isn't it more productive anyway that if there's percieved lack of documentation to simply actively work on that, rather than complaining loudly? Or that if you think the process itself has flaws or is understaffed, to help productively, like Anthony Towns notes[1]? Because, hey, Anthony is right there. Let me tell you story of http://buildd.debian.org/~jeroen/status/ -- I noticed that sometimes due to system crashes, network downtime, or whatnot, a few packages might end up in state 'Building' for a prolonged time, and that there was no automated mechanism to unstuck it -- it needed someone to note that, and then the buildd admin requeued it. Instead of complaining loudly about that on the lists, I asked myself how this could be resolved. The first thing needed for that was detection of the issue itself, so I wrote the above-mentioned page. And I noted that the problem was much less than I thought. Anyway, Steve Langasek picked up actually looking at it regularly, and feeding back give-back suggestions to the buildd admins when needed. And after a while he was granted full wanna-build access to do it himself, because he has shown to understand how it works. A similar issue I noted in the past is the big number of build failures that don't get tagged 'Failed'. I tried working on classifying them, but got bored so increadibly fast that I gave up, and decided for myself this should be something the porters should rather look into. And thus I mailed in June about that[2]. I don't believe anyone picked up that, but I might be wrong, of course, my mail was hidden in a big thread about various stuff, just like this very mail is... Someone interested in porting (actually, I personally am myself not interested at all), should maybe mail to all arch-specific lists some request similar to Vince Sanders' request[3] regarding classifying arm failures. --Jeroen [1] http://lists.debian.org/debian-devel/2005/12/msg00323.html [2] http://lists.debian.org/debian-devel/2005/06/msg00674.html [3] http://lists.debian.org/debian-devel-announce/2005/12/msg2.html -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, December 9, 2005 20:02, Erinn Clark wrote: Surely flaming people on mailing lists as a way to get things done is not something people want to encourage in NMs... right? Wouldn't Debian want to find people who can think of new and inventive ways to achieve goals rather than resorting to these measures? Especially since they *don't work*. I'm not really convinced that such an approach would have a significant effect as long as you're not measuring existing DD's to the same standards. Which, as far as I can see, does not happen. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, 9 Dec 2005 14:02:17 -0500, Erinn Clark [EMAIL PROTECTED] said: * Manoj Srivastava [EMAIL PROTECTED] [2005:12:09 12:47 -0600]: Err, so if a NM candidate speaks as openly as some DD's do, they get threatened with having their applications cancelled because of them speaking their minds? What is this, a munich beer hall in 1933? Isn't the point of NM to weed out people before they become problematic DDs? My impression was that this applied to overall personality / how well you play with others, as well as technical ability. Surely flaming people on mailing lists as a way to get things done is not something people want to encourage in NMs... right? Wouldn't Debian want to find people who can think of new and inventive ways to achieve goals rather than resorting to these measures? Especially since they *don't work*. I'm surprised you think raising ones voice civilly in concern about a problem area in Debian is not playing nicely with others. Is your contention that some volunteers are so much more equal than others that no voices may ever be raised in concern about their (lack of) performance ever again? Nathaniel Nerode's postings have never been uncivil, they have never called anyone names, has never failed to respond in a manner which rises above civil discourse (at least, in the mails I have looked at, which were just this last 10 days or so) -- so I am forced to come to the conclusion that you must equate any dissent as not playing nice. In that light, how do you view your dissent with a member of the tech ctte and a senior debian developer? Would people be correctly justified in asking for you application to be rescinded as well? (;-), for the humour impaired). manoj -- The big cities of America are becoming Third World countries. Nora Ephron Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
* Manoj Srivastava [EMAIL PROTECTED] [2005:12:09 13:27 -0600]: I'm surprised you think raising ones voice civilly in concern about a problem area in Debian is not playing nicely with others. Is your contention that some volunteers are so much more equal than others that no voices may ever be raised in concern about their (lack of) performance ever again? I just don't think encouraging flames is going to result in clever solutions, which are, to me, far more interesting. One can voice their concerns all day long and at the end of the day that is all they will have achieved. Whooptee doo. But no, I am not trying to regulate free speech, if that's what you mean. :) so I am forced to come to the conclusion that you must equate any dissent as not playing nice. Aww. -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, 9 Dec 2005 15:06:26 -0500, Erinn Clark [EMAIL PROTECTED] said: * Manoj Srivastava [EMAIL PROTECTED] [2005:12:09 13:27 -0600]: I'm surprised you think raising ones voice civilly in concern about a problem area in Debian is not playing nicely with others. Is your contention that some volunteers are so much more equal than others that no voices may ever be raised in concern about their (lack of) performance ever again? I just don't think encouraging flames is going to result in clever solutions, which are, to me, far more interesting. Who was encouraging flames? Nathanael said: On Thu, 8 Dec 2005 16:52:31 -0500, Nathanael Nerode [EMAIL PROTECTED] 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. This is a qualified observation, not an encouragment -- unless you buy the observation, and subscribe to that approach -- in any case, implying that Nathanael encouraged flaming is specious, slanderous, and incorrect. One can voice their concerns all day long and at the end of the day that is all they will have achieved. Whooptee doo. But no, I am not trying to regulate free speech, if that's what you mean. :) No, however, you do seem to be slandering a fellow NM candidate. Please desist. Or provide some proof of your claim he is encouraging flames. manoj -- Human industry, if left to itself, will naturally find its way to the most useful and profitable employment. -- Adam Smith Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: - How can I get information from inside a buildd, e.g. temporary files created during a failed build. First pass answer: you can't. sbuild (tries to) clean up after builds. Alternate: try to get a porter to redo the build and give you the desired info. Best: rewrite your build script to put the desired info into the build log. Instead of: foo /tmp/foo 21 use: if foo /tmp/foo 21 ; then : ; else cat /tmp/foo ; exit 1 ; fi -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
In article [EMAIL PROTECTED] [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. and get threats from the current buildd administrator to make sure you don't do that. (Who could abuse his power as part of other teams to do that.) Been there, done that. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
* Erinn Clark [EMAIL PROTECTED] [2005:12:09 12:45 -0500]: * Josselin Mouette [EMAIL PROTECTED] [2005:12:09 17:48 +0100]: Le vendredi 09 d?cembre 2005 ? 12:07 +1000, Anthony Towns a ?crit : 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. Why would it make his work not good for our use? The buildd.net software is obviously much superior to buildd.debian.org, but it hasn't been integrated; the fact his author is Ingo Juergesmann shouldn't matter. Where is the buildd.net software located? I poked around on the site but I couldn't find it except for the update-buildd.net script. (Replying to myself after getting an answer on IRC from Ingo...) The short summary to my answer is that buildd.net software is not publicly available, which may explain at least part of the reason it's not integrated. This was apparently explained in some other buildd thread, but I'm not sure which one or where to look. -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 04:08:55PM -0500, Erinn Clark wrote: Where is the buildd.net software located? I poked around on the site but I couldn't find it except for the update-buildd.net script. (Replying to myself after getting an answer on IRC from Ingo...) The short summary to my answer is that buildd.net software is not publicly available, which may explain at least part of the reason it's not integrated. This was apparently explained in some other buildd thread, but I'm not sure which one or where to look. Please stop assuming wrong facts. As I already stated several times before: Ryan was offered to integrate the buildd.net software. He declined with the argument that all information is already available on buildd.d.o. That's a clear sign that he doesn't want to integrate it. Blame him, not me. And where is the source for buildd.debian.org? -- 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: Intel notebooks for needy developers in developing countries
El Jueves, 8 de Diciembre de 2005 7:14, Andreas Schuldei escribió: ... i can try to come up with a list of countries if it helps. For some reason I don't understand, hitting reply on most messages in the list brings up the new message window with the correct To: address (debian-devel@lists.debian.org), but hitting it on yours did not last night. Not until tody I realized about that. So I'm resending the message to the correct address: Does a country considered by the U.S. government as terrorist, or with which having commercial relationships is forbidden for american companies, apply for this offering? I'm far from being interested in these computers, but I think it's worth asking. Note the country in my email address. Regards, Andy.
Re: buildd administration
Ingo Juergensmann [EMAIL PROTECTED] writes: Please stop assuming wrong facts. As I already stated several times before: Ryan was offered to integrate the buildd.net software. He declined with the argument that all information is already available on buildd.d.o. That's a clear sign that he doesn't want to integrate it. Blame him, not me. And where is the source for buildd.debian.org? If you want to replace an existing infrastructure, you have to clearly demonstrate that the new stuff is better. Saying that it's okay that the new stuff isn't publically available because the old stuff isn't either doesn't help the cause any. Also, it's somewhat ironic that, in a thread where much has been made of how overloaded the existing buildd administrators are, the offer of the buildd software was made privately to one of those overloaded individuals. (And were they then allowed to make it public?) C'mon, this is a free software project. The obvious first step for providing better infrastructure would be to make that infrastructure publically available for anyone to download, play with, hack on, or otherwise evaluate, whether the existing infrastructure component is similarly available or not. I'd think this would just be common sense. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- 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 Fri, 9 Dec 2005 11:52:07 -0500, Andy Teijelo Pérez wrote El Jueves, 8 de Diciembre de 2005 7:14, Andreas Schuldei escribió: ... i can try to come up with a list of countries if it helps. For some reason I don't understand, hitting reply on most messages in the list brings up the new message window with the correct To: address (debian-devel@lists.debian.org), but hitting it on yours did not last night. Not until tody I realized about that. So I'm resending the message to the correct address: Does a country considered by the U.S. government as terrorist, or with which having commercial relationships is forbidden for american companies, apply for this offering? I'm far from being interested in these computers, but I think it's worth asking. Note the country in my email address. I can almost bet that Cuba is not getting any. .Alejandro Regards, Andy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel notebooks for needy developers in developing countries
* Andy Teijelo Pérez [EMAIL PROTECTED] [2005-12-09 11:52:07]: Does a country considered by the U.S. government as terrorist, or with which having commercial relationships is forbidden for american companies, apply for this offering? I got some wise advice about not to make the contry the ulitmate critera (and to NOT give a list of countries). So if there would live a person in cuba working hard on debian and being unable to afford a computer, I would not exclude him because the US government does not like cuba. (I come from the old europe myself, after all. :-) I am not the one makeing the ulitmate decision, though. I just put together the list. signature.asc Description: Digital signature
ALSA packager needed
The ALSA packaging team needs help. We really need someone with expertise in programming for the ALSA library. If you are able to help us, please contact us at [EMAIL PROTECTED] -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Heiko Müller writes: We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. please be more precise. Debian currently uses 4.0, and has a 4.1 prerelease in the archives (gcc-snapshot). such regressions are best filed as bug reports with a self-contained example. thanks, Matthias
Co-maintainers sought
I seek co-maintainers for: mwavem thinkpad, tpctl resolvconf -- Thomas Hood -- 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: * Andy Teijelo Pérez [EMAIL PROTECTED] [2005-12-09 11:52:07]: Does a country considered by the U.S. government as terrorist, or with which having commercial relationships is forbidden for american companies, apply for this offering? I got some wise advice about not to make the contry the ulitmate critera (and to NOT give a list of countries). So if there would live a person in cuba working hard on debian and being unable to afford a computer, I would not exclude him because the US government does not like cuba. (I come from the old europe myself, after all. :-) I couldn't care less about the US government. Is just the fact that if the PC is done in any of the associated countries, they are not allowed to distribute to those countrys. In other words, MIT, Intel, AMD or whoever OEM that is actually part of the US would never be allowed to ship to Cuba. Never. It would have to be all done by some Japan company or so. .Alejandro I am not the one makeing the ulitmate decision, though. I just put together the list. -- 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 Sat, Dec 10, 2005 at 12:14:59AM +0100, Andreas Schuldei wrote: having commercial relationships is forbidden for american companies, apply for this offering? I got some wise advice about not to make the contry the ulitmate critera (and to NOT give a list of countries). So if there would live a person in cuba working hard on debian and being unable to afford a computer, I would not exclude him because the US government does not like cuba. (I come from the old europe myself, after all. :-) I am not the one makeing the ulitmate decision, though. I just put together the list. Yeah that would be a real pain to exlude countries because of stupid political 'correctness'. All in all in Free Software movement we don't know what the borders are, do we? 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: buildd administration
Erinn Clark writes: Surely flaming people on mailing lists as a way to get things done is not something people want to encourage in NMs... right? Right. After all, as we all know, no DD would ever do such a thing. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 10:19:46AM -0500, Daniel Jacobowitz wrote: I'm not saying that this all needs to be publicly logged. I don't give a rat's ass whether it is or not. But please don't stand there saying that the process is completely transparent. I don't believe I said that. I don't believe it's remotely fair to set the standard at the unreachable level of perfection, either. The major task of buildd maintenance (aiui) is handlings logs though, and that's certainly what was being complained about earlier. I'd be interested to see you name an area that's had anything like the transparency w-p provides the build process though. I guess there's britney, which gives public logs of what's going on, but also requires a degree of handholding every now and then that isn't particularly logged. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
On Fri, Dec 09, 2005 at 05:56:24PM +0100, Josselin Mouette wrote: Le vendredi 09 décembre 2005 à 23:49 +1000, Anthony Towns a écrit : How many more years are we going to waste time with this hysteria before realising it doesn't achieve anything but rapidly sucking the fun out of things? How many developer resignations will you need to understand inaction from people at key positions sucks the fun out of things in a worse way? Yeah, threatening resignations, that sure is fun! If the responsibility position isn't fun enough for the work to be done, the person holding that position should resign. It probably required some courage from you do resign from being release manager, and you deserve credits for doing it instead of letting things rot. Actually it required complete disinterest in the entire process; I made the decision when the Let's force in amd64 in spite of what anyone says GR got proposed. What required time, skill, planning and energy was the process of actually teaching other folks the skills they needed to help out; of the five volunteers only two worked out. At least by now I'm only amused that your best characterisation of my time as RM is letting things rot. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
On Fri, Dec 09, 2005 at 04:27:10PM +0100, Michael Banck wrote: On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote: 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. Where should I best complain for your NM application to be cancelled? You can direct concerns about candidates to [EMAIL PROTECTED], which will be taken into account when the AM's report is being evaluated. I presume it takes quite a few comments from different developers before those would override the AM's recommendation though. Positive comments can also be sent there (as an additional advocate round, I guess), and are AIUI particularly appreciated, since that gives more support to accepting a candidate, which is, after all, what almost always happens at that point. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
On Fri, Dec 09, 2005 at 05:48:13PM +0100, Josselin Mouette wrote: There is absolutely zero documentation on how the buildd network works. If the documentation's insufficient, ask politely for help. buildd.debian.org points you at wanna-build and its svn repo, which has some reasonably extensive READMEs as well as all the source. You know, the things you have to be aware of if you want to give a hand. $ lynx -dump http://bugs.debian.org/release-critical/other/all.html | grep FTBFS | wc 4174195 31201 I don't really understand the viewpoint that says fixing the problem isn't a response to pointing out a problem. It isn't a response, because a problem you report isn't really fixed until you've been warned it has been fixed. *shrug* Sure, there are better possible responses. At some point you have to accept that resolving your uncertanties isn't as important as other things people could be doing. If you actually want to get that better result, the way your going about advocating for it is *precisely* wrong. Sorry, but it's simply not possible. When you don't have the required credentials, you can't do anything with the buildd network. When you don't know personally its internals, which are not documented, you don't even know where to start. I don't believe it's that easy to dig into them. I've never run a buildd; I've never invoked sbuild; I don't think I have login access on any buildds, though I might be wrong. That hasn't stopped me getting access to the w-b groups on buildd.d.o (which was to enable britney to do better stats), and I even got to sign my first build log the other day to test the security stuff I've been working on. My strategy for this is to work around not having access, recognise other people have different priorities to me and that they're only going to do what I want when our priorities match, and be polite about it all. I think it says something when that strategy, which afaics has proven successful repeatedly, is dismissed as too hard. Then, will someone explain what happened to get things fixed? You seem to be fairly affirmative about this, so you probably know. There were some private conversations that, AIUI, it'd be unethical and possibly illegal for me to quote, and I doubt you'd accept any summary I might make. The DPL has the same information I do, though, as a response to his querying what was going on, and I believe his position is with a single elected DPL, there is still someplace for the buck to stop, as a U.S. idiom puts it., so maybe it's worth asking him. It could save a lot of time later, if people ask things correctly and to the right person instead of complaining and trolling in this mailing list. If you follow the advice above, you won't have any problems. Oh right, there is no problem with waiting for 2 months for a keyring update. An update for a key that was confiscated as part of a police raid months beforehand? I don't think there's a really major problem, no. Haven't you noticed that while there can be obnoxious persons, most people start to complain only when things become really unbearable? No, I haven't noticed that at all. Well, let me rephrase. I've noticed most people don't start to complain at all, whether things are bearable or not. Most of the complaints, meanwhile, are from people who'll complain no matter what (more or less), and don't give a damn whether their complaints are effective or not. Obviously, YMMV. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
Josselin Mouette [EMAIL PROTECTED] wrote: Le vendredi 09 décembre 2005 à 23:49 +1000, Anthony Towns a écrit : How many more years are we going to waste time with this hysteria before realising it doesn't achieve anything but rapidly sucking the fun out of things? How many developer resignations will you need to understand inaction from people at key positions sucks the fun out of things in a worse way? Reading these threads makes me want to resign. WILL YOU NOT THINK OF THE CHILDREN? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Thijs Kinkhorst [EMAIL PROTECTED] wrote: I'm not really convinced that such an approach would have a significant effect as long as you're not measuring existing DD's to the same standards. Which, as far as I can see, does not happen. A procedure is in place for developers to be ejected from the project. If you feel that anyone is behaving in a way that would not have allowed them to get through NM, then please do invoke it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Sat, Dec 10, 2005 at 11:46:50AM +1000, Anthony Towns wrote: On Fri, Dec 09, 2005 at 10:19:46AM -0500, Daniel Jacobowitz wrote: I'm not saying that this all needs to be publicly logged. I don't give a rat's ass whether it is or not. But please don't stand there saying that the process is completely transparent. I don't believe I said that. I don't believe it's remotely fair to set the standard at the unreachable level of perfection, either. You said that the logs tell you what the buildd admins are doing with the buildd. I disagree. The major task of buildd maintenance (aiui) is handlings logs though, and that's certainly what was being complained about earlier. I'd be interested to see you name an area that's had anything like the transparency w-p provides the build process though. I guess there's britney, which gives public logs of what's going on, but also requires a degree of handholding every now and then that isn't particularly logged. The majority of handling logs is monkeywork - very easy, mostly automated. The main jobs of the buildd admin are to (A) provide a human sanity check on what's getting built successfully; I am and always have been somewhat dubious of the value of this, even when I was doing it; and (B) doing something about the failures. What buildd.debian.org logs is the output of the sbuild runs. We have great visibility into what _sbuild_ is doing. But what the _buildd admin_ is doing is, by and large, taking care of the failures: whether that means dep-waiting them, filing bugs because of them, poking anything obscure that caused the buildd environment to get broken (e.g. when a package fails to uninstall, or a broken package fills the disk with logs). This stuff doesn't get logged, nor would it be particularly easy to log. The current buildd admins don't seem to be very responsive about filing bugs for the failures; they tend to sit for rather a long time unless porters, or package maintainers, go out and stare at the logs on their own. But my sample size for this last bit is small, so take it with a grain of salt. I don't think that the human step of signing the successful logs has any value nowadays. The closest a human can go to checking the volume of mail a buildd produces is running it through some clever procmail filters, anyway. Or reading through any logs that strike them as particularly interesting. I don't have handy stats about the volume of mail produced by the buildd anymore, but voltaire's currently pumping out about eighty thousand lines a day over the last week and a half, if I'm looking at the right logs. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote: 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. It tells you what the buildd admins are doing with the buildds. No. It tells us some of what they are doing. It does not tell us everything; sometimes there are problems which are hard to diagnose without more specific information. It doesn't tell you why they're doing that, of course, but if that's what you want to know you're better off creating an environment where folks are interested in talking to you. I see. Can we please post a list of the Debian developers who have blacklists like this, and exclude them from single-point-of-failure jobs? Is it ok for me to decide to ignore bug reports from people, merely on the grounds that I am not interested in talking to someone? No, because I've no idea what your request was or what its importance was compared to other pressing issues. It was poisted on debian-release. If there was a page tracking such issues that I could follow -- like the one Jeroen set up for tracking and diagnosing removals needed from the archive prior to his inclusion in the ftpteam -- I might be able to do so, but I understand you're dismissive of that approach. No, not in the least. That's a good start, but for it to be an excellent start, it needs to work like the BTS, and be something that the relevant volunteers themselves read and pay attention to. Not at all. Indeed, that's happened in the past -- Joey and James tried to close new-maintainer in July 1999 insisting they needed help, and n-m continued in a crap state until October when James quit from new-maintainer outright. It nevertheless took until April 2000 before new maintainers began being accepted. And new-maintainer's not without it's continuing problems even after that process. I don't think that's a model that bears repeating, personally. You're welcome to your own opinion of course. I'm not sure I understand. Joey and James tried to *close*, which is not at all the same thing. Indeed, my recollection was that they resisted any actual help, they insisted that their role was absolutely essential, and both refused to process applications and refused to let anyone else take over the work. Finally James stopped, and things began to slowly improve. 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. Perhaps you should talk to Nathaniel, who seems to think public criticism is effective in today's Debian, and work out some consensus reality. No, I don't think it's effective. I think it's counter-productive. But that does *not* mean that it's not *equally* counter-productive to maintain blacklists, ignore email, refuse to post status reports or discuss issues, and the like. Indeed, I think those things are ever more counter-productive. Moreover, if those things are done, the public criticism tends to get massively reduced pretty quickly, because if it's misplaced, everyone can clearly see. An excellent example of this is the publication of the NEW queue. Now that everyone can see the NEW queue, I don't see any of the big public criticism about slow processing. This is an infantile and counterproductive attempt to maintain control and a sense of superiority. I don't believe this is the case. If you believe you know the people involved better than I do, and your judgement is thus better informed, you are, again, welcome to it. Actually, we don't know who the people are at all. One cannot even find out the *names* of the people doing this work. (BTW, I see #335981 and #336371 haven't received a response since late October; or has raptor been down that entire time, so that you haven't been able to diagnose it further -- it certainly seems down now?) Upstream is working on #335981 and #336371. In fact, scm has *never* supported s390; when I took over maintenance of the package I opened the bugs so that it could be more effectively tracked. And since I am the one who opened #335981, I don't really think a reply to myself is all that necessary. #336371 was opened as a result of a normal build failure, by someone who performs the useful task of opening FTBFS bugs when appropriate; a personal reply does not seem necessary. Certainly if I received a question about the bugs, I would reply as soon as practicable. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: The major task of buildd maintenance (aiui) is handlings logs though, and that's certainly what was being complained about earlier. No. What I was complaining about was totally ignoring of requeue requests sent to the @buildd.debian.org advertised addresses. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Russ Allbery [EMAIL PROTECTED] writes: Ingo Juergensmann [EMAIL PROTECTED] writes: Please stop assuming wrong facts. As I already stated several times before: Ryan was offered to integrate the buildd.net software. He declined with the argument that all information is already available on buildd.d.o. That's a clear sign that he doesn't want to integrate it. Blame him, not me. And where is the source for buildd.debian.org? If you want to replace an existing infrastructure, you have to clearly demonstrate that the new stuff is better. Saying that it's okay that the new stuff isn't publically available because the old stuff isn't either doesn't help the cause any. Also, it's somewhat ironic that, in a thread where much has been made of how overloaded the existing buildd administrators are, the offer of the buildd software was made privately to one of those overloaded individuals. (And were they then allowed to make it public?) He is the only contact address mentioned. Who else should get an offer? C'mon, this is a free software project. The obvious first step for providing better infrastructure would be to make that infrastructure publically available for anyone to download, play with, hack on, or otherwise evaluate, whether the existing infrastructure component is similarly available or not. I'd think this would just be common sense. You can test and play around with buildd.net all you want and easily see its superiority. You can also contact Ingo and ask him for the scripts, as I have done, and you may recieve them. Something that I found impossible for buildd.d.o. Ingo is offering a service and paying for it. That he isn't throwing the source at anyone casualy stumbling accross his site should hinder anyone intrested. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: On Fri, Dec 09, 2005 at 10:19:46AM -0500, Daniel Jacobowitz wrote: I'm not saying that this all needs to be publicly logged. I don't give a rat's ass whether it is or not. But please don't stand there saying that the process is completely transparent. I don't believe I said that. I don't believe it's remotely fair to set the standard at the unreachable level of perfection, either. The major task of buildd maintenance (aiui) is handlings logs though, and that's certainly what was being complained about earlier. I'd be interested to see you name an area that's had anything like the transparency w-p provides the build process though. I guess there's britney, which gives public logs of what's going on, but also requires a degree of handholding every now and then that isn't particularly logged. Cheers, aj Which in no way provides any transparency to arch@buildd.d.o, which was being complained about earlier. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Goswin von Brederlow [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: C'mon, this is a free software project. The obvious first step for providing better infrastructure would be to make that infrastructure publically available for anyone to download, play with, hack on, or otherwise evaluate, whether the existing infrastructure component is similarly available or not. I'd think this would just be common sense. You can test and play around with buildd.net all you want and easily see its superiority. You can also contact Ingo and ask him for the scripts, as I have done, and you may recieve them. Something that I found impossible for buildd.d.o. Ingo is offering a service and paying for it. That he isn't throwing the source at anyone casualy stumbling accross his site should hinder anyone intrested. I wholeheartedly approve of the decision to decline to use the software of people with this attitude towards free software as part of the core Debian infrastructure. It's one thing to have the source diverge due to lack of time, but the above rings TONS of MAJOR warning bells for me. It sounds very much like the sort of conversation that I get into with vendors who are trying to say they do open source without actually doing anything of the sort. Much of what we do here is *exactly* about throwing the source at anyone casually stumbling across our site. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 07:24:00PM -0800, Thomas Bushnell BSG wrote: An excellent example of this is the publication of the NEW queue. Now that everyone can see the NEW queue, I don't see any of the big public criticism about slow processing. Well, that's not very interesting, because the processing isn't slow anymore which could well be the cause. Fortunately we can differentiate those two explanations, because there was a time when the NEW queue was visible and processing remained slow, between 17th Feb 2005 [0] and 18th March 2005 [1] or so. If transparency were the fix, then there shouldn't've been any big public criticism about slow processing in that time. Unfortunately for that theory, there was, see [2]. Really, that theory was screwed from the beginning, since that information has *always* been available, although not in as nice a form as it currently is. That sort of information is helpful to tell you when there is a problem, but that's only the first step. ATM, the corresponding thing would be to (gosh!) setup a webpage tracking whatever issue you don't think is receiving enough attention, so people can see if it is actually a problem. The way to then go about solving it is *politely* working *with* the people who're currently involved. Okay, I guess I've made that point enough for this round. See y'all again next month! What are we up for next anyway? N-M? Cheers, aj [0] http://lists.debian.org/debian-devel/2005/02/msg00795.html [1] http://lists.debian.org/debian-project/2005/03/msg00142.html [2] http://lists.debian.org/debian-devel/2005/03/msg00291.html signature.asc Description: Digital signature
Re: buildd administration
On Fri, Dec 09, 2005 at 07:25:14PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: The major task of buildd maintenance (aiui) is handlings logs though, and that's certainly what was being complained about earlier. No. What I was complaining about was totally ignoring of requeue requests sent to the @buildd.debian.org advertised addresses. Requeue requests are part of handling logs... You get a failed log, you analyse it to say oh, that's a transient error due to other things then you requeue it... If that analysis comes from reading a mail, great. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
On Fri, Dec 09, 2005 at 10:11:12PM -0500, Daniel Jacobowitz wrote: The majority of handling logs is monkeywork - very easy, mostly automated. The main jobs of the buildd admin are to The job of the buildd admin is to make sure packages are built. Mostly that's automated, which is great, which means the buildd admin's job is mostly to keep the automation working. (A) provide a human sanity check on what's getting built successfully; I am and always have been somewhat dubious of the value of this, even when I was doing it; and (B) doing something about the failures. By and large its the porters that need to do something about failures; which is to say, working out the problem and uploading a fix. The buildds job wrt failures is to make sure they're not caused by brokenness in the build setup, which is one place the human sanity check comes in. Likewise when the RMs are trying to coordinate transitions, and packages need to not be autobuild on old libraries, or need to be mass-binNMUed. What buildd.debian.org logs is the output of the sbuild runs. We have great visibility into what _sbuild_ is doing. But what the _buildd admin_ is doing is, by and large, taking care of the failures: I don't think that's a valid way of splitting things up. The job is to build packages; if that's being done mostly well, that's great. If the other bits could be done better, well, fine. The current buildd admins don't seem to be very responsive about filing bugs for the failures; That's been the case for quite a while now from what I've seen; but OTOH, there are plenty of FTBFS bugs that just don't get attention anyway. It's also something competent porters can take over fairly trivially -- simply by looking through the buildd.d.o logs and analysing the failures that they can reproduce themselves. I don't think that the human step of signing the successful logs has any value nowadays. The value it has is that the key doesn't get put on a machine that's running random scripts day-in/day-out. Delaying signing 'til the end of the day gives you some chance to learn of problems that might apply to successful builds too. Someone with a particular interest might like to analyse this, but I don't think signing successful logs is much of a problem. I don't have handy stats about the volume of mail produced by the buildd anymore, but voltaire's currently pumping out about eighty thousand lines a day over the last week and a half, if I'm looking at the right logs. The number of lines isn't terribly interesting; you don't read build logs like a book, you grep through them like an encyclopaedia at most. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
The job of the buildd admin is to make sure packages are built. Mostly that's automated, which is great, which means the buildd admin's job is mostly to keep the automation working. Dan was a really good buildd admin. Maybe he knows what he's talking about. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 07:24:00PM -0800, Thomas Bushnell BSG wrote: No, not in the least. That's a good start, but for it to be an excellent start, it needs to work like the BTS, and be something that the relevant volunteers themselves read and pay attention to. It doesn't actually need anyone else to pay attention to it; it just needs to exist so people *can* pay attention to it. I'm not sure I understand. Joey and James tried to *close*, which is not at all the same thing. Indeed, my recollection was that they resisted any actual help, they insisted that their role was absolutely essential, and both refused to process applications and refused to let anyone else take over the work. Finally James stopped, and things began to slowly improve. Your recollection's mistaken. It's in the -private archives though, so you can correct if if you like. Trivially though, you can note simply from public information that things only actually improved -- in that people got processed again -- when James *started* again, which is the exact opposite of your mischaracterisation above. This is an infantile and counterproductive attempt to maintain control and a sense of superiority. I don't believe this is the case. If you believe you know the people involved better than I do, and your judgement is thus better informed, you are, again, welcome to it. Actually, we don't know who the people are at all. One cannot even find out the *names* of the people doing this work. Sure you can -- at the very least you just need to check the signatures of autobuilt packages. If you're too lazy to do that (and hey, who isn't?) you can check the qualification pages on the wiki, which has most of that information too. (BTW, I see #335981 and #336371 haven't received a response since late October; or has raptor been down that entire time, so that you haven't been able to diagnose it further -- it certainly seems down now?) Upstream is working on #335981 and #336371. In fact, scm has *never* supported s390; scm |5d9-4.1 | unstable | s390 when I took over maintenance of the package I opened the bugs so that it could be more effectively tracked. RC bugs need to be *fixed*, not merely tracked. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: On Fri, Dec 09, 2005 at 07:25:14PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: The major task of buildd maintenance (aiui) is handlings logs though, and that's certainly what was being complained about earlier. No. What I was complaining about was totally ignoring of requeue requests sent to the @buildd.debian.org advertised addresses. Requeue requests are part of handling logs... You get a failed log, you analyse it to say oh, that's a transient error due to other things then you requeue it... If that analysis comes from reading a mail, great. So why was the request ignored for a month? Why did my email result in no action, twice, not even a response? Perhaps you don't know the answer to these questions. But then how can you so surely assert that there is no problem? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: The job of the buildd admin is to make sure packages are built. Mostly that's automated, which is great, which means the buildd admin's job is mostly to keep the automation working. So when the build admin is not doing that job, what should we do? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: Upstream is working on #335981 and #336371. In fact, scm has *never* supported s390; scm |5d9-4.1 | unstable | s390 And yet, it didn't actually run successfully on s390. Support is not just a matter of compiling. when I took over maintenance of the package I opened the bugs so that it could be more effectively tracked. RC bugs need to be *fixed*, not merely tracked. Yes, and I'm working with upstream. Supporting scheme on these architectures is very tricky, because it needs to copy the stack and do all kinds of cleverness, and Aubrey didn't have the hardware to do it. It cannot be done through generic code. My involvement has been to work on the porting itself, and more importantly, to hook Aubrey up with the Debian porters in the hope of working on the problems and improving support. Worst case, I'll have to decide that s390 should be removed from the supported list, but I'm not giving up yet. Before you scold me further about the ONE release-critical bug in packages I maintain, shall we start examining yours? Moreover, please notice how despite a hostile and uncomprehending question, I have answered your question as fully and completely as I can. I did not say, Anthony is being a jerk, so I will ignore him. I did not say, From now on, I'll ignore Anthony. Now, you'll be happy to do the same, right? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 09:40:11PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: Requeue requests are part of handling logs... You get a failed log, you analyse it to say oh, that's a transient error due to other things then you requeue it... If that analysis comes from reading a mail, great. So why was the request ignored for a month? Why did my email result in no action, twice, not even a response? I've told you what I'd need to answer that question already. Perhaps you don't know the answer to these questions. But then how can you so surely assert that there is no problem? Easy: the best tools we've got to judge whether buildds are keeping up are the buildd graphs which indicate that with the exception of m68k and arm (hrm, and possibly hppa), all our ports are doing extremely well. Although I guess that's different from saying there's no problem if you're being pedantically literal. I have no interest in that sort of discussion though. *shrug* Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
On Fri, Dec 09, 2005 at 09:44:59PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: Upstream is working on #335981 and #336371. In fact, scm has *never* supported s390; scm |5d9-4.1 | unstable | s390 And yet, it didn't actually run successfully on s390. Support is not just a matter of compiling. Support's a matter of many things. One of those is ensuring you don't have RC bugs. If a package is failing to build or to function on some architecture, your job as that package's maintainer is see if it can be fixed (talking to porters and/or upstream if it's beyond your skills), and if it can't be fixed trivially, to note that it's not currently supported on that architecture by both ensuring that non-working packages fail to build (by editing the Architecture: line or adding appropriate test suites), and passing that information on to others. In this case that means not having a control file that explicitly declares s390 is a supported architecture, and filing a bug against ftp.debian.org indicating that the s390 build is broken and should be removed. That then warrants downgrading the s390 FTBFS bugs to important or wishlist. As far as transparency goes; I'll note you didn't add anything to either bug report indicating you're working with upstream. It's the silence and the uncertainty over whether anything's actually being done to fix anything that's the real issue, you know? when I took over maintenance of the package I opened the bugs so that it could be more effectively tracked. RC bugs need to be *fixed*, not merely tracked. Yes, and I'm working with upstream. RC bugs need to be fixed as a matter of *urgency*, not over a matter of months. Before you scold me further about the ONE release-critical bug in packages I maintain, shall we start examining yours? I don't believe I have any open RC bugs, or any open FTBFS bugs, so I don't see the relevance. But hey, if it'll make you feel better to convince yourself that it's everyone else's fault and there's nothing you can do, go ahead. Moreover, please notice how despite a hostile and uncomprehending question, It's amazing how it's always hostile and uncomprehending when it's you that's being questioned, yet when you're doing the questioning they tend consistently towards concerned and incisive. Given your apparent discomfort with that question, perhaps you'd care to consider how much more hostile and uncomprehending it might seem if instead of making the question as part of a conversation between us, I'd instead posted to d-d-a about it, or simply raised it as a general conversation piece about how people in your position should be reviewed for replacement as a matter of urgency. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: So why was the request ignored for a month? Why did my email result in no action, twice, not even a response? I've told you what I'd need to answer that question already. Perhaps you don't know the answer to these questions. But then how can you so surely assert that there is no problem? Easy: the best tools we've got to judge whether buildds are keeping up are the buildd graphs which indicate that with the exception of m68k and arm (hrm, and possibly hppa), all our ports are doing extremely well. This is the only metric? How about long delays on particular packages? The average amount built is not the only consideration. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel notebooks for needy developers in developing countries
Yeah that would be a real pain to exlude countries because of stupid political 'correctness'. All in all in Free Software movement we don't know what the borders are, do we? We (Debian developers and contributors) certainly all agree on this (or, at least, the vast majority of us). However, the donator here is a US company which may be restricted by the laws of the United States of America. Whether we like them or not is not really relevant. If Intel cannot donate a computer to a Cuban citizen, there's not much we can do about it, except by asking the same donation to a company that wouldn't be restricted to these exportation laws (such as a Japanese company, maybe...which I'm not even sure of). This certainly does not prevent Andreas to record the name of a Cuban citizen in his list and propose it to Intel which is what I would recommend doing if a Cuban citizen really qualifies for the donation. But we should wait until we know there is *really* someone qualifying for the donation in Cuba, before turning this into a rhetorical case, no? (removing CC to Andreas who certainly reads this list) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au writes: On Fri, Dec 09, 2005 at 09:44:59PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: Upstream is working on #335981 and #336371. In fact, scm has *never* supported s390; scm |5d9-4.1 | unstable | s390 And yet, it didn't actually run successfully on s390. Support is not just a matter of compiling. Support's a matter of many things. One of those is ensuring you don't have RC bugs. What I said was that scm has never supported s390, but it is intended to. In my current judgment, it is not ready for testing until it does support s390. That judgment may change. I was using the word support to refer to a package supporting an arch. Now you are referring to a very different usage of support; that is, a developer supporting a package. For a package which is not part of debian stable or testing, it seems to me that support amounts to actually working on getting it ready for testing and ultimately stable. If a package is failing to build or to function on some architecture, your job as that package's maintainer is see if it can be fixed (talking to porters and/or upstream if it's beyond your skills), and if it can't be fixed trivially, to note that it's not currently supported on that architecture by both ensuring that non-working packages fail to build (by editing the Architecture: line or adding appropriate test suites), and passing that information on to others. This is in fact exactly what is happening. In this case that means not having a control file that explicitly declares s390 is a supported architecture, and filing a bug against ftp.debian.org indicating that the s390 build is broken and should be removed. That then warrants downgrading the s390 FTBFS bugs to important or wishlist. Yes, because actually *making it work* on the architecture is unimportant. Well, as the maintainer, I disagree. As far as transparency goes; I'll note you didn't add anything to either bug report indicating you're working with upstream. It's the silence and the uncertainty over whether anything's actually being done to fix anything that's the real issue, you know? I'm sorry, were there people who were worried about this? Were you wishing that scm worked on your s390 box? I am happy to answer queries, but I have received none. In addition, I would point out that your method of supporting the package amounts to documenting its inadequacy and then doing nothing. My method (described below) is much more focused on actually furthering development and the usefulness of the package. RC bugs need to be fixed as a matter of *urgency*, not over a matter of months. The package in question is not in testing, and was not released in sarge. The RC bug does not affect any users at all. It holds the package out of testing, which I think is currently appropriate. Is there some *problem* here? Or are you concerned about a bookkeeping issue? What is the particular urgency with which you are concerned? How would it help things if I did as you suggest, and then opened a new RC bug indicating my judgment that the package is not yet ready for stable? What seems patently clear is that you chose to make this the place upon which to take your stand and criticize me, without having done the basic research to find out these facts. Still, you having chosen to do this, my responsiblity as a developer certainly includes that I should answer your emails as fully and completely as I can. Are you willing to commit to do the same, and expect the same of the developers you are so busy defending? I don't believe I have any open RC bugs, or any open FTBFS bugs, so I don't see the relevance. But hey, if it'll make you feel better to convince yourself that it's everyone else's fault and there's nothing you can do, go ahead. Where did I blame anyone? I am addressing the bug in question. (Actually, you have six open RC bugs, because you maintain packages by ignoring them and relying on others to fix your bugs for you, and then not acknowleding the NMUs. I fail to see how this is better.) Nor did I say there is nothing I can do. Instead, what I did was: 1) Adopt the package, since I saw it was having trouble and the previous maintainer did not seem able to give it the attention it needed. 2) Work with upstream to figure out what archs really worked and what didn't. 3) Start addressing the missing archs by helping to get upstream in contact with experts on those archs, and making sure he had access to suitable hardware. 4) Lend some expertise as time was available to help with the actual porting task. 5) Arrange to have the BTS correctly document the state of the package. 6) Answer even unfriendly questions from a fellow developer who doesn't even care about the particular issue. Moreover, please notice how despite a hostile and uncomprehending question, It's amazing how it's
Re: buildd administration
On Fri, Dec 09, 2005 at 10:37:08PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: Easy: the best tools we've got to judge whether buildds are keeping up are the buildd graphs which indicate that with the exception of m68k and arm (hrm, and possibly hppa), all our ports are doing extremely well. This is the only metric? How about long delays on particular packages? The average amount built is not the only consideration. No, not the only, the best. It is mostly the responsibility of the maintainer to resolve package specific issues though; which usually amount to three things: FTBFS bugs, problems with toolchains and build-depends that only affect one package or a few, and problems with P-a-s not being accurate. Toolchain issues usually, which seem to be your concern, take some time to resolve, and are often fixed by mass give-backs once related issues have worked their way through the build system. Sometimes the related problems take a while to resolve, of course. FTBFS issues are the most common though, as well as the easiest to resolve; your point would carry more weight if you took the time to fix yours first. (Looking through -private, I saw someone remark that 1000 bugs was too many -- we have got 1400 _RC_ bugs at the moment...) (Also, those graphs do not indicate the average amount by any measure, so your characterisation is again completely wrong. Please take more care) Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
On Fri, Dec 09, 2005 at 10:54:59PM -0800, Thomas Bushnell BSG wrote: In addition, I would point out that your method of supporting the package amounts to documenting its inadequacy and then doing nothing. No, the issue is one of resolving RC issues: in this case by: (a) seeing if the FTBFS can be fixed immediately, and finding it can't (b) documenting (this is the transparent bit, so pay attention) that fact by not having s390 incorrectly listed as a supported arch in the source and ensuring it does not incorrectly indicate a known broken build is successful as it did in the past (c) informing ftpmaster that the build currently in the archive is broken by filing a bug requesting the broken build be removed (you know, communicating with people) (d) downgrading the bug so that it is not incorrectly listed as a RC issue that the RM and QA teams have to attend to (e) as maintainer, work with upstream and porters to fix the downgraded but still open bug we were just talking about I'm sorry that you think important bugs equate to doing nothing. But either way, this is the way things are done, it's not something you get to disagree with. Since this point obviously needs to be made clearer, I guess it's time to have some more rounds of removing packages that have long outstanding RC bugs. I guess I'll coordinate with the RM team to do this sometime over Christmas/New Year. (Actually, you have six open RC bugs, because you maintain packages by ignoring them and relying on others to fix your bugs for you, and then not acknowleding the NMUs. I fail to see how this is better.) There is nothing wrong with NMUs. Honestly, if you fail to see how a bug fixed in an NMU is better than an open RC bug and a package in the archive that doesn't work at all, I don't understand how you passed n-m. 6) Answer even unfriendly questions from a fellow developer who doesn't even care about the particular issue. Ah, unfriendly, doesn't even care. There we go. As it happens I do care about that bug, as it's an RC issue that stops people from using the package and makes both quality assurance and the release process harder. Given your apparent discomfort with that question, perhaps you'd care to consider how much more hostile and uncomprehending it might seem if instead of making the question as part of a conversation between us, I'd instead posted to d-d-a about it, or simply raised it as a general conversation piece about how people in your position should be reviewed for replacement as a matter of urgency. If someone believes that they would do a better job maintaining scm, I'm entirely happy to hand over maintenance of it. Are you volunteering? Somehow I didn't think you'd care to consider it. Cheers, aj signature.asc Description: Digital signature
Re: buildd administration
In article [EMAIL PROTECTED] you wrote: If a package is failing to build or to function on some architecture, your job as that package's maintainer is see if it can be fixed (talking to porters and/or upstream if it's beyond your skills) BTW: is there a way to get build failures by mail? especially from the architectures which are not visible on buildd.debian.org/PTS like hurd and bsd. Took me two days to find a build failure, and I guess it would have taken weeks before i would get a FTBFS bug report (asuming those are manual). Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted qpsmtpd 0.31.1-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 00:00:12 -0800 Source: qpsmtpd Binary: qpsmtpd Architecture: source all Version: 0.31.1-3 Distribution: unstable Urgency: low Maintainer: Devin Carraway [EMAIL PROTECTED] Changed-By: Devin Carraway [EMAIL PROTECTED] Description: qpsmtpd- Flexible SMTP daemon for network-level spam detection Closes: 342336 Changes: qpsmtpd (0.31.1-3) unstable; urgency=low . * add patch: forkserver-early-privdrop: drop root privileges early, so logs get created with correct ownership (Closes: #342336) * Correct permissions bug on affected systems by chowning to run-as user if logfile is owned by root at startup * Run package config under /bin/bash for now, not /bin/sh Files: c6c9bc0799184a3f2d800475c830c5d7 585 mail extra qpsmtpd_0.31.1-3.dsc 6c940f5ad4c2a37166faffb161eb5c1a 28292 mail extra qpsmtpd_0.31.1-3.diff.gz 8faf5b4e9028a4c9611cf5ed9a99c9a1 137290 mail extra qpsmtpd_0.31.1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmTm/U5XKDemr/NIRAkQlAJ96h6Np1FulK1NFa61m0hi6d/yrlQCfSHDr je83tVLwMwoUa2/4ynqUD4w= =B2a4 -END PGP SIGNATURE- Accepted: qpsmtpd_0.31.1-3.diff.gz to pool/main/q/qpsmtpd/qpsmtpd_0.31.1-3.diff.gz qpsmtpd_0.31.1-3.dsc to pool/main/q/qpsmtpd/qpsmtpd_0.31.1-3.dsc qpsmtpd_0.31.1-3_all.deb to pool/main/q/qpsmtpd/qpsmtpd_0.31.1-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ocaml 3.09.0-2 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 10:19:39 +0100 Source: ocaml Binary: ocaml-compiler-libs ocaml-native-compilers ocaml-base ocaml-nox ocaml-mode ocaml-interp ocaml-source ocaml-base-nox ocaml Architecture: source i386 all Version: 3.09.0-2 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers debian-ocaml-maint@lists.debian.org Changed-By: Julien Cristau [EMAIL PROTECTED] Description: ocaml - ML language implementation with a class-based object system ocaml-base - Runtime system for ocaml bytecode executables ocaml-base-nox - Runtime system for ocaml bytecode executables ocaml-compiler-libs - Ocaml interpreter and standard libraries ocaml-interp - Ocaml interpreter and standard libraries ocaml-mode - A major mode for editing Objective Caml in Emacs ocaml-native-compilers - Native code compilers of the ocaml suite (the .opt ones) ocaml-nox - ML language implementation with a class-based object system ocaml-source - Sources for Objective Caml Closes: 216886 338437 Changes: ocaml (3.09.0-2) unstable; urgency=low . * Modified debian/rules to exit with an error when native compiler build fails, instead of building a broken package. * New patch kbsd-gnu.dpatch to add support for GNU/Hurd and GNU/k*BSD on i386 (thanks to Robert Millan and Aurélien Jarno; Closes: #216886). * Add myself to Uploaders (acked by Sven). * Add patch by Steve Langasek [EMAIL PROTECTED] to fix native code linking by passing the --no-relax option to ld (Closes: #338437). Bug#335578 stays open since a proper fix to the generated asm would still be better than this workaround. Files: d60dd6cfb10133068c8df90d28e902ce 915 devel optional ocaml_3.09.0-2.dsc 2f064fdc050ae13d4539925e9e7f 58818 devel optional ocaml_3.09.0-2.diff.gz b3dfc9c0800f94a60acf13db8b84b324 93992 devel optional ocaml-mode_3.09.0-2_all.deb dfb6d7482d1ba00d1c3d0f5b40604e74 6143030 devel optional ocaml-nox_3.09.0-2_i386.deb 9441c777bb11568899a7d70b8be0c6e2 2637736 devel optional ocaml-native-compilers_3.09.0-2_i386.deb 0203b7a4abae1af46b7f367b41c5fe2e 1796220 devel optional ocaml_3.09.0-2_i386.deb d10fb93fdb5bdb3159e577da0265fe84 254570 devel optional ocaml-base-nox_3.09.0-2_i386.deb a00682f8f3509e7aa0735efa1a6bbfed 65684 devel optional ocaml-base_3.09.0-2_i386.deb 797eef0b0195aa247b457d9b578af4b2 2051890 devel optional ocaml-source_3.09.0-2_all.deb 5cb70a0bec2199f2d2cf946347360b41 1008386 devel optional ocaml-interp_3.09.0-2_i386.deb 416e9fc62f16976353eacfc04d28db7b 764872 devel optional ocaml-compiler-libs_3.09.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmNOt1cqbBPLEI7wRAmI7AJ44EMWQfT20npXHDs1VWbX1tS72CgCfYpFR r/ueb6vpJxVsIMoft/UVPzA= =uozo -END PGP SIGNATURE- Accepted: ocaml-base-nox_3.09.0-2_i386.deb to pool/main/o/ocaml/ocaml-base-nox_3.09.0-2_i386.deb ocaml-base_3.09.0-2_i386.deb to pool/main/o/ocaml/ocaml-base_3.09.0-2_i386.deb ocaml-compiler-libs_3.09.0-2_i386.deb to pool/main/o/ocaml/ocaml-compiler-libs_3.09.0-2_i386.deb ocaml-interp_3.09.0-2_i386.deb to pool/main/o/ocaml/ocaml-interp_3.09.0-2_i386.deb ocaml-mode_3.09.0-2_all.deb to pool/main/o/ocaml/ocaml-mode_3.09.0-2_all.deb ocaml-native-compilers_3.09.0-2_i386.deb to pool/main/o/ocaml/ocaml-native-compilers_3.09.0-2_i386.deb ocaml-nox_3.09.0-2_i386.deb to pool/main/o/ocaml/ocaml-nox_3.09.0-2_i386.deb ocaml-source_3.09.0-2_all.deb to pool/main/o/ocaml/ocaml-source_3.09.0-2_all.deb ocaml_3.09.0-2.diff.gz to pool/main/o/ocaml/ocaml_3.09.0-2.diff.gz ocaml_3.09.0-2.dsc to pool/main/o/ocaml/ocaml_3.09.0-2.dsc ocaml_3.09.0-2_i386.deb to pool/main/o/ocaml/ocaml_3.09.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nsd 2.3.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 09:45:19 +0100 Source: nsd Binary: nsd Architecture: source i386 Version: 2.3.3-1 Distribution: unstable Urgency: low Maintainer: OndÅej Surý [EMAIL PROTECTED] Changed-By: OndÅej Surý [EMAIL PROTECTED] Description: nsd- authoritative name domain server Changes: nsd (2.3.3-1) unstable; urgency=low . * New upstream release. * Pass pidfile to nsd to allow chrooting. * Prepare config files to allow easier chrooting. * Move uid of nsd setuid user to nsd_user and add it to flags automatically. Files: b9ec52aaff57faad76f759ea7c1120e8 611 net optional nsd_2.3.3-1.dsc 7e9f0ebfdf9dd29213170999cd60c20e 236488 net optional nsd_2.3.3.orig.tar.gz ee5233e63cbada1084e1e76b4f56a031 7513 net optional nsd_2.3.3-1.diff.gz d5cc728078c45fccfcaee25ce69e48ac 149862 net optional nsd_2.3.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDmUeU9OZqfMIN8nMRAmtpAJoCt/3J0eP+CXONNeuff0MYPopwPACfY7FW NEYyIyq7Zp5cOlqAAXzKDIo= =4K4r -END PGP SIGNATURE- Accepted: nsd_2.3.3-1.diff.gz to pool/main/n/nsd/nsd_2.3.3-1.diff.gz nsd_2.3.3-1.dsc to pool/main/n/nsd/nsd_2.3.3-1.dsc nsd_2.3.3-1_i386.deb to pool/main/n/nsd/nsd_2.3.3-1_i386.deb nsd_2.3.3.orig.tar.gz to pool/main/n/nsd/nsd_2.3.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dictd 1.10.2-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 03:33:25 -0500 Source: dictd Binary: dictfmt dictd dictzip dict Architecture: source i386 Version: 1.10.2-3 Distribution: unstable Urgency: low Maintainer: Kirk Hilliard [EMAIL PROTECTED] Changed-By: Kirk Hilliard [EMAIL PROTECTED] Description: dict - Dictionary Client dictd - Dictionary Server dictfmt- Utility to format a file for use by the dictd server dictzip- Compression utility for dictionary databases Changes: dictd (1.10.2-3) unstable; urgency=low . * Changed umask to 022 to avoid other writable pid files. Files: bb639aa940eca512a261b282c344e752 663 text optional dictd_1.10.2-3.dsc bc8056d818ff542fef9f8a79a7bfa656 46352 text optional dictd_1.10.2-3.diff.gz ae4def132de682028fe1f71bd4f77129 132018 text optional dictd_1.10.2-3_i386.deb 674d03f0b28d9b9c5b03235157ac21ce 72750 text optional dict_1.10.2-3_i386.deb 1cd49bb4bf400177b5e0fe584c1a3295 56694 text optional dictzip_1.10.2-3_i386.deb 0428d498546333480ac87ed5cde4288e 65658 utils optional dictfmt_1.10.2-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDmUSqMoV8KThaPsERApQJAKCypIeWtt/6gJhCFDvnvMQdGShVkgCg1UwN Rb77DYDCyHCzZerC0sV5RZk= =1Qcb -END PGP SIGNATURE- Accepted: dict_1.10.2-3_i386.deb to pool/main/d/dictd/dict_1.10.2-3_i386.deb dictd_1.10.2-3.diff.gz to pool/main/d/dictd/dictd_1.10.2-3.diff.gz dictd_1.10.2-3.dsc to pool/main/d/dictd/dictd_1.10.2-3.dsc dictd_1.10.2-3_i386.deb to pool/main/d/dictd/dictd_1.10.2-3_i386.deb dictfmt_1.10.2-3_i386.deb to pool/main/d/dictd/dictfmt_1.10.2-3_i386.deb dictzip_1.10.2-3_i386.deb to pool/main/d/dictd/dictzip_1.10.2-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sword 1.5.8-7 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 8 Dec 2005 10:42:17 + Source: sword Binary: libsword-dev libsword5c2a diatheke Architecture: source i386 Version: 1.5.8-7 Distribution: unstable Urgency: medium Maintainer: Daniel Glassey [EMAIL PROTECTED] Changed-By: Daniel Glassey [EMAIL PROTECTED] Description: diatheke - CGI script for making bible website libsword-dev - Development files for libsword libsword5c2a - API/library for bible software Closes: 339269 Changes: sword (1.5.8-7) unstable; urgency=medium . * ackknowledge NMU, thanks, Closes: #339269 * don't autogenerate debian/control using cdbs * use gnutls version of curl since sword is GPLd Files: a383113cec50f8b813de88ee50d10e11 749 libs optional sword_1.5.8-7.dsc 7026fd1dfa72bcbb819b63fe7623a6ef 8489 libs optional sword_1.5.8-7.diff.gz 2ac3a44c677efbfbf9f859556ab28759 457680 libs optional libsword5c2a_1.5.8-7_i386.deb 4348ff4a23b537139930f4cf545a8150 623570 libdevel optional libsword-dev_1.5.8-7_i386.deb 975421579dc2fc80846d7c4a57d418d2 58248 web optional diatheke_1.5.8-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmVIV/offrSwPzRoRArphAJ9VuLUVyiOTyT/Qe2KAlyklN2yaRQCg9yuL H5niy08AK7/hIPLEqQRxx08= =ktdH -END PGP SIGNATURE- Accepted: diatheke_1.5.8-7_i386.deb to pool/main/s/sword/diatheke_1.5.8-7_i386.deb libsword-dev_1.5.8-7_i386.deb to pool/main/s/sword/libsword-dev_1.5.8-7_i386.deb libsword5c2a_1.5.8-7_i386.deb to pool/main/s/sword/libsword5c2a_1.5.8-7_i386.deb sword_1.5.8-7.diff.gz to pool/main/s/sword/sword_1.5.8-7.diff.gz sword_1.5.8-7.dsc to pool/main/s/sword/sword_1.5.8-7.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ocaml 3.09.0-3 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 11:01:06 +0100 Source: ocaml Binary: ocaml-compiler-libs ocaml-native-compilers ocaml-base ocaml-nox ocaml-mode ocaml-interp ocaml-source ocaml-base-nox ocaml Architecture: source i386 all Version: 3.09.0-3 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers debian-ocaml-maint@lists.debian.org Changed-By: Julien Cristau [EMAIL PROTECTED] Description: ocaml - ML language implementation with a class-based object system ocaml-base - Runtime system for ocaml bytecode executables ocaml-base-nox - Runtime system for ocaml bytecode executables ocaml-compiler-libs - Ocaml interpreter and standard libraries ocaml-interp - Ocaml interpreter and standard libraries ocaml-mode - A major mode for editing Objective Caml in Emacs ocaml-native-compilers - Native code compilers of the ocaml suite (the .opt ones) ocaml-nox - ML language implementation with a class-based object system ocaml-source - Sources for Objective Caml Changes: ocaml (3.09.0-3) unstable; urgency=low . * Fix build on non-native arches which was broken by the changes to debian/rules in the previous release. Sorry for this :( Files: 23af3e7f7d1acf0a258559d7e102338b 915 devel optional ocaml_3.09.0-3.dsc c141cee614d11107c298a65be49ca137 58894 devel optional ocaml_3.09.0-3.diff.gz 4d0a578381f2c4babeda3c6fce14123b 94044 devel optional ocaml-mode_3.09.0-3_all.deb ea8dd7f9d8088af0f30bde970e33cd48 6142978 devel optional ocaml-nox_3.09.0-3_i386.deb ea9f792a17c7b430ab64a3a85cec0fab 2637778 devel optional ocaml-native-compilers_3.09.0-3_i386.deb fab4b88f697eabafec5b32743b6cd1c7 1796192 devel optional ocaml_3.09.0-3_i386.deb 72a9bda337fb739f69780efb65c44686 254610 devel optional ocaml-base-nox_3.09.0-3_i386.deb b4f0cfb0d064359260261d3e8ae19595 65734 devel optional ocaml-base_3.09.0-3_i386.deb 252942b1ef6ebda25463d708158a8f91 2051902 devel optional ocaml-source_3.09.0-3_all.deb 72ba66c8b8631e1e418be2df4745cd42 1008418 devel optional ocaml-interp_3.09.0-3_i386.deb 53f1bf1b07099eb1e6255a39d219b8d7 764952 devel optional ocaml-compiler-libs_3.09.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmWP11cqbBPLEI7wRAmCJAJ9CD0ykXiforHfObkK9UXETeFiP0gCfSJnz y7YkIL2B/WVpc/QAg5b2C+o= =iCbX -END PGP SIGNATURE- Accepted: ocaml-base-nox_3.09.0-3_i386.deb to pool/main/o/ocaml/ocaml-base-nox_3.09.0-3_i386.deb ocaml-base_3.09.0-3_i386.deb to pool/main/o/ocaml/ocaml-base_3.09.0-3_i386.deb ocaml-compiler-libs_3.09.0-3_i386.deb to pool/main/o/ocaml/ocaml-compiler-libs_3.09.0-3_i386.deb ocaml-interp_3.09.0-3_i386.deb to pool/main/o/ocaml/ocaml-interp_3.09.0-3_i386.deb ocaml-mode_3.09.0-3_all.deb to pool/main/o/ocaml/ocaml-mode_3.09.0-3_all.deb ocaml-native-compilers_3.09.0-3_i386.deb to pool/main/o/ocaml/ocaml-native-compilers_3.09.0-3_i386.deb ocaml-nox_3.09.0-3_i386.deb to pool/main/o/ocaml/ocaml-nox_3.09.0-3_i386.deb ocaml-source_3.09.0-3_all.deb to pool/main/o/ocaml/ocaml-source_3.09.0-3_all.deb ocaml_3.09.0-3.diff.gz to pool/main/o/ocaml/ocaml_3.09.0-3.diff.gz ocaml_3.09.0-3.dsc to pool/main/o/ocaml/ocaml_3.09.0-3.dsc ocaml_3.09.0-3_i386.deb to pool/main/o/ocaml/ocaml_3.09.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted madison-lite 0.6 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 11:34:27 + Source: madison-lite Binary: madison-lite Architecture: source all Version: 0.6 Distribution: unstable Urgency: low Maintainer: Colin Watson [EMAIL PROTECTED] Changed-By: Colin Watson [EMAIL PROTECTED] Description: madison-lite - display versions of Debian packages in an archive Changes: madison-lite (0.6) unstable; urgency=low . * Sort output by packages in the order specified on the command-line (to match madison) rather than interleaving results for different packages. Files: 377dfa54ab327391e016f584dc3117a7 508 admin optional madison-lite_0.6.dsc b6dd48440c63037003f6ff851601aa33 10264 admin optional madison-lite_0.6.tar.gz 7bb675cb550a0acfb31efe3296792ab1 12088 admin optional madison-lite_0.6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmWyU9t0zAhD6TNERAk4wAJ9Po/DGuxmdMOU4dkRyjHqHL8j9uACfU2B3 9ox3fpn1/CGbbN7gyASmJFE= =ux9F -END PGP SIGNATURE- Accepted: madison-lite_0.6.dsc to pool/main/m/madison-lite/madison-lite_0.6.dsc madison-lite_0.6.tar.gz to pool/main/m/madison-lite/madison-lite_0.6.tar.gz madison-lite_0.6_all.deb to pool/main/m/madison-lite/madison-lite_0.6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apt-setup 1:0.4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 12:09:30 + Source: apt-setup Binary: apt-mirror-setup apt-cdrom-setup apt-setup-udeb Architecture: source all Version: 1:0.4 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Colin Watson [EMAIL PROTECTED] Description: apt-cdrom-setup - set up a CD in sources.list (udeb) apt-mirror-setup - set up a mirror in sources.list (udeb) apt-setup-udeb - Configure apt (udeb) Closes: 313235 Changes: apt-setup (1:0.4) unstable; urgency=low . [ Frans Pop ] * Use the codename for the release in sources.list instead of the suite. Requires: cdrom-detect =1.11; choose-mirror =1.16; iso-scan =1.10. Closes: #313235 . [ Colin Watson ] * Make apt-setup-verify preserve blank lines. * Avoid double slashes in sources.list mirror lines. Files: 8296280c423f62c844a9e80da6338eb3 615 debian-installer extra apt-setup_0.4.dsc 78e48b394a7c9725b96865e61f4c989c 65415 debian-installer extra apt-setup_0.4.tar.gz dee617f6176345fdaa2c05fb39b5b5fa 8684 debian-installer standard apt-setup-udeb_0.4_all.udeb cd061018e7869a177dc73ea46cbf6abd 20712 debian-installer extra apt-mirror-setup_0.4_all.udeb 102ea0f51a177c1b403153738c6c4deb 3150 debian-installer extra apt-cdrom-setup_0.4_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmXV/9t0zAhD6TNERAoDsAJ4jUDJzBsJYktR+4rFN5UYGPwlhVwCfR1Ku EhgfF472nEyCLeRoxpJ12ik= =ZSwq -END PGP SIGNATURE- Accepted: apt-cdrom-setup_0.4_all.udeb to pool/main/a/apt-setup/apt-cdrom-setup_0.4_all.udeb apt-mirror-setup_0.4_all.udeb to pool/main/a/apt-setup/apt-mirror-setup_0.4_all.udeb apt-setup-udeb_0.4_all.udeb to pool/main/a/apt-setup/apt-setup-udeb_0.4_all.udeb apt-setup_0.4.dsc to pool/main/a/apt-setup/apt-setup_0.4.dsc apt-setup_0.4.tar.gz to pool/main/a/apt-setup/apt-setup_0.4.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted loop-aes-utils 2.12r-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 11:05:48 +0100 Source: loop-aes-utils Binary: loop-aes-utils mount-aes-udeb Architecture: source i386 Version: 2.12r-1 Distribution: unstable Urgency: low Maintainer: Max Vozeler [EMAIL PROTECTED] Changed-By: Max Vozeler [EMAIL PROTECTED] Description: loop-aes-utils - Tools for mounting and manipulating filesystems mount-aes-udeb - Mount utils for loop-AES (udeb) Changes: loop-aes-utils (2.12r-1) unstable; urgency=low . * New upstream release - Includes CAN-2005-2876 fix * Sync with util-linux 2.12r-1 * patches/30swsusp-resume - Added from util-linux 2.12r-1 Files: ed7eb7501ee5b2e8e72dfd0a7470030d 643 admin optional loop-aes-utils_2.12r-1.dsc c261230b27fc0fbcc287c76884caf2d3 1992725 admin optional loop-aes-utils_2.12r.orig.tar.gz 58b9c9c159129cf155aa4290483eb38a 73385 admin optional loop-aes-utils_2.12r-1.diff.gz b6c8c6cd12853f8afcd806a05a6f3d49 143702 admin optional loop-aes-utils_2.12r-1_i386.deb 7b0141a074ba9268b74a8a94ea397f14 84390 debian-installer extra mount-aes-udeb_2.12r-1_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmXVGnVvVEbfNotwRAip3AJ92T4DRfQLGpfzpNgNV/MrcVMHssgCeOHW8 0/V/Z7AIzetCbiSUIhltxI0= =vYuW -END PGP SIGNATURE- Accepted: loop-aes-utils_2.12r-1.diff.gz to pool/main/l/loop-aes-utils/loop-aes-utils_2.12r-1.diff.gz loop-aes-utils_2.12r-1.dsc to pool/main/l/loop-aes-utils/loop-aes-utils_2.12r-1.dsc loop-aes-utils_2.12r-1_i386.deb to pool/main/l/loop-aes-utils/loop-aes-utils_2.12r-1_i386.deb loop-aes-utils_2.12r.orig.tar.gz to pool/main/l/loop-aes-utils/loop-aes-utils_2.12r.orig.tar.gz mount-aes-udeb_2.12r-1_i386.udeb to pool/main/l/loop-aes-utils/mount-aes-udeb_2.12r-1_i386.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kile 1:1.8.1-3.2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 09 Dec 2005 13:44:02 +0100 Source: kile Binary: kile kile-i18n Architecture: all i386 source Version: 1:1.8.1-3.2 Distribution: unstable Urgency: low Maintainer: Ben Burton [EMAIL PROTECTED] Changed-By: Adeodato Simó [EMAIL PROTECTED] Description: kile - KDE Integrated LaTeX Environment kile-i18n - translations for Kile, the KDE Integrated LaTeX Environment Closes: 342229 Changes: kile (1:1.8.1-3.2) unstable; urgency=low . * Non-maintainer upload with maintainer's consent. * No source-changes upload to make kile-i18n installable again after its binNMU. (Closes: #342229) Files: 37180382a30a86b533be22fbedc32470 704 tex optional kile_1.8.1-3.2.dsc ab63d682a858c1f5781611201cbb437a 163408 tex optional kile_1.8.1-3.2.diff.gz b602a41e3bfe909cb42491f0b8216137 1792592 tex optional kile-i18n_1.8.1-3.2_all.deb d2aeb1798660e15279b21f3246cdb32d 1311876 tex optional kile_1.8.1-3.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Signed by Adeodato Simó [EMAIL PROTECTED] iEYEARECAAYFAkOZfoEACgkQgyNlRdHEGIJRuACePpsypQUvLFOWZAIBogd5cS9l 5jcAni7Td9mf00zSqge/CEBAicWqG5UH =P6UQ -END PGP SIGNATURE- Accepted: kile-i18n_1.8.1-3.2_all.deb to pool/main/k/kile/kile-i18n_1.8.1-3.2_all.deb kile_1.8.1-3.2.diff.gz to pool/main/k/kile/kile_1.8.1-3.2.diff.gz kile_1.8.1-3.2.dsc to pool/main/k/kile/kile_1.8.1-3.2.dsc kile_1.8.1-3.2_i386.deb to pool/main/k/kile/kile_1.8.1-3.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted preload 0.2-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 12:49:08 +0200 Source: preload Binary: preload Architecture: source i386 Version: 0.2-3 Distribution: unstable Urgency: low Maintainer: Kari Pahula [EMAIL PROTECTED] Changed-By: Kari Pahula [EMAIL PROTECTED] Description: preload- an adaptive readahead daemon Closes: 340983 Changes: preload (0.2-3) unstable; urgency=low . * Using s-s-d without its path in logrotate didn't work and just broke it even further. Calling invoke-rc.d preload reload now instead. (Closes: #340983) * s/start-stop-daemon -u 1/start-stop-daemon -u 0/ (argh). Files: 7692d0392d8c8e25e0c30390a8092815 569 misc optional preload_0.2-3.dsc c7ec4d9ef46e3d5ec91b02c7b7a053d9 4408 misc optional preload_0.2-3.diff.gz 4f1fa31f0256566f88909eff4d3f4d40 32038 misc optional preload_0.2-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmXy/NFDtUT/MKpARAmjqAJ9yV1CfODchur/1niDYuJSsI4bHbwCg8ivx 6+6TIhgB+v87FKs6lCA3Tsg= =qBiz -END PGP SIGNATURE- Accepted: preload_0.2-3.diff.gz to pool/main/p/preload/preload_0.2-3.diff.gz preload_0.2-3.dsc to pool/main/p/preload/preload_0.2-3.dsc preload_0.2-3_i386.deb to pool/main/p/preload/preload_0.2-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libmusicbrainz-queries-perl 0.09-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 14:33:24 +0100 Source: libmusicbrainz-queries-perl Binary: libmusicbrainz-queries-perl Architecture: source i386 Version: 0.09-1 Distribution: unstable Urgency: low Maintainer: Michael Ablassmeier [EMAIL PROTECTED] Changed-By: Michael Ablassmeier [EMAIL PROTECTED] Description: libmusicbrainz-queries-perl - provides access to the MusicBrainz RDF Query Constants Changes: libmusicbrainz-queries-perl (0.09-1) unstable; urgency=low . * New upstream release * Bump up Standards version. Files: eadf81d0ffe503b8ab7a81b62fa5b669 680 perl optional libmusicbrainz-queries-perl_0.09-1.dsc bbb98a50b3c25cdf539dfe7a951f0bf8 18402 perl optional libmusicbrainz-queries-perl_0.09.orig.tar.gz 905024b16b8c53b17536c9cf8e15f61b 1535 perl optional libmusicbrainz-queries-perl_0.09-1.diff.gz 1de0b8a8d3adfbd789017fae5ff3491c 21882 perl optional libmusicbrainz-queries-perl_0.09-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDmYnzmHaJYZ7RAb8RAuufAJ9D4UY3Ki9YD0IvuIFJc/KFQUJzsgCgxYuJ +CK6d9gpjJbiBAaT3MJOoFg= =zKgl -END PGP SIGNATURE- Accepted: libmusicbrainz-queries-perl_0.09-1.diff.gz to pool/main/libm/libmusicbrainz-queries-perl/libmusicbrainz-queries-perl_0.09-1.diff.gz libmusicbrainz-queries-perl_0.09-1.dsc to pool/main/libm/libmusicbrainz-queries-perl/libmusicbrainz-queries-perl_0.09-1.dsc libmusicbrainz-queries-perl_0.09-1_i386.deb to pool/main/libm/libmusicbrainz-queries-perl/libmusicbrainz-queries-perl_0.09-1_i386.deb libmusicbrainz-queries-perl_0.09.orig.tar.gz to pool/main/libm/libmusicbrainz-queries-perl/libmusicbrainz-queries-perl_0.09.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gabber2 1.9.4+cvs20040709-17 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 5 Dec 2005 22:39:30 -0200 Source: gabber2 Binary: gabber2 Architecture: source i386 Version: 1.9.4+cvs20040709-17 Distribution: unstable Urgency: low Maintainer: Goedson Teixeira Paixao [EMAIL PROTECTED] Changed-By: Goedson Teixeira Paixao [EMAIL PROTECTED] Description: gabber2- jabber client for the GNOME desktop Closes: 332350 336077 Changes: gabber2 (1.9.4+cvs20040709-17) unstable; urgency=low . * Added Return as accelerator to the default button in the Login Dialog (Closes: #336077). * Properly handle save history settings (Closes: #332350). * Improved unseen messages handling in chat window: - Chat window is marked as having new messages only when it is not the window with the input focus. - Display the number of new messagens in the window title. * Changes the chat window icon to reflect the current presence status of the contact. Files: f5df670778fc32f199f5fb075ace04ba 848 gnome optional gabber2_1.9.4+cvs20040709-17.dsc 551964c7d0e28a373c44cc650bfe956d 261440 gnome optional gabber2_1.9.4+cvs20040709-17.diff.gz 33566c68ef0915592b0e53027452ffa5 1810156 gnome optional gabber2_1.9.4+cvs20040709-17_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmZGi7tjUzB3rjq4RAg9xAJ44sSgznGzGV6fBndsMlq3/0xoEGwCghJd/ f+g6VGz8/MiPibbj/BzfHgg= =5L2l -END PGP SIGNATURE- Accepted: gabber2_1.9.4+cvs20040709-17.diff.gz to pool/main/g/gabber2/gabber2_1.9.4+cvs20040709-17.diff.gz gabber2_1.9.4+cvs20040709-17.dsc to pool/main/g/gabber2/gabber2_1.9.4+cvs20040709-17.dsc gabber2_1.9.4+cvs20040709-17_i386.deb to pool/main/g/gabber2/gabber2_1.9.4+cvs20040709-17_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted junior-games-gl 1.7 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 10:57:43 -0400 Source: junior-games-gl Binary: junior-games-gl Architecture: source all Version: 1.7 Distribution: unstable Urgency: low Maintainer: Ben Armstrong [EMAIL PROTECTED] Changed-By: Ben Armstrong [EMAIL PROTECTED] Description: junior-games-gl - Debian Jr. 3D Games (hardware acceleration required) Closes: 340078 Changes: junior-games-gl (1.7) unstable; urgency=low . * Depend on ppracer instead of tuxracer. (Closes: #340078) Files: 291792ff15a4bfb47f390904fdbae1d8 483 misc extra junior-games-gl_1.7.dsc 4df34a3952db44e3dd4313a1b5ddbb72 1857 misc extra junior-games-gl_1.7.tar.gz 463c0f7b579ec984cf01d395ef0bdfa3 2090 misc extra junior-games-gl_1.7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmZwlWpTzygsnE8gRAi2xAJ9sAsFit1U5fLoHbPK6OR+sPskMIACfZCu9 RQu2xEtfSJR89SYP1qc3OsU= =6fPO -END PGP SIGNATURE- Accepted: junior-games-gl_1.7.dsc to pool/main/j/junior-games-gl/junior-games-gl_1.7.dsc junior-games-gl_1.7.tar.gz to pool/main/j/junior-games-gl/junior-games-gl_1.7.tar.gz junior-games-gl_1.7_all.deb to pool/main/j/junior-games-gl/junior-games-gl_1.7_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-yacc 0.2-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 13:34:44 +0100 Source: cl-yacc Binary: cl-yacc Architecture: source all Version: 0.2-1 Distribution: unstable Urgency: low Maintainer: René van Bevern [EMAIL PROTECTED] Changed-By: René van Bevern [EMAIL PROTECTED] Description: cl-yacc- parser generator for Common Lisp Changes: cl-yacc (0.2-1) unstable; urgency=low . * New upstream release . * debian/control: + add cdbs and debhelper to Build-Depends because they are used for the clean target + Indent Homepage field in description Files: dfc820c4d49c0d96e72e34766afe07b7 652 devel optional cl-yacc_0.2-1.dsc 28609d3024dad390cfd2c16942abc38d 16788 devel optional cl-yacc_0.2.orig.tar.gz 0307b937be14e779735b11681a62d8ed 2509 devel optional cl-yacc_0.2-1.diff.gz bd25f34d1eb41efd1a124b0ff1304121 151854 devel optional cl-yacc_0.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmaYH11ldN0tyliURArECAJ0fXYhC+4xdUCzqUGh5jqIME7i3iwCgpKf4 vrs3zoIOmg468O9exJPy/S8= =CKd6 -END PGP SIGNATURE- Accepted: cl-yacc_0.2-1.diff.gz to pool/main/c/cl-yacc/cl-yacc_0.2-1.diff.gz cl-yacc_0.2-1.dsc to pool/main/c/cl-yacc/cl-yacc_0.2-1.dsc cl-yacc_0.2-1_all.deb to pool/main/c/cl-yacc/cl-yacc_0.2-1_all.deb cl-yacc_0.2.orig.tar.gz to pool/main/c/cl-yacc/cl-yacc_0.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libwpd 0.8.4-2 (source all powerpc hppa i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 16:20:02 + Source: libwpd Binary: libwpd-tools libwpd8-doc libwpd8c2a libwpd8-dev libwpd-stream8c2a Architecture: all hppa i386 powerpc source Version: 0.8.4-2 Distribution: unstable Urgency: low Maintainer: Masayuki Hatta (mhatta) [EMAIL PROTECTED] Changed-By: Rene Engelhard [EMAIL PROTECTED] Description: libwpd-stream8c2a - Library for handling WordPerfect documents (shared library) libwpd-tools - Tools from libwpd for converting WordPerfect to HTML/RAW/Text libwpd8-dev - Library for handling WordPerfect documents (development) libwpd8-doc - Library for handling WordPerfect documents (documentation) libwpd8c2a - Library for handling WordPerfect documents (shared library) Changes: libwpd (0.8.4-2) unstable; urgency=low . * re-autogen to fix hppa build * update automake builddep and add autoconf Files: 0dc4e88660a345c2fbda9abe09791cda 96048 devel optional libwpd_0.8.4-2.diff.gz 11b93508b739bb44655c581b1edb35e6 12438 libs optional libwpd-stream8c2a_0.8.4-2_powerpc.deb 25568f879dabe35a8f994eb6a92227e2 10714 libs optional libwpd-stream8c2a_0.8.4-2_i386.deb 3761b51009262605ef420f5489fba703 295202 libdevel optional libwpd8-dev_0.8.4-2_hppa.deb 3f4b510a2f2f4bdddf64976f8fe8cf86 27404 utils optional libwpd-tools_0.8.4-2_hppa.deb 4fc74c41169ec7e88cceb38c5df8f474 26080 utils optional libwpd-tools_0.8.4-2_powerpc.deb 599bac93ebd1f5ed2e36ad6791ca793d 142706 libs optional libwpd8c2a_0.8.4-2_i386.deb 5d1d7516026b781c94d0866f97f8030a 246348 libdevel optional libwpd8-dev_0.8.4-2_i386.deb 9a7afcc1758e4434ed3f963825424959 823044 doc optional libwpd8-doc_0.8.4-2_all.deb b18bcabff2636429946bc98e7807c039 11582 libs optional libwpd-stream8c2a_0.8.4-2_hppa.deb eade30f00ea6438165c55cf4512b29f4 789 devel optional libwpd_0.8.4-2.dsc d5e53b99214314b11f3f2c39d816 22476 utils optional libwpd-tools_0.8.4-2_i386.deb f95bfa37bea1b2758e53a9297b8f7d14 272538 libdevel optional libwpd8-dev_0.8.4-2_powerpc.deb fe44b8168ad37d92ff88d7ec2f428d32 149904 libs optional libwpd8c2a_0.8.4-2_powerpc.deb ff19602a78cb99fc8f098c7861b7a6ec 174204 libs optional libwpd8c2a_0.8.4-2_hppa.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmbSQ+FmQsCSK63MRAu3YAJ0VqsLTUi/7jo9M1xeiDJ+WhXxS2gCfdkjK VnjhhZ9BFN13+ovJ+otwsGM= =jaA+ -END PGP SIGNATURE- Accepted: libwpd-stream8c2a_0.8.4-2_hppa.deb to pool/main/libw/libwpd/libwpd-stream8c2a_0.8.4-2_hppa.deb libwpd-stream8c2a_0.8.4-2_i386.deb to pool/main/libw/libwpd/libwpd-stream8c2a_0.8.4-2_i386.deb libwpd-stream8c2a_0.8.4-2_powerpc.deb to pool/main/libw/libwpd/libwpd-stream8c2a_0.8.4-2_powerpc.deb libwpd-tools_0.8.4-2_hppa.deb to pool/main/libw/libwpd/libwpd-tools_0.8.4-2_hppa.deb libwpd-tools_0.8.4-2_i386.deb to pool/main/libw/libwpd/libwpd-tools_0.8.4-2_i386.deb libwpd-tools_0.8.4-2_powerpc.deb to pool/main/libw/libwpd/libwpd-tools_0.8.4-2_powerpc.deb libwpd8-dev_0.8.4-2_hppa.deb to pool/main/libw/libwpd/libwpd8-dev_0.8.4-2_hppa.deb libwpd8-dev_0.8.4-2_i386.deb to pool/main/libw/libwpd/libwpd8-dev_0.8.4-2_i386.deb libwpd8-dev_0.8.4-2_powerpc.deb to pool/main/libw/libwpd/libwpd8-dev_0.8.4-2_powerpc.deb libwpd8-doc_0.8.4-2_all.deb to pool/main/libw/libwpd/libwpd8-doc_0.8.4-2_all.deb libwpd8c2a_0.8.4-2_hppa.deb to pool/main/libw/libwpd/libwpd8c2a_0.8.4-2_hppa.deb libwpd8c2a_0.8.4-2_i386.deb to pool/main/libw/libwpd/libwpd8c2a_0.8.4-2_i386.deb libwpd8c2a_0.8.4-2_powerpc.deb to pool/main/libw/libwpd/libwpd8c2a_0.8.4-2_powerpc.deb libwpd_0.8.4-2.diff.gz to pool/main/libw/libwpd/libwpd_0.8.4-2.diff.gz libwpd_0.8.4-2.dsc to pool/main/libw/libwpd/libwpd_0.8.4-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cproto 4.7e-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 10:25:50 -0600 Source: cproto Binary: cproto Architecture: source i386 Version: 4.7e-1 Distribution: unstable Urgency: low Maintainer: Kenneth J. Pronovici [EMAIL PROTECTED] Changed-By: Kenneth J. Pronovici [EMAIL PROTECTED] Description: cproto - Generate C function prototypes and convert function definitions Changes: cproto (4.7e-1) unstable; urgency=low . * New upstream release. Files: 746e83a3c9629898c51534e7ef30b18f 576 devel optional cproto_4.7e-1.dsc fbbba31154ad42af9441d44fddd7e45f 145919 devel optional cproto_4.7e.orig.tar.gz 3f19417b05459238d0b6e91c3cc53f15 2199 devel optional cproto_4.7e-1.diff.gz 246ced63d9c33497331fe588310f5fe9 46414 devel optional cproto_4.7e-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDmbEn8On2ujzZUQQRAk/PAJ0SyK8B9s+daa6gL8h9VqaGpWsSDgCgmTbe LAMRRvAWWYAMy1A35kCkYs4= =yNkd -END PGP SIGNATURE- Accepted: cproto_4.7e-1.diff.gz to pool/main/c/cproto/cproto_4.7e-1.diff.gz cproto_4.7e-1.dsc to pool/main/c/cproto/cproto_4.7e-1.dsc cproto_4.7e-1_i386.deb to pool/main/c/cproto/cproto_4.7e-1_i386.deb cproto_4.7e.orig.tar.gz to pool/main/c/cproto/cproto_4.7e.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debian-installer-utils 1.21 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 17:36:40 +0100 Source: debian-installer-utils Binary: di-utils-terminfo di-utils-mapdevfs di-utils-shell di-utils-reboot di-utils di-utils-exit-installer Architecture: source i386 all Version: 1.21 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Frans Pop [EMAIL PROTECTED] Description: di-utils - Miscellaneous utilities for the debian installer (udeb) di-utils-exit-installer - Exit installer (udeb) di-utils-mapdevfs - mapdevfs utility for the debian installer (udeb) di-utils-reboot - Reboot (udeb) di-utils-shell - Execute a shell (udeb) di-utils-terminfo - Terminfo entries needed by newt/slang in debian installer (udeb) Changes: debian-installer-utils (1.21) unstable; urgency=low . * chroot-setup.sh: set LANG again; not doing so causes endless perl warnings. * apt-install: run chroot_setup before setting the frontend to noninteractive as chroot_setup clears that variable. Files: 92871f4d494b464ebc64a7ef737576fe 965 debian-installer standard debian-installer-utils_1.21.dsc beefb86b4034c394182102b18d9558db 52786 debian-installer standard debian-installer-utils_1.21.tar.gz 06628f35cca3df2c8f2b7af17becd9ef 14340 debian-installer standard di-utils-shell_1.21_all.udeb ba9fac067f05115499eea69ebb51125e 6780 debian-installer standard di-utils-reboot_1.21_all.udeb 379462fb7118aa44955c0a94e59fe355 debian-installer extra di-utils-exit-installer_1.21_all.udeb 65c67ba6240d5887423259c5440b7bc2 754 debian-installer standard di-utils-terminfo_1.21_all.udeb f4cfa53fb7d29e8869fa285e1a37 7522 debian-installer standard di-utils_1.21_i386.udeb 1672105badfb95fa387da4978345f71d 2172 debian-installer standard di-utils-mapdevfs_1.21_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDmbYKgm/Kwh6ICoQRAnTQAKDCTx22DoJDq8xmhL/OoyWvqmQYIwCePyKQ CbOlreLZHDhC5ew5fqGi8Vw= =6hlT -END PGP SIGNATURE- Accepted: debian-installer-utils_1.21.dsc to pool/main/d/debian-installer-utils/debian-installer-utils_1.21.dsc debian-installer-utils_1.21.tar.gz to pool/main/d/debian-installer-utils/debian-installer-utils_1.21.tar.gz di-utils-exit-installer_1.21_all.udeb to pool/main/d/debian-installer-utils/di-utils-exit-installer_1.21_all.udeb di-utils-mapdevfs_1.21_i386.udeb to pool/main/d/debian-installer-utils/di-utils-mapdevfs_1.21_i386.udeb di-utils-reboot_1.21_all.udeb to pool/main/d/debian-installer-utils/di-utils-reboot_1.21_all.udeb di-utils-shell_1.21_all.udeb to pool/main/d/debian-installer-utils/di-utils-shell_1.21_all.udeb di-utils-terminfo_1.21_all.udeb to pool/main/d/debian-installer-utils/di-utils-terminfo_1.21_all.udeb di-utils_1.21_i386.udeb to pool/main/d/debian-installer-utils/di-utils_1.21_i386.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xpuyopuyo 0.9.8-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 08:59:58 -0800 Source: xpuyopuyo Binary: xpuyopuyo Architecture: source i386 Version: 0.9.8-3 Distribution: unstable Urgency: low Maintainer: Daniel Burrows [EMAIL PROTECTED] Changed-By: Daniel Burrows [EMAIL PROTECTED] Description: xpuyopuyo - A puzzle game similar to tetris, played with colored blobs Closes: 342657 Changes: xpuyopuyo (0.9.8-3) unstable; urgency=low . * Build-depend on groff-base. (Closes: #342657) Files: 589ed39c5aa10a49689b827cd5263dd8 629 games optional xpuyopuyo_0.9.8-3.dsc 051255a06123ffd8e43442174b58e60a 21998 games optional xpuyopuyo_0.9.8-3.diff.gz 006c2441d8aebc02fa52479e0cf116d4 1001874 games optional xpuyopuyo_0.9.8-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmb9vch6xsM7kSXgRAvcwAKCUXocQflu9M32BxrqZ5Dmx3aqkBQCg70UL 0oRrHVwRh1/AVjK1U1mSBGM= =mYR3 -END PGP SIGNATURE- Accepted: xpuyopuyo_0.9.8-3.diff.gz to pool/main/x/xpuyopuyo/xpuyopuyo_0.9.8-3.diff.gz xpuyopuyo_0.9.8-3.dsc to pool/main/x/xpuyopuyo/xpuyopuyo_0.9.8-3.dsc xpuyopuyo_0.9.8-3_i386.deb to pool/main/x/xpuyopuyo/xpuyopuyo_0.9.8-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xemacs21 21.4.18-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 10 Dec 2005 00:02:01 +0900 Source: xemacs21 Binary: xemacs21-gnome-mule xemacs21-mule xemacs21-bin xemacs21-gnome-nomule xemacs21-supportel xemacs21-gnome-mule-canna-wnn xemacs21-support xemacs21-mule-canna-wnn xemacs21 xemacs21-nomule Architecture: source all i386 Version: 21.4.18-1 Distribution: unstable Urgency: low Maintainer: OHURA Makoto [EMAIL PROTECTED] Changed-By: OHURA Makoto [EMAIL PROTECTED] Description: xemacs21 - highly customizable text editor xemacs21-bin - highly customizable text editor -- support binaries xemacs21-gnome-mule - highly customizable text editor -- Mule binary xemacs21-gnome-mule-canna-wnn - highly customizable text editor -- Mule binary compiled with Cann xemacs21-gnome-nomule - highly customizable text editor -- Non-mule binary xemacs21-mule - highly customizable text editor -- Mule binary xemacs21-mule-canna-wnn - highly customizable text editor -- Mule binary compiled with Cann xemacs21-nomule - highly customizable text editor -- Non-mule binary xemacs21-support - highly customizable text editor -- architecture independent suppo xemacs21-supportel - highly customizable text editor -- non-required library files Changes: xemacs21 (21.4.18-1) unstable; urgency=low . * New upstream release * debian/patches/20_gcc_4.0_compiling.dpatch: Sync with 21.4.18 * debian/control.in: Update Standards-Version. Files: 624ff286af4a18af1574ad86d3fde840 1040 editors optional xemacs21_21.4.18-1.dsc b1ab33ddba5664eb0425b2411aecfb75 8378710 editors optional xemacs21_21.4.18.orig.tar.gz dd9a9a8332c6bed58d2a6abc6e9b98b2 69118 editors optional xemacs21_21.4.18-1.diff.gz 66054d3c1bd7d7a23fbb0cb9929ed404 13936 editors optional xemacs21_21.4.18-1_all.deb 2cc1261c1e55defcacdc4185317ff67e 1291632 editors optional xemacs21-supportel_21.4.18-1_all.deb f9fec4b6a5e4c7d8b74835291f6b8a54 4573828 editors optional xemacs21-support_21.4.18-1_all.deb 534e3766bb9543d1a6f4b4fcc724def3 1823452 editors optional xemacs21-nomule_21.4.18-1_i386.deb 3af9cfdd0169dbccffe7e3914255f676 2085938 editors optional xemacs21-mule_21.4.18-1_i386.deb e822b713561a3fb8d3ad1cfb2f3f0140 2172510 editors optional xemacs21-mule-canna-wnn_21.4.18-1_i386.deb 38f3f848e658d96fd0b6ea806cd1ce6d 1865704 gnome optional xemacs21-gnome-nomule_21.4.18-1_i386.deb 904443964f064b396601f8d7ed4ef331 2124658 gnome optional xemacs21-gnome-mule_21.4.18-1_i386.deb 61e820bff7e5cde0c5f98165211b2c84 2214878 gnome optional xemacs21-gnome-mule-canna-wnn_21.4.18-1_i386.deb 526c7f639178ad5dc982acaf11205c7c 489918 editors optional xemacs21-bin_21.4.18-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmbtT7qLvonfc4IMRAlB1AKCNsEiZBrR0v5zOSIUPo7O2TbuwoACeIDWd GRu21Gb4Nng83amHtQp8klk= =GyxA -END PGP SIGNATURE- Accepted: xemacs21-bin_21.4.18-1_i386.deb to pool/main/x/xemacs21/xemacs21-bin_21.4.18-1_i386.deb xemacs21-gnome-mule-canna-wnn_21.4.18-1_i386.deb to pool/main/x/xemacs21/xemacs21-gnome-mule-canna-wnn_21.4.18-1_i386.deb xemacs21-gnome-mule_21.4.18-1_i386.deb to pool/main/x/xemacs21/xemacs21-gnome-mule_21.4.18-1_i386.deb xemacs21-gnome-nomule_21.4.18-1_i386.deb to pool/main/x/xemacs21/xemacs21-gnome-nomule_21.4.18-1_i386.deb xemacs21-mule-canna-wnn_21.4.18-1_i386.deb to pool/main/x/xemacs21/xemacs21-mule-canna-wnn_21.4.18-1_i386.deb xemacs21-mule_21.4.18-1_i386.deb to pool/main/x/xemacs21/xemacs21-mule_21.4.18-1_i386.deb xemacs21-nomule_21.4.18-1_i386.deb to pool/main/x/xemacs21/xemacs21-nomule_21.4.18-1_i386.deb xemacs21-support_21.4.18-1_all.deb to pool/main/x/xemacs21/xemacs21-support_21.4.18-1_all.deb xemacs21-supportel_21.4.18-1_all.deb to pool/main/x/xemacs21/xemacs21-supportel_21.4.18-1_all.deb xemacs21_21.4.18-1.diff.gz to pool/main/x/xemacs21/xemacs21_21.4.18-1.diff.gz xemacs21_21.4.18-1.dsc to pool/main/x/xemacs21/xemacs21_21.4.18-1.dsc xemacs21_21.4.18-1_all.deb to pool/main/x/xemacs21/xemacs21_21.4.18-1_all.deb xemacs21_21.4.18.orig.tar.gz to pool/main/x/xemacs21/xemacs21_21.4.18.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted heroes 0.21-6 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Dec 2005 10:25:52 -0800 Source: heroes Binary: heroes-sdl heroes-common heroes-ggi Architecture: source i386 Version: 0.21-6 Distribution: unstable Urgency: low Maintainer: Daniel Burrows [EMAIL PROTECTED] Changed-By: Daniel Burrows [EMAIL PROTECTED] Description: heroes-common - Collect powerups and avoid your opponents' trails heroes-ggi - Collect powerups and avoid your opponents' trails heroes-sdl - Collect powerups and avoid your opponents' trails Closes: 342421 Changes: heroes (0.21-6) unstable; urgency=low . * Update config.guess and config.sub (Closes: #342421). * Update debhelper compat level to 5. * Build-depend on heroes-data. (HACK) . This is necessary because upstream uses heroes --help to generate the manpage, but this command fails if the data files for heroes are not available; worse, the failure mode is to generate an invalid manpage! Files: 28726b18fb987ce930642e04ba1ef99c 734 games optional heroes_0.21-6.dsc b865ab82ad76982ae34aa64545b1e71b 120181 games optional heroes_0.21-6.diff.gz 10e983eb0d70d598b360e4129b1ff55c 119048 games optional heroes-ggi_0.21-6_i386.deb f7f592492f9577dad10d23861913c54d 115108 games optional heroes-sdl_0.21-6_i386.deb 80a2d673a0053563f8a496af50a1843e 148962 games optional heroes-common_0.21-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmcX9ch6xsM7kSXgRAkTQAJ0RnQLunWZPmMzcGszbMyMPhHltyQCgt/uV ORTkZ8CofLZ0yrsIcqwLcpg= =41Pb -END PGP SIGNATURE- Accepted: heroes-common_0.21-6_i386.deb to pool/main/h/heroes/heroes-common_0.21-6_i386.deb heroes-ggi_0.21-6_i386.deb to pool/main/h/heroes/heroes-ggi_0.21-6_i386.deb heroes-sdl_0.21-6_i386.deb to pool/main/h/heroes/heroes-sdl_0.21-6_i386.deb heroes_0.21-6.diff.gz to pool/main/h/heroes/heroes_0.21-6.diff.gz heroes_0.21-6.dsc to pool/main/h/heroes/heroes_0.21-6.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted elilo 3.4pre5.2-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 9 Dec 2005 10:14:30 -0800 Source: elilo Binary: elilo Architecture: source i386 Version: 3.4pre5.2-2 Distribution: unstable Urgency: low Maintainer: Bdale Garbee [EMAIL PROTECTED] Changed-By: Bdale Garbee [EMAIL PROTECTED] Description: elilo - Bootloader for systems using EFI-based firmware Closes: 342639 Changes: elilo (3.4pre5.2-2) unstable; urgency=low . * change section from base to admin to match override * accept patch to fix syntax issue in elilo script, closes: #342639 Files: 5faa49fe26f5d4994b65150f188ab592 585 admin optional elilo_3.4pre5.2-2.dsc 0608a863e69ed9c7575b3d74f461b37f 14929 admin optional elilo_3.4pre5.2-2.diff.gz 579ff2b8cfa6137b1199a33766549d73 120366 admin optional elilo_3.4pre5.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmctCZKfAp/LPAagRAmrKAJ910v2VsftNuhnfXzkx3v+YeqoLegCfbz3D xv6msPXfvAiOaO9gSeCwz6U= =RTgR -END PGP SIGNATURE- Accepted: elilo_3.4pre5.2-2.diff.gz to pool/main/e/elilo/elilo_3.4pre5.2-2.diff.gz elilo_3.4pre5.2-2.dsc to pool/main/e/elilo/elilo_3.4pre5.2-2.dsc elilo_3.4pre5.2-2_i386.deb to pool/main/e/elilo/elilo_3.4pre5.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
