Re: Upcoming Squeeze point release 6.0.2
Alexander Reichle-Schmehl wrote: Hi! Am 09.06.2011 00:09, schrieb Philipp Kern: the second Squeeze point release (6.0.2) is now scheduled for Saturday, June 25th. Bad timing; Meike and I will not be available on that weekend. Joey, are you available? Yep. I'm available that weekend. Regards, Joey -- Linux - the choice of a GNU generation. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110613173058.gz27...@finlandia.home.infodrom.org
Re: The future of clamav wrt. stable/volatile
Michael Tautschnig wrote: In the clamav packaging team we had recurring discussion about how to deal with clamav in the near (== lenny) and more distant (= squeeze) future. The current situation is as follows: - We've got severly outdated clamav packages in etch(-security). - A few packages depend on clamav; those depends are not necessarily versioned. - Any sensible use of clamav requires the packages from volatile to be able to handle all features of upstream's current signature database. - We've had 16 security updates since the release of etch, which constantly required backporting of upstream's fixes that were included in the volatile releases. We could of course continue this game of telling users that nothing but the clamav from volatile is what one should use on production systems, but maybe there are other options as well. Let me see what options we have: - Stick with the current scheme. Possible, but neither user- nor maintainer-friendly. - Move clamav to volatile only. This would, however, also require that all depending packages go to volatile, even the depends are unversioned. Does the clamav interface change between versions? If not, would it be possible that a sufficiently stable version will be included in stable and updates (including new versions) be handled via volatile - including a large note in the clamav package to include volatile. Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
Stephen Gran wrote: This one time, at band camp, Martin Schulze said: Michael Tautschnig wrote: In the clamav packaging team we had recurring discussion about how to deal with clamav in the near (== lenny) and more distant (= squeeze) future. The current situation is as follows: - We've got severly outdated clamav packages in etch(-security). - A few packages depend on clamav; those depends are not necessarily versioned. - Any sensible use of clamav requires the packages from volatile to be able to handle all features of upstream's current signature database. - We've had 16 security updates since the release of etch, which constantly required backporting of upstream's fixes that were included in the volatile releases. We could of course continue this game of telling users that nothing but the clamav from volatile is what one should use on production systems, but maybe there are other options as well. Let me see what options we have: - Stick with the current scheme. Possible, but neither user- nor maintainer-friendly. - Move clamav to volatile only. This would, however, also require that all depending packages go to volatile, even the depends are unversioned. Does the clamav interface change between versions? Yes, clamav had several soname changes during the etch release, and several configuration and command line options changed. I don't think we can depend on it staying stable during lenny. *sigh* If not, would it be possible that a sufficiently stable version will be included in stable and updates (including new versions) be handled via volatile - including a large note in the clamav package to include volatile. That's roughly what we're doing now - try to get the most stable version we can into the stable release, and track changes via volatile. The downside for both users and maintainers is that depending packages frequently don't get updated for the changed clamav, leaving them performing poorly, or not catching new viruses, or both. The downside That's the same situation as it is now, right? Somebody needs to forward port reverse depends that require the old interface, it seems. However, getting these into volatile should be easier than getting them into stable (via proposed-updates). Having all of clamav and all revdeps in volatile would be an alternative but is probably not an option... for us as maintainers is that we have to support a version of clamav in stable that no one actually uses. I've done this for 2 releases now, and it always feels vaguely pointless by the end of the release cycle. I can feel your pain. Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: emacs22 22.2+2-5
Rob Browning wrote: I've uploaded emacs22 22.2+2-5 unstable which contains two bug fixes that I believe should be considered for Lenny. Please let me know if you would like me to do anything further. *sigh* Still no updated version of tramp included, so the current version in Debian still fills up /tmp with temporary files that are not deleted. Not even in sid. See Bug#482760. Regards, Joey -- ( ) go ahead, you can blog everything in this mail ( ) please don't blog the personal stuff in this mail ( ) this conversation never happened Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update
dann frazier wrote: On Sun, Jul 27, 2008 at 02:29:38PM -0400, Joey Hess wrote: I'm wondering who wrote: As linux-modules-extra-2.6-etchnhalf was not ready in time we decided to skip it for r4 and include it in r5. Frans Pop wrote: Well done folks. You've again managed to break at least part of the functionality of Debian Installer and, more importantly, left users with a potentially unbootable system after installation. fjp You can now partition using loop-aes encryption, but the modules are not available for the installed system. fjp So you cannot access any loop-aes encrypted partitions. fjp Or (hopefully) the installation will fail during finish-install. Well, it would seem we have the first peice of errata for the end of http://www.debian.org/releases/etch/debian-installer/etchnhalf How's this? Index: etchnhalf.wml === RCS file: /cvs/webwml/webwml/english/releases/etch/debian-installer/etchnhalf.wml,v retrieving revision 1.4 diff -u -p -r1.4 etchnhalf.wml --- etchnhalf.wml 15 Jul 2008 08:56:10 - 1.4 +++ etchnhalf.wml 27 Jul 2008 21:17:42 - @@ -175,6 +175,9 @@ release. h3 id=errata-r0Errata specific to qetch-and-a-half/q/h3 p -No known issues. +Partitions encrypted using loop-AES will not be accessable after installation. accessible? +This issue is due to the absence of loop-aes kernel modules for the etchnhalf ^^ caused by? +kernel. These modules will be made available in the next update of Debian +GNU/Linux 4.0, 4.0r5. ... and can be fetched from proposed-updates before.? Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-lighttpd] Bug#474951: Is a fix for etch planned?
Philipp Kern wrote: On Tue, Apr 15, 2008 at 08:39:03AM +0200, Pierre Habouzit wrote: Dear security team, you broke lighttpd badly with your last upload, because you use a broken patch to fix the last CVE on it. Please update the patch, using e.g. the one in the unstable version instead. You've broken lighttpd for almost 10 days, it's quite unacceptable to have a lighttpd in _stable_ in that state. Dear SRM team: would an upload to s-p-u be accepted if the security team still doesn't react ? As the current lighttpd distributed through security is utterly broken if you have SSL activated, of course I would accept an update through s-p-u. But I would be deeply disappointed about this is handled, too. Since it's broken on security.debian.org, it should be fixed there and passed through to s-p-u. Pierre, could you send the relevant patch to the security team for safety? Regards, Joey -- Experience is something you don't get until just after you need it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SRM] Please review apache2 2.2.3-4+etch3
Martin Zobel-Helas wrote: Hi, Considering that there is already an update pending for etch r2, and that CVE-2007-3847 is of similar severity as the issues fixed in 2.2.3-4+etch2, I think it makes sense to upload +etch3 to s-p-u, too. Martin Schulze agreed to this. Security team, please ack that. I acked this. Regards, Joey -- Everybody talks about it, but nobody does anything about it! -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch and kernels2.4
Michelle Konzack wrote: Am 2007-06-17 19:48:10, schrieb Pierre Habouzit: Then you have to stay with sarge. too bad. I think, you do not understand the problem IF someone is using the Stock Debian Kernel she/he can not upgrade to Etchm since ALL Etch-Kernels have SMP compiled in. It is realy bad from Debian to kick off its USERS. The MOST USERS do not know HOW to compile there OWN KERNEL since they are ONLY USERS. Fortunately, not many users have these broken cpus that don't work with the kernel Debian provides. It's unfortunate that you happen to maintain a swarm of them, but you can still build your own kernel and use it. Without people having such strange hardware helping maintain the Debian kernel, it cannot support such hardware. Regards, Joey -- Debian automatically detects USB sticks. This is so non-Debian. -- Joey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: desktop-base for etchr1
Fathi Boudra wrote: desktop-base for etchr1 was rejected. BTW, this is just a call to SRM team to know if Martin is alone to think desktop-base must be rejected ? Come on people! Can't you accept a decision others have to make? Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon 'maddog' Hall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please remove live-package from Etch
Holger Levsen wrote: Holger (who's also a stable ion3 user. Or rather, have been.) Isn't that an oxymoron qua author? Regards, Joey -- The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permission to upload a new hylafax package
Steve Langasek wrote: On Tue, Feb 20, 2007 at 02:55:41PM +0100, Giuseppe Sacco wrote: Hi all, hylafax 4.3.2 has just been released[1]. This is a minor update but fixes a few bug forwarded upstream and simplify the way Debian package may be done. The more important fix is that PAM will work again (it is somewhat broken on 4.3.1). FWIW, I've installed the new upstream version yesterday on a machine that ought to run hylafax and can conclude that it doesn't run worse than before. Also, some of the Debian patches have been included upstream. I'd consider this version suitable for etch, but it's your decision, of course. Regards, Joey -- GNU GPL: The source will be with you... always. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-mailman-hackers] Re: Planning for an upgrade path from etch to lenny for mailman
Thijs Kinkhorst wrote: On Tue, 2007-01-23 at 11:50 +0100, Martin Schulze wrote: Please keep in mind that the upgrade path from etch to lenny needs to work for etch r0 to lenny r0 as well. So I've understood, but cannot back this up with any documentation. Where is this documented? I'm curious as to the background of this requirement. I don't know if this needs to be documented. If it needs to, I guess that the developer's reference would be the proper document. Then the best would be to provide mailman2.1 in lenny and allow an upgrade from mailman2.1 to mailman2.2 *in* lenny. That's certainly possible, but would require (more than) doubling of the security support for mailman. We're quite motivated to prevent that where possible. It would be better without, but from what I read, this seems to be difficult. Regards, Joey -- Computers are not intelligent. They only think they are. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Planning for an upgrade path from etch to lenny for mailman
Lionel Elie Mamane wrote: It has just come to my attention that there will be no upgrade path from the version of Mailman in etch at this time (2.1.9) to the version lenny will most probably have (2.2.x), but there will be an upgrade path from the yet-unreleased 2.1.y, y9, to 2.2.x, and an upgrade path from 2.1.9 to 2.1.y. The reason is a fundamental file format change in how data is stored; mailman 2.1.10 will have an export binary that will export the data to a neutral (XML) format and Mailman 2.2 will have an import binary that will import that format. We can do the export in preinst and the import in postinst, but only if the package being upgraded from contains that bin/export/. (Shipping the said bin/export as part of the Mailman 2.2 package will be highly inconvenient; it is a python script that imports a significant part of Mailman itself; we'd have to basically ship a private copy of Mailman 2.1 in the Mailman 2.2 package.) My question is: Will you accept a freeze-exception update to mailman, or a point-release update to mailman later, to add the said bin/export to the etch package of mailman 2.1? Please keep in mind that the upgrade path from etch to lenny needs to work for etch r0 to lenny r0 as well. Even if we include the current version of bin/export (from their SVN repository, the 2.1.x branch) in the etch-mailman package, there is a non-zero risk that the said XML format will change and that we will need to update it in a point release of etch to ensure an upgrade path to lenny. Then the best would be to provide mailman2.1 in lenny and allow an upgrade from mailman2.1 to mailman2.2 *in* lenny. Regards, Joey -- There are lies, statistics and benchmarks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Erroneous upload of gnome-vfs2 2.16 to unstable
Loïc Minier wrote: I mistakingly uploaded gnome-vfs2 2.16 to unstable; it bumps shlibs and is incompatible with unstable's bonobo; it's not suitable for etch. First, sorry for this mistake. Second, here are the options: - upload bonobo 2.16 into unstable and upload updates via TPU until the release - upload an epoched gnome-vfs2 Now that this incident has happened, and assuming that we're short before a release, is there really a need to revert to 2.14 or something instead of continuing with GNOME 2.16? The packages in etch could still be updated via proposed-updates if they need to. PS: I didn't check gnome-vfs2's upload target as it was close to being a simple rebuild upload for experimental/i386 as we don't have a buildd there. I suppose I should work on introducing simple debian/rules checks in our experimental branch to fail when the target dist is unstable. Ouch! Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why is alpha a release candidate?
Thomas Bushnell BSG wrote: So the release criteria require buildd redundancy. And yet, half the release candidate archs still don't have it. It gets marked in yellow on http://release.debian.org/etch_arch_qualify.html. Well, the one-and-only alpha buildd has been down for apparently ten days and does not respond to ping, and I don't recall seeing anything from the alpha team on debian-release or debian-devel. Please correct me if this is inaccurate. The machine is currently being moved to a new location, fwiw. Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SSH upgrade problem
I upgraded a machine from sarge to etch and the process broke over ssh :(
Here's the log:
Preconfiguring packages ...
(Reading database ... 100606 files and directories currently installed.)
Unpacking openssh-client (from .../openssh-client_1%3a4.3p2-7_i386.deb) ...
Transferring ownership of conffile /etc/ssh/moduli ...
dpkg: error processing
/var/cache/apt/archives/openssh-client_1%3a4.3p2-7_i386.deb (--unpack):
trying to overwrite `/etc/ssh/moduli', which is also in package ssh
Aborting ownership transfer of conffile /etc/ssh/moduli ...
Unpacking openssh-server (from .../openssh-server_1%3a4.3p2-7_i386.deb) ...
Transferring ownership of conffile /etc/default/ssh ...
Transferring ownership of conffile /etc/init.d/ssh ...
Transferring ownership of conffile /etc/pam.d/ssh ...
dpkg: error processing
/var/cache/apt/archives/openssh-server_1%3a4.3p2-7_i386.deb (--unpack):
trying to overwrite `/etc/init.d/ssh', which is also in package ssh
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Aborting ownership transfer of conffile /etc/default/ssh ...
Aborting ownership transfer of conffile /etc/init.d/ssh ...
Aborting ownership transfer of conffile /etc/pam.d/ssh ...
Errors were encountered while processing:
/var/cache/apt/archives/openssh-client_1%3a4.3p2-7_i386.deb
/var/cache/apt/archives/openssh-server_1%3a4.3p2-7_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Only
DPkg::Options {--force-overwrite;}
in /etc/apt/apt.conf (or equivalent) helped.
Since I used apt-get and not aptitude and cannot repeat the process
since the machine is upgraded, I'm not sure this is an issue. It
might be that aptitude can cope with this better. So this is FYI.
I can open a bug report if you like.
Regards,
Joey
--
If nothing changes, everything will remain the same. -- Barne's Law
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH upgrade problem
Noah Meyerhans wrote: On Thu, Dec 28, 2006 at 06:11:28PM +0100, Martin Schulze wrote: I upgraded a machine from sarge to etch and the process broke over ssh :( I believe this was fixed by 1:4.3p2-8, which should be allowed to enter etch ASAP. Cool! Good to know that this problem is addressed. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#404888: glib2.0: cannot go into testing; causes gnucash regrsession
Josselin Mouette wrote: Le jeudi 28 décembre 2006 à 17:29 -0800, Thomas Bushnell BSG a écrit : On Fri, 2006-12-29 at 01:56 +0100, Josselin Mouette wrote: Now, if you don't provide us with the necessary data, we won't be able to fix the regression it introduces in gnucash. There are clearly two plausible solutions to the underlying problem: 1. Change gnucash to conform to the new behavior of glib, AIUI this has already been done, as gnucash doesn't generate such files anymore. 2. Change glib to conform to the existing expectations of gnucash. This is what I'm proposing to do. I don't think allowing the space character does much harm, but I'm asking upstream nevertheless. For the sake of the upcoming release, I wonder how many files / users are affected by this change? Is it really release-critical? If not, would it not helpe if Thomas provides a script in the gnucash package that adjusts the keys that are now broken and documents this ... err... change... in the release notes? Regards, Joey -- Of course, I didn't mean that, which is why I didn't say it. What I meant to say, I said. -- Thomas Bushnell Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security team's opinion
Andreas Barth wrote: Hi, there are two issues where I would like to ask you to comment on: - mantis: We have two requests to allow it in. Is this ok from your side? (No bug id, sorry - in case that not, could you please open an RC bug on mantis?) Why should the Security Team oppose a migration of Mantis? - mplayer: Bug #395252: Please depend on ffmpeg binary packages Can you please comment whether this bug has to be resolved prior to Etch? If I remember correctly, then a) it's not possible to switch mplayer to using the ffmpeg package unless i) the code is changed, and ii) the release team would allow the package with changed code to go into etch which could not be as well tested as before, and b) there is no stable API of ffmpeg, and maybe c) there's no shared ffmpeg library (?!?), and d) Moritz already okayed mplayer with its own ffmpeg for etch as an exception. I don't think the security is going to object to Moritz here. Regards, Joey -- A mathematician is a machine for converting coffee into theorems. Paul Erdös -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security team's opinion
Moritz Muehlenhoff wrote: On Tue, Dec 12, 2006 at 08:12:31PM +0100, Martin Schulze wrote: Andreas Barth wrote: Hi, there are two issues where I would like to ask you to comment on: - mantis: We have two requests to allow it in. Is this ok from your side? (No bug id, sorry - in case that not, could you please open an RC bug on mantis?) Why should the Security Team oppose a migration of Mantis? Because it has a _really_ poor security record (21 distinct vulnerabilities in the last two years!), which were extremely hard to fix, as upstream kept information hidden in inaccessible bugs and were thus unadressed for a long time. Is the version of Mantis in stable kicked out during a dist-upgrade? If not, users will stay with the old version and will probably be more harmed compared to if they would upgrade to the newer version. If mantis were anyhow important I would agree to still keep it, but given that it's a package with no significant user base (40 installed in popcon, probably less in production) it's just not worth the effort. That may be an argument. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a few comments on the release notes
Frans Pop wrote: On Thursday 16 November 2006 01:02, peter green wrote: 3: the restructuring of the ssh packages probablly deserves a mention in the upgrading section, if i'm not mistaken then upgrading a system with ssh installed but sshd disabled is likely to result in sshd enabled which could pose a security issue if passwords are weak. This seems not to be the case: an existing /etc/ssh/sshd_not_to_be_run will still be honored. Speaking of SSH, it may be worth mentioning in the release notes that HashKnownHosts is set on by default in the etch version and that this affects the way the known_hosts file looks like. Regards, Joey -- Given enough thrust pigs will fly, but it's not necessarily a good idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security support mozilla, php
Andreas Barth wrote: we have two bug reports against the release notes which should be discussed here: #390441: release-notes: Document unclear Mozilla security situation Mozilla and friends will be supported as long as their package maintainer are able to backport patches from upstream. Looking at sarge, this works sufficiently well at the moment. For details you should ask [EMAIL PROTECTED] #398437: Please add notice about PHP register_globals not security supported Please go ahead. I hope that no PHP installation we currently provide has it turned on. Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: user-mode-linux too [was: Re: apache2 DSA considerations for etch]
Mattia Dongili wrote: On Tue, Nov 14, 2006 at 08:06:38AM +0100, Joey Schulze wrote: [...] *sigh* That would've been the best solution. I'd say this is ok, however, please watch security updates as the security team will probably forget to update apache2-mpm-itk when apache2 has been updated. (-Murphy) Ehrm... while we are at it I suppose user-mode-linux deserves a similar treatment as it builds from linux-source-* packages. Can't they use the regular kernel packages? Or let's phrase it differently, why can't the regular kernel package create another flavour for uml? Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Wouter Verhelst wrote: I think the best way forward at this point in time is to create our own release, as you suggest, very much like what amd64 did for sarge. On the August 16 birthday party in Breda, I discussed this with Jeroen Van Wolffelaar who told me that in theory, it should not be very hard to create a suite in dak to allow us to have a mostly-etch distribution; In theory a lot more should be possible. My fear is that even when it shouldn't be too difficult it can still take a long time until ftpmasters implement the required changes. I'd rather be sure the code is there before the release of etch so m68k-etch can be release right afterwards. one that is only slightly different from the 'real' etch. Given their track record, I suspect (though I haven't asked) that the security team would not object to supporting such a release. Given that - the differences in packages are only minimal - it's not problematic if there are packages missing - there's enough buildd power connected to the archive to build security updates - there's a chance to update the stable m68k releases wrt. point releases In general, let it be like stable, then it's fine. Regards, Joey -- It's time to close the windows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Frans Pop wrote: On Monday 18 September 2006 09:18, Frans Pop wrote: * Installation Guide Add note in the introduction that m68k is not officially supported. Otherwise the same as d-i: continue building and uploading into unstable. I'd suggest to just keep the development version available on alioth [3]. Should have thought a bit longer about this... The installation-guide is an arch:all package. This means that if it is built, the m68k variant will become available in Etch. Something else to consider is that a lot of the links (e.g. from where to download images) will be incorrect. Mainly for this reason I would suggest disabling m68k for official builds, but still keep the development builds on Alioth. Couldn't an exception be programmed into the installation guide? Regards, Joey -- There are lies, statistics and benchmarks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (I)
Matthijs Mohlmann wrote: Hi, What about #375494 and #377047, those are security bugs in the current stable distribution (Sarge) and according to the Security Team it didn't warrant an upload. Although it has a CVE so I think it's worth an upload to stable. The first one doesn't look like a real security problem. And the second one is just a copy of the first one. Regards, Joey PS: Please make use of linebreaks -- Have you ever noticed that General Public Licence contains the word Pub? Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (I)
Holger Levsen wrote: On Saturday 16 September 2006 08:50, Martin Schulze wrote: The first one doesn't look like a real security problem. Please explain why you think that putting arbitrary long strings into fixed sized buffers is not a security problem, preferedly in the bugreport. Please explain how an attacker can exploit this and force slapd to put arbitrary long strings into fixed sized buffers. Precondition: Requiring either root permissions or LDAP admin permissions don't count. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge - Etch upgrade issue
Alexander Schmehl wrote: * Steve Langasek [EMAIL PROTECTED] [060908 01:46]: 1) sarge: 1.1) apt-get dist-upgrade - upgrading to etch [..] Yes, I can see that apt Recommends: debian-archive-keyring and Suggests: gnupg. Given that apt should be doing secure archives by default now, the Suggests: seems like the wrong relationship; I think this warrants a bug on apt, no? Shouldn't the Recommends: debian-archive-keyring be enought? AFAIK the Release Notes recommend using aptitude instead of apt-get. And aptitude respects recommends should pull in debian-archive-keyring, which depends on gnupg. The release notes for sarge recommended aptitude over apt-get due to some strange problems with apt-get alone. Will this still be the case for etch or rather the sarge - etch upgrade? Regards, Joey -- The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Meeting Minutes from the latest SRM meeting
Martin Zobel-Helas wrote: - Time based release: We spoke about the idea of a time based release for r4. Anthony and Julien think it is a too short time frame, but we should try this experiment, and the speak with cd-vendors after r4, so we get better impression. Release date of r4 set to ~16th of October. What do you want to achieve with talking to CD vendors? They'll need at least half a year between updates so that they can produce cheap and sell their sets. This collides with the Debian goal to let updates flow into the stable releases after a not too long time. You can't achieve both goals. When you talk to CD vendors, please don't emphasize on r* at all. These should merely small updates and not a reason to restart producing CDs/DVDs again. Only when the vendor needs to produce a new disk set they should use the most recent images from Debian. - Point-Releases for oldstable: We talked about point releases for oldstable. Martin is willing to do that with beginning of etch=stable. Anthony stated that this needs to be implemented on dak side, but is straightforward, though. Details of this point were skipped for this meeting however. Finally... That would be great. Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge - Etch upgrade issue
Ingo Juergensmann wrote: Joey asked me to forward this to here, so here it is: When upgrading sarge to etch, apt-get complains about untrusted source of packages because gnupg isn't installed during apt-get dist-upgrade. After manually installing gnupg apt-get update everything seems fine... It may be worth considering to add a Dependency against GnuPG to apt when apt complains if no gnupg or no keyring has been found on the users system. Alternatively, it may be worth considering to alter the default setting of apt so that it will accept packages from untrusted source - i.e. from official Debian mirrors. Maybe by adding // Comment this out to only accept packages from authorised // sources. See apt-key(8) for details. // APT::Get::AllowUnauthenticated true; to /etc/apt/apt.conf (or use a single file in apt.conf.d) Regards, Joey -- The only stupid question is the unasked one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secure APT Key Management
Andreas Barth wrote:
Hi,
I try to summarize the results of the discussion from start of August,
in hope that we can finish this off, and test-run this first for the
next stable point release. From the security team, some input on their
preference would be welcome.
The idea is to have different keys:
- One standard online-key for signing unstable; this key would be
rotated e.g. yearly (or whatever the ftp-masters consider fit, I don't
really mind).
- One release key per stable release; taken care offline by the stable
release team.
- One security key per stable release; taken care somehow by the
security team.
Umh... you know that currently the security team has no authority
over the use of any gpg key during the release of security updates,
right? So, this seems to require modifications in the archive
software (and there are several issues pending for years already).
The same most probably applies to the SRM key/team.
Apt in stable recognizes as valid:
- The current stable key
- The previous stable key
- The unstable key
How do you propose the key rollover with the unstable key to be
recognised by the stable apt?
Stable Releases is signed off by:
- The current stable key
- The previous stable key
- The unstable key (perhaps also by the previous/next near to a
rollover)
Security Releases is signed off by:
Out of curiosity, what is a Security Release? Every security update?
- The current security key
- The previous security key
Why not the current stable security key?
(and the previous stable security key, you've introduced them above
at least).
I'm not sure what a different security key buys us except another
set of keys to handle, especially when the key is only known to
the dak operator and the dak software.
- The unstable key (perhaps also by the previous/next near to a
rollover)
Stable release keys (and perhaps also security keys, depending on the
security team) don't have expiry dates, but are expired with publishing
a revocation certificate with stable+2 (as we still need the key for
stable+1 for upgrades).
When there are stable security keys, they should have an expiration
date set (high enough so that Debian has enough chances to update
their distribution as releases in the meantime).
When there is only one security key, it's not clear to me what
an expiration buys us. A way is required to get new key to the
user in case of a compromise and to revoke the old one.
So, if someone upgrades e.g. from sarge to etch (just using them as
names now, ignoring that sarge doesn't contain such an apt):
Client runs sarge - authoritative are woody, sarge, expired old sid key
... when the key is expired, it's not useful anymore, hardly
considered as authoritative...
Client gets etch-Release.gpg from mirror (signed off by sarge, etch, sid)
new sid key
Client verifies etch-Release.gpg with sarge key
Client installs new packages - now authoritative sarge, etch, sid keys
(and installation contained a revokation for the woody key).
How? Where?
Regards,
Joey
--
Linux - the choice of a GNU generation.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mailman 2.1.5-8sarge3: screwup between security and maintainer upload
Lionel Elie Mamane wrote: let a be an architecture in sarge. Then one of the following holds for mailman in sarge r3: - it is affected by a security problem. - it has a severity critical bug. Mailman in sid: - may or may not suffer of a security problem A security problem in Mailman in sarge patched in May has _not_ been issued a DSA. Oh. Which security problem are you talking about? There seems to have been a screw-up in handling of mailman security and stable updates: There are two different mailman packages in Debian with version number 2.1.5-8sarge3. Ugh? How did that happen? Where is the second one? I only see 2.1.5-8sarge3 in stable but only 2.1.5-8sarge2 in the security archive. History, in chronological order: -8sarge2 security update to fix: potential DoS attack with malformed multi-part messages (closes: #358892) [CVE-2006-0052] -8sarge3 maintainer update (that got frozen waiting for -8sarge2 to happen in order not to conflict with it) to fix bug #358575, a severity critical bug. Uploaded to stable-proposed-updates in the night from 11 to 12 April 2006, where it created problems because -8sarge1 was to be going in sarge r2, and having -8sarge3 appear confused everything. Stable update team says something along the lines of will consider for sarge r3. Apparently it has been installed in the archive. -8sarge3 security update to fix: formt string vulnerability [src/common.c, debian/patches/72_CVE-2006-2191.dpatch] That security update has not been announced by a DSA, and cannot be downloaded from http://security.debian.org/pool/updates/main/m/mailman/ . I don't have access to the source of this package. It was apparently prepared by Martin Joey Schulze on 13 May 2006. Umh? But where is it? I don't have it either. I have recorded the patch to fix this vulnerability, though. It's attached. As a maintainer of Mailman, I have no recollection of being notified of CVE-2006-2191 (it is possible I have missed the notification, but my email archives do not contain anything relevant with subject mailman and 2191 in the body); the CVE entry at mitre.org contains no information. I have no idea whether this security problem affects the version in sid or not, I have no precise information _what_ this security problem is. I found a trace. Apparently this problem has been considered not exploitable later, and hence the issue was disregarded. The researcher was Karl Chen. He suggested to file a normal bug then. If that has happened, you should have (had) it in your bug list. The situation right now: - sarge r3 contains mailman 2.1.5-8sarge3, but some architectures have the security update (such as i386) and others have the maintainer update (such as source, sparc and alpha). Thus all architectures are screwed up in one way or the other. AARRRGGG! This is an interesting screwup... So, please, security team, tell us about CVE-2006-2191. If appropriate, issue a DSA about it, for a package under version number -8sarge4, built on top of -8sarge3 the maintainer update. Please give us (the mailman-in-Debian maintainers) the information needed to fix CVE-2006-2191 in sid, or make a retroactive note in the changelog to note when it was fixed by a new upstream version. I'll forward you the mails wrt this issue. Guess we didn't contact you earlier because it became a non-issue. Stable release team, please react accordingly; you may for example do a binary sourceless NMU for the architectures that have -8sarge3 the security update so that they all have -8sarge3 the maintainer update. Imho, it's more useful to upload 2.1.5-8sarge4 and only bump the version number to get the new version built for all architectures into the archive. Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preparing the next Release
Hi, in private Steve and I discussed some release issues, and we both agreed that (a) our output is public and (b) it should happen in public, so here it is dragged into the public. Steve wrote: Broad categories of release-critical bugs that exist today: - packages that FTBFS - security bugs - data loss bugs - packages that violate the DFSG as understood by the project today - bugs related to removal of obsolete libs - trivially broken maintainer scripts - packages that are badly put together to the point that the whole package, or a major component of it, is unusable Steve Langasek wrote: On Wed, Aug 30, 2006 at 07:44:27AM +0200, Martin Schulze wrote: These bugs are at least to be investigated and maybe resolved in a rather pragmatic way: - packages that FTBFS . on which architecture? As long as it's a release architecture, does this matter? Doesn't the security team still typically wait for a security update to be built on all archs before releasing it? I'm not sure if it makes sense to reply to each of your paragraph, since you're the one to decide anyway, not me. However, I believe that such questions need to be raised and investigated in time, and maybe some packages need to be dropped from the release or from particular architectures. With regards to security support, all packages that the security team needs to support must to be compileable by the buildds for all architectures they were released for. When there is no cups for amd64 in the release, it does not matter whether it FTBFS on amd64 or not, for example. If a package FTBFS on one architecture, it (or rather an oder version) must not be released with this architecture, though. Being unable to fix security bugs in such packages is one reason, potential license violation by not shipping the proper source package would be another reason not to do so. While I would love to have the exact set of packages on all architectures, I need to accept the fact that on some architectures some packages just don't work or cause an FTBFS we are unable to fix in time for the release. . how widely is it used? Again, does this matter for questions of RCness? (If you mean is it ok to remove the package instead of fixing it, this is already a judgement call the release team makes.) I believe that it does matter. You're explanation in brackets imply that you're already working as I suggested. Fixing the problems should have a higher priority than removing a package. However, when either nobody cares about a fix or it is not possible to fix the problem in time, a removal may be warranted. . how likely will we have to recompile it? Do you have a formula for easily determining the probability of a security hole being discovered in any arbitrary package over a given period of time? If so, please share it! Follow-up question, what is the threshold below which it's sufficiently unlikely for a security hole to be found that the security team volunteers to accept responsibility for the FTBFS bug as well in the event a security bug *is* found? No, I don't have. I could add a question about the possibility to run remotely provided data by this package? Whether the program runs under the user id of the normal user or is privileged in any way. It's very difficult to measure, I admit. - data loss bugs . data loss always or only in some esoteric situations? Do you think it should be ok for packages to lose users' data only /some/ of the time? I don't, FWIW... Well, we've already had packages that can potentially use data when you use three quite uncommen switches, two undocumented commandline switches, one broken config line and the system has three processors with a permanent load of 53. This is a bit exagerated, but I hope you'll get an idea of what I was trying to express. When the data los *can* happen in only certain quite uncommon circumstances and the rest of the system and of the package works fine, I'm not too sure we should delay the release to get this problem fixed before. Especially since the problem exists for n months already without the hell being frozen. Such problems usually warrant an inclusion in a point release, so can be fixed after the release as well. . could we accept that this package has a bug and keep it buggy in etch? What's the point of including it in a stable release if we know it'll eat user data? Honestly, shouldn't we have more pride in our stable releases than that? Please read above. If it only happens or can happen in some very rare situations, what's the point of delaying the release? This could still be fixed in a point release. It's better not to release etch with such bugs, however, are they all really worth being able to delay a release? - bugs related to removal of obsolete libs . how widely is it used? . can the package be removed without hurting the overall system? . can the package be removed
Re: Preparing the next Release
Steve Langasek wrote: Another transition that today is in an earlier stage is the mozilla-xulrunner transition. I've asked on #debian-release what people thought should be done if seamonkey isn't packaged in time for etch -- should mozilla and all its reverse-deps be dropped because it's not security-supportable, or should they be kept rather than removing what's still a large number of packages with a large install base? Does the answer to this question change with the number of reverse-dependencies still remaining? Since for Mozilla it has already be announced that it's end has reached, it should be removed. Regarding security support in case it it will still be shipped with etch, Alex Sack needs to be contacted since he's doing all the work. There's still Firefox and Thunderbird, so similar codebases. Speaking of being ready for a freeze, I would consider this date generally reached already. Most of the packages are in a considerably fine state. There are still problems, though, but there will always be problems anyway. When the installer is working fine on all release architectures and the kernel and udebs have been migrated into testing as well, we already have a *pretty* *good* system. I think the main obstacle to freezing right now is the firmware question, really. If the project decides that etch should be deferred until sourceless firmware blobs are out of main, then it doesn't make sense to start freezing yet. Well, if the project decides that this issue must not be ignored for the sake of etch, then we don't have to talk about a release anytime soon anyway. That'd annul a lot of currently ongoing discussion. Regards, Joey -- Everybody talks about it, but nobody does anything about it! -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (I)
Kevin B. McCarty wrote: Second, is it planned to include the next round of security updates to the Mozilla family by Alexander Sack? (cf. [0] [1]) For some reason these don't seem to have gone into security.d.o yet and it would be very nice to ship mozilla* packages that are up-to-date with security fixes. They are still building. Although I'm not speaking for the SRM anymore, they have to draw the line at some date after which no updates are possible anymore or they won't be able to update stable at all, because there are always some security updates in preparation. Third, please note that even if those updates don't get into Sarge r3, the existing mozilla-thunderbird security update needs a bin-NMU on i386 [2]. Eeks. In case somebody is working on an NMU, please get in touch with the security team so that it doesn't annulate the upcoming security update. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HAL needed by Konqueror in kde-desktop
Stephen Frazier wrote: I installed ETCH from Aug 21 businesscard iso. My preseed file selects tasks standard, kde-desktop. When I tried to open a floppy disk with Konqueror it issued a message saying that HAL was needed. I installed HAL using aptitude and after rebooting Konqueror was able to open the floppy disk. I think HAL should be added to the list of package that are installed by tasksel when kde-desktop is selected. Maybe there's also a dependency missing in the konqueror package. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (I)
Rene Engelhard wrote:
Martin Zobel-Helas wrote:
Accepted Packages
-
These packages will be installed into the stable Debian distribution
and will be part of the next revision.
[...]
freetype2-demosstable2.1.7-2.4 alpha arm hppa i386 ia64 m68k mips
mipsel powerpc s390 sparc
freetype2-demosupdates 2.1.7-2.5 alpha arm hppa i386 ia64 m68k mips
mipsel powerpc s390 sparc
freetype stable2.1.7-2.4 source
freetype updates 2.1.7-2.5 source
libfreetype6-dev stable2.1.7-2.4 alpha arm hppa i386 ia64 m68k mips
mipsel powerpc s390 sparc
libfreetype6-dev updates 2.1.7-2.5 alpha arm hppa i386 ia64 m68k mips
mipsel powerpc s390 sparc
libfreetype6-udeb stable2.1.7-2.4 alpha arm hppa i386 ia64 m68k mips
mipsel powerpc s390 sparc
libfreetype6-udeb updates 2.1.7-2.5 alpha arm hppa i386 ia64 m68k mips
mipsel powerpc s390 sparc
libfreetype6 stable2.1.7-2.4 alpha arm hppa i386 ia64 m68k mips
mipsel powerpc s390 sparc
libfreetype6 updates 2.1.7-2.5 alpha arm hppa i386 ia64 m68k mips
mipsel powerpc s390 sparc
DSA 1095 freetype - fix several vulnerabilities
Uh, that's bad. -2.5 is broken. See http://bugs.debian.org/libfreetype6.
Unfortunately still no DSA which corrects the broken packages caused by
the first DSA...
There's not going to be any due to ongoing conflicting actions by the
security team and the maintainer. Attached is my last trial to get
this fixed. Feel free to pass this through proposed-updates.
Regards,
Joey
--
Those who don't understand Unix are condemned to reinvent it, poorly.
diff -u freetype-2.1.7/debian/changelog freetype-2.1.7/debian/changelog
--- freetype-2.1.7/debian/changelog
+++ freetype-2.1.7/debian/changelog
@@ -1,3 +1,19 @@
+freetype (2.1.7-3.1) stable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Rebuilt with higher version number
+
+ -- Martin Schulze [EMAIL PROTECTED] Fri, 18 Aug 2006 17:06:28 +0200
+
+freetype (2.1.7-2.6) stable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Adjusted the patch to fix integer overflows to catch negative and zero
+values as well, thanks to Wolfram Gloger [EMAIL PROTECTED]
+[debian/patches/400-CVE-2006-2493_integer-overflows.diff, Bug#373581]
+
+ -- Martin Schulze [EMAIL PROTECTED] Thu, 17 Aug 2006 09:15:31 +0200
+
freetype (2.1.7-2.5) stable-security; urgency=high
* Non-maintainer upload by the Security Team
diff -u freetype-2.1.7/debian/patches/400-CVE-2006-2493_integer-overflows.diff
freetype-2.1.7/debian/patches/400-CVE-2006-2493_integer-overflows.diff
--- freetype-2.1.7/debian/patches/400-CVE-2006-2493_integer-overflows.diff
+++ freetype-2.1.7/debian/patches/400-CVE-2006-2493_integer-overflows.diff
@@ -77,12 +77,15 @@
#include rasterrs.h
-@@ -175,6 +176,9 @@
+@@ -175,6 +176,12 @@
bitmap-rows = height;
bitmap-pitch = pitch;
-+if ((FT_ULong)pitch LONG_MAX/height)
++if ((FT_ULong)pitch LONG_MAX/height || height = 0)
++{
++ error = Raster_Err_Array_Too_Large;
+ goto Exit;
++}
+
if ( FT_ALLOC( bitmap-buffer, (FT_ULong)pitch * height ) )
goto Exit;
signature.asc
Description: Digital signature
Summary: Secure APT Key Management
Last week I started a discussion[1] to find out the current status of key management in Secure APT which is a release goal for etch and said to be included in the next release of Debian. I don't find the situation terribly promising, though, but here's a summary, so we may come to a solution some day. 1. http://lists.debian.org/debian-release/2006/07/msg00192.html Does one of the proposals below meet the requirements of ftpmasters? If not, what would be their preferred implementation? Secure APT will cause a lot of trouble if key management is troublesome and bound to fail right after the release of etch, when the next key rollover is due to happen, or one year later. Goswin von Brederlow asked[2] ftpmasters to store the public signing keys next to the signed file to have a standardised place where keys for any apt-getable archive can be found. 2. http://lists.debian.org/debian-release/2006/07/msg00193.html Martin Krafft pointed out[3] that there is too much danger of man in the middle or DNS-poisoning attacks for automatic upgrades over the network of keys to be trusted automatically, unless Debian starts using SSL. 3. http://lists.debian.org/debian-release/2006/07/msg00194.html The way he envisions key management is that every Debian machine trusts the SPI CA. Debian should provide a webpage for downloading and verifying keys, protected by SSL/TLS. The use would require easy-to-use tools to install these keys, and proper error messages from APT that will make it obvious what to do. Florian Weimer stated[4] that the only approach known to work is static keys for stable releases and stable security updates. The keys can be stored off-line or on-line, at the discretion of the respective teams. He pointed out that we have botched all yearly key rollovers, and that there is zero evidence that we'll get the first one that reallly matters right. 4. http://lists.debian.org/debian-release/2006/07/msg00201.html Joey Hess added[5] that the last date at which key management can be added/included in the installer will be the final build of d-i initrds, which is going to happen on Wednesday, October 18th, 2006. However, I believe that this would be way too late in terms of code maturity and proper tests. 5. http://lists.debian.org/debian-release/2006/07/msg00202.html Raphaël Hertzog suggested[2] to use two signatures, one from a yearly key and one from a stable release key. The user can decide on their own to trust either a yearly key only or the release key only, and omit a key rollover. The release key could also be stored offline which will reduce[7] the likelihood of being compromised. 6. http://lists.debian.org/debian-release/2006/07/msg00212.html 7. http://lists.debian.org/debian-release/2006/07/msg00221.html Regards, Joey -- Let's call it an accidental feature. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to cleanly get rid of exim 3 for etch?
Marc Haber wrote: (2) Update exim3 with the warning message in sarge via s-p-u and a point release. If this is a required step upon the upgrade/removal, then your path is flawed. You cannot expect all users who upgrade from sarge to etch to have the most recent updates installed. There are a lot of machines out there that aren't updated against ftp.debian.org, many aren't even updated against security.debian.org. Regards, Joey -- Let's call it an accidental feature. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secure APT Key Management
Raphael Hertzog wrote: I'd really love to see this feature properly implemented. The only approach which is known to work is static keys for stable releases and stable security updates. The keys can be stored off-line or on-line, at the discretion of the respective teams. So far, we have botched all yearly key rollovers, and there is zero evidence that we'll get the first one that reallly matters right. Unfortunately, the key rollover approach is generally assumed to be required to achieve a decent level of security and strongly preferred over the alternatives. Needless to say, I very strongly disagree with that position. Why don't we put two signatures ? One from a yearly key and one from a release key. The release key could also be stored off-site on a floppy/cd/usb-stick and only be used when when the released release is updated (i.e. when a point release is made). This reduces the chance of this key to be compromised, since it wouldn't be stored on the net as updates are only done very infrequently. Regards, Joey -- Let's call it an accidental feature. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Secure APT Key Management
According to the last release update the key management issue for Secure APT is not yet resolved. Are there chances to get key management settled down before the release? It would really be a shame if we couldn't get this done and provide the user with a proper infrastructure. This requires collaboration between ftpmaster, release team and apt developers, I guess. Is there a place where the relevant issues are discussed so that a decision can be made and a solution can be implemented *in time*? I'd really love to see this feature properly implemented. Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for public announcement for the next release update
Moin! Andreas Barth wrote: just two things: First, I think the release team has the right to send out texts to debian-news on his own. Why didn't you approve our mail? I'm considering to ask the mailing list admins to give us direct permissions to post to that list. I don't think so. I didn't think the mail was suitable for the list as is, which is why I took the liberty to start from scratch and phrase it properly (imho) based on the detailed mail and information Marc sent to the -devel-announce list before Second, though I really welcome more announcements about the release of Etch, please wait until you get an ok from a release team member, I would have, if you and Marc wouldn't have whined so much before and gotton onto my nerves. That left me with the impression that this issue is so pressing that I must not delay it any further and send it out as soon as I consider it suitable. I'm sorry if I have gotton a wrong impression. In and ideal world, we would work *together* and not work after each other. I would much prefer to do that. Unfortunately, this is the second time something like that happens, and it has happened exactly after the same receipe. You prepare an announcement, whine about it, adding pressure to me, so that I send it out without enough time for re-confirmation, and then you're not happy with the result either. especially if you create your text in such a short time periode (and both Marc and I were away via the weekend). It might help to Cc debian-release for such input. Also, as you know, you could try to call The input was taken from the announcement sent to -devel-announce. If that should be wrong, I wonder why it has been sent there before. Marcs version of the public announcement even linked to that mail. I don't understand why you're upset now. me on my mobile phone if you need urgent input. I'm really very Since the input was taken from your (i.e. Marcs) announcement, there was no need for urgent input. I've sent you both a mail with a question, though. Its answer could've changed the announcement but it wouldn't have been important enough to add pressure on your or anything. I hope we can work *together* in the future. Joey -- Long noun chains don't automatically imply security. -- Bruce Schneier Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security fix for shadow in sarge (#356939)
Christian Perrier wrote: As a consequence, I hereby ask the security team to DROP the processing of the 4.0.3-31sarge6 version you have. As you wish, packages deleted. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CVE-2006-2314: debian dovecot package vulnerable. (fwd)
martin f krafft wrote: I tend to agree with Joey on the issue, though I do think it's not very nice that the postgresql security upgrade breaks other packages. But going via stable-proposed-updates seems like the right path. Have you talked to the stable release team? Maybe they'd be willing to let it into the next update? I'd say... Maybe... Just maybe... Did it ever occur to you that this may be the reason Jaldhar asked on debian-release, the list the stable release team confirmed as a requirement for uploading to proosed-updates? Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Postgresql-related updates
Moin! DSA 1087 introduced a stricter parsing of specially encoded data streams in postgresql. Martin Pitt pointed out that psycopg and python-pgsql still use \' for '-encoding instead of '' which is the only accepted encoding after installing this security upeate. Hence, both package should probably be updated in the next point release so that their valid encoding of an invalidly encoded stream does not result in a postgresql error but will be accepted. Martin Pitt was so kind and provided patches for both packages which are linked to in the respective bug reports. For psycopg this is Bug#369230 and for python-pgsql this refers to Bug#369250. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release updates and the general audience
Andreas Barth wrote: the target group for our release updates are our developers. However, we have seen in the past more than once journalists picking up the release update and writing articles about them. Not only once there have been slightly suboptimal stories, e.g. with overemphasizing some issues (which might happen because we basically present a patch, whereas journalists like to have a that's the new status as well, especially if they're not too deep into the topic - something I could understand). Now, I was phoning was someone from Heise about this. He told me that they might be able to produce better articles if they have more time, and they would have more time if we forward such articles to Heise directly. He also suggested to add phone numbers or so for questions, so that misunderstandings could be fixed before anyone in the public even sees them. Basically, this is something I would like to do. My question is just: How do we do that best? Should the release team also post a small story to debian-news at the same time (and suggest all journalists to subscribe to debian-news also)? Or anything else? And, how do we make sure we're available for questions in short time? Which address should we consider journalists for contacts so that they can e.g. be given out a mobile phone number to call to? Naturally, journalists should be subscribed to debian-announce and debian-news. If the release update is something significantly new and dedicated to the public instead of our own developers (and maybe testing users, prospective developers, interested users etc.) it may be discussable to send the update to debian-news instead. I guess, however, that this would have to be decided on a per-issue basis. Re phone numbers: the press releases mostly contain a phrase who to mail for more details. Usually this works and people get directed to people more knowledgable on that particular issue. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Postgresql-related updates
Martin Schulze wrote: DSA 1087 introduced a stricter parsing of specially encoded data streams in postgresql. Martin Pitt pointed out that psycopg and python-pgsql still use \' for '-encoding instead of '' which is the only accepted encoding after installing this security upeate. Hence, both package should probably be updated in the next point release so that their valid encoding of an invalidly encoded stream does not result in a postgresql error but will be accepted. Martin Pitt was so kind and provided patches for both packages which are linked to in the respective bug reports. For psycopg this is Bug#369230 and for python-pgsql this refers to Bug#369250. Martin also provided a patch for dovecot in Bug#369359, which would only apply if the admin allowed ' as part of the username (which is turned off by default). I don't think this warrants an update to sarge, but I'm not the one to decide, so here's the information for you to judge. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Preparing for update in stable
Andreas Barth wrote: The main problem is going to be testing the new images as it will not be possible to run an installation and download kernel udebs from s-p-u and other udebs from stable. The question is however: should we try to keep the old udebs in stable also? Are they not overwritten by the point release? Or should we try to change stable so that we have two versions of the udebs in stable? I fear that they need to be kept since otherwise a lot of installation media that are currently used would get suddenly wrecked. I guess that it may be a good idea to implement something like a public morgue for these udebs for etch and its successors in that the installer is able to look into a second (morgue) directory for the udebs it requires for installation if they can't be fetched from the main source (main archive). Regards, Joey -- GNU GPL: The source will be with you... always. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The powerpc port should be removed from etch release candidates ...
Sven Luther wrote: I have seen Frans claim various times about patches and changes i was proposing that it will never be applied anyway because i proposed it, and he didn't thrust me. Do you really thing that in the light of this me sending in patches just to have them rote in the BTS is valable ? world+dog has svn access to the d-i repo, why then did they remove me from it ? Does somebody see a connection between your last question and the first question of the paragraph quoted? Regards, Joey -- GNU GPL: The source will be with you... always. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge upgrade - linux, grub conflict
Bastian Blank wrote: On Tue, Apr 18, 2006 at 05:04:53PM +0200, maximilian attems wrote: waldi why not add your patch to update-grub to the next stable release? Please keep in mind that you can't rely on a current sarge installation when it is upgraded to etch, in other words, you can't depend on people keeping their sarge r0 up-to-date with newer revisions or security updates. Especially for offline installations that are only maintained via ready CD/DVD images this may be the case. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libapache2-request-perl security upgrade broken
Martin Zobel-Helas wrote: When trying to upgrade to the latest libapache2-request-perl (2.04-dev-1sarge2) I've got a broken dep on perl = 5.8.4-8sarge4, but perl 5.8.4-8sarge3 only is available. Following Joey's piece of advice, I'm contacting you on that matter. He remarked that perl 5.8.4-8sarge4 is the one in proposed-updates... This is a bug introduced by the security team. There is nothing the stable release team can do about this but only release the next stable point release in near future. I read the developers reference where it says: Build the package on a clean system which only has packages installed from the distribution you are building for. as Do only build packages within a stable enviroment. If the security team uses additional resources to build their packages, their fault. FWIW: The package has been built by a build daemon. That's nothing the security team controls. They can not even been sure that packages in proposed-updates will be in the next stable point release. So, please go and ask the security team to update that package again. That won't help. Quick investigation: Affected architectures: alpha arm i386 mips mipsel s390 sparc Unaffected architectures: amd64 hppa ia64 m68k powerpc Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian history?
?? wrote: I wanna debian history if exist summarize debian history infomation ttp://www.debian.org/doc/manuals/project-history/ http://cvs.infodrom.org/calendar/calendar.infodrom.debian Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon 'maddog' Hall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kaffeine in Debian unstable
Jordi Pina Estany - Pinucset wrote: Hi, I'm here for asking if it's planned to enter Kaffeine in Debian unstable. Is there somebody working in it? Errm... Is anything wrong with the current packages? kaffeinestable0.6-1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source kaffeineunstable 0.7.1-1.3 m68k source kaffeineunstable 0.7.1-1.3+b1 alpha arm hppa i386 ia64 mips mipsel powerpc s390 sparc Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timeline for next kernel update round
Martin Zobel-Helas wrote: Hi Moritz, On Wednesday, 15 Mar 2006, you wrote: Frans Pop wrote: On Wednesday 15 March 2006 00:15, Moritz Muehlenhoff wrote: The update is built and tested, it'll appear soon. It contains three ABI changing security fixes, so the ABI will be bumped. I can't speak for d-i. i had some discussion with Frans Pop today and we agreed that it might make more sense to have a new sarge d-i with R3 rather than R2. That's also due to the fact that he can't tell me how long it might take to build new sarge based d-i packages. (spoke about 2-8 weeks). So my plan would be, as soon as we get the remaining issue for R2 fixed (which i expect within the next 2 weeks), we then go without new kernels in R2 and then have R3 a few weeks later (4-8 weeks), then with new kernels and new d-i. Do you think this sounds reasonable for the security team? Yes. Regards, Joey -- Never trust an operating system you don't have source for! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Status of PowerPC64?
Dear Release managers and assistants, what is the current status of the inclusion of a powerpc64 architecture? Are there plans to include it in the archive? If so, for when is the inclusion planned? Or, what's the current status of the port as perceived by you. Is the port official and grown-up enough for Debian to maintain 64bit powerpc machines? Regards, Joey -- Long noun chains don't automatically imply security. -- Bruce Schneier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#349396
Mario Joußen wrote: Hi, I fixed the RC bug #349396 of affix-kernel with my last upload to unstable. Since the package in Sarge is unusable also, I want to update this package as well. Is this okay? Please go ahead. If it is okay, what is the correct distribution? stable or stable-proposed-updates? Distribution is stable The version should be . 2.1.1-2 iff you're the maintainer and this version hasn't been used yet . 2.1.1-1.2 iff you're not the maintainer and this version hasn't been used yet . 2.1.1-1.1sarge1 otherwise (or 2.1.1-1.1.sarge1) Regards, Joey -- Long noun chains don't automatically imply security. -- Bruce Schneier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preparation of the next stable Debian GNU/Linux update (III)
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.1r2/. I am preparing the next revision of the current stable Debian distribution (sarge) and will frequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still enough time to reconsider. The overall plan is to release a new update of the stable Debian distribution roughly two months after the last update or after the initial release, whatever is suitable. The next revision of stable should therefore be released at the end of February / beginning of March. An ftpmaster still has to give the final approval for each package since ftpmasters are responsible for the archive. However, I'm trying to make their work as easy as possible in the hope to get the next revision out properly and without too much hassle. The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/sarge/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. . Packages that fix an unusable minor part of a package. If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). Changelog - 2006/02/17 11:01 MET * Moved elog from reject to accept * Accepted heimdal * Accepted kronolith * Accepted libast * Investigation of libchipcard * Moved nfs-user-server from further to accept * Accepted noweb * Accepted otrs * Accepted scponly * Accepted sodipodi * Updated gpdf * Updated xpdf Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. adzapperstable20050316-1all source adzapperupdates 20050316-1sarge1 all source DSA 966 adzapper - denial of service albatrossstable1.20-1 source albatrossupdates 1.20-2 source python-albatross-common stable1.20-1 all python-albatross-common updates 1.20-2 all python-albatross-doc stable1.20-1 all python-albatross-doc updates 1.20-2 all python-albatross stable1.20-1 all python-albatross updates 1.20-2 all python2.2-albatross stable1.20-1 all python2.2-albatross updates 1.20-2 all python2.3-albatross stable1.20-1 all python2.3-albatross updates 1.20-2 all DSA 942 albatross - design error antiwordstable0.35-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source antiwordupdates 0.35-2sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 945 antiword - insecure temporary file backuppcstable2.1.1-2sarge1 all source backuppcupdates 2.1.1-2sarge2 all source Fixed bug that prevented backups when iptuils-ping is installed. cernlib-basestable2004.11.04-3 all cernlib-baseupdates 2004.11.04.dfsg-0sarge1 all cernlib-core-devstable2004.11.04-3 all cernlib-core-devupdates 2004.11.04.dfsg-0sarge1 all cernlib-corestable2004.11.04-3 all cernlib-coreupdates 2004.11.04.dfsg-0sarge1 all cernlib-extras stable2004.11.04-3 all cernlib-extras updates 2004.11.04.dfsg-0sarge1 all cernlib-montecarlo stable2004.11.04-3
Re: Preparation of the next stable Debian GNU/Linux update (I)
Martin Zobel-Helas wrote: Hi Joey, there was some discussion[1] wether the next stable update could have some timezone data updated in the glibc package. Show me the changes. Unless large chunks of the world are affected I don't consider timezone details to warrant an update in our stable release. A note in the release notes may be useful instead. Regards, Joey -- Everybody talks about it, but nobody does anything about it! -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (I)
Thomas Viehmann wrote: would you entertain a one-line fix removing the deluser command from the postrm of chipcard-tools (source package libchipcard). I'm having trouble with this on #346527 (still need to figure out how to fix this for users upgrading from original sarge) and think that this could be simple enough and grave enough for being worth addressing in a stable update. If you are generally OK with this, I'll upload the (one-line postrm + changelog) fix to s-p-u. Please go ahead. Normally, such a change wouldn not warrant a fix in a stable release, but in this case the package in question is not available in the subsequent distribution so it will be removed in either way, hence an update. Regards, Joey -- Linux - the choice of a GNU generation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preparation of the next stable Debian GNU/Linux update (II)
stable0.0.20050310-1.1 i386 source wine updates 0.0.20050310-1.2 i386 source DSA 954 wine - design flaw xpdf-common stable3.00-13 all xpdf-common updates 3.00-13.4 all xpdf-reader stable3.00-13 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc xpdf-reader updates 3.00-13.4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc xpdf-utils stable3.00-13 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc xpdf-utils updates 3.00-13.4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc xpdf stable3.00-13 all source xpdf updates 3.00-13.4 all source DSA 931 xpdf - buffer overflows Requires further Investigation -- These packages need further investigation. One reason the package is listed here could be that I'm not yet convinced this package should go into stable, but don't want to reject it entirely at the moment. Another reason could be that released and updated architectures are not yet in sync. libmail-audit-perl stable2.1-5all source libmail-audit-perl updates 2.1-5sarge2 all source mail-audit-toolsstable2.1-5all mail-audit-toolsupdates 2.1-5sarge2 all DSA 960 libmail-audit-perl - insecure temporary file creation nfs-user-server stable2.2beta47-20alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source nfs-user-server updates 2.2beta47-20sarge1 alpha hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source ugiddstable2.2beta47-20alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc ugiddupdates 2.2beta47-20sarge1 alpha hppa i386 ia64 m68k mips mipsel powerpc s390 sparc Fix FreeBSD compatibility (Bug#322414) MISSING arm Rejected Packages - These packages don't meet the requirements and will be rejected (if katie supports that, otherwise we'll just carry them with us until the end of time). elogstable2.5.7+r1558-3 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source elogupdates 2.5.7+r1558-4+sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source Misdirected security update gnome-cpufreq-applet stable0.3.1-6 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source gnome-cpufreq-applet updates 0.3.1-6.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source Fixes normal bugs, not suited for a stable update muttstable1.5.9-2alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source muttupdates 1.5.9-2sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source Arbitrary changes. rsshstable2.2.3-1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source rsshupdates 2.2.3-1.sarge.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source Misplaced security update Removed Packages These packages will be removed from the stable Debian distribution. This normally only a result of license problems when the license prohibits their distribution. Disclaimer -- This list intends to help the ftp-masters releasing 3.1r2. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2006/02/10 07:22 MET -- Linux - the choice of a GNU generation. signature.asc Description: Digital signature
Preparation of the next stable Debian GNU/Linux update (I)
mipsel powerpc s390 sparc source Arbitrary changes. rsshstable2.2.3-1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source rsshupdates 2.2.3-1.sarge.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source Misplaced security update Removed Packages These packages will be removed from the stable Debian distribution. This normally only a result of license problems when the license prohibits their distribution. Disclaimer -- This list intends to help the ftp-masters releasing 3.1r2. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2006/02/06 09:43 MET -- Reading is a lost art nowadays. -- Michael Weber signature.asc Description: Digital signature
Re: fai 2.8.4sarge for sarge-proposed-updates
Thomas Lange wrote: Content-Description: message body text Hi, I uploaded fai (2.8.4sarge1) sarge-proposed-updates; urgency=low. This contains fixes for three important bugs. Attached is the debdiff to 2.8.4, but most lines in it are just cvs/svn diffs since I moved from CVS to svn. Most changes look like: diff -Nurp fai-2.8.4/conf/dhclient.conf fai-2.8.4sarge1/conf/dhclient.conf --- fai-2.8.4/conf/dhclient.conf2003-03-27 08:39:34.0 -0800 +++ fai-2.8.4sarge1/conf/dhclient.conf 2005-11-10 14:37:18.0 -0800 @@ -1,4 +1,4 @@ -# $Id: dhclient.conf,v 1.3 2003/03/27 16:39:34 lange Exp $ +# $Id: dhclient.conf 3027 2005-11-10 22:37:16Z lange $ # fai configuration for dhclient v3 Such changes are *not* suitable for an update to a stable release (or a security update). I'd wish developers would be more careful when preparing an update (or contact others prior to an upload). I hope that this version will be included into the next point release of sarge. Approved. Regards, Joey -- Given enough thrust pigs will fly, but it's not necessarily a good idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (VI)
Andrew Donnellan wrote: It's been a while since the last update: how long to go before r1? Dunno. Ryan (ftpmaster) won't give a green light for r1 until the kernel has been updated. That'll still take a while. Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (VI)
Otavio Salvador wrote: Martin Schulze [EMAIL PROTECTED] writes: Andrew Donnellan wrote: It's been a while since the last update: how long to go before r1? Dunno. Ryan (ftpmaster) won't give a green light for r1 until the kernel has been updated. Kernel of sarge? 2.6.8 and 2.4.27? IIRC, Debian Kernel Team already have some ready packages for it. I know. Most of them are ready. Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When's the mirror pulse?
Nathanael Nerode wrote: I've been waiting for the latest updates to etch to hit the mirrors, but I can't figure out when they'll get there. Is the time of the mirror pulse documented anywhere for the benefit of the obsessive? Incidentally, mirror.debian.org/status.html is dead. The mirror pulse happens after the archive reorganisation which signals the mirrors at the end. The katie run starts at: katie_tz=US/Eastern katie_time=14:52 Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: f-prot-installer needs update in stable again
Johannes Rohr wrote: Dear release team, unfortunately the f-prot-installer package is again broken by upstream changes. The release of f-prot 4.6.2 includes a modification of the check-updates.pl script incompatible with the installer script in the package. Therefore I would like to ask for an update in stable. An inter version diff is attached. The change is a one-liner. Please upload. BTW: If this continues, I consider moving the package over to volatile.d.n. Good. Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug 285025
Thomas Bushnell BSG wrote: Bug 285025 is fixed in sarge and etch; do I need to leave the bug open? Is there anything I need to do about it? Thanks for the note, I'll update the woody package with the large patch. Regards, Joey -- This is GNU/Linux Country. On a quiet night, you can hear Windows reboot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (IV)
Martin Zobel-Helas wrote: Hi Joey, please also update base-config. #154482 is still valid for sarge, and is very annoying. From the first glance this looks like a wrong setting in the debconf db. -- dpkg-reconfigure base-config with proper priorities Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (IV)
Colin Watson wrote: Martin Zobel-Helas wrote: please also update base-config. #154482 is still valid for sarge, and is very annoying. From the first glance this looks like a wrong setting in the debconf db. -- dpkg-reconfigure base-config with proper priorities (a) You mean 'apt-setup' - base-config does not ask any questions in its maintainer scripts so dpkg-reconfigure is not useful for it; (b) The apt-setup patch mentioned in base-config 2.66's changelog is needed to have that question actually get re-asked when you run apt-setup, which is the bug. So, where is the patch, and where is the updated package? Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#318463: Proposed update to e2fsprogs for stable
Theodore Ts'o wrote: On Tue, Aug 23, 2005 at 06:58:27AM +0200, Martin Schulze wrote: Theodore Ts'o wrote: When is the first stable update planned to be released? I would like to update sarge before September, but haven't heard back from ftpmaster yet whether this would be possible. In that case, given that timeline, and given that testing is going to be frozen at 1.37-2sarge1 for several weeks, could you arrange an override so that 1.37-2sarge-2 can get into stable-proposed-updates? I have no power over the archive. Maybe Steve or Colin can help. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#318463: Proposed update to e2fsprogs for stable
Steve Langasek wrote: On Sun, Aug 21, 2005 at 11:20:49PM -0400, Theodore Ts'o wrote: I would like to upload the following release to sarge to fix a grave bug (#318463), and taking the opportunity to fix a few other potential core-dumping inducing bugs. All of these are cherry picked from the e2fsprogs development tree. Should I go ahead and upload the following to stable-proposed updates? e2fsprogs (1.37-2sarge2) testing; urgency=low ^^^ If so, please be sure to fix the target in the changelog :) Even though this doesn't seem to be critical I'd accept it for the first stable update. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (II)
Alexander Sack wrote: On Sat, Aug 20, 2005 at 05:11:01PM +0200, Martin Schulze wrote: If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). Changelog - 2005/08/20 17:09 MET * Accepted mantis * Investigation of mozilla * Investigation of mozilla-firefox Please add mozilla-thunderbird here too. The security upload is pending as you told me :). I can only add packages that are there. Two architectures are missing for Thunderbird on klecker before I can release an advisory. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#318463: Proposed update to e2fsprogs for stable
Theodore Ts'o wrote: When is the first stable update planned to be released? I would like to update sarge before September, but haven't heard back from ftpmaster yet whether this would be possible. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preparation of the next stable Debian GNU/Linux update (II)
-071+1sarge1 all vim-full stable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-full updates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc vim-gnomestable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-gnomeupdates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc vim-gtk stable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-gtk updates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc vim-lesstif stable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-lesstif updates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc vim-perl stable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-perl updates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc vim-python stable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-python updates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc vim-ruby stable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-ruby updates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc vim-tcl stable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-tcl updates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc vim stable1:6.3-071+1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source vim updates 1:6.3-071+1sarge1 alpha arm hppa i386 ia64 mips mipsel powerpc sparc source Applied modeline patch MISSING m68k MISSING s390 lib64z1-dev stable1:1.2.2-4 s390 sparc lib64z1-dev updates 1:1.2.2-4.sarge.2 sparc lib64z1 stable1:1.2.2-4 s390 sparc lib64z1 updates 1:1.2.2-4.sarge.2 sparc zlib-bin stable1:1.2.2-4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc zlib-bin updates 1:1.2.2-4.sarge.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc sparc zlib1g-dev stable1:1.2.2-4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc zlib1g-dev updates 1:1.2.2-4.sarge.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc sparc zlib1g-udeb stable1:1.2.2-4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc zlib1g-udeb updates 1:1.2.2-4.sarge.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc sparc zlib1g stable1:1.2.2-4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc zlib1g updates 1:1.2.2-4.sarge.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc sparc zlib stable1:1.2.2-4 source zlib updates 1:1.2.2-4.sarge.2 source DSA 740 zlib - remote DOS DSA 763 zlib - remote DoS MISSING s390 Rejected Packages - These packages don't meet the requirements and will be rejected (if katie supports that, otherwise we'll just carry them with us until the end of time). libdbd-pg-perl stable1.41-3alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source libdbd-pg-perl updates 1.42-0sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source New upstream version, not suitable for a stable release. specter-mysql stable1.3+1.4pre2-2alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc specter-mysql updates 1.3+1.4pre2-2sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc specter-pgsql stable1.3+1.4pre2-2alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc specter-pgsql updates 1.3+1.4pre2-2sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc specterstable1.3+1.4pre2-2alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source specterupdates 1.3+1.4pre2-2sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source Misplaced upload? Unneeded changes, doesn't fix open bugs Removed Packages These packages will be removed from the stable Debian distribution. This normally only a result of license problems when the license prohibits their distribution. Disclaimer -- This list intends to help the ftp-masters releasing 3.1r1. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2005/08/20 17:09 MET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: f-prot-installer should be updated in stable
Johannes Rohr wrote: I am not sure whether this is really the appropriate place for my inquiry. I am the maintainer of f-prot-installer, an installer package for the F-Prot virus scanner, which is in contrib. Currently the installer is broken due to a minor change in the F-Prot tarball that is downloaded from the vendor's site. The result is that the start script /usr/bin/f-prot hangs. The fix is trivial: replacing /usr/bin/f-prot by a symlink to /usr/lib/f-prot/f-prot.sh I have prepared a fixed package that does exactly that. (the change is a one-liner). I would like to ask whether the release team would be ready to accept this new version into stable if it gets uploaded. (If anyone wants to check, it is at deb[-scr] http://www.rohr.org/johannes/debian/ unstable/ ) I don't seem to be able to look, please send me the diff.gz or the interdiff between the current version in stable via mail privately and off-list. Regards, Joey -- GNU GPL: The source will be with you... always. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preparation of the next stable Debian GNU/Linux update (I)
mipsel powerpc s390 sparc source cripupdates 3.5-1sarge2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 733 crip - insecure temporary files gaim-data stable1:1.2.1-1.1 all gaim-data updates 1:1.2.1-1.3 all gaim-devstable1:1.2.1-1.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc gaim-devupdates 1:1.2.1-1.3 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc gaimstable1:1.2.1-1.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source gaimupdates 1:1.2.1-1.3 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 734 gaim - denial of service mdadm-udeb stable1.9.0-4alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc mdadm-udeb updates 1.9.0-4sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc mdadm stable1.9.0-4alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source mdadm updates 1.9.0-4sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source * Make sure error output from MAKEDEV is sent to stderr, to avoid interfering with debconf; this avoids installation problems on udev-using systems. Thanks to Jonas Smedegaard for the patch. Based on the sid upload by Steve Langasek. Closes: #299623. razor stable2.670-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source razor updates 2.670-1sarge2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 738 razor - remote DOS spamassassin stable3.0.3-1 all source spamassassin updates 3.0.3-2 all source spamc stable3.0.3-1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc spamc updates 3.0.3-2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc DSA 736 spamassassin - remote DOS tracstable0.8.1-3all source tracupdates 0.8.1-3sarge2 all source DSA-739 trac - missing input sanitising Requires further Investigation -- These packages need further investigation. One reason the package is listed here could be that I'm not yet convinced this package should go into stable, but don't want to reject it entirely at the moment. Another reason could be that released and updated architectures are not yet in sync. lib64z1-dev stable1:1.2.2-4 s390 sparc lib64z1 stable1:1.2.2-4 s390 sparc zlib-bin stable1:1.2.2-4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc zlib-bin updates 1:1.2.2-4.sarge.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc zlib1g-dev stable1:1.2.2-4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc zlib1g-dev updates 1:1.2.2-4.sarge.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc zlib1g-udeb stable1:1.2.2-4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc zlib1g-udeb updates 1:1.2.2-4.sarge.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc zlib1g stable1:1.2.2-4 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc zlib1g updates 1:1.2.2-4.sarge.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc zlib stable1:1.2.2-4 source zlib updates 1:1.2.2-4.sarge.1 source DSA 740 zlib - remote DOS MISSING s390 MISSING sparc Rejected Packages - These packages don't meet the requirements and will be rejected (if katie supports that, otherwise we'll just carry them with us until the end of time). libdbd-pg-perl stable1.41-3alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source libdbd-pg-perl updates 1.42-0sarge1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source New upstream version, not suitable for a stable release. Removed Packages These packages will be removed from the stable Debian distribution. This normally only a result of license problems when the license prohibits their distribution. Disclaimer -- This list intends to help the ftp-masters releasing 3.1r1. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2005/07/08 09:16 MET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (I)
Steffen Grunewald wrote: Hi Joey, On Fri, Jul 08, 2005 at 09:18:16AM +0200, Martin Schulze wrote: Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.1r1/. I am preparing the (most probably) last revision ever of the current stable Debian distribution (woody) and will frequently send reports so people can actually comment on it and intervene whenever this is required. It is scheduled for any time now. s/the \(most probably\) last revision ever/another step towards the final version/ s/woody/sarge/ The joy of semi-automated postings... No, the joy of copied templates... :) It's corrected on the web page. Regards, Joey -- Computers are not intelligent. They only think they are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wanna-build only knows about older versions?
Michael Stone wrote: [3] What is the proper contact procedure? debian-admin seems to be a black hole at the moment--who should [EMAIL PROTECTED] contact about buildd problems if not d-a? d-a is wrong, James and Ryan are the people to contact. They are on d-a as well, though. [4] I'm sure the amd64 guys would love it if we start swinging the ax, because that would alleviate any concerns about archive space... There'll be an amd64 buildd hooked to the security arechive just like for any other architecture, and upload into security.debian.org. At least that's the plan. In that case, all we have to do is collect the work. No extra work. Regards, Joey -- Computers are not intelligent. They only think they are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release team for etch?
Steve Langasek wrote: Currently, I am planning to stick around for etch. If we're still waiting for etch two years from now, it's hard to predict how I'll feel at that point. :) Ugh! However, that'd be still one year faster than sarge... Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uploading to both stable and unstable
Jérôme Marant wrote: (Please CC me on reply) Hi, I think we are going to add many fixes to emacs21 until emacs22 comes out and it would be nice to add those fixes to stable as well. Err... did you notice that stable has been released recently? Do you know what stable means? And what's the difference between stable and volatile or *cough* unstable? Is it still possible? I recall we could add more than one distribition name in changelog entries. If so, shall we use 'stable unstable' or 'proposed-updates unstable', or maybe something else? Those changes will most probably be rejected from stable. In former times the archive suite could not handle such uploads anyway. Regards, Joey -- It's time to close the windows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please allow drupal 4.5.3-1
Steve Langasek wrote: On Wed, Jun 01, 2005 at 07:16:00PM -0700, Ian Eure wrote: On Wednesday 01 June 2005 04:54 pm, Hilko Bengen wrote: Just a few hours ago, the Drupal project has released version 4.5.3, a bugfix release which fixes a serious security bug. I have created and just uploaded a 4.5.3-1 package to unstable. Updated Debconf translations are the only additional changes over 4.5.2-3 which is the version in sarge. Any reason why you can't just apply the patch to fix that specific bug? And you probably want to be emailing the release team... He did contact the release team; unfortunately, the diff between 4.5.2 and 4.5.3 is rather large and I don't believe it's all security-related, so I think this will have to be left for the security team after all. Umh, the release team most probably has even stricter rules than the release team when it comes to cluttering the diff... Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpha buildd down?
Roger Leigh wrote: There are at least two RC bugs waiting stuck at Needs-Build on the alpha buildd (samba, ettercap) for quite a while now. Has the alpha buildd keeled over? Yes, we had experienced a problem yesterday. Thiemo got the machine back up abut stopped the buildd. The buildd maintainer should know about it and will probably take care of it soon. Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preparation of the next stable Debian GNU/Linux update (I)
s390 sparc source TODO: Why should this be added to Debian stable? spellcast stable1.0-12 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source spellcast updates 1.0-12.1i386 source * Moved to non-free due to licensing which was incorrectly considered free by the previous maintainer. See http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00136.html * Added a rant on why spellcast is not GPL describing the issue in the README.Debian file with more detail than the information available in the copyright file. MISSING alpha MISSING arm MISSING hppa MISSING ia64 MISSING m68k MISSING mips MISSING mipsel MISSING powerpc MISSING s390 MISSING sparc spellcast-doc stable1.0 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source spellcast-doc updates 1.0.1 i386 source * Moved to non-free due to licensing which was incorrectly considered free by the previous maintainer. See http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00136.html * Added a rant on why spellcast is not GPL describing the issue in the README.Debian file with more detail than the information available in the copyright file. MISSING alpha MISSING arm MISSING hppa MISSING ia64 MISSING m68k MISSING mips MISSING mipsel MISSING powerpc MISSING s390 MISSING sparc syslog-ng stable1.5.15-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source syslog-ng updates 1.5.15-1.2 hppa syslog-ng updates 1.5.15-1.3 mipsel source 1.5.15-1.2 would be DSA 175 syslog-ng - buffer overflow 1.5.15-1.3 has the security update again vim-gtk stable6.1.018-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-gtk updates 6.1.018-1woody1 alpha hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-perlstable6.1.018-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-perlupdates 6.1.018-1woody1 alpha hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-python stable6.1.018-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-python updates 6.1.018-1woody1 alpha hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-rubystable6.1.018-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-rubyupdates 6.1.018-1woody1 alpha hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-tcl stable6.1.018-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim-tcl updates 6.1.018-1woody1 alpha hppa i386 ia64 m68k mips mipsel powerpc s390 sparc vim stable6.1.018-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source vim updates 6.1.018-1woody1 alpha hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source Minor security updates that don't warrant an advisory MISSING arm yaboot stable1.3.6-1 powerpc source yaboot updates 1.3.10-0woody1 powerpc source * Backport yaboot 1.3.10 to stable (See bug #190439). - This is necessary to boot/install on recent Apple hardware. - Ethan reports that the one line change between 1.3.9 and 1.3.10 is critical. Unly required for new boot-floppies Rejected Packages - These packages don't meet the requirements and will be rejected (if katie supports that, otherwise we'll just carry them with us until the end of time). Removed Packages These packages will be removed from the stable Debian distribution. This normally only a result of license problems when the license prohibits their distribution. Disclaimer -- This list intends to help the ftp-masters releasing 3.0r6. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2005/05/06 08:52 MET -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
Holger Levsen wrote: On Wednesday 06 April 2005 12:42, Martin Schulze wrote: Hmmm... the only mail address for stable security support on http://www.debian.org/intro/organization is [EMAIL PROTECTED] - [EMAIL PROTECTED] didnt seem appropriate to me. What's wrong with that address? The reason to have filed #297811 is to be able to do stable security support. So I choose the address for stable security support. debian-security-private@ seemed to me like a mail-address to address general security problems or security problems which should remain undisclosed until they are solved. Would that have been a better address ? Yes. Ok. So if debian-security-private@ is also responsible for stable security maybe it would be a good idea to add the address there. (As I also think it's not really perfect that only your personal mail address is listed for stable security support...) Huh? In which universe do you live? Not in one where the Debian Security Team is responsible for security updates in the stable Debian release apparently. (I guess you mixed Security Team with Release Manager for ``stable''.) ((Since at the moment, it's both me, it does not matter currently, but that doesn't have to be the case all the time...)) Regards, Joey -- GNU GPL: The source will be with you... always. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
Holger Levsen wrote: Howto handle security fixes for fai-kernels --- fai-kernels uses the kernel-source-2.4.27 and kernel-source-2.6.8 packages. If these packages get updated with a security fix, fai-kernels needs to be rebuild. The kernel-image-debs which are included in the fai-kernel package contain the kernel abi version in the included packages name. If the abi version changes, those abi version number has to be incremented in fai kernels control file as well. Oh great, so we need to consider FAI as another architecture. Since there are only two base source packages left over (many thanks to the kernel team), this should be doable. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed fix to allow security support for fai-kernels in sarge (#297811)
Steve Langasek wrote: - Nothing in the source or binary package names matches the kernel.*2\.(4\.27|6\.8) regexp that I've been using so far to identify the kernel packages requiring attention I have no knowledge of how important the latter is to the security team; they may not be bothered by it as long as they're aware that this package exists which doesn't follow the usual naming convention. (which I presume that after this thread, at least one member of the security team *is* aware of this.) I have a list of packages to take care of, we only need to rewrite it once sarge is released and not forget about the list again. The actual name of the package/source does not matter too much as long as we are permanently aware of it. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suggestions for packages to force to testing for security fixes
Riku Voipio wrote: On Fri, Apr 01, 2005 at 05:10:05AM -0800, Steve Langasek wrote: lsh-utils 2.0-1 needed, have 1.4.2-8.2 for CAN-2005-0389 lsh-utils 2.0.1-1 needed, have 1.4.2-8.2 for CAN-2005-0814 (Also has a RC bug though.) yeah, that doesn't sound like a win yet (though it's also built on m68k). lsh-utils has following, worrying description: --snip-- Description: Secure Shell v2 (SSH2) protocol server WARNING: This is a work in progress, and may be totally insecure. --snip-- If the description is not out of date (It hasn't changed since last stable), is this really something that should go to sarge? Since it's in woody already, yes. Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301839: freebsd5-buildutils: can't fulfill the build dependencies in sarge
Adrian Bunk wrote: Security support can turn out to be a nightmare if build dependencies aren't fulfilled. As security bloke I can only agree to this. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel security upgrades
Andreas Barth wrote:
Ok, summarising this means for me:
If we change the abi for d-i, than a lot of work at a lot of places
needs to be done. Definitly possible, but not the thing we want to do
for each security upgrade. On the other side, as long as we keep the
old kernel around, and don't rebuild the CDs, everything is still fine.
The reason why we cannot keep the old kernels was - beside the fact that
it's not so nice if we force our users to upgrade their kernel as first
action - that we're overwriting the kernel source with the upgrade.
However, as long as the updated kernels are only available via
security.d.o and via {stable,testing}-proposed-updates, the overwriting
doesn't happen.
So, one idea would be to push the updated kernels into sarge only very
seldom (means: reserve time for exactly one more ABI transition in
sarge before release, rest happens only in unstable, t-p-u and/or
testing-security), and decide on each of the following point releases
whether we want to have the effort to touch all of the mentioned
packages, or if we keep the updated kernels only on security.d.o.
This paragraph deals only with the current situation of pre-sarge, right?
Once sarge is released, we need to expect a changed abi every month,
even though it may not happen that often, it will happen. It's not
clear how to handle this...
Regards,
Joey
--
The only stupid question is the unasked one.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ABI-changing kernel security fixes for sarge
Sven Luther wrote: We'd need at least a list of module packages that we need to recompile when a kernel update changes the ABI and all the modules become void. This also means that we need to be able to rebuild modules from their corresponding source package. Notice that enabling auto-NEW for such abi-changes will speed up this process considerably, but i was told a whinner for even suggesting such, and bashed upon unendlessly. What is auto-NEW? Alos, please find someone else for building the powerpc 2.6.8 and 2.4.27 security updates as i will most certainly not do that anymore. I'd assume that another powerpc kernel developer/maintainer is part of the kernel team then. Otherwise it will be difficult to support powerpc kernels security-wise. Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-ia64 ABI reversion
Steve Langasek wrote: On Fri, Mar 25, 2005 at 08:04:30AM +0100, Martin Schulze wrote: I've also been told that many module packages aren't built the Debian way with a .dsc file that can be used as basis for dpkg-buildpackage or similar. This makes the problem more difficult. The kernel module packages we know of that are built in this fashion are being blocked from testing, based on your comments. Thanks. waldi, could you be more specific about which other modules packages aren't built the Debian way in sarge? Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing stable PostgreSQL bugfixes
Steve Langasek wrote: On Sun, Feb 27, 2005 at 10:28:27PM +0100, Martin Pitt wrote: In the light of #291700 I prepared a new PostgreSQL stable upload. It fixes a grave misbehaviour if a database is called peer, and fixes the calling of dpkg --compare-versions which caused the help screen to be printed when installing the package from scratch. Would you accept the following debdiff for stable-proposed-updates? This needs to be approved by the Stable Release Manager, Joey Schulze. I don't know if Joey follows this list. I do. I am not convinced though that this update has to go into the stable release since it's just a normal bug. If you consider it severe enough, please get robster to add a note to the release notes for woody about not naming tables peer. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (forw) Bug#298060: Please don't install login as setuid root
Christian Perrier wrote: Security and release teams, may I have your advice about this suggestion? As you may know, I currently act as maintainer for the shadow package, but I'm also aware of my own weaknesses when it comes at security (and security-related) issues so I prefer getting the advice of more competent people. Given that installing login non setuid has been blessed for Ubuntu, I'm inclined to follow the suggestion, but doing so close to a release is maybe not wise.so I'm seeking for advices..:-) When no code needs to be changed but only the suid bit dropped and login still works as expected, I don't see a reason not to drop the setuid bit, even the contrary, I wonder why it is setuid root in the first place. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preparation of the next stable Debian GNU/Linux update (I)
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.0r5/. I am preparing the next revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. It is scheduled for the end of February / beginning of March. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision roughly two months after the last update. However, it may be required that this happens before the release of sarge or it won't happen at all. It may be the last update if no updates to 3.0 are possible after sarge has been released. An ftpmaster still has to give the final approval for each package since ftpmasters are responsible for the archive. However, I'm trying to make their work as easy as possible in the hope to get the next revision out properly and without too much hassle. The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. . Packages that fix an unusable minor part of a package. If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). Changelog - 2005/01/28 11:53 MET * Accepted chbg * Accepted enscript * Accepted f2c * Accepted gallery * Accepted gatos * Accepted imagemagick * Accepted kdebase * Accepted libdbi-perl * Accepted mc * Accepted mysql * Accepted playmidi * Accepted queue * Accepted squid * Accepted sword * Accepted unarj * Accepted vdr * Moved wmaker from further to accept * Accepted xine-lib * Accepted xtrlock * Accepted zhcon * Updated xpdf 2005/01/14 15:55 MET * Accepted bmv * Accepted cacti * Moved catdoc from further to reject * Accepted exim * Accepted glibc * Accepted gopher * Accepted hylafax * Accepted kdelibs * Accepted linpopup * Accepted lintian * Investigation of wmaker 2005/01/09 12:27 MET * Investigation of acorn-fdisk * Investigation of catdoc * Investigation of console-common * Accepted cupsys * Investigation of gcc-2.95 * Accepted htmlheadline * Accepted imlib2 * Investigation of kernel-image-2.2.20-reiserfs-i386 * Investigation of kernel-image-2.4.18-1-alpha * Investigation of kernel-image-2.4.18-1-i386 * Investigation of kernel-image-2.4.18-i386bf * Investigation of kernel-image-2.4.19-ia64 * Investigation of kernel-patch-2.4-grsecurity * Accepted krb5 * Investigation of lha * Accepted libgd1 * Investigation of libpam-radius-auth * Investigation of lsb * Accepted mm * Accepted namazu2 * Accepted nasm * Investigation of parted * Accepted pcal * Accepted perl * Investigation of qpopper * Investigation of slocate * Investigation of spellcast * Investigation of spellcast-doc * Investigation of ssed * Investigation of syslog-ng * Accepted tiff * Accepted xpdf * Investigation of yaboot * Accepted zip Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. bmv stable1.2-14 i386 source bmv updates 1.2-14.2i386 source DSA 633 bmv - insecure temporary file cacti stable0.6.7-2 all source cacti updates 0.6.7-2.2 all source DSA 164 cacti - arbitrary code execution chbgstable1.5-1alpha arm hppa i386 ia64
Preparation of the next stable Debian GNU/Linux update (IV)
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.0r4/. I am preparing the next revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. It is planned to update the stable Debian release at the end of this year. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision roughly two months after the last update. However, it may be required that this happens before the release of sarge or it won't happen at all. It may be the last update if no updates to 3.0 are possible after sarge has been released. An ftpmaster still has to give the final approval for each package since ftpmasters are responsible for the archive. However, I'm trying to make their work as easy as possible in the hope to get the next revision out properly and without too much hassle. The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. . Packages that fix an unusable minor part of a package. If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). Changelog - 2004/12/24 14:18 MET * Accepted a2ps * Accepted debmake * Accepted ethereal * Accepted htget * Accepted mpg123 * Accepted netkit-telnet-ssl * Accepted xfree86 * Accepted xzgv Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. a2psstable4.13b-16alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source a2psupdates 4.13b-16woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 612 a2ps - unsanitised input abiword-common stable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-common updates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-doc stable1.0.2+cvs.2002.06.05-1all abiword-doc updates 1.0.2+cvs.2002.06.05-1woody2 all abiword-gnomestable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-gnomeupdates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-gtk stable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-gtk updates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-plugins stable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-plugins updates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword stable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source abiword updates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source xfonts-abi stable1.0.2+cvs.2002.06.05-1all xfonts-abi updates 1.0.2+cvs.2002.06.05-1woody2 all DSA 579 abiword - buffer overflow apache-common stable1.3.26-0woody5 alpha arm hppa i386 ia64 m68k mips
Preparation of the next stable Debian GNU/Linux update (III)
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.0r4/. I am preparing the next revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision roughly two months after the last update. However, it may be required that this happens before the release of sarge or it won't happen at all. It may be the last update if no updates to 3.0 are possible after sarge has been released. An ftpmaster still has to give the final approval for each package since ftpmasters are responsible for the archive. However, I'm trying to make their work as easy as possible in the hope to get the next revision out properly and without too much hassle. The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. . Packages that fix an unusable minor part of a package. If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). Changelog - 2004/12/18 19:17 MET * Updated atari800 * Accepted cscope * Accepted zgv 2004/12/10 09:22 MET * Accepted hpsockd * Accepted nfs-utils * Accepted viewcvs 2004/12/03 09:20 MET * Accepted libcrypt-passwdmd5-perl * Accepted openssl * Accepted rlpr * Updated libgd1 * Updated libgd2 Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. abiword-common stable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-common updates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-doc stable1.0.2+cvs.2002.06.05-1all abiword-doc updates 1.0.2+cvs.2002.06.05-1woody2 all abiword-gnomestable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-gnomeupdates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-gtk stable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-gtk updates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-plugins stable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword-plugins updates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc abiword stable1.0.2+cvs.2002.06.05-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source abiword updates 1.0.2+cvs.2002.06.05-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source xfonts-abi stable1.0.2+cvs.2002.06.05-1all xfonts-abi updates 1.0.2+cvs.2002.06.05-1woody2 all DSA 579 abiword - buffer overflow apache-common stable1.3.26-0woody5 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc apache-common updates 1.3.26-0woody6 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc apache-dev stable1.3.26-0woody5 alpha arm hppa i386 ia64 m68k mips mipsel powerpc
Re: Preparation of the next stable Debian GNU/Linux update (III)
Santiago Vila wrote: Not directly related to 3.0r4, but while we are at it: Would be possible to remove packages in security.debian.org which are already part of 3.0r3? What would we gain from this? I would not like that but maybe you have a good reason for asking. Regards, Joey -- Experience is something you don't get until just after you need it.
Re: Preparation of the next stable Debian GNU/Linux update (III)
Ron Johnson wrote: On Sat, 2004-12-18 at 19:53 +0100, Santiago Vila wrote: Not directly related to 3.0r4, but while we are at it: Would be possible to remove packages in security.debian.org which are already part of 3.0r3? Isn't that not correct, since someone who installs from 3.0 or 3.0r[123] disks will need all of the packages in security.d.o to be able to upgrade to the latest secure revisions? In general yes, but normally you also have the regular links to http.us.debian.org, no? Regards, Joey -- Experience is something you don't get until just after you need it.
Re: status of getting security fixes into sarge
Joey Hess wrote: perl 5.8.4-4 needed, have 5.8.4-3 for CAN-2004-0976 Still missing mipsel build, should probably be re-queued or uploaded manually. I suspect there is a problem with the buildd host. Perl builds (and runs) fine in environments outside of this particular buildd. Requeuing doesn't change anything. Somebody would have to debug the failing 12 test cases on that particular host, I guess... Regards, Joey -- WARNING: Do not execute! This call violates patent DE10108564. http://www.elug.de/projekte/patent-party/patente/DE10108564 wget -O patinfo-`date +%Y%m%d`.html http://patinfo.ffii.org/
Preparation of the next stable Debian GNU/Linux update (II)
slocate - buffer overflow MISSING alpha MISSING arm MISSING hppa MISSING ia64 MISSING i386 MISSING m68k MISSING mips MISSING powerpc MISSING s390 MISSING sparc spellcast stable1.0-12 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source spellcast updates 1.0-12.1i386 source * Moved to non-free due to licensing which was incorrectly considered free by the previous maintainer. See http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00136.html * Added a rant on why spellcast is not GPL describing the issue in the README.Debian file with more detail than the information available in the copyright file. MISSING alpha MISSING arm MISSING hppa MISSING ia64 MISSING m68k MISSING mips MISSING mipsel MISSING powerpc MISSING s390 MISSING sparc spellcast-doc stable1.0 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source spellcast-doc updates 1.0.1 i386 source * Moved to non-free due to licensing which was incorrectly considered free by the previous maintainer. See http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00136.html * Added a rant on why spellcast is not GPL describing the issue in the README.Debian file with more detail than the information available in the copyright file. MISSING alpha MISSING arm MISSING hppa MISSING ia64 MISSING m68k MISSING mips MISSING mipsel MISSING powerpc MISSING s390 MISSING sparc ssedstable3.57a-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source ssedupdates 3.57a-2woody alpha i386 m68k mips powerpc ssedupdates 3.57a-2woody1 hppa mipsel source delay-install-u ssed_3.57a-2woody_alpha.changes delay-install-u ssed_3.57a-2woody_i386.changes delay-install-u ssed_3.57a-2woody_m68k.changes delay-install-u ssed_3.57a-2woody_mips.changes delay-install-u ssed_3.57a-2woody_powerpc.changes delay-install ssed_3.57a-2woody1_hppa.changes delay-install ssed_3.57a-2woody1_mipsel.changes MISSING alpha MISSING arm MISSING hppa MISSING ia64 MISSING m68k MISSING mips MISSING powerpc MISSING s390 MISSING sparc syslog-ng stable1.5.15-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source syslog-ng updates 1.5.15-1.2 hppa mipsel 1.5.15-1.2 would be DSA 175 syslog-ng - buffer overflow 1.5.15-2 was a bogus fix and removes the DSA, congratulations. And since it has had a newer source, there is no source anymore. Congratulations. I love it when maintainers think properly. yaboot stable1.3.6-1 powerpc source yaboot updates 1.3.10-0woody1 powerpc source * Backport yaboot 1.3.10 to stable (See bug #190439). - This is necessary to boot/install on recent Apple hardware. - Ethan reports that the one line change between 1.3.9 and 1.3.10 is critical. Unly required for new boot-floppies Rejected Packages - These packages don't meet the requirements and will be rejected (if katie supports that, otherwise we'll just carry them with us until the end of time). lha stable1.14i-2 alpha arm i386 ia64 m68k powerpc s390 sparc source lha stable1.14i-2.0.1 hppa lha updates 1.14i-2.woody4 alpha arm hppa i386 ia64 m68k powerpc s390 sparc source DSA 515 lha - several vulnerabilities Security update for non-free debian/patch.CAN-2004-0234_0235: Add to fix CAN-2004-0234 (buffer overflows), CAN-2004-0235 (directory traversal). See: http://marc.theaimsgroup.com/?l=full-disclosurem=108345064008698w=2 * debian/control: Change my mail address. 1.14i-2.woody4: said security update, too many changes Removed Packages These packages will be removed from the stable Debian distribution. This normally only a result of license problems when the license prohibits their distribution. Disclaimer -- This list intends to help the ftp-masters releasing 3.0r4. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2004/11/26 12:48 MET -- Of course, I didn't mean that, which is why I didn't say it. What I meant to say, I said. -- Thomas Bushnell
