Re: bullseye / libgdbm6:amd64 is a catastrophgy

[Christopher Huhn]

Am 25.08.23 um 12:30 schrieb Roberto C. Sánchez:

I reported this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043023


The first reason is that bugs of this nature (i.e., bugs that are not of
a serious security nature, but which might still require a fix) are
handled by the maintainer coordinating with the stable release managers
(or oldstable release managers, in this case) to receive approval to
upload a fixed package to be included in the next point release. Based
on the response from the maintianer in your bug report, this does not
appear to be in consideration.


We had a similar problem with autofs that got fixed and is now in 
bullseye-proposed-updates waiting for the next Bullseye point release [1].


The autofs maintainer was very responsive.
The situation was different though:
1) The problem also affected the bookworm package (got fixed too)
2) We provided a patch with the fix that confirmed it works for us
3) The patch was more or less trivial

If you really need to get your problem fixed in Bullseye and convince 
the maintainer to push it to a point release you should make sure the 
proposed patch [2] is cleaned up so

1) it applies cleanly against the Bullseye sources in the package
2) does not change the default behavior of the existing Bullseye package 
(ie. prereading behaviour should be the same with and without the patch 
unless explicitly requested).

3) does not contain mere white-space changes
4) make some decent testing to verify the patch does not break stuff

Given that will give you an updated package in Bullseye you'd still have 
to change your code to change the GDBM_PREREAD behaviour.

So you need a workaround from your side anyhow, don't you?
A backport of the bookworm package would be my way to go, I guess.

That said, LTS point releases do contain functional changes that are not 
security related, so there seems to be no general security-fixes-only 
policy for LTS either. Is that correct?


Best

Christopher

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039967
[2] https://git.gnu.org.ua/gdbm.git/commit/?id=d69a106c04

Broken bind9 security update

[Christopher Huhn]

Hi y'all

It looks like the bind9 security update for Stretch is severely broken, 
cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007945


We had to emergency downgrade to get our DNS servers working again.

Best

Christopher

Re: Archive of squeeze-lts ?

[Christopher Huhn]

Hi,

just stumbled upon this old discussion and have to add my 2 cents:

On 03/29/2016 12:04 AM, Antoine Beaupré wrote:
> I'm seeing this when trying to fetch lts packages from
archive.debian.org at the moment. Anyone know a good contact for them?

E: Release file expired, ignoring
http://archive.debian.org/debian/dists/squeeze-lts/Release  (invalid
since 9d 1h 10min 4s)

> The key did not expire. It's the "Valid-Until" date set in the (signed

with a non-expired key) Release file that elapsed... and this is exactly
its purpose.


sqeeze-lts is the only repository on archive.d.o that behaves like that.
Neither squeeze nor squeeze-backports nor squeeze-security do nor 
anything really 'historic'.


AFAICT squeeze-lts is the only repository implementing this flag at all. 
Is that correct?



Let you know when you don't have the latest version and right now there's
no "latest version" any more since the release is no longer maintained.


Don't you think that people explicitly fetching packages from 
archive.d.o are well aware that these are not supported any more?
Their apt config had already been broken when squeeze(-*) has been 
removed from ftp.d.o. That should be warning enough.


Putting 'Acquire::Check-Valid-Until "false";' in apt.conf (and 
eventually keeping that after Wheezy upgrade) is not really a 
recommendable solution.

After all this flag affects all sources.

Have a nice weekend,
Christopher