[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#681563: marked as done (unblock: eglibc/2.13-35)

Your message dated Fri, 17 Aug 2012 12:39:05 +0100
with message-id <514d05d1df9a7f22a819976131e98cc4@mail.adsl.funky-badger.org>
and subject line Re: Bug#681563: unblock: eglibc/2.13-34
has caused the Debian Bug report #681563,
regarding unblock: eglibc/2.13-35
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
681563: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681563
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock

eglibc/2.13-34 has been uploaded in time for going to testing [1] and
got an freeze exception. However it is blocked due to 'block-udeb'. As
this version doesn't change anything wrt debian-installer, would it be
possible to get it unblocked?

Then it would be possible to upload a fix for RC bug #681113 (already
committed by Petr in SVN) and for security issues from bug#681473 (once 
I have time to look at it), otherwise it means the upload has to go
through t-p-u.

[1] http://lists.debian.org/debian-devel-announce/2012/06/msg00009.html

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

--- End Message ---
--- Begin Message --- 
On 17.08.2012 12:26, Aurelien Jarno wrote:

On Thu, Aug 16, 2012 at 07:29:21PM +0100, Adam D. Barratt wrote:

-Priority: standard
+Priority: required
 Description: Transitional package to ensure multiarch compatibility
Does this change (which doesn't appear to be mentioned in the changelog, 
btw) have any practical impact?


It appears in the changelog as:
   * control.in/main: switch multiarch-support to priority: required.
Closes:
     #677624.
You're (obviously) absolutely correct. I somehow failed to see that, despite reading straight past it multiple times *sigh* 


It has been done to conform to the policy, as all multiarch packages
(pre-)depends on it, some of them being of priority required. Actually this is probably an RC bug (policy violation). The only practical impact I see is that the package is downloaded by debootstrap directly instead 
of being downloaded as a dependency of other packages.
It's a policy violation that's not always applied much. Thanks for the explanation.
+ * patches/arm/unsubmitted-ldconfig-cache-abi.diff: disable, as it will 
+    conflict with upstream x32 support.

The earlier discussion on this mentioned regenerating the ldconfig
caches to ensure that mixed armhf / armel systems continued to work as expected. Does that need doing as a result of this change, or once the 
updated patch is accepted upstream?


This has to be done once the updated patch is accepted upstream.
Actually it's something already done in the postinst of libc6, though
maybe we'll have to do it slightly earlier.


Okay; thanks.

Unblocked.

Regards,

Adam

--- End Message ---
Reply to: