Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload
On Mon, Jul 18, 2016 at 07:41:54PM +0200, Andreas Metzler wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: britney > > Hello, > > I have been wondering why hugin 2016.2.0~rc1+dfsg-2 (urgency=low) will > be considered for testing migration after only 5 days and I think I found > the reason. > > Testing has 2016.0.0+dfsg-1, which was followed by > [2016-07-16] 2016.2.0~rc1+dfsg-2 in unstable (low) > [2016-07-11] 2016.2.0~rc1+dfsg-1 in experimental (low) > [2016-06-04] 2016.2.0~beta1+dfsg-1 in experimental (medium) > > britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium > urgency and chose to consider this urgency for sid->testing migration. > > I think that is a bug, especially as dch uses medium by default for > uploads to experimental. > > cu Andreas Does it remember or does it parse the changelog and use the highest priority since the version in testing? The hugin changelog contains the urgency=medium entry so this seems a valid urgency to use. MfG Goswin
ia32-libs update for lenny
Hi, I've prepared an ia32-libs update for lenny and Frederik Schueler will sponsor the upload soon. The upload brings ia32-libs back in sync with the packages contained in stable, stable security and stable-proposed-updates. The only other change to the binaries is fixing a broken symlink so ia32-libs works on ia64 at all (#563402). As you can see below there are quite a number of bugs and security bugs fixed by this upload. The upload contains updates from the following packages: Source 2.7 2.7+lenny1 -- attr2.4.43-12.4.43-2 audiofile 0.2.6-7 0.2.6-7+lenny1 cairo 1.6.4-6 1.6.4-7 cups1.3.8-1 1.3.8-1+lenny7 cyrus-sasl2 2.1.22.dfsg1-21 2.1.22.dfsg1-23+lenny1 dbus1.2.1-3 1.2.1-5+lenny1 directfb1.0.1-9 1.0.1-11 e2fsprogs 1.41.0-31.41.3-1 expat 2.0.1-4 2.0.1-4+lenny3 fontconfig 2.6.0-1 2.6.0-3 freetype2.3.7-2 2.3.7-2+lenny1 gcc-4.3 4.3.1-9 4.3 4.3.2-1.1 glibc 2.7-13 2.7-18lenny2 gnutls262.4.1-1 2.4.2-6+lenny2 hal 0.5.11-30.5.11-8 isdnutils 3.9.20060704-3.43.9.20060704-3.6 jack-audio-connection-kit 0.109.2-3 0.109.2-5 keyutils1.2-7 1.2-9 krb51.6.dfsg.4~beta1-4 1.6.dfsg.4~beta1-5lenny2 lcms1.17.dfsg-1 1.17.dfsg-1+lenny2 libaio 0.3.106-8 0.3.107-3 libdrm 2.3.1-1 2.3.1-2 libnss-ldap 261-2 261-2.1 libpam-ldap 184-4.1 184-4.2 libpng 1.2.27-11.2.27-2+lenny2 libselinux 2.0.65-42.0.65-5 libtool 1.5.26-41.5.26-4+lenny1 libusb 0.1.12-12 0.1.12-13 libwmf 0.2.8.4-6 0.2.8.4-6+lenny1 libx11 1.1.4-2 1.1.5-2 libxcb 1.1-1.1 1.1-1.2 libxi 1.1.3-1 1.1.4-1 libxml2 2.6.32.dfsg-3 2.6.32.dfsg-5+lenny1 mesa7.0.3-5 7.0.3-7 nas 1.9.1-4 1.9.1-5 ncurses 5.6+20080804-1 5.7+20081213-1 openldap2.4.10-32.4.11-1+lenny1 openssl 0.9.8g-13 0.9.8g-15+lenny6 pam 1.0.1-4 1.0.1-5+lenny1 pulseaudio 0.9.10-20.9.10-3+lenny1 sane-backends 1.0.19-17 1.0.19-23 tiff3.8.2-113.8.2-11.2 xorg7.3+15 7.3+20 The other packages in ia32-libs remain unchanged. MfG Goswin -- -- Format: 1.8 Date: Tue, 26 Jan 2010 12:05:22 +0100 Source: ia32-libs Binary: ia32-libs ia32-libs-dev lib32gcc1 Architecture: source amd64 Version: 2.7+lenny1 Distribution: stable Urgency: low Maintainer: Debian ia32-libs Team Changed-By: Goswin von Brederlow Description: ia32-libs - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-dev - ia32 development libraries and headers for use on ia32/ia64 syste lib32gcc1 - GCC support library (ia32) Closes: 563402 Changes: ia32-libs (2.7+lenny1) stable; urgency=low . [ Goswin von Brederlow ] * Update to match versions in lenny + security + proposed-updates. * Fix ld-linux.so.2 link for ia64. (Closes: #563402) * Add misc depends for debhelper. * Add lots of lintian overrides where nothing can be done about them. * Bump debhelper compat to 5. * Bump minimum libc6-i386 dependency to 2.7-18lenny1. . * Incudes security fixes for: CVE-2008-3529 CVE-2008-3639 CVE-2008-3640 CVE-2008-3641 CVE-2008-3834 CVE-2008-3964 CVE-2008-4225 CVE-2008-4226 CVE-2008-4311 CVE-2008-4311 CVE-2008-4989 CVE-2008-5077 CVE-2008-5286 CVE-2008-5824 CVE-2008-5907 CVE-2009-0040 CVE-2009-0163 CVE-2009-0581 CVE-2009-0590 CVE-2009-0688 CVE-2009-0723 CVE-2009-0733 CVE-2009-0844 CVE-2009-0845 CVE-2009-0846 CVE-2009-0847 CVE-2009-0887 CVE-2009-0946 CVE-2009-1189 CVE-2009-1364 CVE-2009-1377 CVE-2009-1378 CVE-2009-1379 CVE-2009-1386 CVE-2009-1894 CVE-2009-2285 CVE-2009-2347 CVE-2009-2347 CVE-2009-2409 CVE-2009-2414 CVE-2009-2625 CVE-2009-2730 CVE-2009-2820 CVE-2009-3560 CVE-2009-3560 CVE-2009-3720 CVE-2009-3736 CVE-2009-4212 CVE-2009-4355 CVE-2010-0015 STR #2911 STR #2974 STR #2918 STR #2919 STR #2966 GNUTLS-SA-2008-3 GNUTLS-SA-2009-4 MIT-KRB5-SA-2009-004 MITKRB5-SA-2009-0001 MITKRB5-SA-2009-002 . * Includes bugfixes for: 248172 295173 313697 319554 368560 394068 401092 401296 429739 4
Re: ia32-libs update for lenny
Hi again,
Martin Zobel-Helas mentioned I should have added a full diff for
approval. Well, the full diff would be basically the full 282MiB source
package as it contains all the deb and orig.tar.gz of the packages. You
can download it from mentors.debian.net.
I listed all the packages changed in my previous mails and you (or the
security team) already approved each one individually. For a diff of
each please look at each package yourself. The diff of the non-binary
stuff, also visible via
http://svn.debian.org/viewsvn/pkg-ia32-libs/branches/lenny/ia32-libs/,
is attached below. The only chunk not related to updates of the
contained debs or lintian is this one:
--- ia32-libs/debian/rules (revision 358)
+++ ia32-libs/debian/rules (revision 362)
@@ -143,7 +141,7 @@
# Link the ld.so into place
mkdir -p $(DEST)/lib/
- ln -s $(ROOT)lib$(SUFFIX)/ld-2.3.2.so $(DEST)/lib/ld-linux.so.2
+ ln -s $(ROOT)lib$(SUFFIX)/ld-linux.so.2 $(DEST)/lib/ld-linux.so.2
ifneq (/,$(ROOT))
# Move uname into place
which fixes the broken symlink on ia64 so the ld.so can be found again,
a grave bug.
MfG
Goswin
--
Index: ia32-libs/debian/control
===
--- ia32-libs/debian/control(revision 358)
+++ ia32-libs/debian/control(revision 362)
@@ -8,7 +8,7 @@
Package: ia32-libs
Architecture: amd64 ia64
-Pre-Depends: dpkg (>= 1.13.21)
+Pre-Depends: ${misc:depends}, dpkg (>= 1.13.21)
Depends: lsb-release, lib32gcc1, ${lib:Depends}
Replaces: ia32-libs-openoffice.org, ia32-libs-dev (<< 1.6), nvidia-glx-ia32
(<< 1.0.8774-7)
Conflicts: ia32-libs-dev (<< 1.6), nvidia-glx-ia32 (<< 1.0.8774-7)
@@ -21,14 +21,14 @@
Package: ia32-libs-dev
Architecture: ia64
Section: libdevel
-Depends: ia32-libs (= ${Source-Version})
+Depends: ${misc:depends}, ia32-libs (= ${Source-Version})
Description: ia32 development libraries and headers for use on ia32/ia64
systems
This package contains headers and development libraries for building
32-bit ia32 applications on amd64/ia64 Debian systems.
Package: lib32gcc1
Architecture: ia64
-Depends: ia32-libs (= ${Source-Version})
+Depends: ${misc:depends}, ia32-libs (= ${Source-Version})
Description: GCC support library (ia32)
Shared version of the support library, a library of internal subroutines
that GCC uses to overcome shortcomings of particular machines, or
Index: ia32-libs/debian/compat
===
--- ia32-libs/debian/compat (revision 0)
+++ ia32-libs/debian/compat (revision 362)
@@ -0,0 +1 @@
+5
Index: ia32-libs/debian/extract-changlogs.sh
===
--- ia32-libs/debian/extract-changlogs.sh (revision 0)
+++ ia32-libs/debian/extract-changlogs.sh (revision 362)
@@ -0,0 +1,61 @@
+#!/bin/sh
+
+while read PKG VER; do
+ ( cd srcs/t/${PKG}*/
+dpkg-parsechangelog --since $VER | sed 's/^/#/' \
+| while read LINE; do
+case "$LINE" in
+ ("# .") echo "# ";;
+ ("# "*) echo "$LINE";;
+ ("# "*) echo "$LINE" | while read foo PKG VER REL URG; do
+ echo "# [ $PKG $VER $REL $URG ]"
+done;;
+ esac
+done | cut -b3-
+echo
+ )
+done < libXaw7.so.7 instead of libXaw7.so.7.0.0
Index: ia32-libs/debian/rules
===
--- ia32-libs/debian/rules (revision 358)
+++ ia32-libs/debian/rules (revision 362)
@@ -1,11 +1,9 @@
#!/usr/bin/make -f
-export DH_COMPAT=4
-
DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
# Lowest version with fully ABI compatible libraries
-SHLIB_VERSION=2.4
+SHLIB_VERSION=2.7+lenny1
OSVER=$(shell lsb_release -s -i)
ifeq (Debian,$(OSVER))
@@ -24,7 +22,7 @@
# On amd64 some package compile 32bit debs directly.
# Skip converting them and Depend on them instead.
ifeq (amd64,$(DEB_HOST_ARCH))
- lib_depends = libc6-i386 (>= 2.3.6-2), lib32z1, lib32stdc++6, lib32asound2,
lib32ncurses5
+ lib_depends = libc6-i386 (>= 2.7-18lenny1), lib32z1, lib32stdc++6,
lib32asound2, lib32ncurses5
FILTER = zlib1g libc6 libgcc1 libasound2 libstdc++6 libncurses5
EXTRA_INSTALL =
else
@@ -143,7 +141,7 @@
# Link the ld.so into place
mkdir -p $(DEST)/lib/
- ln -s $(ROOT)lib$(SUFFIX)/ld-2.3.2.so $(DEST)/lib/ld-linux.so.2
+ ln -s $(ROOT)lib$(SUFFIX)/ld-linux.so.2 $(DEST)/lib/ld-linux.so.2
ifneq (/,$(ROOT))
# Move uname into place
Index: ia32-libs/sources.list.deb
===
--- ia32-libs/sources.list.deb (revision 358)
+++ ia32-libs/sources.list.deb (revision 362)
@@ -1,2 +1,8 @@
-deb http://ftp.de.debian.org/debian lenny main
-deb-src http://ftp.de.debian.org/debian lenny main
+deb ht
Re: ia32-libs update for lenny
Julien Cristau writes: > On Tue, Jan 26, 2010 at 15:42:22 +0100, Goswin von Brederlow wrote: > >>* Add misc depends for debhelper. >>* Add lots of lintian overrides where nothing can be done about them. >>* Bump debhelper compat to 5. > > These don't sound necessary for a stable update? > > Cheers, > Julien True. They just make it that much simpler to see that there are no serious errors hidden. All 3 are just to remove lintian warnings. The last also removes the debhelper warnings about compat prior to 5 being deprecated. They have no effect at all on the package build. If you insist I can remove them again but then the build log will contain a ton of extra warnings. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs update for lenny
"Adam D. Barratt" writes: > Hi, > > On Tue, 2010-01-26 at 15:42 +0100, Goswin von Brederlow wrote: >> I've prepared an ia32-libs update for lenny and Frederik Schueler will >> sponsor the upload soon. The upload brings ia32-libs back in sync with >> the packages contained in stable, stable security and >> stable-proposed-updates. The only other change to the binaries is fixing >> a broken symlink so ia32-libs works on ia64 at all (#563402). > > I notice that it's now been uploaded. Unfortunately, it's too late for > 5.0.4 so will get reviewed after the point release. > > Regards, > > Adam That really sucks. Mark Hymers promised he would (co)maintain ia32-libs and do stable/security updates but no sign of them for 6 month now. Should have given up earlier and do it myself I guess. And I guess I don't have to hurry with ia32-libs-gtk then eigther. Given the number of security fixes and their severity should I send this over to the security team so they will be available before the next point release? Or would they want something that only updates packages with security flaws? MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596132: nmu: ia32-libs_20090808
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, the build of ia32-libs for ia64 on the recent upload was broken and the dependencies of the package are wrong. This was a problem of the build environment and it should work fine on the buildds. nmu ia32-libs_20100905 . ia64 . -m "Rebuild to fix dpkg-shlibs generated dependencies" Thanks Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -- 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/20100908200728.5500.27917.report...@frosties.localdomain
Bug#611851: unblock: ia32-libs-core/20110202
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock packages ia32-libs-core, ia32-libs and ia32-libs-gtk.
The last upload made by Thijs Kinkhorst to fix security concerns and
to add the security repository to the sources ia32-libs updates from
introduced a small probelm in the fetch-and-build script. The problem
appears when more than one version of a source is known, i.e. when
squeeze and security have different versions. This has 4 effects:
1) both versions are downloaded and included in the source.
2) duplicate entries in copyright
3) duplicate entries in changelog
4) the next fetch-and-build run fails
I could live with the first 3 but the last would make security support
much more difficult.
I included a quick fix for this in fetch-and-build so only the newest
version is included:
==
diff --git a/fetch-and-build b/fetch-and-build
index 5c986bc..a1c642f 100755
--- a/fetch-and-build
+++ b/fetch-and-build
@@ -105,10 +105,24 @@ done \
*) SRC="$VAL";;
esac;;
"") echo >&2 "Fetching source $SRC $VER for $PKG"
- echo "$SRC=$VER";;
+ echo "$SRC $VER";;
esac
done \
-| sort -u | (cd srcs; xargs $APT_GET -d source) || exit 1 # Fetch source
+| { sort -u; echo; } \
+| while read SRC VER; do # Filter out old version of duplicate sources
+if [ "$SRC" = "$LAST_SRC" ]; then
+ if dpkg --compare-versions "$LAST_VER" "<<" "$VER"; then
+ echo >&2 "Skipping $SRC $LAST_VER for $VER"
+ LAST_VER="$VER"
+ else
+ echo >&2 "Keeping $SRC $LAST_VER for $VER"
+ fi
+else
+ echo "$LAST_SRC=$LAST_VER"
+ LAST_SRC="$SRC"
+ LAST_VER="$VER"
+fi
+ done | tail --lines +2 | (cd srcs; xargs $APT_GET -d source) || exit 1 #
Fetch source
##
# fetch prebuild debs
==
I also added Thijs Kinkhorst to debian/control since he asked to be
added to the team and offered to keep an eye on security uploads of
the ia32-libs packages for the next stable cycle. I hope that is ok
even this late in the game.
Other than that there are a number of new sources included:
util-linux (2.17.2-9)
eglibc (2.11.2-10)
* Revert incorrect upstream patch for CVE-2010-3847 and use the correct
set of patches:
ncurses (5.7+20100313-5)
pango1.0 (1.28.3-1+squeeze1)
* 01_CVE-2011-0020.patch: patch from Behdad Esfahbod to fix heap
corruption. #610792, CVE-2011-0020. LP: #696616.
I hope this can still be included in squeeze.
MfG
Goswin
PS: The sources are on mentors and need a sponsor for the upload. Thijs?
unblock ia32-libs-core/20110202
unblock ia32-libs/20110202
unblock ia32-libs-gtk/20110202
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (666, 'unstable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-debian-xen-1 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
--
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/20110202211409.25833.57544.reportbug@frosties.localnet
Bug#611851: unblock: ia32-libs-core/20110202
Philipp Kern writes: > On Thu, Feb 03, 2011 at 09:57:12AM +0100, Thijs Kinkhorst wrote: >> On Wed, February 2, 2011 22:14, Goswin von Brederlow wrote: >> > PS: The sources are on mentors and need a sponsor for the upload. Thijs? >> > unblock ia32-libs-core/20110202 >> > unblock ia32-libs/20110202 >> > unblock ia32-libs-gtk/20110202 >> I would sponsor this if the release team acks that it is still possible. > > Let's do that for 6.0.1. You can upload it, but it won't hit squeeze > at this point. > > The fetch-and-build fix can also be included in a future .1 upload, so you're > not stuck with that bug for the uploads thereafter. > > Kind regards > Philipp Kern That should then also go to security, at least the 2 packages with security fixes. MfG Goswin -- 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/87r5bpb62a.fsf@frosties.localnet
Re: Release goal proposal: Archive-wide build-arch and build-indep support
Niels Thykier writes: > On 2011-11-05 21:22, Niels Thykier wrote: >> >> Hi, >> >> I would like to propose the goal of getting archive-wide support for >> the optional debian/rules targets "build-arch" and "build-indep". >> The intention is to finally solve issues like #619284 and the goal >> is related to #629385. >> >> [...] >> >> To keep it attainable, the goal for Wheezy is to fix the subset of >> packages that would need to differentiate "build" and >> "build-arch"/"build-indep". Once we have the data available, we >> will put up a dd-list for the reduced set. >> >> [...] > > The reduced set is available thanks to some UDD queries. We are looking > at ~500 packages (see attached dd-list if some of your packages are there). > > The data is also available from[1], where you can also see the queries I > used to generate this set (see reduced-set.py). > > > Thanks for considering, > ~Niels > > [1] http://people.debian.org/~nthykier/rg-build-arch-target/ Have you considered (or already written) a lintian check for those targets? MfG Goswin -- 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/87ty64ml13.fsf@frosties.localnet
Re: Multiarch support in dpkg really in time for wheezy?
Michael Gilbert writes: > On Sat, Oct 29, 2011 at 7:10 AM, Stefano Zacchiroli wrote: >> What worries me is that there is multi-arch work in dpkg, work that has >> its origins in Debian. That work is ready enough to be deployed in >> popular Debian derivatives such as Ubuntu, but is not in Debian proper >> yet. That is bad for Debian morale and should be avoided. Moreover, that >> work is also considered ready enough by other dpkg co-maintainers, by >> the Release Team, and by various porters, which have all asked multiple >> times to have that work in the Debian archive. > > You could also make a case from a terminological perspective as well. > Unstable is where development in Debian is supposed to happen, so it's > perfectly acceptable to upload unfinished/unstable changes, and if you > happen to break something (at least with dpkg) you'll have hundreds of > eyes looking at what you broke and trying to figure out how to fix it. > So anyway, don't worry so much about breaking unstable. That's what > its there for. > > Best wishes, > Mike s/unstable/experimental/ Screwing up dpkg in unstable is too anoying to too many users and really not neccessary. But yes, multi-arch dpkg is way overdue. MfG Goswin -- 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/87ehwx5yi1.fsf_-_@frosties.localnet
Re: Multiarch support in dpkg really in time for wheezy?
Raphael Hertzog writes: > Hi, > > I'll try to share some news with the release team. > > On Sat, 22 Oct 2011, Guillem Jover wrote: >> What I'll do though, when I get back home tomorrow from my current >> trip, is to push already reviewed stuff and keep pushing incrementally, >> instead of my usual big pushes, so that the progress is more visible. > > This has been the case so far with regular progress every week. The last > changes have not been pushed on the master branch but on guillem's private > repository. > > http://git.hadrons.org/?p=debian/dpkg.git;a=shortlog;h=refs/heads/pu/multiarch/master > > The latest changes have been made today. About half of the multiarch > branch has already been merged on master. > >> The 1.16.2 will still happen, as planned, quicker than our usual 2 >> months between micro releases. > > According to this sentence, the last possible date for the 1.16.2 release > is today. > > Guillem, given that you're not yet over, can you try to set a new target? > > Cheers, Hi Raphael, could you maybe please just upload a multiarch dpkg to experimental without waiting for Guillem? If he wants to audit the changes before they go into unstable that is fine but it makes no sense not to test the code by more people already or to have them all search around for what git repository to use this week for the latest changes. Lets find and fix the bugs before Guillem has to audit them. MfG Goswin -- 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/87r50slgaj.fsf_-_@frosties.localnet
Re: aptitude plans for the squeeze cycle
Daniel Burrows writes: > On Sun, Aug 16, 2009 at 02:41:08PM +0200, Marc Brockschmidt > was heard to say: >> Heya, >> >> As announced on dda [RT1], we want to get an impression when releasing >> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December >> 2009, and some developers have noted that their planned changes wouldn't be >> possible in this time frame. So, to find out when releasing would work for >> most people, it would be great if you could answer the following questions: >> >> Do you have any big changes planned? How much time would they take, and >> what consequences are there for the rest of the project? > > The main thing is that I want to get aptitude 0.6.0 into squeeze. In > addition to some general fixes and improvements, the dependency solver > should run five times faster on large problems than the current release > of aptitude does. Hopefully this will mitigate the problems that I > heard about with it taking a long time to calculate the upgrade to > lenny. > > This means that I'll have to scale back my ambitions for that release. > Specifically, I don't think the GTK+ frontend will be ready to be the > default interface by December, so I've decided to focus on tying up > loose ends and getting a build put together where the GTK+ code is an > experimental add-on, not the default package (which mostly comes down > to adjusting package dependencies and alternative priorities). > > I'm currently finishing up some code to cache data that's been > downloaded for display in the UI, such as screenshots and changelogs. > I also want to disable the full-text search of package descriptions > by default; user feedback on that change has been uniformly negative. > Once those changes are in and tested, I think I'll be ready to > release 0.6.0. > >> How many "big" transitions will the upcoming changes cause? When should those >> happen? Can we do something to make them easier? > > I don't expect aptitude's changes to impact many other packages. > > The changes mostly fall into a few categories: > > (1) New GTK+ interface: purely a UI change, and won't be installed by > default in 0.6.0. > > (2) New searching code: as noted above, the full-text search will be > switched off. The whole search engine has been rewritten from > scratch; however, the search language should be the same as it > was before. > > (3) Dependency solver optimizations: should be transparent to users. > > (4) Dependency solver enhancements: tighter constraints can be > placed on what the solver returns, and the solver's treatment of > particular packages can be overridden in /etc/apt/apt.conf. > > Should not impact other packages, except that it makes it possible > to give hints to the resolver (this could be used to, e.g., > provide a recommended apt.conf stanza to make the upgrade smoother > and avoid known resolver problems). If the release team would > like different hints than the few that are available currently, I > would be happy to add some more knobs here. > > (5) General enhancements and bugfixes: I don't expect that these will > have an impact on other software. > > Daniel Any plans to work with Steve Langasek on the multiarch proposal? That would be a rather big change as well. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Lenny point release
Hi, please coordinate with Mark Hymers, the current ia32-libs and ia32-libs-gtk maintainer, about security and proposed updates in those two packages. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team: Release goals, schedule, state of the union
Raphael Hertzog writes: > On Wed, 26 Aug 2009, Matthijs Kooijman wrote: >> Or is the second step in this release goal of actually using the new source >> format for all (or at least a lot?) packages? > > Yes. I'd like to achieve this by changing dpkg-source to build 3.0 (quilt) > or 3.0 (native) source packages by default (generating a source package > using the old format would then require putting "1.0" in > debian/source/format). > > Cheers, > -- > Raphaël Hertzog Is that actualy a release goal for squeeze? If so then I would prefer if that where stated specifically and seperately to the goal of allowing 3.0 source packages at all. Allowing 3.0 format is long overdue imho and from what has been told just needs patches to be applied to DAK to b completed. Changing packages I believe will happen naturally after that and I would rather see a gradual adoption of the new format than brute forcing maintainer to change their packages before squeeze. The new format has enough advantages to stand on its own. Change dh_make and other package creating helpers so new packages default to 3.0 (quilt). Since blindly changing dpkg-source to use 3.0 format breaks packages maybe a better change would be to make a missing debian/source/format first a warning and then an error. But maybe that is just me. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please, unblock youtube-dl/2009.09.13-1
Rogério Brito writes: > Hi, Luk. > > On Nov 05 2009, Luk Claes wrote: >> Rogério Brito wrote: >> > So, I would appreciate if you could unblock youtube-dl/2009.09.13-1, as >> >> Will it survive interface/protocol changes? > > Really, I don't know and I can't give any assurance, but upstream is > quite active and responsive (I have already submitted some patches and > he was fast integrating changes and cleaning up the code). > > In other words, we have people looking after the package. > > > Regards, Rogério Brito. But will it remain functional for 1-3 years in stable/old-stable? MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFH: Multiarch capable toolchain as release goal
Hi, I would like to suggest a new release goal and hope that some DDs will advocate it. This one is actualy quite trivial but some convincing seems to be neccessary to get it done: # Multiarch capable toolchain Description: The toolchain should be ready to handle libraries and include files in the multiarch locations. Bug-Url: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369064 State: All done except for binutils. Patch exists. The toolchain support is needed so multiarch packages can be installed on a uniarch systems (what we now have) and people can still compile stuff. We are so near to having a multiarch capable toolchain and the only thing standing in the way of multiarch is ld not looking in all the directories. Having this in Lenny would mean that future multiarch packages could be used on / backported to Lenny without having to revert the multiarch paths. We already have all the runtime support in place and ld really is the last thing standing in the way. It would be such a shame to waste another release cycle before we can actualy start creating multiarch packages because of one lousy patch not getting applied. So please do voice your support. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Andreas Barth <[EMAIL PROTECTED]> writes: > * Goswin von Brederlow ([EMAIL PROTECTED]) [080415 20:34]: >> Description: The toolchain should be ready to handle libraries and >>include files in the multiarch locations. >> Bug-Url: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369064 >> State: All done except for binutils. Patch exists. > > Binutils are frozen for Lenny, so please no additional changes. > > > Cheers, > Andi > -- > http://home.arcor.de/andreas-barth/ Damn. And here I was hoping there were still time since only essential is frozen and binutils is optional. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
[EMAIL PROTECTED] (Lennart Sorensen) writes: > On Tue, Apr 15, 2008 at 09:03:54PM +0200, Andreas Barth wrote: >> * Goswin von Brederlow ([EMAIL PROTECTED]) [080415 20:34]: >> > Description: The toolchain should be ready to handle libraries and >> >include files in the multiarch locations. >> > Bug-Url: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369064 >> > State: All done except for binutils. Patch exists. >> >> Binutils are frozen for Lenny, so please no additional changes. > > I suspect by the time a fully working multiarch is done, x86 won't need > it anymore because everything will be fully 64bit. :) I would say we are already there big time. Users of ia32-libs do disagree though. But the usefullness of multiarch for x86_64-linux-gnu + i486-linux-gnu has taken a major dive since sarge (which is a good thing). > Now I suppose sparc and others might still like it if they have > performance advantages of 32bit code over 64bit code, in which case > keeping 64bit for only those programs where the extra address space is > worth it would be great. s390x, sparc64, mips64, mipsel64, ppc64 all have performance hits for 64bit code so one would limit 64bit binaries to what needs the address space. But then there is i486-linux-gnu + i486-linux-uclibc, x86_64-kfreebsd-gnu + x86_64-linux-gnu, arm-linux-gnu + armel-linux-gnu, ia64-linux-gnu + i486-linux-gnu and many other combinations. Recently there was also renewed interest in reviving the 64bit long, 32bit pointer code generation in gcc for amd64. That way you get all the speed benefits of the improved 64bit mode without the penalty of double sized pointers. That could be used to slimmen programs that don't need 64bit address space. So, while being far less in demand, multiarch still has huge benefits. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Ove Kaaven <[EMAIL PROTECTED]> writes:
> Andreas Barth skrev:
>> * Lennart Sorensen ([EMAIL PROTECTED]) [080415 22:26]:
>>> I suspect by the time a fully working multiarch is done, x86 won't need
>>> it anymore because everything will be fully 64bit. :)
>
> As Wine maintainer, I'd disagree with that.
>
>> People, we want to release soon. Anyone is welcome to hack on feature in
>> experimental, but please do not push for stuff to unstable which is
>> expected to break stuff. If it wasn't important enough to push it during
Have you read the patch? All it does is add more SEARCH_DIR("...");
entries to the /usr/lib/ldscripts/ and correct the entries that are
wrong now. The risk is virtually zero. Far far away from "expected to
break stuff".
>> the last 12 months, it isn't important enough to hold up the release
>> now.
It has been pushed since sarge. Unfortunately pushing doesn't mean
anything will give. The glibc and gcc teams where nice enough to add
the patches for multiarch support but binutils has just kept stubborn.
> The way I understand it, they HAVE been pushing... and pushing... for
> a long time... against a nonresponsive binutils maintainer. This
> thread is just their latest, last-ditch effort since nothing else
> worked so far. But I could be wrong, I guess.
You are right. The patch has been around for years and requests for any
response to the patch have just been ignored.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Andreas Barth <[EMAIL PROTECTED]> writes: > * Goswin von Brederlow ([EMAIL PROTECTED]) [080415 20:34]: >> Description: The toolchain should be ready to handle libraries and >>include files in the multiarch locations. >> Bug-Url: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369064 >> State: All done except for binutils. Patch exists. > > Binutils are frozen for Lenny, so please no additional changes. > > > Cheers, > Andi I hope you do agree that binutils will need a freeze exception for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476200 Otherwise etch -> lenny upgrades will fail without force-overwrite. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installing Debian Testing on Athlon64
Dhiraj Gaurh <[EMAIL PROTECTED]> writes: > Hi, > Sarge does contain kernel packages for amd64 but if you try to > download sarge, there is no directory for the amd64 architecture. Is > amd64 not yet fully supported by sarge ?? Do I need to install i386 > and then upgrade the kernel to amd64, then what about all the other > applications ? > Thanks a lot > Dhiraj > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] How about following the ports page and reading the amd64 FAQ? The amd64 kernel images in sarge are only 64bit kernels for use with i386 sarge. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: statistics of build-successful, but not uploaded yet packages
Kenshi Muto <[EMAIL PROTECTED]> writes: > Hi, > > I found some packages weren't uploaded from buildds in spite of they > were already built successfully (for example XEmacs21 with high level > security fix on mipsel). > > I created small script to verify wanna-build status and build log. > I put scripts and result on http://kmuto.jp/debian/upload_reminder/ ... > Kenshi Muto > [EMAIL PROTECTED] Does that show different entries than the list of packages in state uploading? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-listchanges in standard
Martin Michlmayr <[EMAIL PROTECTED]> writes: > ... I think apt-listchanges and its dependencies only need an > override change but maybe there's more I've overlooked. ... The override files need to changes so DAK outputs the right Packages file. The source needs to change so uploads don't complain and custom builds also have the right priority. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: statistics of build-successful, but not uploaded yet packages
Kenshi Muto <[EMAIL PROTECTED]> writes: > At Tue, 22 Feb 2005 17:39:14 +0100, > Goswin von Brederlow wrote: >> > I found some packages weren't uploaded from buildds in spite of they >> > were already built successfully (for example XEmacs21 with high level >> > security fix on mipsel). >> > >> > I created small script to verify wanna-build status and build log. >> > I put scripts and result on http://kmuto.jp/debian/upload_reminder/ > >> Does that show different entries than the list of packages in state >> uploading? > > Yes. > > My page shows: build done, but isn't signed by buildd maintainer. > > State upload shows: build done and sign done. Package will be uploaded > by cron. > > (My page will update every 0:00 JST and 12:00 JST.) > > Thanks, > -- > Kenshi Muto > [EMAIL PROTECTED] Right, I always forget that. But on that note could you add the packages in state uploading to the list. Sometimes things get lost on upload and it takes a long time for someone to notice too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: statistics of build-successful, but not uploaded yet packages
Kenshi Muto <[EMAIL PROTECTED]> writes: > At Wed, 23 Feb 2005 11:21:03 +0100, > Goswin von Brederlow wrote: >> Right, I always forget that. But on that note could you add the >> packages in state uploading to the list. Sometimes things get lost on >> upload and it takes a long time for someone to notice too. > > OK, I added this feature to my script. Because it is impossible to > know when buildd admin uploaded packages, date information is just > extra. The timestamp in the arch-all.txt file should give you that information. Otherwise I would create a list of package seen now, now-1, now-2, rotate them and only show entries that persist. Anyway, thanks for gathering this information in one place. Thats easier than checking every arch seperately. Mfg Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-listchanges in standard
Martin Michlmayr <[EMAIL PROTECTED]> writes: > * Goswin von Brederlow <[EMAIL PROTECTED]> [2005-02-23 10:39]: >> > ... I think apt-listchanges and its dependencies only need an >> > override change but maybe there's more I've overlooked. ... >> >> The override files need to changes so DAK outputs the right Packages >> file. >> >> The source needs to change so uploads don't complain and custom builds >> also have the right priority. > > You're missing the point. I know what needs to happen from a > technical POV in order to change the priority. I mailed -release > because I'm wondering if there are any reasons against promoting > apt-listchanges to standard. > > -- > Martin Michlmayr > http://www.cyrius.com/ Sorry, didn't mean to imply you didn't. Just wanted to remind everyone thats it's two things. There are some 10 packages currently in debian that only chnaged the override file but not package source. Didn't want to see another one. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: heavy dependency on debootstrap
Sébastien Chaumat <[EMAIL PROTECTED]> writes: > Hello, > > My package (replicator) depends heavily on the exact behavior of the > deboostrap package : debootstrap is called with a list of additional > packages to install and I always must sync this list with the actual > dependencies in sarge. > > Thus I always need a delay (mainly because regression tests take a > long time) each time debootstrap or a dependency in base is > modified. I will need this delay again when the freeze will happen to > be able to upload the correct version of replicator for sarge. > > Can we now take this into account in the release process. I think it > would be better if I can have a single contact in the release team to > allow better coordination. > > Thanks! > > Sebastien Could you please change replicator to use cdebootstrap, at lest optionally. cdebootstrap parses the Packages file and builds a list of packages to install based on essential, priority and dependencies. Changes in either one of the three will automatically adjust the set of packages to install. With cdebootstrap you just say what extra packages you need and the rest falls in place on its own. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arm buildd holdup?
Hamish Moffatt <[EMAIL PROTECTED]> writes: > http://buildd.debian.org/stats/arm-all.txt shows that the package is in > state need-build on arm. Overall arm status shows it's pretty up to > date, so the 9 day delay is unexpected. Is there anyone I can contact > and will that help? Need-build is a good sign. http://buildd.net/ shows you are on place 37 out of 120. I suggest just waiting unless the buildd has stoped altogether. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sat, Mar 12, 2005 at 03:19:23PM +1100, Matthew Palmer wrote: >> [Probably going a bit off track for -release; MFT to -devel] > >> On Fri, Mar 11, 2005 at 07:14:35PM -0800, Steve Langasek wrote: >> > The queue ordering is entirely automatic, and AIUI the queue(s) is (are) >> > sorted by: > >> > - target suite >> > - package priority >> > - package section >> > - package name > >> > I personally believe it would be beneficial to prioritize by upload urgency >> > as well (probably as a sort criterion between package priority and package >> > section), but the w-b maintainers disagree. > >> I'm trying to work out why package *section* matters at all. Package name >> is a bit odd, too, but including the section in there is just totally whack. > > Consider that libraries have their own section. Certain package sections > are (on the whole) more central to the dependency graph than others, so it's > to our advantage to order those first to reduce the need for give-backs or > dep-waits. Build-Depends should be set automaticaly as Dep-Wait for every source upload. That would reduce a lot of needless work for both machines and admins. >> Upload priority would be nice to sort by, but I think the queue needs to be >> as FIFO as possible for fairness and "principle of least surprise" sake. I think package urgency isn't considered because people would abuse it to get their packages build faster, or so someone nameless fears. Remember that the buildd queue is not FIFO at all. The queue has a completly static order. Any changes to the queue are just packages hiding because they are not "needs-build". I consider that the biggest flaw of all in wanna-build. >> Now I have this urge to go and make surgery on w-b. Yes please. Packages should Dep-Wait automatically, should be ordered by '(age * alpha) + beta' with alpha / beta set by at least the package priority and upload urgency. Optionaly also the number of Build-Depends and revers Build-Depends on the package. > Given that the w-b maintainers disagree, changing the code is not the hard > part. The system is designed such that it only really works properly if the > buildds drain the Needs-Build queue on a regular basis. This doesn't seem > terribly robust to me, but it's not my call. If you can convince the w-b admins to allow changes I could send you patches. Having a queue that will hapily starve packages is quite unfair to maintainers. Next you know x* will be renamed to a* just to get it build faster. > -- > Steve Langasek > postmodern programmer MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
Wouter Verhelst <[EMAIL PROTECTED]> writes: > Op za, 12-03-2005 te 15:01 -0800, schreef Thomas Bushnell BSG: >> Goswin von Brederlow <[EMAIL PROTECTED]> writes: >> >> > Remember that the buildd queue is not FIFO at all. The queue has a >> > completly static order. Any changes to the queue are just packages >> > hiding because they are not "needs-build". I consider that the biggest >> > flaw of all in wanna-build. >> >> This is news to me. >> >> It means that when one is told "just wait, your package will get >> rebuilt"; it is not necessarily true at all. There is no upper bound >> at all on time to wait for building, and that's a disaster. > > This paragraph assumes nobody ever looks the length of the needs-build > queue of his architecture, and nobody feels bad when the queue is longer > than normal. That idea would be hilarious if it wasn't sad. > > In reality, the upper bound is determined by motivated porters who try > hard to avoid the queue ever to grow too long, day after day. The queue length is bound and easily detected if it grows too long. But do you notice when the same packages keep showing up at the end of the queue for weeks? The queue can be as small as 1 package inbetween and that 1 package could still never get build. Eventualy someone notices, usualy the maintainer, and a new "why isn't my package build yet?" flame starts. >> People >> should stop repeating the fiction then that "just wait" means "your >> package will eventually get built". > > Why, if it is true? It usualy is. It might not be. And it can be an awfully long wait. The last one is the problem. The first two not. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
Wouter Verhelst <[EMAIL PROTECTED]> writes: > Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek: >> The queue ordering is entirely automatic, and AIUI the queue(s) is (are) >> sorted by: >> >> - target suite >- previous compilation state (already built packages are prioritized > above packages never built for the target architecture) >> - package priority >> - package section >> - package name >> >> I personally believe it would be beneficial to prioritize by upload urgency >> as well (probably as a sort criterion between package priority and package >> section), but the w-b maintainers disagree. > > I agree with the w-b maintainers. The queue order is only interesting in > the case where there is a backlog; in other cases, packages are usually > built rather fast. In the case where there is a backlog, those trying to > fix the architecture (usually those that are working on it) should be in > charge of deciding what package gets built first, not the maintainer of > a random package -- /all/ package builds are urgent if there's a > backlog. Since you think an empty queue is normal why then fight changes to the queue order? If it is empty most of the time as you say the specific order hardly matters. Packages will be build within 15 minutes of their upload no matter what order as they will be the only packae in the queue. As you say, the oder is only relevant when there is a backlog and that is currently a badly starving algorithm. The problem is that a backlog is more and more the normal day to day business while an empty queue is rare. Obviously not for every arch but always some archs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
Wouter Verhelst <[EMAIL PROTECTED]> writes: > Op ma, 14-03-2005 te 17:59 +0100, schreef Goswin von Brederlow: >> Wouter Verhelst <[EMAIL PROTECTED]> writes: >> >> > Op vr, 11-03-2005 te 19:14 -0800, schreef Steve Langasek: >> >> The queue ordering is entirely automatic, and AIUI the queue(s) is (are) >> >> sorted by: >> >> >> >> - target suite >> >- previous compilation state (already built packages are prioritized >> > above packages never built for the target architecture) >> >> - package priority >> >> - package section >> >> - package name >> >> >> >> I personally believe it would be beneficial to prioritize by upload >> >> urgency >> >> as well (probably as a sort criterion between package priority and package >> >> section), but the w-b maintainers disagree. >> > >> > I agree with the w-b maintainers. The queue order is only interesting in >> > the case where there is a backlog; in other cases, packages are usually >> > built rather fast. In the case where there is a backlog, those trying to >> > fix the architecture (usually those that are working on it) should be in >> > charge of deciding what package gets built first, not the maintainer of >> > a random package -- /all/ package builds are urgent if there's a >> > backlog. >> >> Since you think an empty queue is normal why then fight changes to the >> queue order? > > You misunderstood. I don't fight generic changes to the order; I just > don't think it would be a good thing that any random developer could > prioritize his pet package. My suggestion is to use an aging algorithm with "time * alpha + beta". Aspects of a source would then affect alpha and beta. Example: - Essential: yes adds 100 to beta and 5 to alpha. - Urgency: critical adds 10 to beta and 1 to alpha The package with the highest score gets build first. Alpha makes a package advance the queue faster overtaking other packages while beta makes packages start further up in the queue. By adjusting the changes to alpha and beta each aspect of a source can be finely tuned to have some affect on the queue. So random developer can influence the priority by setting the urgency but not so much as to abuse the power and deadlock other packages. Instead of the urgency of uploads the number of bugs (weighted by priority) could be used instead or on top of that. Or the number of depends, revers depends, dep-waits, A lot of aspects could be added up to set alpha and beta for each package. Even alpha=1, beta=- and time in minutes would be an improvement. That would mean that after 6 days any package would be build before a fresh upload of the most essential package. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iptables sarge release
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sun, May 08, 2005 at 06:15:00PM -0500, Laurence J. Lane wrote: >> There are a couple of iptables bugs that missed the standard >> freeze. #283822 in particular is scripting error that causes >> a FTBFS when using a dash (and probably other shells) instead >> of bash. > >> iptables (1.2.11-10) unstable; urgency=medium > >> * fixed scripts/prep.sh: patching and patch ordering >> * fixed a bashism reported by Geller Sandor in Bug#283822. Thanks. > >>-- Laurence J. Lane <[EMAIL PROTECTED]> Wed, 1 Dec 2004 19:11:34 -0500 > >> iptables (1.2.11-9) unstable; urgency=medium > >> * another prep.sh tweak for patch ordering >> * Bug#283721, Policy match save code puts in line feed that makes >> iptables-restore error, reported and fixed by Matthew Grant. Thanks. > >>-- Laurence J. Lane <[EMAIL PROTECTED]> Tue, 30 Nov 2004 23:04:01 -0500 > > Approved. > > Thanks, > -- > Steve Langasek > postmodern programmer There is another bug caused by different alignment on i386 and amd64 causing 32bit iptables to not work under a 64bit kernel. I'm not sure how complicated the patch will be but it looks to be localised to one file and function only. Is that likely to get accepted to sarge too and should I hurry to make a patch? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release policy changes
Matthias Klose <[EMAIL PROTECTED]> writes: > How can you tell, for which C++ ABI packages like mozilla-dev and > festival-dev are built? IMO that is the technical reason you are > asking for. It doesn't matter if an application or a library is linked > to libstdc++. Remember that C++ ABI != libstdc++ API. AFAIK packages > like php4 have such provides as well. [EMAIL PROTECTED]:~% apt-cache show mozilla-dev Package: mozilla-dev Architecture: amd64 Source: mozilla Version: 2:1.7.8-1 Depends: mozilla-browser (= 2:1.7.8-1), libnspr-dev (= 2:1.7.8-1), libxt-dev, libc6 (>= 2.3.2.ds1-21), libgcc1 (>= 1:3.4.1-3), libglib2.0-0 (>= 2.6.0), libidl0, libstdc++6 (>= 3.4.3-1) As you can see clearly from the Depends the package was build against C ABI from 1:3.4.1-3 and C++ ABI from 3.4.3-1. All dynamic libraries must have those Depends or they already violate policy. And that version maps to an uniqe ABI. Further doesn't the package name for libgcc1 and libstdc++ always change with abi changes? E.g. libstdc++5 vs. libstdc++6. Static libraries remain a problem there. But the package providing mozilla-dev-abi102 or mozilla-dev-abi1002 wouldn't solve the problem for two reasons: 1. The C++ ABI is determined by the compiler and not the package unless the package uses gcc-version (which mozilla does actually). The abi version should be extracted from g++ during build. 2. Build-Depends can't be on virtual packages. That just breaks all over the place. So if you want the c++ abi version reflected in the build package then it must be in the package name itself: mozillac102-dev vs mozillac1002-dev. But that rather belongs in the mozilla package itself and not the dev. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release policy changes
Russ Allbery <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > >> [EMAIL PROTECTED]:~% apt-cache show mozilla-dev >> Package: mozilla-dev >> Architecture: amd64 >> Source: mozilla >> Version: 2:1.7.8-1 >> Depends: mozilla-browser (= 2:1.7.8-1), libnspr-dev (= 2:1.7.8-1), >> libxt-dev, libc6 (>= 2.3.2.ds1-21), libgcc1 (>= 1:3.4.1-3), libglib2.0-0 (>= >> 2.6.0), libidl0, libstdc++6 (>= 3.4.3-1) > >> As you can see clearly from the Depends the package was build against C >> ABI from 1:3.4.1-3 and C++ ABI from 3.4.3-1. All dynamic libraries must >> have those Depends or they already violate policy. And that version maps >> to an uniqe ABI. > > I think you're confusing the C++ ABI with the SONAME of libstdc++. > They're not necessarily the same thing, although right now they tend to > change at the same time. Having the SONAME of libstdc++ change is > actually probably more likely to cause problems than a C++ ABI change > (since the latter is likely to be an edge case at this point), but either > can cause problems. If libstdc++ changes its ABI without its SONAME then every package linked against it most likely breaks. That certainly wouldn't do. If the ABI changes but not the SONAME then the only sane thing to do is to encode the ABI in the package name, e.g. libstc++-6c1002. Just like for any other lib doing the upcoming c++ abi transition. So what I ment to say is that the package name changes. SONAME can stay the same, but not the package name. That would cause untold chaos. As a sidenote, even if the package name stays the same the shlibs file should have a never version and that would show up in the Depends line again. But that would be an obscure way to detect it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release Team meeting minutes - 2005-06-18
Aurelien Jarno <[EMAIL PROTECTED]> writes: > Andreas Barth a écrit : >> release blockers: >> - toolchain transition >> - xorg >> - sorting out docs-in-main vs. the DFSG >> - SCC; amd64 as an official arch > > So SCC is now a fact, not a proposal anymore? SCC as in forcing primary mirrors to carry only selective archs is a fact. A neccessity. The remaining 99% of the vancouver proposal are very much unclear though and I sure as hell hope get some more discussion and change. Not wearing any hat and not being in any way relevant, Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
slidentd not entering testing
Hi, update excuses give me the following for slidentd: slidentd_0.0.19-5 (0.0.19-1 Installed) P-a-s: slidentd: !m68k Build-Depends: libowfat-dev, dietlibc-dev Section: net Architecture: alpha arm hppa i386 ia64 mips mipsel powerpc sparc Maintainer: Christian Kurz 67 days old (needed 10 days) out of date on m68k: slidentd (from 0.0.19-1) out of date on s390: slidentd (from 0.0.19-1) Not considered Slidentd seems to have droped some archs that have no dietlibc package. Since it was build in the past on m68k and s390 that seems to now hold up slidentd. Could this be added to the manual update hints? MfG Goswin
Re: Some observations regardig the progress towards Debian 3.1
Adrian Bunk <[EMAIL PROTECTED]> writes: > Hi, > > below are some subjective opservations and opinions regarding the > progress towards Debian 3.1 . > > Please read it, and make your own opinions on where I'm right and where > I'm wrong, even if you might not agree with my opinions on other issues > or if you don't agree with everything below. >... > Another problem for the release is the Debian installer. The vast > majority of Debian installations is i386. If the new installer isn't > ready on all architectures it might be an option to ship some > architectures without installer in 3.1r0, and add the installer for > these architectures in 3.1r1 or 3.1r2. This way Debian 3.1 might be > released more early, and even for the affected architectures it's > better, since additionally to the status quo (installing and using > Debian 3.0), they can upgrade to Debian 3.1 . > > > Thanks for reading this mail. > > Yours > Adrian The problems with porting debian-installer to different archs is minimal. As shown on the D-I debcamp in Oldenburg porting to a new architecture can be done over a weekend without any prior knowledge of d-i. Since then several things have also been simplified in respect to porting and more people are able to help on the issue. Given a person with the hardware and time I'm certain support can be added in a single day. The big problem is getting access to the hardware directly or indirectly through a tester. And don't tell me use debians machines unless you are able to provide accounts for sveral non DD d-i developers (which needs sudo for additional build-depends needed for that arch). Well, enough ranting. Overall I think the porting to the remaining archs is the lesser of the problems of d-i. MfG Goswin
Re: Some observations regardig the progress towards Debian 3.1
Yann Dirson <[EMAIL PROTECTED]> writes: > On Fri, Nov 21, 2003 at 04:42:44PM -0800, Mike Fedyk wrote: > > Why does testing get out of a releasable state? > > o RC bugs are found after entering testing > > what else? > > - Maintainers sometime miss versionned deps > - Build-deps are ignored by the testing scripts - Binary arch and binary all packages aren't autobuild and still fail frequently. - Foo depends on Bar and new version of Foo entering testing breaks Bar - pre/postinst/rm scripts that worked from release to release fail on the version jump in testing MfG Goswin
Re: Some observations regardig the progress towards Debian 3.1
Yann Dirson <[EMAIL PROTECTED]> writes: > On Sun, Nov 23, 2003 at 05:13:24PM +0100, Adrian Bunk wrote: > > Independent of your suggestions: > > It's never a good idea to use a version number namespace that is already > > occupied for something different. > > OK, good point. > > So maybe pre-testing-like rebuilds should get the 4th decimal place > instead ? Hm, maybe... > > Regards, Nothing stops me from using Version 1.2.3.4.5.6.7.8.9. MfG Goswin
Re: Some observations regardig the progress towards Debian 3.1
Adrian Bunk <[EMAIL PROTECTED]> writes: > On Thu, Nov 27, 2003 at 09:18:18AM +0100, Yann Dirson wrote: > > On Thu, Nov 27, 2003 at 08:59:54AM +0100, Goswin von Brederlow wrote: > > > Nothing stops me from using Version 1.2.3.4.5.6.7.8.9. > > > > It's sure that this system of numeration only works for non-native > > Debian packages. It's not clear at all how to distinguish a NMU or a > > binary NMU on a native Debian package, without looking at the previous > > revision in the changelog file... > > For source NMUs it's clearly defined in section 5.11.4.1. of your > Developer's Reference, that says a source NMU of a native package gets a > Debian revision of 0.1 . > > E.g. > > Version: 1.0 > Source NMU : 1.0-0.1 Yep, but you have to go by the debian revision minor part. Numbering the parts won't help. > I haven't found it explicitely mentioned, but the logial version number > for a binary NMU of version 1.0 would be 1.0-0.0.1 . A binary NMU implies you haven't changed the source. If you change the version number you have changed the source and must upload it too. Thus binary NMU must have the same version number. > Although this looks starange at a first glance, this gives a clear > version that is under all circumstances lower than the next maintainer > upload (this wouldn't be possible without adding a Debian revision to > the NMU). I use 1.2-3 -> 1.2-3.0.1 for debs privatly rebuild with optimisations. That way either a NMU or maintainer upload has a higher version. MfG Goswin
Re: Some observations regardig the progress towards Debian 3.1
Adrian Bunk <[EMAIL PROTECTED]> writes: > On Thu, Nov 27, 2003 at 07:53:47PM +0100, Goswin von Brederlow wrote: > > Adrian Bunk <[EMAIL PROTECTED]> writes: > >... > > > I haven't found it explicitely mentioned, but the logial version number > > > for a binary NMU of version 1.0 would be 1.0-0.0.1 . > > > > A binary NMU implies you haven't changed the source. If you change the > > version number you have changed the source and must upload it too. > > Thus binary NMU must have the same version number. > >... > > That's wrong. > > Please read section 5.10.2.1. of your Developer's Reference. Ok, the hopefully nowadays very rare "magic" version bumping to get a recompile of an already install package uploaded. Does that happen anymore? MfG Goswin
Qestions to "Why is package X not in testing yet?"
Hi, I asked Bjorn Stenberg about why inn2 is waiting on perl (see mail below) and he suggested that maybe the sarge testing script would ensure, that the version of perl used during building would enter sarge before/with inn2. He wasn't sure though and suggested I check here to confirm what is realy happening. Is he right or is something else going on? MfG Goswin PS: please CC me on all replies since I'm not on the list. --- Begin Message --- Hi, I am wondering how the update-excuses script comes to the conclusion that inn2 (as an example of a bunch of them) is waiting for perl. Looking at the "Why is package X not in testing yet?" page for inn2 http://bjorn.haxx.se/debian/testing.pl?package=inn2;printalldeps=1 I see no reason why a newer perl than sarge is needed: | # info: inn2 depends on perl (ok, testing has version 5.8.2-2) | # inn2 depends on perlapi-5.8.2, provided by: perl-base | o info: perl-base has version 5.8.2-2 in testing Looking at the inn2 Depends I also see no clue why perl is blocking it. | Depends: libc6 (>= 2.3.2.ds1-4), libdb4.1, libperl5.8 (>= 5.8.2), debconf (>= 0.5), inn2-inews (>= 2.3.999+20030227-1), cron, exim4 | mail-transport-agent, time, procps, perl, perlapi-5.8.2 libperl5.8, perl and perlapi-5.8.2 are available in sarge. Can you shed any more light on this? Thanks in advance and for your pages, they are very helpfull. MfG Goswin --- End Message ---
Re: Qestions to "Why is package X not in testing yet?"
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sun, Feb 22, 2004 at 12:31:05AM +0100, Goswin von Brederlow wrote: > > I asked Bjorn Stenberg about why inn2 is waiting on perl (see mail > > below) and he suggested that maybe the sarge testing script would > > ensure, that the version of perl used during building would enter > > sarge before/with inn2. He wasn't sure though and suggested I check > > here to confirm what is realy happening. > > > Is he right or is something else going on? > > Something else is almost certainly going on. > > At a guess, one or more of the architectures that have been backlogged > recently built inn2 after perl 5.8.3 was in the archive, resulting in an > arch-specific dependency bump to libperl5.8 (>= 5.8.3). > > Looks like this is the case on m68k at least; there may be others. Ahh, after checking i386, mips and mipsel (the other two big backlog archs) I stoped checking. On m68k inn2 also depends on perlapi-5.8.3. Thanks for noticing that. So there is no magic version checking on top of Depends/Conflicts/.. then, right? MfG Goswin
Re: Sarge and real i386-boxes
Andreas Barth <[EMAIL PROTECTED]> writes: > Hi, > > since some time, it's not possible to upgrade to sarge with an real > i386-box (real mean: not i486 or higher). This is due to changes in > the gcc, and therefore we need an upgrade kernel etc, see bug #241497 > for the details. It was intended to put this kernel into > dists/sarge/main/upgrade-i386. > > As this bug is open since some time, my question is this: > > Does anyone of you feel obligated to upload a kernel, tools and/or to > write a README? Or should I just go ahead and upload the appropriate > files? Is anyone still using real i386 cpus? MfG Goswin
Re: 2.6.8 release
Sven Luther <[EMAIL PROTECTED]> writes: > On Sun, Aug 01, 2004 at 04:57:40AM -0700, William Lee Irwin III wrote: >> At some point in the past, I wrote: >> >> The 2.6.8 release has been almost exclusively focused on stabilization. >> >> I highly recommend adopting as much of 2.6.8 as possible if not the >> >> whole delta between 2.6.7 and 2.6.8. If not incrementing the version >> >> number after freeze is the primary constraint, I'd literally recommend >> >> just marking the delta to reach virgin 2.6.8 as an add-on patch in the >> >> 2.6.7-deb repository while leaving the version number intact. >> >> On Sun, Aug 01, 2004 at 08:38:23AM +0200, Sven Luther wrote: >> > I don't understand this, what would be the gain over doing real >> > 2.6.8 packages ? >> >> It would be a loss vs. shipping real 2.6.8 packages. The only use of >> such a technique would be to satisfy a constraint on version numbers. > > I don't think it is needed to resort to such tricks. > > Friendly, > > Sven Luther D-I constrains the debian revision which would have to change. Bumping the revision or the version is about the same amount of work to get it being used. So no gain there. MfG Goswin
Re: please re-queue liblrdf
Robert Jordens <[EMAIL PROTECTED]> writes: > Hi! > > liblrdf 0.3.7-2 has failed to build because of an RC bug in libraptor. > The bug is now fixed and liblrdf should be retried on > sparc, arm and m68k. > > Thanks, > > Robert. Wrong lists :) Each architecture has an @buildd.debian.org alias (CCed them) and m68k has its own mailinglist for buildd stuff (also Cced). I see m68k is already retrying the build while sparc and arm haven't reacted to the failed builds on Jun 10th. MfG Goswin == # alpha: installed # amd64: installed # arm: libs/liblrdf_0.3.7-2: Building by buildd_arm-elara [optional:out-of-date] Previous state was Needs-Build until 2004 Jun 10 20:54:37 # hppa: installed # i386: installed # ia64: installed # m68k: libs/liblrdf_0.3.7-2: Building by buildd_m68k-zeus [optional:out-of-date] Previous state was Needs-Build until 2004 Aug 02 05:27:20 Previous failing reasons: 0.3.7-2 > cc -DHAVE_CONFIG_H -I. -I. -I.. -g -Wall -O2 -Wall -g -I.. -MT lrdf.lo -MD -MP -MF .deps/lrdf.Tpo -c lrdf.c -fPIC -DPIC -o .libs/lrdf.o > In file included from lrdf.c:4: > /usr/include/raptor.h:283: error: parse error before "va_list" > make[3]: *** [lrdf.lo] Error 1 0.3.5-2 > /bin/sh ../libtool --mode=link cc -g -Wall -O2 -Wall -g -I.. -o liblrdf.la -rpath /usr/lib lrdf.lo lrdf_multi.lo md5.lo -lraptor -lraptor -lcurl -lssl -lcrypto -ldl -lxml2 -lz -lpthread -lm -lglib-2.0 > cc -shared .libs/lrdf.o .libs/lrdf_multi.o .libs/md5.o -L/usr/lib /usr/lib/libraptor.so /usr/lib/libcurl.so -lssl -lcrypto -ldl /usr/lib/libxml2.so -lz -lpthread -lm /usr/lib/libglib-2.0.so -Wl,-soname -Wl,liblrdf.so.0 -o .libs/liblrdf.so.0.0.0 > /usr/bin/ld: cannot find -lssl > collect2: ld returned 1 exit status 0.3.5-1 > cd .. && \ > automake-1.7 --gnu src/Makefile > /bin/sh: line 1: automake-1.7: command not found > make[3]: *** [Makefile.in] Error 127 0.3.1-2 > m68k-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -g -I.. -c md5.c -MT md5.lo -MD -MP -MF .deps/md5.TPlo -o md5.o >/dev/null 2>&1 > mv -f .libs/md5.lo md5.lo > /bin/sh ../libtool --mode=link m68k-linux-gcc -Wall -g -I.. -o liblrdf.la -rpath /usr/lib -version-info 1:3:1 lrdf.lo lrdf_multi.lo md5.lo -lraptor -lraptor > grep: /usr/lib/libglib-2.0.la: No such file or directory > /bin/sed: can't read /usr/lib/libglib-2.0.la: No such file or directory > libtool: link: `/usr/lib/libglib-2.0.la' is not a valid libtool archive > make[3]: *** [liblrdf.la] Error 1 See #204539 # mips: installed # mipsel: installed # powerpc: installed # s390: installed # sparc: libs/liblrdf_0.3.7-2: Building by buildd_sparc-vore [optional:out-of-date] Previous state was Needs-Build until 2004 Jun 10 19:36:24
Re: RFC: Adding minimal amd64/biarch support for sarge
Peter Cordes <[EMAIL PROTECTED]> writes: > On Wed, Aug 04, 2004 at 05:42:30PM -0400, Daniel Jacobowitz wrote: >> First, what I'm suggesting: two new packages for sarge and one modified >> package. They would allow 64-bit applications using a small set of standard >> libraries to run on an otherwise i386 installation, and allow 64-bit >> applications to be built. > > I would love that. I admin some bioinformatics clusters, and some > phylogenetics (tree-of-life reconstruction) programs use tree data > structures full of pointers that, with gcc-3.3, are faster in 32bit mode > than 64bit mode. (It would really kick ass if AMD64 had a mode with the > extra registers, but 32bit pointers. Then pointer-heavy data structures > would be faster.) Anyway, being able to easily compile in 32 or 64bit and > benchmark would be very useful. Also, I wouldn't have to statically link > 64bit binaries that are faster in 64bit mode, and users wouldn't have to > deal with the chroot. (not that it's much trouble with dchroot :) It won't use the extra registers in 32bit mode. It would be theoretically possible to build for 64bit (with extra registers) but 32bit pointers [The Tru64 cc can do that on alpha] but it would require extending the pointers to 64bit on every use and would probably void all the speedup. One thing you could do with gcc to emulate this is to use an array index instead of a pointer. For problems where 4GB is just not enough (so you need 64bit) and 64bit waste too much ram this can help a lot. But you buy ram for some extra instructions. > So, for me (and my ~dozen users) at least, this really would be useful. If > you can't get it into sarge, I don't mind tracking unstable for some > packages on the cluster (it's not quite what some would call a "production" > system). It would rock to have it in sarge :) The progress looks good. I have made an amd64-libs package with some patches from Daniel Jacobowitz and he has made a gcc-3.4 package. Now if I get thekernel-image-amd64 build and all of them through new in time you have the 32/64 bit support. MfG Goswin
Re: No libtiff transition for sarge
Jose Carlos Garcia Sogo <[EMAIL PROTECTED]> writes: > On Sun, Aug 08, 2004 at 06:46:09PM +0200, Andreas Metzler wrote: > > [...] > >> > [1] OK, you could upload half of GNOME recompiled against an older >> > libgpg-error0 >> >> Nicely spotted. Seems like libgpg-error0 somehow missed radar, another >> case for tpu, imho. > > Woops! That's was really my fault. I check that there were no internal > need to upgrade shlibs, but I forgot to change shlibs creation. > Anyway, such change should be made, as new interfaces have been added > from 0.7 to 1.0. A package using that should be able to say that he > needs the new version. If you have new features shlibs needs to be bumped. To fix this in sid it looks like you have to upload the old 0.7 version with an epoch or as 1.0-realy-0.7 and recompile everything against it (assuming nothing uses the new features yet). Both is rather ugly. Uploading t-p-u versions looks cleaner. (but do what RM says) > Other reason is that libgpg-error was priority optional till this last > upload, when I realised that libgnutls/libcrypt depend on it. Even, > though I have changed it in my sources, bug filled in ftp.d.o is not > yet closed. (see #262938) > > And basically, all those GNOME packages depending directly on > libgpg-error0 need to be relibtoolized and reuploaded, with new libtool > >= 1.5.6, and those dependencies will disappear. If someone can > provide me a list, I can see what can be done in this field from GNOME > Team part. apt-cache rdepends libgpg-error0 > Anyway, I'd like to hear release people about this issue. If a fixed > package must be drop to t-p-u I'll prepare it ASAP. (CC set on > d-release for that) > > Cheers, MfG Goswin
Re: FTFBS in sarge
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sat, Sep 04, 2004 at 04:07:37PM -0500, Robin Verduijn wrote: > >> On Thu, Sep 02, 2004 at 12:39:25AM +0200, Bastian Blank wrote: >> > mcvs_1.0.8-4 > >> Meta-CVS has failed for over a year to get into testing due to a bug in >> clisp. Since that[1] does not seem to be actively worked on fixing (by >> the clisp maintainer nor by the mips porters), the only way for mcvs Why not fix it yourself? Since you seem to use clisp I guess you are familiar with it? >> to propagate to testing now is if its MIPS package is removed from the >> testing archives. I filed a bug[2] for that almost 3 months ago. Should >> I bump its severity up higher (it's now "serious") or will that make no >> difference? > > I don't imagine it makes a difference. Severities are a rather fuzzy > concept where ftp.debian.org is concerned. > > You may want to get mcvs added to P-a-s > (http://buildd.debian.org/quinn-diff-Packages-arch-specific), as this > makes the case for removal from the archive clearer. Do you think it wise to exclude packages from an arch just because it has some bug? If the maintainer can't be bothered to fix a bug the package should not enter testing. Excluding an arch just works around semi orphaned packages. > -- > Steve Langasek > postmodern programmer MfG Goswin
Re: FTFBS in sarge
Robin <[EMAIL PROTECTED]> writes: > Hi Goswin, > > Goswin von Brederlow ([EMAIL PROTECTED]) wrote on 09:21:50AM 05/09/04: >> Why not fix it yourself? Since you seem to use clisp I guess you are >> familiar with it? > > I actually did try to fix the bug in clisp but I didn't succeed at it > because I didn't know enough about MIPS assembly in order to follow > through on it. My requests on the debian-mips mailing lists all went > unanswered[1]. Have you tried talking to the gcc maintainer team to find some mips guys directly? Or to the linux-mips mailinglist? Maybe some non Debian person can help. >> Do you think it wise to exclude packages from an arch just because it >> has some bug? If the maintainer can't be bothered to fix a bug the >> package should not enter testing. Excluding an arch just works around >> semi orphaned packages. > > Just in case you didn't get it, the problem is not even in *my* package. It wasn't adressed against your package. Sorry. > The clisp package at some point built the FFI module for mips, which let > my mcvs package be built and propagated into testing. Then the clisp > maintainer turned off building the FFI module for certain architectures > (including mips), making it impossible for mcvs to build successfully for > those architectures from that point on. I agree with you that the *clisp* > package w/o FFI on some architectures shouldn't have made it into testing > but it did, and that's how things stand now. Have you considered dropping just the clisp needing parts for not fully supported archs? On i386 I don't see a Depends: clisp in mcvs so it seems to be usefull without it at first glance. Maybe that would solve the problem. Since you have a problem with the language support for the specific arch it is very hard to find someone qualified to fix this. > - robin > > [1] http://lists.debian.org/debian-mips/2004/05/msg00141.html > http://lists.debian.org/debian-mips/2004/06/msg00035.html MsG Goswin
Re: FTFBS in sarge
Seo Sanghyeon <[EMAIL PROTECTED]> writes: >> Robin <[EMAIL PROTECTED]> writes: >>> The clisp package at some point built the FFI module for mips, which let >>> my mcvs package be built and propagated into testing. Then the clisp >>> maintainer turned off building the FFI module for certain architectures >>> (including mips), making it impossible for mcvs to build successfully for >>> those architectures from that point on. I agree with you that the *clisp* >>> package w/o FFI on some architectures shouldn't have made it into testing >>> but it did, and that's how things stand now. > > Goswin von Brederlow wrote: >> Have you considered dropping just the clisp needing parts for not >> fully supported archs? On i386 I don't see a Depends: clisp in mcvs so >> it seems to be usefull without it at first glance. Maybe that would >> solve the problem. > > Oh, no. Meta-CVS is _written in_ Common Lisp! Debian mcvs package > contains both Lisp runtime and Lisp image. > > No, it cannot depend on clisp package, unless the build is changed to > compile FFI part dynamically. I don't believe dynamic FFI will work > where static FFI fails. > > Seo Sanghyeon Does that mean every clisp program in Debian has a copy of the clisp runtime in it? MfG Goswin
Re: Problem with kernel on SATA hosts - RC?
Richard Atterer <[EMAIL PROTECTED]> writes: > Hello, > > I think there is a problem with kernel-image-2.6.8-1-686, but I'm not sure > whether I messed up something... > > I installed sarge on a SATA host a while ago (Intel ICH, worked just > fine!). Now I upgraded from the installer's kernel-image-2.6.8-1-386 to > version 2.6.8-10 of the kernel-image-2.6.8-1-[36]86 package. The problem is with near certainty that you updated from a sata-ide driver to a sata-scsi driver. The device names for your disk subsequently changed from /dev/hda to /dev/sda. This has a few effects: 1. the modules needed change from what mkinitrd sees as needed (e.g. then ide-disk, now sd). 2. the root device changes but mkinitrd still puts the old one into the initrd (default is probe). 3. the device names change but /etc/fstab is not changed. If you get that far then the fsck tests will fail. All of this has absolutely no bearing on whether you have modules or buildin drivers. Debian kernel nowadays don't have anything builtin that can free up some more space on the floppy. > The problem: The SATA code is built as modules in the regular kernel > package, but it mustn't be. You need the following kernel config: No, it isn't. :) MfG Goswin
Re: Where should I request forgotten rebuilds?
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Release team, > > Thanks for the octave cluebat. Thanks also for pushing R through last > weekend or whenever that was. There is one remaining problem: > r-cran-fseries is 50 days old and not in testing because initial builds on > arm and s390 failed due to changes happening then to the R toolchain. These > have long been ironed out -- but the source package fseries never get > rescheduled. > > Where would I request that? On the respective porters list? Somewhere else? [EMAIL PROTECTED] > Thanks again, Dirk MfG Goswin
Re: Please refrain from non-RC gcc-3.4 uploads until a new version has entered sarge
Matthias Klose <[EMAIL PROTECTED]> writes: > Frank Küster writes: > ok, I'll upload a new versions with urgency=high. The current packages > are not suitable for sarge. We'll need newer packages for > > - gcc-3.4_3.4.3-6, containing a current libunwind lib. > > - libunwind-0.98.3-3 > > - gcc-3.2_3.3.5, depending on the new libgcc1 from gcc-3.4_3.4.3-6 > > - glibc -20, depending on the new gcc-3.4. Glibc also needs a minor patch for amd64. It now has to create the /lib64 and /usr/lib64 symlinks. It would be nice if those could be added before glibc is pushed into sarge. > I'm currently waiting from the ia64 people review of the packages at > http://people.debian.org/~doko/gcc-3.4/ After that I'll upload the > packages. A new glibc should be uploaded, after the gcc builds have > started, or else the gcc builds will fail due to an uninstallable > locales package (which I fail to understand why that dependency isn't > fixed :-( ). arch:any <-> arch:all versioned depends. > Sorry for inconvenience, that unwind based exceptions was more painful > than expected. > > Matthias MfG Goswin
Re: Obsolete binaries
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > On Mon, Dec 20, 2004 at 01:39:57PM +1000, Anthony Towns wrote: >> Looking at the other page that does something similar (based on ftp.d.o >> bugs) that someone on this list should know the url for, and merging the >> two would be good too. > > You are referring to: > > http://ftp-master.wolffelaar.nl/removals.html > > I'll look into merging rene output into this page. > >> And could we please start getting these obscure pages moved onto >> release.debian.org or at least *.debian.net? Or at least start linking >> to them? > > In progress. > > --Jeroen Do you want the scripts from buildd.net (or rewrites thereof like Igloos page) too? MfG Goswin
Re: Installing Debian Testing on Athlon64
Dhiraj Gaurh <[EMAIL PROTECTED]> writes: > Hi, > Sarge does contain kernel packages for amd64 but if you try to > download sarge, there is no directory for the amd64 architecture. Is > amd64 not yet fully supported by sarge ?? Do I need to install i386 > and then upgrade the kernel to amd64, then what about all the other > applications ? > Thanks a lot > Dhiraj > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] How about following the ports page and reading the amd64 FAQ? The amd64 kernel images in sarge are only 64bit kernels for use with i386 sarge. MfG Goswin
Re: m68k (was Re: C++ transitions status report
Nathanael Nerode <[EMAIL PROTECTED]> writes: >>> And the following library packages haven't built in c2 versions on >>> all architectures, and therefore prevent other packages from >>> transitioning: >> >>> pdfkit.framework -- m68k (blocks viewpdf.app, gworkspace.app) >> >>m68k should just be ignored for these purposes; the arch is doing much >>better than in past months, but it's still not quite keeping up to the point >>that we're checking installability counts there. > > Yes, but... > > I didn't think it was a good idea to reupload the packages > depending on that library, or to queue them for rebuilding on m68k, > since they'd end up linked to the old version of libstdc++ on m68k. > Until the transitioned library built. > > Am I right about that? If you reupload the package you can Build-Depends: libfoo-dev (>= 1.2-3) | libfoo-dev, where 1.2-3 is the version with the c2a fix. This would prevent the buildds from building against the old libfoo-dev as they always pick the first alternative. (doesn't work for build-essential stuff) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd maintainers stuck?
Steve Langasek <[EMAIL PROTECTED]> writes: > On Tue, Nov 29, 2005 at 07:46:42PM -0800, Thomas Bushnell BSG wrote: > >> The initial upload of libcapplet 1:1.5.11-12 failed to build on alpha, >> arm, i386, and mipsel because of a temporarily absent build >> dependency. This upload occurred over three weeks ago. > >> On November 17 I requested that the buildds requeue this build, but >> nothing has happened. Can the release team please schedule a binNMU >> or do whatever is supposed to happen? ... > My preference would be that such requests be sent first to the porters > (either the mailing lists specified on http://www.debian.org/ports/, or the > individual porters mentioned on the wiki pages linked from > http://release.debian.org/etch_arch_qualify.html). While most of these > porters are not themselves buildd admins, they *are* the people responsible > for the overall health of a given port, and they should definitely be taking > an active role in sorting out build failures for their architecture; so if > they aren't already in a position to batch-proxy such requests to the buildd > maintainers, they darn well ought to get there. Please don't. That is just wrong. All packages should be buildd build and the porters can do nothing if the buildd (admin) screws up. It realy is the admins job to fix the buildd and handle missing Build-Depends. If the port is suddenly responcible for fixing buildd problems then more people need access to wanna-build and buildds so they can actualy do something about it. Or binary NMUs must be un-deprecated again. MfG Goswin PS: One thing $random volunteer could do would be patching wanna-build to Dep-Wait automatically for the obvious cases. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd maintainers stuck?
Andreas Barth <[EMAIL PROTECTED]> writes: > * Goswin von Brederlow ([EMAIL PROTECTED]) [051206 14:59]: >> PS: One thing $random volunteer could do would be patching wanna-build >> to Dep-Wait automatically for the obvious cases. > > Auto-Dep-Wait works for some months now. > > > Cheers, > Andi Aparently not in the case in question. So there might be room for improvement. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd maintainers stuck?
Steve Langasek <[EMAIL PROTECTED]> writes: > On Tue, Dec 06, 2005 at 02:56:28PM +0100, Goswin von Brederlow wrote: >> Steve Langasek <[EMAIL PROTECTED]> writes: > >> > On Tue, Nov 29, 2005 at 07:46:42PM -0800, Thomas Bushnell BSG wrote: > >> >> The initial upload of libcapplet 1:1.5.11-12 failed to build on alpha, >> >> arm, i386, and mipsel because of a temporarily absent build >> >> dependency. This upload occurred over three weeks ago. > >> >> On November 17 I requested that the buildds requeue this build, but >> >> nothing has happened. Can the release team please schedule a binNMU >> >> or do whatever is supposed to happen? > >> ... >> > My preference would be that such requests be sent first to the porters >> > (either the mailing lists specified on http://www.debian.org/ports/, or the >> > individual porters mentioned on the wiki pages linked from >> > http://release.debian.org/etch_arch_qualify.html). While most of these >> > porters are not themselves buildd admins, they *are* the people responsible >> > for the overall health of a given port, and they should definitely be >> > taking >> > an active role in sorting out build failures for their architecture; so if >> > they aren't already in a position to batch-proxy such requests to the >> > buildd >> > maintainers, they darn well ought to get there. > >> Please don't. That is just wrong. > >> All packages should be buildd build and the porters can do nothing if >> the buildd (admin) screws up. It realy is the admins job to fix the >> buildd and handle missing Build-Depends. > > [Note to Thomas: porters who refer to transient build failures as buildd > admin "screw-ups" are not the porters you're looking for.] > > So are you arguing that all 1000+ maintainers should be bombarding buildd > maintainers directly with requeue requests of unknown validity, with the There should not be any need to request anything as it is the normal buildd admins job to care for the buildd. Only on the rare occasions that something slips through the cracks should there be any mail. You can hardly call that bombarding. > current duplicate requests, general port ignorance, and spam ensuring that > the mail address has a sufficiently low S:N ratio that it's hardly worth > paying attention to? Or are you saying that no one, porters included, > should work with buildd maintainers and bring it to their attention when a > transient failure has been overlooked or resolved? > > I don't see either approach as being particularly helpful. I'm saing that the email addresses should be used for what they were created for in the first place. To contact the people that can do something about the buildds for that arch and get a overlooked transient failure underway again. >> If the port is suddenly responcible for fixing buildd problems then >> more people need access to wanna-build and buildds so they can actualy >> do something about it. Or binary NMUs must be un-deprecated again. > > No, buildd admins are responsible for fixing buildd problems. *Porters* are > responsible for *ensuring their port is a viable release candidate*. Given > that one of the release criteria is "keeping up with unstable", porters most > definitely *are* expected to help make sure packages are getting built. > From a "too many cooks" standpoint, this doesn't mean constantly looking > over the buildd admin's shoulder and telling them every time a package needs > requeued; see the other thread on -devel for my take on better ways for > porters to spend their time. But if a package that failed earlier gets > un-stuck, and the buildd admin hasn't noticed, shouldn't it be the porters > who bring it to their attention? And how should they (be it porters or the maintainer him/herself) bring it to their attention if not by mailing @buildd.d.o? You just deterred from that in your mail. What other way is there? And note that maintainers usualy have way more knowledge about their package and package dependencies to know what they need. For the build failures due to missing Build-Depends no arch specific knowledge is required. Just the availability of packages. > Oh, and for the record: the score today is that of 10 existing Debian ports > that are required to have designated porters to be qualified as release > candidates for etch (that's excluding i386, which has... um... "virtual > porters", and amd64 which isn't hooked to the official w-b yet), 7 of them > have at least one porter with w-b access for the port. So if the porters > aren't w
Re: buildd maintainers stuck?
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Steve Langasek <[EMAIL PROTECTED]> writes: > >> No, buildd admins are responsible for fixing buildd problems. *Porters* are >> responsible for *ensuring their port is a viable release candidate*. Given >> that one of the release criteria is "keeping up with unstable", porters most >> definitely *are* expected to help make sure packages are getting built. > > I think the problem is that if the buildds don't talk to the porters, > and the porters aren't allowed to upload binNMUs themselves, then they > are essentially barred from their assigned task. > > How about we make porters responsible for running their buildds > instead of the current arrangement? You mean allow porters to add buildds (or just buildd admins) to the arch to increase redundancy? This can be a gradual process. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd maintainers stuck?
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > How about making porters responsible for running the buildds for their > arch? I consider anyone who runs a buildd for an arch a porter already so that is already there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd maintainers stuck?
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > >> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: >> >>> How about making porters responsible for running the buildds for their >>> arch? >> >> I consider anyone who runs a buildd for an arch a porter already so >> that is already there. > > If they are unwilling to cooperate with the rest of the porters, and > they aren't participating, then I don't think they are a porter. > > Calling a dog's tail a leg doesn't make it one. > > Thomas The might just be bad porters. Bad dog, BAD. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-ia32-libs-maintainers] Bug#684029: ia32-libs-i386: Please, downgrade ldap depends to recommends
On Mon, Aug 06, 2012 at 12:28:35PM +0200, Vincent Danjean wrote: > Package: ia32-libs-i386 > Version: 20120701 > Severity: normal > > Currently, ia32-libs-i386 depends on > libldap-2.4-2 (>= 2.4.23-7.2) > libnss-ldap (>= 264-2.2) > libpam-ldap (>= 184-8.5) > > I understand that, on systems where ldap is installed on the main (amd64) > architecture, installing the corresponding i386 packages is required. > However, when the main architecture does not have any ldap infrastructure > installed (most laptops for example), we are required to install packages > that ask "strange" questions (ldap base, ...) and that reconfigure > /etc/nsswitch. > > Would it be possible to downgrade the Depends to a Recommends (at least) > with a corresponding Breaks (<< old-versions) if needed? > If this is possible (I did not test), I think this should be applied to > the wheezy package. > > Regards, > Vincent Dear release team, would such a change (moving the 3 packages from Depends to Recommends) be suitable for a freeze exception? MfG Goswin -- 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/20120813081636.GA3477@frosties
Re: [Pkg-ia32-libs-maintainers] Bug#684029: ia32-libs-i386: Please, downgrade ldap depends to recommends
On Sat, Aug 18, 2012 at 05:38:58PM +0200, Julien Cristau wrote: > On Mon, Aug 13, 2012 at 10:16:36 +0200, Goswin von Brederlow wrote: > > > On Mon, Aug 06, 2012 at 12:28:35PM +0200, Vincent Danjean wrote: > > > Package: ia32-libs-i386 > > > Version: 20120701 > > > Severity: normal > > > > > > Currently, ia32-libs-i386 depends on > > > libldap-2.4-2 (>= 2.4.23-7.2) > > > libnss-ldap (>= 264-2.2) > > > libpam-ldap (>= 184-8.5) > > > > > > I understand that, on systems where ldap is installed on the main (amd64) > > > architecture, installing the corresponding i386 packages is required. > > > However, when the main architecture does not have any ldap > > > infrastructure > > > installed (most laptops for example), we are required to install packages > > > that ask "strange" questions (ldap base, ...) and that reconfigure > > > /etc/nsswitch. > > > > > > Would it be possible to downgrade the Depends to a Recommends (at least) > > > with a corresponding Breaks (<< old-versions) if needed? > > > If this is possible (I did not test), I think this should be applied to > > > the wheezy package. > > > > > > Regards, > > > Vincent > > > > Dear release team, > > > > would such a change (moving the 3 packages from Depends to Recommends) be > > suitable for a freeze exception? > > > Wouldn't Recommends be just as wrong? Especially as those packages are > recommended against AFAIK > (http://www.debian.org/releases/squeeze/amd64/release-notes/ch-whats-new.en.html#new-ldap). > > Cheers, > Julien They are in the squeeze ia32-libs package so dropping them completly would mean a regression on upgrade. Having them as Recommends would make them removable if not needed at least. MfG Goswin -- 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/20120827084349.GA32615@frosties
Bug#596899: unblock: ia32-libs/20100914
Hi, ia32-libs has been updated again to fix an unreported RC bug (uninstallable on ia64), a simple bug and to cover package updates in squeeze: --- ia32-libs (20100919) unstable; urgency=high * Make dependency on lib32bz2-1.0 [amd64] only. * Add gcc-3.3 1:3.3.6ds1-20 for libstdc++5 (Closes: #597306) * Packages updated [ openldap (2.4.23-5) unstable; urgency=high ] [ Steve Langasek ] * High-urgency upload for RC bugfix. * debian/slapd.scripts-common: fix gratuitous (and wrong) use of grep in get_suffix(), which causes us to incorrectly parse any slapd.conf that uses tabs instead of spaces. #595672. * debian/slapd.init, debian/slapd.scripts-common: when $SLAPD_CONF is not set in /etc/default/slapd, we should always set a default value, giving precedence to slapd.d and falling back to slapd.conf. Users who don't want to use an existing slapd.d should point at slapd.conf explicitly. #594714, #596343. * debian/slapd.init: 'invoke-rc.d slapd stop' should not fail due to the absence of a slapd configuration; we should still exit 0 so that the package can be removed gracefully. #596100. * drop build-conflicts with libssl-dev; we explicitly pass --with-tls=gnutls to configure, so there's no risk of a misbuild here. * debian/slapd.default: now that we have a sensible default behavior in both slapd.init and the maintainer scripts, leave SLAPD_CONF empty to save pain later. * debian/slapd.scripts-common: ... and do the same in migrate_to_slapd_d_style, we just need to comment out the user's previous entry instead of blowing it away. * debian/slapd.scripts-common: call get_suffix in a way that lets us separate responses by newlines, to properly handle the case when a DN has embedded spaces. Introduces a few more stupid fd tricks to work around possible problems with debconf. #595466. * debian/slapd.scripts-common: when parsing the names of includes, handle double-quotes and escape characters as described in slapd.conf(5). #595784. * debian/slapd.scripts-common, debian/slapd.postinst: on upgrade from versions <= 2.4.23-4, explicitly grant access to cn=Subschema, which otherwise is blocked by our added olcAccess settings. #596326. * debian/slapd.init.ldif: set the acl in the default LDIF for new installs, too. * Likewise, grant access to dn.exact="" so that base dn autodiscovery works as intended. #596049. * debian/slapd.init.ldif: synchronize our behavior on new installs with that on upgrades, avoiding the non-standard cn=localroot,cn=config. * debian/slapd.scripts-common: don't run the migration code if slapd.d already exists. #593965. [ Matthijs Mohlmann ] * Remove upgrade_supported_from_backend, implemented patch from Peter Marschall to automatically detect if an upgrade is supported. (#594712) [ Peter Marschall ] * debian/slapd.init: correctly set the slapd.conf argument even when SLAPD_PIDFILE is non-empty in /etc/default/slapd. #593880. * debian/slapd.scripts-common: pass -g to slapadd/slapcat, so that subordinate databases aren't incorrectly included in the dump/restore of the parent database. #594821. [ pam (1.1.1-6) unstable; urgency=low ] * Updated debconf translations: - Swedish, thanks to Martin Bagge (#575875) [ pam (1.1.1-5) unstable; urgency=low ] * debian/rules: pass getconf LFS_CFLAGS so that we get a 64-bit rlimit interface. #579402. * Update debian/source.lintian-overrides to clean up some spurious warnings. * Bump Standards-Version to 3.9.1. * Add lintian overrides for a few more spurious warnings. * debian/patches-applied/no_PATH_MAX_on_hurd: define PATH_MAX for compatibility when it's not already set. #552043. * debian/local/pam-auth-update: Don't try to pass embedded newlines to debconf; backslash-escape them instead and use CAPB escape. * debian/local/pam-auth-update: sort additional module options before writing them out, so that we don't wind up with a different config file on every invocation. Thanks to Jim Paris for the patch. #594123. [ sane-backends (1.0.21-4) unstable; urgency=low ] * debconf translations: + it.po: courtesy of Luca Monducci (#593722). [ xorg (1:7.5+7) unstable; urgency=low ] [ Julien Cristau ] * Nuke x11-common's Conflicts. This was needed for upgrades from the monolith, which aren't relevant anymore. * Also drop Pre-Depends on debconf. The debconf interaction in x11-common.preinst was removed in 1:7.4+2. * Drop versioned build-dep on dpkg 1.7.0. Even woody had that.. * Drop x11-common Depends on debianutils 1.13. That was also in woody. * Add xserver-xorg-video-geode to -all on i386 (#567909). [ Cyril Brulebois ] * Add myself to Uploaders. * Update Debian po files by running debconf-updatepo (through debian/rules
Bug#596899: unblock: ia32-libs/20100914
FS: Can you check your source tree and remove debian/lib32gcc1* (see
below) and then upload 20100927 from git please?
Julien Cristau writes:
> On Tue, Sep 14, 2010 at 23:15:48 +0200, Goswin von Brederlow wrote:
>
>> Please unblock package ia32-libs and ia32-libs-gtk
>>
> Why does this use debian/README.Source instead of debian/README.source
> as policy recommends?
Typo. Fixed in git.
> Why does this include the xorg package, which is everything but a
> library?
It contains xorg because one of the deb packages included lists it as
source:
Package: libglu1-xorg
Architecture: all
Version: 1:7.5+7
Source: xorg
Description: transitional package for Debian etch
This package is provided to smooth upgrades from Debian 3.1 ("sarge") to
Debian etch. It may be safely removed from your system.
I guess that can be savely removed. Makes no sense in ia32-libs. :)
The real package (libglu1-mesa) is already included.
Fixed in git.
> Why does this build-depend on a bunch of biarch libs, since aiui it's
> not actually building anything?
It does run dpkg-shlibdeps to get the right versioned depends on the
biarch libs. Without the libs dpkg-shlibsdeps complains and the depends
would be incomplete. So those are intentional and required.
Note that on ia64 it depends on ia32-libs-core for the same reason.
> The source package includes a bunch of debhelper log files and substvars
> for lib32gcc1.
Not from my side. Must be cruft left from an earlier version on
Fredericks side. Seems that debhelper only removes those files for
packages in debian/control and they aren't tracked in git. So nothing
would have removed them when updating the source with "git pull".
Filing bug against lintian to warn about them.
> the fix-la thing is made of ugly..
Seems to work and is simple. I didn't want to write a whole *.la file
parser just to change the libdir. Patch welcome if you know something
better.
> Cheers,
> Julien
Updating the package (from 20100919) also updates:
New source isdnutils 1:3.9.20060704+dfsg.1-3
New source openldap 2.4.23-6
[ isdnutils (1:3.9.20060704+dfsg.1-3) unstable; urgency=low ]
* QA upload.
* Replace tcl8.3-dev Build Dependency with tcl-dev (#590651).
[ openldap (2.4.23-6) unstable; urgency=high ]
* Check for an empty directory to prevent an rm -f /*. (#597704)
MfG
Goswin
--
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/87aan3j7gc@frosties.localdomain
Re: Advance freeze exception request for libcgi-application-extra-plugin-bundle-perl
Mehdi Dogguy writes: > On 10/13/2010 11:41 AM, Nicholas Bamber wrote: >> Mehdi, When 0.2 was built there was a hope of getting it into >> squeeze. I can understand if the boat was missed on that a long time >> ago. >> >> The issue with #593102 is that the usptream component has an odd >> layout and so needed to be repacked to build correctly. > > Yeah. I do know that (I checked before answering). It will be the first > time Debian will release with l-a-e-p-b-perl. So, missing a module in > the first release can't considered a regression. That's why, *I* don't > consider it as RC. Other people might have a different opinion though. > >> If we produce a 0.1.1 that ONLY updates the copyright for the icons >> and does the repacking for ProtectCSF could we get that into >> squeeze? Of course such a 0.1.1 would not have updated standards >> versions or updated copyright format etc. > > Yes. > >> As such simply downgrading #599794 to something less serious and >> waiting for the freeze to lift is attractive if that is an option. >> > > No, that's still not an option. We could tag it squeeze-ignore if we > don't grant a freeze-exception for it, but the issue remains serious. > > Regards, Well, if you add copyright etc in 0.1.1 then that will fix the bug. Which means 0.1, 0.2, ... are buggy but 0.1.1 will be fixed. Thanks to version tracking in the BTS there should be no confusion. The version in squeeze/sid will be bug free but experimental will be buggy. A new experimental upload of 0.3 would fix that seperately. MfG Goswin -- 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/87sk0a2vkj@frosties.localdomain
Bug#596899: unblock: ia32-libs/20100914
Julien Cristau writes: > On Tue, Sep 14, 2010 at 23:15:48 +0200, Goswin von Brederlow wrote: > >> Please unblock package ia32-libs and ia32-libs-gtk >> > Some more questions now that 20101012 has been uploaded: > - what's the point of the ia32-libs-dev package? nothing seems to > depend on it, and it didn't exist on amd64 until now. I can't find an > explanation or mention of this in the changelog either... > - lib32gcc1.debhelper.log is still there, along with lib32gcc1.substvars > > Cheers, > Julien It is now needed to build wine among other things. We had lots of requests from people wanting to compile 32bit stuff and lots of bugs about the hacked together links previously used being broken that it made sense to reintroduce the ia32-libs-dev package and do it properly. I will think of something to write in the changelog and Debian.NEWS about it. I'm sure there will be another update needed and if that is OK I can add that then. MfG Goswin -- 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/87hbgqtc5e@frosties.localdomain
Bug#596899: unblock: ia32-libs/20100914
Julien Cristau writes: > On Wed, Oct 13, 2010 at 16:12:13 +0200, Goswin von Brederlow wrote: > >> Julien Cristau writes: >> >> > On Tue, Sep 14, 2010 at 23:15:48 +0200, Goswin von Brederlow wrote: >> > >> >> Please unblock package ia32-libs and ia32-libs-gtk >> >> >> > Some more questions now that 20101012 has been uploaded: >> > - what's the point of the ia32-libs-dev package? nothing seems to >> > depend on it, and it didn't exist on amd64 until now. I can't find an >> > explanation or mention of this in the changelog either... >> > - lib32gcc1.debhelper.log is still there, along with lib32gcc1.substvars >> > >> > Cheers, >> > Julien >> >> It is now needed to build wine among other things. >> > wine doesn't build-depend on it. Does that mean wine/amd64 is > unbuildable at the moment? I'm afraid so. Should be fixed shortly. >> We had lots of requests from people wanting to compile 32bit stuff and >> lots of bugs about the hacked together links previously used being >> broken that it made sense to reintroduce the ia32-libs-dev package and >> do it properly. >> > I'd rather they used chroots than clutter the debian archive with more > of this. I have trouble with the word "properly" in your sentence. > > Cheers, > Julien You can't build 32bit packages for amd64 in a 32bit chroot. That results in the wrong arch and wrong dependencies. The "properly" part is that now the *.so symlinks are taken from the packages. Before there was a hardcoded list of links to create and every time a library version changed the respective link would break. MfG Goswin -- 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/87d3r6fxme@frosties.localdomain
Re: Pre-approval request for dpkg sync() changes for squeeze
Phillip Susi writes: > On 10/22/2010 5:35 AM, Guillem Jover wrote: >> 1) Switch back from sync() to fsync() before rename() (while keeping > > Don't you WANT to use sync? If you fsync every file that is going to be > rather slow since it forces a disk write for every file, rather than > allowing writes between each file to be combined and batched. Ideally > you want to unpack all files from all packages being installed/upgraded, > then issue one big sync(), and finally all of the rename()s, with one > final sync(), don't you? > > To throw out some numbers, it seems like it can easily take 60ms or more > for an fsync(), between writing the file data, writing the journal, > writing inode, writing the directory entry, then finally the journal > again. If you are replacing 1000 files then you are spending 60 seconds > just on the fsync calls. If you only use a single sync, then the whole > thing could easily write all of the file data, adjacent inodes, journal > commits, etc in 1-2 seconds with only 2-3 seeks. Or 5 minutes because sync() also needs to write out the 16GB cache data to my usb 1.0 drive that is not involved with dpkg at all. MfG Goswin -- 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/87eibfet8q@frosties.localdomain
Bug#596899: unblock: ia32-libs/20100914
Philipp Kern writes: > On Mon, Oct 25, 2010 at 08:16:41PM +0200, Julien Cristau wrote: >> > You can't build 32bit packages for amd64 in a 32bit chroot. That results >> > in the wrong arch and wrong dependencies. >> But you can use i386 packages on amd64 in a 32bit chroot. That results >> in much less crack smoking all around. > > It's also plain wrong considering that we do exactly that. The buildds run > amd64 with linux32. > > Kind regards, > Philipp Kern The i386 buildds run a amd64 kernel with i386 userspace and they build packages for i386. This was about building 32bit packages for *amd64*. MfG Goswin -- 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/877hh19rrz@frosties.localdomain
Are read-only / install bugs RC?
Hi, I recently did a squeeze install with read-only / and /usr and found a few minor glitches: * ifupdown installed without /dev/shm mounted * /etc/mtab not a link to /proc/mounts * /etc/fstab lists the device for proc as "proc", system says "none", mounting local filesystems gives error * lvm wants to write to /etc unless configured otherwise [1] (No error during boot, lvm handles R/O /etc fine, but reduces usability) At least the first 3 are critical to a read-only / and /usr system and must be fixed before the system boots cleanly and becomes usable. The last one (lvm) is more an anoyance. For example one can't create new logical volumes without remounting / read-write. But it can easily be configured to use /var. My question now is: How critical is this for squeeze and how to fix it? Do we want to support installing with / set read-only? Or should D-I object to / having the read-only option set? Can we mount /target/dev/shm in D-I prior to installing ifupdown? Should D-I set the /etc/mtab link or should mount (util-linux) create it? Should D-I write the proc entry in fstab differently or should mount handle differences in the pseudo device for virtual fileystems better? MfG Goswin -- [1] http://bugs.debian.org/562234 -- 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/87r5ekceax@frosties.localnet
Bug#596899: Please unblock ia32-libs/20101012
Michael Gilbert writes: > On Tue, 9 Nov 2010 16:21:19 +0100, Julien Cristau wrote: >> On Tue, Nov 9, 2010 at 15:41:56 +0100, Thijs Kinkhorst wrote: >> >> > As for ia32-libs, I would be willing to sponsor it but I don't think we >> > should be making uploads for such trivial cleanup operations, is this >> > really necessary to get ia32-libs unblocked? >> > >> No. I just didn't want to unblock it until the wine issue was resolved. >> >> I'm still not convinced ia32-libs-dev is a useful/sane thing to ship. >> Providing a working runtime environment for 32bit programs is one thing. >> Providing a build environment is another entirely, and the way it has to >> mangle .la files (and now .pc too) makes me wonder what other sort of >> brokenness it lets through. > > Why is it that ia32-libs provides all of these 32-bit libs as a > monolithic package anyway? Wouldn't the saner solution be to provide > each desired 32-bit lib from the original source package for that lib > (for example bzip2 provides lib32bz2, lib32bz2-dev, etc)? In that case > ia32-libs is could just be a metapackage, rather than the mess it is > currently. Obviously this solution will need to be deferred to wheezy > (perhaps as a release goal?) since time is short for squeeze. 1) bzip2 compiles a 32bit flavour on amd64. On ia64 it is included in ia32-libs (lenny) or ia32-lib-core (squeeze). No 32bit compiler on ia64. 2) Providing the same binary package from different source packages on different architectures is bad. Confuses the BTS and other things. Providing a lib32bz2 on ia64 not build from bzip2 would be bad. So it would have to be named something liike ia32-libbz2. 3) Ftp-master (Ganneff) rejected a split of ia32-libs into 54 source packages some while back. This was so that each source change would only require that source to be uploaded, preferably by the original maintainer. Also dependencies between libs would have been tracked correctly. 4) Ftp-master (Ganneff) removed ia32-apt-get from Debian. Ia32-apt-get generated the lib32* packages on-the-fly on the users system. It provided 32bit support for basically every library in Debian (or any repository) with instant (security) updates and also support for 3rd party apt repositories with only i386 (e.g. skype) to be directly installable. 5) We now have several conflicting packages that need 32bit support. E.g. nss-ldap and jackd. They should have been split out of ia32-libs already to allow installing the different flavours of them but that has to wait for post squeeze. Dependencies on them might require more splits. At some point doing the full split down to actual source package will be simpler. Someone might have to convince ftp-master to reverse their decision on 3 or 4. MfG Goswin -- 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/87mxp8cd62@frosties.localnet
Bug#596899: Please unblock ia32-libs/20101012
Michael Gilbert writes: > On Tue, 9 Nov 2010 16:21:19 +0100 Julien Cristau wrote: > >> On Tue, Nov 9, 2010 at 15:41:56 +0100, Thijs Kinkhorst wrote: >> >> > As for ia32-libs, I would be willing to sponsor it but I don't think we >> > should be making uploads for such trivial cleanup operations, is this >> > really necessary to get ia32-libs unblocked? >> > >> No. I just didn't want to unblock it until the wine issue was resolved. >> >> I'm still not convinced ia32-libs-dev is a useful/sane thing to ship. >> Providing a working runtime environment for 32bit programs is one thing. >> Providing a build environment is another entirely, and the way it has to >> mangle .la files (and now .pc too) makes me wonder what other sort of >> brokenness it lets through. I probably won't object to this if the >> current breakage gets fixed though, because I'm getting tired of this >> package and would rather do something useful instead. >> >> alsa-plugins also build-depends on ia32-libs, does it need a fix for the >> new stuff too? what about libvdpau? > > alsa-plugins, nspluginwrapper, fglrx-driver, nvidia-graphics-drivers, > and sun-java6 all build-depend on ia32-libs, and build successfully > without ia32-libs-dev. libvdpau doesn't. I've uploaded a fix for that > to mentors: > http://mentors.debian.net/debian/pool/main/l/libvdpau > > Mike Thanks. I checked in the past but overlooked libvdpau. Good to have this looked at by another set of eyeballs. MfG Goswin -- 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/87ipzwcd0w@frosties.localnet
Bug#596899: Please unblock ia32-libs/20101012
"Thijs Kinkhorst" writes: > As for ia32-libs, I would be willing to sponsor it but I don't think we > should be making uploads for such trivial cleanup operations, is this > really necessary to get ia32-libs unblocked? > > I can take a look at wine later this week if no-one beats me to it and if > the release team approves the change for squeeze. Hi, I've just uploaded an updated ia32-libs-core and ia32-libs to mentors: ia32-libs-core (20101117) unstable; urgency=low . [ Goswin von Brederlow ] * Replace lib32icu42 with lib32icu44. * Update Packages: + alsa-lib 1.0.22-2 -> 1.0.23-2.1 + blcr 0.8.2-13 -> 0.8.2-15 + bzip2 1.0.5-4-> 1.0.5-6 + eglibc2.10.2-9 -> 2.11.2-7 + gcc 4.4_4.4.4-1-> 4.4_4.4.5-6 + icu 4.2.1-3-> 4.4.1-6 + libffi3.0.9-2-> 3.0.9-3 + ncurses 5.7+20100313-2 -> 5.7+20100313-4 ia32-libs (20101117) unstable; urgency=low . * Drop ia32-libs-dev from ia64. No 32bit compiler there (Closes: #603679, #540027). * Make ia32-libs-dev priority extra (sync with ftp-master overrides). * Add lintian override for executable stack in libSDL-1.2. . * Packages updated [ esound (0.2.41-8) unstable; urgency=low ] [ libxml2 (2.7.8.dfsg-1) unstable; urgency=low ] ... The ia32-libs-core contains the security update for libc6: * Add any/submitted-origin.diff from Andreas Schwab to forbid the use of $ORIGIN in privileged programs. Add any/cvs-audit-suid.diff to only load SUID audit objects in SUID binaries. Fix CVE-2010-3847. Closes: #600667. The ia32-libs fixes the grave bug of ia32-libs-dev being uninstallable on ia64. With wine in DELAYED/7 that hopefully only leaves the libvdpau patch as blocker for unblocking ia32-libs. I would welcome a sponsoring of these. MfG Goswin -- 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/87eiakcc9c@frosties.localnet
Re: Bug#596899: Please unblock ia32-libs/20101012
Thijs Kinkhorst writes: > On Wednesday 17 November 2010 14:26:07 Goswin von Brederlow wrote: >> ia32-libs-core (20101117) unstable; urgency=low >> ia32-libs (20101117) unstable; urgency=low > > I just uploaded these to sid. Thx. MfG Goswin -- 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/8739qxmikj@frosties.localnet
Re: Bug#596899: Please unblock ia32-libs/20101012
Thijs Kinkhorst writes: > On Wednesday 17 November 2010 14:26:07 Goswin von Brederlow wrote: >> ia32-libs-core (20101117) unstable; urgency=low >> ia32-libs (20101117) unstable; urgency=low > > I just uploaded these to sid. > > I hope they can be unblocked and their urgency pushed by the release team if > they think it's appropriate. > > What about ia32-libs-gtk, will there also be another update for that? > > > Cheers, > Thijs Petty sure all of them will need more updates as new libs are unblocked into squeeze. But there was nothing urgent to fix for ia32-libs-gtk. The current one can go in now and then a later unblock request will just deal with updated libs and have no source changes. MfG Goswin -- 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/877hg9milg@frosties.localnet
Re: Bug#596899: Please unblock ia32-libs/20101012
"Adam D. Barratt" writes: > On Sat, 2010-12-04 at 08:37 +0100, Thijs Kinkhorst wrote: >> On Thursday 18 November 2010 22:24:01 Thijs Kinkhorst wrote: >> > On Wednesday 17 November 2010 14:26:07 Goswin von Brederlow wrote: >> > > ia32-libs-core (20101117) unstable; urgency=low >> > > ia32-libs (20101117) unstable; urgency=low >> > >> > I just uploaded these to sid. >> >> I think ia32-libs-core still needs an unblock? > > Why was the Breaks on "ia32-libs (<< 20100418)" dropped? That isn't Breaks readded as per policy "7.6.1: Overwriting files in other packages". Thanks for noticing. > mentioned in the changelog. (Nor are the two lines that have > retrospectively appeared in the changelog for ia32-libs-core 20100421). Good question actually. Seems like some changes crept in that I had commited locally but not pushed when Frederik uploaded 20100421. I've reverted the commit. > Regards, > > Adam Uploading ia32-libs-core_20101207_source to mentors. Sponsors welcome. Packages updated: [ gcc-4.4 (4.4.5-8) unstable; urgency=low ] [ icu (4.4.1-7) testing-proposed-updates; urgency=high ] The upload contains one more change to the source which I hope is acceptable for squeeze. I replaced the older fetch-and-build script with the newer one from ia32-libs (and ia32-libs-gtk) so that they have the same script again. This includes the part that automatically generates the debian/changelog entries for the updated debs. So the future debian/changelog entries of ia32-libs-core, ia32-libs and ia32-libs-gtk will all look the same too. MfG Goswin -- 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/87vd35v7ou@frosties.localnet
Re: Bug#596899: Please unblock ia32-libs/20101012
Thijs Kinkhorst writes: > On Tuesday 07 December 2010 18:01:05 Goswin von Brederlow wrote: >> Uploading ia32-libs-core_20101207_source to mentors. Sponsors >> welcome. > > I have uploaded this now. I think this needs unblocking so that ia32-libs can > also migrate. > > I've also sponsored ia32-libs-gtk/20101125 which could also need an unblock. > > My interest in this is from a security team standpoint where if we want to be > able to support these packages in an at least somewhat acceptable way, we > need > them to be as up to date w.r.t. the contained packages as possible at time of > release, so that if we need to make an update later we will not drag in > updates for half of the libraries aswell. > > Ideally ia32-libs* contain the same versions of the libraries that are also > released as normal packages. If we update ia32-libs* now that we're in a deep > freeze we can at least get reasonably close. Depending on how long the freeze > still lasts and what updates are let in, it may be desirable to make another > upload later that updates the contained packages. And/or we ship a "catch up" > update in the first point release. > > > Cheers, > Thijs Thanks. On the note of ia32-libs-gtk. It seems that was rejected by an overzelous lintian check. It doesn't depend on libc (no kidding :). I will have to check that and add lintian overrides to it or get lintian fixed. MfG Goswin -- 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/8762uung1i@frosties.localnet
Re: Status of PowerPC64?
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sun, Mar 12, 2006 at 11:13:09PM +0100, Martin Schulze wrote: >> 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? > > The question of which ports are included in the archive is one for the ftp > team to decide, not the release team. (Yes, amd64 integration is a > requirement for the etch release, but that's an architecture that everyone > agrees should be in the archive -- the release blocker only specifies what > order certain things need to happen in.) > > Informally, I'm pretty sure that there are no plans for inclusion of a full > powerpc64 port in the Debian archive, since it has the same performance > problems as sparc64 for applications that don't require the extra address > space. I would like to see a proposal or guideline for multiarch only architectures in the debian archive and in the release. Here are some thoughts that might help someone to write such a proposal: First: What is a multiarch only architecture: - not the prefered architecture for a cpu e.g. sparc64 is slower than sparc so sparc is prefered - architecture provides special features to a subset of binaries e.g. sparc64 provides 64bit address space uclibc provides a slimmer system for embedded use - packages can be build on the prefered architecture of the cpu e.g. gcc -m64 builds sparc64 code on sparc As a result of that multiarch only architectures should have a very limited amount of packages as candidates for building. There hould be a patch to limit the arch:all packages in those archs and to limit uploads to only that subset of packages. The exact subset should probably be defined by the ftp-master and the port team together. Multiarch only architectures don't neccesarily need a buildd infrastructure. The debian/rules files could build debs for the multiarch only architectures on the prefered architecture for that cpu. This only requires a small patch to dpkg-genchanges which is already in the BTS. If this is the way to go I don't know. But it would be an option. Multiarch only architecture don't need an installer. The archive would only have a subset of packages available anyway and they are to be an add-on to the prefered architecture for that cpu. Examples for multiarch only architectures, from the top of my head: Sparc64, mips64, mips64el, powerpc64, s390x. Note that neither i386 nor amd64 fall under this as each is the prefered architecture for some cpus and applications. They do have multiarch but need a full set of packages for optimal performance. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Antique RC bugs (many about licensing)
Nathanael Nerode <[EMAIL PROTECTED]> writes: > I went through the RC bugs which apply to etch and are older than one year. > This is a rather disturbing list, as you would expect from the age of the > bugs. > In most cases I don't think you can expect the maintainers to deal with these > bugs on their own. > > What are the release managers planning to do about these? > > First the easy bugs: > --- > > Package: libuclibc0 (optional; David Schleef) [uclibc/0.9.27-1 ; =] [add/edit > comment] > 261725 [ ] libuclibc0 - violates FHS > > This deserves a long-term exception because the FHS has no reasonable > alternative > placement, and tools expect the placement used here. The multiarch path is different from the cross-tools paths used in libuclibc0. The only argument for the multiarch dirs (over cross-tool dirs) is that it does not pollute toplevel dirs. cross-tools multiarch - /lib/$(gcc -dumpmachine) /usr/$(gcc -dumpmachine)/lib/usr/lib/$(gcc -dumpmachine) /usr/$(gcc -dumpmachine)/include/usr/include/$(gcc -dumpmachine) /usr/bin/$(gcc -dumpmachine)-gcc- A decision about which to use has to be made NOW if you want any say in the matter. Otherwise the multiarch dirs will be added to gcc, binutils and glibc any day now. libuclibc0 should then just follow their example. MfG Goswin PS: A change in the multiarch dir has to be pushed into the FHS multiarch proposal as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 glibc update for sarge
Hi, Martin Zobel-Helas asked me on irc to comment on the update so here we go. The debian-amd64 team would welcome it very much if it got included. As you can see from the bugreport [1] the fix is included upstream and in debian since 2.3.5-3. The bug prevents NPTL threads from functioning correctly which is a big issue on amd64. Most notably mysql hangs due to this. MfG Goswin [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314408 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Security updated versions in sid and amd64
Dear release team, please consider binNMUing the packages (list below) for amd64 to avoid different packages with the same version to exists on the debian archives. Hi, as you might know amd64 has been added to the Debian archive. For this Ftp-Master insisted on rebuilding every package of the archive. This isn't such a bad idea but has some side effects. One of those is that packages with a security update that have no newer version in sid will be rebuild. Their version and filename will match the packages on security.debian.org but their md5sums will differ from the security announcements. This is anoying for anyone doing security checks, breaks merging mirrors into a single repository (like reprepro can do) and can cause apt-get to reinstall the package on every single upgrade/dist-upgrade. Since 3 of them are already rebuild and in the archive it is probably impossible to import the old security builds instead even if we could convince Ftp-Master to allow them in. So there are 2 solutions left for this problem: 1) upload a new source (or NMU it) 2) binNMU the package If you are aware of problems with binNMUing your package, e.g. a strict versioned depends on a arch:all package of the same source, please let the release team know about them and prepare a new source upload asap. In detail the following packages are affected: antiword 0.35-2sarge1 graphviz 2.2.1-1sarge1 gtkdiskfree 1.9.3-4sarge1 ilohamail 0.8.14-0rc3sarge1 ketm 0.0.6-17sarge1 lynx 2.8.5-2sarge1 mysql-dfsg 4.0.24-10sarge1 replicator 3.1-sarge-1.5 weex 2.6.1-6sarge1 Thanks, Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
Julien Danjou <[EMAIL PROTECTED]> writes: > On Fri, Mar 24, 2006 at 03:53:03PM +0100, Martin Zobel-Helas wrote: >> Looks like just rebuilding the security version resolves that error, for >> whatever reason. Julien and me just cross checked that and got the same >> result. > > We tried to reproduce the bug with zobel, and finally discovered the Truth. > > I'll try to explain: > > $ apt-get source tar=1.14-2.1 > $ cd tar-1.14 > $ debuild > ../first-build.log > $ grep REMOTE_SHELL config.h > /* #undef REMOTE_SHELL */ > $ debuild > ../second-build.log > $ grep REMOTE_SHELL config.h > #define REMOTE_SHELL "/usr/bin/rsh" > > And with the diff between log files it is obvious, in the first run we > can see: > > /usr/bin/make > make[1]: Entering directory `/home/tar-1.14' > cd . && /bin/sh /home/tar-1.14/config/missing --run aclocal-1.8 -I m4 > /home/tar-1.14/config/missing: line 52: aclocal-1.8: command not found > WARNING: `aclocal-1.8' is missing on your system. You should only need it if > you modified `acinclude.m4' or `configure.ac'. You might want > to install the `Automake' and `Perl' packages. Grab them from > any GNU archive site. > cd . && /bin/sh /home/tar-1.14/config/missing --run automake-1.8 --gnits > /home/tar-1.14/config/missing: line 52: automake-1.8: command not found > WARNING: `automake-1.8' is missing on your system. You should only need it if > you modified `Makefile.am', `acinclude.m4' or `configure.ac'. > You might want to install the `Automake' and `Perl' packages. > Grab them from any GNU archive site. > cd . && /bin/sh /home/tar-1.14/config/missing --run autoconf > /home/tar-1.14/config/missing: line 52: autoconf: command not found > WARNING: `autoconf' is missing on your system. You should only need it if > you modified `configure.ac'. You might want to install the > `Autoconf' and `GNU m4' packages. Grab them from any GNU > archive site. > /bin/sh ./config.status --recheck > [...] You should touch the files in the right order so the timestamps match. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
Andreas Metzler <[EMAIL PROTECTED]> writes: > On 2006-03-25 Bdale Garbee <[EMAIL PROTECTED]> wrote: > [...] >> However, I don't immediately understand why the auto* tools are being >> invoked by make during this build? > [...] > > [EMAIL PROTECTED]:/tmp$ lsdiff -z tar_1.14-2.1.diff.gz | \ > egrep -v '/debian/|/src/' > tar-1.14/config/config.guess > tar-1.14/config/config.sub > tar-1.14/po/de.po > tar-1.14/configure.ac > tar-1.14/doc/tar.texi > > You are patching configure.ac, which causes auto* to try to regenerate > ./configure. Remove the patchlet and it should build fine. As you are not > shipping the corresponding change to ./configure the thing is > ineffictive anyway, unless you are rebuildung on a system that has the > whole auto* shebang installed.[1] > > hth, cu andreas > > [1] It actually FTBFS for me, with auto* installed: > cd . && /bin/bash /tmp/tar-1.14/config/missing --run aclocal-1.8 -I m4 > aclocal: m4/gettext.m4: 378: macro `AM_LC_MESSAGES' not found in library > aclocal: macro `jm_GLIBC21' required but not defined > make: *** [aclocal.m4] Error 1 And remeber, if you ship a patch for configure and configure.ac then the files will have timestamps in the same order as they are in the diff, which is probably random. To make sure the timestamps fit you have to "touch configure.ac; touch configure" in rules then. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
Martin Zobel-Helas <[EMAIL PROTECTED]> writes: > Hi Andi, > > On Monday, 27 Mar 2006, you wrote: >> * Martin Zobel-Helas ([EMAIL PROTECTED]) [060324 16:00]: >> > Looks like just rebuilding the security version resolves that error, for >> > whatever reason. Julien and me just cross checked that and got the same >> > result. >> > >> > If noone minds we reupload tar with a bumped version number to s-p-u. >> >> Is a binary-only upload enough? If so, why not just queue a binNMU by >> the buildd? (And one should check all the archs BTW, and also add a test >> suite one day :) > > as Julien and me found out, tar works only if either ssh is installed or > the correct enviroment variables are set. As ssh is not installed per > default in buildd enviroment we need to patch the rules-file to get the > correct enviroment variables set. > > So, no, binNMU is not enough (only if you can persue all buildd > maintainers to install ssh inside the changeroot per default ;) ) > > Greetings > Martin Again? I wrote a bug about this years ago with a fix. I think is was just adding --rsh=/usr/bin/rsh to the configure call. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BinNMU for obby
Philipp Kern <[EMAIL PROTECTED]> writes: > Hi there, > > it seems that some A(P|B)I changes in the most recent gmp upload broke > obby and causes its dependent applications to FTBFS (see RC bug > #367862). > > A simple recompile of obby against the current gmp version in the > archive fixed the compilation error for me, so please schedule a BinNMU > of obby 0.3.0-3 across all arches. > > Kind regards, > Philipp Kern That is not the way to fix this. If gmp has changed its API then the dev package has to change its name. If the ABI changed then the soname must change. The same then goes for obby if it reexports the API/ABI. Have you checked that a recompiled obby will work with older gmp packages? If that is not the case then you have no choice but to properly fix this at the source level. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BinNMU for obby
Philipp Kern <[EMAIL PROTECTED]> writes: >> Have you checked that a recompiled obby will work with older gmp >> packages? If that is not the case then you have no choice but to >> properly fix this at the source level. > > They most probably won't work with older, but I could force a shlibs > version dependency locally in obby to require the new version. > > Kind regards, > Philipp Kern Then people can still install the new obby with the old appliactions and they run into the same problem as you do now. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#351269: fragroute needs binNMUs
Niko Tyni <[EMAIL PROTECTED]> writes: > Hi release team, > > the fragroute package needs a recompile because of a libevent1 > ABI change between 0.8-2 and 1.0-1.1 (without a corresponding soname > change). This is the only thing blocking grave bug #351269. > > Could somebody please schedule binNMUs? > > Thanks, Normaly that is not the way to fix this. A library MUST change its soname when it changes the ABI. But why do you only notice that now? Even sarge has libevent1 1.0b-1.1 already. This means that fragroute 1.2-7 in sarge is broken. Do you want to have a binNMU included in the next stable release? MfG Goswin PS: You could upload a new fragroute with the current Standards-Version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Easy removals: B
Pierre HABOUZIT <[EMAIL PROTECTED]> writes: > tag 362959 = > tag 362959 + patch > thanks > > I confirm. I have tracked that issue down, it's because upstream takes > pointer on things that should be gsizes (aka 64 bits on amd64) on things > that are gints (32bits). Pointer should be put into intpointer_t if you must. Or better make a union of int and pointer if you have to mix the two. glib should have its own type for intpointer_t or use that itself. Reusing gsizes sounds awfully wrong. Isn't that 64bit on 32bit cpus as well? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#351269: fragroute needs binNMUs
CCing Julien as he tried to NMU. Niko Tyni <[EMAIL PROTECTED]> writes: > On Mon, May 29, 2006 at 04:24:47AM +0200, Goswin von Brederlow wrote: >> Niko Tyni <[EMAIL PROTECTED]> writes: > >> > the fragroute package needs a recompile because of a libevent1 >> > ABI change between 0.8-2 and 1.0-1.1 (without a corresponding soname >> > change). This is the only thing blocking grave bug #351269. >> > >> > Could somebody please schedule binNMUs? >> > >> > Thanks, >> >> Normaly that is not the way to fix this. A library MUST change its >> soname when it changes the ABI. > > Sure, that was an error. See #304622. > >> But why do you only notice that now? Even sarge has libevent1 1.0b-1.1 >> already. This means that fragroute 1.2-7 in sarge is broken. Do you >> want to have a binNMU included in the next stable release? > >> PS: You could upload a new fragroute with the current Standards-Version. > > I'm not the fragroute maintainer, I'm just trying to help to fix the RC > bug #351269. Apologies if it was not my place to request a binNMU. Is the maintainer MIA? Maybe the package should be checked for that and maybe get a more active one. Are you intrested? Have you asked the maintainer about the fragroute status? Reading through the bug (351269) I see that Julien Danjou <[EMAIL PROTECTED]> already did an NMU of this package to DELAYED/5 on May 16th. That should have hit the archive on the 21st. Julien: What is hapening with your NMU? It seems to be lost. > The fragroute in sarge additionally suffers from the libdumbnet bug > #364821, which was recently fixed for sid. So a binNMU would not be > enough for sarge. No fix for sarge then. Lets hope etch will be ready for X-mas. > Again, sorry if I'm stepping on somebody's toes. > -- > Niko Tyni [EMAIL PROTECTED] You aren't, no worries. It is good when people point out problems like this. And some toes are good to be stepped onto once in a while. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Easy removals: B
Bastian Blank <[EMAIL PROTECTED]> writes: > On Mon, May 29, 2006 at 04:27:24AM +0200, Goswin von Brederlow wrote: >> Pointer should be put into intpointer_t if you must. > > It is intptr_t from stdint.h. Right, sorry. too late at night. >> Or better make a >> union of int and pointer if you have to mix the two. > > This is undefined behaviour, don't do it. Unions are perfectly defined. Do you mean that if you assign a pointer to such a union the int will be undefined and vice versa? That is true but the code should never put a pointer in there and then use it as an int. That is undefined with intptr_t as well. The only thing you can safely do with a pointer cast to an integer is to cast it back. > Bastian MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Easy removals: B
Pierre Habouzit <[EMAIL PROTECTED]> writes: > Le Lun 29 Mai 2006 04:27, Goswin von Brederlow a écrit : >> Pierre HABOUZIT <[EMAIL PROTECTED]> writes: >> > tag 362959 = >> > tag 362959 + patch >> > thanks >> > >> > I confirm. I have tracked that issue down, it's because upstream >> > takes pointer on things that should be gsizes (aka 64 bits on >> > amd64) on things that are gints (32bits). >> >> Pointer should be put into intpointer_t if you must. Or better make a >> union of int and pointer if you have to mix the two. glib should have >> its own type for intpointer_t or use that itself. Reusing gsizes >> sounds awfully wrong. > >> Isn't that 64bit on 32bit cpus as well? > it does not seems so, else the bug would be reproducible on 32bits > machines as well. I think gsize is the size_t from classical C, which > is 32bits on 32bits CPU (aka an int) and 64bits on 64bits CPU (aka a > long). > > the problem is that they use a glib (gtk ?) API to read files, that has > a third argument beeing an out argument for the size of the file. I > don't see where my patch is incorrect, and gcc didn't complained about > comparisons loosing precision or such. I think upstream uses 32bits > devel machines, and never saw the problem of mixing g(u)ints with > gsizes, which is definitely the error. > -- > ·O· Pierre Habouzit > ··O[EMAIL PROTECTED] > OOOhttp://www.madism.org Ahh, sorry, I misunderstood the problem. You aren't storing the address of something in an int but are just passing a pointer to a gint instead of gsize. Changing it to the proper gsize is correct then. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#351269: fragroute needs binNMUs
Julien Danjou <[EMAIL PROTECTED]> writes: > On Mon, May 29, 2006 at 12:30:59PM +0200, Goswin von Brederlow wrote: >> Are you going to NMU fragroute too so it uses the new libdumbnet? > > Only if a binNMU is not sufficient, but I think it should be now, no ? > > Cheers, The bug claims it will be but someone has to test it I guess. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: powerpc64, multiarch vs biarch and etch ...
Steve Langasek <[EMAIL PROTECTED]> writes: > On Tue, May 30, 2006 at 01:26:16PM +0200, Sven Luther wrote: >> On Tue, May 30, 2006 at 12:05:26PM +0200, Andreas Barth wrote: > >> > another month has passed and DebConf happened, so we have a few more >> > changes to announce. > >> > Release Goals >> > = > >> I guess from the above, and previous mails from the multi-arch proposers, >> that this means that multi-arch is now dead for etch, right ? > > I don't see that anything in that mail should be interpreted as a statement > either for or against multiarch in etch. We certainly aren't going to be > endorsing 0-day NMUs for multiarch when the current blockers all relate to > the groundwork that has to be implemented in the base packages -- this is > work that needs to be done, or at least approved of, by the respective > maintainers. No package is currently blocking multiarch compatibility for other packages. Each and every package can be transformed to multiarch on its own and uploaded with the exception of actualy setting the "Multi-Arch:" field. This means: - split binaries out of library packages as per Policy 8.2 (MUST directive) - split architecture independent files out of -dev packages - move arch specific conffiles (e.g. list of plugins) into arch-os-libc dirs - move shared objects (libraries) into arch-os-libc dirs What we (people working on multiarch) need for this is foremost the cooperation of ftp-master not to block package splits as they have done with the libc6/libc-bin split a few weeks before. It is realy anoying for maintainers to do all the work to support multiarch just so they can get shut down by ftp-master when they are done. >> Does this mean that if we want userland powerpc64 support, that we should >> push biarch version of some of the libs needed by those tools needing >> 64bit access ? We already have a few of those in the archive. > > Biarch is a horrible, non-scalable, bletcherous design. With or without > multiarch support, the fewer biarch packages there are in the archive, the > better, IMHO. > > But I'm not an ftpmaster, so MHO doesn't actually count for much here since > I'm not the one who decides how many biarch packages are too many. As Release team you should be able excert some weight to influence ftp-master behaviour or have they come rouge? :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: powerpc64, multiarch vs biarch and etch ...
Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Wed, 31 May 2006, Sven Luther wrote: >> Maybe, but biarch are what we have now, and what can be made to work. I asked >> this same question 6+ month ago, and you gave me the same reply, and >> multi-arch has not progressed an inch since then. > > This is wrong. Sven, please stop saying that nothing changed when you're > simply annoyed that it's not finished yet. > > In the last 6 months we had: > - multiarch support added to ld by Aurelien jarno 2 line patch pending for a year before that plus one new idea to add /lib/ldconfig/. Overall just a better way than editing ld.so.conf. > - a report from HP/Canonical about how to go forward A summary of past consensus plus some new ideas for a new dpkg. Nothing new for !dpkg packages. > - another proposition from Goswin van Brederlow (see his recent work and > bugreports on -dpkg) Mostly resubmitting stuff that has been around for years cleaned up for sids dpkg. This time split into small chunks that hopefully will get accepted with the new dpkg team. > Cheers, Overall the progress, if any, is far from encouraging. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: powerpc64, multiarch vs biarch and etch ...
Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Wed, 31 May 2006, Sven Luther wrote: >> > In the last 6 months we had: >> > - multiarch support added to ld by Aurelien jarno >> >> And Aurelien Jarno telling us he was sick of nothing happening in early >> april, >> and wanting to drop it all. And apparently some of his multi-arch proposals >> was refused by the ftp-masters, or so azeem told me yesterday. > > Aurelien didn't want to drop "multiarch" but didn't want to push it > further because it was too much work for him and he's busy enough already. > The only thing that has been refused is the libc-bin package which I'm > confident will come back soon since the discussion on -devel resulted in a > consensus "it should be safe if done properly". He told me he will only reupload it if ftp-master says they will accept it now. He doesn't want to waste time on a hopeless cause. >> > - a report from HP/Canonical about how to go forward >> >> Indeed, i heard rumors of it not having very much content apart from tollef's >> work which is nothing really new. > > What about reading it and being constructive instead of relying on rumors? > > It is indeed more a summary than something completely new but it does help > however. The suggestion solution is also a long term solution (dpkg > 2.0)... which clearly is not going to happen for etch. And not for etch+1 or probably etch+2 and there still remains the problem of an upgrade path. >> > - another proposition from Goswin van Brederlow (see his recent work and >> > bugreports on -dpkg) >> >> Yes, but what is needed if we want multi-arch in etch we need things to go >> forward. The freeze is in 2 month from now, and there is load of work to be >> done to make the packages multi-arch ready, rebuild all the archive or part >> of >> it, find all the bugs in them, etc. > > Everybody understands that we're not going to have full multi-arch support > for etch. Goswin tries to push some required changes to dpkg that will > allow a smooth transition to multi-arch package in etch+1. I tried pushing in full multiarch but it gets delayed at every corner. There can't be any progress if it takes over a year to push a 2 line patch into binutils. >> There are patches to dpkg, to the toolchain, etc, but the step from plan to >> actual implementation has not be done. > > So help the people interested in doing it instead of complaining that it's > the fault of the release team. The release team doesn't own Debian, they > merely define a reasonable timeframe for changes that other developers > want to push through. > > And multiarch lacked (for a long time) a bit of momentum. It goes better > now, but it's clearly too late for etch. The ability to NMU packages would have added a hell of a lot of momentum. That would have been the help the release team could have given. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: powerpc64, multiarch vs biarch and etch ...
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sat, Jun 03, 2006 at 09:37:35AM +0200, Goswin von Brederlow wrote: >> > And multiarch lacked (for a long time) a bit of momentum. It goes >> > better now, but it's clearly too late for etch. > >> The ability to NMU packages would have added a hell of a lot of >> momentum. That would have been the help the release team could have >> given. > > No, sorry, the right way to get a change like multiarch done is by > building consensus that it's an appropriate thing to do, not by NMUing > core packages over the reservations of the maintainers. So who do I have to convince that multiarch is appropriate? I haven't seen anyone speak out against its basic goals. Everyone I've spoken too sees the sense in supporting s390x, sparc64, mips64, mipsel64, powerpc64 and ia32 for amd64. And after a few minutes discussion they usualy see why multiarch is a good solution to the problem. There just is no anti-multiarch movement that needs a change of mind. Apart from ftp-master blocking the glibc split there has only been inaction or disintrest but no opposition. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
