Re: [Listmaster] Seeking petsupermarket
On Jan 03, Gene Heskett [EMAIL PROTECTED] wrote: every legit address I can think of at uol.br.com, with zero bounces, so they are either a damned good black hole, or are well aware of the nuisance they are being and just don't give a starving rats ass. [X] they are well aware and do not care -- ciao, Marco signature.asc Description: Digital signature
Re: spohr.debian.org not sending email
Ryan Murray [EMAIL PROTECTED] writes: exim treats 45x errors to be per host, rather than per address. That depends on when it gets the error. If exim gets a timeout or an error message after sending RCPT TO, it is treated as a recipient error, and not a host error. http://exim.org/exim-html-4.30/doc/html/spec_43.html#SECT43.2 -- Stig Sandbeck Mathisen [EMAIL PROTECTED] pgpgQvpKOU9ZV.pgp Description: PGP signature
Re: How to Increase Contributions from Volunteers
Joseph Michael Smidt wrote: I believe the greatest barrier the Debian Project has in preventing widespread contributions from greater numbers of volunteers is a psychological barrier. I have personally introduced Debian to several of my friends and always emphasize the idea that they too can contribute to the great cause whether by documentation, translation or adopting a package, etc... Universally they are excited, desire to try it out, then come back having read what it takes to be a Debian Developer and are overwhelmed. They then begin searching out other open source projects where it seems psychologically they will be able to be more of an assistance. They are right: most probably they will find it easier to make contributions to other projects. What is missing from your message is the argument why this should be changed. Would it in fact be a good thing if your friends devoted their time to Debian rather than to those other projects? It is not obvious to me that that would be better. The great cause is the free software movement as a whole. Within that movement there should be room for different kinds of projects, including exclusive hobby clubs. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#344417: ITP: freebsd6-buildutils -- Utilities for building FreeBSD 6.x sources
Le jeudi 22 décembre 2005 à 16:51 +0100, Robert Millan a écrit : This package contains the FreeBSD 6.x counterparts of some standard build utilities (make, yacc, lex ..) . They have some specific modifications needed to be able to build FreeBSD 6.x sources. Maybe it's a dumb question, but isn't there a way to patch these tools and/or the freebsd sources so that we can build them with the standard tools in Debian? Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: How to Increase Contributions from Volunteers
* Thomas Hood [EMAIL PROTECTED] [2006-01-03 12:24:29]: They are right: most probably they will find it easier to make contributions to other projects. we need to promote the easy entry points to contributing to debian more prominently and should hide the how to become a DD in comparison. we should leave that option for the ones that want to contribute above average. signature.asc Description: Digital signature
Re: not getting CCs from the bugs I reported
Le mercredi 28 décembre 2005 à 23:49 -0600, Adam Heath a écrit : You'll only get mails if the sender sends to ###-submitter. Mail sent to just ### is not forwarded, and only stored. This is not a bug in the software, but in the person sending the mail. I consider this a bug in the software. It's awkward not to receive some communications on a bug you submitted. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Bug#345769: ITP: locomo -- Logitech Mouse Control for USB mice
Package: wnpp Severity: wishlist Owner: Thibaut VARENE [EMAIL PROTECTED] * Package name: locomo Version : 1.0 Upstream Authors: Alexios Chouchoulas [EMAIL PROTECTED] Andreas Schneider [EMAIL PROTECTED] Tobias Schleuss [EMAIL PROTECTED] * URL : http://lomoco.linux-gamers.net/ * License : GPL Description : Logitech Mouse Control for USB mice lomoco can configure vendor-specific options on Logitech USB mice (or dual-personality mice plugged into the USB port). A number of recent devices are supported. The program is mostly useful in setting the resolution to 800 cpi or higher on mice that boot at 400 cpi (such as the MX500, MX510, MX1000 etc.), and disabling SmartScroll or Cruise Control for those who would rather use the two extra buttons as ordinary mouse buttons. It can also retrieve battery level from wireless mice. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (90, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-ck7-bz Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
On Mon, Jan 02, 2006 at 08:19:30PM +0100, Adrian von Bidder wrote: 'just plug' is the watchword. New device model just needs a reboot - in some circumstances device numbering is random without hardware changes and without software changes. So it exposes a bug more frequently than before. So why not fix the bug instead of trying to paper over it forever? As a user, a disk changing its name if I plug it to a different SATA connector that happens to be connected to a different chip on the MB is _exactly_ the same problem as the name change on a single reboot. Any solution must work equally well for the plugged in at a different location case or it is useless. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: How to Increase Contributions from Volunteers
On Tue, 03 Jan 2006, Andrew Vaughan wrote: Whats needed is a genuine team of 2-5 suitable new maintainer 'peers' [...] You just described how Alioth-based team maintainership works when it involves people who aren't DDs, which it often does AFAIK. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Andreas Schuldei wrote: we need to promote the easy entry points to contributing to debian more prominently and should hide the how to become a DD in comparison. we should leave that option for the ones that want to contribute above average. If there is any truth to what Joseph Michael Smidt originally said: 1.)All people psychologically want to feel important and that they are an official part of an organization. I feel there should be an official title for all contributers so they feel like they are part of the community, not just a pion until they get official developer status. then it might help to reword several pages at debian.org so that they are more inclusive. Rename Developers' Corner to Contributors' Corner. Under The People write This is a comprehensive listing of all the Debian _maintainers_ accompanied with a list of packages they maintain, instead of ...developers... (which would also be more accurate since non-DD maintainers are already listed). And so on. Reword with the principle in mind that there are many contributors to Debian who are not Debian Developers®. -- Thomas Hood
Re: Bug#344417: ITP: freebsd6-buildutils -- Utilities for building FreeBSD 6.x sources
On Tue, Jan 03, 2006 at 12:42:22PM +0100, Josselin Mouette wrote: Le jeudi 22 d?cembre 2005 ? 16:51 +0100, Robert Millan a ?crit : This package contains the FreeBSD 6.x counterparts of some standard build utilities (make, yacc, lex ..) . They have some specific modifications needed to be able to build FreeBSD 6.x sources. Maybe it's a dumb question, but isn't there a way to patch these tools and/or the freebsd sources so that we can build them with the standard tools in Debian? Yes but: - In big packages (like kFreeBSD), it's a huge work. - Upstream is extremely unlikely to accept patches for that. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Andreas! On 1/3/06, Andreas Schuldei [EMAIL PROTECTED] wrote: * Thomas Hood [EMAIL PROTECTED] [2006-01-03 12:24:29]: They are right: most probably they will find it easier to make contributions to other projects. we need to promote the easy entry points to contributing to debian more prominently and should hide the how to become a DD in comparison. we should leave that option for the ones that want to contribute above average. Hm, perhaps something like Corey Burger's HelpingUbuntu wikipage?[1] I for one would like to see a HelpingDebian page where we could outline these various points of entry... ... then again, I just noticed DebianContributerProject.[2] Not that I'm a killjoy, but that ought to be Contributor, not Contributer[3] ;) [1] https://wiki.ubuntu.com/HelpingUbuntu [2] http://wiki.debian.org/DebianContributerProject [3] http://www.dict.org/bin/Dict?Form=Dict2Database=gcideQuery=Contribute - -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDuo3XV4ex/fpThR0RAuTiAKCHKyeg2VcI7N2l4XRc6OulLEvJ7wCeJyS3 nQChCGkW8u3Xj0b7a025CME= =osFm -END PGP SIGNATURE-
Re: Experiment: poll on switching to vim-tiny for standard vi?
On 03-Jan-06, 00:46 (CST), Steve Langasek [EMAIL PROTECTED] wrote: On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote: If you agree with the change, do Stefano and I need to do anything other than swap vi alternative priorities and swap important-optional priorities? Why swap the vi alternative priorities? Because if vim is the default, and someone deliberately installs nvi, the presumption is that they prefer nvi, and thus it should grab the vi link. Such behaviour is pretty much standard alternative handling: the default install is the lowest priority, and the optional variants have higher priorities. For a single user system, this makes sense. For a multi-user system, where the admin might want all of (vim, nvi, vile, whatever) as options for the user, it's easy to pick whichever one you want for the default. SteveG -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
Hello, However due to the QT library transition my package which I fixed in unstable at once has not entered testing yet... packagesearch | 2.0.4 | testing | source, alpha, ... packagesearch | 2.0.4 | unstable | source, alpha, ... You are right, the QT library transition is compeleted now. I can't see any mention of xterm in packagesearch's changelog, nor any bugs filed about the problem, either. Look at changelog.gz, probably I should have copied it to changelog.Debian.gz too. Bugs were not filed against this problem. And to be honest it might _not_ have occured in testing. I've never checked when xterm changed in its behaviour, and if this xterm version made the transition before the new version of packagesearch. Also note that it was only one feature of packagesearch which broke (after all packagesearch does only recommend xterm and works without it). But my point was that such (unforseeable) things might break things in testing. But I have taken the point of the replies. Second hand experience is nothing I will base my judgement on (and make it public) any more. So please disregard my statement against testing Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: not getting CCs from the bugs I reported
On Tue, Jan 03, 2006 at 12:58:25PM +0100, Josselin Mouette wrote: Le mercredi 28 d?cembre 2005 ? 23:49 -0600, Adam Heath a ?crit : You'll only get mails if the sender sends to ###-submitter. Mail sent to just ### is not forwarded, and only stored. This is not a bug in the software, but in the person sending the mail. I consider this a bug in the software. It's awkward not to receive some communications on a bug you submitted. I sometimes consider it useful. For instance, when someone has submitted a patch to the bug, and I am discussing the patch with this individual, and not the original submitter of the bug report. -- gram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: not getting CCs from the bugs I reported
On Thu, 29 Dec 2005, Thijs Kinkhorst wrote: On Wed, 2005-12-28 at 23:49 -0600, Adam Heath wrote: You'll only get mails if the sender sends to ###-submitter. Mail sent to just ### is not forwarded, and only stored. This is not a bug in the software, but in the person sending the mail. I'd consider this a bug in the software, the principle of least surprise would suggest that one gets copied on updates to bugs one submits. I've seen this on every BTS I've encountered and it makes sense to do so. Of course it should be easy to unsubscribe. See #37078 et al. Don Armstrong -- In all matters of government, the correct answer is usually: Do nothing -- Robert Heinlein _Time Enough For Love_ p428 http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: not getting CCs from the bugs I reported
On Tue, Jan 03, 2006 at 09:30:44AM -0600, Graham Wilson wrote: On Tue, Jan 03, 2006 at 12:58:25PM +0100, Josselin Mouette wrote: Le mercredi 28 d?cembre 2005 ? 23:49 -0600, Adam Heath a ?crit : You'll only get mails if the sender sends to ###-submitter. Mail sent to just ### is not forwarded, and only stored. This is not a bug in the software, but in the person sending the mail. I consider this a bug in the software. It's awkward not to receive some communications on a bug you submitted. I sometimes consider it useful. For instance, when someone has submitted a patch to the bug, and I am discussing the patch with this individual, and not the original submitter of the bug report. AIUI, that's where [EMAIL PROTECTED] comes in handy. You could send the email to the bug via that alias and then CC the person you're discussing the patch with. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] pgpkbE3C7W7hx.pgp Description: PGP signature
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
Thanks for your answer, and information you provided. At the begining I have to make a correction. My happiness last for a day or two, after that the problems with gnome, web-browsers, totem came back (maybe after reboot ? I don't know yet..). I found some more verbose error message from totem saying something about dbus and network connection error. I experience similiar problems with pure testing (fresh install, withoud mixing packages) and mixed testing+unstable and experimental gnome. I didn't try pure unstable release yet. The unstable debian distribution name I think could be wrongly interpreted. ..the first stage of public testing.. sounds a little better, maybe it could be a good system for me ? Nobody want's to have something unstable installed. Ubuntu sounds good - there is no negative meaning, it could convince people to use it although it contains almost the same software as debian unstable, as you said. But in fact, isn't it true that ubuntu success (1st place according to distrowatch.com) is also success of debian ? But does debian development proft from that ? Maybe it could do something similiar as ubuntu - release system for desktop users with quite up-to-date software allowing wider testing or take something back from testing ubuntu results ? These are just some ideas, I don't say these are recipes for success. I think debian should notice ubuntu success and could infer to improve it's development. It could make conditions to get more pepole use it and like it (and maybe even love it). Best regards Radek
Re: not getting CCs from the bugs I reported
Scripsit Josselin Mouette [EMAIL PROTECTED] Le mercredi 28 décembre 2005 à 23:49 -0600, Adam Heath a écrit : You'll only get mails if the sender sends to ###-submitter. Mail sent to just ### is not forwarded, and only stored. This is not a bug in the software, but in the person sending the mail. I consider this a bug in the software. It's awkward not to receive some communications on a bug you submitted. I think the theory is that a non-technical user who reports a bug might not be interested in reading a lot of mail where scary geeks throw incomprehensible jargon at each other while they figure out how to fix the problem. On the other hand, I do not think that most of the bugs in our BTS are reported by non-technical users. -- Henning Makholm This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
Debian people are well aware of Ubuntu and their way of doing things. No need to point it out. As for your problem, please post to debian-user or other more apropriate mailing list and describe it as precisely as you can. Debian-devel is for internal development of Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: something strange with rsh/ssh + bash/tcsh is happening. Please advise
Scripsit Yaroslav Halchenko [EMAIL PROTECTED] -c string If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0. so - sldkjf (if I read English correctly) should be assigned to $0 (yikes again). Lets try: cat zzz.sh #!/bin/bash echo #0=$0 #1=$1 * /bin/bash -c /home/yoh/zzz.sh sldkjf sdf sdf #0=/home/yoh/zzz.sh #1= so what the hell is right in this situation Bash behaves as the manual page says. The string is '/home/yoh/zzz.sh', and every $1 in that string did indeed get expanded to sdf, after which the command reads '/home/yoh/zzz.sh'. On the other hand: $ bash -c 'echo 0=$0 1=$1' sldkjf sdf sdf 0=sldkjf 1=sdf $ bash -c 'source zzz.sh' sldkjf sdf sdf #0=sldkjf #1=sdf $ The argument to the -c option is being interpreted as _a shell script_ itself. -- Henning Makholm It will be useful even at this early stage to review briefly the main features of the universe as they are known today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
Le jeudi 29 décembre 2005 à 21:25 -0600, Adam Heath a écrit : You edit or add to the udev rules. These are usually used to set policy for whole categories of devices, but you can of course fine tune it, or replace all the standard rules with your own. The default gives you all the standard names, as with a static /dev. (I personally switched it to the devfs-style rules.) That's the wrong answer. What ever happened to standard unix tools? chmod/mkdir/chown/mv? Can you give us a way to change permissions of a device that can be plugged or unplugged? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Bug#345828: ITP: libclass-meta-perl -- Class automation, introspection, and data validation
Package: wnpp Severity: wishlist Owner: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] * Package name: libclass-meta-perl Version : 0.52 Upstream Author : David Wheeler [EMAIL PROTECTED] * URL : http://search.cpan.org/~dwheeler/Class-Meta-0.52/ * License : Perl: Artistic/GPL Description : Class automation, introspection, and data validation Class::Meta provides an interface for automating the creation of Perl classes with attribute data type validation. It differs from other such modules in that it includes an introspection API that can be used as a unified interface for all Class::Meta-generated classes. In this sense, it is an implementation of the Facade design pattern. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit : Something troubles me. You make unofficial packages while waiting for official packages. Aren't you DD ? Wouldn't uploading these unofficial packages in unstable make them official ? I don't think we need more packages maintained by Christian Marillat. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
RFA: simulavr: Atmel AVR simulator
Package: wnpp Severity: normal I no longer use this package myself. It would be better off with a maintainer who does use it. Cheers, Shaun simulavr: Atmel AVR simulator simulavr simulates the Atmel AVR family of micro-controllers, emulates a gdb remote target, and displays register and memory information in real time.
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
ti, 2006-01-03 kello 21:06 +0100, Josselin Mouette kirjoitti: Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit : Something troubles me. You make unofficial packages while waiting for official packages. Aren't you DD ? Wouldn't uploading these unofficial packages in unstable make them official ? I don't think we need more packages maintained by Christian Marillat. We could do with fewer character assassinations, too. -- Pity the sysadmin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. So, I'd say it's better to give some time to be sure that the kernel that is shipping with Debian's stable distribution is really a stable kernel, and not a crappy one. I don't think you can tell the difference before this version of the kernel reaches a big number of people, and therefore, it does need time (frozen, in testing). However, if while preparing the release, the frozen kernel would show up as being a crappy one, the release managers might allow for a new kernel to enter testing. But this is only a hypothetical case, and I expect it would be carefully evaluated before it actually happened. -- Besos, Marga
Re: bits from the release team
Hi, thanks for your mail. I just want to point out that we published the timeline already back in October, but of course, that shouldn't refrain us from changing it if this is necessary. :) [re-arranged the quote] * Sven Luther ([EMAIL PROTECTED]) [060103 22:03]: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. Hm, I'm quite sure we had some good reason for this; however, I cannot really remember why we put the kernel to the essential tool chain. On the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough last-minutes changes to the installer that we cannot avoid to better not change the kernel; if the installer team (i.e. Joey Hess or Frans Pop) tell us otherwise, we can of course adjust our plannings. However, there will be a minimum periode where we just need to freeze everything to get enough testing to the proposed release. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Well, we as release team first believe what is told us by the relevant maintainers. Our current status is that kernel upgrades late in the release process (especially after the d-i RC) are rather painfull. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. The first kernel after 2.6.8 that was a real improvement was 2.6.12 and that was released definitely too late for Sarge. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. This is an extremely bad way to get friendly cooperation and discussion about changing anything. Producing new udebs for all architectures for d-i can be done quite fast, as evidenced by the recent uploads for 2.6.14, provided the porters taking care of the udebs for their architecture . I expect little problems or delay for 2.6.15. As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for i386. Yes, we did wait a while before updating to 2.6.14, but that was mainly because d-i itself first had to prepare its userland for the removal of devfs. So please, get off your hobbyhorse and stop pissing people off with unfounded statements. pgpQBmyWehbrh.pgp Description: PGP signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. the kernel is an essential piece of our release, makes sense to have it in tune with everchanging userspace interfaces (alsa, udev to name a few). N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. we had the chance for sarge, but we weren't ready. for etch we will work for our best to be ready. please don't rush out such mails without consensual position. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Sven Luther [EMAIL PROTECTED] wrote: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. Friendly, Sven Luther -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Sven Luther [EMAIL PROTECTED] wrote: (sorry for the previous empty posting) Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. I wonder how that's going to happen wrt udev and a couple of other things that, as of today, depend on a precise version of the kernel. It might not be that easy to upgrade the kernel during the freeze, unfortunately. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote: Hi, thanks for your mail. I just want to point out that we published the timeline already back in October, but of course, that shouldn't refrain us from changing it if this is necessary. :) Yeah, i was already chidded (?) that my mail was too inflamatory, this was not the intention, altough i wrote it such to get some reaction upto a point :) [re-arranged the quote] * Sven Luther ([EMAIL PROTECTED]) [060103 22:03]: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. Hm, I'm quite sure we had some good reason for this; however, I cannot really remember why we put the kernel to the essential tool chain. On :) the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. i think comparing the kernel with the toolchain is overkill, if nothing else a last minute change in the toolchain will need a kernel recompile anyway maybe. I do confess that i read June 30 at first, and this seemed much less acceptable to me. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough What experience ? There is no way of common measure between todays situation and what happened in the pre-sarge timeframe, and we (i, but some of the kernel team at least agreed with that) fully expect to get things working out nicely well before the release date, so that there would be a much reduced impact from the kernel upload on the d-i build schedule. Remember i proposed the common infrastructure already in marsh/april last year, but was voted done for the sarge release on it (with some no-kind words even). The main issue will be one of testing the kernel and d-i built with it, but there should be no technical hurdles which would cause month-long delays. last-minutes changes to the installer that we cannot avoid to better not change the kernel; if the installer team (i.e. Joey Hess or Frans Pop) tell us otherwise, we can of course adjust our plannings. However, there will be a minimum periode where we just need to freeze everything to get enough testing to the proposed release. Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. Hehe, me runs sid kernels installed almost as is on all my sarge systems indeed, just with rebuild yaird and mininmally backported udev. But still, it is an image issue, and i believe the kernel team would be more happy if the obsolet the day it comes out stigma debian has had in the past doesn't touch us. Also, you will pay in maintenance cost for those few month difference during all the etch livetime, guess who will be ending doing this work ? So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Well, we as release team first believe what is told us by the relevant maintainers. Our current status is that kernel upgrades late in the release process (especially after the d-i RC) are rather painfull. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) d-i is only a part of the problem anyway, and i believe the less problematic. out-of-tree modules and third-party patches are a worse mess. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:32:12PM +0100, Maximilian Attems wrote: On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. the kernel is an essential piece of our release, makes sense to have it in tune with everchanging userspace interfaces (alsa, udev to name a few). Indeed, that is why it is part of base, but putting it in comparison with the toolchain (glibc, gcc, etc) is overkill. N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. we had the chance for sarge, but we weren't ready. Due in big part to the messed up kernel situation we inherited from in sarge, remember i proposed delaying sarge to get the unified kernel infrastructure :) for etch we will work for our best to be ready. indeed. please don't rush out such mails without consensual position. like bow and smile and wait forever ? This is not i believe the debian way of handling things, and i am certainly not the only one taking this kind of approach, and much more involved and whatever DDs than me have done it like that, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Maintaining a debian package
Hi there! I'm currently developing an application for library management (real books, CDs, etc). I'd like to distribute it over the internet, because I think it could be useful to other users. As I'm using debian and like it pretty much, I'd like to add it to the list of packages that debian oficially provides. The first problem is, that I don't know how to create debian-packages. I even have a lot of problems when creating a distribution with automake and autoconf. Well, I'm going to learn it (at least, I hope so :)). I'd like to know more about the process of how packages are added to the official debian package list. Thanks in advance, Andi Drebes P.S.: Sorry for my bad english - it's not my native language... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote: (forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. Well, i remember joeyh vetoing it because it would take at least a month to get the change done, and i believe we didn't really push for it because the infrastructure was a mess back then. This has changed. The one point that put me up, is that we should have gotten that security update in, but this was also vetoed for the same month-long delay in the kernel/d-i upgrade process. The kernel team has reduced that delay to less than 24hours now for the release arches, but there is still work to be done on the d-i side of it, and more specifically with the module .udebs, which could be uploaded quickly, but rely on the porters doing very unfriendly drudge work. My believe is that this kind of thing should be as much automated as possible, to let the few ressource we have be used where best it should, a little work at the start which will pay off forever after, this is what computers and programming is for, to make the task of the users and programmers easier, i think we all agree with that, or we would still be using boot-floppies :) The first kernel after 2.6.8 that was a real improvement was 2.6.12 and that was released definitely too late for Sarge. Agreed, the issue is the common infrastrucure, and the cost the previous situation has, and the repercusion of this cost on stable-security. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. This is an extremely bad way to get friendly cooperation and discussion about changing anything. :) Well, we could have released 2.6.15 with .udeb modules included, which would have been less friendly even. Producing new udebs for all architectures for d-i can be done quite fast, It could, joeyh even told me it could be easily automated, and Kamion mentioned me he is already doing part of what is needed for that automation (namely building module .udebs without installing the kernel images), but upto now it is still a pain, and takes over a week or two to get done, this was the case for both 2.6.12, and 2.6.14, and why is that ? Because the porters are slackers is not really the right reply to this. as evidenced by the recent uploads for 2.6.14, provided the porters taking care of the udebs for their architecture . I expect little problems or delay for 2.6.15. Indeed, and this is the crux of the problem, you put all the responsability on the porters, while there is really no porter work needed at all. it is only the nature of the non-unified package that the mainstream arch gets build quickly, and the non-mainstream arches get bit-rotten until there is an urgency and the porters get kicked. This is the process problem we are facing, and i think we can solve in a way satisfactory to the d-i team. My plan is to come up with something for the 2.6.16 timeframe, which you can then review, and if it works out well, be used shortly afterward. Etch should release with 2.6.18 i believe, with the current timeframe, so we have two versions afterward to sort things out. As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for i386. And exactly this is the bug, and not the feature, it did happen quite fast for i386, but nobody cared about the other arches, like before the i386 kernel came out quite fast, but other arches came out with a more or less longer delay. Compare with same day upload on 9 of the 12 main debian arches ? Yes, we did wait a while before updating to 2.6.14, but that was mainly because d-i itself first had to prepare its userland for the removal of devfs. The 2.6.12 to 2.6.14 upgrade was indeed very very painful because of the devfs removal and thus initrd-tools replacement, i am well placed to know about that. So please, get off your hobbyhorse and stop pissing people off with unfounded statements. He, so, there is no problem, and the situation is perfect, and you prefer to hide and shoot the messenger :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:26:02PM -0300, Margarita Manterola wrote: On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. Indeed, but that would be something the kernel team is best placed to decide, and if a given unstable kernel is crappy, we won't allow it in testing, its that simple. So, I'd say it's better to give some time to be sure that the kernel that is shipping with Debian's stable distribution is really a stable kernel, and not a crappy one. I don't think you can tell the difference before this version of the kernel reaches a big number of people, and therefore, it does need time (frozen, in testing). Indeed, unstable is such a place, but is 4 month too much of a time to find out, and would a month or two be enough, i do believe this. However, if while preparing the release, the frozen kernel would show up as being a crappy one, the release managers might allow for a new kernel to enter testing. But this is only a hypothetical case, and I expect it would be carefully evaluated before it actually happened. The crappy kernel would never enter testing in the first place, as testing has always been done on unstable. See 2.6.14 is out for over 2 month now, and it didn't reach testing, and never will now that 2.6.15 is out, because the devfs/initrd-tool situation, and this was the right thing to do. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tuesday 03 January 2006 23:01, Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) Bullshit. We (d-i team, mainly Joey) gave very good reasons why we thought the proposal was not good and would result in more problems than it solved. That you choose to structurally ignore the opinions, comments and objections by others who are a lot more knowledgeable about the _other_ area in Debian impacted by the proposal is typical. Your half-baked proposals may look good from a kernel maintenance viewpoint, but in our opinion they have a negative impact on the d-i side of the equation. Rejecting a badly thought out proposal is _not_ the same as saying no outright. I'm not going to repeat the arguments here. They can be found in the archives. Your attitude does nothing to motivate me to work on this. pgp6Ql7CIlWlU.pgp Description: PGP signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:45:16PM +0100, Frans Pop wrote: 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). The real question (IMHO) is probably whether it would be possible to get newer kernels into volatile. I'd guess probably not, given that stuff like udev tends to break every other release, but it's a tempting thought -- the sarge machine here seems to run miles better with a 2.6.14 backport (yay for backports.org) than it ever did with 2.6.8 (which seems to have a really really unstable USB layer). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:33:44PM +0100, Frans Pop wrote: On Tuesday 03 January 2006 23:01, Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) Bullshit. We (d-i team, mainly Joey) gave very good reasons why we thought the proposal was not good and would result in more problems than it solved. You did indeed give good reasons why having the one .udeb per module plan i follhardly proposed would not work. The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. I believe that this is indeed an argument, but which is outweighted by the benefit especially on the port situation, i believe, and the reason i come back with this times after time :) That you choose to structurally ignore the opinions, comments and objections by others who are a lot more knowledgeable about the _other_ area in Debian impacted by the proposal is typical. Yeah, i am an idiot and you know best, especially when you fail to clearly understand what i propose and chose to reject it on the basis of what you think i propose, this is probably due in part to some lacking in my communication skills, but i guess you also don't make things easy. Your half-baked proposals may look good from a kernel maintenance viewpoint, but in our opinion they have a negative impact on the d-i side of the equation. And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Don't look only to save a few hours of work during the moment, in order to lose huge amounts of times (and irremediable lose of face even) later on. Rejecting a badly thought out proposal is _not_ the same as saying no outright. Yeah, but you have kept saying to me : it is a stupid idea, don't even think about it, and then you speak about badly thought out proposal ? I'm not going to repeat the arguments here. They can be found in the archives. Indeed, apart from the fact that they are the arguments against the wrong proposal :) Your attitude does nothing to motivate me to work on this. Yep, but i don't ask you to work on this, while you ask me to not work on it and keep the status quo, which is broken. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Cite message-ids or irc logs please. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Understanding how the above paragraph could be perceived as insulting is left as an exersise for the reader. -- see shy jo signature.asc Description: Digital signature
Re: bits from the release team
* Steinar H. Gunderson [Tue, 03 Jan 2006 23:34:26 +0100]: On Tue, Jan 03, 2006 at 10:45:16PM +0100, Frans Pop wrote: 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). The real question (IMHO) is probably whether it would be possible to get newer kernels into volatile. I'd guess probably not, given that stuff like udev tends to break every other release, but it's a tempting thought -- the sarge machine here seems to run miles better with a 2.6.14 backport (yay for backports.org) than it ever did with 2.6.8 (which seems to have a really really unstable USB layer). There was a bit discussion about this on d-volatile last week (starting at [1]). I think a fair summary of the discussion is: - from the volatile side of things, Andreas Barth expressed that it was probably best to pick one = 2.6.12 version, stick to it as the newer kernel for sarge until etch releases, and manage to get security support for it. - from the kernel side of things, Sven Luther raised his concerns about the uninteresting scenario that for the kernel team would be to maintain yet _another_ kernel tree, and proposed to track in volatile the kernels from etch, instead of creating a separate tree for stable-newer-kernel. [1] http://lists.debian.org/debian-volatile/2005/12/msg00025.html Given that backports.org seems to successfully track kernels on sid already (as per Steinar's comment), and given that I've heard Frans Pop mention the possibility of a sarge d-i update using 2.6.12, perhaps volatile could be the place for security updates for the kernel of such d-i update (if one happens, and if they canl't be place if the official archive, that is). Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Javier Álvarez - ¡Ay, Maricruz! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Sven Luther wrote: And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Pedantically speaking, fjp made no d-i release decisions last April. If you would like to blame this pendant, you'll need to be a bit more specific. -- see shy jo signature.asc Description: Digital signature
Re: bits from the release team
On Tuesday 03 January 2006 23:52, Sven Luther wrote: The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. So, when can we expect a coherent, full proposal (with overview of benefits, possible pitfalls, things that need to be worked out further, and so on) on this in a dedicated mail on a new thread to the relevant mailing lists, so we can actually comment on it instead of only seeing a rough outline mentioned every so often as part of a flame? (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. You forget the argument that when kernel udebs are maintained within d-i, we will be much more likely to spot changes in them as a possible cause of breakage when installation-reports come in. pgpRRzbMYjt34.pgp Description: PGP signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:09:18PM -0500, Joey Hess wrote: Sven Luther wrote: And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Pedantically speaking, fjp made no d-i release decisions last April. Nope, you did, and the Your above was meant to be the d-i team. I also remember you accusing of single-handledly delaying the sarge release by a week, which was not welcome after i invested almost a week fighthing with k-p to get the 2.4 ppc kernels in a decent shape for sarge, especially as i didn't really believe into 2.4 powerpc kernels at that time. Would i have told you at the start of that week what i would have tried to do, can you honestly you would have let me do it ? But anyway, let's agree to disagree or whatever, and stop hurting each other, there will be a proposal made in the 2.6.16 timeframe, and we can then speak again about this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:13:37AM +0100, Frans Pop wrote: On Tuesday 03 January 2006 23:52, Sven Luther wrote: The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. So, when can we expect a coherent, full proposal (with overview of benefits, possible pitfalls, things that need to be worked out further, and so on) on this in a dedicated mail on a new thread to the relevant mailing lists, so we can actually comment on it instead of only seeing a rough outline mentioned every so often as part of a flame? The linux-2.6 package will propose a solution which will produce the *EXACT SAME* set of .udebs as with the current kernel-wedge solution, and will be more easy to maintain in a more automated way, and integrated with the rest of the linux-2.6 kernel, so porters only need to do the work once in a single integrated way. (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) This is not my past experience though, and the current method sucks, this is a fact, i as powerpc porter of d-i have to live with, so why should i not be allowed to express my opinion about this ? The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. You forget the argument that when kernel udebs are maintained within d-i, we will be much more likely to spot changes in them as a possible cause of breakage when installation-reports come in. well, if the only thing you are afraid about is documentation, we shall provide you with this information in a way most suitable. All this can and and will be easily automated and presented upon you on a platter, which is not the case with the current kernel-wedge situation, where the i386 .udebs and kernel-wedge are updated and the rest of the ports left out in the cold without any kind of info about possible breakage already fixed on i386, thanks you very much, so two weights two measures, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:04:39PM -0500, Joey Hess wrote: Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Cite message-ids or irc logs please. Such hiding in the sand, ... well i don't keep irc logs, and you can go searching for those past email posts as well as i can. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Understanding how the above paragraph could be perceived as insulting is left as an exersise for the reader. Yeah, and i have mails from you which where degrees of magnitude more insulting than those, and i have still not forgiven you about the way you hurt me in april. So tone done your arrogance a bit, please. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, 3 Jan 2006, Margarita Manterola wrote: On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Jan 03, Julien BLACHE [EMAIL PROTECTED] wrote: I wonder how that's going to happen wrt udev and a couple of other things that, as of today, depend on a precise version of the kernel. udev only depends on a recent enough version of the kernel (probably 2.6.15 by the time etch will be frozen) and the upstream maintainers promised that (modulo bugs) versions = 072 will be forward-compatible with new kernel releases. Anyway, I agree that we should aim to release something better than a six months old kernel (which sarge showed is often too old). -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
Josselin Mouette [EMAIL PROTECTED] writes: Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit : Something troubles me. You make unofficial packages while waiting for official packages. Aren't you DD ? Wouldn't uploading these unofficial packages in unstable make them official ? I don't think we need more packages maintained by Christian Marillat. Same apply for you... Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
Josselin Mouette [EMAIL PROTECTED] writes: Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit : Something troubles me. You make unofficial packages while waiting for official packages. Aren't you DD ? Wouldn't uploading these unofficial packages in unstable make them official ? I don't think we need more packages maintained by Christian Marillat. Moron are still here in 2006. Happy new year... christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? (Other than telling people just use Ubuntu, which is what I do.) -- ciao, Marco signature.asc Description: Digital signature
Re: bits from the release team
On Wednesday 04 January 2006 00:17, Adeodato Simó wrote: Given that backports.org seems to successfully track kernels on sid already (as per Steinar's comment), and given that I've heard Frans Pop mention the possibility of a sarge d-i update using 2.6.12, Hmm. That needs a bit of context. The only way in which the d-i team has so far considered an update of d-i for Sarge is if a newer kernel version is officially supported for Sarge. For us this would be easiest if the new version would be included in a point release, but I personally doubt such a proposal would ever pass the Stable release manager. We could also look into this if a new kernel were made part of volatile, although that would mean d-i would have to be extended in some places to be able to support that. Still, first requirement is selection of a kernel that will be supported. Downside of anything more recent than 2.6.12 is that a lot of structural changes in d-i would need to be backported to deal with the removal of devfs and to support the new initrd generators. pgp2ItpXdtkUs.pgp Description: PGP signature
Re: bits from the release team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Jan 2006 00:24:04 +0100 Sven Luther [EMAIL PROTECTED] wrote: (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) This is not my past experience though, and the current method sucks, this is a fact, i as powerpc porter of d-i have to live with, so why should i not be allowed to express my opinion about this ? Because your ignorance of being rude will hurt the conversation - even if your arguments are sane. Go ahead and claim that I have no right to say so due to my having a record of being rude myself. Such reaction would only prove my point here. - Jonas P.S. Please do *not* cc me as I am subscribed to d-kernel! - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuwm8n7DbMsAkQLgRAklqAJ9Tz82+Gw7DjDid2F2cncgsjh2kswCfcZYn J8jSPC7UpM3ut3Oo/5BXkK4= =seHD -END PGP SIGNATURE-
Re: bits from the release team
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 05:28:15PM -0600, Adam Heath wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. Notice that Linus recently expressed on LKML that udev and other userland breakage on kernel upgrade is not to acceptable, so this would be a bug to be fixed. But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev and it works. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? Why doesn't debian really collaborate with ubuntu on the kernels, which would be more natural. Debian use mostly the mainline upstream kernels, which is where everything goes back in anyway, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
This one time, at band camp, Josselin Mouette said: Le jeudi 29 décembre 2005 à 21:25 -0600, Adam Heath a écrit : You edit or add to the udev rules. These are usually used to set policy for whole categories of devices, but you can of course fine tune it, or replace all the standard rules with your own. The default gives you all the standard names, as with a static /dev. (I personally switched it to the devfs-style rules.) That's the wrong answer. What ever happened to standard unix tools? chmod/mkdir/chown/mv? Can you give us a way to change permissions of a device that can be plugged or unplugged? Of course. With a static /dev/, the node is always there to be operated on whether or not there is hardware associated with the device node. You can chmod it whether there is a device plugged in or not. udev largely solves the problem of 'my /dev tree is ugly with all those extra things in it'. Until it also solves all of the problems it brings with it, and provides an upgrade path better than 'upgrade the kernel first', I have to remain unconvinced. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:10:49AM +0100, Sven Luther wrote: But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev and it works. AFAIK it should work with the default ruleset. It breaks only with certain custom rules due to a bug in the libsysfs version used by udev. So, if you did not create any udev rules yourself you should be fine. With old udev and new kernel my rules that map my USB disks to persistent names under /dev were definitely broken. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Tue, Jan 03, 2006 at 08:58:49AM -0600, Steve Greenland wrote: On 03-Jan-06, 00:46 (CST), Steve Langasek [EMAIL PROTECTED] wrote: On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote: If you agree with the change, do Stefano and I need to do anything other than swap vi alternative priorities and swap important-optional priorities? Why swap the vi alternative priorities? Because if vim is the default, and someone deliberately installs nvi, the presumption is that they prefer nvi, and thus it should grab the vi link. I think that's a pretty bad presumption; to me, it indicates that *someone* on the system prefers nvi and has requested its installation, but this doesn't mean it's the preference of either the system administrator or of the majority of the users. Such behaviour is pretty much standard alternative handling: the default install is the lowest priority, and the optional variants have higher priorities. For a single user system, this makes sense. For a multi-user system, where the admin might want all of (vim, nvi, vile, whatever) as options for the user, it's easy to pick whichever one you want for the default. OTOH, the admin may not understand the alternatives system, or recognize its relevance at the time of installing the package (worst case, some other package pulls it in automatically), which makes for an inconsistent user experience. I think the single-user system is the last one that alternatives handling should optimize for, since the *one* person who's going to know to type nvi instead of vi, and the one person who can fix the alternatives if he doesn't like them, is the admin... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Maintaining a debian package
On Tue, Jan 03, 2006 at 10:59:12PM +0100, Andi Drebes wrote: Hi there! I'm currently developing an application for library management (real books, CDs, etc). I'd like to distribute it over the internet, because I think it could be useful to other users. As I'm using debian and like it pretty much, I'd like to add it to the list of packages that debian oficially provides. The first problem is, that I don't know how to create debian-packages. I even have a lot of problems when creating a distribution with automake and autoconf. Well, I'm going to learn it (at least, I hope so :)). I'd like to know more about the process of how packages are added to the official debian package list. Thanks in advance, Andi Drebes P.S.: Sorry for my bad english - it's not my native language... Hi Andi, you may notice that Debian has many programs to catalog thing. Some for cd/dvd's, some for books, etc. When you make an ITP you will need to make an argument as to why this packages should be added. Debian developers will want to know what differentiates your package from other similar ones in Debian already. This is not to say that you will be unable to add your package to debian, but on rare occasions it has been decided that some packages would not benefit being added. An ITP also know as an intent to package is a request that is sent to the Debian BTS (bug tracking system) to announce a request to add a package to Debian. Your next step should be to get familar with Debian by visiting the debian mentor website and join the debian-mentors mailing list. There you will be helped to develop your package so that it can be made into a '.deb' aka debian package. Once you do this, you will need someone to sponsor your package. This will allow someone who is a debian developer to look at your work and if ok, will upload it into Debian. You IIRC can request a sponsor here. Cheers, Kev ps. If you want some beta tester for your work, you should include a URL so that folks like me can try your work, assuming you feel it is in a shape to be tested. -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: bits from the release team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2006 10:13 PM, Sven Luther wrote: On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? Why doesn't debian really collaborate with ubuntu on the kernels, which would be more natural. Debian use mostly the mainline upstream kernels, which is where everything goes back in anyway, so ... Just my two cents... :) Sometime ago, Adrian Bunk [1]raise the question about a kernel stable tree in LKML, after a lot of discussion (and AFAIK no good resolution), a lot of ideas travel on the list (also in the midle of flamewar), ideas like try to not break the entire userland and let the distro take care of having a stable kernel. 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) If you give it a quick look (and a quick try), we will have more users testing the same kernel, which means more feedback, we will have more developers working to get it stable and working to get it secure. Probably even upstream get benefits from this model and sounds like a very good way to work together, even to try to integrate outside patches and backporting things. =) Kind regards, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFDuzGiCjAO0JDlykYRAsYxAKCYl+WPqiEWapKTK3Yee//o6Dn58wCfXPh5 JOZOVATPQIMWPgMnHzDuKrg= =qcxC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
In article [EMAIL PROTECTED] you wrote: I think the single-user system is the last one that alternatives handling should optimize for, since the *one* person who's going to know to type nvi instead of vi, and the one person who can fix the alternatives if he doesn't like them, is the admin... which also means he most likely wants to have the manually installed packet to grab the alternative link. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Remove from call- wave
Please remove me from call-wave. Thanks, corkylinda54 ( Louis E. Grantham )
Re: How to Increase Contributions from Volunteers
On Tue, 3 Jan 2006 12:50:22 +0100, Andreas Schuldei [EMAIL PROTECTED] said: * Thomas Hood [EMAIL PROTECTED] [2006-01-03 12:24:29]: They are right: most probably they will find it easier to make contributions to other projects. we need to promote the easy entry points to contributing to debian more prominently and should hide the how to become a DD in comparison. What on earth for? we should leave that option for the ones that want to contribute above average. We are trying to build the best distribution of linux on the planet, not the so-so ditribution created by the most number of people. Why do you think that an excellent direbution can come by with contribution of people who are, in your own words, below average? manoj -- A man without a woman is like a statue without pigeons. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:27:25PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote: (forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. Well, i remember joeyh vetoing it because it would take at least a month to get the change done, and i believe we didn't really push for it because the infrastructure was a mess back then. This has changed. The one point that put me up, is that we should have gotten that security update in, but this was also vetoed for the same month-long delay in the kernel/d-i upgrade process. The kernel team has reduced that delay to less than 24hours now for the release arches, You have been harranguing the ftp team to approve new upstream kernels through the NEW queue before they've even been uploaded -- for an amazing false optimization that burns good will with your fellow developers. Even if udebs *were* being built from the same linux-2.6 source package, this doesn't address the real reason why it's important to freeze the kernel early: *the kernel is a core component of everyone's system and detecting regressions takes a long time*. Anything that requires a reboot cycle or an installation test in order for users to detect bugs is going to need a longer testing period than other packages; the only way to ensure this happens is by freezing it early, i.e., around the same time as the toolchain packages for which we have the same problem of figuring out whether a new version is better or worse. The underlying assumption in your plea for a shorter kernel freeze is newer is better. But people who accept this assumption unconditionally don't *run* Debian stable; so neither should we base our freeze timeline on an unconditional acceptance of it. Newer isn't necessarily better, but it is necessarily *different*, which is the enemy of stability. There is still room for targetted fixes to the kernel after the freeze date; backports of new drivers, or backports of specific bugfixes, are certainly fair game. Taking a new version of whatever upstream happens to have released would not be. My believe is that this kind of thing should be as much automated as possible, to let the few ressource we have be used where best it should, a little work at the start which will pay off forever after, this is what computers and programming is for, to make the task of the users and programmers easier, i think we all agree with that, or we would still be using boot-floppies :) I'm all in favor of streamlining the integration of new kernel versions into the installer, but I don't believe that the majority of the work involved falls into the automatable category. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) The biggest obstacle to this is that different distributions have different and contradictory requirements for what ships in the kernel. For Debian, the obvious requirement is that everything we ship in main meets the DFSG; this is a requirement that is not shared by Ubuntu, for instance, which means any collaboration on kernels between those two distros has to allow for different bits being stripped out at the time of source package generation. It would certainly be nice to see improvements in kernel collaboration, and I believe it is possible, we just have to be honest with ourselves about the difficulties involved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:34:43PM -0800, Steve Langasek wrote: On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) The biggest obstacle to this is that different distributions have different and contradictory requirements for what ships in the kernel. For Debian, the obvious requirement is that everything we ship in main meets the DFSG; this is a requirement that is not shared by Ubuntu, for instance, which means any collaboration on kernels between those two distros has to allow for different bits being stripped out at the time of source package generation. It would certainly be nice to see improvements in kernel collaboration, and I believe it is possible, we just have to be honest with ourselves about the difficulties involved. Also, notice that cooperation with the ubuntu kernels was more marked when Fabionne was the ubuntu kernel maintainer, but now that he has passed the relay, i feel that it is less. We have proposed to them to use a common infrastrcuture with enabled/disabled patches for both, but the reply was mostly of the kind, yeah we would like to cooperate, and no actions followed. I believe it has also an influence on the place where the source package is ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they said we should use their system. So, altough patches can occasionally be exchanged, i doubt that cooperation will go further for control-and-politics reason, and i believe it is maybe best so for both involved. There can be cooperation without sharing all the infrastructure and packaging. Other less high-profile daughter-distros are probably simply reusing the debian kernel, and this is probably the best way of doing this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hi, ive a new mail address
Thanks for your comments.
Re: bits from the release team
* Sven Luther ([EMAIL PROTECTED]) [060103 23:02]: On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote: the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. i think comparing the kernel with the toolchain is overkill, if nothing else a last minute change in the toolchain will need a kernel recompile anyway maybe. I do confess that i read June 30 at first, and this seemed much less acceptable to me. well, the kernel is definitly about the same level as the toolchain and standard/base - changes can have very easily impact on the installer, and it is not an option to remove the package if it is broken. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough What experience ? I was speaking about the installer. And usually there are lots of last-minute changes that need to go in - not only new languages, but lots of other small minor, but still important bug fixes. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. Hehe, me runs sid kernels installed almost as is on all my sarge systems indeed, just with rebuild yaird and mininmally backported udev. Well, but then an older kernel doesn't hurt you? :P Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Of course, we have seen that the kernel build process is way more mature now. Nobody doubts that. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Well, they are definitly the relevant people for the installer. And, frankly speaking, at least I have good experience with both of them. d-i is only a part of the problem anyway, and i believe the less problematic. out-of-tree modules and third-party patches are a worse mess. Hm, which out-of-tree modules do you consider to be release critical, i.e. we cannot release without them? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted at 3.1.10 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Jan 2006 23:08:51 -0800 Source: at Binary: at Architecture: source i386 Version: 3.1.10 Distribution: unstable Urgency: low Maintainer: Ryan Murray [EMAIL PROTECTED] Changed-By: Ryan Murray [EMAIL PROTECTED] Description: at - Delayed job execution and batch processing Closes: 321141 321325 325253 332417 335307 Changes: at (3.1.10) unstable; urgency=low . * Fix typo in init script (closes: #321141) * Allow at time - number minutes to work (closes: #321325) * Correct cannot find job logic for atrm (closes: #325253) * Rewrite init script using lsb functions (closes: #335307) * Correct help for atrm; -q is not supported (closes: #332417) Files: 91ec852182d9959248ef2ff492093301 503 admin important at_3.1.10.dsc 6e5857e23b3c32ea6995fb7f8989987e 99179 admin important at_3.1.10.tar.gz 8983a16a2e5901506f1431b7c52837f1 41612 admin important at_3.1.10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuiS5N2Dbz/1mRasRAgKqAJ4u/uA/CwHF8H+1Z+WlhgMUki5TVgCgm6UW OYoAcoTimqLdhX3yC3cztjk= =li/2 -END PGP SIGNATURE- Accepted: at_3.1.10.dsc to pool/main/a/at/at_3.1.10.dsc at_3.1.10.tar.gz to pool/main/a/at/at_3.1.10.tar.gz at_3.1.10_i386.deb to pool/main/a/at/at_3.1.10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ser2net 2.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 07:46:13 + Source: ser2net Binary: ser2net Architecture: source i386 Version: 2.3-1 Distribution: unstable Urgency: low Maintainer: Marc Haber [EMAIL PROTECTED] Changed-By: Marc Haber [EMAIL PROTECTED] Description: ser2net- Allows network connections to serial ports Closes: 345247 Changes: ser2net (2.3-1) unstable; urgency=low . * new upstream version. Will now build on GNU/kFfeeBSD. Thanks to Aurelien Jarno. Closes: #345247 * Disable DEB_AUTO_UPDATE_DEBIAN_CONTROL * Re-Generate debian/control, manually fix wrong dependencies * bump debhelper level to 5 * Standards-Version: 3.6.2 (no changes necessary) * Update FSF street address * document new option \s in ser2net.conf, enable in default config. Files: 094da125ea5f1301b3d42984fb871d80 598 utils optional ser2net_2.3-1.dsc 5f83a3e8aec18331cb61069dccdfba47 303997 utils optional ser2net_2.3.orig.tar.gz 63005ac4c8a959584157997e17cb4249 5466 utils optional ser2net_2.3-1.diff.gz 5645719036ba8dcb5c85ba494ce32dc1 36798 utils optional ser2net_2.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuizMgZalRGu6PIQRAuU6AJ93X+pfZ1RwcrieclXXcS0Pi12vGQCgvO7Y N5YbG67KAb+5nGelsC/y8lw= =Yhe/ -END PGP SIGNATURE- Accepted: ser2net_2.3-1.diff.gz to pool/main/s/ser2net/ser2net_2.3-1.diff.gz ser2net_2.3-1.dsc to pool/main/s/ser2net/ser2net_2.3-1.dsc ser2net_2.3-1_i386.deb to pool/main/s/ser2net/ser2net_2.3-1_i386.deb ser2net_2.3.orig.tar.gz to pool/main/s/ser2net/ser2net_2.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mtink 1.0.12-2 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 08:40:58 +0100 Source: mtink Binary: mtink mtink-doc Architecture: source i386 all Version: 1.0.12-2 Distribution: unstable Urgency: low Maintainer: Sylvain Le Gall [EMAIL PROTECTED] Changed-By: Sylvain Le Gall [EMAIL PROTECTED] Description: mtink - Status monitor and configuration tool for Epson inkjet printers mtink-doc - Documentation for mtink Closes: 345538 Changes: mtink (1.0.12-2) unstable; urgency=low . * Stop depending on xlib-dev, depends on libx11-dev, libxpm-dev, libxt-dev. (Closes: #345538) Files: a01f94b2fbfc334966102a9ae3c47d18 770 misc extra mtink_1.0.12-2.dsc 75bc67a195d39e116119a17e48d4bdb8 17470 misc extra mtink_1.0.12-2.diff.gz eb34a943f474b4f4e1e9be8c67eca117 542526 doc extra mtink-doc_1.0.12-2_all.deb 58ccbfdd137fbbd6badbe4bca7c46444 158740 misc extra mtink_1.0.12-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuiyUir2bofsN/psRAnRuAKCJKn6Oa6p9RwIQ1S2W2hn0BxGmOQCfVSwH 8npvtSIPenITmEi0Z8K1vks= =/daK -END PGP SIGNATURE- Accepted: mtink-doc_1.0.12-2_all.deb to pool/main/m/mtink/mtink-doc_1.0.12-2_all.deb mtink_1.0.12-2.diff.gz to pool/main/m/mtink/mtink_1.0.12-2.diff.gz mtink_1.0.12-2.dsc to pool/main/m/mtink/mtink_1.0.12-2.dsc mtink_1.0.12-2_i386.deb to pool/main/m/mtink/mtink_1.0.12-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted aterm 1.0.0-1 (alpha i386 sparc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 07:16:46 +0100 Source: aterm Binary: aterm-ml aterm Architecture: alpha i386 source sparc Version: 1.0.0-1 Distribution: unstable Urgency: low Maintainer: Göran Weinholt [EMAIL PROTECTED] Changed-By: Göran Weinholt [EMAIL PROTECTED] Description: aterm - Afterstep XVT - a VT102 emulator for the X window system aterm-ml - Afterstep XVT - a VT102 emulator for the X window system Closes: 236166 335157 338214 Changes: aterm (1.0.0-1) unstable; urgency=low . * New upstream release (closes: #335157). + Fixes resizing of windows when showing contents is slow (closes: #236166). * Patches included upstream: 01_linuxkeys, 02_fontchange_removal, 03_resize_window_always, 04_shift_insert_outside_window, 06_mouse_wheel_codes, 07_scrollKey_resource, 08_manpage_resource_path, 09_specific_resources_before_global, 11_tt_winsize_fd, 12_child_fd_closed, 13_fix_warnings, 14_background_crash, 15_scrollttyoutput, 16_uninitialized_keysym, 18_untbl_manpage, 19_manpage_section. * Extracted the part of 17_color_sequences that isn't applied upstream yet and made it into 22_eterm_transparency. * Update 10_warn_faulty_boolean and 20_cutToBeginningOfLine. * New patch 24_background_updates: when changing workspaces, only update the background image if it is necessary. * New patch, 25_superflous_linking: don't link against libSM, libICE, libXext. * debian/control: + Update to Standards-Version: 3.6.2 (no changes). + Remove superflous build-dependencies: libice-dev, libsm-dev, libxpm-dev. * New patch, 26_manpage_paths: fix file paths in the FILES section of aterm(1). Thanks to Sean Finney for reporting this (closes: #338214). Files: 03ebef35fa7106ca787ff9c2e4e27774 328094 x11 optional aterm-ml_1.0.0-1_alpha.deb 3072058b803fcef7d0e2a4ebe118e1e1 13074 x11 optional aterm_1.0.0-1.diff.gz 4d7679eab79c2aeaa87f36659a3c6768 101834 x11 optional aterm_1.0.0-1_alpha.deb 568777c65a723f6ba27464473c424a10 288358 x11 optional aterm_1.0.0.orig.tar.gz 72f44c83197e39ab59a3644f0319b497 81506 x11 optional aterm_1.0.0-1_i386.deb ac10cbfcafcc639be39f0579c94a1c88 228110 x11 optional aterm-ml_1.0.0-1_sparc.deb c01d0232f0fa98d6b0885fe3303771b6 84820 x11 optional aterm_1.0.0-1_sparc.deb d88413dd2154d06b1adc9f6932d3cde6 243736 x11 optional aterm-ml_1.0.0-1_i386.deb ea24bb3a86081d29070d82aef9131900 606 x11 optional aterm_1.0.0-1.dsc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDujMrjfWLtkqIVOYRAjAlAKCKGCJXK2zRtmlzcD5agYJWQma64gCfQ6k+ B2Xvtz6ENOSI3oeO1vQerSU= =jhmo -END PGP SIGNATURE- Accepted: aterm-ml_1.0.0-1_alpha.deb to pool/main/a/aterm/aterm-ml_1.0.0-1_alpha.deb aterm-ml_1.0.0-1_i386.deb to pool/main/a/aterm/aterm-ml_1.0.0-1_i386.deb aterm-ml_1.0.0-1_sparc.deb to pool/main/a/aterm/aterm-ml_1.0.0-1_sparc.deb aterm_1.0.0-1.diff.gz to pool/main/a/aterm/aterm_1.0.0-1.diff.gz aterm_1.0.0-1.dsc to pool/main/a/aterm/aterm_1.0.0-1.dsc aterm_1.0.0-1_alpha.deb to pool/main/a/aterm/aterm_1.0.0-1_alpha.deb aterm_1.0.0-1_i386.deb to pool/main/a/aterm/aterm_1.0.0-1_i386.deb aterm_1.0.0-1_sparc.deb to pool/main/a/aterm/aterm_1.0.0-1_sparc.deb aterm_1.0.0.orig.tar.gz to pool/main/a/aterm/aterm_1.0.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sear 0.6.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 09:53:44 + Source: sear Binary: sear Architecture: source i386 Version: 0.6.0-1 Distribution: unstable Urgency: low Maintainer: Michael Koch [EMAIL PROTECTED] Changed-By: Michael Koch [EMAIL PROTECTED] Description: sear - 3D client for the Worldforge game servers Closes: 320877 342191 Changes: sear (0.6.0-1) unstable; urgency=low . * New upstream release (Closes: #320877, #342191). - Removed debian/patches/amd64-fixes.patch. Applied upstream. - Removed debian/patches/usr-games.patch. Fixed upstream. - Removed debian/patches/console-at-startup.patch as there is some GUI now. - Added debian/patches/sear-in.patch to remove usage of WFUT. - Updated Build-Depends, added libguichan0-dev, Depend on right API versions of the different other libs. - Make sear Depend on sear-media = 0.6. * Updated watch file. * Updated Standards-Version to 3.6.2. * Fixed address of FSF in debian/copyright. Files: c8c54958f56557d602f4ab2a2689a0c8 915 games optional sear_0.6.0-1.dsc 04be04c19a03b2928f42ecfb52c8ea51 656807 games optional sear_0.6.0.orig.tar.gz 29d839cf03f6a20360b1ea9af627db7d 4356 games optional sear_0.6.0-1.diff.gz ea0f6c5dd97073f4212c3bc6091e8de7 875206 games optional sear_0.6.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDukw5WSOgCCdjSDsRAmCsAKCdBpaKqelmzXdT1Sj1piJfkgepwQCcC6Xt /UHs+p6cfdGa39zhddBqiiY= =xGtB -END PGP SIGNATURE- Accepted: sear_0.6.0-1.diff.gz to pool/main/s/sear/sear_0.6.0-1.diff.gz sear_0.6.0-1.dsc to pool/main/s/sear/sear_0.6.0-1.dsc sear_0.6.0-1_i386.deb to pool/main/s/sear/sear_0.6.0-1_i386.deb sear_0.6.0.orig.tar.gz to pool/main/s/sear/sear_0.6.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted thunar 0.1.4svn+r18850-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 02 Jan 2006 23:42:32 +0100 Source: thunar Binary: libthunar-vfs-1-dev thunar libthunar-vfs-1 Architecture: source i386 Version: 0.1.4svn+r18850-2 Distribution: unstable Urgency: low Maintainer: Debian Xfce Maintainers [EMAIL PROTECTED] Changed-By: Yves-Alexis Perez [EMAIL PROTECTED] Description: libthunar-vfs-1 - VFS abstraction used in thunar libthunar-vfs-1-dev - Development files for libthunar-vfs thunar - File Manager for Xfce Changes: thunar (0.1.4svn+r18850-2) unstable; urgency=low . * Added a build-dependancy on libxml-parser-perl so thunar builds in pbuilder * Changed the dependancy for libthunar-vfs-1-dev to libthunar-vfs-1 Files: 772ab4ceec6d3d839b5f2f70a1b9f3c7 941 x11 optional thunar_0.1.4svn+r18850-2.dsc f0970f67882088d381acf249ae489bd9 2538 x11 optional thunar_0.1.4svn+r18850-2.diff.gz 4a9aacdb5eb672dbc1c08fd118a89636 173722 x11 optional thunar_0.1.4svn+r18850-2_i386.deb c90630748b792b3df63bc9f3b06818ee 54890 libdevel optional libthunar-vfs-1-dev_0.1.4svn+r18850-2_i386.deb 5f12d53db6ccaa0325d948de99b7d398 117748 libs optional libthunar-vfs-1_0.1.4svn+r18850-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDukgwMQdl+99c4rQRAhEFAJ9/hqGUf1xSflX/bNHqjxAYkTeiigCfbNxk G3e3kKNHJGpfTFK638WIcGI= =qRuh -END PGP SIGNATURE- Accepted: libthunar-vfs-1-dev_0.1.4svn+r18850-2_i386.deb to pool/main/t/thunar/libthunar-vfs-1-dev_0.1.4svn+r18850-2_i386.deb libthunar-vfs-1_0.1.4svn+r18850-2_i386.deb to pool/main/t/thunar/libthunar-vfs-1_0.1.4svn+r18850-2_i386.deb thunar_0.1.4svn+r18850-2.diff.gz to pool/main/t/thunar/thunar_0.1.4svn+r18850-2.diff.gz thunar_0.1.4svn+r18850-2.dsc to pool/main/t/thunar/thunar_0.1.4svn+r18850-2.dsc thunar_0.1.4svn+r18850-2_i386.deb to pool/main/t/thunar/thunar_0.1.4svn+r18850-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted muttprint 0.72d-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 10:51:23 +0100 Source: muttprint Binary: ospics muttprint muttprint-manual Architecture: source all Version: 0.72d-3 Distribution: unstable Urgency: low Maintainer: Rene Engelhard [EMAIL PROTECTED] Changed-By: Rene Engelhard [EMAIL PROTECTED] Description: muttprint - Pretty printing of mails muttprint-manual - Manual for muttprint ospics - Some images of operating system logos/mascots Closes: 342277 Changes: muttprint (0.72d-3) unstable; urgency=low . * readd uncorrupted Debian.png from CVS (closes: #342277) Files: 6da2bde3546d100e5e242f8043ca14cc 651 mail optional muttprint_0.72d-3.dsc fd01a76d827805b55592dddff9f6f09f 215999 mail optional muttprint_0.72d-3.diff.gz 1e4603bde6c60b93cb427f898ef399be 97380 mail optional muttprint_0.72d-3_all.deb e5c5a0914809a5d1f982a34c940acd27 901066 doc optional muttprint-manual_0.72d-3_all.deb 785574b0f3272f32f03879d68b092f93 237878 graphics optional ospics_0.72d-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDukpg+FmQsCSK63MRAs1bAJoC/7bEVaRbOdpwtBjXO8tG94LXxACdG14t vt1PEtEzC5Od8R+j9jt5tSE= =DLqx -END PGP SIGNATURE- Accepted: muttprint-manual_0.72d-3_all.deb to pool/main/m/muttprint/muttprint-manual_0.72d-3_all.deb muttprint_0.72d-3.diff.gz to pool/main/m/muttprint/muttprint_0.72d-3.diff.gz muttprint_0.72d-3.dsc to pool/main/m/muttprint/muttprint_0.72d-3.dsc muttprint_0.72d-3_all.deb to pool/main/m/muttprint/muttprint_0.72d-3_all.deb ospics_0.72d-3_all.deb to pool/main/m/muttprint/ospics_0.72d-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sear-media 0.6-20051129-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 09:22:39 + Source: sear-media Binary: sear-media Architecture: source all Version: 0.6-20051129-1 Distribution: unstable Urgency: low Maintainer: Michael Koch [EMAIL PROTECTED] Changed-By: Michael Koch [EMAIL PROTECTED] Description: sear-media - 3D client for the Worldforge game servers - data files Changes: sear-media (0.6-20051129-1) unstable; urgency=low . * New upstream release. * Updated watch file. * Updated DH_COMPAT version to 4. * Updated Standards-Version to 3.6.2. * Made sear-media Conflict with sear 0.6.0. * Fixed debian/copyright as the data are now GPL only. Files: c4f15ef900d3e10479473115f99fd9c7 600 games optional sear-media_0.6-20051129-1.dsc 7d4cd1a0ea9bdb5abbd170c82bb6a958 29721090 games optional sear-media_0.6-20051129.orig.tar.gz fddc04cfeee1c28fb7c4f3f694bf48ac 1906 games optional sear-media_0.6-20051129-1.diff.gz a57cdc285b856f47de73ca51caf0ca37 29662974 games optional sear-media_0.6-20051129-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDukxKWSOgCCdjSDsRAkLdAJ99a2x0RYgdx2CpR00cJuX9ohP27wCggyVH xls6L5kAp0Jdw6sPIgfbLQw= =ShuQ -END PGP SIGNATURE- Accepted: sear-media_0.6-20051129-1.diff.gz to pool/main/s/sear-media/sear-media_0.6-20051129-1.diff.gz sear-media_0.6-20051129-1.dsc to pool/main/s/sear-media/sear-media_0.6-20051129-1.dsc sear-media_0.6-20051129-1_all.deb to pool/main/s/sear-media/sear-media_0.6-20051129-1_all.deb sear-media_0.6-20051129.orig.tar.gz to pool/main/s/sear-media/sear-media_0.6-20051129.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted optcomplete 1.2-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 10:56:28 +0100 Source: optcomplete Binary: python2.3-optcomplete optcomplete-common python-optcomplete python2.4-optcomplete Architecture: source all Version: 1.2-4 Distribution: unstable Urgency: low Maintainer: Bastian Kleineidam [EMAIL PROTECTED] Changed-By: Bastian Kleineidam [EMAIL PROTECTED] Description: optcomplete-common - common scripts and documentation for python-optcomplete python-optcomplete - provide bash-completion for Python programs (dummy package) python2.3-optcomplete - provide bash-completion for Python programs python2.4-optcomplete - provide bash-completion for Python programs Changes: optcomplete (1.2-4) unstable; urgency=low . * added debian/watch file for uscan Files: 496a1d2c495db4a35254e61e3d730909 646 python optional optcomplete_1.2-4.dsc 5bad5798f184018a3057e01aed93d55a 5024 python optional optcomplete_1.2-4.diff.gz a0c3ab42095b99f2b47de78b6dc22794 3050 python optional python-optcomplete_1.2-4_all.deb 6c9aa46b987830e7d86da48366b609c3 8414 python optional python2.3-optcomplete_1.2-4_all.deb ced13a5a5637e82a07f0b80920a3738e 8418 python optional python2.4-optcomplete_1.2-4_all.deb c94f4867c5387c9e4b1e3eb72d70b51c 19208 python optional optcomplete-common_1.2-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDukskeBwlBDLsbz4RAmfsAJ9qKqzOKSPrTmKl5Vno/HVNxiq5jgCeM6Ne h4du9lg4NpvuiO+wyJdEt24= =4yTy -END PGP SIGNATURE- Accepted: optcomplete-common_1.2-4_all.deb to pool/main/o/optcomplete/optcomplete-common_1.2-4_all.deb optcomplete_1.2-4.diff.gz to pool/main/o/optcomplete/optcomplete_1.2-4.diff.gz optcomplete_1.2-4.dsc to pool/main/o/optcomplete/optcomplete_1.2-4.dsc python-optcomplete_1.2-4_all.deb to pool/main/o/optcomplete/python-optcomplete_1.2-4_all.deb python2.3-optcomplete_1.2-4_all.deb to pool/main/o/optcomplete/python2.3-optcomplete_1.2-4_all.deb python2.4-optcomplete_1.2-4_all.deb to pool/main/o/optcomplete/python2.4-optcomplete_1.2-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sear 0.6.0-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 10:58:56 + Source: sear Binary: sear Architecture: source i386 Version: 0.6.0-2 Distribution: unstable Urgency: low Maintainer: Michael Koch [EMAIL PROTECTED] Changed-By: Michael Koch [EMAIL PROTECTED] Description: sear - 3D client for the Worldforge game servers Changes: sear (0.6.0-2) unstable; urgency=low . * Removed Build-Depends on xlibmesa-dev | libgl-dev. Files: aef5873c19b38e85b4a53aaa2fb4c0ba 901 games optional sear_0.6.0-2.dsc b97b551ff9f6bcd1a45d4d03a8e6b94a 4386 games optional sear_0.6.0-2.diff.gz 5035158fb5e984d0d0224da9d4744512 875224 games optional sear_0.6.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDuml9WSOgCCdjSDsRApDLAJ4433weUD0nzUi65EyYO0mz8V1NOwCaAxEv 8cdKRkTuw3DXDlG2wAUOEOA= =XrkZ -END PGP SIGNATURE- Accepted: sear_0.6.0-2.diff.gz to pool/main/s/sear/sear_0.6.0-2.diff.gz sear_0.6.0-2.dsc to pool/main/s/sear/sear_0.6.0-2.dsc sear_0.6.0-2_i386.deb to pool/main/s/sear/sear_0.6.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted synaptic 0.57.7.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 12:32:33 +0100 Source: synaptic Binary: synaptic Architecture: source i386 Version: 0.57.7.1 Distribution: unstable Urgency: low Maintainer: Michael Vogt [EMAIL PROTECTED] Changed-By: Michael Vogt [EMAIL PROTECTED] Description: synaptic - Graphical package manager Changes: synaptic (0.57.7.1) unstable; urgency=low . * fixed build-dependencies Files: 02237567900dc054304583c7a2eb48f5 713 admin optional synaptic_0.57.7.1.dsc fb4fc5839212db4843bc9546083f4264 2006968 admin optional synaptic_0.57.7.1.tar.gz 86b37f6896e5895e6c23191941c7d0ec 1778728 admin optional synaptic_0.57.7.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDumOsliSD4VZixzQRAv4zAJ4ib7ZadzCIHb/NA/QaN5gYS2mv2ACfTLV0 dU2sk2iSq9KGqwvLQDTZkWU= =C1BB -END PGP SIGNATURE- Accepted: synaptic_0.57.7.1.dsc to pool/main/s/synaptic/synaptic_0.57.7.1.dsc synaptic_0.57.7.1.tar.gz to pool/main/s/synaptic/synaptic_0.57.7.1.tar.gz synaptic_0.57.7.1_i386.deb to pool/main/s/synaptic/synaptic_0.57.7.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libtextwrap 0.1-4 (source i386 sparc alpha)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 03 Jan 2006 22:37:51 +1100 Source: libtextwrap Binary: libtextwrap-dev libtextwrap1 Architecture: source i386 alpha sparc Version: 0.1-4 Distribution: unstable Urgency: low Maintainer: Anibal Monsalve Salazar [EMAIL PROTECTED] Changed-By: Anibal Monsalve Salazar [EMAIL PROTECTED] Description: libtextwrap-dev - text-wrapping library with i18n - development files libtextwrap1 - text-wrapping library with i18n - runtime Closes: 341477 342673 Changes: libtextwrap (0.1-4) unstable; urgency=low . * Fixed libtextwrap-dev: bogus use of Conflicts, closes: #341477. * Fixed libtextwrap(GNU/k*BSD): FTBFS: out of date libtool scripts, closes: #342673. * Fixed override disparity found in unstable, changed libtextwrap1 priority from important to standard. * Added debian watch file. Files: 4cee1597336b01dbf33541dab74c8568 639 libs important libtextwrap_0.1-4.dsc ef7e68b6c0d1207ade2bd1668c7cee7c 3340 libs important libtextwrap_0.1-4.diff.gz f4eed609a80151c6bb53326e6de13614 14454 libdevel optional libtextwrap-dev_0.1-4_i386.deb 292428f7c666a866d39e5ea9713fd649 9332 libs standard libtextwrap1_0.1-4_i386.deb 38d79a36c6342dcb88694563ae81869e 14680 libdevel optional libtextwrap-dev_0.1-4_sparc.deb 418ab47664795372e2b619d06137d488 9382 libs standard libtextwrap1_0.1-4_sparc.deb 50475d015e0f477a4b25549cf48e4706 16220 libdevel optional libtextwrap-dev_0.1-4_alpha.deb b04823bc156626cdd632c5772621c410 10176 libs standard libtextwrap1_0.1-4_alpha.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDumrGipBneRiAKDwRAnHIAJ45Vu9PD3BZlSDq7JR6f97qIgFISgCgjR2e xH1GE65+EVJ+5dl7OfHeC8A= =VVkA -END PGP SIGNATURE- Accepted: libtextwrap-dev_0.1-4_alpha.deb to pool/main/libt/libtextwrap/libtextwrap-dev_0.1-4_alpha.deb libtextwrap-dev_0.1-4_i386.deb to pool/main/libt/libtextwrap/libtextwrap-dev_0.1-4_i386.deb libtextwrap-dev_0.1-4_sparc.deb to pool/main/libt/libtextwrap/libtextwrap-dev_0.1-4_sparc.deb libtextwrap1_0.1-4_alpha.deb to pool/main/libt/libtextwrap/libtextwrap1_0.1-4_alpha.deb libtextwrap1_0.1-4_i386.deb to pool/main/libt/libtextwrap/libtextwrap1_0.1-4_i386.deb libtextwrap1_0.1-4_sparc.deb to pool/main/libt/libtextwrap/libtextwrap1_0.1-4_sparc.deb libtextwrap_0.1-4.diff.gz to pool/main/libt/libtextwrap/libtextwrap_0.1-4.diff.gz libtextwrap_0.1-4.dsc to pool/main/libt/libtextwrap/libtextwrap_0.1-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted yardradius 1.0.21-17 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 13:17:47 +0100 Source: yardradius Binary: yardradius Architecture: source i386 Version: 1.0.21-17 Distribution: unstable Urgency: low Maintainer: Francesco Paolo Lovergine [EMAIL PROTECTED] Changed-By: Francesco Paolo Lovergine [EMAIL PROTECTED] Description: yardradius - YARD Radius Auth/Acct Server Changes: yardradius (1.0.21-17) unstable; urgency=low . * Moved to compatibility level 4 for debhelper * Policy bumped to 3.6.2 * init script changed to use lsb-base if available * Reverted to non-native package Files: af2a7908b5e12e4245343a59f6142437 635 net optional yardradius_1.0.21-17.dsc 30c2e3dfb3c9d8cfcba3ecd67f376dff 394983 net optional yardradius_1.0.21.orig.tar.gz 63517aeef88ffcb608096b2b1b8c9578 17857 net optional yardradius_1.0.21-17.diff.gz 887fc280c1cf2cb5bb28dc6418660ff2 160674 net optional yardradius_1.0.21-17_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDumxXpFNRmenyx0cRAg5KAKCSTpMwS5E79l6gSuuTslsk0eMFAgCeMHqZ yTltt1X6CmfbBu5bm9ZXVUU= =pylk -END PGP SIGNATURE- Accepted: yardradius_1.0.21-17.diff.gz to pool/main/y/yardradius/yardradius_1.0.21-17.diff.gz yardradius_1.0.21-17.dsc to pool/main/y/yardradius/yardradius_1.0.21-17.dsc yardradius_1.0.21-17_i386.deb to pool/main/y/yardradius/yardradius_1.0.21-17_i386.deb yardradius_1.0.21.orig.tar.gz to pool/main/y/yardradius/yardradius_1.0.21.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted storebackup 1.19-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.7 Date: Sat, 31 Dec 2005 15:54:02 +0100 Source: storebackup Binary: storebackup Architecture: source all Version: 1.19-2 Distribution: unstable Urgency: low Maintainer: Arthur Korn [EMAIL PROTECTED] Changed-By: Arthur Korn [EMAIL PROTECTED] Description: storebackup - fancy compressing managing checksumming hard-linking cp -rua Changes: storebackup (1.19-2) unstable; urgency=low . * Fix instance of too well predicteable filename of written to temporary file, found and fixed by Moritz Muehlenhoff. Files: 04156e935dd45c5fa6baabd52d7c9fb4 585 utils optional storebackup_1.19-2.dsc ebd49e6a079e1c4743ffd0421463a366 5695 utils optional storebackup_1.19-2.diff.gz bf4fe91577bd22ef975f9478ed666bcb 126858 utils optional storebackup_1.19-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDtpzENgpsykSg/LgRA40SAJ0eUhj2pw8dVK6Jk++tAV8fGWiWAQCgzwSF b3Lf05FS8lOdo4w3m7XCVak= =3cIs -END PGP SIGNATURE- Accepted: storebackup_1.19-2.diff.gz to pool/main/s/storebackup/storebackup_1.19-2.diff.gz storebackup_1.19-2.dsc to pool/main/s/storebackup/storebackup_1.19-2.dsc storebackup_1.19-2_all.deb to pool/main/s/storebackup/storebackup_1.19-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtkwave 1.3.81-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 Jan 2006 00:29:10 +1100 Source: gtkwave Binary: gtkwave Architecture: source i386 Version: 1.3.81-1 Distribution: unstable Urgency: low Maintainer: Hamish Moffatt [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: gtkwave- a VCD (Value Change Dump) file waveform viewer Closes: 345771 Changes: gtkwave (1.3.81-1) unstable; urgency=low . * New upstream release (closes: #345771) * Updated upstream source location and generally improved copyright file * Removed build-dep for xlibs-dev, as gtkwave does not make any direct X11 function calls but uses GTK+ for everything Files: 8f18320bc9dab106b01c24a2bce3a340 718 electronics optional gtkwave_1.3.81-1.dsc 3dfd17856187c816b533aec1e78e80cb 857752 electronics optional gtkwave_1.3.81.orig.tar.gz 8f30c4ecfd3524dce6571e9430c9f989 3623 electronics optional gtkwave_1.3.81-1.diff.gz 96ac4e251c847c769ddc98ad29c57b23 621146 electronics optional gtkwave_1.3.81-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQCVAwUBQ7p8odiYIdPvprnVAQK5pwP9Gh37pylru7uIh+eU2IlxzJu8UMs9Odo1 uZcSm8NEOwkY9QvrA2GTP6Pl1+UmB9PIPF6DjSsnrCYrwlko6b+f5znwwFgujLUK 6dokc9xMch0BsNfm80fp+VmQfebbtldejV3OJ8St+jw/pGo3Eg6pjKHfMCK1hJP6 l+0uUIGPxHU= =uxl+ -END PGP SIGNATURE- Accepted: gtkwave_1.3.81-1.diff.gz to pool/main/g/gtkwave/gtkwave_1.3.81-1.diff.gz gtkwave_1.3.81-1.dsc to pool/main/g/gtkwave/gtkwave_1.3.81-1.dsc gtkwave_1.3.81-1_i386.deb to pool/main/g/gtkwave/gtkwave_1.3.81-1_i386.deb gtkwave_1.3.81.orig.tar.gz to pool/main/g/gtkwave/gtkwave_1.3.81.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted raptor 1.4.8-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Jan 2006 23:09:34 -0800 Source: raptor Binary: libraptor1-dev libraptor1-doc libraptor1 raptor-utils Architecture: source all i386 Version: 1.4.8-1 Distribution: unstable Urgency: low Maintainer: Dave Beckett [EMAIL PROTECTED] Changed-By: Dave Beckett [EMAIL PROTECTED] Description: libraptor1 - Raptor RDF parser and serializer library libraptor1-dev - Raptor RDF parser and serializer development libraries and header libraptor1-doc - Documentation for the Raptor RDF parser and serializer library raptor-utils - Raptor RDF parser and serializer utilities Changes: raptor (1.4.8-1) unstable; urgency=low . * New upstream release * Added libraptor1-doc package for the new gtk-doc html * debian/watch: Updated url Files: c0e4b77f9c4baa91490d8da49b580b98 717 devel optional raptor_1.4.8-1.dsc 112d8b72a37f4de8a00f840999f2d383 1315307 devel optional raptor_1.4.8.orig.tar.gz a774bd7ba50f92d6d1e5ab6c2d7da01f 7921 devel optional raptor_1.4.8-1.diff.gz cf2dbbcd908072a44b9d5ad39754aa4b 97148 doc optional libraptor1-doc_1.4.8-1_all.deb 32e576d4b8b0f32facee83e9d24f50b5 183410 libdevel optional libraptor1-dev_1.4.8-1_i386.deb a40b861c03e61c46469a0f9f23592322 137126 libs optional libraptor1_1.4.8-1_i386.deb 424e5ff7378d68b177d61b0912994732 43622 text optional raptor-utils_1.4.8-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuiN8Q+ySUE9xlVoRAnhdAJ9Wc7k2sOeNnuA6j63brBKeDVVROQCgkha4 bu1a3Ru3GC9231I/m0HNhT8= =dBs7 -END PGP SIGNATURE- Accepted: libraptor1-dev_1.4.8-1_i386.deb to pool/main/r/raptor/libraptor1-dev_1.4.8-1_i386.deb libraptor1-doc_1.4.8-1_all.deb to pool/main/r/raptor/libraptor1-doc_1.4.8-1_all.deb libraptor1_1.4.8-1_i386.deb to pool/main/r/raptor/libraptor1_1.4.8-1_i386.deb raptor-utils_1.4.8-1_i386.deb to pool/main/r/raptor/raptor-utils_1.4.8-1_i386.deb raptor_1.4.8-1.diff.gz to pool/main/r/raptor/raptor_1.4.8-1.diff.gz raptor_1.4.8-1.dsc to pool/main/r/raptor/raptor_1.4.8-1.dsc raptor_1.4.8.orig.tar.gz to pool/main/r/raptor/raptor_1.4.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted llvm 1.6-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Jan 2006 15:23:30 -0700 Source: llvm Binary: llvm-libs llvm-examples llvm-cfe llvm llvm-doc Architecture: source all i386 Version: 1.6-1 Distribution: unstable Urgency: low Maintainer: Al Stone [EMAIL PROTECTED] Changed-By: Al Stone [EMAIL PROTECTED] Description: llvm - Low-Level Virtual Machine (LLVM) compiler for C/C++ llvm-cfe - C front end for LLVM C/C++ compiler llvm-doc - documentation for LLVM (Low-Level Virtual Machine) compiler llvm-examples - examples using LLVM (Low-Level Virtual Machine) compiler llvm-libs - common libraries for LLVM compiler for C/C++ Closes: 332517 339768 Changes: llvm (1.6-1) unstable; urgency=low . * Closes: bug#339768 -- new upstream version * Closes: bug#332517 -- FTBS on s390 (it's not a supported architecture) Files: 8391c76fbb4c1424278d52a51db4eb75 702 devel optional llvm_1.6-1.dsc a14d08c2314f24c9f2de2911e0ce19d3 43411899 devel optional llvm_1.6.orig.tar.gz 185d212c4fbb23dccfa953a1adc24057 9118 devel optional llvm_1.6-1.diff.gz 3555a29a9256120d352ea70bdcc0136b 4327544 libs optional llvm-libs_1.6-1_i386.deb f4b2864da0724172680c543ce68380fa 5768132 devel optional llvm-cfe_1.6-1_i386.deb c2f11385bf9910464c44b68c2dea65d5 17393660 devel optional llvm_1.6-1_i386.deb ba5917b32182740d0e11dead7d59a6b0 2616732 doc optional llvm-examples_1.6-1_i386.deb 27f3dee4c8179dbd1c4f5a6594f75de2 41651876 doc optional llvm-doc_1.6-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDucRDso6+T7qY4V0RAn1UAJ4wAgG2UNGL8vUlZ7rMkBB9JgbruQCcDIt0 TJ84/NjLo/uDeiU4Gd4SvoQ= =DK+Y -END PGP SIGNATURE- Accepted: llvm-cfe_1.6-1_i386.deb to pool/main/l/llvm/llvm-cfe_1.6-1_i386.deb llvm-doc_1.6-1_all.deb to pool/main/l/llvm/llvm-doc_1.6-1_all.deb llvm-examples_1.6-1_i386.deb to pool/main/l/llvm/llvm-examples_1.6-1_i386.deb llvm-libs_1.6-1_i386.deb to pool/main/l/llvm/llvm-libs_1.6-1_i386.deb llvm_1.6-1.diff.gz to pool/main/l/llvm/llvm_1.6-1.diff.gz llvm_1.6-1.dsc to pool/main/l/llvm/llvm_1.6-1.dsc llvm_1.6-1_i386.deb to pool/main/l/llvm/llvm_1.6-1_i386.deb llvm_1.6.orig.tar.gz to pool/main/l/llvm/llvm_1.6.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apr-util1.0 1.2.2-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 13:05:02 + Source: apr-util1.0 Binary: libaprutil1.0-dbg libaprutil1.0-dev libaprutil1.0 Architecture: source i386 Version: 1.2.2-2 Distribution: unstable Urgency: low Maintainer: Debian Apache Maintainers debian-apache@lists.debian.org Changed-By: Thom May [EMAIL PROTECTED] Description: libaprutil1.0 - The Apache Portable Runtime Utility Library libaprutil1.0-dbg - The Apache Portable Runtime Utility Library - Development Headers libaprutil1.0-dev - The Apache Portable Runtime Utility Library - Development Headers Changes: apr-util1.0 (1.2.2-2) unstable; urgency=low . * Upgrade to debhelper v5 * Call dh_installdocs, so we actually get a copyright. Files: 173624a2f5abc26ef54e54531efdad6b 1665 libs optional apr-util1.0_1.2.2-2.dsc bc8429283a583c065155f1a56c28af9c 13840 libs optional apr-util1.0_1.2.2-2.diff.gz 8b3f04dde7048946c3c94f85b4debb94 645311 libs optional apr-util1.0_1.2.2.orig.tar.gz 835738910fcf064195d9ad4889446cea 63830 libs optional libaprutil1.0_1.2.2-2_i386.deb ce34256fe521f26fbb4ced58e4fc5289 112428 libs optional libaprutil1.0-dev_1.2.2-2_i386.deb a11d7e349b8d7e6022e5b4b38ac8944a 112122 libs optional libaprutil1.0-dbg_1.2.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQIVAwUBQ7qEg7VnlGdHP376AQLmPxAAlOSxDwVEp8PTnB1dvdzt+DAPMbv2vgQ9 H1+yChKqZmLKwwPHv5HVT+8KlZDkSgj01hQmM7Al0ZaukL/dNDydgXW+TBQIbvcX lrHXq9UYcf7ZuZVuBBFb8FgivnG/FMOviuhkRbs0Z2p4JN794xSdlpW2K+I+LLal s+N5a1if+pGSNqBPtac3sQ1APk43l0bptdUIq8O46dGWEBULFTpxiotKyL3DPHEp v9ezPR5/+4ZltwmsM9CJFv433oSXmB67DN1ZvjTcJqtgFyPiZFGeUMDH0mlDclZ3 sHOlFwVyaC6qh+P9IHsLm6jsUKW2sTycgy9CtBYgegVoGBGRh8mdYtasisfJvI33 xAwkspe+NOFi9ubpbWRkSPYJ6RCyq7NoSC5rn+O7y+7JVo5/tKXPwLkpBvFRG1mP vEqeYctv9z/NtXZEqh5ewLbqPHKEs3ByavRnFXqOpnQ3MKYbZjEqXkVX7fgIuGnr RPDogO6Z7RDr5i3k6wS0j0V9uW6xMHvykVMycAyQPU3LonsqkbIDZy33lsWqqHKX f2739jUUl5v1IBt8CxpIOla6I3NAnfFwGmVhgFO6KDozFQSDmZqQLN/ocgV7fteK +KOfpYMbWhpgjDYhAnh85/oi5URq3ze8e6+XB5SiYShbZnHzv4mThwCnkfW7nm86 ETPupHPaq7A= =5w7Y -END PGP SIGNATURE- Accepted: apr-util1.0_1.2.2-2.diff.gz to pool/main/a/apr-util1.0/apr-util1.0_1.2.2-2.diff.gz apr-util1.0_1.2.2-2.dsc to pool/main/a/apr-util1.0/apr-util1.0_1.2.2-2.dsc apr-util1.0_1.2.2.orig.tar.gz to pool/main/a/apr-util1.0/apr-util1.0_1.2.2.orig.tar.gz libaprutil1.0-dbg_1.2.2-2_i386.deb to pool/main/a/apr-util1.0/libaprutil1.0-dbg_1.2.2-2_i386.deb libaprutil1.0-dev_1.2.2-2_i386.deb to pool/main/a/apr-util1.0/libaprutil1.0-dev_1.2.2-2_i386.deb libaprutil1.0_1.2.2-2_i386.deb to pool/main/a/apr-util1.0/libaprutil1.0_1.2.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apr1.0 1.2.2-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 13:01:56 + Source: apr1.0 Binary: libapr1.0 libapr1.0-dbg libapr1.0-dev Architecture: source i386 Version: 1.2.2-2 Distribution: unstable Urgency: low Maintainer: Debian Apache Maintainers debian-apache@lists.debian.org Changed-By: Thom May [EMAIL PROTECTED] Description: libapr1.0 - The Apache Portable Runtime Library libapr1.0-dbg - The Apache Portable Runtime Library - Development Headers libapr1.0-dev - The Apache Portable Runtime Library - Development Headers Changes: apr1.0 (1.2.2-2) unstable; urgency=low . * Up to debhelper v5 * Add call to dh_installdocs; not sure why I was not doing this already. Files: 87140f87bc70afc1d145182c5954e646 1489 libs optional apr1.0_1.2.2-2.dsc 27d7e79dc1853a8fa3511d1a79b54c72 7898 libs optional apr1.0_1.2.2-2.diff.gz f96e3b04ccf86ed28a0734d7efc5bb65 1096029 libs optional apr1.0_1.2.2.orig.tar.gz e63ab0d5e5749648bc324e08a4a3fe06 104360 libs optional libapr1.0_1.2.2-2_i386.deb 1afe6c2012c6e8924aa7c6b569d44dc4 251734 libs optional libapr1.0-dev_1.2.2-2_i386.deb 03a6c32e93dd2ae660a448519436f957 166904 libs optional libapr1.0-dbg_1.2.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQIVAwUBQ7qDz7VnlGdHP376AQKuOQ//YUtXOHMgSD+o6YML8A3BriKwQzqaqSKP u8FWiRyiZhbsxAusaeCZf8+zJu4mF3wNSFeXOX1Xf7QbzL0m0zPxkMpnrTfu/Iz4 hAg/1ORESlw2+4hx+ClcmhWy7cPm0r0cAUU03poSN3jy83622p/eH/AAIAnB+V+l Rn5B6juNEkVQLjKuZZyDETlbVOpWdkX3rpbroRttVVFmqOnjfkUv8c7A14xczWJC oiyjn5j3ZH44wn222paMi+em+UftvGHJ8BDQ+A1aZkRNL+aPRSEuDW482kHbn/tj VJX3MqSR/FyZH1/nS3hcHuKdK0Mjb2iFhMJkqjc97+/2yexh/2YiRFLiggmVp2jt QMM1epdTtIvJu3d2KQpM4DKqUu5b3XdS6a9G5M3RPToSctFKPeqpXdkICI34E3i2 P6vvL/tsjgxKnRZCCWbVi5QVriIFROAYnZfSdnByw4/ffUFxSHAPsJk6gH0b1rYC BCI/tHH25lM3ppSnQ4v+QsmT1gq/MF4866CCtZ1aXbaRuc3DvdkNNQ9fORf+ue9y E2LDWdGvqYL7u+G/4FLLvPWOg3+gZKBFObmCCmtbGmsihshP1syhTf4swbPTQ01R +CW7sPRYCOwy6PNJwYAr3TPRUjetLuxG4eTF4YwlsOrzSvmhzMpsHWDpeWY1C+oH iXntPyEcaTk= =CIp1 -END PGP SIGNATURE- Accepted: apr1.0_1.2.2-2.diff.gz to pool/main/a/apr1.0/apr1.0_1.2.2-2.diff.gz apr1.0_1.2.2-2.dsc to pool/main/a/apr1.0/apr1.0_1.2.2-2.dsc apr1.0_1.2.2.orig.tar.gz to pool/main/a/apr1.0/apr1.0_1.2.2.orig.tar.gz libapr1.0-dbg_1.2.2-2_i386.deb to pool/main/a/apr1.0/libapr1.0-dbg_1.2.2-2_i386.deb libapr1.0-dev_1.2.2-2_i386.deb to pool/main/a/apr1.0/libapr1.0-dev_1.2.2-2_i386.deb libapr1.0_1.2.2-2_i386.deb to pool/main/a/apr1.0/libapr1.0_1.2.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-2.6 2.6.15-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 06:48:07 + Source: linux-2.6 Binary: linux-image-sun3 linux-image-2.6-powerpc-miboot linux-headers-2.6.15-1-rpc linux-image-2.6-footbridge linux-tree-2.6.15 linux-image-2.6-parisc64 linux-image-2.6-amd64-generic kernel-image-2.6-686-smp linux-headers-2.6.15-1-parisc-smp linux-image-2.6-486 linux-headers-2.6-atari linux-headers-2.6-s390 linux-image-2.6.15-1-s3c2410 linux-image-mvme16x linux-headers-2.6.15-1-s390 linux-image-itanium linux-image-2.6-amd64-k8-smp linux-image-2.6-rpc linux-image-2.6.15-1-atari linux-image-2.6.15-1-amiga linux-image-2.6-s390 linux-image-q40 linux-headers-2.6-sparc64-smp linux-headers-2.6-mvme147 linux-image-2.6.15-1-parisc linux-image-2.6.15-1-powerpc-smp linux-image-2.6.15-1-itanium linux-image-footbridge kernel-image-2.6-itanium-smp linux-image-2.6.15-1-mvme147 linux-image-2.6.15-1-parisc64-smp linux-headers-2.6-686-smp linux-headers-2.6.15-1-amd64-k8 linux-image-atari linux-doc-2.6.15 linux-image-2.6-q40 kernel-image-2.6-k7-smp linux-headers-2.6.15-1-486 linux-headers-2.6-powerpc-miboot linux-headers-2.6-apus linux-headers-2.6.15 linux-headers-2.6.15-1-powerpc-smp linux-image-2.6.15-1-k7 linux-image-2.6.15-1-parisc64 linux-image-s390 linux-image-apus linux-image-2.6.15-1-sun3 linux-headers-2.6.15-1-mac linux-image-2.6-itanium linux-image-parisc-smp linux-image-2.6.15-1-s390 linux-image-2.6.15-1-powerpc linux-image-amd64-k8-smp linux-image-2.6-parisc-smp linux-image-2.6.15-1-apus linux-image-2.6.15-1-parisc-smp linux-headers-2.6.15-1-amiga linux-headers-2.6-amd64-generic linux-image-2.6-mckinley-smp linux-image-amiga linux-image-2.6-k7 linux-image-2.6.15-1-686-smp linux-headers-2.6.15-1 linux-image-mckinley-smp linux-image-em64t-p4-smp linux-image-2.6.15-1-sparc64 linux-image-2.6-powerpc linux-image-parisc64-smp linux-headers-2.6-s3c2410 linux-image-2.6-hp linux-headers-2.6.15-1-alpha-generic linux-image-sparc64-smp linux-headers-2.6.15-1-sparc64-smp linux-headers-2.6-parisc64-smp linux-image-2.6-parisc64-smp kernel-image-2.6-mckinley linux-image-2.6.15-1-q40 linux-image-powerpc-smp linux-image-2.6.15-1-mckinley linux-headers-2.6-itanium-smp kernel-image-2.6-power3 linux-headers-2.6.15-1-parisc kernel-image-2.6-powerpc kernel-image-2.6-generic linux-headers-2.6-mvme16x linux-image-2.6.15-1-alpha-generic linux-image-2.6-alpha-generic linux-headers-2.6-amd64-k8-smp linux-image-2.6-em64t-p4 linux-headers-2.6.15-1-mckinley linux-headers-2.6.15-1-bvme6000 linux-image-2.6.15-1-amd64-generic linux-headers-2.6-powerpc linux-image-hp linux-headers-2.6-em64t-p4-smp kernel-image-powerpc-smp linux-headers-2.6-sparc64 linux-image-powerpc64 linux-headers-2.6-hp linux-headers-2.6-powerpc64 linux-image-2.6-apus linux-image-2.6.15-1-powerpc64 linux-headers-2.6.15-1-footbridge linux-headers-2.6.15-1-powerpc64 linux-headers-2.6.15-1-sparc64 linux-headers-2.6.15-1-q40 linux-headers-2.6-mac linux-headers-2.6.15-1-686 linux-image-2.6.15-1-amd64-k8-smp linux-headers-2.6-em64t-p4 linux-headers-2.6-rpc linux-image-2.6-mckinley linux-headers-2.6.15-1-s390x linux-headers-2.6-alpha-generic linux-headers-2.6-bvme6000 kernel-image-2.6-sparc64-smp kernel-image-powerpc linux-image-bvme6000 linux-headers-2.6-alpha-smp linux-headers-2.6.15-1-powerpc linux-image-2.6-atari linux-headers-2.6.15-1-em64t-p4 linux-headers-2.6.15-1-parisc64 linux-image-s3c2410 linux-headers-2.6-sun3 linux-image-2.6.15-1-mckinley-smp linux-headers-2.6.15-1-ixp4xx linux-headers-2.6-mckinley-smp kernel-image-2.6-power4-smp linux-image-parisc64 linux-headers-2.6.15-1-k7 linux-image-k7-smp kernel-image-2.6-486 linux-image-2.6.15-1-s390x linux-manual-2.6.15 kernel-image-power3-smp linux-image-2.6-parisc linux-image-2.6-bvme6000 linux-image-mckinley linux-image-itanium-smp linux-image-2.6-sparc64-smp linux-headers-2.6-s390x linux-headers-2.6-parisc linux-image-2.6.15-1-footbridge linux-image-2.6-ixp4xx linux-image-2.6.15-1-486 linux-headers-2.6-q40 linux-headers-2.6.15-1-alpha-smp kernel-image-2.6-k7 linux-image-2.6.15-1-em64t-p4-smp linux-image-ixp4xx linux-image-rpc linux-image-2.6-mac kernel-image-2.6-power3-smp linux-headers-2.6.15-1-hp linux-image-2.6-s390x kernel-image-2.6-smp linux-image-2.6.15-1-686 linux-image-alpha-smp linux-image-2.6.15-1-sparc64-smp linux-image-2.6.15-1-k7-smp linux-image-2.6-amd64-k8 linux-image-parisc linux-headers-2.6.15-1-powerpc-miboot linux-headers-2.6-footbridge linux-image-2.6.15-1-bvme6000 linux-image-2.6.15-1-ixp4xx linux-headers-2.6.15-1-mvme147 linux-image-2.6-sparc64 linux-image-amd64-k8 linux-image-2.6.15-1-em64t-p4 linux-image-2.6.15-1-alpha-smp linux-headers-2.6.15-1-em64t-p4-smp linux-image-2.6.15-1-powerpc-miboot kernel-image-power4 linux-headers-2.6.15-1-amd64-generic linux-headers-2.6.15-1-itanium linux-headers-2.6.15-1-sun3 linux-headers-2.6.15-1-mvme16x linux-image-2.6-s3c2410 linux-headers-2.6-k7-smp linux-image-2.6.15-1-amd64-k8
Accepted kwave 0.7.5-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 11:29:36 +0100 Source: kwave Binary: kwave Architecture: source i386 Version: 0.7.5-1 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: kwave - sound editor for KDE Changes: kwave (0.7.5-1) unstable; urgency=low . * New upstream version. Files: 334cfd6634ea319cc857734c2412cfb6 850 kde optional kwave_0.7.5-1.dsc 0c6951360b4ce10f537efdd2c6b1712c 3082906 kde optional kwave_0.7.5.orig.tar.gz c7fc1ba72bf45a655ed25d772c0cd352 7124 kde optional kwave_0.7.5-1.diff.gz cbaf330db1f6d1159b76534080c952cc 2988332 kde optional kwave_0.7.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDunZPw3ao2vG823MRAmsoAKCPzffe25Fd9TvERBAEtzYefvIjBgCcCqvY ciQo2L52D5AI4+vjvKw9mZ8= =p/jB -END PGP SIGNATURE- Accepted: kwave_0.7.5-1.diff.gz to pool/main/k/kwave/kwave_0.7.5-1.diff.gz kwave_0.7.5-1.dsc to pool/main/k/kwave/kwave_0.7.5-1.dsc kwave_0.7.5-1_i386.deb to pool/main/k/kwave/kwave_0.7.5-1_i386.deb kwave_0.7.5.orig.tar.gz to pool/main/k/kwave/kwave_0.7.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdbix-class-loader-perl 0.11-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 16:05:06 +0100 Source: libdbix-class-loader-perl Binary: libdbix-class-loader-perl Architecture: source all Version: 0.11-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libdbix-class-loader-perl - Dynamic definition of DBIx::Class sub classes. Changes: libdbix-class-loader-perl (0.11-1) unstable; urgency=low . * New upstream release * debian/watch file updated * debian/control - libuniversal-require-perl added to dependencies, - libdbd-sqlite2-perl changed to libdbd-sqlite3-perl Files: d4a6991bd5db94a5fc05c52caa82adcb 895 perl optional libdbix-class-loader-perl_0.11-1.dsc 66aed46b1c7812792098b2ace687a5b6 9546 perl optional libdbix-class-loader-perl_0.11.orig.tar.gz f89093db0119efa3d80ff6c241f0760a 2374 perl optional libdbix-class-loader-perl_0.11-1.diff.gz b5a92e10d6e0bdeb46002ab4f46166e5 25812 perl optional libdbix-class-loader-perl_0.11-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDupPr+NMfSd6w7DERAqERAJ98Qdhxf4b5QqJqMqOP/Wu15DkQcQCfVqVG aKDDruM9r9ildyLhGQu5pzY= =gyNn -END PGP SIGNATURE- Accepted: libdbix-class-loader-perl_0.11-1.diff.gz to pool/main/libd/libdbix-class-loader-perl/libdbix-class-loader-perl_0.11-1.diff.gz libdbix-class-loader-perl_0.11-1.dsc to pool/main/libd/libdbix-class-loader-perl/libdbix-class-loader-perl_0.11-1.dsc libdbix-class-loader-perl_0.11-1_all.deb to pool/main/libd/libdbix-class-loader-perl/libdbix-class-loader-perl_0.11-1_all.deb libdbix-class-loader-perl_0.11.orig.tar.gz to pool/main/libd/libdbix-class-loader-perl/libdbix-class-loader-perl_0.11.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dsdo 1.4.52-1 (source all powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Dec 2005 16:18:15 +0100 Source: dsdo Binary: aspell-da myspell-da wdanish idanish Architecture: source all powerpc Version: 1.4.52-1 Distribution: unstable Urgency: low Maintainer: Jonas Smedegaard [EMAIL PROTECTED] Changed-By: Jonas Smedegaard [EMAIL PROTECTED] Description: aspell-da - The Comprehensive Danish Dictionary (DSDO) - aspell idanish- The Comprehensive Danish Dictionary (DSDO) - ispell myspell-da - The Comprehensive Danish Dictionary (DSDO) - myspell wdanish- The Comprehensive Danish Dictionary (DSDO) - wordlist Changes: dsdo (1.4.52-1) unstable; urgency=low . * New upstream release. * Minor updates to local cdbs snippets (wrong namespaces). * Add local cdbs snippet copyright-check.mk. * Update debian/copyright: + Add differing copyright holder for unsq and ispell/ispell.aff (both still licensed as GPL), thanks to above cdbs snippet. + Quote only minimally (to avoid changing FSF address). * Simplify debian/watch to unfuck qa.debian.org status. * Mention Homepage (not Website) in long descriptions. * Define empty CDBS_BUILD_DEPENDS to avoid cdbs debian/control auto-update causing build-dependency on build-essential (and thus calm Debian ftpmasters scared that build-essential might one day not be needed and break the world as we know it :-P ). * Auto-update debian/control. Files: 91cce956c5e28792d200cdc65afbdf4c 715 text optional dsdo_1.4.52-1.dsc 2aa45cf8d235869ff986fc418c7ed51d 469372 text optional dsdo_1.4.52.orig.tar.gz c5de271b1654cd9ae5de4c59d46d5ed4 10002 text optional dsdo_1.4.52-1.diff.gz 1d38dc9459ba994e434442a0739ecc61 982346 text optional wdanish_1.4.52-1_all.deb 8d51520b3cb82e988ac40f9cab274522 472682 text optional myspell-da_1.4.52-1_all.deb 27e7045c720715027ee8d50e29e9a359 194 text optional idanish_1.4.52-1_powerpc.deb f2ac17145818aa72d0f7487fb31f3c3a 4627162 text optional aspell-da_1.4.52-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDupeYn7DbMsAkQLgRAqrFAKCa0m5LQAs8C4R9Qw70cKnehutdcwCfY+Ej KRnXjSuNGkQGGge8bDbGzt0= =HvZf -END PGP SIGNATURE- Accepted: aspell-da_1.4.52-1_powerpc.deb to pool/main/d/dsdo/aspell-da_1.4.52-1_powerpc.deb dsdo_1.4.52-1.diff.gz to pool/main/d/dsdo/dsdo_1.4.52-1.diff.gz dsdo_1.4.52-1.dsc to pool/main/d/dsdo/dsdo_1.4.52-1.dsc dsdo_1.4.52.orig.tar.gz to pool/main/d/dsdo/dsdo_1.4.52.orig.tar.gz idanish_1.4.52-1_powerpc.deb to pool/main/d/dsdo/idanish_1.4.52-1_powerpc.deb myspell-da_1.4.52-1_all.deb to pool/main/d/dsdo/myspell-da_1.4.52-1_all.deb wdanish_1.4.52-1_all.deb to pool/main/d/dsdo/wdanish_1.4.52-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ydpdict 0.66-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 14:53:00 +0100 Source: ydpdict Binary: ydpdict Architecture: source i386 Version: 0.66-1 Distribution: unstable Urgency: medium Maintainer: Marcin Owsiany [EMAIL PROTECTED] Changed-By: Marcin Owsiany [EMAIL PROTECTED] Description: ydpdict- Interface for Collins dictionaries Closes: 345548 Changes: ydpdict (0.66-1) unstable; urgency=medium . * New upstream version - fixes samples playing and cmdline dict selection bugs Closes: #345548 urgency=medium since they are quite important for some people Files: 17f546d9d0a43a61fd0864dc38d3d09c 573 contrib/text optional ydpdict_0.66-1.dsc df6bf6196f15cde40bf71591948f61bf 69328 contrib/text optional ydpdict_0.66.orig.tar.gz 1c3f99fe31432be292112f31d46b8153 24565 contrib/text optional ydpdict_0.66-1.diff.gz e0beb982277a94d838d65aae734c48ef 20604 contrib/text optional ydpdict_0.66-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuoRtOg2KoGD0EhYRAvWdAJ0Vu75TEHfEPtw9VYnyMJi5W8TXjgCeLz7w DEag/Cn3CdIZSNmxEJ43Vuc= =de2k -END PGP SIGNATURE- Accepted: ydpdict_0.66-1.diff.gz to pool/contrib/y/ydpdict/ydpdict_0.66-1.diff.gz ydpdict_0.66-1.dsc to pool/contrib/y/ydpdict/ydpdict_0.66-1.dsc ydpdict_0.66-1_i386.deb to pool/contrib/y/ydpdict/ydpdict_0.66-1_i386.deb ydpdict_0.66.orig.tar.gz to pool/contrib/y/ydpdict/ydpdict_0.66.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted backupninja 0.9.2-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 29 Dec 2005 15:31:22 -0500 Source: backupninja Binary: backupninja Architecture: source all Version: 0.9.2-2 Distribution: unstable Urgency: low Maintainer: Micah Anderson [EMAIL PROTECTED] Changed-By: Micah Anderson [EMAIL PROTECTED] Description: backupninja - lightweight, extensible meta-backup system Changes: backupninja (0.9.2-2) unstable; urgency=low . * Fixed no user defaults file mysql handler problem Files: 1599c5c00b33d7228c25120283004591 577 admin optional backupninja_0.9.2-2.dsc b3ffc361608360bdc9cf5dc7b4e13fef 6242 admin optional backupninja_0.9.2-2.diff.gz 4ec02137f666c4eff92afe534e440681 69104 admin optional backupninja_0.9.2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuqQ49n4qXRzy1ioRAlr8AJ40PiA41CpBuPaqP1Zqx2JZCdRb/wCgmqmt EPccY0fhZoZEJbjyaNGxjIc= =YEE/ -END PGP SIGNATURE- Accepted: backupninja_0.9.2-2.diff.gz to pool/main/b/backupninja/backupninja_0.9.2-2.diff.gz backupninja_0.9.2-2.dsc to pool/main/b/backupninja/backupninja_0.9.2-2.dsc backupninja_0.9.2-2_all.deb to pool/main/b/backupninja/backupninja_0.9.2-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xml-light 2.2-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 17:37:47 +0100 Source: xml-light Binary: libxml-light-ocaml-dev Architecture: source i386 Version: 2.2-2 Distribution: unstable Urgency: low Maintainer: Sylvain Le Gall [EMAIL PROTECTED] Changed-By: Sylvain Le Gall [EMAIL PROTECTED] Description: libxml-light-ocaml-dev - mininal XML parser and printer for OCaml Closes: 345792 Changes: xml-light (2.2-2) unstable; urgency=low . * Apply patch 02_cmi_depends to fix the FTBFS with the latest make package (Closes: #345792) Files: 49b8e209959b145904ccd46614e5fc13 626 libdevel optional xml-light_2.2-2.dsc b5add4abdb2f95f0b578d1604cc96636 2524 libdevel optional xml-light_2.2-2.diff.gz 8751adaa1f76c3585a84b02a41fe0faf 67804 libdevel optional libxml-light-ocaml-dev_2.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuqjzir2bofsN/psRAu+FAJ4swwQG0gIgglh8AiIhpnzATOxYBQCfXvKM cT3XCzZ8BsAf3F2agWqZaE8= =+LAO -END PGP SIGNATURE- Accepted: libxml-light-ocaml-dev_2.2-2_i386.deb to pool/main/x/xml-light/libxml-light-ocaml-dev_2.2-2_i386.deb xml-light_2.2-2.diff.gz to pool/main/x/xml-light/xml-light_2.2-2.diff.gz xml-light_2.2-2.dsc to pool/main/x/xml-light/xml-light_2.2-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debconf 1.4.67 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 Jan 2006 18:42:30 + Source: debconf Binary: debconf-english debconf-doc debconf-utils debconf-i18n debconf Architecture: source all Version: 1.4.67 Distribution: unstable Urgency: low Maintainer: Joey Hess [EMAIL PROTECTED] Changed-By: Colin Watson [EMAIL PROTECTED] Description: debconf- Debian configuration management system debconf-doc - debconf documentation debconf-english - small footprint English-only debconf debconf-i18n - full internationalization support for debconf debconf-utils - debconf utilities Closes: 301998 344336 344643 344749 344966 344966 345339 Changes: debconf (1.4.67) unstable; urgency=low . [ Christian Perrier ] * Translations: - Greek updated programs. Closes: #344643 - Tagalog updated debconf. Closes: #344749 - Catalan updated debconf and programs. Closes: #344966 - Czech updated debconf and programs. Closes: #345339 . [ Joey Hess ] * debconf.conf(5) typo fix. Closes: #344336 . [ Colin Watson ] * Add bash completion file (thanks, Alexandra N. Kossovsky). Closes: #301998 * Fix DebconfCommunicator inheritance. . [ Luk Claes ] * Translations: - Catalan updated programs and debconf. Closes: #344966 Files: f6e8a5d3629d0d2f2395a4ba1685473d 685 admin optional debconf_1.4.67.dsc b235b43ccc0a4364c8f269c1fca383b3 403501 admin optional debconf_1.4.67.tar.gz 755b66f6e8671493cbdc62aa5ef1b891 123714 admin important debconf_1.4.67_all.deb 76f34eb5a0e0a00f3045238d1f49ea6c 116550 admin important debconf-i18n_1.4.67_all.deb 0efe6b7c3101ae3fcba7e39837f1f827 842 admin extra debconf-english_1.4.67_all.deb a1f95525132ee570ebe223fc433ac8e3 164282 doc optional debconf-doc_1.4.67_all.deb 8727ad75321ed83a1ffa94be3be6a1c9 32990 devel optional debconf-utils_1.4.67_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuseM9t0zAhD6TNERAg8OAJ9R13QGNqLHuBjOqSPmJQVCZSVTFQCeLSGr zTqSVVDIJ7zC3LX2P4WgJnA= =H7MI -END PGP SIGNATURE- Accepted: debconf-doc_1.4.67_all.deb to pool/main/d/debconf/debconf-doc_1.4.67_all.deb debconf-english_1.4.67_all.deb to pool/main/d/debconf/debconf-english_1.4.67_all.deb debconf-i18n_1.4.67_all.deb to pool/main/d/debconf/debconf-i18n_1.4.67_all.deb debconf-utils_1.4.67_all.deb to pool/main/d/debconf/debconf-utils_1.4.67_all.deb debconf_1.4.67.dsc to pool/main/d/debconf/debconf_1.4.67.dsc debconf_1.4.67.tar.gz to pool/main/d/debconf/debconf_1.4.67.tar.gz debconf_1.4.67_all.deb to pool/main/d/debconf/debconf_1.4.67_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-utilities 1.2.3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Dec 2005 17:14:19 +0100 Source: cl-utilities Binary: cl-utilities Architecture: source all Version: 1.2.3-1 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-utilities - a Common Lisp library of common functions Changes: cl-utilities (1.2.3-1) unstable; urgency=low . * New upstream, new features: 1. Now this doesn't assume that SBCL has sb-rotate-byte, which was causing some problems. Thanks to Gary King and John Wiseman for finding this problem in a certain version of SBCL on ppc. 2. If :split-sequence-deprecated is added to *features* before compiling cl-utilities, it will create a :split-sequence package which exports the usual split-sequence interface. This is for easy backward compatibility. If you do not add :split-sequence-deprecated to *features*, it will leave split-sequence alone. Thanks to Greg Pfeil for the idea and some of the code. Files: b003b840682c9caadda468ca3bd983bd 601 devel optional cl-utilities_1.2.3-1.dsc 3b9cfdb2a5b65e394067022cfb3e219d 22418 devel optional cl-utilities_1.2.3.orig.tar.gz 0c23608ad3bc43d5f36e5353e24af1b2 1795 devel optional cl-utilities_1.2.3-1.diff.gz d065d7d12f22ecc247ad91f6cb0ff9d2 25128 devel optional cl-utilities_1.2.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDtq7V11ldN0tyliURAsEtAJ9M3mu3QV49uEZZWmkkQ0voP6LaqACgkT7Z ayryTphvUJvRIkD/FfUXoZ0= =yN7M -END PGP SIGNATURE- Accepted: cl-utilities_1.2.3-1.diff.gz to pool/main/c/cl-utilities/cl-utilities_1.2.3-1.diff.gz cl-utilities_1.2.3-1.dsc to pool/main/c/cl-utilities/cl-utilities_1.2.3-1.dsc cl-utilities_1.2.3-1_all.deb to pool/main/c/cl-utilities/cl-utilities_1.2.3-1_all.deb cl-utilities_1.2.3.orig.tar.gz to pool/main/c/cl-utilities/cl-utilities_1.2.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sbcl 1:0.9.8.0-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 Dec 2005 17:15:50 +0100 Source: sbcl Binary: sbcl sbcl-common Architecture: source i386 all Version: 1:0.9.8.0-1 Distribution: unstable Urgency: low Maintainer: Peter Van Eynde [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: sbcl - A development environment for Common Lisp sbcl-common - Architecture independent files for SBCL Changes: sbcl (1:0.9.8.0-1) unstable; urgency=low . * Added conflicts with older versions of cl-clx-sbcl. Noted by Humberto Ortiz Zuazaga on the Lisp Gardners ML. * New upstream release Files: f38f475fba166d8df536b0b932875adf 675 devel optional sbcl_0.9.8.0-1.dsc b429c383d1a11e62b9f7273df227ff42 4324380 devel optional sbcl_0.9.8.0.orig.tar.gz 5cb4c231a71ed6b0222175267701f9e4 21213 devel optional sbcl_0.9.8.0-1.diff.gz 1f255c48ff3dc9a30a1c9f9a966316e8 4004700 devel optional sbcl-common_0.9.8.0-1_all.deb 43ce6b6cca0a6747c500a1820c2bac6a 8234126 devel optional sbcl_0.9.8.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuOtz11ldN0tyliURApz1AJ9NUJtzh3KrUc+TfKgJxkrSOCIHTgCdGcbZ njmQdD4haoo1l2whUar1+/Y= =Gojn -END PGP SIGNATURE- Accepted: sbcl-common_0.9.8.0-1_all.deb to pool/main/s/sbcl/sbcl-common_0.9.8.0-1_all.deb sbcl_0.9.8.0-1.diff.gz to pool/main/s/sbcl/sbcl_0.9.8.0-1.diff.gz sbcl_0.9.8.0-1.dsc to pool/main/s/sbcl/sbcl_0.9.8.0-1.dsc sbcl_0.9.8.0-1_i386.deb to pool/main/s/sbcl/sbcl_0.9.8.0-1_i386.deb sbcl_0.9.8.0.orig.tar.gz to pool/main/s/sbcl/sbcl_0.9.8.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
