Viaggio al DebConf11
Salve a tutti. Rapido sondaggio tra i DD italiani: tra quelli che pensano di andare a Banja Luka a fine luglio c'è qualcuno che si è già fatto un'idea di come viaggiare? A me al momento la soluzione migliore (considerando un po' di cose, in particolare praticità e costo) sembra quello di arrivare a Zagabria in treno e poi continuare in autobus (che sembra molto più pratico del treno tra Zagabria e Banja Luka). Però non ho ancora fatto tutti i conti e sono interessato a capire se qualcun altro si è fatto venire in mente altre soluzioni geniali ed, in particolare, se è possibile viaggiare insieme ad altri per dividere le spese. Io penso di andare il 23 o il 24 luglio (se tutto va bene dovrei riuscire a laurearmi per il 22...). Ciao, Gio. -- Giovanni Mascellani mascell...@poisson.phc.unipi.it Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Re: Solutions Linux 2011 (10, 11 et 12 mai)
On Tue, 03 May 2011, Stéphan Gorget wrote: Solutions Linux approche à grand pas et j'ai finalement pu me libérer pour venir mercredi donner un coup de main sur le stand. Est-ce qu'il faut préparer des choses, où tout simplement arriver en avance où je sais pas ? Si tu as des choses sympas à montrer faisant tourner Debian, tu peux les emmener (plug computer, tablette, n900, ...). Sinon il n'y a besoin de rien de spécial. Pas besoin d'arriver (beaucoup) en avance, être à l'heure ca suffit. A+ -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504070543.gf4...@rivendell.home.ouaza.com
Re: Solutions Linux 2011 (10, 11 et 12 mai)
2011/5/4 Raphael Hertzog hert...@debian.org: On Tue, 03 May 2011, Stéphan Gorget wrote: Solutions Linux approche à grand pas et j'ai finalement pu me libérer pour venir mercredi donner un coup de main sur le stand. Est-ce qu'il faut préparer des choses, où tout simplement arriver en avance où je sais pas ? Si tu as des choses sympas à montrer faisant tourner Debian, tu peux les emmener (plug computer, tablette, n900, ...). Sinon il n'y a besoin de rien de spécial. Pas besoin d'arriver (beaucoup) en avance, être à l'heure ca suffit. A+ -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) J'ai bien un cluster HPC de + de 200 Tflops (Environ 1300 noeuds). Mais ca va pas être facile à déplacer. -- Stéphan -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=pbif0_unb5pewspxrxmd6+4k...@mail.gmail.com
Re: Solutions Linux 2011 (10, 11 et 12 mai)
J'ai bien un cluster HPC de + de 200 Tflops (Environ 1300 noeuds). Mais ca va pas être facile à déplacer. Peut être en photos ? Avec une note explicative sur la machine pour présenter des choses concrètes. Est-ce qu'il y aura des panneaux pour mettre des posters ou affiches ? -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=y-tkjneu+vbluzbagrigr471...@mail.gmail.com
Re: Solutions Linux 2011 (10, 11 et 12 mai)
On Wed, 4 May 2011 10:45:52 +0200, kaliderus kalide...@gmail.com wrote: J'ai bien un cluster HPC de + de 200 Tflops (Environ 1300 noeuds). Mais ca va pas être facile à déplacer. Peut être en photos ? Avec une note explicative sur la machine pour présenter des choses concrètes. Très bonne idée, ça pourrait intéresser les visiteurs. Bye, Carl Chenet -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/078fe9fe1225a2929d8c72f494df1dbd@localhost
Re: Solutions Linux 2011 (10, 11 et 12 mai)
On 04/05/11 at 09:27 +0200, Stéphan Gorget wrote: 2011/5/4 Raphael Hertzog hert...@debian.org: On Tue, 03 May 2011, Stéphan Gorget wrote: Solutions Linux approche à grand pas et j'ai finalement pu me libérer pour venir mercredi donner un coup de main sur le stand. Est-ce qu'il faut préparer des choses, où tout simplement arriver en avance où je sais pas ? Si tu as des choses sympas à montrer faisant tourner Debian, tu peux les emmener (plug computer, tablette, n900, ...). Sinon il n'y a besoin de rien de spécial. Pas besoin d'arriver (beaucoup) en avance, être à l'heure ca suffit. J'ai bien un cluster HPC de + de 200 Tflops (Environ 1300 noeuds). Mais ca va pas être facile à déplacer. Je croyais qu'il était sous RedHat ? ;) - Lucas -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504094736.ga8...@xanadu.blop.info
Re: Solutions Linux 2011 (10, 11 et 12 mai)
Raphael Hertzog hert...@debian.org wrote: Salut, Si tu as des choses sympas à montrer faisant tourner Debian, tu peux les emmener (plug computer, tablette, n900, ...). Sinon il n'y a besoin de rien de spécial. Attention à la fauche, tenez vos gadgets en laisse, ne les perdez jamais des yeux, ne les donner pas aux visiteurs. Il y a tous les ans des vols dans des conditions proprement incroyables, soyez sur vos gardes avec votre (petit) matériel et surtout ne laissez rien traîner dessus en cas de vol (infos perso, clés ...). JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb9an4le@sonic.technologeek.org
Re: Solutions Linux 2011 (10, 11 et 12 mai)
2011/5/4 Lucas Nussbaum lu...@lucas-nussbaum.net: On 04/05/11 at 09:27 +0200, Stéphan Gorget wrote: 2011/5/4 Raphael Hertzog hert...@debian.org: On Tue, 03 May 2011, Stéphan Gorget wrote: Solutions Linux approche à grand pas et j'ai finalement pu me libérer pour venir mercredi donner un coup de main sur le stand. Est-ce qu'il faut préparer des choses, où tout simplement arriver en avance où je sais pas ? Si tu as des choses sympas à montrer faisant tourner Debian, tu peux les emmener (plug computer, tablette, n900, ...). Sinon il n'y a besoin de rien de spécial. Pas besoin d'arriver (beaucoup) en avance, être à l'heure ca suffit. J'ai bien un cluster HPC de + de 200 Tflops (Environ 1300 noeuds). Mais ca va pas être facile à déplacer. Je croyais qu'il était sous RedHat ? ;) - Lucas L'information est récente mais maintenant officielle, après je vais essayer de me renseigner pour savoir quel est le périmètre de ce que je peux dire ou montrer. -- Stéphan -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktin3dyvg2qonnivga92tzor-vwa...@mail.gmail.com
Re: Solutions Linux 2011 (10, 11 et 12 mai)
On 04/05/11 at 14:16 +0200, Stéphan Gorget wrote: 2011/5/4 Lucas Nussbaum lu...@lucas-nussbaum.net: On 04/05/11 at 09:27 +0200, Stéphan Gorget wrote: 2011/5/4 Raphael Hertzog hert...@debian.org: On Tue, 03 May 2011, Stéphan Gorget wrote: Solutions Linux approche à grand pas et j'ai finalement pu me libérer pour venir mercredi donner un coup de main sur le stand. Est-ce qu'il faut préparer des choses, où tout simplement arriver en avance où je sais pas ? Si tu as des choses sympas à montrer faisant tourner Debian, tu peux les emmener (plug computer, tablette, n900, ...). Sinon il n'y a besoin de rien de spécial. Pas besoin d'arriver (beaucoup) en avance, être à l'heure ca suffit. J'ai bien un cluster HPC de + de 200 Tflops (Environ 1300 noeuds). Mais ca va pas être facile à déplacer. Je croyais qu'il était sous RedHat ? ;) - Lucas L'information est récente mais maintenant officielle, après je vais essayer de me renseigner pour savoir quel est le périmètre de ce que je peux dire ou montrer. Ca pourrait peut-être être intéressant de faire une press release commune sur ça, si c'est acceptable pour EDF. - Lucas -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504130958.ga18...@xanadu.blop.info
Inclusion de lib sous licence personnalisée
Bonsoir à tous, je participe au développement de logiciels libres pour les écoles primaires au travers du projet AbulÉdu. Nous avons fait le choix de bosser sur Qt depuis un peu plus d'un an et au fur et à mesure nous avançons dans différentes directions. En ce moment je cherche des solutions pour des échanges client/serveur et je suis tombé sur la libmaia dont voici la licence: https://github.com/wiedi/libmaia/blob/master/LICENSE Pouvez-vous me confirmer qu'elle n'est pas libre au sens Debian/GNU ? Pouvez-vous me confirmer qu'avec un tout petit peu de bonne volonté le développeur pourrait placer son travail sur GNU/GPL ? J'entends pas là que la GPL ne modifierais pas grand chose par rapport à sa licence actuelle. Merci d'avance, Éric -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc1be72.9060...@ryxeo.com
Re: Inclusion de lib sous licence personnalisée
Le 04/05/2011 23:23, Laurent Fousse a écrit : Bonjour, * Éric Seigne [Wed, May 04, 2011 at 11:00:34PM +0200]: Pouvez-vous me confirmer qu'elle n'est pas libre au sens Debian/GNU ? Je ne vois pas de problème spécifique du point de vue de Debian, c'est une BSD 2-clauses. Bonsoir Laurent, Cyril et tous les autres, merci à vous deux pour ces précisions, je peux donc continuer le développement avec cette lib au lieu de ma lancer dans un re-dev c'est cool :) le résultat final, c'est par exemple: http://raconte-moi.abuledu.org/w/1456-gourmandise-punie amicalement, Éric -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc1c664.3020...@ryxeo.com
Re: Inclusion de lib sous licence personnalisée
Bonjour, * Éric Seigne [Wed, May 04, 2011 at 11:00:34PM +0200]: Pouvez-vous me confirmer qu'elle n'est pas libre au sens Debian/GNU ? Je ne vois pas de problème spécifique du point de vue de Debian, c'est une BSD 2-clauses. Pouvez-vous me confirmer qu'avec un tout petit peu de bonne volonté le développeur pourrait placer son travail sur GNU/GPL ? J'entends pas là que la GPL ne modifierais pas grand chose par rapport à sa licence actuelle. Elle modifierait un point fondamental : tout logiciel incorporant une partie des sources serait forcé d'être GPL à son tour. Et ce n'est pas tout. On peut préférer la GPL, mais ce n'est ni mineur ni une question de « bonne volonté » mais de philosophie. Laurent. -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504212348.gf1...@coriandre.lateralis.org
Re: PPAs for Debian
On Wed, May 04, 2011 at 01:23:12AM -0400, Scott Kitterman wrote:
That depends on what you mean by 'issue'. I think exactly the issues that
concern some people in Debian about packages of 'poor quality' being
generated
in an uncontrolled PPA system are happening with regularity in Ubuntu.
Although it doesn't happen every week or anything, it's happened more often
than I can recall that someone files a bug in Ubuntu about broken PPA
packages
done by some random non-developer. I believe Debian is quite correct to be
concerned about the potential for user confusion and damage to Debian's
reputation for high quality work.
PPAs as a developer tool are one thing, PPAs as a tool for random uploads, I
think are quite another.
AOL. I think that for Project needs, PPAs accessible only to DDs + DMs
would be a good compromise to avoid random uploads. It also seems sane
in order to avoid the risk of DOS-ing buildds. It's not too constraining
either as, after all, we won't (and simply can't) block users out there
to set up their own package repositories by means other than PPA.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: PPAs for Debian
Mike Hommey, 2011-05-04 07:57:47 +0200 : [...] Add to that that allowing random people to upload packages to be built on Debian build daemons is a recipe to have the buildds compromised. My initial idea about how one would go about implementing them involved very strict isolation of the builds (either with LXC or a more heavy-handed virtualisation system). Not going to be very efficient in the slow path, but the scope of a compromise would be a temporary environment that's going to be thrown away in a minute or so and never reused. Roland. -- Roland Mas Shyumiribirikku ga susunde imashyou ka ? -- Le Schmilblick en japonais -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o5bszlj@mirexpress.internal.placard.fr.eu.org
Re: Reporting same bug in different packages
Le mardi 03 mai 2011 à 18:19 +0100, Ben Hutchings a écrit : Where is your RFH bug? I’m not the maintainer. I’m just one of the guys who happen to upload it when it gets too outdated. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: PPAs for Debian
Heya, Roland Mas lola...@debian.org writes: Mike Hommey, 2011-05-04 07:57:47 +0200: Add to that that allowing random people to upload packages to be built on Debian build daemons is a recipe to have the buildds compromised. My initial idea about how one would go about implementing them involved very strict isolation of the builds (either with LXC or a more heavy-handed virtualisation system). Not going to be very efficient in the slow path, but the scope of a compromise would be a temporary environment that's going to be thrown away in a minute or so and never reused. If anyone would have actually read the PPA proposal, they would know that uploads were and are intended to be restricted to DDs and DMs (which can break buildds anyway, if they want) and building should happen in throw-away chroots (not for security, but don't mess with my system reasons). Marc pgpA4XuJtzDNF.pgp Description: PGP signature
Re: PPAs for Debian
On 4 May 2011 15:23, Scott Kitterman deb...@kitterman.com wrote: That depends on what you mean by 'issue'. I think exactly the issues that concern some people in Debian about packages of 'poor quality' being generated in an uncontrolled PPA system are happening with regularity in Ubuntu. Although it doesn't happen every week or anything, it's happened more often than I can recall that someone files a bug in Ubuntu about broken PPA packages done by some random non-developer. I believe Debian is quite correct to be concerned about the potential for user confusion and damage to Debian's reputation for high quality work. I don't personally see this as an issue, I think it is clear that Ubuntu hosted PPAs are not controlled by Ubuntu, and as such the quality may vary widely. If you don't trust the person making the archive, don't use it. If the files look seriously old, don't use it. As for bug reports, being filled at at the wrong place, this will always be an issue with or without the PPAs. Also I believe anybody can already get an account and upload files to alioth - I don't believe we have a problem with poor quality files being uploaded by random developers. Or if this is an issue, maybe we should restrict alioth to developers only too? I personally use my Ubuntu PPA for my Django based libraries; I don't think it is reasonable to put every Django application/library I develop immediately in Debian main, but this does not imply that the quality is lacking in these packages. It makes sense to have a central system everyone can use, manually setting up private repositories that support automatic uploads, autobuilding, etc, is a reasonably complicated task, using time that could be better spent on improving the quality of the packages. -- Brian May br...@microcomaustralia.com.au
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote: On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote: Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518 which is fixed (sort of) by commit 0354e355 (2011-04-01). Oh my word. So glibc 2.13 breaks random binaries that happened to incorrectly use memcpy() instead of memmove()? memcpy() has fat warnings about the areas not overlapping, and that's the very purpose of that function: a memmove() that is faster but less safe. What's wrong with the glibc developers (and Ulrich Drepper in particular)? Nothing wrong, it is exactly the same as new compilers breaking behaviour forbidden by the standard that used to work before. The only problem is the breakage happening rarely, and thus being able to survive for long. I'm with Linus on this: let's just revert to the old behaviour. A tiny amount of clock cycles saved isn't worth the instability. I'd instead propose to sacrifice a tiny amount of cycles to check for overlapping and abort()ing so buggy code can be fixed. Random instability is the worst kind of error, a clean crash is easy to fix. Heck, we can even make a change just before wheezy is frozen to make it call memmove() when a breakage is detected. Just please don't paper over the bugs until then. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Bug#598406: ITP: vavoom -- The most advanced Doom/Heretic/Hexen/Strife source port around!
[ Cc: debian-devel-ga...@lists.debian.org FYI ] On Tue, Sep 28, 2010 at 04:14:11PM -0300, gustavo panizzo wrote: Package: wnpp Severity: wishlist Owner: gustavo panizzo g...@zumbi.com.ar * Package name: vavoom Version : 1.32-1 Upstream Author : Janis Legzdinsh vav...@vavoom-engine.com * URL : http://www.vavoom-engine.com * License : GPL I think a careful licensing check will be needed, iirc. Programming Lang: C++ Description : The most advanced Doom/Heretic/Hexen/Strife source port around! Vavoom is a source port based on sources of Doom, Heretic, Hexen and a little bit from Quake. Supported platforms are Windows and Linux. Vavoom has a graphical launcher (vlaunch). game-data-packager grew heretic support very recently (deng supports it too). Hexen support is still needed. i intend to contact the games team regarding this package. That would be awesome :-) You would be very welcome and I encourage you to join the team. You can request to join the team at https://alioth.debian.org/project/request.php?group_id=30862 The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/v/vavoom/vavoom_1.32-1.dsc I'll try to take a look at it over the next week. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504085759.ga1...@deckard.alcopop.org
Re: Reporting same bug in different packages
schrieb Josselin Mouette am 2011-05-03 17:22: Le mardi 03 mai 2011 à 15:56 +0200, Patrick Strasser a écrit : Congratulations, you have added yet another bug on the pile that no one ever reads, since there are no real maintainers for poppler. Now that's really bad. Alternatives? Reporting upstream, reporting against affected packages? Asking someone with PDF knowledge to have a look at it? Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at student dot tugraz dot at Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ipr500$okl$1...@dough.gmane.org
Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off.
Package: general Severity: normal Even if through gnome-screensaver-preferences and gnome-power-preference I disable the screensaver and the automatic turning off of the monitor, when I'm away the monitor became blank and black. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504091116.3125.22239.report...@a.gmsa
Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off.
reassign 625538 gnome thanks On Mittwoch, 4. Mai 2011, Alessandro Sardone wrote: Package: general Severity: normal Even if through gnome-screensaver-preferences and gnome-power-preference I disable the screensaver and the automatic turning off of the monitor, when I'm away the monitor became blank and black. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105041116.26614.hol...@layer-acht.org
Re: PPAs for Debian
Marc 'HE' Brockschmidt, 2011-05-04 10:42:31 +0200 : Heya, Roland Mas lola...@debian.org writes: Mike Hommey, 2011-05-04 07:57:47 +0200: Add to that that allowing random people to upload packages to be built on Debian build daemons is a recipe to have the buildds compromised. My initial idea about how one would go about implementing them involved very strict isolation of the builds (either with LXC or a more heavy-handed virtualisation system). Not going to be very efficient in the slow path, but the scope of a compromise would be a temporary environment that's going to be thrown away in a minute or so and never reused. If anyone would have actually read the PPA proposal, they would know that uploads were and are intended to be restricted to DDs and DMs (which can break buildds anyway, if they want) and building should happen in throw-away chroots (not for security, but don't mess with my system reasons). Oh, we're in full agreement, no question about that :-) I'm sorry I didn't read the proposal, I was only trying to debunk a misapprehension (and, possibly, nudge implementers into a way that would be helpful in a more general case than the Debian PPA, such as… other users of FusionForge, for instance. My view is that PPAs should be handled as a particular case of a more general architecture for continuous integration (or autobuilding) in the forge. My point of view is biased, but I'm pretty sure we could find other use cases for builds *besides* packages. Customized CD images, possibly, or datasets or tdebs or whatnot. Roland. -- Roland Mas Sauvez un arbre, tuez un castor. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei4estit@mirexpress.internal.placard.fr.eu.org
Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off.
reassign 625538 gnome-power-manager merge 370692 625538 thanks This is a known bug in gnome-power-manager. Regards, Roger On Wed, May 04, 2011 at 11:16:25AM +0200, Holger Levsen wrote: reassign 625538 gnome thanks On Mittwoch, 4. Mai 2011, Alessandro Sardone wrote: Package: general Severity: normal Even if through gnome-screensaver-preferences and gnome-power-preference I disable the screensaver and the automatic turning off of the monitor, when I'm away the monitor became blank and black. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105041116.26614.hol...@layer-acht.org -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: glibc: causes segfault in Xorg
On Wed, 04 May 2011, Adam Borowski wrote: I'd instead propose to sacrifice a tiny amount of cycles to check for overlapping and abort()ing so buggy code can be fixed. Random instability is the worst kind of error, a clean crash is easy to fix. Heck, we can even make a change just before wheezy is frozen to make it call memmove() when a breakage is detected. Just please don't paper over the bugs until then. While I can sympathize with this (it's what I want as a developer), it's certainly not a good idea in Debian in general: we have many derivatives taking unstable/testing at various points in time, and we also want to make testing generally usable by end-users. So it's best if you consider unstable always in production-mode by default. It's the same story than building applications/libraries with DISABLE_DEPRECATED, it's good for developers but we should not enable those in unstable/testing because we prefer not breaking packages that have not been updated yet. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504094833.gd22...@rivendell.home.ouaza.com
new experimental debdelta feature --format=unzipped
Dear all, I just uploaded into experimental a new version 0.42exp of debdelta ( you may find some binaries also in [3] ). This version adds an experimental feature : if you call 'debdelta-upgrade' with the option '--format=unzipped' , then in the recreated deb the data.tar part will not be compressed. This may speed up the 'debdelta-upgrade' + 'apt-get upgrade' process. Indeed, writing to hard disk is fast (let's say 5MB/sec, but usually much more); whereas compressing random data with 'bzip2 -9' or 'lzma -9' is much slower (let's say 2.0MB/sec and 1.5 MB/sec) ; and moreover the compressed data is then decompressed by dpkg when installing; so avoiding the compress/decompress should be a win/win (unless you run out of disk space...). Please test it and tell me what you think. (Let me mention that old deltas in the server do not support this new feature, so you may get some warnings for some days). (I also want to thank Guillem Jover for proposing this idea, in a mail in debian-dpkg@l.d.o). (In the future, we may add an even more aggressive behavior, whereby the data is directly piped from debdelta thru dpkg to the hard disk ; this would be in the spirit of [2] ; I already adapted the deltas to support this, but it needs changes in APT and in dpkg , it may be done as part of [4] ). A. [1] http://debdelta.debian.net [2] http://wiki.debian.org/SummerOfCode2010/StreamingPackageInstall [3] http://debdelta.debian.net/squeeze-backports/ [4] http://wiki.debian.org/SummerOfCode2011/AptDebdeltaIntegration signature.asc Description: OpenPGP digital signature
Re: glibc: causes segfault in Xorg
Le 04/05/2011 11:48, Raphael Hertzog a écrit : On Wed, 04 May 2011, Adam Borowski wrote: I'd instead propose to sacrifice a tiny amount of cycles to check for overlapping and abort()ing so buggy code can be fixed. Random instability is the worst kind of error, a clean crash is easy to fix. Heck, we can even make a change just before wheezy is frozen to make it call memmove() when a breakage is detected. Just please don't paper over the bugs until then. While I can sympathize with this (it's what I want as a developer), it's certainly not a good idea in Debian in general: we have many derivatives taking unstable/testing at various points in time, and we also want to make testing generally usable by end-users. So it's best if you consider unstable always in production-mode by default. So how do you plan to detect bugs if you never enable a feature? Don't answer me experimental, this is enabled in experimental for over a month, and AFAIK it is also enabled in the latest Ubuntu release. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc1281b.2030...@aurel32.net
Processed: Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off.
Processing commands for cont...@bugs.debian.org: reassign 625538 gnome-power-manager Bug #625538 [general] general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off. Bug reassigned from package 'general' to 'gnome-power-manager'. merge 370692 625538 Bug#370692: gnome-power-manager: DPMS Power Saving States Not Activated Bug#625538: general: Monitor turns off even if in gnome-screensaver and gnome-power i disalbe automatic turning off. Merged 370692 625538. thanks Stopping processing here. Please contact me if you need assistance. -- 370692: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370692 625538: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625538 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.1304504168535.transcr...@bugs.debian.org
Re: glibc: causes segfault in Xorg
Steve M. Robbins st...@sumost.ca wrote: Hi, I'm with Linus on this: let's just revert to the old behaviour. A tiny amount of clock cycles saved isn't worth the instability. Tiny amount?! The optimized memcpy() variants that break shitty code bring a 4 to 5x speedup on the processors they've been written for! JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3jyn4gx@sonic.technologeek.org
Re: time based freezes
On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote: On 2011-04-24, Stefano Zacchiroli lea...@debian.org wrote: Dear Release Team ... good luck in proposing a freeze month now :-) I would propose mid september or mid-march. That's just after 2nd patch release of new set of releases by KDE. And why not new gnome release, or maybe new kernel version or even any other program packaged I think that, the best choice is to follow a time based release content definition which may be described by the following procedure. 1) Release team calls for a release content with a target date +/- 3 month. 2) DD answer each with his road map (bugs, new upstream releases, ...) which should fit in for the date, within a month from the call date. 3) Release team, compiling the information, fills bugs for new feature and tag bugs for the next release. 4) DD confirm/infirm the tags within 1 month 5) Release team fixes the freeze date BTW, if the freeze happens on a separate copy of testing (let's say frozen), it will be great. Uploads should target frozen, be built into it (not into unstable). Only bug fixes are allowed on it. Cheers, signature.asc Description: This is a digitally signed message part
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
Steve Langasek vor...@debian.org writes: On Mon, May 02, 2011 at 06:09:17PM +0200, Goswin von Brederlow wrote: Also the libc6-msp430-dev:all and libc6-dev:msp430 packages will both be using /usr/inlcude/msp430 triplet/ and already trigger the problem you fear. No, libc6-msp430-dev would use /usr/triplet/include as it does today. mrvn@book:~% less /var/lib/dpkg/info/libc6-dev-i386.list | grep include /usr/include /usr/include/gnu /usr/include/gnu/stubs-32.h /usr/include/i486-linux-gnu /usr/include/sys /usr/include/sys/vm86.h /usr/include/sys/elf.h Aparently not. But maybe that is just the biarch packages. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxj2bvf4.fsf@frosties.localnet
Re: Debian rolling: tentative summary
Josselin Mouette josselin.moue...@ens-lyon.org writes: Le lundi 02 mai 2011 à 19:31 +0200, Goswin von Brederlow a écrit : To those users that want newer software my next question would be What software?. My feeling there is that it is only some software, allways the same software and used for the same use case: KDE / Gnome / Multimedia stuff for the Desktop. Looking at the other group, those that cherish the slow release cycles and excelent stability and security support, shows a a large bias towards servers that are either completly headless or where people don't care about the latest sparkly desktop hype. They need to run and keep running without having to upgrade them every 6 month. If my impression is right then maybe there is something to say for having a desktop and a server flavour like other distributions. It would be wastefull to have a rolling release with all sources included if the users only need a subset. The desktop users only want the new sparkly KDE / Gnome / Multimedia stuff. They do not care about the latest coreutils or latest postgresql. Iâve seen such arguments to split the distribution between desktop and server components many times, but I still donât buy them. First of all, the line is very hard to draw. The desktop requires server components (for example Apache binaries), and some daemons require desktop components (like Glib). Where do you put a GUI to configure iptables? or the necessary components to make remote desktops? Which is why I don't want to completly split, as in not have the server packages available in the desktop distribution. The way I imagine the sparkly releases would contain a full package set or you would have deb http://ftp.debian.org/debian stable main deb http://ftp.debian.org/debian sparkly main In both cases the desktop distribution would still have an apache and postgresql and all that. Just not bleeding edge versions of those. For the other way around, servers needing desktop components, the components would still be there in the full release. The sparkly release might have a newer version of libs but they must already be compatible or have a new SONAME. So I would think there wouldn't be any (or at least not many) problematic links between desktop and server parts. If you want to make a distinction between users, make it between those who want stable things maintained in the long term and those who want always the latest stuff. But there are desktop users in the former category and web applications developers in the latter. So maybe throw away the lables like desktop and server and let the sparkly release grow naturally. Lets start with an empty package set and add packages that need a newer version. When there is a new KDE version between stable releases then KDE can be added to sparkly. When there is a new must have apache version then that can be added. There would have to be some guidelines for when to add something and probably some nice big flame wars. It would be something inbetween stable and volatile. But I think with just a minimum of restrained on when to add a new version the sparkly release would be a much smaller set of packages than a full release and respectively less work to pull off. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iptqbuta.fsf@frosties.localnet
Re: glibc: causes segfault in Xorg
Adam Borowski kilob...@angband.pl writes: On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote: I'm with Linus on this: let's just revert to the old behaviour. A tiny amount of clock cycles saved isn't worth the instability. I'd instead propose to sacrifice a tiny amount of cycles to check for overlapping and abort()ing so buggy code can be fixed. Random instability is the worst kind of error, a clean crash is easy to fix. Heck, we can even make a change just before wheezy is frozen to make it call memmove() when a breakage is detected. Just please don't paper over the bugs until then. +1. Maybe do this in 2 steps: 1) give a warning on stderr, 2) abort. If even gcc fails (see other mail in this thread) then aborting when we don't need to doesn't seem like a good option. Or have a env var to disable the abort() so one can work around it. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei4ebuc8.fsf@frosties.localnet
Re: Integrating aptosid?
On Tue, May 03, 2011 at 05:32:41PM -0400, Yaroslav Halchenko wrote: On Tue, 03 May 2011, Alessandro Ghedini wrote: Or am I missing some substantial design issue which is still lacking from http://wiki.debian.org/Derivatives/Guidelines Sounds like the Debian Pure Blends [0] [1], with the difference that they seem to use tasks instead of metapackages if I understood it correclty. tasks are used to create the metapackages ;) Exactly (just uploaded metapackages for Debian Science generated from tasks files :-)). blends are indeed very very related indeed. Historically though they became of wider scope and deeper coverage, than I think many of the derivatives, which are often just customized package selection + design + custom installer/live-media. The reasons why Blends have a focus on a certain workfield is that there was simply no intend to generate a Debian derivative (the idea was just to sit inside Debian). However, I do not see a reason why the Blends concept should not be enhanced to more general customisation. That's just a question of the content where you let the techniques (as well as the conceptual ideas) work on. So, theoretically, blends mechanism could be extended to actually provide such customized installer + appearance... Yes. or may be Debian installer itself could be used out of the box to provide a selection among blends and their tasks and even within the tasks, because some tasks cover too much of the software instances, not reasonable to have pre-installed them all at once. I'm for a long time in preference of this but that's a different topic. But altogether the point is that indeed, it would be nice we somehow we could bring derivatives communities closer to Debian so they do not loose their originality/projects but infuse their work into Debian meanwhile. On Debian Med list we try to teach derivatives with the same focus as Debian Med to use our Blends techniques (which also work for derivatives as well). Kind regards Andreas. PS: Yaroslav, it was nice to read that you share the same dream (expressed in your previous mail) as me. :-) -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504111624.ga...@an3as.eu
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote: Steve M. Robbins st...@sumost.ca wrote: Hi, I'm with Linus on this: let's just revert to the old behaviour. A tiny amount of clock cycles saved isn't worth the instability. Tiny amount?! The optimized memcpy() variants that break shitty code bring a 4 to 5x speedup on the processors they've been written for! And furthermore, even if Debian chooses to fix this, upstreams will be forced to eventually cater to the default glibc behavior for every other libc distro out there that does not have their own fix (and non-libc OS's where this behavior already exists), so gains would be potentially limited. That said, regressions do suck, especially when they take the form of heisenbugs. But one could easily hack something LD_PRELOAD'able check for stuff like this without forcing a global change. my 0.02 $LC_MONETARY anyway, sean -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504113415.gb2...@cobija.connexer.com
Re: Qt3 looking for adopters
You miss qucs for instance. I suppose qt3 is near bug free ? Could help to maintain but in team Bastien On Sun, May 1, 2011 at 7:56 PM, Ana Guerrero a...@debian.org wrote: Hi, kdelibs3 was removed recently from the archive and the last tiny bit of KDE 3 remaining, aRts, will be removed quite soon. This means the KDE team is not longer interested in Qt3 and we are looking for new maintainer(s). Personally, I would have gone for removing Qt3 too but the following concerns have been raised: - latest LSB 4.1 still needs Qt3 - some software using Qt3 do not have any replacement (twinkle has mentioned for several users). There is a list of packages using Qt 3 at [1] and even if Qt3 is kept in the archive, I am planning to do a QA round of all the packages using Qt3. - there seem to be a lot of people using their Qt 3 software and Debian in scientific environments. Qt 3 was EOL'ed in July 2007 [2], so if you decide to adopt Qt 3 you won't have any support by upstream. Also, if you adopt the package, please coordinate with the KDE team so we can push some final changes. If there are no adopters in the next 3 weeks, I will do an orphaning upload (and file the O: bug) with the changes mentioned earlier. Ana PS: cc'me in replies [1] http://wiki.debian.org/qt3-x11-freeRemoval [2] http://qt.nokia.com/about/news/archive/press.2007-01-22.4604809587/) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=0qbMZi1hwt=mh3qy59pzn2dw...@mail.gmail.com
Re: Qt3 looking for adopters
On Sun, May 1, 2011 at 7:56 PM, Ana Guerrero a...@debian.org wrote: Hi, kdelibs3 was removed recently from the archive and the last tiny bit of KDE 3 remaining, aRts, will be removed quite soon. This means the KDE team is not longer interested in Qt3 and we are looking for new maintainer(s). Personally, I would have gone for removing Qt3 too but the following concerns have been raised: - latest LSB 4.1 still needs Qt3 - some software using Qt3 do not have any replacement (twinkle has mentioned for several users). There is a list of packages using Qt 3 at [1] and even if Qt3 is kept in the archive, I am planning to do a QA round of all the packages using Qt3. - there seem to be a lot of people using their Qt 3 software and Debian in scientific environments. Qt 3 was EOL'ed in July 2007 [2], so if you decide to adopt Qt 3 you won't have any support by upstream. Also, if you adopt the package, please coordinate with the KDE team so we can push some final changes. On Wed, May 04, 2011 at 01:29:39PM +0200, Bastien ROUCARIES wrote: You miss qucs for instance. I did not mean to be exhaustive. All the packages using Qt3 have at least one person who consider them important or they would not be in the archive. I suppose qt3 is near bug free ? It has 21 bugs. The important point here is you would become also *upstream*. Could help to maintain but in team There are plenty of one-person teams in Debian :-) Ana -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504115546.ga11...@pryan.ekaia.org
Re: glibc: causes segfault in Xorg
On Wed, 04 May 2011, Aurelien Jarno wrote: Le 04/05/2011 11:48, Raphael Hertzog a écrit : So it's best if you consider unstable always in production-mode by default. So how do you plan to detect bugs if you never enable a feature? Really abort()ing is not a nice behaviour, it would be way better to print a warning and fallback to a correct behaviour. Users can then report the problems without experiencing a non working-application. When something like this is not possible, I'm afraid Debian unstable is not a good place to experiment... I know this answer is not entirely satisfactory but the truth is there are other distributions which follow another developement model that are better suited to experiment such things, for example Fedora. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504120641.gb23...@rivendell.home.ouaza.com
Re: glibc: causes segfault in Xorg
Le 04/05/2011 14:06, Raphael Hertzog a écrit : a nice behaviour, it would be way better to print a warning and fallback to a correct behaviour. Users can then report the problems without experiencing a non working-application. Printing a warning on a thing that is potentially used everywhere, especially in scripts is not a good idea. It will simply corrupt the data that the othe part of the script is waiting for, and that even on stderr, a lot of scripts are not (correctly?) designed for that. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc14537.8050...@aurel32.net
A concrete proposal for rolling implementation
Hi, during the recent discussions about rolling, a proposal was made in a blog comment, and after giving it some quick thoughts, most people I’ve talked with seem to think it is a good idea, so it’s time for it to be discussed at large. It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. The idea is to make this process automatic. Let me elaborate. The new “rolling” suite --- This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up packages from unstable. Typically it would be generated from an override file that looks like: source-package version xserver-xorg-video-ati 1.2.3-4 ... The rolling suite would try to have a package that has *at least* this version. If it is found in testing, the package is removed from rolling. If otherwise it is found in unstable, the package is picked from unstable. This way, when something is broken in testing and cannot be unbroken quickly, a maintainer who notices it could add (or make the people in charge add) the necessary packages to the override file. If, for a reason or another, an important bug fix or a security update doesn’t propagate to testing quickly enough, you can now just add it and the necessary dependencies to rolling, and people using it aren’t affected. Whenever the affected packages finally migrate to testing, the discrepancy between rolling and testing automatically disappears. The reason for the “at least” version rule is that new uploads to unstable are supposed to fix the situation in testing anyway. I don’t think we should keep in rolling packages that are no longer in unstable. A concrete example -- Let’s imagine something that might happen soon (although of course we will try hard for it not to happen): a new version of nautilus migrates to testing, but it was missing a Breaks - it doesn’t work with the version of gnome-settings-daemon in testing. The new gnome-settings-daemon in unstable works, but it won’t migrate because there is a libgnomekbd transition in progress, and gnome-screensaver which is part of the transition doesn’t build on s390. In this case, we can just add libgnomekbd and gnome-settings-daemon to the override file. Users of the rolling suite will have the two versions of libgnomekbd available, and they can update their systems to a working state. Why I like it - First of all, this idea doesn’t affect *at all* the current release process. It just takes people willing to maintain the override file - and we could even choose to let any DD modify it. And it’s much faster to modify such a file than telling every user from testing that they have to upgrade to the unstable version. And just as importantly, I think it should just work. There’s very little chance that people get completely hosed systems like it happens sometimes for unstable. There are all chances that something broken in testing can be fixed by pulling a handful of packages from unstable. What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Again, no disruption: people can keep on breaking some pieces of experimental, but if they want some other pieces to be useful for rolling users, they just need to be committed to more carefulness and to add them to the override file. What do you think? -- Joss -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304511852.9090.85.camel@pi0307572
Re: glibc: causes segfault in Xorg
Le 04/05/2011 07:42, Steve M. Robbins a écrit : On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote: Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518 which is fixed (sort of) by commit 0354e355 (2011-04-01). Oh my word. So glibc 2.13 breaks random binaries that happened to incorrectly use memcpy() instead of memmove()? What's wrong with the glibc developers (and Ulrich Drepper in particular)? I'm with Linus on this: let's just revert to the old behaviour. A tiny amount of clock cycles saved isn't worth the instability. Thanks, -Steve P.S. I tried rebuilding glibc myself locally, but gcc also segfaults in the process :-( Are you sure it is something related? Which gcc version are you using? Do you have a backtrace point to the same issue? I am using this libc version for two months (on a CPU having ssse3 instruction set), it is also used by other distributions, so I find strange it breaks something so common than gcc. For XOrg it can be due to the difference in configuration, that's why the problem stayed unnoticed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc146eb.9000...@aurel32.net
Re: glibc: causes segfault in Xorg
Le mercredi 04 mai 2011 14:23:19, Aurelien Jarno a écrit : Le 04/05/2011 14:06, Raphael Hertzog a écrit : a nice behaviour, it would be way better to print a warning and fallback to a correct behaviour. Users can then report the problems without experiencing a non working-application. Printing a warning on a thing that is potentially used everywhere, especially in scripts is not a good idea. It will simply corrupt the data that the othe part of the script is waiting for, and that even on stderr, a lot of scripts are not (correctly?) designed for that. Is there a usertag to track the memcpy bugs? Regards. signature.asc Description: This is a digitally signed message part.
Re: time based freezes
[Abou Al Montacir, 2011-05-04] On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote: On 2011-04-24, Stefano Zacchiroli lea...@debian.org wrote: Dear Release Team ... good luck in proposing a freeze month now :-) I would propose mid september or mid-march. That's just after 2nd patch release of new set of releases by KDE. And why not new gnome release, or maybe new kernel version or even any other program packaged because I'm too lazy to send 42 mails¹ every 2 years, specially when some of recipients might start ignoring them after receiving two with different dates and most other upstreams will not get such mails at all. You can pick the release date of your favourite $foo package with popcon=0, I really don't care as long as we can put Debian freezes on $month every $parity year on http://www.debian.org/ and not change it for next decade or so. Upstream authors that care about Debian, will try to release new stable version on time, the ones that don't will just do what they do now and we'll deal with it the same way we handle it now. [¹] even if created as 1 mail with 41 addresses in CC ;-P -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504131453.gl17...@piotro.eu
Re: A concrete proposal for rolling implementation
[Josselin Mouette, 2011-05-04] This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. +1 [...] What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. I'm not interested in helping f.e. with Perl bugs so once the ones I care about are fixed, I just want to focus on Sid (i.e. upload new upstream versions, prepare new transitions etc.) - I can wait a month or two, but these long freezes demotivate me a lot. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504132207.gm17...@piotro.eu
Re: A concrete proposal for rolling implementation
Piotr Ożarowski wrote: [Josselin Mouette, 2011-05-04] This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. +1 [...] What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. I'm not interested in helping f.e. with Perl bugs so once the ones I care about are fixed, I just want to focus on Sid (i.e. upload new upstream versions, prepare new transitions etc.) - I can wait a month or two, but these long freezes demotivate me a lot. While I agree with the demotivation stance, why can't those packages be uploaded to experimental, fwiw ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/iprk5f$hgt$1...@dough.gmane.org
Re: A concrete proposal for rolling implementation
Hi, I came to the same conclusion than you after the discussion we had in the comments of your article. I think it's the right approach. I still have a few comments though. On Wed, 04 May 2011, Josselin Mouette wrote: It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. I think you meant what's broken in testing (i.e. you take a few selected packages from unstable to fix bugs present in testing). This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. It doesn't need to be a pseudo-suite. It's a collection of packages taken in testing or unstable, it's not more complicated to make it a full suite. And PR-wise, it's way better to avoid testing appearing in the sources.list. Also it means that the day where we have improved our processes in unstable/testing so that rolling is no longer necessary, we can simply merge testing and rolling in a single suite. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up Why powerpc? If we really take more than i386/amd64 for rolling, there are more users of armel than of powerpc. packages from unstable. Typically it would be generated from an override file that looks like: source-package version xserver-xorg-video-ati 1.2.3-4 ... The rolling suite would try to have a package that has *at least* this version. If it is found in testing, the package is removed from rolling. If otherwise it is found in unstable, the package is picked from unstable. You still need some sort of britney to verify that the package is effectively installable in rolling, and to verify you're not breaking installability of other packages available in rolling. But yes the basic principle is to stay as close to testing as possible, to get as much as possible fixed via testing (in particular when it's possible to fix via an updated version pushed through t-p-u) and for the rest to cherry-pick some updates from unstable. Once we diverged from testing, there's the question of what to do when the package gets updated in unstable. By default the answer is nothing unless the updated package fix a RC bug that is not present in testing but that was introduced since then (and is now present in the rolling version). Why I like it - First of all, this idea doesn’t affect *at all* the current release process. It just takes people willing to maintain the override file - and we could even choose to let any DD modify it. And it’s much faster to modify such a file than telling every user from testing that they have to upgrade to the unstable version. I don't believe in the let any DD modify it but there should be a simple way for DD to evaluate and submit such requests of integration into rolling. And just as importantly, I think it should just work. There’s very little chance that people get completely hosed systems like it happens sometimes for unstable. There are all chances that something broken in testing can be fixed by pulling a handful of packages from unstable. I agree with this. There might some corner-cases where we might require direct uploads into rolling but if we stick to i386/amd64, it's easy enough to do even without specific support on the buildd side. What to do during freezes - I leave that aside for now. Your proposal covers the need to push newer upstream versions to users but doesn't respond to the desire of developers to continue development. But it's really another discussion so I prefer to not discuss it in that thread. What do you think? +1 from me. Thank you for the proposal! Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504133040.gb24...@rivendell.home.ouaza.com
Re: A concrete proposal for rolling implementation
[Didier Raboud, 2011-05-04] While I agree with the demotivation stance, why can't those packages be uploaded to experimental, fwiw ? because that's not what experimental is for and it's harder to use it (did you notice that python3.2 is in experimental or did someone gave you proper apt-pinning rule when Squeeze was frozen?) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504133210.gn17...@piotro.eu
AutoNotify: Returned mail: Data format error
Message [o91db421774654d4eaeccd1845b56aa3d.pro] triggered rule [Anti-Virus Malware Scanning (1)] at 4:04:20 PM 5/4/2011 Sender: debian-devel@lists.debian.org Recipient(s): mhan...@shb.com.sa Subject: Returned mail: Data format error
Re: A concrete proposal for rolling implementation
Le mercredi 04 mai 2011 à 15:30 +0200, Raphael Hertzog a écrit : On Wed, 04 May 2011, Josselin Mouette wrote: It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. I think you meant what's broken in testing (i.e. you take a few selected packages from unstable to fix bugs present in testing). Yes, of course. It doesn't need to be a pseudo-suite. It's a collection of packages taken in testing or unstable, it's not more complicated to make it a full suite. It cannot be “just” a full suite. When you add a package coming from unstable, you must also keep the version that is already in testing. To follow on my example, if you allow libgnomekbd and gnome-settings-daemon from unstable, you still need libgnomekbd from testing, otherwise other packages will become uninstallable. And PR-wise, it's way better to avoid testing appearing in the sources.list. That’s really an implementation detail. If you really want to hide it, you just need to ensure rolling can have two versions of the same sources at the same time. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up Why powerpc? If we really take more than i386/amd64 for rolling, there are more users of armel than of powerpc. Yes, sure. It was just an example. You still need some sort of britney to verify that the package is effectively installable in rolling, and to verify you're not breaking installability of other packages available in rolling. If rolling is just an overlay on testing, I don’t think that’s necessary. The worst that could happen is that the version in rolling is uninstallable, but the version in testing would still be. What the britney-like thing could do is bring automatically all dependencies that are actually necessary for the package to be installable. But this could also make things more complicated, since britney tests source packages, not binaries. You might bring a source in rolling only for a runtime that is needed, but the development header being uninstallable is not a problem. Britney would prevent that, while it would still be a good move. Once we diverged from testing, there's the question of what to do when the package gets updated in unstable. By default the answer is nothing unless the updated package fix a RC bug that is not present in testing but that was introduced since then (and is now present in the rolling version). I’m not entirely sure, but I think it’s better to pick the update from unstable instead of letting in rolling a package that is no longer available somewhere else. It should make upgrades smoother, and it should also be less work for maintainers, since it avoids having another version from which problems can arise. -- Joss -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304516627.9090.154.camel@pi0307572
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote: While I can sympathize with this (it's what I want as a developer), it's certainly not a good idea in Debian in general: we have many derivatives taking unstable/testing at various points in time, and we also want to make testing generally usable by end-users. So it's best if you consider unstable always in production-mode by default. I disagree with this. We expect *our* users of sid to use things like apt-listbugs and to be wary of blindly upgrading. I think we should hold downstream distributions to higher standards. If a downstream distribution blindly accepts a libc from sid and it doesn't do what they want, imho that's their fault. Especially with a core package. I'm concerned that this attitude, if adopted elsewhere, would paralyze Debian development, for fear of inconveniencing other distributions. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504135835.gb4...@deckard.alcopop.org
Re: glibc: causes segfault in Xorg
Aurelien Jarno aurel...@aurel32.net writes: Le 04/05/2011 14:06, Raphael Hertzog a écrit : a nice behaviour, it would be way better to print a warning and fallback to a correct behaviour. Users can then report the problems without experiencing a non working-application. Printing a warning on a thing that is potentially used everywhere, especially in scripts is not a good idea. It will simply corrupt the data that the othe part of the script is waiting for, and that even on stderr, a lot of scripts are not (correctly?) designed for that. I don't see how this is different from the error reporting on duplicate free or memory list corruptions. So printing a warning does break a few bad scripts. Aborting will also break them, but it will break all the clean scripts and normal use cases too. While not ideal I think I would prefer a error over aborting at least for the time being. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc3ia7ja.fsf@frosties.localnet
Re: glibc: causes segfault in Xorg
Le 04/05/2011 16:02, Goswin von Brederlow a écrit : Aurelien Jarno aurel...@aurel32.net writes: Le 04/05/2011 14:06, Raphael Hertzog a écrit : a nice behaviour, it would be way better to print a warning and fallback to a correct behaviour. Users can then report the problems without experiencing a non working-application. Printing a warning on a thing that is potentially used everywhere, especially in scripts is not a good idea. It will simply corrupt the data that the othe part of the script is waiting for, and that even on stderr, a lot of scripts are not (correctly?) designed for that. I don't see how this is different from the error reporting on duplicate free or memory list corruptions. So printing a warning does break a few Duplicate free or memory prints an error and *aborts*, so the data it's not propagated further. Printing a warning and continuing, means the data is propagated further. bad scripts. Aborting will also break them, but it will break all the clean scripts and normal use cases too. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc15e52.1070...@aurel32.net
Re: A concrete proposal for rolling implementation
On Wed, 04 May 2011, Josselin Mouette wrote: It doesn't need to be a pseudo-suite. It's a collection of packages taken in testing or unstable, it's not more complicated to make it a full suite. It cannot be “just” a full suite. When you add a package coming from unstable, you must also keep the version that is already in testing. To follow on my example, if you allow libgnomekbd and gnome-settings-daemon from unstable, you still need libgnomekbd from testing, otherwise other packages will become uninstallable. A full suite can have 2 versions of the same source package and can contain both libgnomekbd4 and libgnomekbd7. It's not a problem. And PR-wise, it's way better to avoid testing appearing in the sources.list. That’s really an implementation detail. If you really want to hide it, you just need to ensure rolling can have two versions of the same sources at the same time. OK. Testing already can, so it should be ok for rolling too. You still need some sort of britney to verify that the package is effectively installable in rolling, and to verify you're not breaking installability of other packages available in rolling. If rolling is just an overlay on testing, I don’t think that’s necessary. The worst that could happen is that the version in rolling is uninstallable, but the version in testing would still be. Yes but as long as it's uninstallable, the bug is not fixed for the user. So while we did not break anything, we did not fix anything either. :-) What the britney-like thing could do is bring automatically all dependencies that are actually necessary for the package to be installable. But this could also make things more complicated, since britney tests source packages, not binaries. You might bring a source in rolling only for a runtime that is needed, but the development header being uninstallable is not a problem. Britney would prevent that, while it would still be a good move. Yes, we could try to improve britney towards this. But I'm not sure it's a good idea to pick only some binary packages from a source package. It happens often enough that the package lack a strict dependency that might be required and picking all the binaries from a source package limits the risk of upgrading them separately (and thus experiencing the bug). Once we diverged from testing, there's the question of what to do when the package gets updated in unstable. By default the answer is nothing unless the updated package fix a RC bug that is not present in testing but that was introduced since then (and is now present in the rolling version). I’m not entirely sure, but I think it’s better to pick the update from unstable instead of letting in rolling a package that is no longer available somewhere else. It should make upgrades smoother, and it should also be less work for maintainers, since it avoids having another version from which problems can arise. In that case, those updates should follow the same rules than for testing itself. It would be unreasonable to accept the new unstable upload immediately. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504142011.ge24...@rivendell.home.ouaza.com
Re: A concrete proposal for rolling implementation
Josselin Mouette j...@debian.org writes: This way, when something is broken in testing and cannot be unbroken quickly, a maintainer who notices it could add (or make the people in charge add) the necessary packages to the override file. If, for a reason or another, an important bug fix or a security update doesnât propagate to testing quickly enough, you can now just add it and the necessary dependencies to rolling, and people using it arenât affected. Whenever the affected packages finally migrate to testing, the discrepancy between rolling and testing automatically disappears. That sounds like a nice idea. Maybe call it hot-fix instead of rolling. :) I would suggest one more thing though. Sometimes it is know that a package breaks on upgrade and maybe even causes data loss. But the fix might not be aparent or quick to implement. Maybe it would be nice if one could then also remove or block a package so people won't upgrade to the known bad version while the maintainer works on a fix. Note: this would prbably require a full Packages file and people to only add rolling to sources.list without also having testing. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwoua6oo.fsf@frosties.localnet
Re: Qt3 looking for adopters
On Wed, May 4, 2011 at 1:55 PM, Ana Guerrero a...@debian.org wrote: On Sun, May 1, 2011 at 7:56 PM, Ana Guerrero a...@debian.org wrote: Hi, kdelibs3 was removed recently from the archive and the last tiny bit of KDE 3 remaining, aRts, will be removed quite soon. This means the KDE team is not longer interested in Qt3 and we are looking for new maintainer(s). Personally, I would have gone for removing Qt3 too but the following concerns have been raised: - latest LSB 4.1 still needs Qt3 - some software using Qt3 do not have any replacement (twinkle has mentioned for several users). There is a list of packages using Qt 3 at [1] and even if Qt3 is kept in the archive, I am planning to do a QA round of all the packages using Qt3. - there seem to be a lot of people using their Qt 3 software and Debian in scientific environments. Qt 3 was EOL'ed in July 2007 [2], so if you decide to adopt Qt 3 you won't have any support by upstream. Also, if you adopt the package, please coordinate with the KDE team so we can push some final changes. On Wed, May 04, 2011 at 01:29:39PM +0200, Bastien ROUCARIES wrote: You miss qucs for instance. I did not mean to be exhaustive. All the packages using Qt3 have at least one person who consider them important or they would not be in the archive. I suppose qt3 is near bug free ? It has 21 bugs. The important point here is you would become also *upstream*. No they are trinirty qt3 :) Could you offer me sponsorship ? Bastien Could help to maintain but in team There are plenty of one-person teams in Debian :-) Ana -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktin4pqfejf102rwehdummbojdp9...@mail.gmail.com
Re: A concrete proposal for rolling implementation
Piotr Ożarowski dijo [Wed, May 04, 2011 at 03:22:07PM +0200]: [Josselin Mouette, 2011-05-04] This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. +1 I'll also state it: Josselin's proposal looks very interesting, simple and compatible with what we have now! [...] What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. I'm not interested in helping f.e. with Perl bugs so once the ones I care about are fixed, I just want to focus on Sid (i.e. upload new upstream versions, prepare new transitions etc.) - I can wait a month or two, but these long freezes demotivate me a lot. For many bugs, it's not only that I'm not interested, but I'm also disqualified. Of course, a long freeze can be demotivating, and it can also cause a spike of work when we reopen unstable for anything goes uploads. In my case, I used this last freeze to redo the packaging for one of my complex packages, and kept up-to-date with upstream via experimental - So I was breaking stuff and keeping up to date at the same time. It cannot always work like this, of course, I'm just mentioning a way to keep the fun flowing while in freeze. Now, long freezes are complicated, true. But I don't think keeping unstable disconnected from (frozen|testing) will really help us. If all uploads during the freeze have to go through t-p-u, we will lose a bit of what gives coherence to the whole system. I feel, as many others have stated, that the Squeeze release cycle was quite a successful one, even with some erupting flames here and there... Probably we should focus more on keeping the bug count lower during the non-freezing period? That should surely lead to a shorter freeze period. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504153025.gc15...@gwolf.org
Re: A concrete proposal for rolling implementation
Hi, (you already know, but let's state that on dd@ too) Josselin Mouette j...@debian.org (04/05/2011): during the recent discussions about rolling, a proposal was made in a blog comment, and after giving it some quick thoughts, most people I’ve talked with seem to think it is a good idea, so it’s time for it to be discussed at large. It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. your proposal certainly makes a lot of sense. Having to quick-fetch packages from unstable to avoid long-term breakages seems to be the major issue for prospective testing users, and “automating” (whatever the details) that pinning seems like an easy and non-disruptive (as far as the testing process is concerned -- AFAICT, IMVHO, etc.) way to fix that major usability issue. Thank you for coming with that concrete proposal. Mraw, KiBi. signature.asc Description: Digital signature
Re: PPAs for Debian
On Wed, May 04, 2011 at 08:28:00AM +0200, Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 01:23:12AM -0400, Scott Kitterman wrote: I believe Debian is quite correct to be concerned about the potential for user confusion and damage to Debian's reputation for high quality work. PPAs as a developer tool are one thing, PPAs as a tool for random uploads, I think are quite another. AOL. I think that for Project needs, PPAs accessible only to DDs + DMs Maybe we should think about not use the «PPAs» name so there will be less confusion about the kind of service being discussed, and in the long term will be less confused for users as well I recall «debhub» being used early, or maybe «DebSandBox». Cheers -- René signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, May 03, 2011 at 04:49:42PM +0200, Jan Hauke Rahm wrote: On Tue, May 03, 2011 at 01:31:24PM +0200, Pierre Habouzit wrote: On Tue, May 03, 2011 at 11:41:35AM +0200, Lucas Nussbaum wrote: It is clear from the discussion that there would be consequences. Some would be negative, some positive. I think that we have now a pretty good understanding of the possibilities and their consequences. The remaining problem is to count DDs heads in the two camps: - Let's focus on stable releases. A rolling release should not be provided officially by Debian. - Let's see what we can do about rolling, provided we find a way to do it without diminishing the quality of our stable releases. FWIW I'm in neither. My camp would be: Please do not impede our way to produce stable releases in any ways, do whatever you want with rolling. I'm sorry but I find that a lame request. If, in whatever circumstances, Debian as a project decides to care about something beyond stable releases, for instance something called rolling, it will as a matter of fact use power of the project for such new thing and thus distract that power from stable releases. Always. Saying that anyone can do anything as long as it never interferes with what we have now is exactly the definition of keeping the status-quo, i.e. preventing improvement. Granted, it also prevents breakage. Huh, no, you can do lots of stuff that don't harm releasing a Stable… I've suggested integrating aptosid (or $derivative) people inside of Debian as a way to provide rolling, I know that Joss did so on planet too e.g. That has two very important advantages: * it brings in new blood *now* (and not an hypothetical later) to actually take care of rolling (which doesn't make all my reservation moot but I reckon does lessen their scope significantly); * it brings people who know how to do that and already have infrastructure to do so. We would just give them the opportunity to benefit from the larger and robust infrastructure we have, while taking their experience. Looks like it's win-win. Have you asked *any* contributor of *any* project about why they didn't put their efforts in Debian but instead into a different project? That's not the same thing as creating ways inside of Debian to scatter resources on too many projects. That would be irrational. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504155811.gg27...@madism.org
Re: A concrete proposal for rolling implementation
Le mercredi 04 mai 2011 à 16:20 +0200, Raphael Hertzog a écrit : A full suite can have 2 versions of the same source package and can contain both libgnomekbd4 and libgnomekbd7. It's not a problem. OK, so I officially do not care a shit™. What the britney-like thing could do is bring automatically all dependencies that are actually necessary for the package to be installable. But this could also make things more complicated, since britney tests source packages, not binaries. You might bring a source in rolling only for a runtime that is needed, but the development header being uninstallable is not a problem. Britney would prevent that, while it would still be a good move. Yes, we could try to improve britney towards this. But I'm not sure it's a good idea to pick only some binary packages from a source package. It happens often enough that the package lack a strict dependency that might be required and picking all the binaries from a source package limits the risk of upgrading them separately (and thus experiencing the bug). Indeed. The appropriate result to obtain would be something like: “the list of source packages you need to pull for a given binary package to be installable”. I’m not entirely sure, but I think it’s better to pick the update from unstable instead of letting in rolling a package that is no longer available somewhere else. It should make upgrades smoother, and it should also be less work for maintainers, since it avoids having another version from which problems can arise. In that case, those updates should follow the same rules than for testing itself. It would be unreasonable to accept the new unstable upload immediately. I don’t think it would be entirely unreasonable, since we’re already in the case of a specific package we had to pull from unstable, to expect the maintainer to be careful enough. Don’t forget that we’re talking about probably a dozen of packages at a given time. Of course, having a delay before accepting the package seems sensible too, so it’s not like I really care. -- Joss -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304524993.9090.298.camel@pi0307572
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: The new “rolling” suite --- This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. This is an excellente proposal which technically can be implemented this way: - having a new britney instance, which is chained to the result of the testing britney. - it is fed with a new hint file composed of forced migrations (those are versionned), feeding the result of the testing britney with sid. - result is a new release only made of testing or unstable packages. If you find the people wanting to make up the rolling team, I think it's a few hours work to setup (and overhead on the ftp servers would just be minimal: a new suite and associated Packages files, nothing more). Doing it this way: - leverages the same tools as what we have now (britney, dak); - only uses packages either in unstable or testing, which makes rolling a glorified Pin-file hence people using rolling don't diverge from the stable release work and are actually *worthwile* bug reporters and gives more coverage on testing *excellent*. - benefits from the release work: e.g. if a package is removed from testing, since rolling is recreated from that, it inherits that (nothing prevents the rolling team to force it back for whichever reason). - allows to take snapshots of rolling on a semi-regular basis (with associated d-i releases). E.g. every 3 months or so. Those would be alphas before the freeze, and betas during the freeze. I like it a lot, I'm even finding it useful: it looks like it resolves the rolling issues for people (wrt having something like a 'Usable' testing), but doesn't really forks testing, only glorified pinning managed at the project level instead of on each other's machines. But it doesn't make those users worthless to the release team, quite the contrary. It could even turn-up to become a useful release tool. I just love that proposal. At least something technical that makes sense, thanks Joss. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504161129.gh27...@madism.org
Re: PPAs for Debian
Stefano Zacchiroli dijo [Sat, Apr 30, 2011 at 12:56:15PM +0200]: I think it would make quite sense to get something like e.g. ppa done for Debian. But thats something else than it's proposed here. Yes, absolutely. I'd even dare to say that having something like PPA for Debian is a priority. It would be yet another way to enable people to experiment with big changes in Debian, showing their value, with minimum impact on the work of others. Fully agree here. It happens that I've a recent update on this topic to share. There were some concerns about the need of something like a NEW queue for Debian's PPA, for legal reasons. I had a long phone call with SPI lawyer about this just yesterday. It turns out that there are a few provisions we should follow to stay on the safe side, but there is no specific blocker either. We can go ahead, individual maintainers will be responsible of what they upload / distribute via PPA. Here I think we would be facing two different use cases, which impose very different results: • A PPA-like can be used by a Debian-related person (DD/DM/Dwhatever), and we trust the credentials they have already presented as personal identification (so what you stated can be held) • But at least AFAICT, Canonical's PPAs allow also non-Ubuntu-related people to maintain their own repositories. That's a great way for them to start getting acquinted with the technical processes and get closer to becoming officialy affiliated. I have also seen it as a common distribution channel for independent projects. The second use case might be what I feel as most attractive - Yes, I maintain a couple of personal apt repos with things not really suitable for Debian, some of which I could move to a PPA were it available, but a non-Debianer might find it harder (and less motivating) to learn the details of setting up his repo. But we should then look into how we can ensure personal identification - Would we keep the key reachability requirement? I think it's the least we could do. If contributors cannot be identified, then I guess responsability would fall upon the project, as infrastructure providers, right? Greetings, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504163132.ge15...@gwolf.org
Re: PPAs for Debian
Paul Tagliamonte dijo [Wed, May 04, 2011 at 12:16:54AM -0400]: AFAIU, only DD and DM could create PPA and upload to them. If this is not the case, then I share your fears. Usage of the PPA system on LP requires that you agree to the usage terms (not unlike machine usage policies for Debian). We let non-MOTU upload to their own PPAs (has their name in the URL), and if nonfree (or malicious) packages are uploaded, they can have PPA rights removed. How do you ensure the identity of the uploaders? If my acount gets forbidden, what protection is there so I don't just create a new one? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504163445.gf15...@gwolf.org
Re: PPAs for Debian
Marc 'HE' Brockschmidt dijo [Wed, May 04, 2011 at 10:42:31AM +0200]: (...) If anyone would have actually read the PPA proposal, they would know that uploads were and are intended to be restricted to DDs and DMs (which can break buildds anyway, if they want) and building should happen in throw-away chroots (not for security, but don't mess with my system reasons). Oh... well, I took some time today to read through this gigantic thread (expecting erupting flames but finding very interesting discussions instead!), and had not reached this point. If Debian-PPAs are to be limited to DDs and DMs (and I'd add non-uploading DDs), my points about identifications can be perfectly ignored. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504163800.gg15...@gwolf.org
Re: PPAs for Debian
On Wednesday, May 04, 2011 12:34:45 PM Gunnar Wolf wrote: Paul Tagliamonte dijo [Wed, May 04, 2011 at 12:16:54AM -0400]: AFAIU, only DD and DM could create PPA and upload to them. If this is not the case, then I share your fears. Usage of the PPA system on LP requires that you agree to the usage terms (not unlike machine usage policies for Debian). We let non-MOTU upload to their own PPAs (has their name in the URL), and if nonfree (or malicious) packages are uploaded, they can have PPA rights removed. How do you ensure the identity of the uploaders? If my acount gets forbidden, what protection is there so I don't just create a new one? This is no protection nor any identity checks for uploaders with the Launchpad PPAs. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105041240.32799.deb...@kitterman.com
Re: A concrete proposal for rolling implementation
Hi, Josselin Mouette j...@debian.org writes: The new “rolling” suite --- This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up packages from unstable. Typically it would be generated from an override file that looks like: source-package version xserver-xorg-video-ati 1.2.3-4 I don't think this needs to be restricted to a subset of architectures when you allow rolling to pick different versions[1] for each arch. [1] including none if the required version is not available in unstable A concrete example -- Let’s imagine something that might happen soon (although of course we will try hard for it not to happen): a new version of nautilus migrates to testing, but it was missing a Breaks - it doesn’t work with the version of gnome-settings-daemon in testing. The new gnome-settings-daemon in unstable works, but it won’t migrate because there is a libgnomekbd transition in progress, and gnome-screensaver which is part of the transition doesn’t build on s390. In this case, we can just add libgnomekbd and gnome-settings-daemon to the override file. Users of the rolling suite will have the two versions of libgnomekbd available, and they can update their systems to a working state. In this case, you could add the newer version to rolling for all architectures except s390. This way all users not using s390 could already upgrade to the new version. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s2saaf2tqba@bistromathics.mathi.uni-heidelberg.de
Re: Bits from the Release Team - Kicking off Wheezy
Marc 'HE' Brockschmidt dijo [Mon, May 02, 2011 at 09:15:38AM +0200]: I understand members of the release team feel particularly responsible to do various release-critical tasks that should have been done by the maintainers but haven't (for various reasons). And I guess that's the reason of your remark. But that's not scalable ultimately. So I think it's a good move to say we support testing and we expect every maintainer to take care of their packages there (as opposed to the current situation where too much of that work is left in the hands of the release team). Saying that will not make people do it. We have also said that we will fix bugs in a frozen testing distribution, but that doesn't mean that everyone does it. Raphael, just announcing that something should be done doesn't get stuff done. FWIW... Splitting developers' focus this way does not only mean some of us are bound to ignore rolling (as we care about stable), but the opposite - Some of us will ignore stable (as we package stuff that caters better to rolling). Of course, some packages could be hinted never to enter stable, or stuff like that... But I do feel that, although I overall like the rolling proposal, it is bound to dillute attention and, therefore, overall QA. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504165042.ga16...@gwolf.org
Bug#625636: ITP: mccs -- multi-critera CUDF solver
Package: wnpp Severity: wishlist Owner: Ralf Treinen trei...@debian.org * Package name: mccs Version : 1.0 Upstream Author : Claude Michel c...@polytech.unice.fr * URL : http://users.polytech.unice.fr/~cpjm/misc/mccs.html * License : BSD Programming Lang: C Description : multi-critera CUDF solver mccs is a solver for package dependencies expressed in the CUDF format. It takes as input a CUDF problem and computes the best solution according to a combination of optimization criteria chosen by the user. Basic criteria to be maximized or minimized may be selected from a list of pre-defined criteria, and these can be combined using using various aggregation operators. It relies on an Integer Programming solver or a Pseudo Boolean solver to achieve its task. The version of mccs distributed with this package uses cbc as underlying solving engine, however, mccs may also be used together with other solvers like Cplex, Gurobi, Lpsolver, Glpk, SCIP or WBO. -Ralf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504181402.7218.70420.report...@seneca.free.fr
Re: glibc: causes segfault in Xorg
Jon Dowland j...@debian.org writes: On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote: While I can sympathize with this (it's what I want as a developer), it's certainly not a good idea in Debian in general: we have many derivatives taking unstable/testing at various points in time, and we also want to make testing generally usable by end-users. I don't think mixing unstable and testing here as if they're the same thing is warranted. If we get common crashes, that's going to become an RC bug fairly quickly, and won't be propagated to testing. So it's best if you consider unstable always in production-mode by default. I disagree with this. We expect *our* users of sid to use things like apt-listbugs and to be wary of blindly upgrading. I think we should hold downstream distributions to higher standards. If a downstream distribution blindly accepts a libc from sid and it doesn't do what they want, imho that's their fault. Especially with a core package. I'm concerned that this attitude, if adopted elsewhere, would paralyze Debian development, for fear of inconveniencing other distributions. +1 unstable is exactly the place to check this sort of thing, IMO. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwougrow@windlord.stanford.edu
Re: A concrete proposal for rolling implementation
On 04/05/11 at 14:24 +0200, Josselin Mouette wrote: Hi, during the recent discussions about rolling, a proposal was made in a blog comment, and after giving it some quick thoughts, most people I’ve talked with seem to think it is a good idea, so it’s time for it to be discussed at large. It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. The idea is to make this process automatic. Let me elaborate. The new “rolling” suite --- This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up packages from unstable. Typically it would be generated from an override file that looks like: source-package version xserver-xorg-video-ati 1.2.3-4 ... The rolling suite would try to have a package that has *at least* this version. If it is found in testing, the package is removed from rolling. If otherwise it is found in unstable, the package is picked from unstable. This way, when something is broken in testing and cannot be unbroken quickly, a maintainer who notices it could add (or make the people in charge add) the necessary packages to the override file. If, for a reason or another, an important bug fix or a security update doesn’t propagate to testing quickly enough, you can now just add it and the necessary dependencies to rolling, and people using it aren’t affected. Whenever the affected packages finally migrate to testing, the discrepancy between rolling and testing automatically disappears. The reason for the “at least” version rule is that new uploads to unstable are supposed to fix the situation in testing anyway. I don’t think we should keep in rolling packages that are no longer in unstable. While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504201222.ga31...@xanadu.blop.info
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 03:30:40PM +0200, Raphael Hertzog wrote:
On Wed, 04 May 2011, Josselin Mouette wrote:
It starts from the following fact: if you want a testing system that
works correctly, you usually have to add APT lines for unstable, while
pinning them to only install specific packages you need to unbreak
what’s broken in unstable.
Thanks for the proposal, it looks really interesting!
A few comments and some potential help/directions are below.
It doesn't need to be a pseudo-suite. It's a collection of packages taken
in testing or unstable, it's not more complicated to make it a full suite.
And PR-wise, it's way better to avoid testing appearing in the
sources.list.
I don't think that the name showing up in sources.list are important for
PR reasons. The problem with the current testing marketing (for those
who buy PR arguments) is not the sources.list line, but that the suite
is called that way everywhere and advertised solely as the developer /
internal suite that it is. If we advertise rolling with that name (and
proper explanation), what is in sources.list wouldn't really matter.
Still, having a single suite sounds more flexible: we will be able to
control the whole set of rolling packages server side, no matter what is
currently in testing. Not that I can imagine a reason for doing that
now, but having that flexibility sounds good. (And you have already
discussed that it is possible to have.)
The rolling suite would only exist for a subset of architectures (we
could start with powerpc, i386 and amd64), generated by picking up
Why powerpc? If we really take more than i386/amd64 for rolling, there
are more users of armel than of powerpc.
Beside the specific choices of architectures, I'm not sure I see which
specific problem architectures bring into the game. For testing proper,
there are some architecture alignment rules that might make transition
more complex. But for rolling as it is being proposed here, it looks
like that with per-architecture overrides we can support whatever
architecture sets we please.
Are there other constraints than manpower for the overrides that I'm
overlooking? (Note: I'm not arguing that we should have rolling for all
archs, I'm just trying to understand if I've overlooked some
constraints.)
You still need some sort of britney to verify that the package is effectively
installable in rolling, and to verify you're not breaking installability
of other packages available in rolling.
If you only need installability test for binaries (and possibly even
satisfaiability of build-depends, which is currently not checked by
britney but used on buildds), edos-distcheck offers that out of the box.
It would most likely be way easier to setup than britney. For some of
the other needs expressed by Joss, we (as in Mancoosi) have most of the
code ready as well, although not necessarily packaged yet. I need to
look at the details of what Joss had in mind, but we have code ready to
answers questions like which package do I absolutely need to be
installable in that suite?.
If you want to go ahead with patching britney, by all means go ahead, as
it might provide patches useful for the main brintey as well. But if you
want to try some alternatives, we can probably help.
What do you think?
+1 from me. Thank you for the proposal!
Ditto!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: A concrete proposal for rolling implementation
Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504202329.ga20...@madism.org
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:17:03PM +0200, Stefano Zacchiroli wrote: If you want to go ahead with patching britney, by all means go ahead, as it might provide patches useful for the main brintey as well. But if you want to try some alternatives, we can probably help. I don't think you need to patch britney at all. Just take the last testing computed as a testing-britney output as a start, have a list of force-hints to be processed, taken from unstable, and there you go. It's just a new britney run. Admitedly there is a small patch to be done, force hints in britney are strictly versionned, for the rolling case one may want to have looser way to express force hints (with version ranges e.g.), but that should't be really hard. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504202724.gb20...@madism.org
Re: PPAs for Debian
On Wed, May 04, 2011 at 01:23:12AM -0400, Scott Kitterman wrote: PPAs as a developer tool are one thing, PPAs as a tool for random uploads, I think are quite another. I'd hate to see Debian make the same mistake that Canonical did in this regard. PPA on Debian infrastructure should be limited to people with a key in the keyring. Though we should make the software available for people to build their own PPA infrastructure easily. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504203954.gb21...@madism.org
Bug#625652: ITP: morfeusz -- morphological analyser of Polish
Package: wnpp Severity: wishlist Owner: Jakub Wilk jw...@debian.org * Package name: morfeusz Version : 20110416 Upstream Author : Zygmunt Saloni, Włodzimierz Gruszczyński, Marcin Woliński, Robert Wołosz * URL : http://sgjp.pl/morfeusz/ * License : BSD-2-clause Programming Lang: C++, Perl Description : morphological analyser of Polish Lexeme is an abstract entity of language, a word in the dictionary sense. Word form is a word that has been interpreted — ascribed to a particular lexeme and described as for its grammatical function. Morphological analysis consists in determining all forms of all lexemes for a particular word, that it is an exponent of. The context, in which the word has appeared, is not taken into consideration in this process. Morfeusz carries out a morphological analysis for Polish. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504204140.ga7...@jwilk.net
Re: A concrete proposal for rolling implementation
* Pierre Habouzit [2011-05-04 22:23 +0200]: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504204846.ga27...@furrball.stateful.de
Re: A concrete proposal for rolling implementation
On Wednesday, May 04, 2011 04:25:35 PM Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: What to do during freezes - If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Yes, absolutely. This seems straightforward, elegant, and useful as it encourages maintainer to push their changes to the Debian archive and make them visible and testable to rolling users, even when unstable is de facto closed. Does this mean Experimental should be renamed Unfrozen? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105041658.32267.deb...@kitterman.com
Re: A concrete proposal for rolling implementation
What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Again, no disruption: people can keep on breaking some pieces of experimental, but if they want some other pieces to be useful for rolling users, they just need to be committed to more carefulness and to add them to the override file. I also find this a very good implementation, although I would like a 'true' rolling release, without any freezes at all. I'm not sure how much extra work it implies or how much sense it would make to have an exact clone of testing just without the freezes. -- Best regards, Mit freundlichen Grüßen, Cristian Henzel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc1bf92.7050...@b3r3.info
Re: gtkpod packaging dependencies
On 02/05/11 22:22, Matteo F. Vescovi wrote: Hi! On 02/05/2011 20:54, phantomjinx wrote: Hi, Someone with the handle 'mfv' came into the gtkpod irc channel wondering about gtkpod dependencies as he was packaging it for debian. It was me :-) Sorry if I didn't wait long enough for your direct reply. I have already produced an ubuntu ppa for the 2.0.1-beta so thought the debian directory would be useful. Thanks a lot, really. Your help is really appreciated. I hope I'll find a sponsor to upload it soon to unstable. Please find attached. (Not registered so please cc any replies. Thanks). Same here. Regards phantomjinx Cheers, mfv -- Ing. Matteo F. Vescovi Hi Matteo, Just found your question in gtkpod irc. Not quite certain what you were asking about the copyrights. I think ... The AUTHORS file in the gtkpod source is the most accurate record of all the authors. Probably a couple more besides so always essential to add the line about others past and present. Any other info then ask away. Regards PGR -- I know exactly who reads the papers ... The Daily Mirror is read by people who think they run the country. The Guardian is read by people who think they ought to run the country. The Times is read by people who do actually run the country. The Daily Mail is read by the wives of the people who run the country. The Financial Times is read by the people who own the country. The Morning Star is read by the people who think the country ought to be run by another country. The Daily Telegraph is read by the people who think it is. Jim Hacker, Yes Minister -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc1c3c8.4030...@phantomjinx.co.uk
Re: A concrete proposal for rolling implementation
Hiya, On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: What to do during freezes - If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Yes, absolutely. This seems straightforward, elegant, and useful as it encourages maintainer to push their changes to the Debian archive and make them visible and testable to rolling users, even when unstable is de facto closed. It's an excellent idea. Some of the initial feedback that I've gotten about DEP-10 (in particular some brainstorming on IRC with Carsten Hey) is pointing at ideas along these lines, and I hope to flush them out in a bit more detail RSN. But I think it's particularly exciting that these two ideas (rolling, and dealing with freezes) might not conflict with each other, and perhaps complement one another. One issue that would need to be addressed with experimental is that opening a migration route anywhere out of experimental might come as an unpleasant surprise to some, since there's a standing expectation that it's a pseudo-suite where we can put stuff that we don't necessarily want to try out in unstable. Not an insurmountable problem (either we change that or introduce yet another psuedo-suite for this purpose), but worth note anyway. sean -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504214045.ga4...@cobija.connexer.com
Re: A concrete proposal for rolling implementation
On Wed, May 4, 2011 at 6:40 PM, sean finney sean...@debian.org wrote: [...] On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: What to do during freezes - If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. [...] One issue that would need to be addressed with experimental is that opening a migration route anywhere out of experimental might come as an unpleasant surprise to some, since there's a standing expectation that it's a pseudo-suite where we can put stuff that we don't necessarily want to try out in unstable. Not an insurmountable problem (either we change that or introduce yet another psuedo-suite for this purpose), but worth note anyway. Indeed. I guess we could specify a flag in this overrides file that says whether or not it's fine to fetch from experimental (defaulting to off). That way it would be up to the maintainer to specify that experimental is good and stable enough for rolling. I really like this new proposal, nice job. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktin4vnums0qbqe1ruvubkezyrhu...@mail.gmail.com
Has anyone attempted a tomcat7 package?
I've been trying to build a tomcat7 package based on the existing tomcat6 package. After fiddling with it for a while, I've managed to build what looks like a working binary, but I get a backtrace when the services starts. The relevant part of the backtrace is java.lang.NoClassDefFoundError: org/apache/tomcat/util/res/StringManager at org.apache.catalina.startup.Catalina.clinit(Catalina.java:80) ... at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:406) meaning there's a missing class. I found the reference to the class in build.xml however I have no idea why it's not being built nor what should I do in debian/rules to install it in its proper place. I've run ant manually and gotten the file to build, and attempted putting it in tomcat's class search path, but the problem persists. If anyone is working on a tomcat7 package, or can shed light on what I'm supposed to do next, I'd appreciate any pointers. Thanks in advance! -- Ernesto Hernández-Novich - @iamemhn - Unix: Live free or die! Geek by nature, Linux by choice, Debian of course. If you can't aptitude it, it isn't useful or doesn't exist. GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304556130.4104.248.ca...@deepthought.ius.cc
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote: Steve M. Robbins st...@sumost.ca wrote: Hi, I'm with Linus on this: let's just revert to the old behaviour. A tiny amount of clock cycles saved isn't worth the instability. Tiny amount?! The optimized memcpy() variants that break shitty code bring a 4 to 5x speedup on the processors they've been written for! Though I didn't see any actual time measurements in the bug thread, I am sure there is a speedup of some kind for the memcpy() call itself. I'm not interested in that. I am interested to know the speedup -- measured in real-world conditions -- for actual, popular applications. But I'm really not interested that much. I'm really interested in having a running system. Yes, even one with buggy software that happens to be important to me. Cheers, -Steve signature.asc Description: Digital signature
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 01:34:15PM +0200, sean finney wrote: And furthermore, even if Debian chooses to fix this, upstreams will be forced to eventually cater to the default glibc behavior for every other libc distro out there that does not have their own fix (and non-libc OS's where this behavior already exists), That's fine: let others be the guinea pigs, then introduce the optimized memcpy later when the rest of the world has adapted. so gains would be potentially limited. For me, having a working system would be a great gain! That said, regressions do suck, especially when they take the form of heisenbugs. But one could easily hack something LD_PRELOAD'able check for stuff like this without forcing a global change. Sounds interesting. What do you have in mind? -Steve signature.asc Description: Digital signature
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote: * Pierre Habouzit [2011-05-04 22:23 +0200]: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? That's the point, you don't target rolling, your goal is still to make stuff migrate into testing, rolling is just the extra few packages testing needs to fix the most important breakages that happen (e.g. your PAM example, or large migrations where dependencies across libraries are too loose and break testing, Joss said it happens to gnome quite a lot e.g.). IOW to target rolling you target testing, IOW you help doing stable stuff, isn't that nice? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505054655.ga26...@madism.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 12:05:22AM +0300, Cristian Henzel wrote: What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Again, no disruption: people can keep on breaking some pieces of experimental, but if they want some other pieces to be useful for rolling users, they just need to be committed to more carefulness and to add them to the override file. I also find this a very good implementation, although I would like a 'true' rolling release, without any freezes at all. I'm not sure how much extra work it implies or how much sense it would make to have an exact clone of testing just without the freezes. Not a lot, I don't expect it larger than having to place a dozen hints usually, up to a small hundred during the peaks (100 is less than 1% of our source packages). Maintaining something like that isn't hard, it's already what the RM Team does to follow testing migrations, and if rolling is generated after testing is, the Rolling Team will benefit from the RT work so it's just an incremental effort. Nothing wasted. (And not wanting to finger point but I've read at least a certain RT Member saying that he would even consider help a Rolling Team as he's already doing that pinning on his workstation…) -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505055010.gb26...@madism.org
Accepted bobcat 2.15.00-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 03 May 2011 15:14:57 +0200 Source: bobcat Binary: libbobcat2 libbobcat-dev Architecture: source i386 Version: 2.15.00-1 Distribution: unstable Urgency: low Maintainer: Frank B. Brokken f.b.brok...@rug.nl Changed-By: Frank B. Brokken f.b.brok...@rug.nl Description: libbobcat-dev - headers and documentation for the Bobcat library libbobcat2 - run-time (shared) Bobcat library Changes: bobcat (2.15.00-1) unstable; urgency=low . * New upstream release repairs flaws appearing with g++ 4.6 Checksums-Sha1: 7007464c7a00bc5a1bc6971284c0d7359d6e299b 1859 bobcat_2.15.00-1.dsc d339e86e57de24c3b9cdce870012a3642f34d771 879410 bobcat_2.15.00.orig.tar.gz a9d50c72d96090a05d88da8ac032dfd3f47b4e84 11284 bobcat_2.15.00-1.debian.tar.gz 0b37599818e71f55827b8b63aac9d4d6d79b7ff7 233536 libbobcat2_2.15.00-1_i386.deb 1c205ad156a5b77972af395f1079983745f44f17 1382350 libbobcat-dev_2.15.00-1_i386.deb Checksums-Sha256: c0dddef0f13ffdf586cab8a7a3242e02731b88a81fa2af9d29d880a9e6334b3f 1859 bobcat_2.15.00-1.dsc 4f35f48f7e1c844a4ff7fe3d28ab1b0d6da9f96f90769adfc43bdb1f7f458847 879410 bobcat_2.15.00.orig.tar.gz 486a9ed5e205e806025ba0cf9b736b798732f32f45283c37c4f11fc07b224419 11284 bobcat_2.15.00-1.debian.tar.gz dd375bab2687f437cdf99d35daea6d8b8d77bd218721c17be671de0dfee6fb8d 233536 libbobcat2_2.15.00-1_i386.deb 768c6ee1376a84dc5b8967731fdbb0c78da2e483c3c465349ee6b924ae81a4b7 1382350 libbobcat-dev_2.15.00-1_i386.deb Files: 29217e535e3f6381af07155f90cd9872 1859 libs optional bobcat_2.15.00-1.dsc 9b50d0d592dc1cdc5819f9054343f27e 879410 libs optional bobcat_2.15.00.orig.tar.gz 03fba73043deaf949a0659f1dc659d1b 11284 libs optional bobcat_2.15.00-1.debian.tar.gz 19fd9511798d236425e23de96f589bf8 233536 libs optional libbobcat2_2.15.00-1_i386.deb 1b5c4cd289f90a54cfeaf68834e18fd6 1382350 libdevel optional libbobcat-dev_2.15.00-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJNwOBvAAoJECHSBYmXSz6WGVgP/AtGXu8mosg4agDRGq2Z+fMv YoHyvNZdoZtQKW5pqdVC/eLRKuVt+sWsYp97QVVzn4su14K+5+/3635kqjtrMBsk HYZlYZ+nm4v0T9BPesgq02w9Gwwlx4EJAhtQVybN+hW4TX0K8tQCwV8B2V56M/Tj p4thUJa2nwtMb+n3RUoGQgfzIQ4lU15yz1/jdhVZ0yVXu1NOwCh6x45TXoFxGjbj JLZdQk5EUBTT5jMonSRYkhDvmn5SFOpmcw+XVDqmy45MIA8D5kmZ6CCJPtvxy4rJ 4fV8A0XZqZyko+QEkpP24HJsrk6KgB9GKo3SmZvFA4qSbhYUqxaTU4IGvB3GPOym oqZ/uoy4HybXrMUXYfGlQ2itjoV6OdEHdKDJFIOnwd+DZZLS7yYNk1eCc/bmvRJe TKTsbZORLEc7p3N7NP0AmJ65Yi5ArO7U5qWnrWFRrHXxaAv3+FbQc/kZw863QwUJ pKROvZmHSufMoapKBUVgaLEqDznneOGQhbbnMMdtqmqtaTNJ7A7uXsCJYqD1qm56 0fx5Fv4tZ5pbK9ijy2lDPv0AIfH7NlKIcthc6tGcl3VoKVtxtLEjRt4D/ukPYS0J xVkMPe+IiccJG4VY8KrNH3kFLBzP6nAtcpy8LWJ9/zE3SCdbscM5ZhQGSBQwKB8H +yMihVQ1etIa39kzlbI0 =mPLL -END PGP SIGNATURE- Accepted: bobcat_2.15.00-1.debian.tar.gz to main/b/bobcat/bobcat_2.15.00-1.debian.tar.gz bobcat_2.15.00-1.dsc to main/b/bobcat/bobcat_2.15.00-1.dsc bobcat_2.15.00.orig.tar.gz to main/b/bobcat/bobcat_2.15.00.orig.tar.gz libbobcat-dev_2.15.00-1_i386.deb to main/b/bobcat/libbobcat-dev_2.15.00-1_i386.deb libbobcat2_2.15.00-1_i386.deb to main/b/bobcat/libbobcat2_2.15.00-1_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhvb1-00080l...@franck.debian.org
Accepted expeyes 1.0.3-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 May 2011 07:22:18 +0200 Source: expeyes Binary: expeyes expeyes-firmware-dev python-expeyes expeyes-doc-en expeyes-doc-fr Architecture: source all Version: 1.0.3-2 Distribution: unstable Urgency: low Maintainer: Georges Khaznadar georg...@ofset.org Changed-By: Georges Khaznadar georg...@ofset.org Description: expeyes- hardware software framework for developing science experiments expeyes-doc-en - User manual for expeyes library, in English language expeyes-doc-fr - User manual for expeyes library, French translation expeyes-firmware-dev - hardware software framework for developing science experiments python-expeyes - Python library for expeyes Closes: 625185 625271 625472 Changes: expeyes (1.0.3-2) unstable; urgency=low . * added expeyes-doc ( 1.0.3) in Conflicts:, in order to make expeyes-doc-xx installable. Closes: #625472, #625271 * made imagemagick a build-dependency. Closes: #625185 Checksums-Sha1: 585e98291ee82ba440fa0c58b3b0e1e794b90822 1209 expeyes_1.0.3-2.dsc 85a07cb4c6ab6d850ce3e0faa655444c20fdc868 98211 expeyes_1.0.3-2.debian.tar.gz a59c9e32e66828ad0822c1e1d4c7466402210ffe 266870 expeyes_1.0.3-2_all.deb a27d89d50db11974360a1a41d2b574f99af5e888 10918 expeyes-firmware-dev_1.0.3-2_all.deb 78fdbc8d74f15a3a74f76cbce21bf38ffed7ec46 17030 python-expeyes_1.0.3-2_all.deb 22865da70a196afc65cd7b95fd8228bba09264b4 2975440 expeyes-doc-en_1.0.3-2_all.deb 30e2bbd0bacdf3ace8affd76f2a06103b445ae4a 3094434 expeyes-doc-fr_1.0.3-2_all.deb Checksums-Sha256: 129465f6ef74c7e8434d625a0df53d6d7241b2c9492b06347aadf31154bd835a 1209 expeyes_1.0.3-2.dsc 12514b04e489a84c251faca7da757ef63fe6dd6dd499eacebe3d12d6636a1d1b 98211 expeyes_1.0.3-2.debian.tar.gz ebc1d7e05dab6a2ec48b4f904712e108f0e64d2d873b2e6cdbb1b7d6d90aa081 266870 expeyes_1.0.3-2_all.deb 1276781e8fbace02bd6c9c17b4b031d6c7cb2d82248d296c604c4b89f3eef318 10918 expeyes-firmware-dev_1.0.3-2_all.deb cb3155a69817cc241a24f276310525443863e59d46a06591531c4413cb497ec0 17030 python-expeyes_1.0.3-2_all.deb 0dde7d1399cdfdc072e681ee684eeab9559f1b4655134845c757eec0419786d7 2975440 expeyes-doc-en_1.0.3-2_all.deb f558bb906d90090e5a3b5c795602fb15fc9ca939b1ea9728b09450787a287899 3094434 expeyes-doc-fr_1.0.3-2_all.deb Files: 4cb76361c9c7eee726f50c706909cc00 1209 science extra expeyes_1.0.3-2.dsc a0202012ee5abea31ae08b17a544ff4f 98211 science extra expeyes_1.0.3-2.debian.tar.gz 12f8a5ebdfb22775fa086fb11f4e5287 266870 science extra expeyes_1.0.3-2_all.deb 4fff83a08208ae2419db47abb9e036c6 10918 devel extra expeyes-firmware-dev_1.0.3-2_all.deb 02466eec6c782b3798fdcc7449d97d45 17030 python extra python-expeyes_1.0.3-2_all.deb 84c01f6d600b7a14d0d86bd5ddfa2b2c 2975440 doc extra expeyes-doc-en_1.0.3-2_all.deb c77e4b660a3f6c0dbadff609f1bffe62 3094434 doc extra expeyes-doc-fr_1.0.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFNwOcznfmb2hFpETARAofWAJ9N/vvjeXGEg5i6azurpgWbmTOK1gCfW+G7 wAHma2FcuTF/W9vT6UNni6I= =1c74 -END PGP SIGNATURE- Accepted: expeyes-doc-en_1.0.3-2_all.deb to main/e/expeyes/expeyes-doc-en_1.0.3-2_all.deb expeyes-doc-fr_1.0.3-2_all.deb to main/e/expeyes/expeyes-doc-fr_1.0.3-2_all.deb expeyes-firmware-dev_1.0.3-2_all.deb to main/e/expeyes/expeyes-firmware-dev_1.0.3-2_all.deb expeyes_1.0.3-2.debian.tar.gz to main/e/expeyes/expeyes_1.0.3-2.debian.tar.gz expeyes_1.0.3-2.dsc to main/e/expeyes/expeyes_1.0.3-2.dsc expeyes_1.0.3-2_all.deb to main/e/expeyes/expeyes_1.0.3-2_all.deb python-expeyes_1.0.3-2_all.deb to main/e/expeyes/python-expeyes_1.0.3-2_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhvct-0008mk...@franck.debian.org
Accepted libnss-db 2.2.3pre1-3.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 May 2011 07:31:48 +0200 Source: libnss-db Binary: libnss-db Architecture: source amd64 Version: 2.2.3pre1-3.2 Distribution: unstable Urgency: medium Maintainer: Piotr Roszatycki dex...@debian.org Changed-By: Aurelien Jarno aure...@debian.org Description: libnss-db - NSS module for using Berkeley Databases as a naming service Closes: 548484 577057 Changes: libnss-db (2.2.3pre1-3.2) unstable; urgency=medium . * Non-maintainer upload. * Build depends on libdb-dev ( 4.6) instead of libdb4.6-dev. Closes: #548484. * Fix security issue which allows to read arbitrary file contents (CVE-2010-0826), patch taken from Ubuntu. Closes: #577057. Checksums-Sha1: 7fc3340a3c8df876b9e95f271b1e3f3777e02320 1307 libnss-db_2.2.3pre1-3.2.dsc 4243f0a44642e6b6517af28a2513b648b0c29904 18551 libnss-db_2.2.3pre1-3.2.diff.gz 756797386a5d62b4dcd66f496c74077216881237 29728 libnss-db_2.2.3pre1-3.2_amd64.deb Checksums-Sha256: d7847b0cdb4da5d601bf7c5dbb6943a60ecf70bd50ef78a27b6ba3e5cd370808 1307 libnss-db_2.2.3pre1-3.2.dsc b4f2d9cab5f26e0b05b6dfb1d17e54e9d1f16af13d355948fe42f8ac5956515a 18551 libnss-db_2.2.3pre1-3.2.diff.gz a7b8b773acc4d81da2a24516b832ae2d9dd23a01ea1d7e10d5a0bc57215f640a 29728 libnss-db_2.2.3pre1-3.2_amd64.deb Files: daf32e1b8f39dfee3d89a71b45ee3411 1307 admin standard libnss-db_2.2.3pre1-3.2.dsc 4cc3d777041da5163d88732727f8a29d 18551 admin standard libnss-db_2.2.3pre1-3.2.diff.gz 7d5036da15e0052109ffe6728d00a9e6 29728 admin standard libnss-db_2.2.3pre1-3.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFNwOnnw3ao2vG823MRAkSiAJ9pftKt6Ut09BQxtBsUp+iUyXdBTgCggHfo CIuNU4Z4UFo48nA6bKw6Uis= =L279 -END PGP SIGNATURE- Accepted: libnss-db_2.2.3pre1-3.2.diff.gz to main/libn/libnss-db/libnss-db_2.2.3pre1-3.2.diff.gz libnss-db_2.2.3pre1-3.2.dsc to main/libn/libnss-db/libnss-db_2.2.3pre1-3.2.dsc libnss-db_2.2.3pre1-3.2_amd64.deb to main/libn/libnss-db/libnss-db_2.2.3pre1-3.2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhvrm-0003yv...@franck.debian.org
Accepted svgalib 1:1.4.3-31 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 May 2011 06:41:22 +0200 Source: svgalib Binary: svgalib-bin libsvga1 libsvga1-dev Architecture: source amd64 Version: 1:1.4.3-31 Distribution: unstable Urgency: low Maintainer: Guillem Jover guil...@debian.org Changed-By: Guillem Jover guil...@debian.org Description: libsvga1 - console SVGA display libraries libsvga1-dev - console SVGA display development libraries and headers svgalib-bin - console SVGA display utilities Closes: 623747 Changes: svgalib (1:1.4.3-31) unstable; urgency=low . * Fix upstream installation of setuid programs and exclude them from dh_fixperms instead of restoring the permissions afterwards. This fixes a build failure when the utilities are not built. (Closes: #623747) * Now using Standards-Version 3.9.2 (no changes needed). Checksums-Sha1: 1cfd76eed7bb41ec0dbd2e915d4d64b5147aa1e0 1273 svgalib_1.4.3-31.dsc e4d6b06e3179f7243ad117268df082d69160e8a4 65717 svgalib_1.4.3-31.debian.tar.gz fdaf4c477034871f793f6369c93965473b40c26b 21420 svgalib-bin_1.4.3-31_amd64.deb 55e64fb8febf9ee0e2208bcebb19ee61e3fc57bc 306146 libsvga1_1.4.3-31_amd64.deb 171bdc324cea2505dae7768c686d5859c03eeb1f 563272 libsvga1-dev_1.4.3-31_amd64.deb Checksums-Sha256: 20bb99c57b97f90b4ee65f1bbe3887b594ea37f21de3c8356de4361ff6757729 1273 svgalib_1.4.3-31.dsc 9a814c7e5c8789ee91e6c6c43bf28fbbb828db0768c3ea90070f9b2e65ca9262 65717 svgalib_1.4.3-31.debian.tar.gz f1b6fb7c6b9514fe9e9e19678c34875ce76cad2ba303383f8d291590270a4822 21420 svgalib-bin_1.4.3-31_amd64.deb f8dd143035d383ff56270a965cdf8144890e127be829c3b061c33eda084b1439 306146 libsvga1_1.4.3-31_amd64.deb 29d5c1887f1d15437336bbdccd51459651d73890657c79aaa9a9bb3b844dd567 563272 libsvga1-dev_1.4.3-31_amd64.deb Files: 0c78a1a33b37e7cd2caaea2140568eb4 1273 graphics optional svgalib_1.4.3-31.dsc 3b545c3cc9b5272a539a897149a82fe9 65717 graphics optional svgalib_1.4.3-31.debian.tar.gz c55b0ca995475b4bbb8cdf515fff416a 21420 graphics optional svgalib-bin_1.4.3-31_amd64.deb a8de0457fbc3b92be27405435ab453c7 306146 libs optional libsvga1_1.4.3-31_amd64.deb 81ef8e4afd899422349b63d6cbe57f47 563272 libdevel optional libsvga1-dev_1.4.3-31_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3A2f0ACgkQuW9ciZ2SjJuvMQCcDPP9DmuvfwjgXeVocUNpU8Oo IXsAniAoUxQkKqkJo9y70LxiH3xwiH+7 =SmAA -END PGP SIGNATURE- Accepted: libsvga1-dev_1.4.3-31_amd64.deb to main/s/svgalib/libsvga1-dev_1.4.3-31_amd64.deb libsvga1_1.4.3-31_amd64.deb to main/s/svgalib/libsvga1_1.4.3-31_amd64.deb svgalib-bin_1.4.3-31_amd64.deb to main/s/svgalib/svgalib-bin_1.4.3-31_amd64.deb svgalib_1.4.3-31.debian.tar.gz to main/s/svgalib/svgalib_1.4.3-31.debian.tar.gz svgalib_1.4.3-31.dsc to main/s/svgalib/svgalib_1.4.3-31.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhwdg-0004ld...@franck.debian.org
Accepted mpop 1.0.24-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 02 May 2011 18:57:16 +0200 Source: mpop Binary: mpop mpop-gnome Architecture: source amd64 Version: 1.0.24-2 Distribution: unstable Urgency: low Maintainer: Emmanuel Bouthenot kol...@debian.org Changed-By: Emmanuel Bouthenot kol...@debian.org Description: mpop - POP3 mail retriever mpop-gnome - POP3 mail retriever - with GNOME keyring support Changes: mpop (1.0.24-2) unstable; urgency=low . * Update debian/copyright to reflect licensing changes * Do no rely on default configure options while building mpop without GNONE keyring support (avoid mpop to be linked with some GNOME libs). Checksums-Sha1: 6c6a046a2906a65c0eb019bc999eaf2fb6d21f0e 1865 mpop_1.0.24-2.dsc 179436876ea086d72ee262ea0924382b9006af99 5830 mpop_1.0.24-2.debian.tar.gz a77253d66c468964039d1a1bb0f7530ba451f1d7 117626 mpop_1.0.24-2_amd64.deb b7cebd2a2dcc9245dad26e93ecb5d3314a7e33aa 55054 mpop-gnome_1.0.24-2_amd64.deb Checksums-Sha256: c09c9bfba289062b358b44fbc72c28ca0f5410366770bba36c076eb3164ab7dc 1865 mpop_1.0.24-2.dsc 391a3b9bf0ffeb6ea248ee613f7612fd01b2e926f36d009006b7d469d4e5fe53 5830 mpop_1.0.24-2.debian.tar.gz f6585a58541a5570d2c055f08ac46a64892b0a833b8379e63f5cfbb10bfd548c 117626 mpop_1.0.24-2_amd64.deb 567c86ae285fa1dff0dad2a0a034634d33b8d02e130d3032c1ec1bdaf1dadc28 55054 mpop-gnome_1.0.24-2_amd64.deb Files: 78e5b4b271bb95142379d1fe9b9920c9 1865 mail extra mpop_1.0.24-2.dsc 696041df83bfb051931ca6bb8aabff69 5830 mail extra mpop_1.0.24-2.debian.tar.gz fb3ea534707f4ee5341b5e2999138e94 117626 mail extra mpop_1.0.24-2_amd64.deb b0b8ed44b52ca571414e1203b17b0603 55054 mail extra mpop-gnome_1.0.24-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJNwPIzAAoJEEsHdyOSnULDZtwQAIfF3SKNCCVnfGyISpzvR4a7 P5KcqVfdcgCX+pE0Zbrq8LGRHpmLB2dRPBViKnDcv9D9osJppFz6+YMuuQo16Q5q GGVFhDZhuMyubMXkxZ/FOutRHT+kAJyjFRGh6ulMODkwOZv14Dxyz/Q95OtnwC/p 3pqRZs1N5jTrGRQSeNwqkpH8GVNvC3gCiL93dhGHf8/a74n5k4xkBDw0R3aachDf k9J7m2hPTjm1zUZFmbQkZRVN1/zeK+TNkSu5RRD6qP4IXUCYQlSMfJWmXBQ8T+nw +WMKqjbDkZ1G9CO1sMYnzqS6w7vM/3B4MeKp1mI9XmjdbIWK7avBu/tNXTlHeRC6 OblMOax1sI5lUWcBh0K8w0bD0CKurBaKQEEWEFNSwn8KGjJ5GZowGloGKAAH+e27 Fm44hJ9h67UAOcHQgUJOXz/t/Jj0rMD3W1WRlz3qtpzGJoDWl5PwzFR8v3Ii2sUh QQcNcDbcK6V5JVv/aQSxTL2A2WbcX+xLY5CwfE3Boew1RsutUpdlAd1+ADr6t5su YVTb6lGd3oDHpENct6AzaQtNA4/cwgxPSTlGXmM5gOS7BmeP42VvpFSssrc4PUFn lQ/u0ab/Plod4SrNjBrY7s6V0tfFxj1dNzaFxr30mzuVUB/2HyXYfZ0TivYz4joM nuxuFMfwxuU6EF/Yg/yh =ysvV -END PGP SIGNATURE- Accepted: mpop-gnome_1.0.24-2_amd64.deb to main/m/mpop/mpop-gnome_1.0.24-2_amd64.deb mpop_1.0.24-2.debian.tar.gz to main/m/mpop/mpop_1.0.24-2.debian.tar.gz mpop_1.0.24-2.dsc to main/m/mpop/mpop_1.0.24-2.dsc mpop_1.0.24-2_amd64.deb to main/m/mpop/mpop_1.0.24-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhxhf-0006lo...@franck.debian.org
Accepted blender 2.57.2-svn36339-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 02 May 2011 15:18:20 +0200 Source: blender Binary: blender blender-dbg Architecture: source amd64 Version: 2.57.2-svn36339-1 Distribution: unstable Urgency: low Maintainer: Kevin Roy kin...@gmail.com Changed-By: Kevin Roy kin...@gmail.com Description: blender- Very fast and versatile 3D modeller/renderer blender-dbg - debug symbols for Blender Changes: blender (2.57.2-svn36339-1) unstable; urgency=low . * New Upstream Release Checksums-Sha1: a540224b4f60b594ab809a2c7ab94f98a571ae45 1677 blender_2.57.2-svn36339-1.dsc dd692949916f891609df037eee09ee44ab0d06ad 16577621 blender_2.57.2-svn36339.orig.tar.gz 8757d82a82cb9939c2bfe8a164f735deebfef1f8 30144 blender_2.57.2-svn36339-1.debian.tar.gz b5e8a900e8b8a4bb68e6be014a751c441f6b8257 14893430 blender_2.57.2-svn36339-1_amd64.deb 6b6352a9efa083d3f59167039cb1f4d6765b2bd8 42466190 blender-dbg_2.57.2-svn36339-1_amd64.deb Checksums-Sha256: e8476ec800b7896be98ecbe953b4da794907962189984845cc44c54a58bbb377 1677 blender_2.57.2-svn36339-1.dsc ad3cafcc0f4e3c35d1b0f54ca12f2b7a245cf2604b67fdf274f7155394cbb353 16577621 blender_2.57.2-svn36339.orig.tar.gz cc9e239484e49cead8961791ce2b752acb67e74b1bb7f6c9ff2bf02e79f2b61b 30144 blender_2.57.2-svn36339-1.debian.tar.gz ba732ecc76aa16bfaa67f467081faf44bba8ec951dfbb096de11c11cf650a15f 14893430 blender_2.57.2-svn36339-1_amd64.deb da8908e76e978714c7a8631606360c7db4dfbfccdeeeb9e1e58facbd30332d2a 42466190 blender-dbg_2.57.2-svn36339-1_amd64.deb Files: ccfac93fcb33174e73e66fa6e61f107b 1677 graphics optional blender_2.57.2-svn36339-1.dsc 04cd1bd0be1664e4585ebc7652995496 16577621 graphics optional blender_2.57.2-svn36339.orig.tar.gz ede60d7a7226101581bf85b0bb154513 30144 graphics optional blender_2.57.2-svn36339-1.debian.tar.gz 7516b613bef09f5a4c670508c5908120 14893430 graphics optional blender_2.57.2-svn36339-1_amd64.deb f503c29d9a998c71bd33a93c67da5ef3 42466190 debug extra blender-dbg_2.57.2-svn36339-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3BGagACgkQsKTFpDfZQSwCdgCfVbfsGyCCNylh/KYuoPfhJ57w q8cAn1SQI6o6oHFqG4WJLz2EpseqzsCw =tj/X -END PGP SIGNATURE- Accepted: blender-dbg_2.57.2-svn36339-1_amd64.deb to main/b/blender/blender-dbg_2.57.2-svn36339-1_amd64.deb blender_2.57.2-svn36339-1.debian.tar.gz to main/b/blender/blender_2.57.2-svn36339-1.debian.tar.gz blender_2.57.2-svn36339-1.dsc to main/b/blender/blender_2.57.2-svn36339-1.dsc blender_2.57.2-svn36339-1_amd64.deb to main/b/blender/blender_2.57.2-svn36339-1_amd64.deb blender_2.57.2-svn36339.orig.tar.gz to main/b/blender/blender_2.57.2-svn36339.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhzdz-00032u...@franck.debian.org
Accepted debdelta 0.42exp (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 May 2011 11:04:55 +0200 Source: debdelta Binary: debdelta Architecture: source i386 Version: 0.42exp Distribution: experimental Urgency: low Maintainer: A Mennucc1 mennu...@debian.org Changed-By: A Mennucc1 mennu...@debian.org Description: debdelta - diff and patch utilities which work with Debian packages Changes: debdelta (0.42exp) experimental; urgency=low . * Implemented streaming capabilities in patches; implemented new --format option for 'debdelta-upgrade', so that '--format=unzipped' will create debs with data.tar uncompressed * debdelta-upgrade bails out on a delta if locale files are missing, even if 'localepurge' is not used (see bug 619086) Checksums-Sha1: 2c558897625714b4b979f5b8fb3cf74ce778c42d 808 debdelta_0.42exp.dsc 82e1803ca84a38a252652d67bf2beef1466a5432 122800 debdelta_0.42exp.tar.gz 60329a6ec59bc42a1f9d4750641cde1481ec7ef2 104464 debdelta_0.42exp_i386.deb Checksums-Sha256: e0b69f8e71a35887b666e8676f8ec662238bcbf934c04f71caff3e90bd15a8c9 808 debdelta_0.42exp.dsc 46110879a14f0444a3a8814892685e1cba4f6edd8f6044c0971d5b4773ea6f3f 122800 debdelta_0.42exp.tar.gz 5f4d5ca45d730b5590a69fcdfb469aa7fb9b85af1d3c60e223b74323e5899356 104464 debdelta_0.42exp_i386.deb Files: 0936b99e3f19f1b8fc05ae82e3a04d23 808 devel optional debdelta_0.42exp.dsc ad4c560fa7c1ea1360c433bbfe74ae2b 122800 devel optional debdelta_0.42exp.tar.gz 3e8e87b846ed595d38e7c720938d89d8 104464 devel optional debdelta_0.42exp_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3BGH8ACgkQ9B/tjjP8QKSAqACgpEVepEbm6VU0vjCmI/+o5Toh TtIAn3srsCJN3073mjnJs8u43tQAXhJe =zHh0 -END PGP SIGNATURE- Accepted: debdelta_0.42exp.dsc to main/d/debdelta/debdelta_0.42exp.dsc debdelta_0.42exp.tar.gz to main/d/debdelta/debdelta_0.42exp.tar.gz debdelta_0.42exp_i386.deb to main/d/debdelta/debdelta_0.42exp_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhzhf-0003fd...@franck.debian.org
Accepted dpkg 1.16.0.3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 May 2011 10:01:30 +0200 Source: dpkg Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect Architecture: source amd64 all Version: 1.16.0.3 Distribution: unstable Urgency: medium Maintainer: Dpkg Developers debian-d...@lists.debian.org Changed-By: Guillem Jover guil...@debian.org Description: dpkg - Debian package management system dpkg-dev - Debian package development tools dselect- Debian package management front-end libdpkg-dev - Debian package management static library libdpkg-perl - Dpkg perl modules Changes: dpkg (1.16.0.3) unstable; urgency=medium . * Allow again Priority field values not known to dpkg. Regression introduced in 1.16.0. Checksums-Sha1: 70304310e32f5da73b8d065e7fa68bc526e36dd7 1208 dpkg_1.16.0.3.dsc 6e16d18864d4845eeaf6262497fde44931a1638d 5322701 dpkg_1.16.0.3.tar.bz2 41121adbc34319c32c7572a493c506f8fb7a9e19 495252 libdpkg-dev_1.16.0.3_amd64.deb 233224a114aedbc1c668ff29592fea4974187894 2226604 dpkg_1.16.0.3_amd64.deb 37eef6286cb11c4b48a7a6bd810d5ecfba5d2b34 949982 dselect_1.16.0.3_amd64.deb 27fbb0aff81f16e80f1813a4fcfb1170cf8798cb 871908 dpkg-dev_1.16.0.3_all.deb ac52189f9df4bea982da9f843d476f504a203f4e 749038 libdpkg-perl_1.16.0.3_all.deb Checksums-Sha256: 4ad990f9d868face77668dceebdba57e87a98930471e4fc022f491d07ca5d660 1208 dpkg_1.16.0.3.dsc 69669720020e67629d70aa5325e3c20c05cae7a9fc2d8abd442672c7b29e31d3 5322701 dpkg_1.16.0.3.tar.bz2 b1cd218e0973365b17d97a4967b7966ff9090ad8ad9cdb9d70df58c34dfeb16c 495252 libdpkg-dev_1.16.0.3_amd64.deb 18c4cd01ddf40fa95cf8a64b0c66d8043b3f160a41dfd955f0d144eab28e53fe 2226604 dpkg_1.16.0.3_amd64.deb dc4d91c133c70c7165f134bd841313098764a6b1048f923d644278e932362eb5 949982 dselect_1.16.0.3_amd64.deb fe02a1a9a7d0c4b12b1775aac7ba999b27ca8222a1be9efc49bfaf3dd1377200 871908 dpkg-dev_1.16.0.3_all.deb f1cb38b02c6572c1037e7292b9ec874e6deb5ebd50bd0206da786f2ff5d73b37 749038 libdpkg-perl_1.16.0.3_all.deb Files: 605327ee89b56534abf99bded4911177 1208 admin required dpkg_1.16.0.3.dsc 0266b06ef9da8278cea008d21e17e5f6 5322701 admin required dpkg_1.16.0.3.tar.bz2 0d45c28a5b058c7932e4d1d68aa59cc2 495252 libdevel optional libdpkg-dev_1.16.0.3_amd64.deb 31f95e86ea1298bcc0bab94adc0485c0 2226604 admin required dpkg_1.16.0.3_amd64.deb d7500c3b56aebab1d21647d622924afc 949982 admin optional dselect_1.16.0.3_amd64.deb e9e5c86827b36efc9f0dd05f6c7ecbe9 871908 utils optional dpkg-dev_1.16.0.3_all.deb ca37761848957e497784e68d3d29919a 749038 perl optional libdpkg-perl_1.16.0.3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3BEGEACgkQuW9ciZ2SjJv7HQCfaYGZNox5wiNuF63Lv/5rzoAU cI0AoKkNqvzHtHEfzZ7lYPzTsFfkGGcQ =/pe4 -END PGP SIGNATURE- Accepted: dpkg-dev_1.16.0.3_all.deb to main/d/dpkg/dpkg-dev_1.16.0.3_all.deb dpkg_1.16.0.3.dsc to main/d/dpkg/dpkg_1.16.0.3.dsc dpkg_1.16.0.3.tar.bz2 to main/d/dpkg/dpkg_1.16.0.3.tar.bz2 dpkg_1.16.0.3_amd64.deb to main/d/dpkg/dpkg_1.16.0.3_amd64.deb dselect_1.16.0.3_amd64.deb to main/d/dpkg/dselect_1.16.0.3_amd64.deb libdpkg-dev_1.16.0.3_amd64.deb to main/d/dpkg/libdpkg-dev_1.16.0.3_amd64.deb libdpkg-perl_1.16.0.3_all.deb to main/d/dpkg/libdpkg-perl_1.16.0.3_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhziy-0004lb...@franck.debian.org
Accepted handlersocket 1.0.6-80-g88bf1e0-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 03 May 2011 10:24:20 -0700 Source: handlersocket Binary: handlersocket-mysql-5.1 handlersocket-doc libhsclient-dev libnet-handlersocket-perl Architecture: source amd64 all Version: 1.0.6-80-g88bf1e0-1 Distribution: unstable Urgency: low Maintainer: Clint Byrum cl...@ubuntu.com Changed-By: Clint Byrum cl...@ubuntu.com Description: handlersocket-doc - HandlerSocket command line client handlersocket-mysql-5.1 - HandlerSocket plugin for MySQL 5.1 libhsclient-dev - HandlerSocket client library libnet-handlersocket-perl - HandlerSocket perl client library. Closes: 621310 Changes: handlersocket (1.0.6-80-g88bf1e0-1) unstable; urgency=low . * New upstream release. * Carefully ensure that libhsclient.la has no dependency_libs. (Closes: 621310) * Make clean steup remove unpacked mysql source Checksums-Sha1: b04cdeb3bcd68e735e5b447471901706459936b1 1315 handlersocket_1.0.6-80-g88bf1e0-1.dsc fb81d84ef511bb1948504438a9296084076aa526 162009 handlersocket_1.0.6-80-g88bf1e0.orig.tar.gz 2bde3607f27a764947c359901ea5fd59217cf43d 3085 handlersocket_1.0.6-80-g88bf1e0-1.debian.tar.gz 8c9d05fbb6e23d4246a2f47db881c939c278a11a 816286 handlersocket-mysql-5.1_1.0.6-80-g88bf1e0-1_amd64.deb 565cc074f17d03f6c86249e5f03198a2b17ef58a 16166 handlersocket-doc_1.0.6-80-g88bf1e0-1_all.deb 351a6263a9f6e005e4e9c75aae72fdb64dc91472 33534 libhsclient-dev_1.0.6-80-g88bf1e0-1_amd64.deb e447167c670d9d8a7f1b53174ed07d0529d1441e 28698 libnet-handlersocket-perl_1.0.6-80-g88bf1e0-1_amd64.deb Checksums-Sha256: e8895082df80613074763a715568bfda1bd636d77d310a33be79063ee94a855f 1315 handlersocket_1.0.6-80-g88bf1e0-1.dsc 15595e95bf5f43bcfb335e5211a5a4945584404b0528d1b6846ce13daf9af857 162009 handlersocket_1.0.6-80-g88bf1e0.orig.tar.gz 782f1e33439d0dd27d77e9fdfc12967f47d4b772385ad46fb79475628220e289 3085 handlersocket_1.0.6-80-g88bf1e0-1.debian.tar.gz d5730c2a6d82d84821349f816f0865692a9f7fd4ef95bb279409dc19812309da 816286 handlersocket-mysql-5.1_1.0.6-80-g88bf1e0-1_amd64.deb 65156841ec6674d5acab5b6a6ff48143ebe71c9324c10c9ba24527b92c42d63c 16166 handlersocket-doc_1.0.6-80-g88bf1e0-1_all.deb 91975249959f3cc7dcbd343b73c7682de33ee9752287c92d7b765606e9de1142 33534 libhsclient-dev_1.0.6-80-g88bf1e0-1_amd64.deb c831bebcdcdf97812d3d06a5f36afe6f7c22fc07b659923bb86b3c09662988f6 28698 libnet-handlersocket-perl_1.0.6-80-g88bf1e0-1_amd64.deb Files: 82f90779c2633a6052f79f56f944a602 1315 database extra handlersocket_1.0.6-80-g88bf1e0-1.dsc 282075549473369cb2bce2caf651b708 162009 database extra handlersocket_1.0.6-80-g88bf1e0.orig.tar.gz c502cc1b1f282cb31179303a0e74cd25 3085 database extra handlersocket_1.0.6-80-g88bf1e0-1.debian.tar.gz 5f03c1389013dcd9f82b57d8074cea0b 816286 database extra handlersocket-mysql-5.1_1.0.6-80-g88bf1e0-1_amd64.deb 8ed8ecef8d462257391ebdb524644b15 16166 doc extra handlersocket-doc_1.0.6-80-g88bf1e0-1_all.deb 853fa3be960a40b20385ca30af2759c4 33534 libdevel extra libhsclient-dev_1.0.6-80-g88bf1e0-1_amd64.deb 24b04f82ba5b0bb9f5bcada04d2ab536 28698 perl extra libnet-handlersocket-perl_1.0.6-80-g88bf1e0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk3BEj8ACgkQr/RnCw96jQFPNQCfVD2oprrXj4Zch6C0ShjOGm9d lSgAnjHSTmX8iMZWJTmhrzfdIJcjog4N =rfkW -END PGP SIGNATURE- Accepted: handlersocket-doc_1.0.6-80-g88bf1e0-1_all.deb to main/h/handlersocket/handlersocket-doc_1.0.6-80-g88bf1e0-1_all.deb handlersocket-mysql-5.1_1.0.6-80-g88bf1e0-1_amd64.deb to main/h/handlersocket/handlersocket-mysql-5.1_1.0.6-80-g88bf1e0-1_amd64.deb handlersocket_1.0.6-80-g88bf1e0-1.debian.tar.gz to main/h/handlersocket/handlersocket_1.0.6-80-g88bf1e0-1.debian.tar.gz handlersocket_1.0.6-80-g88bf1e0-1.dsc to main/h/handlersocket/handlersocket_1.0.6-80-g88bf1e0-1.dsc handlersocket_1.0.6-80-g88bf1e0.orig.tar.gz to main/h/handlersocket/handlersocket_1.0.6-80-g88bf1e0.orig.tar.gz libhsclient-dev_1.0.6-80-g88bf1e0-1_amd64.deb to main/h/handlersocket/libhsclient-dev_1.0.6-80-g88bf1e0-1_amd64.deb libnet-handlersocket-perl_1.0.6-80-g88bf1e0-1_amd64.deb to main/h/handlersocket/libnet-handlersocket-perl_1.0.6-80-g88bf1e0-1_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhzp2-0005vw...@franck.debian.org
Accepted jack-mixer 9-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 May 2011 09:28:29 +0200 Source: jack-mixer Binary: jack-mixer Architecture: source amd64 Version: 9-2 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org Changed-By: Alessio Treglia ales...@debian.org Description: jack-mixer - JACK Audio Mixer Changes: jack-mixer (9-2) unstable; urgency=low . * Move to dh_python2: - Replace XSPV with XPV. - Drop python-support, bump python-all-dev to = 2.6.6-3~. - Drop XBPV. - Append --no-guessing-versions to dh_python2 call, we are not yet able to build this for all supported versions. * Drop lash's stuff from Recommends field. * Get rid of unneeded .la files. * Bump Standards. Checksums-Sha1: a5e80111c12d77636567680106f06f8f8f62348b 1395 jack-mixer_9-2.dsc 1f71222d3cd51a604a064ff40806fe44d17cf288 3003 jack-mixer_9-2.debian.tar.gz 1266dc2cff3a40f705f316ce63461cafc6ab9040 61082 jack-mixer_9-2_amd64.deb Checksums-Sha256: 22ec09864f614de28439b009a9aafac9710b18fe813ed9d4808393dc9e916705 1395 jack-mixer_9-2.dsc 9b532a5edc8fc88f487d6cad8a868911f12da35ea2259dcc70ddb2fe8999bdc1 3003 jack-mixer_9-2.debian.tar.gz 5e665c510aced5b88a3afeb5d25308aef66b78afc63577503a9a82f4548a9775 61082 jack-mixer_9-2_amd64.deb Files: c3ca09cfa68fddc3db5372bddcc558d8 1395 sound optional jack-mixer_9-2.dsc f59f8a732c9ae63edbf8de7827cc135b 3003 sound optional jack-mixer_9-2.debian.tar.gz 5965d3f96a0c4ccc77ac5911fc0b510d 61082 sound optional jack-mixer_9-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3BFt4ACgkQRdSMfNz8P9DRDgCfTNlPWbU4x2We9rSBzxiJDGw4 GhUAn0rGorkk1CXtjS+9e7DolGlE9zbo =Dez+ -END PGP SIGNATURE- Accepted: jack-mixer_9-2.debian.tar.gz to main/j/jack-mixer/jack-mixer_9-2.debian.tar.gz jack-mixer_9-2.dsc to main/j/jack-mixer/jack-mixer_9-2.dsc jack-mixer_9-2_amd64.deb to main/j/jack-mixer/jack-mixer_9-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhzr4-0006ix...@franck.debian.org
Accepted libopenraw 0.0.8-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 May 2011 10:10:29 +0200 Source: libopenraw Binary: libopenraw-dev libopenraw1 libopenraw1-dbg libopenrawgnome1 libopenrawgnome-dev libopenrawgnome1-dbg Architecture: source i386 Version: 0.0.8-3 Distribution: unstable Urgency: low Maintainer: David Paleino da...@debian.org Changed-By: David Paleino da...@debian.org Description: libopenraw-dev - free implementation for RAW decoding - development files libopenraw1 - free implementation for RAW decoding libopenraw1-dbg - debugging symbols for libopenraw libopenrawgnome-dev - GNOME integration for libopenraw - development files libopenrawgnome1 - free implementation for RAW decoding (GNOME integration) libopenrawgnome1-dbg - debugging symbols for libopenrawgnome Closes: 625141 Changes: libopenraw (0.0.8-3) unstable; urgency=low . * Drop unneeded linkage to Boost's Unit Test Framework, causes FTBFS (03-fix_boost_linking.patch) (Closes: #625141) * Standards-Version bump to 3.9.2, no changes needed * Debhelper compatibility bumped to 8 Checksums-Sha1: ecb9b54957e0258c2f26b5ea808f2496cebcb6f4 1450 libopenraw_0.0.8-3.dsc 9b4fc72b03c0666dc8cb03c3d913b4660cd87a6f 7990 libopenraw_0.0.8-3.debian.tar.gz 68877c45dbb82013c34f4695763d53095e5637aa 215644 libopenraw-dev_0.0.8-3_i386.deb ea60a29d38ccbc81f17f72a41a7cd7f91a1ba1cf 142784 libopenraw1_0.0.8-3_i386.deb 89bfca19751f98131ca7602fb4ab6940c2de87fc 880336 libopenraw1-dbg_0.0.8-3_i386.deb 41306617d8c768fec27b0824bc26331c88c23ce5 14708 libopenrawgnome1_0.0.8-3_i386.deb 4add9e54c1a30e534e5a285584cc2ee7d262f2ff 14246 libopenrawgnome-dev_0.0.8-3_i386.deb 7e0c3fc73d60ea1ac12e26049eb1dbeee99a55c4 16784 libopenrawgnome1-dbg_0.0.8-3_i386.deb Checksums-Sha256: f96427e90432fdcd68b55ea9f95558018dfb088f687aafb5151a3764ee1fc1f0 1450 libopenraw_0.0.8-3.dsc 4636019080095b3fc4aa054e597efd2cca7e1865963e9a45e7ac41fd1a0769e2 7990 libopenraw_0.0.8-3.debian.tar.gz fd73bedd83b030c12bc1ddbb3c2c41f530dd377a527dd69b66d70e17240bb56f 215644 libopenraw-dev_0.0.8-3_i386.deb d277d2d03a6b06970016a830daae4c748c2c7920d02b6a86acd5215753dc2b16 142784 libopenraw1_0.0.8-3_i386.deb 804a12482ac38b1e1c3d66fb47778558eabf93ed6c4c858d75e66d71128d1d19 880336 libopenraw1-dbg_0.0.8-3_i386.deb ba21eb2728087df9ca5c600fca72f82ac70867268c568a72589f041051a88013 14708 libopenrawgnome1_0.0.8-3_i386.deb 2a4ae36323ea162185b8b8ec2706351c81470238594572f936c7256efebc7a42 14246 libopenrawgnome-dev_0.0.8-3_i386.deb 950e0edd0a5b8de015e289afb74add11a19b3b1441a48cb363c28735b168bffc 16784 libopenrawgnome1-dbg_0.0.8-3_i386.deb Files: 49865eef8a038a173c24a387385843b3 1450 libs optional libopenraw_0.0.8-3.dsc 3d39ca4f374f983d96d668abc7f6ff6d 7990 libs optional libopenraw_0.0.8-3.debian.tar.gz aa1ff9d091135fd0f98345263ca95521 215644 libdevel optional libopenraw-dev_0.0.8-3_i386.deb 74c2dac5a6894e4e2296f6a1c334b593 142784 libs optional libopenraw1_0.0.8-3_i386.deb 1d9ceace49829d427b095c1c0c36c84e 880336 debug extra libopenraw1-dbg_0.0.8-3_i386.deb 0cd292b92367e3e84365bd161e73b9f8 14708 libs optional libopenrawgnome1_0.0.8-3_i386.deb 2d49bf1543f16bca1517759749a70245 14246 libdevel optional libopenrawgnome-dev_0.0.8-3_i386.deb c375a58dcc81ef533c623f56b70e01f5 16784 debug extra libopenrawgnome1-dbg_0.0.8-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3BDxAACgkQ5qqQFxOSsXRqSACaAnPBjHx4nC7Gw53TrwM1d83H ISMAniu1KMEuzHqIufDeWn0AdXZG9hEq =J6bX -END PGP SIGNATURE- Accepted: libopenraw-dev_0.0.8-3_i386.deb to main/libo/libopenraw/libopenraw-dev_0.0.8-3_i386.deb libopenraw1-dbg_0.0.8-3_i386.deb to main/libo/libopenraw/libopenraw1-dbg_0.0.8-3_i386.deb libopenraw1_0.0.8-3_i386.deb to main/libo/libopenraw/libopenraw1_0.0.8-3_i386.deb libopenraw_0.0.8-3.debian.tar.gz to main/libo/libopenraw/libopenraw_0.0.8-3.debian.tar.gz libopenraw_0.0.8-3.dsc to main/libo/libopenraw/libopenraw_0.0.8-3.dsc libopenrawgnome-dev_0.0.8-3_i386.deb to main/libo/libopenraw/libopenrawgnome-dev_0.0.8-3_i386.deb libopenrawgnome1-dbg_0.0.8-3_i386.deb to main/libo/libopenraw/libopenrawgnome1-dbg_0.0.8-3_i386.deb libopenrawgnome1_0.0.8-3_i386.deb to main/libo/libopenraw/libopenrawgnome1_0.0.8-3_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhzlg-00018s...@franck.debian.org
Accepted mew-beta 7.0.50~6.3.50+0.20110325-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 04 May 2011 17:50:09 +0900 Source: mew-beta Binary: mew-beta mew-beta-bin Architecture: source all i386 Version: 7.0.50~6.3.50+0.20110325-1 Distribution: unstable Urgency: low Maintainer: Tatsuya Kinoshita t...@debian.org Changed-By: Tatsuya Kinoshita t...@debian.org Description: mew-beta - mail reader supporting PGP/MIME for Emacs (development version) mew-beta-bin - external commands for Mew (development version) Changes: mew-beta (7.0.50~6.3.50+0.20110325-1) unstable; urgency=low . * New upstream release. (development snapshot on 2011-03-25, kazu-yamamoto-Mew-6c59817) * debian/copyright: Switch to the DEP-5 format. * debian/control: Update Standards-Version to 3.9.2. Checksums-Sha1: 941a1c50e4df0ded1cc2454db5e5f66ae9f4d99e 1186 mew-beta_7.0.50~6.3.50+0.20110325-1.dsc 12c3d4dc1662cc376d632cfc17788d3abab78e84 1026638 mew-beta_7.0.50~6.3.50+0.20110325.orig.tar.gz 13803285b9ba41fab93eb8ac869867fb4b1e6c9f 71079 mew-beta_7.0.50~6.3.50+0.20110325-1.debian.tar.gz 078b527247e03aefe745a45eb91e8e0f0cdba3e1 836400 mew-beta_7.0.50~6.3.50+0.20110325-1_all.deb 1dfd0bae997ec2f7258682f1c8efa303f1aa1c0e 61230 mew-beta-bin_7.0.50~6.3.50+0.20110325-1_i386.deb Checksums-Sha256: 50ca295367fd93c4066edb8b323cbb8f6e6445e31894b46bee3e632b77318297 1186 mew-beta_7.0.50~6.3.50+0.20110325-1.dsc c20f45c0c5bfd2ad2ae748873eabcf325aa3cd8af1952f201bce0d29cf34a185 1026638 mew-beta_7.0.50~6.3.50+0.20110325.orig.tar.gz 2320e1cec5695892b02d84f91e9a38f9fd3d96de65465105159c5591c66a6aee 71079 mew-beta_7.0.50~6.3.50+0.20110325-1.debian.tar.gz 5305681d3bf7e0fe6d587ec8a750c22c52b86e04844c78be88f77ff3e967d015 836400 mew-beta_7.0.50~6.3.50+0.20110325-1_all.deb 19000394244221c840fec80b27327b2ba4ce78a0383c5c53996deea10f8e9dd9 61230 mew-beta-bin_7.0.50~6.3.50+0.20110325-1_i386.deb Files: 4655955a8357c43e9c05cf1d3a515227 1186 mail extra mew-beta_7.0.50~6.3.50+0.20110325-1.dsc 191928c83cf7fdd23c8eab01274fa9d2 1026638 mail extra mew-beta_7.0.50~6.3.50+0.20110325.orig.tar.gz 1dce9d6384938b7f444f8f324e33515c 71079 mail extra mew-beta_7.0.50~6.3.50+0.20110325-1.debian.tar.gz b7be0abfff070fbbfeefa39c01e22dd9 836400 lisp extra mew-beta_7.0.50~6.3.50+0.20110325-1_all.deb 0bbfad937aa7a454b293f008875d6cb8 61230 mail extra mew-beta-bin_7.0.50~6.3.50+0.20110325-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3BFrAACgkQgV4LPvpMUpjE+ACfc1YmSihfyiK2Z3kHPlkRE6Z/ deQAn2o6zJ7FuwzQMluN4TwG4JUcamLp =JRjy -END PGP SIGNATURE- Accepted: mew-beta-bin_7.0.50~6.3.50+0.20110325-1_i386.deb to main/m/mew-beta/mew-beta-bin_7.0.50~6.3.50+0.20110325-1_i386.deb mew-beta_7.0.50~6.3.50+0.20110325-1.debian.tar.gz to main/m/mew-beta/mew-beta_7.0.50~6.3.50+0.20110325-1.debian.tar.gz mew-beta_7.0.50~6.3.50+0.20110325-1.dsc to main/m/mew-beta/mew-beta_7.0.50~6.3.50+0.20110325-1.dsc mew-beta_7.0.50~6.3.50+0.20110325-1_all.deb to main/m/mew-beta/mew-beta_7.0.50~6.3.50+0.20110325-1_all.deb mew-beta_7.0.50~6.3.50+0.20110325.orig.tar.gz to main/m/mew-beta/mew-beta_7.0.50~6.3.50+0.20110325.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qha0g-00046p...@franck.debian.org
Accepted mhddfs 0.1.38 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Wed, 04 May 2011 12:23:01 +0400 Source: mhddfs Binary: mhddfs Architecture: source amd64 Version: 0.1.38 Distribution: unstable Urgency: low Maintainer: Dmitry E. Oboukhov un...@debian.org Changed-By: Dmitry E. Oboukhov un...@debian.org Description: mhddfs - file system for unifying several mount points into one Changes: mhddfs (0.1.38) unstable; urgency=low . * Apply hardlinks patch, big thanks for patch to Dermot Duffy dermot.du...@gmail.com. Checksums-Sha1: 048709111b4252d6dc6970b443a3abdfd25353a8 824 mhddfs_0.1.38.dsc b76c0040c978ea19e1c905f19c1a8158918f666d 41173 mhddfs_0.1.38.tar.gz 1646b028e8bd75b31238741d62f84ada9df80fe9 26604 mhddfs_0.1.38_amd64.deb Checksums-Sha256: 72f3b114b3490f6571371fcf4f6250a688669a7b0cf7ba1c1aecef3848ea 824 mhddfs_0.1.38.dsc 12eeb8a8ba4b8efe9467c1636c7903c4a9c1986d0ba6e538beba230953f8bb9c 41173 mhddfs_0.1.38.tar.gz c261f5421407f59bd8d00d07296f7d9a4036a70da7bc1818f274336f8834d13f 26604 mhddfs_0.1.38_amd64.deb Files: 976503b29624a846c494d24768b75319 824 utils extra mhddfs_0.1.38.dsc b6b0a340335aaedddb8c2ba40c6b1543 41173 utils extra mhddfs_0.1.38.tar.gz 4a4f1e82cbb518fc4282c452cbadd464 26604 utils extra mhddfs_0.1.38_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREDAAYFAk3BEDwACgkQq4wAz/jiZTd+XQCgwVhvpTMANGdOwr4umHcat1QG lLcAoL5vIxXeeq4jgbJjZB2eoMvns+q8 =7cRG -END PGP SIGNATURE- Accepted: mhddfs_0.1.38.dsc to main/m/mhddfs/mhddfs_0.1.38.dsc mhddfs_0.1.38.tar.gz to main/m/mhddfs/mhddfs_0.1.38.tar.gz mhddfs_0.1.38_amd64.deb to main/m/mhddfs/mhddfs_0.1.38_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qha11-0004b1...@franck.debian.org
