po-ifier la description d'un paquet
Salut, J'ai un paquet tout neuf qui n'attend que l'upload vers les serveurs de Debian et je voudrais tratuire la description du paquet... Par contre, je bloque à po-itification du fichier... Quel est le format à passer à po4a ? Je n'ai pas trouvé de doc qui parle de cela (même si la page de documentation est très complète). Merci, PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:p.karatchentz...@free.fr |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_) -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: po-ifier la description d'un paquet
Patrice Karatchentzeff patrice.karatchentz...@gmail.com (06/04/2009): J'ai un paquet tout neuf qui n'attend que l'upload vers les serveurs de Debian et je voudrais tratuire la description du paquet... http://ddtp.debian.net/ Mraw, KiBi. signature.asc Description: Digital signature
Re: po-ifier la description d'un paquet
Le 6 avril 2009 15:54, Cyril Brulebois k...@debian.org a écrit : Patrice Karatchentzeff patrice.karatchentz...@gmail.com (06/04/2009): J'ai un paquet tout neuf qui n'attend que l'upload vers les serveurs de Debian et je voudrais tratuire la description du paquet... http://ddtp.debian.net/ On est d'accord qu'il y a des gens qui arrivent à le faire : je demande à le faire avant d'envoyer le paquet dans l'archive... PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:p.karatchentz...@free.fr |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_) -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: po-ifier la description d'un paquet
Le 6 avril 2009 16:15, Mike Hommey m...@glandium.org a écrit : On Mon, Apr 06, 2009 at 04:12:24PM +0200, Patrice Karatchentzeff patrice.karatchentz...@gmail.com wrote: Le 6 avril 2009 15:54, Cyril Brulebois k...@debian.org a écrit : Patrice Karatchentzeff patrice.karatchentz...@gmail.com (06/04/2009): J'ai un paquet tout neuf qui n'attend que l'upload vers les serveurs de Debian et je voudrais tratuire la description du paquet... http://ddtp.debian.net/ On est d'accord qu'il y a des gens qui arrivent à le faire : je demande à le faire avant d'envoyer le paquet dans l'archive... Hint: les traductions ne sont pas dans les paquets. Bonne remarque :) 1) faudrait peut-être changer :) 2) autant le faire pour ceux qui en ont envie ? Bon, ça ne résout pas mon problème pour autant... PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:p.karatchentz...@free.fr |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_) -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: po-ifier la description d'un paquet
Le 6 avril 2009 16:49, Cyril Brulebois k...@debian.org a écrit : Patrice Karatchentzeff patrice.karatchentz...@gmail.com (06/04/2009): Bonne remarque :) 1) faudrait peut-être changer :) [...] Suggestion : le chat, là, il se réveille, il regarde la taille du Packages.gz, il imagine ce que ça donne avec whatmille traductions de descriptions en plus, il en tire les conclusions et il se rendort. Et les paquets qui se trimballent les traductions des logiciels, ils font comment ? PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:p.karatchentz...@free.fr |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_) -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. - NMU version number - first changelog line contains TU / team upload / team NMU / ... - no need to put patch in bug - no need for NMU delay - no need to upload to delayed queue My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Monday 06 April 2009, Christian Perrier wrote: Quoting William Pitcock (neno...@dereferenced.org): lilo is due for removal anyway due to being unmaintained upstream and the widespread availability of alternatives. I think that last part is debatable. I do not have time to manage the removal at this point, but it will be gone by June. Has the package already been offered for adoption? Preferably with an overview of its current (upstream) status and main issues. I'd say that if there's anybody willing to (actively) maintain it, it should not be removed. This is a heads up mail for the D-I team. I'm not sure where the original mail comes from, but IMO this should be discussed on d-devel, especially since it impacts more than just D-I. I suspect there are quite a few packages that make some sort of provisions for lilo. There are also significant numbers of people still using lilo for, at least for them, very good reasons. Anyone remember the fairly big upset when lilo was removed from testing around D-I Lenny Beta2? Don't we have some install paths that still depend on LILO? Yes: /boot on LVM is the main one. Anyway, even if we don't, I think we should track that lilo removal and coordinate with William, in order to stop providing lilo-installer. And, I think this should be mentioned as a release goal (dropping lilo). Either high priority if we have install paths depending on lilo, or normal priority otherwise. D-I release goal or Debian release goal [1]? IMO the latter could well be justified as there will also need to be some kind of upgrade strategy for existing users that does not make uncontrolled changes on their hard disk or loses them the ability to boot alternative OSes on dual (or multi) boot systems. Cheers, FJP [1] goal is a somewhat strange term here... signature.asc Description: This is a digitally signed message part.
Re: Team uploads
On Mon Apr 06 08:18, Lionel Elie Mamane wrote: On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. Quite apart from the issue of deciding whether or not something is 'team maintained' in all cases, if you are a member of the team and you are making uploads to the package, then you should just add yourself to uploaders, surely...? That said, the option so far which is least bad is Team Upload in the same way as QA Upload, i.e. no NMU version number, no NMU procedures, no delay, etc, just something to ack the mismatch of changed-by and uploaders/maintainer. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Team uploads
On Mon, Apr 06, 2009 at 08:18:33AM +0200, Lionel Elie Mamane wrote: On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. - NMU version number - first changelog line contains TU / team upload / team NMU / ... - no need to put patch in bug - no need for NMU delay - no need to upload to delayed queue My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. I don't understand; what is the problem with team uploads? Sure, there can be problems in inactive teams, but just because some packages had team uploads doesn't mean they need special QA attention. Besides, I think the Gnome team still puts all team members into Uploaders via some debian/control pre-processing, maybe for the above reason. Getting rid of debian/control.in (unless needed otherwise) due to better team maintership handling might be good thing. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon Apr 06 08:55, Frans Pop wrote: This is a heads up mail for the D-I team. I'm not sure where the original mail comes from, but IMO this should be discussed on d-devel, especially since it impacts more than just D-I. I suspect there are quite a few packages that make some sort of provisions for lilo. There are also significant numbers of people still using lilo for, at least for them, very good reasons. Yes, please do discuss it here. I am one of those users, grub didn't work on one of my machines for some reason. Anyway, isn't grub1 equally unmaintained upstream? I thought they were only working on grub2 (which isn't ready for use yet, or is it?) Don't we have some install paths that still depend on LILO? Yes: /boot on LVM is the main one. We _certainly_ shouldn't throw it out if there are _known_ situations for which it's required. By all means print large warnings or only make it available in expert mode, or whatever, but please don't break existing functionality. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Team uploads
On Mon, Apr 06, 2009 at 09:27:53AM +0200, Michael Banck wrote: On Mon, Apr 06, 2009 at 08:18:33AM +0200, Lionel Elie Mamane wrote: On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. - NMU version number - first changelog line contains TU / team upload / team NMU / ... - no need to put patch in bug - no need for NMU delay - no need to upload to delayed queue My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. I don't understand; what is the problem with team uploads? Sure, there can be problems in inactive teams, but just because some packages had team uploads doesn't mean they need special QA attention. Just like NMUs: just because a package had a small number of NMUs does not mean it needs special QA attention. But a pattern of only NMUs is a tag for QA attention. As Paul means them (I'm in the team, but for this particular package I do work on it once, but don't take charge for any future work), team uploads have the same characteristic: if there are only team uploads, it is an indicator that nobody within the team feels responsible for the package. Yes, there can be corner cases where this is not the case. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: I'm putting the acpi-support package up for adoption. The RFA bug is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683 Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes, the acpi team will welcome new members who like to help too. :-) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise a écrit : In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? Hi Paul, I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Hi Steve, On Mon, April 6, 2009 05:44, Steve Langasek wrote: On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: 1. The upstream for this package is Ubuntu. Ubuntu has never been very cooperative at accepting changes, until recently: our contact Steve Langasek has indicated that he is interested in merging most or all of our changes, provided that we send them in in chunks, with proper rationales. I have to say here in defense of Ubuntu that I don't see any record of these patches being submitted to the Ubuntu package via Launchpad, which, since Ubuntu does not have individual package maintainers, is the only reliable way to ensure that proposed changes are seen and considered by the people working on the package at any given time. Yeah, I think it's probably mostly me being disappointed earlier, and not so much the Ubuntu side. The feeling that I have had is that because there are no individual package maintainers, it's hard to find somebody on the other side who feels responsible for the package, and who is willing to discuss merging of sets of patches etc., so that you can discuss the chances of acceptance _before_ you do the work. It's so much easier if you can talk to a person, launchpad sometimes feels like throwing stuff into a black hole. /rant Things suddenly got much easier when I got into direct contact with you. But I shouldn't be blaming Ubuntu, my expectations just didn't match the way Ubuntu works. I don't have time to work on the Debian package myself (either as maintainer or for sifting through the delta between Debian and Ubuntu), but I definitely am happy to accept fixes upstream in reasonable-sized chunks. Anyway, as Bart points out, there's another issue: 4. Ubuntu is PHASING OUT this package. They have already moved suspend to pm-utils (but have failed to remove suspend support from acpi-support). They're currently moving hotkey translation to hal. This means that soon we will have no upstream that we can follow! Or we should ensure that Ubuntu's hal changes are included in our version of hal as well -- no clue how those packages are related, or whether Ubuntu's changes are going into upstream hal. Since the last time I had a chance to speak with Bart about this, there's been quite a bit of progress on phasing out the package for Ubuntu; in jaunty, we've dropped a number of quirk scripts related to suspend/resume, as well as close to 30 of the ACPI event-handling scripts from /etc/acpi - basically: all those scripts that were being used to synthesize key events (which doesn't work with recent kernels anyway) and which we could verify were being handled by hal. And yes, Martin Pitt works very closely with hal upstream to ensure fixes are incorporated. Thanks for the update! Cheers, Bart -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Japanese Font Transition (step for applications)
Le lundi 06 avril 2009 à 06:18 +0900, Hideki Yamane a écrit : On Thu, 20 Nov 2008 14:51:28 +0100 Josselin Mouette j...@debian.org wrote: In which case the correct approach, I think, is to remove all the ttf-japanese-* in Provides:, and upload new ttf-japanese-gothic/mincho packages that depend on a set of alternative fonts, with a reasonable default. Does it mean that - craete virtual ttf-japanese-gothic/mincho package - it depends on ttf-vlgothic or so Is it correct? If so, I'll make package for that and do ITP. Yes, that’s the idea (although I’d call this a metapackage and not a virtual package). -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#522741: ITP: ieee-data -- Organizationally Unique Identifier listing
Package: wnpp Severity: wishlist Owner: Filippo Giunchedi fili...@debian.org * Package name: ieee-data Version : 20090224 Upstream Author : IEEE * URL : http://standards.ieee.org/regauth/oui/index.shtml * License : not clear if it can be public domain Programming Lang: Plain text Description : Organizationally Unique Identifier listing Provide the OUI listing of identifiers registered with IEEE. Include also Individual Address Block (IAB) listings. Preliminary package available at http://svn.debian.org/wsvn/collab-maint/deb-maint/ieee-data/trunk/#_deb-maint_ieee-data_trunk_ I've contacted IEEE to clear about the copyright/license of the listings. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, Apr 06, 2009 at 05:05:40PM +0900, Charles Plessy wrote: Le Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise a écrit : In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? Hi Paul, I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? But it's not an NMU, the Team is effectively the maintainer. If the team isn't the maintainer, it's not team-maintained, by definition, I'd say. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Meskes wrote: On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: I'm putting the acpi-support package up for adoption. The RFA bug is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683 Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes, the acpi team will welcome new members who like to help too. :-) Thanks for helping out! It sounds like a very good plan to move acpi-support to the acpi team. I will do what's necessary to transfer maintainership to you, I'll keep you informed of the progress. Cheers, Bart -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Mon, 06 Apr 2009, Bart Samwel wrote: black hole. /rant Things suddenly got much easier when I got into direct contact with you. But I shouldn't be blaming Ubuntu, my expectations just didn't match the way Ubuntu works. To be fair, I proposed co-maintenance to Matthew Garrett when I integrated acpi-support in Debian and wanted him to use bzr or something so that we could better collaborate but at that time he was already telling me that acpi-support should/will die and he wasn't interested in setting up something more complicated than change upload. I didn' went further to try to collaborate and at that time was packaging it mostly as a follower of Ubuntu but bugs did accumulate until Bart took it over. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Monday 06 April 2009 08:18:33 Lionel Elie Mamane, vous avez écrit : My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. I do not agree with you. In the ocaml team, I have prepared uploads for some transitions for package for which I am not in the uploader field. I am not in the uploaders because I am not the main responsible for this packaging, however my upload uses the correct workflow, and does not mean that there is no maintainer, but only that for small repetitive tasks, another member of the team can take care of it. Hence, requiring NMU versioning and external patch system would really be a waste of time that would anihilate the efficiency of working in a team. That said, I have nothing strong against the lintian warning. After all, it is only a warning, and the NMU issues can be worked-out between human beings for sure... :-) Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
Le Monday 06 April 2009 09:32:14 Matthew Johnson, vous avez écrit : Don't we have some install paths that still depend on LILO? Yes: /boot on LVM is the main one. We _certainly_ shouldn't throw it out if there are _known_ situations for which it's required. By all means print large warnings or only make it available in expert mode, or whatever, but please don't break existing functionality. Agreed 100% ! I also use lilo for /boot on LVM and I also clearly remember that was the major reason for the previous debate about the removal of lilo. I don't see what has changed so far which may change the situation compared to that time.. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, Apr 06, 2009 at 10:46:19AM +0200, Romain Beauxis wrote: Le Monday 06 April 2009 08:18:33 Lionel Elie Mamane, vous avez écrit : My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. I do not agree with you. In the ocaml team, I have prepared uploads for some transitions for package for which I am not in the uploader field. I am not in the uploaders because I am not the main responsible for this packaging, however my upload uses the correct workflow, and does not mean that there is no maintainer, but only that for small repetitive tasks, another member of the team can take care of it. Yes, but if the main responsible for this package has done no work on it for three years, it is a sign that maybe he doesn't feel responsible anymore, or does not have time anymore or something like that. Not proof, just a sign. Just like NMUs. It falls in very well in the example you gave; some transitions were handled by mass-bug filing + delay + NMU of packages that had not transitioned, so the situation looks similar. For team uploads we remove the bug filing, the delay, most of the NMU procedures (delay, special handling of introduced patch, ...), but keep the NMU numbering. Hence, requiring NMU versioning and external patch system I did not say one should require an external patch system, quite the contrary. I wrote no need to put patch in bug, generalise that to no need to treat the change / patch specially; just commit it in the team's VCS repository, if that's what is usually done in that team. would really be a waste of time that would anihilate the efficiency of working in a team. The only burden I propose imposing is the NMU versioning, which does not feel to me like it is additional work. Instead of writing -3, write -2.1; only two keystrokes more. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, Apr 6, 2009 at 4:49 PM, Romain Beauxis wrote: I also use lilo for /boot on LVM and I also clearly remember that was the major reason for the previous debate about the removal of lilo. Grub2 in lenny and later contains an lvm module: /usr/lib/grub/i386-pc/lvm.mod Has anyone who uses lilo for this tried grub2? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, 06 Apr 2009, Lionel Elie Mamane wrote: Just like NMUs: just because a package had a small number of NMUs does not mean it needs special QA attention. But a pattern of only NMUs is a tag for QA attention. As Paul means them (I'm in the team, but for The point of team upload is precisely so that you can update the package and not take responsibility for a package that you don't want to maintain in the long run. I was in many Uploaders field because lintian complain if you are not in Uploaders/Maintainer, yet I was there only for a single team upload for a perl or a python transition and using an NMU version would have been wrong because everything was properly done in the team VCS and there was no NMU to integrate for the next person working on the package. So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. Then, the Maintainer/Uploader field would be again more accurate to know if we have people that care about the packages or not. So I see this change as good move to better detect that nobody cares about the package. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, 06 Apr 2009, Charles Plessy wrote: I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? IIRC that concept died when we introduced version tracking so it should cause any problem. Bugs are always version closed (and no more tagged fixed/fixed-in-nmu). Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Preparing for GTK 3.0 and GNOME 3
Hi, although for various reasons (mostly ongoing transitions) we are quite late in packaging GNOME 2.26 in Debian, we should also look at the future. GTK+ 3.0 is planned around march 2010, and GNOME 3.0 a little while later. With them comes the final deprecation of many GNOME 2.X interfaces. It took a very long time (8 years!) to get rid of GTK+ 1.2 and the process is in its final stage now. I’d like to avoid this horrible mess for GTK+ 2.X and for the GNOME libraries that will stop being maintained upstream after the 3.0 release. Fortunately, GTK+ 3.0 is an evolutionary change, not a revolutionary one. Which means for some applications there will be zero porting work, and for most of them there will only be minor changes required. For GNOME libraries, the changes will be more radical. This concerns less applications, but several libraries will simply disappear. What you can do right now is start to work on packages using the GNOME library stack. For affected packages, you can start working on patches right now, or at least pester your upstream so that they do. Now for the various pieces. GLIB The changes in GLib will mostly concern in removing deprecated APIs. If your packages build with -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES, they are most likely to build with GLib 3.0 with only compilation changes. Removed functions have replacements described in the API documentation. GDK / GTK+ Same as GLib. If you can build your package with GTK+ 2.16 using -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES, it is very likely that your package can build with GTK+ 3.0. ESOUND Applications still using EsounD should be ported to using libcanberra (for sound events) or GStreamer (for the rest). GCONF There are plans to replace GConf by dconf, but it is quite certain that there will be at least a GConf compatiliby layer, so there is nothing to be done here. GNOME-VFS GnomeVFS has been deprecated for a while in favor of GIO, but porting is not something trivial. The GIO API documentation has some notes on how to port from GnomeVFS. LIBART It is now preferred to draw custom objects directly using Cairo, using the gdk_cairo_* API. LIBBONOBO / LIBBONOBOUI This part is completely going away, and it’s not easy. Replacing it generally means revamping parts of the application to use D-Bus for communication instead. LIBIDL / ORBIT ORBit will stay as a general-purpose CORBA implementation, but it is not meant to be used in GNOME applications anymore – currently its primary users are GConf and Bonobo. LIBGLADE Libglade is going away in favor of GtkBuilder. LIBGNOME This collection of random APIs with various uses is completely going away. The replacements are scattered among various libraries now: * GnomeProgram = GLib, libunique * gnome_execute_* = GLib (g_spawn) * gnome_gconf = GConf * gnome_help, gnome_url = GIO (g_app_info) * gnome_sound = libcanberra * Various stuff in GLib * More information: http://live.gnome.org/LibgnomeMustDie LIBGNOMEUI Same issue as with libgnome, the replacements depend on what the API is originally about. * gnome_init = GLib (GOption) * GnomeClient = Session management will be added to GTK+, it’s still missing AFAIK * The various widgets have replacements in GTK+ now. LIBGNOMECANVAS Deprecated in favor of libcairo. LIBEEL It has never been a widely used library, and it will be gone after 2.24. Replacements can be found in GTK+ for some widgets, for some others you will have to look at how it is now done in Nautilus. GTKSOURCEVIEW GtkSourceView 1.X is already deprecated, you should upgrade to GtkSourceView 2.X now. LIBGNOMEPRINT / LIBGNOMEPRINTUI Both deprecated in favor of gtk-unix-print (in GTK+) which is based on Cairo. LIBNAUTILUS-BURN It is going to be replaced with libbrasero-burn which has a very similar API. Now let’s get to work. FWIW, the end of the evolution transition should be tonight, so you’re going to see things move in the GNOME area really soon. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Team uploads
On Mon, 06 Apr 2009, Emilio Pozuelo Monfort wrote: Raphael Hertzog wrote: So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. You can put the team name and mailing list in the changelog. That will avoid the lintian warning and you can look for team uploads by looking at uploads with the team name in the Changed-By field. A recent example: I have seen that already but it's ugly as well. Changelog are written by humans and not lists and I like to have the name of someone (to blame) in the changelog entry. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On 06/04/09 at 19:48 +0900, Charles Plessy wrote: Le Mon, Apr 06, 2009 at 12:13:45PM +0200, Raphael Hertzog a écrit : On Mon, 06 Apr 2009, Charles Plessy wrote: I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? IIRC that concept died when we introduced version tracking so it should cause any problem. Bugs are always version closed (and no more tagged fixed/fixed-in-nmu). Good :) Does it mean that the Developers Reference must be updated? Index: pkgs.dbk === --- pkgs.dbk (revision 6668) +++ pkgs.dbk (working copy) @@ -2073,13 +2073,6 @@ work on it. /para -para -To acknowledge an NMU, include its changes and changelog entry in your next -maintainer upload. If you do not acknowledge the NMU by including the -NMU changelog entry in your changelog, the bugs will remain closed in the -BTS but will be listed as affecting your maintainer version of the package. -/para - /section section id=nmu-binnmu No, that's still correct. If you don't include the changelog entry fixing the bug, then the BTS' version tracking will be confused, and think that your version still has the bug. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Jack Audio Connection Kit transition
* Felipe Sateler [Tue, 31 Mar 2009 08:58:23 +1100]: * plan for libjack0.100.0-0: there are 11 source packages left with dependencies on this old library. No sourceful uploads are needed for this: once you’ve gotten back to me that the plan is good, I will provide you with a list of packages and schedule Bin-NMUs; then you can do some work of checking if they built successfully everywhere, filing bugs, etc. Once all of them have been rebuilt (which will make them depend on libjack0), please check with us that they’ve migrated to testing, and at that point libjack0.100.0-0 can be dropped. Sounds good? Amsynth will require a sourceful upload, since the dependency is not generated by dpkg-shlibdeps because it dlopens libjack. It is the only one I saw. I’ve scheduled Bin-NMUs for this, for all packages except amsynth. You can check for build-failures here: http://bit.ly/zLyiK, and for progress of their migration here: https://buildd.debian.org/transitions/summary.html. As mentioned above, please check with us before dropping the libjack0.100.0-0 package. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: new virtual package: readline-editor
On Mon, Apr 06, 2009 at 12:44:54PM +0200, Stefano Zacchiroli wrote: Heya, we have several packages implementing line-editing capabilities. I know at least 3 of them: cle, ledit, and rlwrap, but there might be others. Oh yes. Hmm... cle is dead upstream, rather buggy with no progress whatsoever in a very long time; it was mainly useful before rlwrap appeared in the real world (not as C source code in /usr/share/doc/libreadline-dev/examples/, but in /usr/bin/), so I'd think we should rather remove it. (...) they all seem to offer a common interface NAME command that will run command equipped with line editing capabilities. Some packages benefit generically from line editing capabilities without caring about the actual tool implementing it. (...) I hereby propose to introduce a new virtual package called readline-editor [1] provided by all tools offering line editing capabilities as a command wrapper. For the rest, yes, sure, that's good progress. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Again: Bug#503367: plink: file conflict with putty-tools
Andreas Tille wrote: On Fri, 3 Apr 2009, Steffen Moeller wrote: we should ask the technical committee to rule over it. And maybe this needs some voting in the end. Who is this *we*? Do you volunteer? :) no, since I personally see no preferable alternative to the current conflicting state. IMHO plink should be renamed because it is way less popular than the putty tool. So we will loose this voting anyway and there is much effort for an foreseable outcome. IMHO the solution I described in README.Debian is reasonable for plink users even with existing scripts. Morten's suggestion of a rename to purcell_plink (or plink_purcell) seems reasonable to me. snplink I find strange and as it was mentioned in the initial thread, there an earlier program with that name. I personally think that we should not rename it. And putty's plink should not be renamed either. The two are in a technical conflict, though with little practical consequences. To me, this situation is preferable over the renaning of the binary of either. This is a worse solution than a rename. In your view, I know. Please keep in mind that we don't need to package everything. (sn)plink can just be removed from the archive. Or could it move to non-free si it does not adhere to Debian's principles? I need to reread the policy here. Moving to non-free will not solve the problem and is just wrong (because it is actually not non-free). Trying to solve a problem by pretending wrong facts is a no go. I know what you mean. I'd strongly recommend to settle (together with upstream) for a reasonable alternative name (I don't care whether it is snplink, Plink, PLINK or something else) but we should find a reasonable decision in a short time frame (to not spend to power into an issue which does not bring anybody foreward). If _I_ was upstream, with a program that has such a strong name in the community, I would not change it lightheartedly. PLINK would certainly remain PLINK, the only chance I'd see is that upstream leaves the name PLINK for its software and renames the binary alone and then towards something that is very similar to the old one, maybe p_link or so. But this should possibly be synced with a general API overhaul or so. The conflict in my view is a problem of Debian or of UNIX in general, not of either of the two plinks. We should have namespaces of some sort and not everything in one directory. Best, Steffen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Mon, Apr 06, 2009 at 12:52:22PM +0200, Lucas Nussbaum a écrit : On 06/04/09 at 19:48 +0900, Charles Plessy wrote: Le Mon, Apr 06, 2009 at 12:13:45PM +0200, Raphael Hertzog a écrit : On Mon, 06 Apr 2009, Charles Plessy wrote: I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? IIRC that concept died when we introduced version tracking so it should cause any problem. Bugs are always version closed (and no more tagged fixed/fixed-in-nmu). Good :) Does it mean that the Developers Reference must be updated? No, that's still correct. If you don't include the changelog entry fixing the bug, then the BTS' version tracking will be confused, and think that your version still has the bug. Aah thank you, that is clearer: I thought that it was meaning that it is still needed to re-iterate the Closes: command. So if we assume that in the case of “team uploads” the changes would be commited in the teams repository, as opposed to NMUs were the diff is sent to the BTS, it would definitely be useful to have the Debian tools to understand that it is correct that the person signing the changelog is not listed in the Uploaders: not the Maintainer: field. Would it be wrong to use the “ * QA upload” special first line, or is it better to reserve it to the QA team ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522753: ITP: primrose -- compelling tile-placement puzzle game
Package: wnpp Severity: wishlist Owner: Paul Wise p...@debian.org X-Debbugs-CC: debian-devel-ga...@lists.debian.org * Package name: primrose Version : 5 Upstream Author : Jason Rohrer * URL : http://primrose.sf.net * License : None (Public Domain) Programming Lang: C++, PHP Description : compelling tile-placement puzzle game Long description will be a distillation of the description linked from the above URL. This will be maintained by the pkg-games team. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Preparing for GTK 3.0 and GNOME 3
Hi, I wonder whether this shouldnt have been on d-d-a. I think it should have :) regards, Holger, now also wondering if I should send this mail in private ;-) signature.asc Description: This is a digitally signed message part.
Bug#522770: RM: cle -- ROM; dead uptream; buggy; better alternatives available
Package: ftp.debian.org Severity: normal Please remove package cle from unstable / testing; source and binaries. It is dead upstream (no release since 1999), and since I uploaded it to Debian better alternatives have appeared (such as rlwrap). Some Debian-local work has been done in the rather distant past to fix bugs in it, but they never converged to something that works well in all cases: when trying to get one program to work, it breaks others. As far as I know, rlwrap does not share any of the bugs of any version of cle, making it a strictly better alternative; it is what I use myself now. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
Matthew Johnson mj...@debian.org writes: On Mon Apr 06 08:55, Frans Pop wrote: This is a heads up mail for the D-I team. I'm not sure where the original mail comes from, but IMO this should be discussed on d-devel, especially since it impacts more than just D-I. I suspect there are quite a few packages that make some sort of provisions for lilo. There are also significant numbers of people still using lilo for, at least for them, very good reasons. Yes, please do discuss it here. I am one of those users, grub didn't work on one of my machines for some reason. Anyway, isn't grub1 equally unmaintained upstream? I thought they were only working on grub2 (which isn't ready for use yet, or is it?) So lets get grub2 working everywhere. :) A worthy goal. Don't we have some install paths that still depend on LILO? Yes: /boot on LVM is the main one. We _certainly_ shouldn't throw it out if there are _known_ situations for which it's required. We just shouldn't have /boot on lvm. At least there should be one place outside lvm to store /etc/lvm/archive and /etc/lvm/backup so that in the case lvm breaks (gets broken by the user) one can repair it. Linking them to /boot/lvm/archive and /boot/lvm/backup with /boot outside lvm seem like a good idea. The problem with /boot on lvm is that moving or resizing it can break it. So I always found it a good partition to keep outside lvm. By all means print large warnings or only make it available in expert mode, or whatever, but please don't break existing functionality. Matt -- Matthew Johnson MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
new virtual package: readline-editor
Heya, we have several packages implementing line-editing
capabilities. I know at least 3 of them: cle, ledit, and rlwrap,
but there might be others. Some are implemented on top of GNU
readline, some are not (e.g. ledit), nevertheless they all seem to
offer a common interface NAME command that will run command equipped
with line editing capabilities.
Some packages benefit generically from line editing capabilities
without caring about the actual tool implementing it. My example is
ocaml which has an interactive top-level with no built-in line
editing capabilities, but there are others.
I hereby propose to introduce a new virtual package called
readline-editor [1] provided by all tools offering line editing
capabilities as a command wrapper. The implementation should be via
alternatives; as priorities I propose having higher priority for those
implemented on top of GNU readline, because apparently they are
superior to ledit (e.g., they share a persistent history).
If there are no objections I'll submit patches to the three mentioned
packages, and possibly to the other matching the category.
Comments?
Cheers.
[1] An apparently more natural name could have been line editor, but
in the UNIX world it has been traditionally used to refer to
things like ed, and can be misleading.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Team uploads
Raphael Hertzog wrote: So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. You can put the team name and mailing list in the changelog. That will avoid the lintian warning and you can look for team uploads by looking at uploads with the team name in the Changed-By field. A recent example: python-markdown (1.7-2) unstable; urgency=low [ Sandro Tosi ] * debian/control - switch Vcs-Browser field to viewsvn [ Emilio Pozuelo Monfort ] * debian/rules: Don't rely on python-support directory structure. Thanks Josselin Mouette. Closes: #517061. * Standards-Version is 3.8.0. No changes needed. -- Debian Python Modules Team python-modules-t...@lists.alioth.debian.org Wed, 25 Feb 2009 23:35:20 +0100 signature.asc Description: OpenPGP digital signature
Re: New architectures
Joerg Jaspert jo...@ganneff.de disait : we just added two new architectures to the Debian archive. Everybody please welcome kfreebsd-i386 AKA GNU/kFreeBSD i386 kfreebsd-amd64 AKA GNU/kFreeBSD amd64 Hi Joerg, What should be done with amd64-libs and ia32-libs now? Can we add those archs to it as they are? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, 06 Apr 2009, Lionel Elie Mamane wrote: would really be a waste of time that would anihilate the efficiency of working in a team. The only burden I propose imposing is the NMU versioning, which does not feel to me like it is additional work. Instead of writing -3, write -2.1; only two keystrokes more. Too many tools assume that an NMU version is an NMU… for example the PTS would warn that a NMU has to be integrated/acknowledged. I don't see what the NMU versioning buys us. The fact that Uploaders is no more cluttered by entries for people that don't feel responsible seems like to compensate what the NMU versioning would bring us. You can also count the number of consecutive entries that use an email not listed in Uploaders to get a somewhat similar statistic than the one you're looking for. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Monday 06 April 2009 12:27:22 Raphael Hertzog, vous avez écrit : You can put the team name and mailing list in the changelog. That will avoid the lintian warning and you can look for team uploads by looking at uploads with the team name in the Changed-By field. A recent example: I have seen that already but it's ugly as well. Changelog are written by humans and not lists and I like to have the name of someone (to blame) in the changelog entry. Hummm... For blaming, there should be the specific name of the responsible in the changelog. Also, it seems meaningful to me that the changelog is named after the team, it seems to be equivalent to the real world on behalf of the XXX team. A correct semantics could then be: $PACKAGE ($VERSION) unstable; urgency=low [ Romain Beauxis ] * Did a very bad thing -- Package Team package-t...@lists.alioth.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522772: ITP: CDO -- Climate Data Operators
Package: wnpp Severity: wishlist Owner: Alastair McKinstry mckins...@debian.org * Package name: CDO Version : 1.3.0 Upstream Author : Uwe Schulzweida uwe.schulzwe...@zmaw.de * URL : http://www.mpimet.mpg.de/fileadmin/software/cdo/ * License : GPL2 Programming Lang: C Description : Climate Data Operators - tools for climate data manipulation CDO is a collection of command line Operators to manipulate and analyse Climate model Data. Supported data formats are GRIB, netCDF, SERVICE, EXTRA and IEG. There are more than 400 operators available. The following table provides a brief overview of the main categories. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522775: ITP: EMOSLIB -- ECMWF Interpolation Library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry mckins...@debian.org * Package name: EMOSLIB Version : 000360 Upstream Author : European Centre for Medium-range Weather Forecasts * URL : http://www.ecmwf.int/products/data/software/interpolation.html * License : LGPL v2 Programming Lang: F, Fortran Description : ECMWF Interpolation Library The Interpolation library (EMOSLIB) includes Interpolation software and GRIB, BUFR, CREX encoding/decoding routines. It is used by the ECMWF meteorological archival and retrieval system (MARS) and also by the ECMWF graphics packag MetView. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon Apr 06 11:07, Goswin von Brederlow wrote: So lets get grub2 working everywhere. :) A worthy goal. Sure, but don't remove lilo until we're happy that grub2 does work everywhere. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Team uploads
On Mon, 06 Apr 2009, Romain Beauxis wrote: For blaming, there should be the specific name of the responsible in the changelog. Also, it seems meaningful to me that the changelog is named after the team, it seems to be equivalent to the real world on behalf of the XXX team. Except when you have multiple people listed you don't know who uploaded without resorting to who-uploads (or gpg check). Anyway, it's a matter of taste mainly. For me a changelog signature should refer to a human and not a mailing list. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
Frans Pop elen...@planet.nl writes: On Monday 06 April 2009, Christian Perrier wrote: [...] I do not have time to manage the removal at this point, but it will be gone by June. Has the package already been offered for adoption? Preferably with an overview of its current (upstream) status and main issues. I'd say that if there's anybody willing to (actively) maintain it, it should not be removed. Fully agree; it should be properly offered for adoption. This is a heads up mail for the D-I team. I'm not sure where the original mail comes from, but IMO this should be discussed on d-devel, especially since it impacts more than just D-I. I suspect there are quite a few packages that make some sort of provisions for lilo. There are also significant numbers of people still using lilo for, at least for them, very good reasons. Anyone remember the fairly big upset when lilo was removed from testing around D-I Lenny Beta2? I also share the feeling that a lot of people still uses LILO; if possible I do belive it should be kept. [...] -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Raphael Hertzog hert...@debian.org (06/04/2009): Except when you have multiple people listed you don't know who uploaded without resorting to who-uploads (or gpg check). Not to mention cases where 5 people are listed there, and the package got sponsored by even someone else (any idea how many NMs there were in pkg-games?). For me a changelog signature should refer to a human and not a mailing list. Indeed, I like to know who took the “this package can be uploaded” decision, which is a bit more important than just committing a fix in $VCS and adding ones name to the changelog. A bit of final review has to be done, to ensure the whole is consistent; and I expect the trailer line to tell me who did that work. Mraw, KiBi. signature.asc Description: Digital signature
Re: lilo about to be dropped?
On Mon, 6 Apr 2009 17:03:10 +0800 Paul Wise p...@debian.org wrote: On Mon, Apr 6, 2009 at 4:49 PM, Romain Beauxis wrote: I also use lilo for /boot on LVM and I also clearly remember that was the major reason for the previous debate about the removal of lilo. Grub2 in lenny and later contains an lvm module: /usr/lib/grub/i386-pc/lvm.mod Has anyone who uses lilo for this tried grub2? Yes, I do and it works without problems. There are some inconveniences, though, with grub2, which might make some stick with LILO: * on boot it takes quite some time for grub2 to scan the disks for LVM volumes * configuration of grub2 is really a PITA The is no simple configuration file that one could edit. You have to write scripts to add entries. You can't specify the default entry (only the number of the entry, which changes if a new kernel is installed) and there is no vmlinuz/vmlinuz.old (unless you add a script that adds these entries) You can't specify boot options per entry (there's only a global option in /etc/default grub, that applies to all entries). Cheers, harry signature.asc Description: PGP signature
Re: lilo about to be dropped?
I demand that Otavio Salvador may or may not have written... Frans Pop elen...@planet.nl writes: [snip] Anyone remember the fairly big upset when lilo was removed from testing around D-I Lenny Beta2? I also share the feeling that a lot of people still use LILO; if possible I do belive it should be kept. AOL. I for one use it, and intend to continue using it. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output less CO2 = avoid massive flooding.TIME IS RUNNING OUT *FAST*. Under Windows, a program will expand to fill all available virtual memory. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Petter Reinholdtsen dijo [Sat, Apr 04, 2009 at 06:42:29AM +0200]: Not quite sure what the question is. As far as I know, Debian supported tmpfs mounted /var/run when I become co-maintainer of sysvinit, and I have tried to keep it this way. The only recent changes it that it has become easier to enable it. Very good to notice that this now is documented in the policy. If you wonder what the advantages of tmpfs in /var/run is, I know of several, but do not really have time to track down them all. One of them I care specially about is the fact that it allow a computer to boot with a read-only local file system (think diskless workstations and thin clients booting LTSP, machines with flash disks and files with problems with their file systems), and I believe this is a clear advantage. Having tmpfs there also make it more obvious that the content of /var/run/ will be erased at boot. It does achieve not having bogus information on. If your system crashed, some crappy daemons will refuse to start if /var/run/crappyserver.pid exists, or will try to communicate with their peers using /var/run/sloppydaemon.socket, possibly failing cleanly, but possibly leading to head-scratching -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Monday 06 April 2009 16:08:36 Cyril Brulebois, vous avez écrit : Indeed, I like to know who took the “this package can be uploaded” decision, which is a bit more important than just committing a fix in $VCS and adding ones name to the changelog. A bit of final review has to be done, to ensure the whole is consistent; and I expect the trailer line to tell me who did that work. Couldn't this also be a line in the changelog ? This is not a standard but this is done in many cases: [ Romain Beauxis ] * Upload to $TARGET Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, 2009-04-06 at 16:17 +0200, Harald Braumann wrote:
On Mon, 6 Apr 2009 17:03:10 +0800
Paul Wise p...@debian.org wrote:
On Mon, Apr 6, 2009 at 4:49 PM, Romain Beauxis wrote:
I also use lilo for /boot on LVM and I also clearly remember that
was the major reason for the previous debate about the removal of
lilo.
Grub2 in lenny and later contains an lvm module:
/usr/lib/grub/i386-pc/lvm.mod
Has anyone who uses lilo for this tried grub2?
Yes, I do and it works without problems. There are some inconveniences,
though, with grub2, which might make some stick with LILO:
The LVM support in LILO is hideously broken, so these arguments do not
really matter. It only works in certain conditions and is known to break
horribly if you have say, a kernel spanning multiple PVs.
Only a true idiot boots off an LVM volume anyway, since there is risk of
metadata corruption, etc. The real reasoning for carrying LILO around is
for machines where grub1 does not work, and we have ext2linux for those
situations now.
* on boot it takes quite some time for grub2 to scan the disks for LVM
volumes
* configuration of grub2 is really a PITA
The is no simple configuration file that one could edit. You have to
write scripts to add entries.
/boot/grub/{menu.lst,grub.conf} is hard to edit...?
You can't specify the default entry (only the number of the entry,
which changes if a new kernel is installed) and there is no
vmlinuz/vmlinuz.old (unless you add a script that adds these entries)
default X in the config file, and setdefault, works for me.
You can't specify boot options per entry (there's only a global option
in /etc/default grub, that applies to all entries).
Sure you can, just don't use update-grub(1) and update it yourself
instead. Same as lilo, really.
William
signature.asc
Description: This is a digitally signed message part
Re: lilo about to be dropped?
Frans Pop wrote:
On Monday 06 April 2009, Christian Perrier wrote:
Quoting William Pitcock (neno...@dereferenced.org):
lilo is due for removal anyway due to being unmaintained upstream and
the widespread availability of alternatives.
I think that last part is debatable.
I do not have time to manage the removal at this point, but it will
be gone by June.
Has the package already been offered for adoption? Preferably with an
overview of its current (upstream) status and main issues. I'd say that
if there's anybody willing to (actively) maintain it, it should not be
removed.
This is a heads up mail for the D-I team.
I'm not sure where the original mail comes from, but IMO this should be
discussed on d-devel, especially since it impacts more than just D-I. I
suspect there are quite a few packages that make some sort of provisions
for lilo.
There are also significant numbers of people still using lilo for, at
least for them, very good reasons.
I totally agree.
But I think that lilo package description must be changed, warning new
users that lilo have several limits (thus not all kernel within debian
are bootable with lilo).
Maybe we could also require grub{,2} when installing lilo (chained
as other in lilo, for emergency, new debian kernel policies, etc),
but I don't know if it is feasible (e.g. when lilo is not in MBR).
ciao
cate
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, 2009-04-06 at 15:09 +0100, Darren Salt wrote: I demand that Otavio Salvador may or may not have written... Frans Pop elen...@planet.nl writes: [snip] Anyone remember the fairly big upset when lilo was removed from testing around D-I Lenny Beta2? I also share the feeling that a lot of people still use LILO; if possible I do belive it should be kept. AOL. I for one use it, and intend to continue using it. Have you looked into ext2linux? It is intended to supercede lilo. I think your usage requirements will be satisfied by it. William signature.asc Description: This is a digitally signed message part
Re: lilo about to be dropped?
On Mon, Apr 06, 2009 at 10:24:54AM -0500, William Pitcock neno...@sacredspiral.co.uk wrote: On Mon, 2009-04-06 at 16:17 +0200, Harald Braumann wrote: You can't specify boot options per entry (there's only a global option in /etc/default grub, that applies to all entries). Sure you can, just don't use update-grub(1) and update it yourself instead. Same as lilo, really. Even with update-grub, you can: ## If you want special options for specific kernels use kopt_x_y_z ## where x.y.z is kernel version. Minor versions can be omitted. ## e.g. kopt=root=/dev/hda1 ro ## kopt_2_6_8=root=/dev/hdc1 ro ## kopt_2_6_8_2_686=root=/dev/hdc2 ro This suits most needs. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, 2009-04-06 at 10:44 -0300, Otavio Salvador wrote: Frans Pop elen...@planet.nl writes: On Monday 06 April 2009, Christian Perrier wrote: [...] I do not have time to manage the removal at this point, but it will be gone by June. Has the package already been offered for adoption? Preferably with an overview of its current (upstream) status and main issues. I'd say that if there's anybody willing to (actively) maintain it, it should not be removed. Fully agree; it should be properly offered for adoption. This is a heads up mail for the D-I team. I'm not sure where the original mail comes from, but IMO this should be discussed on d-devel, especially since it impacts more than just D-I. I suspect there are quite a few packages that make some sort of provisions for lilo. There are also significant numbers of people still using lilo for, at least for them, very good reasons. Anyone remember the fairly big upset when lilo was removed from testing around D-I Lenny Beta2? I also share the feeling that a lot of people still uses LILO; if possible I do belive it should be kept. The only way it is feasible to do so is to drop all of the Debian patches. Without this, upstream is not cooperative with us. However, I think ext2linux is a feasible upgrade path and that lilo will become unnecessary by the release of squeeze. William -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
William Pitcock wrote:
On Mon, 2009-04-06 at 17:26 +0200, Giacomo A. Catenazzi wrote:
Frans Pop wrote:
On Monday 06 April 2009, Christian Perrier wrote:
Quoting William Pitcock (neno...@dereferenced.org):
lilo is due for removal anyway due to being unmaintained upstream and
the widespread availability of alternatives.
I think that last part is debatable.
I do not have time to manage the removal at this point, but it will
be gone by June.
Has the package already been offered for adoption? Preferably with an
overview of its current (upstream) status and main issues. I'd say that
if there's anybody willing to (actively) maintain it, it should not be
removed.
This is a heads up mail for the D-I team.
I'm not sure where the original mail comes from, but IMO this should be
discussed on d-devel, especially since it impacts more than just D-I. I
suspect there are quite a few packages that make some sort of provisions
for lilo.
There are also significant numbers of people still using lilo for, at
least for them, very good reasons.
I totally agree.
But I think that lilo package description must be changed, warning new
users that lilo have several limits (thus not all kernel within debian
are bootable with lilo).
Maybe we could also require grub{,2} when installing lilo (chained
as other in lilo, for emergency, new debian kernel policies, etc),
but I don't know if it is feasible (e.g. when lilo is not in MBR).
chainloader will work with lilo, but lilo is only kept around for the
people who are crazy and booting off LVMs as it is.
Yes, but it works if you have an additional partition (for boot
record). I don't know if they could live in the same partition
(with some magic).
But IIRC lilo fails also in other cases: some xen immages, on very big
images (which can be reached in some initram).
Booting off LVMs is supported directly by grub2 and ext2linux could
probably be modified to support it in a much better way than lilo does
it, so this is not really a compelling argument for keeping it.
What is ext2linux? packages.d.o and google doesn't give me relevant
informations.
ciao
cate
William
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, 2009-04-06 at 17:26 +0200, Giacomo A. Catenazzi wrote:
Frans Pop wrote:
On Monday 06 April 2009, Christian Perrier wrote:
Quoting William Pitcock (neno...@dereferenced.org):
lilo is due for removal anyway due to being unmaintained upstream and
the widespread availability of alternatives.
I think that last part is debatable.
I do not have time to manage the removal at this point, but it will
be gone by June.
Has the package already been offered for adoption? Preferably with an
overview of its current (upstream) status and main issues. I'd say that
if there's anybody willing to (actively) maintain it, it should not be
removed.
This is a heads up mail for the D-I team.
I'm not sure where the original mail comes from, but IMO this should be
discussed on d-devel, especially since it impacts more than just D-I. I
suspect there are quite a few packages that make some sort of provisions
for lilo.
There are also significant numbers of people still using lilo for, at
least for them, very good reasons.
I totally agree.
But I think that lilo package description must be changed, warning new
users that lilo have several limits (thus not all kernel within debian
are bootable with lilo).
Maybe we could also require grub{,2} when installing lilo (chained
as other in lilo, for emergency, new debian kernel policies, etc),
but I don't know if it is feasible (e.g. when lilo is not in MBR).
chainloader will work with lilo, but lilo is only kept around for the
people who are crazy and booting off LVMs as it is.
Booting off LVMs is supported directly by grub2 and ext2linux could
probably be modified to support it in a much better way than lilo does
it, so this is not really a compelling argument for keeping it.
William
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Romain Beauxis to...@rastageeks.org (06/04/2009): Couldn't this also be a line in the changelog ? Like the trailer line, yes. This is not a standard but this is done in many cases: [ Romain Beauxis ] * Upload to $TARGET Dunno about others, but I just see that as: this person chose to target this or that suite (e.g. unstable after a while in experimental, or experimental to keep things clear for testing/freeze), rather than a final decision. Mraw, KiBi. signature.asc Description: Digital signature
Re: lilo about to be dropped?
OS I also share the feeling that a lot of people still uses LILO; if OS possible I do belive it should be kept. I use lilo, I like lilo. I don't like grub because it has unlogically config, unlogically behavior, strange reconfig-system. I don't like the programs with perverse intellect. Grub is not unixway. I shall use lilo until it is possible. Dear, lilo maintainers! Please don't remove lilo*.deb from debian. -- ... mpd paused: Accept - Can't Stand The Night . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: lilo about to be dropped?
On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov un...@debian.org wrote: OS I also share the feeling that a lot of people still uses LILO; if OS possible I do belive it should be kept. I use lilo, I like lilo. I don't like grub because it has unlogically config, unlogically behavior, strange reconfig-system. I don't like the programs with perverse intellect. Grub is not unixway. Which is more perverse to read a kernel? - reading actual files from actual filesystems - reading hardcoded blocks on the device Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, 2009-04-06 at 17:40 +0200, Giacomo A. Catenazzi wrote:
William Pitcock wrote:
On Mon, 2009-04-06 at 17:26 +0200, Giacomo A. Catenazzi wrote:
Frans Pop wrote:
On Monday 06 April 2009, Christian Perrier wrote:
Quoting William Pitcock (neno...@dereferenced.org):
lilo is due for removal anyway due to being unmaintained upstream and
the widespread availability of alternatives.
I think that last part is debatable.
I do not have time to manage the removal at this point, but it will
be gone by June.
Has the package already been offered for adoption? Preferably with an
overview of its current (upstream) status and main issues. I'd say that
if there's anybody willing to (actively) maintain it, it should not be
removed.
This is a heads up mail for the D-I team.
I'm not sure where the original mail comes from, but IMO this should be
discussed on d-devel, especially since it impacts more than just D-I. I
suspect there are quite a few packages that make some sort of provisions
for lilo.
There are also significant numbers of people still using lilo for, at
least for them, very good reasons.
I totally agree.
But I think that lilo package description must be changed, warning new
users that lilo have several limits (thus not all kernel within debian
are bootable with lilo).
Maybe we could also require grub{,2} when installing lilo (chained
as other in lilo, for emergency, new debian kernel policies, etc),
but I don't know if it is feasible (e.g. when lilo is not in MBR).
chainloader will work with lilo, but lilo is only kept around for the
people who are crazy and booting off LVMs as it is.
Yes, but it works if you have an additional partition (for boot
record). I don't know if they could live in the same partition
(with some magic).
But IIRC lilo fails also in other cases: some xen immages, on very big
images (which can be reached in some initram).
Booting off LVMs is supported directly by grub2 and ext2linux could
probably be modified to support it in a much better way than lilo does
it, so this is not really a compelling argument for keeping it.
What is ext2linux? packages.d.o and google doesn't give me relevant
informations.
Oops. It is extlinux. It's syslinux except it boots off a hard-disk
instead of a floppy or CD. Quite similar to lilo in featureset.
William
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote: || On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov un...@debian.org wrote: || I use lilo, I like lilo. || I don't like grub because it has unlogically config, unlogically || behavior, strange reconfig-system. I don't like the programs with || perverse intellect. Grub is not unixway. || || Which is more perverse to read a kernel? || - reading actual files from actual filesystems || - reading hardcoded blocks on the device I think this question should be: Which is more perverse to read without a kernel? The answer could still fall either way. Personally, as one point of measurement, I prefer lilo because it's lightweight. Ciao. Vincent. -- Vincent Zweije zwe...@xs4all.nl| If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. signature.asc Description: Digital signature
Re: Team uploads
On Mon, 06 Apr 2009 11:52:54 +0800, Paul Wise wrote:
In Debian we have several teams working on maintaining large numbers
of packages (pkg-games, pkg-perl, pkg-gnome for example).
True :)
I
proposed[1] to silence the lintian NMU warnings in the case of team
uploads; where the person doing the upload is a member of the team in
Maintainers but is not present in Uploaders. Does anyone think this
concept of team uploads has merit?
I agree that having to add yourself to Uploaders to avoid NMU
warnings (or listings under sponsored uploads on the DDPO page) is
a pain.
I'm just not sure about a viable solution; adding Team upload to
the changelog is clumsy too and only helps against the lintian
warnings but not against other mechanisms.
(And I agree with statements by others that NMU versions are wrong
and that group-address-in-changelog-trailer is at least weird.)
IMO the general problem is that our tools (both the locally installed
ones and the infrastructures ones) don't have a concept of teams
and team membership in itself. If we had a possibility to
declare/detect this package is team-maintained by $team, and $person
is member of $team, it would be easier ...
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Joan Baez: For Sasha
signature.asc
Description: Digital signature
Re: lilo about to be dropped?
On Mon, 2009-04-06 at 18:06 +0200, Mike Hommey wrote: On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov un...@debian.org wrote: OS I also share the feeling that a lot of people still uses LILO; if OS possible I do belive it should be kept. I use lilo, I like lilo. I don't like grub because it has unlogically config, unlogically behavior, strange reconfig-system. I don't like the programs with perverse intellect. Grub is not unixway. Which is more perverse to read a kernel? - reading actual files from actual filesystems - reading hardcoded blocks on the device Not to mention that it breaks if the blocks span multiple devices. See also: LVM. William signature.asc Description: This is a digitally signed message part
Re: lilo about to be dropped?
On Mon, 2009-04-06 at 18:19 +0200, Vincent Zweije wrote: On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote: || On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov un...@debian.org wrote: || I use lilo, I like lilo. || I don't like grub because it has unlogically config, unlogically || behavior, strange reconfig-system. I don't like the programs with || perverse intellect. Grub is not unixway. || || Which is more perverse to read a kernel? || - reading actual files from actual filesystems || - reading hardcoded blocks on the device I think this question should be: Which is more perverse to read without a kernel? The answer could still fall either way. No, the answer is always the second one. William signature.asc Description: This is a digitally signed message part
Re: lilo about to be dropped?
Quoting Frans Pop (elen...@planet.nl): I'm not sure where the original mail comes from, but IMO this should be From lilo package BTS which I was tracking for l10n purposes. So I just happened to notice William's answer to a bug report and thought it would be good for this to be discussed in public. Clearly, I didn't choose the right place to discuss and the topic has wider implications than just D-I, as the followups show. Good thing that you made the discussion wider. Don't we have some install paths that still depend on LILO? Yes: /boot on LVM is the main one. Anyway, even if we don't, I think we should track that lilo removal and coordinate with William, in order to stop providing lilo-installer. And, I think this should be mentioned as a release goal (dropping lilo). Either high priority if we have install paths depending on lilo, or normal priority otherwise. D-I release goal or Debian release goal [1]? Clearly Debian release goal. IMO the latter could well be justified as there will also need to be some kind of upgrade strategy for existing users that does not make uncontrolled changes on their hard disk or loses them the ability to boot alternative OSes on dual (or multi) boot systems. Which might be very tricky But, as William mentioned in his original mail, upstream activity seems to be low so we need to figure out if we want to keep yet another unmaintained software in Debian. What later puzzled me if the mention in non collaboratve upstream *if we don't drop Debian patches*. That's not exactly inactive upstream so it would be good to clarify the situation of lilo upstream. signature.asc Description: Digital signature
Re: lilo about to be dropped?
* William Pitcock neno...@dereferenced.org [2009-04-06 17:48]: chainloader will work with lilo, but lilo is only kept around for the people who are crazy and booting off LVMs as it is. Booting off LVMs is supported directly by grub2 and ext2linux could probably be modified to support it in a much better way than lilo does it, so this is not really a compelling argument for keeping it. Actually lilo is installed by lenny d-i if you use root-sw-raid with LVM, even if your /boot is an differen partition/sw-raid. Therefore lilo should at least remain for sqeeze to ensure a proper upgrade path. Furthermore I still have 2 machines that refuse to boot with either grub or grub2 but work fine with lilo. And finally your continous insulting of users is not beneficial to the discussion so please refrain from calling others crazy or stupid. yours Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Gunnar Wolf wrote: Petter Reinholdtsen dijo [Sat, Apr 04, 2009 at 06:42:29AM +0200]: Not quite sure what the question is. As far as I know, Debian supported tmpfs mounted /var/run when I become co-maintainer of sysvinit, and I have tried to keep it this way. The only recent changes it that it has become easier to enable it. Very good to notice that this now is documented in the policy. If you wonder what the advantages of tmpfs in /var/run is, I know of several, but do not really have time to track down them all. One of them I care specially about is the fact that it allow a computer to boot with a read-only local file system (think diskless workstations and thin clients booting LTSP, machines with flash disks and files with problems with their file systems), and I believe this is a clear advantage. Having tmpfs there also make it more obvious that the content of /var/run/ will be erased at boot. It does achieve not having bogus information on. If your system crashed, some crappy daemons will refuse to start if /var/run/crappyserver.pid exists, or will try to communicate with their peers using /var/run/sloppydaemon.socket, possibly failing cleanly, but possibly leading to head-scratching /etc/init.d/mountall-bootclean.sh will take care of cleaning up /var/tmp. If not, it would be a bug in mountall-bootclean.sh. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Steve Langasek wrote: On Sat, Apr 04, 2009 at 01:14:51AM +0200, Michael Biebl wrote: Ubuntu. The FHS is silent about directories in /var/run across reboots but requires that all files in /var/run be deleted on reboot. 4.) You have to manually cleanup in postrm. (I guess most packages will forget that, leaving cruft around) If you're creating any files in /var/run during the operation of the package (and if not, why do you have a directory in /var/run in the first place?), then you have to do this anyway, so this isn't new. (Well, I suppose you could just rely on the next reboot deleting them, but that doesn't feel very clean and I'm not sure that's really in the spirit of our requirements.) Not really. Say you have a pretty standard system daemon When the daemon is stopped in postinst, the pid file will be automatically deleted and dpkg will cleanup the remaining /var/run/$foo directory. I think he's referring to the fact that the FHS requires all files in /var/run to be cleared on boot. We have an init script (/etc/rcS.d/S36mountall-bootclean) that takes care of this at the system level, though, on behalf of all packages; the trouble is it's a lot less efficient, overall, to have to repeatedly clean /var/run on boot than it is to just write it to a tmpfs and let the contents be lost on reboot. I think that is one of them main questions: Is it more efficient, to cleanup /var/tmp (i.e. remove everything besides directories) on boot in a single place (mountall-bootclean), or is it more efficient to use a tmpfs and let every package create it's run directory on boot. It's probably hard to tell without proper benchmarking. What can be said though is, that all packages that need a /var/run/ directory must be fixed. (for the numbers: maybe a new archive scan with the new lintian would help to see, how many packages are affected) so it at least requires work by the maintainers. 5.) If your package does not have an init script (I happen to maintain two such packages), I now have to create init scripts simply to create a /var/run directory. That's insane and even more wasting cpu cycles. Could you provide more details about what package without an init script uses /var/run? The only other case that I can think of is packages that create transient UNIX-domain sockets. policykit is such an example. Potentially as D-Bus system bus activated system services are affected by this, because they (usually) don't ship any init script. $ grep -A4 'start)' /etc/init.d/policykit start) mkdir -p /var/run/PolicyKit chown root:polkituser /var/run/PolicyKit chmod 770 /var/run/PolicyKit ;; $ That's what I have on an Ubuntu system; why can't the Debian package do the same? Sure it can. But I consider this solution very ugly and refused to do this so far. For the reasons already mentioned it also makes the (previouly init system agnostic) D-Bus service dependend on sysv-rc. (Yes, this is the only function of this init script. But still, either you create the directories on boot or you have to clean all the files on boot.) We will se such services more and more in the future (like it or not). No. Services that work that way are Doing It Wrong, and we should not accept this as inevitable. Ok, what do you think are they doing wrong: Being started on-demand via D-Bus, i.e. not shipping a sysv init script? I provided a list of cons of tmpfs (you could probably also add, that it breaks selinux). Is there actually a list of pros? Probably? In what case does this break selinux? I'm not a selinux expert, but I read somewhere, that the security context is lost, so you'd have to relabel the directory. I don't know, how costly that operation is (and if this is necessary for a directory in /var/tmp). Maybe Russell or Manoj can chime in here, if they read this. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl bi...@debian.org writes: What can be said though is, that all packages that need a /var/run/ directory must be fixed. (for the numbers: maybe a new archive scan with the new lintian would help to see, how many packages are affected) so it at least requires work by the maintainers. This is in progress now. Lintian is still sadly slower than we'd like, so it's only about two-thirds done and probably won't be finished until Wednesday or so. (I have some additional ideas to speed it up, but haven't had a lot of time to work on it.) -- 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
Re: Team uploads
Raphael Hertzog hert...@debian.org writes: The point of team upload is precisely so that you can update the package and not take responsibility for a package that you don't want to maintain in the long run. I was in many Uploaders field because lintian complain if you are not in Uploaders/Maintainer, yet I was there only for a single team upload for a perl or a python transition and using an NMU version would have been wrong because everything was properly done in the team VCS and there was no NMU to integrate for the next person working on the package. So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. Then, the Maintainer/Uploader field would be again more accurate to know if we have people that care about the packages or not. So I see this change as good move to better detect that nobody cares about the package. Yeah, this is where I'm at with it too. There still should be some humans in Maintainer/Uploaders who are taking primary responsibility for the package, but I think other team members should be able to do QA-style fixes and transition uploads without using NMU versioning or add themselves to Uploaders and hence imply that they're taking ongoing responsibility for the package. -- 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
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
On Mon, 2009-04-06 at 20:42 +0200, Michael Biebl wrote: Sure it can. But I consider this solution very ugly and refused to do this so far. For the reasons already mentioned it also makes the (previouly init system agnostic) D-Bus service dependend on sysv-rc. Wait, now I'm confused. Why wouldn't this same init script work in file-rc? Or are you saying something else? -- -Julian Blake Kongslie If this is a mailing list, please CC me on replies. vim: set ft=text : signature.asc Description: This is a digitally signed message part
Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)
Michael Biebl wrote: Gunnar Wolf wrote: /etc/init.d/mountall-bootclean.sh will take care of cleaning up /var/tmp. /var/run, of course. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: lilo about to be dropped?
WP No, the answer is always the second one. If they add a scheduler (why not? :-\) into the grub it will be become Linux. -- ... mpd paused: Accept - Can't Stand The Night . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Team uploads
On Mon, Apr 06, 2009 at 11:51:54AM -0700, Russ Allbery wrote: Raphael Hertzog hert...@debian.org writes: The point of team upload is precisely so that you can update the package and not take responsibility for a package that you don't want to maintain in the long run. I was in many Uploaders field because lintian complain if you are not in Uploaders/Maintainer, yet I was there only for a single team upload for a perl or a python transition and using an NMU version would have been wrong because everything was properly done in the team VCS and there was no NMU to integrate for the next person working on the package. So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. Then, the Maintainer/Uploader field would be again more accurate to know if we have people that care about the packages or not. So I see this change as good move to better detect that nobody cares about the package. Yeah, this is where I'm at with it too. There still should be some humans in Maintainer/Uploaders who are taking primary responsibility for the package, but I think other team members should be able to do QA-style fixes and transition uploads without using NMU versioning or add themselves to Uploaders and hence imply that they're taking ongoing responsibility for the package. +1, IANADD though. Hauke signature.asc Description: Digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Steve Langasek wrote: On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: 1. The upstream for this package is Ubuntu. Ubuntu has never been very cooperative at accepting changes, until recently: our contact Steve Langasek has indicated that he is interested in merging most or all of our changes, provided that we send them in in chunks, with proper rationales. I have to say here in defense of Ubuntu that I don't see any record of these patches being submitted to the Ubuntu package via Launchpad, which, since Ubuntu does not have individual package maintainers, is the only reliable way to ensure that proposed changes are seen and considered by the people working on the package at any given time. I don't have time to work on the Debian package myself (either as maintainer or for sifting through the delta between Debian and Ubuntu), but I definitely am happy to accept fixes upstream in reasonable-sized chunks. Anyway, as Bart points out, there's another issue: 4. Ubuntu is PHASING OUT this package. They have already moved suspend to pm-utils (but have failed to remove suspend support from acpi-support). They're currently moving hotkey translation to hal. This means that soon we will have no upstream that we can follow! Or we should ensure that Ubuntu's hal changes are included in our version of hal as well -- no clue how those packages are related, or whether Ubuntu's changes are going into upstream hal. Since the last time I had a chance to speak with Bart about this, there's been quite a bit of progress on phasing out the package for Ubuntu; in jaunty, we've dropped a number of quirk scripts related to suspend/resume, as well as close to 30 of the ACPI event-handling scripts from /etc/acpi - basically: all those scripts that were being used to synthesize key events (which doesn't work with recent kernels anyway) and which we could verify were being handled by hal. And yes, Martin Pitt works very closely with hal upstream to ensure fixes are incorporated. I can confirm that. Martin is doing an awesome job, submitting patches upstream or to Debian ftm. As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards standardizing on one power management stack in Debian (and not install 3 by default [1]), i.e. I'd support in phasing out acpi-support and would gladly accept patches for hal and pm-utils which add (if there are) any missing bits from acpi-support. Cheers, Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451380 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: lilo about to be dropped?
I demand that William Pitcock may or may not have written... [snip] Have you looked into ext2linux? It is intended to supercede lilo. I think your usage requirements will be satisfied by it. No; I've not heard of it before. And I can't find it, at least not reasonably easily... :-| -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. I have never let my schooling interfere with my education. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, Apr 06, 2009 at 11:42:42AM -0500, William Pitcock wrote: On Mon, 2009-04-06 at 18:19 +0200, Vincent Zweije wrote: On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote: || On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov un...@debian.org wrote: || I use lilo, I like lilo. || I don't like grub because it has unlogically config, unlogically || behavior, strange reconfig-system. I don't like the programs with || perverse intellect. Grub is not unixway. || || Which is more perverse to read a kernel? || - reading actual files from actual filesystems || - reading hardcoded blocks on the device I think this question should be: Which is more perverse to read without a kernel? The answer could still fall either way. No, the answer is always the second one. Err, why? I've seen grub failing more often, and heard way more report of this, than of lilo. Please explain why you say so. The grub installer also used to read the blockdevice while the filesystem was mounted, which is never the right answer. It has always seemed hackish to me, duplicating fs functionality (and not always correctly, e.g. related to journal replaying on ext3/xfs). A simple block list is just that. iustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
This one time, at band camp, Paul Wise said: Grub2 in lenny and later contains an lvm module: /usr/lib/grub/i386-pc/lvm.mod Has anyone who uses lilo for this tried grub2? hadrian:~# mount /dev/mapper/HADRIAN-ROOT on / type ext3 (rw,relatime,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/mapper/HADRIAN-HOME on /home type ext3 (rw,relatime) /dev/mapper/HADRIAN-TMP on /tmp type ext3 (rw,relatime) /dev/mapper/HADRIAN-USR on /usr type ext3 (rw,relatime) /dev/mapper/HADRIAN-VAR on /var type ext3 (rw,relatime) /dev/mapper/HADRIAN-SRV on /srv type ext3 (rw,relatime) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) ii grub-pc1.96+20080724-16 It works just fine, once you abandon the expectation that the maintainer scripts will do anything at all on fresh in install. Kudos to the d-i team for hiding how little the grub maintainer scripts do. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: lilo about to be dropped?
This one time, at band camp, William Pitcock said: The only way it is feasible to do so is to drop all of the Debian patches. Without this, upstream is not cooperative with us. Why is this? -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Packaging ltp selinux tests
Hello, I'd like to package the selinux tests from the ltp test suite. The tests need a special selinux policy to be loaded and some files to be relabeled. I haven't found any standard way of packaging this, so I made an experimental package (see [1]; it sort of works - not completely, like 10 tests out of 30, but that's not an issue now) and I would like to hear your opinion on these issues: 1. The package loads the policy on postinst configure with semodule -i, is that right? (And did I implement it properly in the scripts?) There were some avc message during package install (semodule was denied access to a terminal with type apt_t), can this be solved? 2. The relabeling has to be done manually with fixfiles relabel; is there a way to do it (and should it be done) automatically? 3. The runtime packages depend on selinux-policy-default; should it (alternatively) depend on the other policies too? Would this need a separate policy package? 4. Should the policy package be in /usr/share? Thanks in advance. Regards Jiri Palecek [1]: http://mentors.debian.net/debian/pool/main/l/ltp/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
Martin Wuertele wrote: Actually lilo is installed by lenny d-i if you use root-sw-raid with LVM, even if your /boot is an differen partition/sw-raid. Therefore lilo should at least remain for sqeeze to ensure a proper upgrade path. I'm afraid you're mistaken here. Lenny D-I should (and AFAIK does) default to grub for that setup. /boot on normal partition or RAID1 + / on whatever combination of RAID+LVM is supported fine by grub. Unless there is some other factor that you've not mentioned D-I does not fall back to lilo for that. Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Mon, Apr 06, 2009 at 11:51:54AM -0700, Russ Allbery a écrit : There still should be some humans in Maintainer/Uploaders who are taking primary responsibility for the package, but I think other team members should be able to do QA-style fixes and transition uploads without using NMU versioning or add themselves to Uploaders and hence imply that they're taking ongoing responsibility for the package. Hi all, so in the end, can we use the “ * QA upload.” special first line for non-uploader uploads without breaking the QA infrastructure? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
On Mon, 06 Apr 2009, Matthew Johnson wrote: On Mon Apr 06 11:07, Goswin von Brederlow wrote: So lets get grub2 working everywhere. :) A worthy goal. Sure, but don't remove lilo until we're happy that grub2 does work everywhere. And that we have something resembling acceptable, up-to-date documentation for it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted liblog-log4perl-perl 1.21-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 Apr 2009 00:01:45 -0500 Source: liblog-log4perl-perl Binary: liblog-log4perl-perl Architecture: source all Version: 1.21-1 Distribution: unstable Urgency: low Maintainer: Manoj Srivastava sriva...@debian.org Changed-By: Manoj Srivastava sriva...@debian.org Description: liblog-log4perl-perl - A Perl port of the widely popular log4j logging package. Changes: liblog-log4perl-perl (1.21-1) unstable; urgency=low . * New upstream release. + (ms) Documentation typos fixed, reported by Breno G. de Oliveira [rt.cpan.org #42428]. + (ms) Fixed DBI appender error message, bug reported by DavidZ. + (ms) Fixed [rt.cpan.org #43740] reported by Martin Koehler. Now using proper POSIX return code EEXISTS instead of error message depending on English locale. * Only run unit tests when DEB_BUILD_OPTIONS does not contain nocheck. This brings us back in compliance with policy. Checksums-Sha1: dc1864a5047da05e45cd10be4520b2a7f289e888 1267 liblog-log4perl-perl_1.21-1.dsc e033da7b6d8b0101b7587685513002212aca04ad 238764 liblog-log4perl-perl_1.21.orig.tar.gz c1bf5be0941629ce66e371c310c8e2fe94987806 25526 liblog-log4perl-perl_1.21-1.diff.gz 01948ffe81b08568214fcdf006718898405cffa1 398862 liblog-log4perl-perl_1.21-1_all.deb Checksums-Sha256: 6618a3914b2b7d0c9569c1f7119f33a08db0eb8270e487d3fdc1b819e126b0da 1267 liblog-log4perl-perl_1.21-1.dsc e0668cfab3fbc8130e08223211e9631ee8e18f146097bfadb6bdec16d02cd95f 238764 liblog-log4perl-perl_1.21.orig.tar.gz 9df62b59fe60e31e60083f86a1bc508604404bf96cc93d7e415e547605c31f53 25526 liblog-log4perl-perl_1.21-1.diff.gz 3e25921c28d1f73bed4c0451f195178f278d6665f1a9d8c3f67b90763fb1ecf9 398862 liblog-log4perl-perl_1.21-1_all.deb Files: fdbc9e134a3c732e46ab4261c13ee516 1267 perl optional liblog-log4perl-perl_1.21-1.dsc 66bfe59ecb3741e9f271750198c3196e 238764 perl optional liblog-log4perl-perl_1.21.orig.tar.gz 7796dae22d39bca1a13e0b386827d470 25526 perl optional liblog-log4perl-perl_1.21-1.diff.gz 0307d00cc645ccf758ef64a35ddff9e1 398862 perl optional liblog-log4perl-perl_1.21-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknZlawACgkQIbrau78kQkzmbwCfWMnqtKHl179XCSUYOQwQygvp CZUAn36alWyRYicJTgqBcTEDtpj2Q8A5 =wvMw -END PGP SIGNATURE- Accepted: liblog-log4perl-perl_1.21-1.diff.gz to pool/main/libl/liblog-log4perl-perl/liblog-log4perl-perl_1.21-1.diff.gz liblog-log4perl-perl_1.21-1.dsc to pool/main/libl/liblog-log4perl-perl/liblog-log4perl-perl_1.21-1.dsc liblog-log4perl-perl_1.21-1_all.deb to pool/main/libl/liblog-log4perl-perl/liblog-log4perl-perl_1.21-1_all.deb liblog-log4perl-perl_1.21.orig.tar.gz to pool/main/libl/liblog-log4perl-perl/liblog-log4perl-perl_1.21.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
Accepted sympy 0.6.4-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 05 Apr 2009 22:51:18 -0700 Source: sympy Binary: python-sympy Architecture: source all Version: 0.6.4-1 Distribution: unstable Urgency: low Maintainer: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org Changed-By: Ondrej Certik ond...@certik.cz Description: python-sympy - Computer Algebra System (CAS) in Python Changes: sympy (0.6.4-1) unstable; urgency=low . * New upstream release * New debian policy update (no changes needed) * XB-Python-Version and XS-Python-Version removed, as they are not needed for python-support Checksums-Sha1: 38821a8551090cde84085f9f10e4685f909a6a75 1324 sympy_0.6.4-1.dsc 949efd7fd47d38e14b3128e1797107b81811c9b6 2214969 sympy_0.6.4.orig.tar.gz 3b86c628ea00783be97b8f3a87347485a278857d 6021 sympy_0.6.4-1.diff.gz 1271e7ce24d7aa0de971db4e9a397bf3141c8835 1378504 python-sympy_0.6.4-1_all.deb Checksums-Sha256: 442b214ffb7e5490367d143283d57ffd11385e546747abe5d4949917c0dc7f75 1324 sympy_0.6.4-1.dsc 79f55fa300478bb14d635ca693b38be56d22b87a3c817329ae6d1189735b1c5a 2214969 sympy_0.6.4.orig.tar.gz b8f5b591ea4717cb6753d25ddc6aa27b962723b608b991277e558782cfbf515b 6021 sympy_0.6.4-1.diff.gz 263b4b6cff044e147fd6e258bdf8a956bea32b8ae25bbef0c6bdde0ddca01651 1378504 python-sympy_0.6.4-1_all.deb Files: 36159bd4b94a11f2cd88036389d61cd9 1324 python optional sympy_0.6.4-1.dsc 5b1c4f76d5b7e1477c852a0ec2201092 2214969 python optional sympy_0.6.4.orig.tar.gz c3db175fa49912a1ab5c4482023f961b 6021 python optional sympy_0.6.4-1.diff.gz f0694c3fb53260948afa29ab2ce5a4a3 1378504 python optional python-sympy_0.6.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknZo/QACgkQKQ++Uu6gdgnCyQCfQa0hWIHxrfCihZXKgq7oRP2B 8IUAniS5hCqYCkIvMRgWjm6itV3l+dQm =8qv0 -END PGP SIGNATURE- Accepted: python-sympy_0.6.4-1_all.deb to pool/main/s/sympy/python-sympy_0.6.4-1_all.deb sympy_0.6.4-1.diff.gz to pool/main/s/sympy/sympy_0.6.4-1.diff.gz sympy_0.6.4-1.dsc to pool/main/s/sympy/sympy_0.6.4-1.dsc sympy_0.6.4.orig.tar.gz to pool/main/s/sympy/sympy_0.6.4.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
Accepted cryptsetup 2:1.0.6+20090405.svn49-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 06 Apr 2009 08:49:14 +0200
Source: cryptsetup
Binary: cryptsetup cryptsetup-udeb
Architecture: source amd64
Version: 2:1.0.6+20090405.svn49-1
Distribution: unstable
Urgency: low
Maintainer: Jonas Meurer m...@debian.org
Changed-By: Jonas Meurer m...@debian.org
Description:
cryptsetup - configures encrypted block devices
cryptsetup-udeb - configures encrypted block devices (udeb)
Closes: 498964 507727 509066 509067 513149 513596 514729 516236 521469 521547
521673 521789 522338 522387
Changes:
cryptsetup (2:1.0.6+20090405.svn49-1) unstable; urgency=low
.
* New upstream svn snapshot. Highlights include:
- Uses remapping to error target instead of calling udevsettle for
temporary crypt device. (closes: #514729, #498964, #521547)
- Removes lots of autoconf stuff as it's generated by autogen.sh anyway.
- Uses autopoint in build process, thus needs to Build-Depend on cvs.
- Fixes signal handler to proper close device.
- Wipes start of device before LUKS-formatting.
- Allows deletion of key slot with it's own key. (closes: #513596)
- Checks device mapper communication and gives proper error message in
case the communication fails. (closes: #507727)
* Update debian patches accordingly:
- Remove obsolete patches 01_gettext_package and 03_check_for_root
- Update patch 02_manpage
* Add missing newlines to some error messages in passdev.c. Thanks to
Christoph Anton Mitterer for bugreport and patch. (closes: #509067)
* Move keyscripts in initramfs from /keyscripts to /lib/cryptsetup/scripts
for the sake of consistency between initramfs and normal system. Document
this change in NEWS.Debian. (closes: #509066)
* Fix $LOUD in cryptdisks.init and cryptdisks.functions to take effect. Add
LOUD=yes to cryptdisks_start. (closes: #513149)
* cryptdisks_{start,stop}: print error message if no entry is found in
crypttab for the given name.
* Actually fix watchfile to work with code.google.com.
* Update Homepage field to code.google.com URL. (closes: #516236)
* Fix location of ltmain.sh, build-depend on versioned libtool.
(closes: #521673, #522338)
* Some minor changes to make lintian happy:
- use set -e instead of /bin/sh -e in preinst.
- link to GPL v2 in debian/copyright
* Bump standards-version to 3.8.1, no changes needed.
* Fix a typo in NEWS.Debian. (closes: #522387)
* Taken from ubuntu:
- debian/checks/un_vol_id: dynamically build the unknown volume type
string, to allow for encrypted swap, (closes: #521789, #521469). Fix
sed to replace '/' with '\/' instead of '\\/' in device names.
- disable error message 'failed to setup lvm device' (LP 151532).
Checksums-Sha1:
6b04ba76ebdb0d19451b1eddcc6061a3342d4a19 1574
cryptsetup_1.0.6+20090405.svn49-1.dsc
4a4cf1765e5148bb9cfc49bf65bbb6d9cfe8cc63 143967
cryptsetup_1.0.6+20090405.svn49.orig.tar.gz
4c63341a56408ac106c08a3d9bc90c5ce7674bc0 60425
cryptsetup_1.0.6+20090405.svn49-1.diff.gz
62f93155ff59539dfba430a5d7f80c9f448a3676 339558
cryptsetup_1.0.6+20090405.svn49-1_amd64.deb
056de544a7c8c919a30b579ddf1fe31b347f5245 277530
cryptsetup-udeb_1.0.6+20090405.svn49-1_amd64.udeb
Checksums-Sha256:
c17d571ddf0803d5592a8224f335d36989828e4e225b8d2d2bd5e6db654bef26 1574
cryptsetup_1.0.6+20090405.svn49-1.dsc
28e2ea63e4bd4ddb79e0536303ed422f507352a4976de4ba6f7bb98590be03b6 143967
cryptsetup_1.0.6+20090405.svn49.orig.tar.gz
2f736b285ac0c306e43a8da3b9a10bb072f2f2a11cc2d378dde1984a52201090 60425
cryptsetup_1.0.6+20090405.svn49-1.diff.gz
9df70422cc4634fb963a08775486f5c0a5ae264fd15256ca65da5f1f15c7f2e3 339558
cryptsetup_1.0.6+20090405.svn49-1_amd64.deb
81686d6a47660c6ec619ffe17ab9852edc4b4bc2c2eadf190b1eff06ce983f15 277530
cryptsetup-udeb_1.0.6+20090405.svn49-1_amd64.udeb
Files:
4cb5b75b2b2a55839a0e355191c2f05f 1574 admin optional
cryptsetup_1.0.6+20090405.svn49-1.dsc
884d049422a4bc08f252f2e1f4b4b5d7 143967 admin optional
cryptsetup_1.0.6+20090405.svn49.orig.tar.gz
af95348937599aeb61f7672e34daff25 60425 admin optional
cryptsetup_1.0.6+20090405.svn49-1.diff.gz
3ed034de830ab10dfa86db0b7ded091c 339558 admin optional
cryptsetup_1.0.6+20090405.svn49-1_amd64.deb
55c987d095a56222880772f80138317c 277530 debian-installer optional
cryptsetup-udeb_1.0.6+20090405.svn49-1_amd64.udeb
Package-Type: udeb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknZpyUACgkQd6lUs+JfIQKPRQCcCOyqV3ixgM31XaxOaz0Gskre
tb4AnAuB1vJHZKmmPXozF6+HWXTsLach
=SuSV
-END PGP SIGNATURE-
Accepted:
cryptsetup-udeb_1.0.6+20090405.svn49-1_amd64.udeb
to pool/main/c/cryptsetup/cryptsetup-udeb_1.0.6+20090405.svn49-1_amd64.udeb
cryptsetup_1.0.6+20090405.svn49-1.diff.gz
to pool/main/c/cryptsetup/cryptsetup_1.0.6+20090405.svn49-1.diff.gz
cryptsetup_1.0.6+20090405.svn49-1.dsc
to pool/main/c/cryptsetup/cryptsetup_1.0.6+20090405.svn49-1.dsc
Accepted libthai 0.1.11-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 Apr 2009 13:54:19 +0700 Source: libthai Binary: libthai-dev libthai0 libthai-data libthai-doc Architecture: source all amd64 Version: 0.1.11-1 Distribution: experimental Urgency: low Maintainer: Theppitak Karoonboonyanan t...@linux.thai.net Changed-By: Theppitak Karoonboonyanan t...@linux.thai.net Description: libthai-data - Data files for Thai language support library libthai-dev - Development files for Thai language support library libthai-doc - Documentation files for Thai language support library libthai0 - Thai language support library Changes: libthai (0.1.11-1) experimental; urgency=low . * Versioned Conflicts on libdatrie0 ( 0.1.4), i.e. lenny version, which lacked symbol versioning and caused symbol clashes. * New upstream release. Checksums-Sha1: f732c94b419057c8628e8c377a8c04827ef50a3c 1339 libthai_0.1.11-1.dsc 0df32815881f3c174b26b315c1c05eb20842dd8e 462122 libthai_0.1.11.orig.tar.gz 2cef98b4bf420ebb2b9fb30d4bd1798c0b8bbf18 7493 libthai_0.1.11-1.diff.gz db8799817b97c77aac5c188326542d52dd5110a9 187846 libthai-data_0.1.11-1_all.deb 32bde173db778ceaec0f3f6a9314c00de2471288 61376 libthai-doc_0.1.11-1_all.deb b12926ba0a20d06f41394c1db96beb83572dc5ee 54500 libthai-dev_0.1.11-1_amd64.deb 27e5bcd6db1974b0db4fd6cfaa99e99a6d4a79bf 35520 libthai0_0.1.11-1_amd64.deb Checksums-Sha256: 3d5b9cc66d0c1807206d14a4055c61dca6a7c2d657911ae95e76da7276b15f76 1339 libthai_0.1.11-1.dsc 60ad219ad3011c300e5af0ab2a91fdbaa55d6c87e6e5e086d6bb1722bcf4df34 462122 libthai_0.1.11.orig.tar.gz c9423a99bd97e57cc3d420a12e1a5ab79e686a1884c422672452c76d1abc6404 7493 libthai_0.1.11-1.diff.gz 58debf8fd714409cba2f9cd82c1a87dcf6e5076094b8a9f0582ae93296c059cc 187846 libthai-data_0.1.11-1_all.deb 3cd7c7a74f3f566c87a0b1ea7b7d9a8feb06ba544c1a3253841696f92a9e4590 61376 libthai-doc_0.1.11-1_all.deb 564c22b708f6a19acf9998d1514928db698d38ec129ad12c0e6f36bd86eca9fe 54500 libthai-dev_0.1.11-1_amd64.deb 350d4117cbf81bb3034d943bd7b99b696dba44a05a743656feaae1cf437cbb1a 35520 libthai0_0.1.11-1_amd64.deb Files: eb02ce12def79af2fd232025c7a491ec 1339 libs optional libthai_0.1.11-1.dsc f27fd7b67116939b2676ddff7180957a 462122 libs optional libthai_0.1.11.orig.tar.gz 09ff641215d67aebaeaff9db6784881b 7493 libs optional libthai_0.1.11-1.diff.gz f52968dd789d6d3da337bad0a82ebe57 187846 libs optional libthai-data_0.1.11-1_all.deb 08fa0a7943756fe03e024006f58472f8 61376 doc optional libthai-doc_0.1.11-1_all.deb 5c1df18f21539a46e2299f1c01970a6e 54500 libdevel optional libthai-dev_0.1.11-1_amd64.deb 7a039a20e9863954ea0a5162441b2487 35520 libs optional libthai0_0.1.11-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknZp9UACgkQqgzR7tCLR/4NQQCfTOeY6eio5AwsvaWYbnwbhP3I +dwAniW/yZ67ElFDKdhq0fSJGkJvNdMR =wYVi -END PGP SIGNATURE- Accepted: libthai-data_0.1.11-1_all.deb to pool/main/libt/libthai/libthai-data_0.1.11-1_all.deb libthai-dev_0.1.11-1_amd64.deb to pool/main/libt/libthai/libthai-dev_0.1.11-1_amd64.deb libthai-doc_0.1.11-1_all.deb to pool/main/libt/libthai/libthai-doc_0.1.11-1_all.deb libthai0_0.1.11-1_amd64.deb to pool/main/libt/libthai/libthai0_0.1.11-1_amd64.deb libthai_0.1.11-1.diff.gz to pool/main/libt/libthai/libthai_0.1.11-1.diff.gz libthai_0.1.11-1.dsc to pool/main/libt/libthai/libthai_0.1.11-1.dsc libthai_0.1.11.orig.tar.gz to pool/main/libt/libthai/libthai_0.1.11.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
Accepted kdeplasma-addons 4:4.2.2-1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 01 Apr 2009 15:41:34 +0200 Source: kdeplasma-addons Binary: kdeplasma-addons plasma-widgets-addons plasma-dataengines-addons plasma-runners-addons plasma-widget-lancelot liblancelot0 liblancelot-dev kdeplasma-addons-dbg Architecture: all amd64 i386 source Version: 4:4.2.2-1 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Ana Beatriz Guerrero Lopez a...@debian.org Description: kdeplasma-addons - addons for KDE 4 Plasma - metapackage kdeplasma-addons-dbg - debugging symbols for kdeplasma-addons liblancelot0 - library that contains all UI widgets and layouts used in the Lanc liblancelot-dev - development headers for liblancelot plasma-dataengines-addons - addons for KDE 4 Plasma - data engines plasma-runners-addons - addons for KDE 4 Plasma - krunner plugins plasma-widget-lancelot - addons for KDE 4 Plasma - lancelot widget plasma-widgets-addons - addons for KDE 4 Plasma - widgets Changes: kdeplasma-addons (4:4.2.2-1) unstable; urgency=low . * New upstream release. Checksums-Sha1: 01ea94194367219d7349c83f6770c20b3ab3e3a1 611604 plasma-widget-lancelot_4.2.2-1_amd64.deb 03645f40e59863087ba36a645ac93b54d8850489 6422 kdeplasma-addons_4.2.2-1_all.deb 1b134b882cdade7744867f02a5bb6ff872525c9f 4237284 plasma-widgets-addons_4.2.2-1_i386.deb 20b88bf05d6a0800b19fd4d5348cc5527dae760e 121678 plasma-runners-addons_4.2.2-1_amd64.deb 2e9cea3744c72e20403de4e9652964f4de20f3b7 108522 plasma-runners-addons_4.2.2-1_i386.deb 41620c4504d7e6e021c98579f61a4e628dacd3a7 601378 plasma-widget-lancelot_4.2.2-1_i386.deb 43f97e14ea45b76f023748452e87d6d6df9201b2 4437610 kdeplasma-addons_4.2.2.orig.tar.gz 74a6b2f198ed8772daa10fb11e68055fa0310079 19054 liblancelot-dev_4.2.2-1_amd64.deb 783ccfa254dce6d43f4500d5ecfa760ff2824452 19054 liblancelot-dev_4.2.2-1_i386.deb 8151a70229fe7104e92a59d42a75f3396ed3d51d 160282 liblancelot0_4.2.2-1_amd64.deb 96812b50f9902c928023ec3cab4f8d2c19e79dc9 149390 liblancelot0_4.2.2-1_i386.deb 9888d2c22cc3805823c29ec44d63478947c21f33 11136034 kdeplasma-addons-dbg_4.2.2-1_amd64.deb a7d8af066c7bf08fdbbc650cacc859eefa6089df 83414 plasma-dataengines-addons_4.2.2-1_i386.deb a9f96a8d6c3ce6c951cf8234fb44b2ce4db9f34c 92570 plasma-dataengines-addons_4.2.2-1_amd64.deb b2f1e0cce9854c30ce4253c2ffc89856098b0a56 11012436 kdeplasma-addons-dbg_4.2.2-1_i386.deb 412307bb05bfa80b1409076a1d51e0516e8a5645 1821 kdeplasma-addons_4.2.2-1.dsc ec155ca96d523521c37bd365570911eda370b9d5 11027 kdeplasma-addons_4.2.2-1.diff.gz f8e87ba115ade3c0af258c820c0e44fcf89326c4 4306204 plasma-widgets-addons_4.2.2-1_amd64.deb Checksums-Sha256: 04baa7dcc0ae74d34ad02c7b41bdbca794765c234f410a4c998aadcb6b15cac6 4437610 kdeplasma-addons_4.2.2.orig.tar.gz 3a1de62b947ed92071bf9684dafacc9264531e8292e6734f75476bf0e98e816e 108522 plasma-runners-addons_4.2.2-1_i386.deb 43c1fbc125ff4dfd8d96d281c41ef3217dd8d44e0d41629f294d6650e7e006c2 4237284 plasma-widgets-addons_4.2.2-1_i386.deb 4dffafe0081b9087ceb612f74829c1bd472cac8deb3d7e88a4c60c2bdf7e6cee 4306204 plasma-widgets-addons_4.2.2-1_amd64.deb 4f71c638b0d310a58cef59b36a3dbf9466e6a5ad6a9791e61e1c5935e536afbc 92570 plasma-dataengines-addons_4.2.2-1_amd64.deb 52a016f49888d07aaddd1bee6b8c16129d528f4ba0429a8afd82f62c335de0f7 611604 plasma-widget-lancelot_4.2.2-1_amd64.deb 280e8a2e734c81db666862646d3e6502941c7a343791a399504352836f2bedc4 1821 kdeplasma-addons_4.2.2-1.dsc 5cb8e4afac2115020e9076e6f04734f88aa819793b8e0b25420871d486a1e49a 121678 plasma-runners-addons_4.2.2-1_amd64.deb 6782a480703dda044e5ed09194551f0ad702c8669d1847cff72b7d5872e6018c 11012436 kdeplasma-addons-dbg_4.2.2-1_i386.deb 6e362af60135273e8fba028e2cda03e55f7fdb5fe099270201a19d2fb1a3815b 601378 plasma-widget-lancelot_4.2.2-1_i386.deb 856a70b41298ab7e742e44d2a676359a23da4e41b78be0c2d3dd8d6a8a2022fa 149390 liblancelot0_4.2.2-1_i386.deb 94b91c286cb793043b2afdcc3c7867f98d66316b5ba6d1fee471a1c20505002e 11027 kdeplasma-addons_4.2.2-1.diff.gz 954f176e5f5a752f630417f2eec012aacd8b51df508fe9fd2d4e3c17169570df 6422 kdeplasma-addons_4.2.2-1_all.deb 9b615e91bef230fc92cec3c8329ec6f9c9b4b52b9f86b704bf66d43e991a30b0 160282 liblancelot0_4.2.2-1_amd64.deb b7365bfb2c1177b1fb08a029e15d0ee191a2ba377fbcd99c9acde4f0a857b836 19054 liblancelot-dev_4.2.2-1_i386.deb bb2cac6764cd06fc4595f378fafbf4c50d87da90409970724cc2f0a23c886c99 11136034 kdeplasma-addons-dbg_4.2.2-1_amd64.deb ec6f592e8a5c4638922b50a42a5191a7586a82d0827d5f42b5d4a23e7c2e872c 83414 plasma-dataengines-addons_4.2.2-1_i386.deb f397fd219973da76f836cd92511edf16d97a97c59e726d43e3b59e02171e719a 19054 liblancelot-dev_4.2.2-1_amd64.deb Files: 01c6df1173bb24a67284a85931a29031 4237284 kde optional plasma-widgets-addons_4.2.2-1_i386.deb 0a261ece9d97661b18d543effe7cb6eb 4437610 utils optional kdeplasma-addons_4.2.2.orig.tar.gz 3b3dbd5a9b5e78b649c5b43cdcd28169 92570 kde optional
Accepted kdeartwork 4:4.2.2-1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 02 Apr 2009 12:31:21 +0200 Source: kdeartwork Binary: kdeartwork kdeartwork-emoticons kdewallpapers kdeartwork-theme-icon kdeartwork-theme-window kdeartwork-style kscreensaver kscreensaver-xsavers kscreensaver-xsavers-webcollage plasma-desktopthemes-artwork Architecture: all amd64 i386 source Version: 4:4.2.2-1 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Sune Vuorela deb...@pusling.com Description: kdeartwork-emoticons - emoticon collections for KDE 4 chat clients kdeartwork-style - widget styles released with KDE 4 kdeartwork-theme-icon - icon themes released with KDE 4 kdeartwork - themes, styles and other artwork from the official KDE 4 release kdeartwork-theme-window - window decoration themes released with KDE 4 kdewallpapers - wallpapers released with KDE 4 kscreensaver - Additional screensavers released with KDE 4 kscreensaver-xsavers-webcollage - webcollage screensaver support for KDE 4 kscreensaver-xsavers - xscreensaver support for KDE 4 plasma-desktopthemes-artwork - desktop themes for KDE 4 Changes: kdeartwork (4:4.2.2-1) unstable; urgency=low . * New upstream release. * Bump build-deps. Checksums-Sha1: 023ef7e513b36edbdcba6b0a1803c7f3619e123d 53546 kdeartwork-style_4.2.2-1_i386.deb 0816031755890d6c2d1039ddf1c48d7dbb076b31 752022 kscreensaver_4.2.2-1_amd64.deb 1d4e562577ecddc7e0f36df15f358294b63ede7d 2268958 kdeartwork-theme-icon_4.2.2-1_all.deb 378406729a2ab029757d9ec8b0d1a1130a3e1350 189140 kscreensaver-xsavers_4.2.2-1_amd64.deb 53e2c9c7c78391385e4b3b8dd689e7b6e67d5b50 12126 kscreensaver-xsavers-webcollage_4.2.2-1_all.deb 579a8d05b996c14710abb896e9fc1f006fc5b576 53754 kdeartwork-style_4.2.2-1_amd64.deb 5fa1ded4ac1a5031a5499fc635ff543479301caa 12209996 kdewallpapers_4.2.2-1_all.deb 71f00f3a25e38ae070886fd79dc43cd68b98d39d 23608232 kdeartwork_4.2.2.orig.tar.gz 7519223186f77e952233c6349fca85c657b9c4bf 75290 kdeartwork-emoticons_4.2.2-1_all.deb 9028edda62cf3b66d9d99e76d0d5a17cea0b6ee6 921436 plasma-desktopthemes-artwork_4.2.2-1_all.deb af5422b52ec39d5710f6591f71011c48dc74a0b1 178544 kscreensaver-xsavers_4.2.2-1_i386.deb ba3e767d89489f72e13c8663fa86f3e9486eed6a 7900 kdeartwork-theme-window_4.2.2-1_amd64.deb c862994e5bd36a00c24cbcec3020d72791f998e3 1415948 kdeartwork_4.2.2-1_all.deb cdaeb7c23a84f74b9fdedf521147a5c504cc8662 7888 kdeartwork-theme-window_4.2.2-1_i386.deb f82ab9c98f17c076a1ca4c5c974b5d464975c2ee 1880 kdeartwork_4.2.2-1.dsc fdf47b9c1a3ce4d4286706ab4a32d144faba3fb8 11418 kdeartwork_4.2.2-1.diff.gz fe39a6ad12643f4db84b4aa4a1507834801615cf 713938 kscreensaver_4.2.2-1_i386.deb Checksums-Sha256: 5bcce1bd5a2f0ae66041308edc690b16585a7252757abfd292d39a5870f425c8 1880 kdeartwork_4.2.2-1.dsc 164bea50fe15bdd899b93b8435a4cfaca50eaca8b34225c9b2baae9bb7c70cb4 23608232 kdeartwork_4.2.2.orig.tar.gz 358ab0acb783f59d42e2bc1d06b8069a6f892a1d3ddd55791b247cf12a43 53754 kdeartwork-style_4.2.2-1_amd64.deb 35ddaed397670edc6c826cd0eb7c18b4e14c3de72aefacccdb985a8f7deac220 713938 kscreensaver_4.2.2-1_i386.deb 95a0ddda33f6aae612d086e5a594d0edeeb333efca13b0cf8bf3de8bde866281 75290 kdeartwork-emoticons_4.2.2-1_all.deb a35c5104c8f68e4cdcf8432046b2e0d16ed636bcc6735af2b5f3e548a0c605c0 1415948 kdeartwork_4.2.2-1_all.deb aab57ea0d41eeeadac4917e63836cd5463fe846700b63d2d8e158596fe9153e4 752022 kscreensaver_4.2.2-1_amd64.deb adce1c905722d3dce61d29fae557413849fe8f273a021de8107fdbcd3835202d 7888 kdeartwork-theme-window_4.2.2-1_i386.deb c42051506a58b217b88e91ca4e8884f46e956cbbf2409fce049e2924214af374 53546 kdeartwork-style_4.2.2-1_i386.deb c7eecaf76f035432162d2107d7f15592b35e215b7b7e72bff62423a4d5be2889 11418 kdeartwork_4.2.2-1.diff.gz d28934312c88cf48879521b063dfcbd9d6e367fcc5a8cd8840c305ed5995bd3e 2268958 kdeartwork-theme-icon_4.2.2-1_all.deb d600c6118a71e387b7f97a2be4245a250418ec3062fbbad1fe0fba4a8a79d447 12126 kscreensaver-xsavers-webcollage_4.2.2-1_all.deb ebbbe139135122c0bd26d0319498fade7d6c00c31ccf81927d19afeae2e52ace 189140 kscreensaver-xsavers_4.2.2-1_amd64.deb f371a3f75f7e10f88f91f8b305d576967077c7bc9198de6894efa1412c106d86 12209996 kdewallpapers_4.2.2-1_all.deb f6bbb47d5f8251054b6f0dfae6192ce7722114df6719b59c6752f6c5994089e1 7900 kdeartwork-theme-window_4.2.2-1_amd64.deb fa1bf5f7faa7758775dc54a4c33c5c27b78e0f72a6e1b5d477089b6ce6a0d56b 921436 plasma-desktopthemes-artwork_4.2.2-1_all.deb fe2528339da65c6f1143f80e44b8328585f6ecca6ed11319f64c41a88aefe1e3 178544 kscreensaver-xsavers_4.2.2-1_i386.deb Files: 83c6d5d2976ab33a6af3d5a223113499 1880 kde optional kdeartwork_4.2.2-1.dsc 193d356138ba39d532aba03e423e217a 12209996 kde optional kdewallpapers_4.2.2-1_all.deb 25925ac53c3b295ff94315274b35436b 178544 kde optional kscreensaver-xsavers_4.2.2-1_i386.deb 31074882e8f915b857a3c14e49965c4e 1415948 kde optional kdeartwork_4.2.2-1_all.deb 433f0505e4027aff7246c60b247f7202 12126 kde optional
Accepted kdebase-workspace 4:4.2.2-1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 06 Apr 2009 03:22:16 +0200
Source: kdebase-workspace
Binary: kdebase-workspace kdebase-workspace-bin kdebase-workspace-libs4+5
kdebase-workspace-data kdebase-workspace-dev plasma-dataengines-workspace
plasma-widgets-workspace plasma-scriptengines plasma-scriptengine-javascript
plasma-scriptengine-qedje plasma-scriptengine-ruby plasma-scriptengine-python
plasma-scriptengine-webkit plasma-scriptengine-googlegadgets kdm klipper
ksysguardd ksysguard kde-window-manager libkdecorations4 libkwineffects1
systemsettings kdebase-workspace-dbg
Architecture: all amd64 i386 source
Version: 4:4.2.2-1
Distribution: unstable
Urgency: low
Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org
Changed-By: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org
Description:
kdebase-workspace - base workspace components from the official KDE 4 release
kdebase-workspace-bin - core binaries for the KDE 4 base workspace module
kdebase-workspace-data - shared data files for the KDE 4 base workspace module
kdebase-workspace-dbg - debugging symbols for the KDE 4 base workspace module
kdebase-workspace-dev - development files for the KDE 4 base workspace module
kdebase-workspace-libs4+5 - libraries provided by the KDE 4 base workspace
module
kde-window-manager - the KDE 4 window manager (KWin)
kdm- KDE Display Manager for X11
klipper- clipboard utility for KDE 4
ksysguardd - System Guard Daemon for KDE 4
ksysguard - System Guard for KDE 4
libkdecorations4 - library used by decorations for the KDE 4 window manager
libkwineffects1 - library used by effects for the KDE 4 window manager
plasma-dataengines-workspace - KDE 4 base workspace Plasma data engines
plasma-scriptengine-googlegadgets - Google Gadgets script engine for Plasma
plasma-scriptengine-javascript - javascript script engine for Plasma
plasma-scriptengine-python - Python script engine for Plasma
plasma-scriptengine-qedje - QEdje script engine for Plasma
plasma-scriptengine-ruby - Ruby script engine for Plasma
plasma-scriptengines - a metapackage to install all Plasma script engines
plasma-scriptengine-webkit - Web and MacOS X dashboard widget support for
Plasma
plasma-widgets-workspace - KDE 4 base workspace Plasma widgets and containments
systemsettings - KDE 4 System Settings
Changes:
kdebase-workspace (4:4.2.2-1) unstable; urgency=low
.
* New upstream release.
.
+++ Changes by Ana Beatriz Guerrero Lopez:
.
* Remove merged patches: 00_4.2.1_real and 00_r934863_plasma_geometry_crash.
* Update installed files, cmake files changed from
usr/lib/cmake/KDE4Workspace-4.2.0
to usr/lib/cmake/KDE4Workspace-4.2.*.
.
+++ Changes by Sune Vuorela:
.
* Hack in kaboom in startkde script.
* Depend on kaboom (=1.0.0).
* Bump build deps.
* Sprinkle over a lot of ${misc:Depends} in control.
Checksums-Sha1:
03b13f8d4d7f5f3d5734bb678c82223b3f2bf668 598018
kdebase-workspace-libs4+5_4.2.2-1_amd64.deb
05f95d4455277b5c0f97114ea2a641aaebaff9d5 74940 ksysguardd_4.2.2-1_amd64.deb
08945b1707e20b0f6ddf026024eeb6cb003d7ee6 105562
plasma-scriptengine-webkit_4.2.2-1_amd64.deb
0b0203b0c8b7dc1a72bed74f6be094aa18a44757 281690
systemsettings_4.2.2-1_amd64.deb
0d7574b1762c249e2ef91a9de768d655faee2628 59873810
kdebase-workspace-dbg_4.2.2-1_i386.deb
0d9cf64377bef62b6c982b2d095685709d107db9 3220774
kdebase-workspace-bin_4.2.2-1_amd64.deb
0ea9591198c5eef1e6211b14de4414aae192ebc2 70364
plasma-scriptengine-googlegadgets_4.2.2-1_amd64.deb
1ee2d93869f6b5659dbf355d117caef6a9e6324c 96594
plasma-scriptengine-webkit_4.2.2-1_i386.deb
204c3708c48ef32d4631014b86bad0abfdfb9d5d 78280 libkwineffects1_4.2.2-1_i386.deb
235f5e6ef0efcaa63f37eff4bbc32dff1724e5c5 274074 systemsettings_4.2.2-1_i386.deb
24b280b0cb112b115c6afd841bb1bbb0d2ef4d44 158136
kdebase-workspace-dev_4.2.2-1_amd64.deb
2f242a807cc30e04f8031094645f17a6abde2f67 2948910
kdebase-workspace-bin_4.2.2-1_i386.deb
34b72be7773bbd93939d1f62e3c81e907a08be4c 22908
plasma-scriptengines_4.2.2-1_all.deb
417ecca697914e8031845ed1df5f3a78581785dd 100284
kdebase-workspace_4.2.2-1.diff.gz
49a8edb0db7162352aeec6a40f836a01601174e8 153394
kdebase-workspace-dev_4.2.2-1_i386.deb
4ba301c77388a98a2ff2857252d128b6d4825c3f 41524
plasma-scriptengine-qedje_4.2.2-1_amd64.deb
507f4cd3ff3df390bb1e36d5b53af1c1a6b7a28d 1758082 kdm_4.2.2-1_amd64.deb
5426c5b05f7783b0fd29196fa8c5bc7657e8397d 39492
plasma-scriptengine-qedje_4.2.2-1_i386.deb
5b0ef9a934d30c71e4b2022108c0dbd687eca404 65664
plasma-scriptengine-googlegadgets_4.2.2-1_i386.deb
5dba2dd96663388b317b2027627b29b6d8a6ddb5 68058 ksysguardd_4.2.2-1_i386.deb
62f6a7222139b3dcabee76cc95a77f070169c4af 245148 ksysguard_4.2.2-1_amd64.deb
63c1526ae9c1c1a1880b4cdbebed628169513556 31418
plasma-scriptengine-python_4.2.2-1_all.deb
655d12c4ad63bbbc14902b02feb3e715b9c032a2 45127826
kdebase-workspace-data_4.2.2-1_all.deb
Accepted kdetoys 4:4.2.2-1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 05 Apr 2009 05:22:15 +0200 Source: kdetoys Binary: kdetoys amor kteatime ktux kweather kdetoys-dbg Architecture: all amd64 i386 source Version: 4:4.2.2-1 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Ana Beatriz Guerrero Lopez a...@debian.org Description: amor - KDE 4 desktop companion kdetoys-dbg - debugging symbols for kdetoys kdetoys- desktop toys from the official KDE 4 release kteatime - KDE 4 utility for making a fine cup of tea ktux - Tux screensaver for KDE 4 kweather - weather display applet for KDE Changes: kdetoys (4:4.2.2-1) unstable; urgency=low . * New upstream release. * Bump KDE build dependencies to 4.2.2. Checksums-Sha1: 036a4c85a3653e090606dfb675df3c5c6bb7fb6d 1374374 kdetoys_4.2.2.orig.tar.gz 05117ada873d5729e365f7d58a22a980407e9633 2021086 kdetoys-dbg_4.2.2-1_amd64.deb 25f3e6fd7b2922a5edeb1bc68653d93339d76f32 1010174 kweather_4.2.2-1_amd64.deb 479ce992ecb7e68d35e48e747718b5af94edfe19 108054 kteatime_4.2.2-1_amd64.deb 66c60ed297fee68ec9f030f9c5848e1b402a9976 1028080 kweather_4.2.2-1_i386.deb 6e3fe8a908ce557ea6ba7bc86d8774e3308d5345 2000596 kdetoys-dbg_4.2.2-1_i386.deb 77eb38e7f5332240741749530a411a61867ae30a 105456 kteatime_4.2.2-1_i386.deb 7c537d1ed059ab853ee5e159424ea2d261ac7680 123928 ktux_4.2.2-1_i386.deb 7ff2346000231119644abfb3b97937d0e36a6e83 5546 kdetoys_4.2.2-1_all.deb ab9aa529ed5e9cb8f0881ebea270d0e6b4d02986 228520 amor_4.2.2-1_amd64.deb b411f1ed1056cc5ba8bbf801dd994595228a3834 216968 amor_4.2.2-1_i386.deb de6451a79cc32e58d577aa7acff4e3e0b6ea7cb9 126832 ktux_4.2.2-1_amd64.deb 3ffde44fb4d0d65c43f2c57880d01a05874bf3d3 1633 kdetoys_4.2.2-1.dsc fe6dd998482af78982c9aedd84d9816923237a34 6976 kdetoys_4.2.2-1.diff.gz Checksums-Sha256: 01493d8bb21bbc69b635faa058d75cf30f20818ad104acfd4870611c5d9fe336 105456 kteatime_4.2.2-1_i386.deb 101409280fd9247f077654893a4c0aaeb663d4fd73bad63857755df84aaceeae 108054 kteatime_4.2.2-1_amd64.deb 265bcae123d4886371c96dff1b6627593c884d8c88a460e38222c6a32fd06f8f 2021086 kdetoys-dbg_4.2.2-1_amd64.deb 439c4536cfa8c7ca1f58cddefc2e2dfbd6caccdce03cfb959cc40f36c55e2556 1010174 kweather_4.2.2-1_amd64.deb 4e6971629174c1f0545a51bf89741faa53b5f3ca736da0e49b0b708c1d27dac2 123928 ktux_4.2.2-1_i386.deb c6382ed9d8fd75f8e171dddf21b7e28fe2dd8429e901ef694850d1f499e92103 1633 kdetoys_4.2.2-1.dsc 5fb4db094b576e9ffd25bcc96984d322713ecda56b8c6f5687dc2d53e97c855f 1028080 kweather_4.2.2-1_i386.deb 72535c0d619a322df1114e2bdb3a5a51afec3079fa6c9b2ef502b29ba3c1ff5e 6976 kdetoys_4.2.2-1.diff.gz 7bed7146e1142d61dd6c7bf0dd649ee0f3fa249be34f78c43f20ff83b5fefde3 228520 amor_4.2.2-1_amd64.deb 9a461894d7e2aef23995a7c529d244f4494e1fb2fa4cd6781baa36d6b039d4fe 5546 kdetoys_4.2.2-1_all.deb a23e16f66b5db3d12c795ddc05d409c3c09bfbfe15b89db73e8f85ccbe58a40c 126832 ktux_4.2.2-1_amd64.deb d9da7a018b2121b0955307f880211c87d88569f8fee75091ce0889e8dc8649ee 216968 amor_4.2.2-1_i386.deb e5f79d5f9b927468dbb3f1eff0598cbd6de394940dd342c4efcf3e7f068b0408 1374374 kdetoys_4.2.2.orig.tar.gz f7295a377fd097fb284042043fcf4425aacf20f9964f60f8a394709a5cfab982 2000596 kdetoys-dbg_4.2.2-1_i386.deb Files: 0ded52822e11eb37e8ca9238f96cd35f 228520 games optional amor_4.2.2-1_amd64.deb 2390d26991c9ed09fc70d3b8107616c8 1374374 kde optional kdetoys_4.2.2.orig.tar.gz 26a7645737572f4e55bc322026130f27 1010174 games optional kweather_4.2.2-1_amd64.deb 5ef8ff2902ef762492f8c818a4175ecc 123928 games optional ktux_4.2.2-1_i386.deb 91d5bb2f3a93bdc77615c064d5ed83f8 108054 kde optional kteatime_4.2.2-1_amd64.deb 97344c2912197d55b3b629fed653f7f6 126832 games optional ktux_4.2.2-1_amd64.deb a77685ebed4fae329277dd87360d99ec 216968 games optional amor_4.2.2-1_i386.deb b10426f2d262dc6b9551fa5916250280 105456 kde optional kteatime_4.2.2-1_i386.deb b75b3234cebb5f2b5dae31d020bdd585 2000596 libdevel extra kdetoys-dbg_4.2.2-1_i386.deb bf9a131669355edaefb535db122bd261 5546 kde optional kdetoys_4.2.2-1_all.deb c4971c8fa91c6b3ff8c572a927aa0db3 1028080 games optional kweather_4.2.2-1_i386.deb d47de69730ecd7c7a72ed5b11898ca71 2021086 libdevel extra kdetoys-dbg_4.2.2-1_amd64.deb d92b05479511bdba9c588545968b685d 6976 kde optional kdetoys_4.2.2-1.diff.gz 07568266e79868cbed4582ed23ff1b91 1633 kde optional kdetoys_4.2.2-1.dsc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Ana Guerrero iEYEARECAAYFAknZtNIACgkQn3j4POjENGGhrwCfZY8/+neFw/o7dROTL7S9TaXI PsMAmwXXmWE2nRcU2sepA5R5S9qUjoT7 =/2uc -END PGP SIGNATURE- Accepted: amor_4.2.2-1_amd64.deb to pool/main/k/kdetoys/amor_4.2.2-1_amd64.deb amor_4.2.2-1_i386.deb to pool/main/k/kdetoys/amor_4.2.2-1_i386.deb kdetoys-dbg_4.2.2-1_amd64.deb to pool/main/k/kdetoys/kdetoys-dbg_4.2.2-1_amd64.deb kdetoys-dbg_4.2.2-1_i386.deb to pool/main/k/kdetoys/kdetoys-dbg_4.2.2-1_i386.deb kdetoys_4.2.2-1.diff.gz to
Accepted kdegraphics 4:4.2.2-1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 31 Mar 2009 22:29:17 +0200 Source: kdegraphics Binary: kdegraphics kdegraphics-dbg kdegraphics-strigi-plugins gwenview kamera kcolorchooser kgamma kolourpaint4 kruler libksane0 libksane-dev ksnapshot libokularcore1 okular okular-dev okular-extra-backends libkdcraw7-dev libkdcraw7 libkexiv2-7-dev libkexiv2-7 libkipi6-dev libkipi6 Architecture: all amd64 i386 source Version: 4:4.2.2-1 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Closes: 436164 455852 Description: gwenview - image viewer for KDE 4 kamera - digital camera support for KDE 4 applications kcolorchooser - color chooser and palette editor for KDE 4 kdegraphics-dbg - debugging symbols for the KDE 4 graphics module kdegraphics - graphics applications from the official KDE 4 release kdegraphics-strigi-plugins - graphics file format plugins for Strigi Desktop Search kgamma - monitor calibration panel for KDE 4 kolourpaint4 - simple image editor for KDE 4 kruler - screen ruler for KDE 4 ksnapshot - screen capture tool for KDE 4 libkdcraw7-dev - RAW picture decoding C++ library (development) libkdcraw7 - Raw picture decoding C++ library (runtime) libkexiv2-7-dev - Qt like interface for the libexiv2 library (development) libkexiv2-7 - Qt like interface for the libexiv2 library (runtime) libkipi6-dev - library for apps that want to use kipi-plugins (development versi libkipi6 - library for apps that want to use kipi-plugins (runtime version) libksane0 - scanner library for KDE 4 (runtime) libksane-dev - scanner library for KDE 4 (development) libokularcore1 - libraries for the Okular document viewer okular-dev - development files for the Okular libraries okular - document viewer for KDE 4 okular-extra-backends - additional document format support for Okular Changes: kdegraphics (4:4.2.2-1) unstable; urgency=low . * New upstream release. * Bump bulid-deps * KDEGraphics is now free of a embedded xpdf copy. (Closes: #436164) * KDEGraphics no longer uses imlib. (Closes: 455852) Checksums-Sha1: 011c25935bd0658e2ef5e1f85631401fb391a21f 13516 kdegraphics_4.2.2-1_all.deb 064525a985a2bbdb12668982acd8b14beb00a89d 1295680 gwenview_4.2.2-1_i386.deb 072e5029cf262bbdfca5b35c87057844c55a20b8 84048 libksane0_4.2.2-1_i386.deb 0aff6c774df49a07e8eec72a11cfcf1cd85d422b 20396 kcolorchooser_4.2.2-1_amd64.deb 0f7bf63da9875f3512070dcb59e9ea6246e3fb48 24860 libkdcraw7-dev_4.2.2-1_i386.deb 10c19d2c20883627476de1ddba30f5a57c1fe5f8 20052 kcolorchooser_4.2.2-1_i386.deb 1608fbaadf605535f338e9ae3fb7105b4b7d866d 3988974 kdegraphics_4.2.2.orig.tar.gz 25142beacd0c59739d757a7e3def1b87086c00e1 43214 kdegraphics-strigi-plugins_4.2.2-1_i386.deb 2725c44ceceac94919c9ff48b41d21974a4c0dbd 45250 kdegraphics-strigi-plugins_4.2.2-1_amd64.deb 31a59a66b2983a1efa733598a4020bbf80f79238 24955544 kdegraphics-dbg_4.2.2-1_i386.deb 32a248962a5895cddd9988eddabc6b4750113643 22778 libkexiv2-7-dev_4.2.2-1_i386.deb 366f8ec46fea5a918d7f3cda8ea19363def16488 273972 libokularcore1_4.2.2-1_amd64.deb 3aed051f393d729d67d5d8ba69c0527174f9 933484 kolourpaint4_4.2.2-1_i386.deb 3e40b9f0536f171527e0b748164b31386563f329 22654 libkexiv2-7-dev_4.2.2-1_amd64.deb 5a7f53ff4869139403fadfbe12b1ee618978f701 152826 okular-extra-backends_4.2.2-1_amd64.deb 69a920c821691626652d728d72adb23fc98bcd94 142462 okular-extra-backends_4.2.2-1_i386.deb 6c4b981699786870f14cb3c0518c8dc41732e1f2 194074 ksnapshot_4.2.2-1_i386.deb 7a0d3a2175e3e702297826b23c0349d753450c0f 17318 libksane-dev_4.2.2-1_amd64.deb 876d0dca826e86cd4adfda1f227ba850a9905884 67654 libkipi6_4.2.2-1_i386.deb 4e78725829a41df0276899ef1dcceadf32289bd8 2100 kdegraphics_4.2.2-1.dsc 922c8520e578125be9b925fe88083e7908d4d7ff 24772 libkdcraw7-dev_4.2.2-1_amd64.deb 944cb695d25de74d215147ab5346df1059c7685c 17338 libksane-dev_4.2.2-1_i386.deb 949ce75de64147050751bd679beead059bda2d69 219156 libkdcraw7_4.2.2-1_amd64.deb 98a16264ce13c96010b92797d3f511954d4df72b 49122 okular-dev_4.2.2-1_amd64.deb 99d109f9040d56e94b277dfb652fe60cf6331250 17288 kdegraphics_4.2.2-1.diff.gz 9e9516ad4b4f783cad34bfb8e0e6753b0a85ed57 70150 libkipi6_4.2.2-1_amd64.deb a83d864eeea071ea9b577f119c28784868b7f9c8 76668 kamera_4.2.2-1_i386.deb ab7895d2d7a3a970fd7e4e0977ff94ac931a2bc8 982278 kolourpaint4_4.2.2-1_amd64.deb b81ace6cab0d974057ad1786e9281a5db8a656d0 25197934 kdegraphics-dbg_4.2.2-1_amd64.deb b998a0753cd0264e5be276b58d636da71b06b82b 89356 libksane0_4.2.2-1_amd64.deb c101d6aa62500340e9787be36d22ac66a6b37d28 222142 libkdcraw7_4.2.2-1_i386.deb c18048e1bf9c021ab3a16e46b7af12f14d47613c 68422 kgamma_4.2.2-1_amd64.deb cbb6adba1a8385fb921016f0b0a649506839cbf3 19316 libkipi6-dev_4.2.2-1_i386.deb ce0543e9095722d64250552ed4facccd47800cad 1333666 gwenview_4.2.2-1_amd64.deb cfb6d837d489b5a0c6e8e995b36b202db736c71f 1026888
Accepted kdebase-runtime 4:4.2.2-1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 05 Apr 2009 01:36:57 +0200 Source: kdebase-runtime Binary: kdebase-runtime kdebase-runtime-bin-kde4 kdebase-runtime-data kdebase-runtime-data-common khelpcenter4 kde-icons-oxygen kdebase-runtime-dbg Architecture: all amd64 i386 source Version: 4:4.2.2-1 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Description: kdebase-runtime-bin-kde4 - core binaries for the KDE 4 base runtime module kdebase-runtime-data-common - shared data files for the KDE 4 base runtime module kdebase-runtime-data - shared data files for the KDE 4 base runtime module kdebase-runtime-dbg - debugging symbols for KDE 4 base runtime module kdebase-runtime - runtime components from the official KDE 4 release kde-icons-oxygen - Oxygen icon theme for KDE 4 khelpcenter4 - Help Center for KDE 4 Changes: kdebase-runtime (4:4.2.2-1) unstable; urgency=low . * New upstream release. . +++ Changes by Sune Vuorela: . * Bump build-deps. Checksums-Sha1: 556d7a8de2caa956954bf436320f6fea99af9d32 2077 kdebase-runtime_4.2.2-1.dsc 13738565e4fc1b99701f3aaad97c436d06cdf8ff 56228 kdebase-runtime-bin-kde4_4.2.2-1_i386.deb 1b7e4a2a31c9bcf156aee8ba13deea61f9068a30 59870 kdebase-runtime-bin-kde4_4.2.2-1_amd64.deb 1f83bf09dc1ce3b35be6455f113ff5379db04a19 23633 kdebase-runtime_4.2.2-1.diff.gz 33ad7b8f81560a83beb4665c047db229af2a17d4 72319687 kdebase-runtime_4.2.2.orig.tar.gz 4821452bb144a577a526f8251831aff2216c0673 366040 kdebase-runtime-data-common_4.2.2-1_all.deb 96d5b1b07e3616b7632746cf13e65fd1d98fe70b 1894902 kdebase-runtime_4.2.2-1_i386.deb a2abd9e721bf89cefdd4526b430c92cea5f5df7a 2067046 kdebase-runtime_4.2.2-1_amd64.deb c09bf851200a88520b1346ae3e58b1cb10a22caa 15073492 kdebase-runtime-dbg_4.2.2-1_i386.deb c2e46bbe855598c10aa15a76cf2343473534790d 65454066 kde-icons-oxygen_4.2.2-1_all.deb dbfb49da832948a5de0b854eec786938a281d029 1848022 khelpcenter4_4.2.2-1_i386.deb eebd80b4b13cd840fc39d597787a52a095c8b8f0 1865700 khelpcenter4_4.2.2-1_amd64.deb f5fe2edf94e3296325c982deb71fc5b5dfc43082 3766636 kdebase-runtime-data_4.2.2-1_all.deb f6424acbbb99a88ca36a0d2330e30aafca822550 15255804 kdebase-runtime-dbg_4.2.2-1_amd64.deb Checksums-Sha256: 2757d827380e3bc481f6cc13dfd64897a1ada536caf9258fe742d6540bec4cfd 366040 kdebase-runtime-data-common_4.2.2-1_all.deb 3ff04445c6920d451a87eb89f17cb763931da166279cff9fbd8a6110d0be5e6a 65454066 kde-icons-oxygen_4.2.2-1_all.deb 54dba5fbacecf3c7ae3eeafcc824e71b226d49c6a4a9569f3c32e7d171413e39 15073492 kdebase-runtime-dbg_4.2.2-1_i386.deb 5a2de39f6f01cdf2e85c0623a32ffc433c5b6d0a10be25a998dc32a86dececf0 1894902 kdebase-runtime_4.2.2-1_i386.deb 6ba0e49b41456043625d1387e4efffad8196a4bcd9b11753223bbb5919a2f979 59870 kdebase-runtime-bin-kde4_4.2.2-1_amd64.deb 94cd8ff8ffc7c521f2f60191aa64240f1f4d7dabd17caa84d1a42f2079f619d5 2067046 kdebase-runtime_4.2.2-1_amd64.deb 50c006d5c3bca297df4915767b9dcc9417103cdc6a4b1b347a350bb37b70cff6 2077 kdebase-runtime_4.2.2-1.dsc b5bafc89a26b908f12454a770f2e710b7d3147a5c21daf7649be71d1ce6345b7 1848022 khelpcenter4_4.2.2-1_i386.deb b5f513acc5350b85851c88d4a392637b1740c1d07d8e7eaa60c959a778bf99ac 23633 kdebase-runtime_4.2.2-1.diff.gz c14cb1e8c50554d0f68ba7873c596ea9b56bcd743949caf5bf3990ed28edaa29 1865700 khelpcenter4_4.2.2-1_amd64.deb c3552f71ab1ba337aa32886b3ead7fb7b35d8e858c2a934f0f15b4261673dd03 72319687 kdebase-runtime_4.2.2.orig.tar.gz c7b48c664e5cf231f47cefee982f082366b0504ede986d0d263eb84db2df1005 3766636 kdebase-runtime-data_4.2.2-1_all.deb cac8d19b8a1d1bda0037a5083289f3040f18072d5c0f3fcc43d27d9e361c5452 56228 kdebase-runtime-bin-kde4_4.2.2-1_i386.deb f3ae42f72673307057ea192322b86acbf9d5caa2efb767e95c3bd99616dc1c48 15255804 kdebase-runtime-dbg_4.2.2-1_amd64.deb Files: 15c273e1d3ebd6907904c3ca55427f62 65454066 kde optional kde-icons-oxygen_4.2.2-1_all.deb 19f8e2ba69cb10b2305afb7b6907c8e6 366040 kde optional kdebase-runtime-data-common_4.2.2-1_all.deb 1b61aeb7568977fd5de68df1d9cb5bf8 3766636 kde optional kdebase-runtime-data_4.2.2-1_all.deb 26fbb915df729233628f4c23b0a79b3d 15073492 devel extra kdebase-runtime-dbg_4.2.2-1_i386.deb 30d9a9c19d8f0bd31db63352b6a511ba 23633 kde optional kdebase-runtime_4.2.2-1.diff.gz 331406aa855fdbe5034cce8b1b21fe9b 1894902 kde optional kdebase-runtime_4.2.2-1_i386.deb 3e5e52daf8c9e19d6fc3ab3197865fe5 72319687 kde optional kdebase-runtime_4.2.2.orig.tar.gz 4847cb35c454e82b2bdc64afeb514967 15255804 devel extra kdebase-runtime-dbg_4.2.2-1_amd64.deb 4ef0cbc15351d7e3f7ba539d879a3d4d 59870 kde optional kdebase-runtime-bin-kde4_4.2.2-1_amd64.deb 6302a3b0c80cfec1ab9f053c748e46d0 1848022 kde optional khelpcenter4_4.2.2-1_i386.deb 69d7745b5252bf09bc52719a260f63f4 56228 kde optional kdebase-runtime-bin-kde4_4.2.2-1_i386.deb cb90ec8d02ad4bea4e8e43c4be1a910a 1865700 kde optional
Accepted meta-kde4 5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 Apr 2009 03:32:52 +0200 Source: meta-kde4 Binary: kde4 kde4-minimal kde4-development Architecture: source all Version: 5 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Ana Beatriz Guerrero Lopez a...@debian.org Description: kde4 - the K Desktop Environment 4 kde4-development - the KDE 4 development platform kde4-minimal - the K Desktop Environment 4, minimal applications Changes: meta-kde4 (5) unstable; urgency=low . * Update all the depends to (= 4.2.2). * Add Suggests on kdebindings for kde4-development. Checksums-Sha1: ddb9bcd27fcf3527459b529cdeb91c54ec9570cd 1009 meta-kde4_5.dsc 12553a8b49c021fa7b373c65a17519cd6fabf97a 2480 meta-kde4_5.tar.gz cd5c28d7d9f7813f8ebab75010841ece91b0fd7c 2546 kde4_5_all.deb 27f90cae7d798f9223854457a413310d24ea6be4 2430 kde4-minimal_5_all.deb 9a76810a75121c6c8fa75a7772b3980427773a65 2348 kde4-development_5_all.deb Checksums-Sha256: b298b4ed16bc5e78e6eedfd0b40af431298da7a6f473e4aaf2d808db574c4c59 1009 meta-kde4_5.dsc 8d93d8c1a4facdb2f23da0c8c4befe83b3bb39c3baf58e7ac13cc21ce27a4193 2480 meta-kde4_5.tar.gz f45b89da9f1c3fc36fc3a4c5803c609f4fdb3d28db50791b1bc22f783e8b3d2b 2546 kde4_5_all.deb 1d43ff7de8161ddd6348ec7b2c3b9d47a2aea743fa5e1c956cb3969ddd0cb403 2430 kde4-minimal_5_all.deb b2bf12c29221a343246d96d3fa1a2e8de49a2d838fc94f649db4b727c92ad78f 2348 kde4-development_5_all.deb Files: 7f61882104575aff4aaafaa7b66b22a8 1009 kde optional meta-kde4_5.dsc cb968315e97fb70e7535a8b3f8454007 2480 kde optional meta-kde4_5.tar.gz 376cc638111ef75c23b286f9179679f7 2546 kde optional kde4_5_all.deb 90dac97f76bd773877cc5b1a8819643c 2430 kde optional kde4-minimal_5_all.deb 20acc4bb443ed8d3dbb7ca6379f22d6e 2348 kde optional kde4-development_5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Signed by Ana Guerrero iEYEARECAAYFAknZw3EACgkQn3j4POjENGEFugCfbgGXMbWEjakL1TV5ubO2aLLi PYUAnilFcnIbxJqRd5wCL73b8YBMySJ5 =Uv3R -END PGP SIGNATURE- Accepted: kde4-development_5_all.deb to pool/main/m/meta-kde4/kde4-development_5_all.deb kde4-minimal_5_all.deb to pool/main/m/meta-kde4/kde4-minimal_5_all.deb kde4_5_all.deb to pool/main/m/meta-kde4/kde4_5_all.deb meta-kde4_5.dsc to pool/main/m/meta-kde4/meta-kde4_5.dsc meta-kde4_5.tar.gz to pool/main/m/meta-kde4/meta-kde4_5.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted pkg-kde-tools 0.4.2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 01 Apr 2009 22:23:23 +0200 Source: pkg-kde-tools Binary: pkg-kde-tools Architecture: source all Version: 0.4.2 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Sune Vuorela deb...@pusling.com Description: pkg-kde-tools - common makesnippets and build scripts for KDE4 related packages Changes: pkg-kde-tools (0.4.2) unstable; urgency=low . * Remove setting of kde home. We now use the default. * Add aggressive conflicts to avoid bad accidents. Checksums-Sha1: eae49a4f6131ce2288406384f8e91ff1c1c5cc05 989 pkg-kde-tools_0.4.2.dsc ce844ef3900151dcfe24bb86e4cf0c06781b28ba 99462 pkg-kde-tools_0.4.2.tar.gz a64aba7604dbb0c602ad908709afb9266764a57d 28090 pkg-kde-tools_0.4.2_all.deb Checksums-Sha256: 94064336e0864a887340e5dbf83eaf227cd50b36fe85ca9b8a1bf0a8e8a527b6 989 pkg-kde-tools_0.4.2.dsc f52f270d999a6f1fd537185bb2ca1042cb4802ee721f060654ad22a2050fdcaa 99462 pkg-kde-tools_0.4.2.tar.gz 4bcfd3691ecd13e567849791912676787856656c9d52db58c2754f932c203fdd 28090 pkg-kde-tools_0.4.2_all.deb Files: bb4284bd2378460ca35e49f8dd7de9fd 989 devel extra pkg-kde-tools_0.4.2.dsc 07ff0e155b45b9061b8bbc743b95cc5c 99462 devel extra pkg-kde-tools_0.4.2.tar.gz 4b5c54c712b2243ce607d05cfaf3e2a0 28090 devel extra pkg-kde-tools_0.4.2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAknZuSoACgkQnMvaFgH6i0pK2wCXQQH5GXBvKQDW07E5me3fjrUp bgCgjjhqth+qk/iaegGtrczWg262SUs= =pqRz -END PGP SIGNATURE- Accepted: pkg-kde-tools_0.4.2.dsc to pool/main/p/pkg-kde-tools/pkg-kde-tools_0.4.2.dsc pkg-kde-tools_0.4.2.tar.gz to pool/main/p/pkg-kde-tools/pkg-kde-tools_0.4.2.tar.gz pkg-kde-tools_0.4.2_all.deb to pool/main/p/pkg-kde-tools/pkg-kde-tools_0.4.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
Accepted kdeaccessibility 4:4.2.2-1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 04 Apr 2009 22:10:35 +0200 Source: kdeaccessibility Binary: kdeaccessibility kde-icons-mono kmag kmouth kttsd kmousetool kdeaccessibility-dbg Architecture: all amd64 i386 source Version: 4:4.2.2-1 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Ana Beatriz Guerrero Lopez a...@debian.org Description: kdeaccessibility - accessibility packages from the official KDE release kdeaccessibility-dbg - debugging symbols for kdeaccessibility kde-icons-mono - a monochromatic icons theme for KDE kmag - a screen magnifier for KDE kmousetool - KDE mouse manipulation tool for the disabled kmouth - a type-and-say KDE frontend for speech synthesizers kttsd - a Text-to-Speech system for KDE Changes: kdeaccessibility (4:4.2.2-1) unstable; urgency=low . * New upstream release. Checksums-Sha1: 0c7fabe50c05c4f0ea671324b5dfdc7e754ec7f6 1684140 kttsd_4.2.2-1_amd64.deb 16b8579a7619aeefadd079e7637112dd382d5aef 7064786 kdeaccessibility_4.2.2.orig.tar.gz 46aa5b90e0acb924860ca2c9cd3d9ec2926956c8 57070 kmousetool_4.2.2-1_i386.deb 8effd8f5731656a2ba91d48abe67d0e1623a60a9 5659464 kdeaccessibility-dbg_4.2.2-1_amd64.deb 9cd4d8e6acd2daefd4a4edb9c177b9c3c148f1ae 258560 kmag_4.2.2-1_i386.deb 9d82141afe22b8f52bdf0a9635bb3a19b5c50c3d 4484208 kde-icons-mono_4.2.2-1_all.deb b1d64200bd423f13d772450fe970abe3da3715d5 1640584 kttsd_4.2.2-1_i386.deb b4e228f50b7e1b609b8260847b21961575c9344e 58686 kmousetool_4.2.2-1_amd64.deb bed22572167f71c1b478af88664ddf9a267f03a4 5592122 kdeaccessibility-dbg_4.2.2-1_i386.deb c32ec98ecc5404f71a6060bc8d538fe52b1c7afd 262632 kmag_4.2.2-1_amd64.deb e1a2127d887678cc99e9b330f8a745891aa616f5 18511 kdeaccessibility_4.2.2-1.diff.gz c2baef8d70b89845ac3574feb82ab85d80496ad1 1566 kdeaccessibility_4.2.2-1.dsc f2c6941ff8535e2fcf854a90a1759500a493df6d 316532 kmouth_4.2.2-1_amd64.deb fb56a45d6e3ccd871cb4654a3540977e2c88b10d 301928 kmouth_4.2.2-1_i386.deb feec25020e3a7aada398c4469e970287309466fd 4668 kdeaccessibility_4.2.2-1_all.deb Checksums-Sha256: 026fce0b636114802402443dd5cb051f64959a9e1538a061ae5e782d0e59ad92 18511 kdeaccessibility_4.2.2-1.diff.gz 1f7a6c13de3a1cf6b332ff9fca4d0bc4e7031e6caa887d4a64cfd27b596de048 4484208 kde-icons-mono_4.2.2-1_all.deb 49881a7be5a70cd2799c4c2086ccd54e4871946c17f1e402840eb9b97461a479 1684140 kttsd_4.2.2-1_amd64.deb b68e09a34697d5e2782d7224a671fcae807ff2d2be3354fa020eb1c98957eebf 1566 kdeaccessibility_4.2.2-1.dsc 5e68942c6f75f6daf41a95cfa54be13b68af916d3a8e13a9aaf85f5779df3b83 1640584 kttsd_4.2.2-1_i386.deb 67ca3385fa304c39399e5a49c8cf8e9da1ff5a81f8b1fe81ba70513852f6120b 301928 kmouth_4.2.2-1_i386.deb 71ee7d56b177410c77f2df014b2aa8fe563fc310f5980824d5eaa79ae2ab922b 4668 kdeaccessibility_4.2.2-1_all.deb 72e98cd83d3a6d3b36f640908f97946a91696da759260cfd7c823547055f9438 7064786 kdeaccessibility_4.2.2.orig.tar.gz 82df398e1b6c87858643a1441dd1bd667e68b8238963549c862efde6c4b6e83c 58686 kmousetool_4.2.2-1_amd64.deb 9c7fd62db629faaf81b4600bcf2600f6f285803ce07f3c7ddaf91b1f2bc38eb8 5659464 kdeaccessibility-dbg_4.2.2-1_amd64.deb aa40c0323f6a3825e4d68391a1a1b8c442309f4e10c8b8f2840343ea0e401655 262632 kmag_4.2.2-1_amd64.deb b778fd219d49fae9d3b6876e401eb7e38dc5c36ec3cc1d37311c44110372b696 5592122 kdeaccessibility-dbg_4.2.2-1_i386.deb ba93cab9573ec2d2ef50245ca635997970f884e646c0196e8edb40b0687873d8 316532 kmouth_4.2.2-1_amd64.deb e96eb58d3dac104782b31a5a05a5acdd066ad2056195bc280ca59023038e9220 258560 kmag_4.2.2-1_i386.deb ef2af45828de590dc530c5fca6e569f348b0cf5650b921b8476f43bc623b2bc4 57070 kmousetool_4.2.2-1_i386.deb Files: 08191b98b96d2a52cf6fe568768c40dc 262632 utils optional kmag_4.2.2-1_amd64.deb 0dbe1560e4e9f321a51c49d20369887e 301928 utils optional kmouth_4.2.2-1_i386.deb 0e43d0607b50ebc0acd304960d6e0cb1 18511 kde optional kdeaccessibility_4.2.2-1.diff.gz 27c65a3740811cca36ab3286f0689a23 316532 utils optional kmouth_4.2.2-1_amd64.deb 44c69a057867f5bc47084ed2c1724370 1566 kde optional kdeaccessibility_4.2.2-1.dsc 4194fb5ebcb43302967ea8d1e51673c0 57070 utils optional kmousetool_4.2.2-1_i386.deb 6dea98c811205647351b6a7518989e2f 4484208 kde optional kde-icons-mono_4.2.2-1_all.deb 74cf1451bb4801f356d38cce81354930 7064786 kde optional kdeaccessibility_4.2.2.orig.tar.gz 86819a51696a7a362711a3c3e42e7a93 4668 kde optional kdeaccessibility_4.2.2-1_all.deb 96982dc8f7312fbbe98aafcd2898134c 5659464 libdevel extra kdeaccessibility-dbg_4.2.2-1_amd64.deb aa4834a3a4fca7e863eea58d0c352951 58686 utils optional kmousetool_4.2.2-1_amd64.deb aed6506ef5b1b53f59633f9155f3fd9e 5592122 libdevel extra kdeaccessibility-dbg_4.2.2-1_i386.deb b52b2c9c7d7e541939173e6c4b8c1fdd 1640584 utils optional kttsd_4.2.2-1_i386.deb eddae46927f1b617ae66831a3a612914 258560 utils optional kmag_4.2.2-1_i386.deb f7919f97b3a914ba1980963592fec6ea 1684140 utils optional kttsd_4.2.2-1_amd64.deb -BEGIN PGP
Accepted ncurses 5.7+20090404-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 6 Apr 2009 11:22:00 +0200 Source: ncurses Binary: libncurses5 libncurses5-dev libncurses5-dbg libncursesw5 libncursesw5-dev libncursesw5-dbg lib64ncurses5 lib64ncurses5-dev lib32ncurses5 lib32ncurses5-dev lib32ncursesw5 lib32ncursesw5-dev ncurses-bin ncurses-base ncurses-term Architecture: source i386 all Version: 5.7+20090404-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann dan...@debian.org Changed-By: Daniel Baumann dan...@debian.org Description: lib32ncurses5 - shared libraries for terminal handling (32-bit) lib32ncurses5-dev - developer's libraries for ncurses (32-bit) lib32ncursesw5 - shared libraries for terminal handling (wide character support) ( lib32ncursesw5-dev - developer's libraries for ncursesw (32-bit) lib64ncurses5 - shared libraries for terminal handling (64-bit) lib64ncurses5-dev - developer's libraries for ncurses (64-bit) libncurses5 - shared libraries for terminal handling libncurses5-dbg - debugging/profiling libraries for ncurses libncurses5-dev - developer's libraries and docs for ncurses libncursesw5 - shared libraries for terminal handling (wide character support) libncursesw5-dbg - debugging/profiling libraries for ncurses libncursesw5-dev - developer's libraries for ncursesw ncurses-base - basic terminal type definitions ncurses-bin - terminal-related programs and man pages ncurses-term - additional terminal type definitions Changes: ncurses (5.7+20090404-1) unstable; urgency=low . * Merging upstream version 5.7+20090404. Checksums-Sha1: 4af73063c9974f46263ef03ef627c197db95f9ac 1517 ncurses_5.7+20090404-1.dsc 9bb5d03167a0fae373527a07b89989fb9b2b6696 2529671 ncurses_5.7+20090404.orig.tar.gz 9ec94f9e7aa1601a3b2ad3c152c647afae23f35c 39920 ncurses_5.7+20090404-1.diff.gz 9834b85a17f054155db740ed325a27996b5eec41 339474 libncurses5_5.7+20090404-1_i386.deb 79fd60b4d25de9ceaa5028613a9361b790e464c7 1556418 libncurses5-dev_5.7+20090404-1_i386.deb 660964dd816714df7ffc8cf22f13bfe4e969855e 1849906 libncurses5-dbg_5.7+20090404-1_i386.deb 447d743a7b3f01bb6a7a8306ba6d91c1ef2e8f1c 362380 libncursesw5_5.7+20090404-1_i386.deb a67ebc98e89249ba50b0f8f7dc4dcf653e13e0fe 479696 libncursesw5-dev_5.7+20090404-1_i386.deb 9537e63b1e5df58b68244677b2776a9fcef02a8b 2064358 libncursesw5-dbg_5.7+20090404-1_i386.deb 1ad927f7c554db69a4471bb48844bc1c0631effa 353336 lib64ncurses5_5.7+20090404-1_i386.deb 60042de2ee6062465cf95f7bf0cbaeba366c2724 419672 lib64ncurses5-dev_5.7+20090404-1_i386.deb f0cda24a1703c5d6f711514a167776c6d8767159 305870 ncurses-bin_5.7+20090404-1_i386.deb 7e2dff5df4613f0746f4c147ea3623ec58388d75 180188 ncurses-base_5.7+20090404-1_all.deb fb5f7557f7bf450b33e2419c271ca1b60ae6124e 561924 ncurses-term_5.7+20090404-1_all.deb Checksums-Sha256: 986abf02f66fb3d25efd3628f03d22839a750f4194e5f014157de33d8b2b9abd 1517 ncurses_5.7+20090404-1.dsc 8f197371370fd31ee1f6297e11525e39e1cfef36e9b2b15467acd24846f5c4b5 2529671 ncurses_5.7+20090404.orig.tar.gz 50264fe71fcc52e36f6f6d2bf47b63b8e68623557db410bc7e389c680788b247 39920 ncurses_5.7+20090404-1.diff.gz 74a381e60eef3faf492a1b515f5cbbe1157c35a1ae1333fb0e9fb93593d7f030 339474 libncurses5_5.7+20090404-1_i386.deb ff86f066f6aeb065280e4c459439277df947ebc2a5161f5c70a825a81a8a48b7 1556418 libncurses5-dev_5.7+20090404-1_i386.deb 263acfba37aa86421cf2fd2a9947ff008be62d980d38fb9976895f77a934f123 1849906 libncurses5-dbg_5.7+20090404-1_i386.deb d701ffd474879023fa94fc2dd015e69aa366d2ac06df1a09d6a920c907d95d74 362380 libncursesw5_5.7+20090404-1_i386.deb b0ebac3f55eaaa17763b6e4ae80f3e4308f2b099875a757ea091916034015de6 479696 libncursesw5-dev_5.7+20090404-1_i386.deb 0cf97f45412a125ea37d2d3eda4cb4e263e2c373db3aa8f0c9eca6dc5dbc9d81 2064358 libncursesw5-dbg_5.7+20090404-1_i386.deb 7a1216a8b41959bc641be8948dfba59e911defac02e76a149a26b008ad8856fb 353336 lib64ncurses5_5.7+20090404-1_i386.deb ec2a61b702a09b0d551ef7702f8523bcf5621c6cf1564fbfeed16d27b892730a 419672 lib64ncurses5-dev_5.7+20090404-1_i386.deb 0924cddf6db4ccfed82d4582ebe71d08d5cc45b4280b1537443e1accc6e675b7 305870 ncurses-bin_5.7+20090404-1_i386.deb f36adfbc7433572bbc5eb138c80dd010a0c2b4dfbdd0421974dc8693f9dbcd49 180188 ncurses-base_5.7+20090404-1_all.deb 9a5d8df4bcb222ac0cb1a7b6f4f54606f313f00b1567c858dd0031224224e060 561924 ncurses-term_5.7+20090404-1_all.deb Files: fa13c197adccea464eac20e25d309167 1517 libs standard ncurses_5.7+20090404-1.dsc a0949006ca28de7f66997f3d6ba7610a 2529671 libs standard ncurses_5.7+20090404.orig.tar.gz 07afc2c54fb287b1f732b42dcd1a6957 39920 libs standard ncurses_5.7+20090404-1.diff.gz 9f89d60649102cc9ed50b19119d5c13f 339474 libs required libncurses5_5.7+20090404-1_i386.deb 3cb46922fc6c8ed7ba915a8673857887 1556418 libdevel optional libncurses5-dev_5.7+20090404-1_i386.deb 3987548a08841083a0220a234a0b2ff9 1849906 debug extra libncurses5-dbg_5.7+20090404-1_i386.deb f353dbbe13abe728ead0435f54c63719 362380 libs important
Accepted nap 1.5.4-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 Apr 2009 10:03:01 +0200 Source: nap Binary: nap Architecture: source i386 Version: 1.5.4-4 Distribution: unstable Urgency: low Maintainer: Massimo Dal Zotto d...@debian.org Changed-By: Massimo Dal Zotto d...@debian.org Description: nap- napster console client Closes: 504676 Changes: nap (1.5.4-4) unstable; urgency=low . * Added spanish debconf templates translation. Closes: #504676. Checksums-Sha1: 72418921ccc33a9b6fcc386f914b5952881a50ac 944 nap_1.5.4-4.dsc 5bdc57835e2c9c2cc4189c98adee8ef7cfea3763 12725 nap_1.5.4-4.diff.gz bbac2050d5a08834581dcefcc2908ac0c5f5ac8c 184846 nap_1.5.4-4_i386.deb Checksums-Sha256: 2f9178e51ecf5f1490fc9001900dc697b2e4c347f35a15d8cd7240f22218f2f4 944 nap_1.5.4-4.dsc d5e6b0038d87f9043fc917ad574d8420284c43efa82b9e107410a0dcfc54eb70 12725 nap_1.5.4-4.diff.gz cfcc983b5ffe3d72b187e238bb48211a6f979ce75fa0da1b82d7b00edacf44a8 184846 nap_1.5.4-4_i386.deb Files: 8cc7459180040d0ecaca91fbb8605d9d 944 net optional nap_1.5.4-4.dsc 37c1cefbd40ad9b4d9ab473d7a9f2b46 12725 net optional nap_1.5.4-4.diff.gz 1fa05c1ab41ae460ea8ee9ba4b48a8f7 184846 net optional nap_1.5.4-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknZ2wIACgkQFH8a6i22VZZpUwCfapCkmPHwkY3c0H04go6KOtVq rd4An0dKTRDDdSAQjjR169POmRozh4Lc =44Y1 -END PGP SIGNATURE- Accepted: nap_1.5.4-4.diff.gz to pool/main/n/nap/nap_1.5.4-4.diff.gz nap_1.5.4-4.dsc to pool/main/n/nap/nap_1.5.4-4.dsc nap_1.5.4-4_i386.deb to pool/main/n/nap/nap_1.5.4-4_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
