Re: Upcoming Squeeze point release 6.0.2

[Martin Schulze]

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: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile

[Martin Schulze]

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: The future of clamav wrt. stable/volatile

[Martin Schulze]

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: emacs22 22.2+2-5

[Martin Schulze]

Rob Browning wrote:
> Martin Schulze <[EMAIL PROTECTED]> writes:
> 
> > 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.
> 
> While I'd be willing to include a patch that specifically deals with
> the tmp files, I'm a bit hesitant to include a whole new tramp
> version, one that doesn't match what was shipped with 22.2.

For lenny I can understand that in general.  For sid I cannot.  Except
you are backporting the tmpfile specific bits of the updated version
of tramp to the version in sid.

> In any case, if I get some time I may look in to the patch myself.  I
> will also probably be working on a 22.3 upload (presumably not for
> Lenny) soon.

Both would be appreciated.

Repeating: I'm using the updated version of tramp on sid for months
without problems - and without a cluttered /tmp directory.

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]

Re: emacs22 22.2+2-5

[Martin Schulze]

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

[Martin Schulze]

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.
> > 
> >  You can now partition using loop-aes encryption, but the modules are 
> > not
> >   available for the installed system.
> >  So you cannot access any loop-aes encrypted partitions.
> >  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.
>  Errata specific to etch-and-a-half
>  
>  
> -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?

[Martin Schulze]

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 Schulze]

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: lost webmin?

[Martin Schulze]

Martijn Sanderse wrote:
> Dear reader,
> 
> I've noticed that package "webmin" dissapeared from the archive, what is the 
> reason for this?

The package webmin has been removed from the Debian distribution due
to security problems, unmaintainable code and no maintainer willing to
maintain it anymore.

If you want to get it back it would be good start to find people to
tidy up the code and work close together with their upstream
developers.

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: etch and kernels2.4

[Martin Schulze]

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

[Martin Schulze]

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

[Martin Schulze]

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

[Martin Schulze]

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

[Martin Schulze]

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

[Martin Schulze]

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, y>9, 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

[Martin Schulze]

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: Please remove Eclipse from Etch (was Re: Will eclipse be part of etch?)

[Martin Schulze]

Filipus Klutiero wrote:
> >407384  back in testing: 
> >libswt3.2-gtk-jni  
> >libswt3.2-gtk-jni: undeclared conflict with libswt-mozilla-gtk-3.2-jni
> 
> Doh. Nothing of the 3 I suggested was done, and it seems I reacted a few 
> hours too late. So, please remove Eclipse from Etch.

Huh?  Can't Eclipse be fixed so that etch could contain it?
Etch without Eclipse would be a pity.

Regards,

Joey

-- 
It's practically impossible to look at a penguin and feel angry.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: why is alpha a release candidate?

[Martin Schulze]

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]

Re: Bug#404888: glib2.0: cannot go into testing; causes gnucash regrsession

[Martin Schulze]

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: SSH upgrade problem

[Martin Schulze]

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]

SSH upgrade problem

[Martin Schulze]

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: Security team's opinion

[Martin Schulze]

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: Security team's opinion

[Martin Schulze]

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: a few comments on the release notes

[Martin Schulze]

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: user-mode-linux too [was: Re: apache2 DSA considerations for etch]

[Martin Schulze]

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: security support & mozilla, php

[Martin Schulze]

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: debugging output in apt-get update

[Martin Schulze]

Jonas Meurer wrote:
> hello,
> 
> apt-get update is still very verbose about the pdiff updates:
> 
> [about 300 lines with "Get: ..."]
> Get:334 2006-09-26-1322.12.pdiff [10.7kB]
> Get:335 2006-09-26-1322.12.pdiff [10.7kB]
> Get:336 2006-09-27-1319.38.pdiff [4821B]
> Get:337 2006-09-26-1322.12.pdiff [10.7kB]
> Get:338 2006-09-27-1319.38.pdiff [4821B]
> Get:339 2006-09-27-1319.38.pdiff [4821B]
> Get:340 2006-09-27-1319.38.pdiff [1720B]
> Get:341 2006-09-27-1319.38.pdiff [1720B]
> Get:342 2006-09-27-1319.38.pdiff [1720B]
> Get:343 2006-09-27-1319.38.pdiff [27.4kB]
> Get:344 2006-09-27-1319.38.pdiff [27.4kB]
> Get:345 2006-09-27-1319.38.pdiff [27.4kB]
> Get:346 2006-09-27-1319.38.pdiff [8054B]
> Get:347 2006-09-27-1319.38.pdiff [8054B]
> Get:348 2006-09-27-1319.38.pdiff [8054B]
> Fetched 1313kB in 1m10s (18.5kB/s)
> Reading package lists... Done
> 
> if i didn't run 'apt-get update' for some weeks, i get hundreds of
> lines, three lines for each pdiff file. I hope that the verbosity
> will be reduced before etch is released.

If you don't updated regularily you should probably not use the pdiff
method but fetch full Packages files instead.  This can be configured
in apt.conf with:

Acquire::Pdiffs "false";

> I would also love to see some some automatics in apt to download the
> full Packages file when pdiffs for more than, lets say two weeks
> would be needed instead.

ack.

Regards,

Joey

-- 
GNU GPL: "The source will be with you... always."

TV-Tip: Sonntag, 1. Oktober 2006, 9:02, ZDF
http://www.zdf.de/ZDFde/inhalt/8/0,1872,3983400,00.html


-- 
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?

[Martin Schulze]

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?

[Martin Schulze]

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)

[Martin Schulze]

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: Preparation of the next stable Debian GNU/Linux update (I)

[Martin Schulze]

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: Sarge -> Etch upgrade issue

[Martin Schulze]

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 Schulze]

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

[Martin Schulze]

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: mailman 2.1.5-8sarge3: screwup between security and maintainer upload

[Martin Schulze]

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]

Re: Secure APT Key Management

[Martin Schulze]

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: Preparing the next Release

[Martin Schulze]

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]

Preparing the next Release

[Martin Schulze]

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
sti

Re: HAL needed by Konqueror in kde-desktop

[Martin Schulze]

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)

[Martin Schulze]

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: Preparation of the next stable Debian GNU/Linux update (I)

[Martin Schulze]

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

Re: Upload new version of ruby-pkg-tools?

[Martin Schulze]

Esteban Manchado Velázquez wrote:
> Hi,
> 
> We, the Ruby Extras Team, have a package (ruby-pkg-tools) with some CDBS
> classes and other build-related tools. Usually Ruby library packages
> Build-Depend on ruby-pkg-tools, so I guess we should contact the Release Team
> before uploading a new version.
> 
> We have a couple of unimportant changes, _plus_ one that allows "hobix" to
> build correctly (without files in /usr/local). In fact, we can change hobix'
> debian/rules to make it work with the previous (i.e. current in the Debian
> archive) r-p-t version, but we think it's generally better to fix the build
> tool, instead of fixing bugs in a per-package-basis.

Does this change prevent any existing packages from building?

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]

Re: how to cleanly get rid of exim 3 for etch?

[Martin Schulze]

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]

Summary: Secure APT Key Management

[Martin Schulze]

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: Secure APT Key Management

[Martin Schulze]

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

[Martin Schulze]

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

[Martin Schulze]

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)

[Martin Schulze]

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 Schulze]

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]

Re: sarge3 kernel build & r3

[Martin Schulze]

dann frazier wrote:
> I saw some questions on irc about the sarge3 kernel build & r3...
> 
>  it's just, i actualy wanted to release sarge r3 with sarge2
> kernels. now i get told sarge3-kernels are already prepared, which
> disapoints me a bit, as noone told the stable release team there will
> be another kernel update round for r3 :(

That's rediculous.  The Security Team does not have to announce their
updates n days in advance to the stable release team.  The Security
Team instead must be able to issue security updates at any time.

Thanks to the new proposed-updates barrier these updates don't even
have to affect proposed-updates as they can easily be installed into
proposed-updates after the next point release.

It would be good if we would be able some day to release kernel
updates in a more timely fashion and also not accumulate this many
security updates in one update.  However, due to the number of
architectures and affected packages I'm not sure this goal can be met
any time soon.  But that's a different story...

>  and actually sarge r3 is just waiting for a new d-i, which i
> understand is currently waiting for kernel udebs...
>  -boot is responsible for the udebs anyway

--> Not the problem of the Security Team

However, if kernel udebs should be part of the security update, then
we'll need proper source packages that build these udebs - or, if
these already exist, a pointer which source package has been forgotton
in the last kernel update rounds.

> During the d-i bof at DebConf I pointed out that the sarge3 kernel
> build is in progress and is not an ABI change - there was consensus to
> wait for this build before doing the d-i build for r3.  I don't
> remember the timeline we discussed for this build.  The current status
> is that the build is complete and pending upload by the security team
> (I think Moritz would be the one to do it, so I've cc'd him).

Oh.  Great.  Good to hear (err... sending such information to
[EMAIL PROTECTED] would actually be a good idea as well...)

>  dannf, as long as u dont upload (before coordinating with
>  zobel/srm-team) everybody is happy about your work :) 

1. Uploading to the security archive should be possible without
   coordination with the release team.  If the later is required,
   something is broken.

2. Thanks to the barrier between incoming and proposed-updates even
   the push into the main archive should not be a problem since the
   stable release team only has to delay acceptance of the new
   packages so that the older ones are not overwritten before the
   point release.  That's one of the benefits of the new barrier.

> Personally, I don't care which kernel gets used - that's a
> stable-release/d-i decision in my opinion. However, I do not think we

Ack.

> should delay the release of the sarge3 kernel to security.debian.org -

Ack.

> I want to avoid any situation that would prevent us from doing timely
> security updates.

Ack.

> If you decide to stick with sarge2 for r3, would an upload of sarge3 to
> security.debian.org break this? As I understand it, sarge2 is already

It shouldn't be able to.

Regards,

Joey

-- 
Every use of Linux is a proper use of Linux.  -- Jon 'maddog' Hall

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: Postgresql-related updates

[Martin Schulze]

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: release updates and the general audience

[Martin Schulze]

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]

Postgresql-related updates

[Martin Schulze]

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: [D-I] Preparing for update in stable

[Martin Schulze]

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 ...

[Martin Schulze]

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

[Martin Schulze]

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 Schulze]

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?

[Martin Schulze]

?? 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

[Martin Schulze]

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 Schulze]

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?

[Martin Schulze]

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

[Martin Schulze]

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)

[Martin Schulze]

Preparation of the next stable Debian GNU/Linux update
==

An up-to-date version is at .

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
 and are found at
.

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
).

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 Schulze]

Steve Langasek wrote:
> >  * Accepted albatross
> >  * Accepted antiword
> >  * Investigation of cernlib
> >  * Investigation of clamav
> >  * Accepted crawl
> >  * Moved evms from further to accept
> >  * Accepted mantis
> >  * Accepted perl
> >  * Accepted sudo
> 
> Are you aware of the complaints regarding the solution implemented in the
> sudo DSA?

Yes, we're discussing already how to handle this.  In general we believe
that the current fix is proper, but may release an update to document it
better.

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]

Preparation of the next stable Debian GNU/Linux update (II)

[Martin Schulze]

6
wine-utils updates   0.0.20050310-1.2  i386
wine   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

Re: Preparation of the next stable Debian GNU/Linux update (I)

[Martin Schulze]

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]

Re: Preparation of the next stable Debian GNU/Linux update (I)

[Martin Schulze]

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]

Preparation of the next stable Debian GNU/Linux update (I)

[Martin Schulze]

ce
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/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

[Martin Schulze]

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)

[Martin Schulze]

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: Preparation of the next stable Debian GNU/Linux update (VI)

[Martin Schulze]

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: When's the mirror pulse?

[Martin Schulze]

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

[Martin Schulze]

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

[Martin Schulze]

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 Schulze]

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: Preparation of the next stable Debian GNU/Linux update (IV)

[Martin Schulze]

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: Bug#318463: Proposed update to e2fsprogs for stable

[Martin Schulze]

Theodore Ts'o wrote:
> What's the schedule for 3.1r2?  I think that this is serious enough
> that we should get it into 3.1r1, and have the updated package
> prepareds, but I accept that I might be biased on the matter, and in
> the end it's really up to the stable release management team.  What
> say ye?

Please see 

   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 soon.

Regards,

Joey

-- 
Unix is user friendly ...  It's just picky about its friends.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please allow zlib_tpu into testing

[Martin Schulze]

Steve Langasek wrote:
> On Wed, Aug 24, 2005 at 12:55:26PM +0100, Mark Brown wrote:
> > On Tue, Aug 23, 2005 at 07:50:53PM -0700, Steve Langasek wrote:
> 
> > > It appears no binary packages have been uploaded yet for s390; we need
> > > those to be installed in testing-proposed-updates before the update can 
> > > be (safely) approved.
> 
> > Oh, update-excuses doesn't mention that.  The relevant binaries *are* on
> > security.debian.org so I've no idea why that would be the case...
> 
> I don't know either.  Cc:ed to the security team, so that someone can see
> whether it got stuck somewhere, or at least re-forward it to the queue on
> ftp-master.

It's stuck on ftp-master:

spohr!joey(pts/10):/org/ftp.debian.org/queue/accepted> l 
zlib_1.2.2-4.sarge.2_s390.changes
-rw-rw-r--  1 katie ftpteam 1724 Jul 20 06:47 zlib_1.2.2-4.sarge.2_s390.changes

You'll have to ask the ftpmasters what's the status of it.

The same happened to gopher and pdns.

Regards,

Joey

-- 
The MS-DOS filesystem is nice for removable media.  -- H. Peter Anvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#318463: Proposed update to e2fsprogs for stable

[Martin Schulze]

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

[Martin Schulze]

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]

Re: Preparation of the next stable Debian GNU/Linux update (II)

[Martin Schulze]

LENHOF Jean-Yves wrote:
> 
> On Lun 22 août 2005 11:42, Martin Schulze a écrit :
> > 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
> 
> For firefox, there's this bug which is very bad
> So for now please don't accept it in this new release
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324344
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324173

Thanks.  I've been informed that 1.0.4-2sarge2 does not work
as expected, even though my - short - tests worked, but I'm
not a web dude.

Eric is working on an update.

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: Preparation of the next stable Debian GNU/Linux update (II)

[Martin Schulze]

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

[Martin Schulze]

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]

Preparation of the next stable Debian GNU/Linux update (II)

[Martin Schulze]

  stable1:6.3-071+1all
vim-doc  updates   1:6.3-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

[Martin Schulze]

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]

Re: Preparation of the next stable Debian GNU/Linux update (I)

[Martin Schulze]

Thomas Viehmann wrote:
> Martin Schulze wrote:
> >  3. The stable version of the package is not installable at all due to
> > broken or unmet dependencies or broken installation scripts.
> Would you consider a fix for #315946 if uploaded to s-p-u?

I'd like to see your proposed fix.

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: Preparation of the next stable Debian GNU/Linux update (I)

[Martin Schulze]

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]

Preparation of the next stable Debian GNU/Linux update (I)

[Martin Schulze]

ble3.5-1alpha arm hppa i386 ia64 m68k mips 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: wanna-build only knows about older versions?

[Martin Schulze]

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?

[Martin Schulze]

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

[Martin Schulze]

Jérôme Marant wrote:
> Selon Martin Schulze <[EMAIL PROTECTED]>:
> 
> > Err... did you notice that stable has been released recently?
> 
> I must have seen a little announce somewhere.
> 
> > Do you know what stable means?  And what's the difference between
> > stable and volatile or *cough* unstable?
> 
> There's nothing about volatile in the Developer's Reference.

Please consult a dictionary.
I was referring to the words, not to suites and archives this time.  *sigh*

> Please tell me about the scope of proposed-updates, except from security
> updates. Thanks.

Consider there is no other scope.

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: Uploading to both stable and unstable

[Martin Schulze]

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: alpha buildd down?

[Martin Schulze]

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]

Re: Please allow drupal 4.5.3-1

[Martin Schulze]

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]

Preparation of the next stable Debian GNU/Linux update (II)

[Martin Schulze]

nly 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/13 06:38 MET

-- 
Unix is user friendly ...  It's just picky about its friends.


-- 
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)

[Martin Schulze]

mipsel powerpc s390 sparc source
parted updates   1.4.24-4.woody.1  alpha arm hppa i386 ia64 m68k 
mips mipsel powerpc 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: Accepted elog 2.5.7+r1558-2 (i386 source)

[Martin Schulze]

Steve Langasek wrote:
> On Thu, May 05, 2005 at 12:12:11PM +0300, Recai Oktas wrote:
> > * Steve Langasek [2005-05-05 01:23:19-0700]
> > > On Thu, May 05, 2005 at 03:32:12AM -0400, Recai Okta?? wrote:
> > [...]
> > > >  elog (2.5.7+r1558-2) testing-proposed-updates; urgency=high
> > > >  .
> > > >* Fix a possible buffer overflow.
> > > >* Urgency set to high because of the security issue.
> > > >* Minor doc fix in welcome message.
> > > >* Improve package description.
> > > 
> > > This changelog mentions neither a Debian bug number, nor a CVE id for this
> > > problem; is either available?
> 
> > No, neither is available.  Should I first submit a bug for this issue?
> 
> No, but please contact the security team and the testing security team to
> inform them of this upload.

FYI: I can only request a CVE Id for a vulnerability we will report
about in a security advisory.  If we don't send out an advisory, I
won't get a CVE Id (unless another vendor issues an advisory).

Recai, please talk to [EMAIL PROTECTED] if you need more from
me as I haven't followed all elog mails on -release.

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: New Postgresql problems

[Martin Schulze]

Andreas Barth wrote:
> * Martin Pitt ([EMAIL PROTECTED]) [050504 15:05]:
> > Martin Schulze [2005-05-04 12:29 +0200]:
> > > Martin Pitt wrote:
> > > > Martin Schulze [2005-05-04  7:53 +0200]:
> > > > > Since testing is frozen now, the update for sarge should go via
> > > > > security.  Since testing and sid share the same version, the
> > > > > package would then migrate into sid as well.
> 
> > > > Hmm, as far as I understood, I could as well upload into sid and ask
> > > > debian-release to push the package into sarge? Or would you prefer
> > > > doing a security update, even if Sarge is not yet released?
> > > 
> > > Let's decide this when the packages are ready.  Officially security
> > > support has started, hence via security.  However, if the packages
> > > will be available soon and the chances that they're built against
> > > wrong libraries are low, they can go via sid as well.
> > 
> > I just uploaded 7.4.7-6 into Sid with urgency=high. I tested the debs
> > on my server which runs Sarge, they install fine and both the upgrade
> > and a fresh installation do not have the vulnerabilities any more. The
> > only difference between Sarge and Sid is now the security fix. For
> > your interest, here is the changeset:
> > 
> >  http://arch.piware.de/cgi-bin/archzoom.cgi/[EMAIL 
> > PROTECTED]/postgresql--devel--1--patch-41?log
> > 
> > Joey, Debian Release Team: Please let me know whether you can push the
> > Sid version into Sarge, or you prefer a separate testing-security
> > upload (which would differ only by the changelog version, though).
> 
> That's more or less Joeys decision if he wants to push the package via
> testing-security (well, it might be a good test for that :). For us,
> pushing via unstable also works.

Since the package *has* been uploaded into sid already, it doesn't make
sense to to another upload and keep buildds busy just for the sake of it.

> (And, just for the record, I was not able to see 7.4.7-6 already in sid,
> but just -5 in incoming.)

It's rather vice versa:

postgresql  testing   7.4.7-5alpha arm hppa i386 ia64 m68k mips 
mipsel powerpc s390 sparc source
postgresql  unstable  7.4.7-5alpha arm hppa i386 ia64 m68k mips 
mipsel powerpc s390 sparc source

and -6 is in incoming.

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: New Postgresql problems

[Martin Schulze]

Martin Pitt wrote:
> I just uploaded 7.4.7-6 into Sid with urgency=high. I tested the debs
> on my server which runs Sarge, they install fine and both the upgrade
> and a fresh installation do not have the vulnerabilities any more. The
> only difference between Sarge and Sid is now the security fix. For
> your interest, here is the changeset:
> 
>  http://arch.piware.de/cgi-bin/archzoom.cgi/[EMAIL 
> PROTECTED]/postgresql--devel--1--patch-41?log
> 
> Joey, Debian Release Team: Please let me know whether you can push the
> Sid version into Sarge, or you prefer a separate testing-security
> upload (which would differ only by the changelog version, though).

Cool!  Thanks.

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: webmin packages need a hint

[Martin Schulze]

Jaldhar H. Vyas wrote:
> On Tue, 19 Apr 2005, Martin Schulze wrote:
> 
> > Have you checked for the vulnerabilities upstream has recently
> > announced in <http://www.webmin.com/changes.html> and
> > <http://www.webmin.com/uchanges.html>?  They are referenced by
> > CAN-2005-1177 as well.
> >
> 
> They only apply to 1.190 and above which are not packaged yet.

Good.  Thanks for investigating!

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]