* Matthias Klose:
> As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13,
> 15
> with 14, 16 with 15. Only having 11 in bullseye would make backports more
> "interesting".
All recent OpenJDK releases can be built by themselves, right?
That's good enough for backports, I
* Florian Weimer:
>> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this. ppc64el features prominently in the
> toolchain work I do (thou
* Paul Gevers:
> * Concern for armel and armhf: only secondary upstream support in GCC
>(Raised by the GCC maintainer; carried over from stretch and buster)
glibc upstream lately has trouble finding qualified persons to
implement security fixes for the 32-bit Arm architecture.
> * Concern
* Jay Berkenbilt:
> I'm about to release qpdf 10. Someone contributed an openssl crypto
> provider. Do you think I should build with the qpdf packages for
> debian with 1) only gnutls, 2) only openssl, or 3) both gnutls and
> openssl? Option 3 allows users to select at runtime but makes qpdf
>
* Aurelien Jarno:
> - Fix for memusagestat's Makefile related code, which has no impact on
> the generated code.
Sorry, I screwed that one up and had to revert it upstream for the 2.28
branch. I don't think the bug introduced by this commit matters for
Debian at present, but it will cause
* Christoph Berg:
> with the update to glibc 2.28, collation aka sort ordering is
> changing:
>
> $ echo $LANG
> de_DE.utf8
> $ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort
>
> stretch:
> aa
> a a
> a-a
> a+a
>
> buster:
> a a
> a+a
> a-a
> aa
>
> A vast number of
* Luke Kenneth Casson Leighton:
> that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits. which is
> why i'm recommending people try
* Niels Thykier:
> armel/armhf:
>
>
> * Undesirable to keep the hardware running beyond 2020. armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]
Fedora is facing an issue running armhf under virtualization on arm64:
* Julien Cristau:
> On Mon, Apr 3, 2017 at 20:43:08 +0200, Florian Weimer wrote:
>
>> * Niels Thykier:
>>
>> > There is a security team related item in the release checklist where we
>> > need input from the you[1]:
>> >
>> > Items are:
* Niels Thykier:
> There is a security team related item in the release checklist where we
> need input from the you[1]:
>
> Items are:
> * release-notes: Security Team signoff for lower supported packages
>
> Please review the release notes and file bugs for the missing items (if
> any) and let
* Niels Thykier:
> Florian Weimer:
>> * Niels Thykier:
>>
>>> [...]
>>
>> Do you think that PIE-by-default makes BIND_NOW-by-default
>> unnecessary?
>>
>> (The argument is that with PIE, it is much more difficult to get a
>> con
* Niels Thykier:
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
> * It is a substantial hardening feature
> * Upstream has vastly reduced the performance penalty for x86
> * The majority of all porters
> In other words, i don't think a s390x box will ever just die.
I'm sure “death” encompasses all events which might lead Debian to
lose access to relevant hardware. It's not just about faults with a
piece of equipment.
* Lennart Sorensen:
> There are a lot of 32bit powerpc chips still going into embedded systems
> being built today. They are not going away anytime soon.
Do they implement the ISA required by the existing Debian port?
* Guido Günther:
> Note that the only (as to my understanding) serious regression has been
> pointed out by Florian as well:
>
> https://lists.debian.org/debian-lts/2015/11/msg00037.html
> https://bugzilla.redhat.com/show_bug.cgi?id=1260698
>
> and it's unclear if this part of the ABI.
The security team has concerns that docker.io cannot be maintained in
jessie.
I asked upstream about the Go version commitment (we cannot rebase to
Go 1.4 or later in jessie because it could break user code):
https://groups.google.com/forum/#!topic/docker-dev/BjNmlgifZ5c
(Not sure if this
* Philipp Kern:
On Wed, Jan 04, 2012 at 07:48:27AM +0100, Florian Weimer wrote:
* Adam D. Barratt:
Apologies if I'm missing something, but if the packages are already in
the queue on security-master, wouldn't it be simpler (and possibly more
logical) to release them from there? Hmmm
* Sam Hartman:
Florian Weimer noticed that the krb5 changelog in squeeze was missing a
CVE that was fixed in the patch applied.
He proposes to make a new upload that corrects the changelog so that
people who track security issues from the changelog will find the fix:
Sorry, there seems
* Sam Hartman:
Florian == Florian Weimer f...@deneb.enyo.de writes:
Florian * Sam Hartman:
Florian Weimer noticed that the krb5 changelog in squeeze was
missing a CVE that was fixed in the patch applied. He proposes
to make a new upload that corrects the changelog so
* Adam D. Barratt:
On Tue, 2012-01-03 at 20:09 +0100, Florian Weimer wrote:
* Sam Hartman:
Florian Weimer noticed that the krb5 changelog in squeeze was missing a
CVE that was fixed in the patch applied.
He proposes to make a new upload that corrects the changelog so that
people who
* Adam D. Barratt:
Apologies if I'm missing something, but if the packages are already in
the queue on security-master, wouldn't it be simpler (and possibly more
logical) to release them from there? Hmmm, looking at the tracker,
maybe because they're just DoS issues?
Yes, and we'd have to
* Philipp Kern:
sun-java6 is sadly still a very high profile package. I won't go and
break all those installations which force sun-java6 over openjdk-6
locally, either in unattended installations or through other means.
It's really unfortunate that most of those installations seem to need
* Matthias Klose:
On 12/11/2011 01:07 PM, Holger Levsen wrote:
Hi,
On Sonntag, 11. Dezember 2011, Philipp Kern wrote:
sorry, but I'd rather like to have an announcement that it has a bug,
me too, for all the reasons Philipp noted.
It's also trivial to download the fixed jdk from
* Moritz Mühlenhoff:
Florian, what's the status of openjdk6 for stable/oldstable?
I've released the pending update for squeeze. lenny will eventually
follow, and so will the pending updates for squeeze, but judging by my
past performance, it will take a while.
If someone else wants to work on
* Moritz Muehlenhoff:
As for stable/oldstable: I noticed that Red Hat provided packages for
update 29 for RHEL 4 (RHEL 5 onwards use OpenJDK):
http://lwn.net/Articles/463919/
If anyone remembers the rationale behind the DLJ, perhaps they can
check if the current BCL matches our needs, too?
* Dominic Hargreaves:
Okay, then we should release a DSA for it, so that the breakage is
more easily blamed on this particular change, and that it's less
confusing if we have to issue follow-up DSAs. Perhaps late May or
early June would be a convenient release date?
Wasn't the earlier
* Adam D. Barratt:
I do share Florian's concern about the potential breakage as a result of
the change. Do we have any idea how many packages in {old,}stable would
be affected and to what degree? Particularly in the case of oldstable,
with its four month update cycle, fixing packages broken
* Martin Pitt:
PostgreSQL just announced new microreleases which fix one security
issue and several bugs. Details at
http://www.postgresql.org/about/news.1289
I already uploaded 8.4.7 and 9.0.3 to unstable with the fixes.
I prepared a lenny update in [1] which is ready for upload. I
* Martin Pitt:
Florian Weimer [2011-02-01 23:36 +0100]:
You've confused the versions, I'm afraid.
Erk, sorry. That was just in the email, though.
For lenny, we need an 8.3 update.
http://people.debian.org/~mpitt/psql/lenny/ has 8.3.14, as it should
be.
Want me to dput this?
Yes
* tony mancill:
On 01/14/2011 11:46 AM, Florian Weimer wrote:
* tony mancill:
As per Section 5.8.5 of the Developer's Reference, I'd like to get
confirmation from the Security Team that they are anticipating and
approve of the upload of the new source version. (My apologies if this
has
* Matthias Klose:
get the files from testing/unstable touch debian/control.in
debian/rules debian/control
I end up with this:
mkdir -p /tmp/buildd/openjdk-6-6b18-1.8.3/build/plugin/icedteanp \
cd /tmp/buildd/openjdk-6-6b18-1.8.3/build/plugin/icedteanp \
* Torsten Werner:
Hi,
On Sun, Jan 16, 2011 at 11:09 AM, Julien Cristau jcris...@debian.org wrote:
How does that follow? These kinds of updates are sort of allowed for
sun-java6 because it's non-free so there's no choice. That does not
apply to openjdk, as far as I know.
I think that
* Florian Weimer:
AFAICT, Debian is actually shipping IcedTea releases, but those are
re-rebranded as IcedTea.
Sorry, re-rebranded as OpenJDK.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
* tony mancill:
As per Section 5.8.5 of the Developer's Reference, I'd like to get
confirmation from the Security Team that they are anticipating and
approve of the upload of the new source version. (My apologies if this
has already been covered; I joined the thread already in progress.)
I would like to make an upload of eglibc to address DSA-2122-2 (the
first round of patches for the $ORIGIN/LD_AUDIT issue does not cover
all corner cases, unfortunately). The changes match those in
2.7-18lenny7, which are based almost verbatim on the upstream patches
(except for whitespace
* Adam D. Barratt:
On Wed, 2010-12-01 at 16:12 +, Florian Weimer wrote:
* Julien Cristau:
On Mon, Nov 22, 2010 at 12:11:43 +0100, Giuseppe Iuculano wrote:
Release Team,
Would this be an acceptable change for a freeze exception?
Yes (assuming it's properly tested).
Okay
* Julien Cristau:
On Mon, Nov 22, 2010 at 12:11:43 +0100, Giuseppe Iuculano wrote:
Release Team,
Would this be an acceptable change for a freeze exception?
Yes (assuming it's properly tested).
Okay, I'll test an isolated backport tomorrow, using the hardware in
question.
--
Florian
* Martin Pitt:
Please let me know how to proceeed with the security update.
Please upload the lenny part to security-master.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
* Julien Cristau:
I've got a few changes queued up for xorg-server in lenny, and was
wondering if it's worth uploading them at some point soonish. I guess I
could add the fix for CVE-2009-1573 (a minor bug in xvfb-run).
Yes, please do. Thanks for taking care of these bugs.
--
To
* Philipp Kern:
Florian,
On 08/08/2010 11:21 AM, Florian Weimer wrote:
Cool, it's based on OpenJDK 6b18. However, we can't upload it as-is
because the version number is greater than the one in testing.
apart from the fact that this could of course be solved by an upload
to t-p-u
* Matthias Klose:
Or does everybody see openjdk as an alibi for Debian to build things
and then use the sun-java packages from non-free?
I know folks who use it in production, admittedly with compiler
excludes to work around some C2 bugs.
For those who are interested in an openjdk-6 update
* Matthias Klose:
On 21.11.2009 06:20, Florian Weimer wrote:
* Steve Langasek:
It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.
My personal impression
* Steve Langasek:
It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.
My personal impression is that Debian does not view this issue as
critical, either.
* Carlos O'Donell:
The nptl enabled hppa libc packages are in experimental.
e.g.
apt-get -t experimental install libc6
Out of curiosity, does this version support cross-process mutexes?
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe.
* Florian Weimer:
Right. Please upload opensaml2 first (after sending in a source
debdiff for review), and then wait with uploading shibboleth-sp2 until
we tell you it's okay to do so.
It's now possible to upload shibboleth-sp2 to security-master. Thanks
for your assistance
* Faidon Liambotis:
Florian Weimer wrote:
Right. Please upload opensaml2 first (after sending in a source
debdiff for review), and then wait with uploading shibboleth-sp2 until
we tell you it's okay to do so.
OK, will do. How should we handle the fact that the newer xmltooling is
breaking
* Faidon Liambotis:
Please note that this fix is in a header file in a function that's
inlined, so after this update is accepted (assuming it's accepted),
shibboleth-sp2 in stable will need to be rebuilt against the new version
of opensaml2. I understand that this can be done via the
* Martin Pitt:
My gut feeling is that it should go through s-p-u (Debian), and
-proposed (Ubuntu) and be copied to -updates after some time of
testing.
After conferring with Tom Lane from upstream, I lean towards releasing
a DSA.
Please contact security@ when you've got packages which you
* Luk Claes:
The most important issues seems to be that ghc6 FTBFS on ia64 [1].
Is ia64 a registerized build (if this GHC-ism is still relevant)?
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
* Luk Claes:
Florian Weimer wrote:
* Luk Claes:
The most important issues seems to be that ghc6 FTBFS on ia64 [1].
Is ia64 a registerized build (if this GHC-ism is still relevant)?
You apparently did not include the footnote. Though if you want to ask
if it has a buildbot
* Jonathan McDowell:
I'd like to upload a new onak package to stable to fix #520117 by
rebuilding against db4.5 instead of db4.6 - I'm hitting what seems to be
#510270 in db4.6.
Shouldn't this be fixed in db4.6 instead?
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
Hi,
I'd like to upload 1:9.5.1.dfsg.P2-1 to stable-proposed-updates (as
1:9.5.1.dfsg.P2-1+lenny1) to fix a bug in DLV processing. We can then
point users to this version if they use dlv.isc.org and experience
resolution failures for .gov:
* Florian Weimer:
Hi,
I'd like to upload 1:9.5.1.dfsg.P2-1 to stable-proposed-updates (as
1:9.5.1.dfsg.P2-1+lenny1) to fix a bug in DLV processing. We can then
point users to this version if they use dlv.isc.org and experience
resolution failures for .gov:
https://lists.dns-oarc.net
* Luk Claes:
I would like to make an upload to stable to fix bug 503992 of Snort. Basicly,
this bug was introduced with the patch for a security vulnerability but
introduced a sigsegv due to an improper call to a function. This error kills
the Snort IDS as soon as it receives fragmented
* Javier Fernández-Sanguino Peña:
It's probably a security bug on its own, so it probably should go
through the DSA process, even though the bug was introduced through
t-p-u before the lenny release.
Since Neil answered already I uploaded the packages to stable using the patch
I sent. If
* Florian Weimer:
Would those who have an interest in this topic please test the patch
in
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=97;bug=514807;mbox=yes
and report if it improves things for them? Thanks.
For the record, it's very likely that we are soon to release updates
Would those who have an interest in this topic please test the patch
in
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=97;bug=514807;mbox=yes
and report if it improves things for them? Thanks.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of
* Bastian Blank:
GnuTLS stopped accepting MD5 as a proper signature type for certificates
just two weeks before the release. While I don't question the decision
themself, MD5 is broken since 4 years, I question the timing.
GNUTLS has rejected RSA-MD5 signatures in X.509 certificate chains
* Moritz Muehlenhoff:
And there is also the option of including it in the first point release,
after a month or two of testing in unstable.
Since the replay attack isn't exactly grave, it could just as well be added
into 5.0.1 oder 5.0.2 once it has gotten some testing.
And if Valid-Until
* Eugene V. Lyubimkin:
Florian Weimer wrote:
And if Valid-Until is only checked against the real-time clock, the
attacker can still feed bad data over NTP, so it's not even a complete
defense. 8-(
However, it seems there is no better solution, or is there?
A counter in the style
* Nicolas François:
Release Managers, Security Team:
Do you want 505071 to be fixed also for Lenny?
Do you mean etch instead of lenny?
We'd probably release a DSA once there's a patch which has some track
record, but as far as I can tell, the issue has not been fully
analyzed yet. You guard
* Matthias Klose:
- s390: rebuilt by hand on raptor/unstable without problems.
Bastian pointed to #479952 as a possible reason. would it
be possible to do a test-rebuild on the machine which is
used security updates?
I think we can apply a real security patch to all the Sun-based
* Matthias Klose:
Well, you know that there is a T2000 available and if the security team
needs a faster buildd they have to ask.
the estimate is wrong.
I what sense? I quoted the actual build time on lebrun. Is spontini
really faster than that?
the openjdk-6 package runs the testsuite.
* Luk Claes:
Matthias Klose wrote:
proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a
copy of the openjdk-6 package with the cacao sources
included. Compared to openjdk-6 on architectures without the Hotspot
JIT support, cacao-oj6 (including a JIT) is a much faster JVM on
* Matthias Klose:
So, we are late with OpenJDK for lenny. I still think lenny would
benefit from having OpenJDK. I'm proposing the following steps,
realizing that not all of them probably can be realized.
Is there upstream security support for OpenJDK 6? I'm asking because
the DLJ stuff used
* Pierre Habouzit:
Isn't it risky for partial upgrades from etch ? Shouldn't we wait for
lenny+1 to revert this ?
I second that, please don't revert the patch until lenny+1. FWIW I
believe the release team as a whole wanted the patch to be kept as well,
but I'll let the other members
$ wget
http://ftp.us.debian.org/debian/dists/etch/main/binary-mipsel/Packages.bz2
$ bzcat Packages.bz2 | grep '^[^ ][^:]*$'
133270:ides a wizard that helps you
133274:eror is the file manager for the K Desktop Environment.
$
Something has been garbled. Other architectures do not suffer from
* Steve Langasek:
If you can tell me how to do this without downloading dozens of MB of
data, I'll do it.
Well, it would've been easier if the addition of db4.5 symbol versions had
been accompanied by a shlibs bump,
Yeah, but this was a bug I tried to fix. 8-/
but something like this
* Bastian Blank:
On Mon, Oct 15, 2007 at 03:11:20PM +0200, Florian Weimer wrote:
Would you please schedule bin-NMUs for radiusd-livingston and libtabe on
all architectures?
(There might be more packages affected on other architectures, but I
can't easily search for them.)
You should
db4.3 4.3.29-9 went into testing despite an RC bug (#442297). The bug
is fixed in version 4.3.29-10. Could you please bump the urgency so
that this rectified soon? Thanks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Steve Langasek:
The bug is fixed in version 4.3.29-10. Could you please bump the urgency
so that this rectified soon? Thanks.
Bumping the urgency won't change the fact that the package failed to build
on the hppa autobuilder.
This has been an going problem since version 4.3.29-1 at
* Steve Langasek:
On Fri, May 25, 2007 at 07:30:36PM +0200, Florian Weimer wrote:
I'd like to do a sourceful (i.e. non-binary-only) NMU of rlwrap for
etch r1, so that the package gets rebuilt on all architectures.
Queing binary NMUs is apparently not enough to fix this issue.
Why not? Were
I'd like to do a sourceful (i.e. non-binary-only) NMU of rlwrap for
etch r1, so that the package gets rebuilt on all architectures.
Queing binary NMUs is apparently not enough to fix this issue.
Would that be acceptable?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Compared to the version in testing, debsecan 0.4.7 offers translation
updates and the following bug fix.
TIA,
Florian
Fri Mar 2 22:00:56 CET 2007 Florian Weimer [EMAIL PROTECTED]
* Migrate /var/lib/debsecan away from root permissions unconditionally.
diff -rN -u old-debian/debian
* Moritz Muehlenhoff:
glibc 2.3.4 introduced more secure heap management, which renders several
code injection attacks moot.
I think these additional checks have already been bypassed. Shall I
dig up a reference?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
The IETF Secretariat will soon reject Internet-Drafts formatted using
the etch's version of xml2rfc (because of an outdated boilerplate).
The new upstream version in unstable should generate acceptable
drafts. Unfortunately, the diff is quite large. If it's not possible
to accept the new
I recommend to add a note urging people to switch to BIND 9 (possibly
mentioning check-names ignore, which is one of the larger hurdles
IIRC).
The main reason is this bug:
CVE-2006-0527 (BIND 4 (BIND4) and BIND 8 (BIND8), if used as a target
forwarder, ...)
- bind 1:8.4.7-1 (low)
* Bastian Blank:
Not possible without another large round of testing. Our infrastracture
currently expects that the upstream part of the version remains
the same through the whole cycle. This information is for example used
to find all patches.
Uhm, why can't you do a simple full upload just
* Frederik Schueler:
As we need to upload a new orig.tar.gz file, we need to rename the
source package.
Huh? Non sequitur.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Martin Schulze:
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.
While you are at it, you could also include this patch:
Revision: 8001
* Martin Schulze:
When there is no cups for amd64 in the release, it does not matter
whether it FTBFS on amd64 or not, for example.
I believe that such FTBFS bugs are already deemed important; they
are not release-critical. A lot of porters who file FTBFS bugs
disagree, but this doesn't make
* Martin Schulze:
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
* Russ Allbery:
Is this bug fixed in xdelta 2.0?
xdelta 2 is a completely different beast.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
* Matthias Klose:
Does it change the internal representation of std::string, or some
other template instantiation provided by libstdc++?
I don't see a change to the internal representation of std::string,
I'm forwarding this upstream.
std::string seems to be fine because the instance is
* Nathanael Nerode:
* removal of non-free docs etc. from all packages
IIRC, the release goal is to release without GNU FDL documentation
only, not to remove all non-free documentation. At least I'm not
aware of a coordinated effort in that direction.
--
To UNSUBSCRIBE, email to [EMAIL
* Matthias Klose:
The change does not have an effect on symbols exported from
libstdc++, but it does have an effect on symbols exported by
libraries which use containers (using an allocator) from the
template headers.
Does it change the internal representation of std::string, or some
other
* Steve Langasek:
Heh. Would it be worth posting summaries of the unfixed RC security bugs
somewhere from time to time, to try to get more people involved with NMUing
them? Or are most of these not RC security bugs at this point?
There is http://idssi.enyo.de/tracker/status/release/unstable
* Thomas Bushnell:
What is expected of me with respect to bug 284925? I would like to
close it; a DSA was given for the version in stable, it refers to
woody only, etc, something like that. I don't understand the details,
but I'd like to close it. What should I do?
You should acknowledge
* Nathanael Nerode:
Note the following apparent facts:
* libssl0.9.7 and libssl0.9.8, if linked in the same binary, will cause
unpredictable failure due to symbol conflicts.
* This could be fixed if libssl0.9.8 had versioned symbols, which it doesn't
yet.
Are you sure? I think it's not
* Branden Robinson:
On Fri, Sep 23, 2005 at 12:10:00AM +0100, Colin Watson wrote:
I hereby tender my resignation as Debian Release Manager.
Thanks for your outstanding service, Colin. Reinventing the team
mid-release was not easy, but you and Steve didn't flinch from it and did a
great
* Steve Langasek:
Of course security support is essential for released architectures,
I don't think this is the case. Apparently, we have successfully
without security support, therefore it cannot be essential.
It's desirable, sure, but essential? Certainly not.
--
To UNSUBSCRIBE, email
* Gerfried Fuchs:
I was told that gnupg might be updated for sarge with the version from
unstable. Please be aware that the gnupg version has changed some of its
locale strings on which t-prot depends for doing its work.
Huh? In this case, t-prot is fundamentally borken. It should use
severity 303131 serious
thanks
* Steve Langasek:
Sure, tagged for removal.
Thanks. Is it possible that the removal is deferred by the freeze?
madison on merkel says that the package is still in testing.
(I can bump #303131 to severity serious if this helps. IIRC, due to
synchronization
In effect, the IETF Secretariat requires that very specific versions
of xml2rfc are used when you submit Internet-Drafts, which include the
prescribed boilerplate texts in the generated documents. I expect
that the required boilerplates change again in the short term (mainly
because of their
* Clint Adams:
db4.2:
#232305: libdb4.2: Hangs on SMP (HyperThreaded P4) system using slapd
2.1.25-1
There doesn't seem to be a fix for this? Or did I miss
something?
AFAICS, this is fixed with changing configure to never link to pthread,
and not using LD_ASSUME_KERNEL.
* Laszlo Boszormenyi:
Why can't we treat security support like a broken package, and remove
it if it isn't fixed by its maintainers?
Because you miss the point. You remove the package from the archive,
and not from the users' system. So the users would be still vulnerable,
and everyone
Hi,
it seems that the lack of security buildds is the biggest obstacle to
the sarge release.
Why can't we treat security support like a broken package, and remove
it if it isn't fixed by its maintainers? I hate this approach as much
as the next guy, but it might be the only way to make progress
* Martin Schulze:
Florian Weimer wrote:
* Andreas Barth:
So, the only thing left now is pgp5i in non-US/non-free (and AFAICS this
can't go to non-free).
What's the security patching status of pgp5i?
What are you referring to?
I've checked in the meantime. The RNG issue has been
* Andreas Barth:
So, the only thing left now is pgp5i in non-US/non-free (and AFAICS this
can't go to non-free).
What's the security patching status of pgp5i?
* Colin Watson:
On Sat, Oct 02, 2004 at 02:59:13PM +0200, Noèl Köthe wrote:
wget = 1.9.1-4 (which is in sarge and frozen) had a security problem
(#261755) which is fixed in -6 and -7 (right now in incoming). -5 had
the first fixing patch but was not multibyte aware (#271931).
Jan Minar
100 matches
Mail list logo
