Bug#1004831: transition: ffmpeg
On Sun, 03 Jul 2022 23:26:46 -0500 Steven Robbins wrote: > Hello, > > On Wed, 22 Jun 2022 22:13:11 +0200 Sebastian Ramacher > wrote: > > > ffmpeg got a new major release including API and ABI breakage. > > Hence, it needs a transition. The reverse dependencies are not yet > > ready, so this bug is just a heads up and should help to track > > progress. Due to ffmpeg's security record, we should complete this > > transition for bookworm. There isn't much that can reasonably be done within Debian for this transition, it's all dependent on upstream work. It seems unlikely that any of the affected packages will be able to clear this transition with a limited Debian-specific patch. https://github.com/void-linux/void-packages/pull/36315 is a useful overview on how various upstream projects are progressing (or not) for ffmpeg5. It's patchy and slow progress. It seems unlikely that any Debian-specific timelines will have any effect on the rate of progress. > Reverse dependencies had 4 months to fix their bugs, so I'm going > ahead with this one. Not even close to enough time for all affected upstream teams. > Yes, well as noted: this is a major release with ABI and API > breakage. It is unrealistic to expect the entire open source world > to adopt this all at once. Digikam upstream, for example, is working > on the transition, but it is not straightforward. Current > recommendation is to continue to build against the version 4 API [1]. > > Consider reintroducing the ffmpeg 4 libraries alongside version 5. I suspect that will come down to which packages are still affected in a few months time and the relative importance of having specific packages in bookworm. It does seem reasonable to consider this now and work out just what would be required and what can be skipped. The autoremovals from testing will start to happen soon, that's a chance to run up a few clean bookworm VMs and see what is missing. Debian has GTK3 and GTK4, Qt5 and Qt6 etc., it's not ideal and it is a lot of work but it may be necessary to have libavcodec4-dev and libavcodec-dev with a new source package ffmpeg4 alongside ffmpeg. > > Thank you, > -Steve > > [1] https://mail.kde.org/pipermail/digikam-users/2022-July/033796.html > -- Neil Williams = https://linux.codehelp.co.uk/ pgpdUEEiCrIBO.pgp Description: OpenPGP digital signature
Bug#991628: buster-pu: package pillow/5.4.1-2+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Fix for CVE-2021-34552 (#991293) is mitigated by FORTIFY_SOURCE, so
this upload targets proposed-updates instead of security after
discussion with Moritz.
Other pending CVEs in pillow for buster have been set to ignored as
the patches would be too intrusive in buster due mainly to binary
changes in the test suite support files.
Debdiff is attached.
pillow (5.4.1-2+deb10u3) buster; urgency=medium
.
* Non-maintainer upload by the Security Team.
.
[ Moritz Mühlenhoff ]
* CVE-2020-35653 CVE-2020-35655 CVE-2021-27921 CVE-2021-27922
CVE-2021-27923 CVE-2021-25290 CVE-2021-25292 CVE-2021-28677
CVE-2021-28678
.
[ Neil Williams ]
* CVE-2021-34552
-- System Information:
Debian Release: 10.10
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diffstat for pillow-5.4.1 pillow-5.4.1
changelog
| 13
patches/CVE-2020-35653.patch
| 26 +
patches/CVE-2020-35655.patch
| 87
patches/CVE-2021-27921_CVE-2021-27922_CVE-2021-27923_CVE-2021-25290_CVE-2021-25292_CVE-2021-28677_CVE-2021-28678.patch
| 209 ++
patches/CVE-2021-34552.patch
| 40 +
patches/series
|4
6 files changed, 379 insertions(+)
diff -Nru pillow-5.4.1/debian/changelog pillow-5.4.1/debian/changelog
--- pillow-5.4.1/debian/changelog 2020-07-22 16:25:31.0 +0100
+++ pillow-5.4.1/debian/changelog 2021-07-20 07:21:31.0 +0100
@@ -1,3 +1,16 @@
+pillow (5.4.1-2+deb10u3) buster; urgency=medium
+ * Non-maintainer upload by the Security Team.
+
+ [ Moritz Mühlenhoff ]
+ * CVE-2020-35653 CVE-2020-35655 CVE-2021-27921 CVE-2021-27922
+CVE-2021-27923 CVE-2021-25290 CVE-2021-25292 CVE-2021-28677
+CVE-2021-28678
+
+ [ Neil Williams ]
+ * CVE-2021-34552
+
+ -- Neil Williams Tue, 20 Jul 2021 07:21:31 +0100
+
pillow (5.4.1-2+deb10u2) buster; urgency=medium
* CVE-2020-11538 CVE-2020-10378 CVE-2020-10177
diff -Nru pillow-5.4.1/debian/patches/CVE-2020-35653.patch
pillow-5.4.1/debian/patches/CVE-2020-35653.patch
--- pillow-5.4.1/debian/patches/CVE-2020-35653.patch1970-01-01
01:00:00.0 +0100
+++ pillow-5.4.1/debian/patches/CVE-2020-35653.patch2021-07-20
07:21:31.0 +0100
@@ -0,0 +1,26 @@
+--- a/src/PIL/PcxImagePlugin.py
b/src/PIL/PcxImagePlugin.py
+@@ -63,9 +63,9 @@
+ version = i8(s[1])
+ bits = i8(s[3])
+ planes = i8(s[65])
+-stride = i16(s, 66)
++ignored_stride = i16(s, 66)
+ logger.debug("PCX version %s, bits %s, planes %s, stride %s",
+- version, bits, planes, stride)
++ version, bits, planes, ignored_stride)
+
+ self.info["dpi"] = i16(s, 12), i16(s, 14)
+
+@@ -102,6 +102,11 @@
+ self.mode = mode
+ self._size = bbox[2]-bbox[0], bbox[3]-bbox[1]
+
++# don't trust the passed in stride. Calculate for ourselves.
++# CVE-2020-35655
++stride = (self._size[0] * bits + 7) // 8
++stride += stride % 2
++
+ bbox = (0, 0) + self.size
+ logger.debug("size: %sx%s", *self.size)
+
diff -Nru pillow-5.4.1/debian/patches/CVE-2020-35655.patch
pillow-5.4.1/debian/patches/CVE-2020-35655.patch
--- pillow-5.4.1/debian/patches/CVE-2020-35655.patch1970-01-01
01:00:00.0 +0100
+++ pillow-5.4.1/debian/patches/CVE-2020-35655.patch2021-07-20
07:18:32.0 +0100
@@ -0,0 +1,87 @@
+2f409261eb1228e166868f8f0b5da5cda52e55bf and
9a2c9f722f78773e608d44710873437baf3f17d1
+upstream
+
+--- pillow-5.4.1.orig/src/libImaging/SgiRleDecode.c
pillow-5.4.1/src/libImaging/SgiRleDecode.c
+@@ -107,14 +107,33 @@ ImagingSgiRleDecode(Imaging im, ImagingC
+ int err = 0;
+ int status;
+
++/* size check */
++if (im->xsize > INT_MAX / im->bands ||
++im->ysize > INT_MAX / im->bands) {
++state->errcode = IMAGING_CODEC_MEMORY;
++return -1;
++}
++
+ /* Get all data from File descriptor */
+ c = (SGISTATE*)state->context;
+ _imaging_seek_pyFd(state->fd, 0L, SEEK_END);
+ c->bufsize = _imagi
Bug#991298: unblock: pillow/8.1.2+dfsg-0.3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package pillow
8.1.2+dfsg-0.3 includes fix for CVE-2021-34552
unblock pillow/8.1.2+dfsg-0.3
diffstat for pillow-8.1.2+dfsg pillow-8.1.2+dfsg
changelog|8
patches/CVE-2021-34552.patch | 40
patches/series |1 +
3 files changed, 49 insertions(+)
diff -Nru pillow-8.1.2+dfsg/debian/changelog pillow-8.1.2+dfsg/debian/changelog
--- pillow-8.1.2+dfsg/debian/changelog 2021-06-13 17:11:04.0 +0100
+++ pillow-8.1.2+dfsg/debian/changelog 2021-07-19 09:52:20.0 +0100
@@ -1,3 +1,11 @@
+pillow (8.1.2+dfsg-0.3) unstable; urgency=high
+
+ * Non-maintainer upload by the Security Team.
+ * CVE-2021-34552 - Replace sprintf with snprintf. Backport upstream change
+from 8.3 to 8.1.
+
+ -- Neil Williams Mon, 19 Jul 2021 09:52:20 +0100
+
pillow (8.1.2+dfsg-0.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch
pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch
--- pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch 1970-01-01
01:00:00.0 +0100
+++ pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch 2021-07-19
09:51:59.0 +0100
@@ -0,0 +1,40 @@
+From 5f4504bb03f4edeeef8c2633dc5ba03a4c2a8a97 Mon Sep 17 00:00:00 2001
+From: Andrew Murray
+Date: Tue, 15 Jun 2021 15:14:26 +1000
+Subject: [PATCH 1/2] Limit sprintf modes to 10 characters
+
+From 518ee3722a99d7f7d890db82a20bd81c1c0327fb Mon Sep 17 00:00:00 2001
+From: Andrew Murray
+Date: Wed, 30 Jun 2021 23:47:10 +1000
+Subject: [PATCH 2/2] Use snprintf instead of sprintf
+
+* https://github.com/python-pillow/Pillow/pull/5567/files
+* Replace sprintf with snprintf in src/libImaging/Convert.c
+
+---
+--- a/src/libImaging/Convert.c
b/src/libImaging/Convert.c
+@@ -1664,9 +1664,8 @@
+ #ifdef notdef
+ return (Imaging) ImagingError_ValueError("conversion not supported");
+ #else
+-static char buf[256];
+-/* FIXME: may overflow if mode is too large */
+-sprintf(buf, "conversion from %s to %s not supported", imIn->mode,
mode);
++static char buf[100];
++snprintf(buf, 100, "conversion from %.10s to %.10s not supported",
imIn->mode, mode);
+ return (Imaging) ImagingError_ValueError(buf);
+ #endif
+ }
+@@ -1724,9 +1723,8 @@
+ }
+ #else
+ {
+- static char buf[256];
+- /* FIXME: may overflow if mode is too large */
+- sprintf(buf, "conversion from %s to %s not supported in
convert_transparent", imIn->mode, mode);
++ static char buf[100];
++ snprintf(buf, 100, "conversion from %.10s to %.10s not supported in
convert_transparent", imIn->mode, mode);
+ return (Imaging) ImagingError_ValueError(buf);
+ }
+ #endif
diff -Nru pillow-8.1.2+dfsg/debian/patches/series
pillow-8.1.2+dfsg/debian/patches/series
--- pillow-8.1.2+dfsg/debian/patches/series 2021-06-13 17:10:51.0
+0100
+++ pillow-8.1.2+dfsg/debian/patches/series 2021-07-19 09:45:27.0
+0100
@@ -7,3 +7,4 @@
CVE-2021-28676.patch
CVE-2021-28677.patch
CVE-2021-28678.patch
+CVE-2021-34552.patch
Bug#929572: unblock: dpkg-cross/2.6.15-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package dpkg-cross I've applied the patch supplied by Helmut in bug #868483 and I've left further optimisations to be done during the bullseye cycle. dpkg-cross-868483.diff is attached. I've uploaded this small change with --delayed 1 Thanks. unblock dpkg-cross/2.6.15-2.1 -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diffstat for dpkg-cross-2.6.15 dpkg-cross-2.6.15 config/cross-config.alpha|1 + config/cross-config.amd64|1 + config/cross-config.hppa |1 + config/cross-config.m68k |1 + config/cross-config.mips64el |1 + config/cross-config.ppc64el |1 + config/cross-config.s390x|1 + debian/changelog |9 + 8 files changed, 16 insertions(+) diff -Nru dpkg-cross-2.6.15/config/cross-config.alpha dpkg-cross-2.6.15/config/cross-config.alpha --- dpkg-cross-2.6.15/config/cross-config.alpha 2015-01-22 19:16:37.0 + +++ dpkg-cross-2.6.15/config/cross-config.alpha 2019-05-26 11:54:08.0 +0100 @@ -1,3 +1,4 @@ +. `dirname $ac_site_file`/cross-config.cache # # alpha specific configure variables # diff -Nru dpkg-cross-2.6.15/config/cross-config.amd64 dpkg-cross-2.6.15/config/cross-config.amd64 --- dpkg-cross-2.6.15/config/cross-config.amd64 2011-03-27 07:14:10.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.amd64 2019-05-26 11:54:08.0 +0100 @@ -1,3 +1,4 @@ +. `dirname $ac_site_file`/cross-config.cache # # amd64-specific configuration variables # diff -Nru dpkg-cross-2.6.15/config/cross-config.hppa dpkg-cross-2.6.15/config/cross-config.hppa --- dpkg-cross-2.6.15/config/cross-config.hppa 2011-03-27 07:14:10.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.hppa 2019-05-26 11:54:08.0 +0100 @@ -1,3 +1,4 @@ +. `dirname $ac_site_file`/cross-config.cache # # hppa specific configure variables # diff -Nru dpkg-cross-2.6.15/config/cross-config.m68k dpkg-cross-2.6.15/config/cross-config.m68k --- dpkg-cross-2.6.15/config/cross-config.m68k 2011-03-27 07:14:10.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.m68k 2019-05-26 11:54:08.0 +0100 @@ -1,3 +1,4 @@ +. `dirname $ac_site_file`/cross-config.cache # # m68k specific configure variables # diff -Nru dpkg-cross-2.6.15/config/cross-config.mips64el dpkg-cross-2.6.15/config/cross-config.mips64el --- dpkg-cross-2.6.15/config/cross-config.mips64el 1970-01-01 01:00:00.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.mips64el 2019-05-26 11:54:08.0 +0100 @@ -0,0 +1 @@ +. `dirname $ac_site_file`/cross-config.cache diff -Nru dpkg-cross-2.6.15/config/cross-config.ppc64el dpkg-cross-2.6.15/config/cross-config.ppc64el --- dpkg-cross-2.6.15/config/cross-config.ppc64el 1970-01-01 01:00:00.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.ppc64el 2019-05-26 11:54:08.0 +0100 @@ -0,0 +1 @@ +. `dirname $ac_site_file`/cross-config.cache diff -Nru dpkg-cross-2.6.15/config/cross-config.s390x dpkg-cross-2.6.15/config/cross-config.s390x --- dpkg-cross-2.6.15/config/cross-config.s390x 1970-01-01 01:00:00.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.s390x 2019-05-26 11:54:08.0 +0100 @@ -0,0 +1 @@ +. `dirname $ac_site_file`/cross-config.cache diff -Nru dpkg-cross-2.6.15/debian/changelog dpkg-cross-2.6.15/debian/changelog --- dpkg-cross-2.6.15/debian/changelog 2017-07-24 17:09:56.0 +0100 +++ dpkg-cross-2.6.15/debian/changelog 2019-05-26 11:54:15.0 +0100 @@ -1,3 +1,12 @@ +dpkg-cross (2.6.15-2.1) unstable; urgency=medium + + [ Helmut Grohne ] + * Non-maintainer upload. + * cross-config: Ensure that every release arch uses the common file. +(Closes: #868483) + + -- Neil Williams Sun, 26 May 2019 11:54:15 +0100 + dpkg-cross (2.6.15-2) unstable; urgency=medium * Make code perl 5.26-compatible (escape left braces in regexps).
Re: How does the transition tracker for python3.7 progress?
On Wed, 3 Oct 2018 19:15:14 +0200 Mattia Rizzolo wrote: > Hi! > > On Wed, Oct 03, 2018 at 05:20:59PM +0100, Neil Williams wrote: > > https://release.debian.org/transitions/html/python3.7.html > > > > At what point does a package listed as unknown get processed to > > determine if it is good or bad? > > python3 transitions are annoyingly hard to track due to many case > corners. > > Yesterday I failed at least 6 bugs against packages that were marked > as unknown due to the wrong build-depends line (IIRC you were amongst > the maintainers of those packages). > > > What is the trigger for that process? > > that's enterely manual, and the sad bit is that there aren't "notes" > nor anybody is going to manually exclude packages from the tracker. > Except people fixing their wrong build-depends (but that still leaves > cases of packages correctly build-depending on e.g. python3-all-)bg > for tests but still being arch:all and so creating a package with a > depends on only a possibly unversioned python3). > > > How do arch:all packages affect the tracker? > > like all other packages... I don't understand your question. > > > https://tracker.debian.org/pkg/nuitka is marked as good but all of > > the other arch:all packages are unknown. > > most of arch:all packages shouldn't appear in the tracker at all (and > indeed they don't). Thanks, that answered my question above. > > > Equally, packages are listed as unknown with a highlight denoting > > "Dependencies" on another package. If that package is marked as > > good, why is the unknown package not checked? > > What highlighting are you talking about? It's a highlight shown on mouseover of the package name in the transition page. Turns out it's not relevant to the problem itself. > > > The package I care about most is at Dependency level 7 and has a > > highlight Dependencies: pyyaml which is in the good list. How do I > > identify what (if anything) I can do about this being listed as > > unknown? As far as I can tell, the package doesn't depend on any of > > the packages currently listed as bad (most of which are sid-only). > > I assume you are talking about src:lava. > > It's weird, I thought I had sent a bug to that, I wonder why I > didn't... It's ok, I can see the problem from your bug report on black. Thank you, that has made it much clearer. I've updated black and uploaded with a build-depends on python3 but not the rest of the list of alternatives I had included in -1. I'm preparing an update of src:lava as well. > > At any rate, the issue is like this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910094 > I must have messed up my list while running mass-bug > > > One of my packages is at Dependency level 1 and unknown but I can't > > tell if I have done anything wrong or how the package affects the > > transition. > > I assume you are talking about src:black. > And indeed I did open a bug for that one yesterday: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910094 > (incidentally, the same bug I reported a few lines above :P) > > > At any rate, those false positives only cause noise in the tracker, > they aren't actually hindering the transition if not for people like > you now and me yesterday that wested their time looking at them. All the more reason to fix the false positive. Sorry to have taken up your time and I am grateful for the help. > > > Currently proper overview of the transition is blocked by > src:python3.7 not migrating due to src:openssl blocking the world. OK, I understand. > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > more about me: > https://mapreri.org : :' : Launchpad > user: https://launchpad.net/~mapreri `. `'` Debian > QA page: https://qa.debian.org/developer.php?login=mattia `- -- Neil Williams h...@codehelp.co.uk pgpJt47Txyq6W.pgp Description: OpenPGP digital signature
How does the transition tracker for python3.7 progress?
https://release.debian.org/transitions/html/python3.7.html At what point does a package listed as unknown get processed to determine if it is good or bad? What is the trigger for that process? How do arch:all packages affect the tracker? https://tracker.debian.org/pkg/nuitka is marked as good but all of the other arch:all packages are unknown. Equally, packages are listed as unknown with a highlight denoting "Dependencies" on another package. If that package is marked as good, why is the unknown package not checked? There are links to RC bugs but not all of those RC bugs relate to the transition (e.g. boost and a few others are RC due to an invalid maintainer address). The package I care about most is at Dependency level 7 and has a highlight Dependencies: pyyaml which is in the good list. How do I identify what (if anything) I can do about this being listed as unknown? As far as I can tell, the package doesn't depend on any of the packages currently listed as bad (most of which are sid-only). One of my packages is at Dependency level 1 and unknown but I can't tell if I have done anything wrong or how the package affects the transition. Help? -- Neil Williams h...@codehelp.co.uk pgp8G21EaDHxE.pgp Description: OpenPGP digital signature
Bug#872991: The upload of lava-tool 0.21-1+deb9u1 has now been made.
My qa.debian.org page shows a stable-new upload but the link to https://ftp-master.debian.org/new/lava-tool_0.21-1%2Bdeb9u1.html doesn't exist and there's nothing on the tracker for lava-tool. https://lists.alioth.debian.org/pipermail/pkg-linaro-lava-devel/Week-of-Mon-20170911/000958.html Did I miss a step? Should I have closed this bug with the upload? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpZNrGy5ExtT.pgp Description: OpenPGP digital signature
Bug#872991: stretch-pu: package lava-tool/0.21-1
Control: tags -1 - moreinfo On Sun, 27 Aug 2017 13:52:28 +0100 "Adam D. Barratt" <a...@adam-barratt.org.uk> wrote: > Control: tags -1 + moreinfo > > On Wed, 2017-08-23 at 14:37 +0100, Neil Williams wrote: > > --- lava-tool-0.21/debian/changelog 2017-01-19 > > 15:46:04.0 + +++ lava-tool-0.21/debian/changelog > > 2017-08-23 11:55:21.0 +0100 @@ -1,3 +1,9 @@ > > +lava-tool (0.21-1+deb9u1) stretch; urgency=medium > > + > > + * Add missing dependency: python-simplejson. (Closes: #872782) > > The metadata for #872782 suggests that it also affects the version of > lava-tool in unstable - is that correct? If it is, please resolve the > issue in unstable first; if not, please add an appropriate fixed > version to the bug so that it's clear which versions are affected. > (And in either case, let us know afterwards.) Fixed version added for bug 872782 to lava-tool 0.23-1 to reflect status of bug as fixed in unstable and testing. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpVRBYTE7kJi.pgp Description: OpenPGP digital signature
Bug#872991: stretch-pu: package lava-tool/0.21-1
Control: tags -1 - moreinfo
On Wed, 23 Aug 2017 14:36:44 +0200
Martin Zobel-Helas <zo...@debian.org> wrote:
> Control: tags -1 + moreinfo
>
> Hi,
>
> On Wed Aug 23, 2017 at 12:32:39 +0100, Neil Williams wrote:
> > diff -Nru lava-tool-0.21/debian/changelog
> > lava-tool-0.21/debian/changelog ---
> > lava-tool-0.21/debian/changelog 2017-01-19
> > 15:46:04.0 + +++ lava-tool-0.21/debian/changelog
> > 2017-08-23 11:55:21.0 +0100 @@ -1,3 +1,9 @@ +lava-tool
> > (0.21-1+deb9u1) stable-proposed-updates; urgency=medium +
> > + * Add missing dependency: python-simplejson. (Closes: #872782)
> > +
> > + -- Neil Williams <codeh...@debian.org> Wed, 23 Aug 2017 11:55:21
> > +0100 +
> > lava-tool (0.21-1) unstable; urgency=medium
> >
> >* New upstream release
>
> i think you want 's/stable-proposed-updates/stretch/' in your
> debian/changelog.
Thanks, I'll fix that.
diff -Nru lava-tool-0.21/debian/changelog lava-tool-0.21/debian/changelog
--- lava-tool-0.21/debian/changelog 2017-01-19 15:46:04.0 +
+++ lava-tool-0.21/debian/changelog 2017-08-23 11:55:21.0 +0100
@@ -1,3 +1,9 @@
+lava-tool (0.21-1+deb9u1) stretch; urgency=medium
+
+ * Add missing dependency: python-simplejson. (Closes: #872782)
+
+ -- Neil Williams <codeh...@debian.org> Wed, 23 Aug 2017 11:55:21 +0100
+
lava-tool (0.21-1) unstable; urgency=medium
* New upstream release
diff -Nru lava-tool-0.21/debian/control lava-tool-0.21/debian/control
--- lava-tool-0.21/debian/control 2017-01-19 15:46:04.0 +
+++ lava-tool-0.21/debian/control 2017-08-23 11:55:21.0 +0100
@@ -22,7 +22,7 @@
Package: lava-tool
Architecture: all
-Depends: python-setuptools,
+Depends: python-setuptools, python-simplejson,
${python:Depends}, ${misc:Depends}
Recommends: ca-certificates
Breaks: lava-dashboard-tool (<< 0.8), lava-scheduler-tool (<< 0.6)
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpdL0FdgZD_I.pgp
Description: OpenPGP digital signature
Bug#872991: stretch-pu: package lava-tool/0.21-1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
To fix bug #872782, I propose to make an upload to stretch-pu with this diff:
changelog |6 ++
control |2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff -Nru lava-tool-0.21/debian/changelog lava-tool-0.21/debian/changelog
--- lava-tool-0.21/debian/changelog 2017-01-19 15:46:04.0 +
+++ lava-tool-0.21/debian/changelog 2017-08-23 11:55:21.0 +0100
@@ -1,3 +1,9 @@
+lava-tool (0.21-1+deb9u1) stable-proposed-updates; urgency=medium
+
+ * Add missing dependency: python-simplejson. (Closes: #872782)
+
+ -- Neil Williams <codeh...@debian.org> Wed, 23 Aug 2017 11:55:21 +0100
+
lava-tool (0.21-1) unstable; urgency=medium
* New upstream release
diff -Nru lava-tool-0.21/debian/control lava-tool-0.21/debian/control
--- lava-tool-0.21/debian/control 2017-01-19 15:46:04.0 +
+++ lava-tool-0.21/debian/control 2017-08-23 11:55:21.0 +0100
@@ -22,7 +22,7 @@
Package: lava-tool
Architecture: all
-Depends: python-setuptools,
+Depends: python-setuptools, python-simplejson,
${python:Depends}, ${misc:Depends}
Recommends: ca-certificates
Breaks: lava-dashboard-tool (<< 0.8), lava-scheduler-tool (<< 0.6)
The need for python-simplejson was removed in subsequent upstream releases, so
0.23-1 in unstable is not affected.
0.21-1 in stretch is currently unusable without python-simplejson being
installed
due to a mistake upstream where simplejson was removed from setup.py whilst some
parts still tried to import it.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
lava-server and django in Stretch #863267 and #847277
Hi guys, Status update on the lava-server and django upgrade problems. As far as we know, the vast majority of existing installations of lava-server will already have django 1.8 installed from jessie-backports and will therefore not see any problems upgrading to Stretch. New Stretch installations with no previous user data will also not be affected. This is entirely about upgrades of lava-server directly from jessie to stretch. I've been discussing with Brian May and Raphael Hertzog about where the actual bug lies, it *seems* to be in the dependency graph calculations of the migration loader inside django 1.10. It is not yet 100% clear if this is a bug caused in 1.7 and revealed by 1.10 or a bug introduced in 1.10 as a result of bug fixes upstream in this area. We are still investigating and we're hoping for some kind of fix soon. Note: the problem disappears completely if django 1.8 is installed between 1.7 and 1.10 and installing 1.8 can even rescue a broken installation in limited circumstances if the admin makes only minimal actions before doing so. Once that is complete, 1.10 can upgrade cleanly. Steve and I will be on VAC from a few hours from now for 1 week. I have tasked the LAVA software team upstream to continue working with Brian and Raphael on potential fixes and testing. Hopefully, we should have a fix or a workaround ready to upload as soon as I'm back. Apologies for the hassle caused here. Please bear with us. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpEdf_eYsBXx.pgp Description: OpenPGP digital signature
Bug#857345: jessie-pu: package debootstrap/1.0.72
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu The fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757819 needs to be available in jessie to solve problems with using --foreign with any Stretch bootstrap operation. Would this be possible to do as an upload to proposed-updates and would this fix be acceptable for the next Jessie point release? -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Bug#830978: Browserified javascript and DFSG 2
On Sat, 16 Jul 2016 06:49:56 -0400 Sam Hartman <hartm...@debian.org> wrote: > >>>>> "Neil" == Neil Williams <codeh...@debian.org> writes: > >> > * The point of having the source code (with an appropriate > >> licence > etc.) is so that all our contributors, downstreams, > >> and users are > able to modify the code and to share their > >> modifications with each > other, with Debian, and with > >> upstream. > >> > >> I agree this is an important consideration, but not serious > >> enough to reject a package. > > Neil> So you consider that upstream are not fully-qualified users > Neil> somehow and therefore do not get the benefits of the DFSG? > Neil> If the freedoms of users who choose to interact with > Neil> upstream are reduced by choices made within the package > Neil> then the package is breaking the DFSG by penalising a field > Neil> of endeavour. > > Neil, I have a fairly strong negative emotional reaction when I read > the paragraph you wrote. I'd like to share that because I think if I > share where I'm coming from it will be easier for me to hear you, and > easier to participate calmly. > > When I read the above, I'm worried because I think that freedoms I > care about would be limited, and I don't like to see the DFSG > reshaped to limit freedoms. > I'm afraid when I think I hear us seeding the contents of Debian to > upstream. We are Debian; we choose what Debian is. > > I want to stress that I think you and I are in agreement on > handlebars. > > However, I do think the freedom to fork from upstream, to move away > from upstream practices we disagree with is important. Absolutely - I think it depends on the upstreams we've each experienced over time. I have been part of or become the entirety of upstream in nearly all the packages which I've packaged for Debian and it has always been friendly. Never a need for a fork, I started to contribute and shortly afterwards got asked to take over upstream... So I tend to have a more upstream approach than some other DD's, yet I haven't needed to fork anything - I just got handed it and told to go ahead! (It also means I rarely have anything in debian/patches...) > I also think that the freedom to "free," over time software even in > cases where upstream has a non-free source control system, or where > we're having to build up a new form of source code because of > restrictions on what's currently the source code are important. > > I do not agree that being an upstream is a field of endeavour. > > I do not agree that we must always use the same source code form that > upstream does. Sometimes upstream is wrong. Sometimes there are > multiple upstreams. > Sometimes we want to fork. Sometimes we do, yes, and we need to retain that ability. However, that is actually rare. More often, we are interacting with upstream or supporting users who want to contribute to upstream themselves. > We do however need to ship the source code we use whatever that is. > It needs to really be source code. It needs to be a reasonable form > in which we would choose to make modifications. If there are other > plausible source forms that are being used (even if some of them are > non-free), and those source forms would make the modifications easier, > that's a strong argument that the software is probably not free as we > propose to ship it. > > I do not wish us to make the upstream form of source so special that > we in our best judgment cannot override it. OK, I didn't mean that we cannot diverge from upstream ever, just that the majority of the time we are trying to work with upstream rather than reaching immediately for a fork. Our decisions should make this collaboration easy, without denying the possibility of the rather blunt instrument of forking the package. Part of this collaboration may involve educating upstream about the problems of distributing their code. This can include source code freedom issues, it can include software architecture (lack of stable APIs preventing a large codebase with plugins being separated out) and it can include portability issues with assumptions in their code which don't work on all our architectures. Fixing these things requires a positive attitude to upstream with few structural barriers. > I do hear your worry that you want to be able to exchange > modifications with upstream. Without modifications, without free > flow of those modifications, software is not free. I ask that we > have the flexibility to reject people who aren't actually shipping > source they would use to modify software while accepting people who > legitimately disagree about what the source form is. Agreed. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpUsrQwI7i5v.pgp Description: OpenPGP digital signature
Re: Bug#830978: Browserified javascript and DFSG 2
ly accepted way. In this case, > would some comfortable with javascript modify the code? If they are > able to modify the split files, they will be able to modify the > browserified files as well without any extra complexity. > > As for patches from upstream, the effort is similar to backporting. > Same for sending patches upstream, effort is similar to rebasing. Where do you get this crazy and fanciful notion that upstream are somehow second-class community members? Upstream are users of the software and all users must be free to choose how to use the freedoms assigned by the DFSG, including to interact with upstream if they choose to do so. There is no division - upstream is a subset of the users of the software. Any freedom granted to a user is given to upstream as well. This is not just about one subset of users - it is about all users, within Debian, upstream of Debian and downstream of Debian. Debian and the DFSG must serve them all equally or it is not worth having. A stream that blocks the flow back to the source will not flow for long. Working on the upstream of a package is just a field of endeavour in terms of the source code and the DFSG. As such, working with or as upstream is fully covered by the DFSG. No package is allowed to penalise users merely due to their particular field of endeavour. So, by your own argument, upstream - as users of the software - are part of the choice of what is the generally accepted way of exercising freedoms given to all users by the DFSG. As such, if upstream have a preference for a format, then that needs to be respected as the accepted way of handling that data in that package. The DFSG does not allow packages to discriminate between upstream and other users. Where one format can be modified by every user and another format can only be modified by some users, then the format which can be modified by everyone *must* be the accepted format or the package fails DFSG. When the second format is actually generated from the first format and cannot exactly regenerate the first from the second, it is obvious that the second format is not the source code in terms of the DFSG as changes to the second would be lost when the first is updated and the second gets regenerated. > > * There may be exceptions to this principle but none of them apply > > in the case of libjs-handlebars. We do not expect that any such > > exception would be applicable to other concatenated or > > `browserified' JavaScript files generated with tools like Grunt, > > even if the JavaScript output is not minified or obfuscated. > > Any JavaScript source that is not obfuscated or minified should be > considered source. Concatenation / browserification is a form of obfuscation for the benefit of another program, not to make it easier for a human to modify. Therefore the question is resolved - the generated form is not source code. It makes absolutely no sense to have two formats of the one source and as one is blatantly generated from the other and cannot be reverse engineered back to the original, then the generated form is not source code. > > * So in the case of bug #817092 against libjs-handlebars, the > > concatened JavaScript is not, in our opinion, source code. This > > would remain true even if the parser-generator input mentioned in > > bug #830986 were available. > > It should be considered dfsg-free. It is not, by your own argument. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgphuuSVYVtNe.pgp Description: OpenPGP digital signature
Re: Bug#782344: unblock: python-django/1.8-1
On Mon, 20 Apr 2015 15:15:22 +0200 Vladimir Macek ma...@sandbox.cz wrote: Hi, I'm an avid user of both Debian and Django. I'd like to say thanks Luke for trying to get the 1.8 LTS to the new stable Debian. It would certainly be awesome for many Django-based apps to not require it's own copy of Django in their environments. And 1.8 looks like an exceptionally well-baked release. From what I see it's unfortunately not the case and we'll stick to 1.7.7. When 1.8 isn't even in experimental so that packages using django can even test with the new major release, it is not a good idea to cause the possible removal of reverse dependencies or trigger bugs in reverse dependencies. Those reverse dependencies have not had time to get any changes for django1.8 into testing. This would be particularly difficult when those upstreams are also trying to retain support for 1.6 in Trusty. Please do not unblock python-django - 1.8 can always go in via backports. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpeaeDAGX1Y2.pgp Description: OpenPGP digital signature
Bug#771166: (approval) unblock: emdebian-archive-keyring/2.0.4
+cUYmSYbHBNDtCTV8b14fNAoc3nsjblgZ+/+0zDvR9ZNv3cUBaCqJ1hlZqZbOWi1X +PTv2r2CRe2A6q9oGj54NmpSIO7EcH2yYcx0GTafY4ZDqZha3kmzLSq1gh2s5kph9 +NyB2pBu31pY3PDPKkxE6+ZAWb6oHZUaKOtr4aXnqLxYzSi6Wv3kS5xXS+ZbCv5lz +/KlTTIlLRm86wvwRnqGqjBGH4knyB+VKtxlR/T+aRQxCMSIICYzpfvM+O8a+hH9Z ++zMAAwYIAMFAqo9dmRfc7BPLhRxb9erSaEhxb05lwiDyzPP6B5hcK8t8S/L4k9Hw +OXoYfnR7/GqUjSj4dYZ5uLlTLOASMpv+5Yq4EmPhuqKWM7MAK0uQXVsxSktswNHE +Hb5c3H8VfQJvpUdelnJdSfqttKvz9Cm1rtPRKylIK/naQJlZ5XxuAcV+PDcWOHq6 +B2uV2aG5CGT2yVM9VjxIkMLBPGXxPjPIKKZky1TTdOdQdGvSyNOu4gd0o+4i07IZ +SXBsHarFPTKGoAZ+YsKRJ3ODAKeKnYXIQQf/OmmHdkKOfRkVDogZyKHVhSNVEOZ4 +NyZwbjXc8FtKGOUYvXcpjuxqzqRckteISQQYEQIACQUCRjVDKgIbDAAKCRC1t3IA +l7s7WNO0AJ0aws9mKLgL0CQKvAKs5UBmpgATXQCfdqJCUVSEsRcihgP8VfOpPeXm +0Vs= +=aGyf -END PGP PUBLIC KEY BLOCK- diff -Nru emdebian-archive-keyring-2.0.3/debian/changelog emdebian-archive-keyring-2.0.4/debian/changelog --- emdebian-archive-keyring-2.0.3/debian/changelog 2012-03-24 09:27:59.0 + +++ emdebian-archive-keyring-2.0.4/debian/changelog 2014-11-27 09:25:43.0 + @@ -1,3 +1,9 @@ +emdebian-archive-keyring (2.0.4) unstable; urgency=medium + + * Revoke 0x97BB3B58 and disable the keyring. + + -- Neil Williams codeh...@debian.org Thu, 27 Nov 2014 09:25:41 + + emdebian-archive-keyring (2.0.3) unstable; urgency=low * Use working directory as GNUPG homedir and clean up the diff -Nru emdebian-archive-keyring-2.0.3/debian/NEWS emdebian-archive-keyring-2.0.4/debian/NEWS --- emdebian-archive-keyring-2.0.3/debian/NEWS 1970-01-01 01:00:00.0 +0100 +++ emdebian-archive-keyring-2.0.4/debian/NEWS 2014-11-27 09:33:22.0 + @@ -0,0 +1,14 @@ +emdebian-archive-keyring (2.0.4) unstable; urgency=medium + + The only key in this keyring has been revoked due to a + possible compromise on the server which was due for + replacement. + . + Emdebian Grip is no longer being updated and the toolchain + repository has not been updated since before the compromise + as work is ongoing for multiarch-compliant toolchains in + Debian. + . + There is no replacement key for this keyring. + + -- Neil Williams codeh...@debian.org Thu, 27 Nov 2014 09:27:56 +
Bug#769780: (pre-approval for) unblock: vmdebootstrap/0.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I'd like to close two important bugs in vmdebootstrap and upload
to unstable to migrate these changes into jessie:
#767196 - downgrade dependency on grub2-common (used for grub2
support inside vm images) to a Recommends: to allow for users
who are running grub-legacy.
#767913 - one character change to the grub2 support to allow
a boot partition to be used in a VM image using grub2.
Both fixes would also be considered for an update to the existing
wheezy-backport, once migrated into jessie.
The current package limits users of grub-legacy to not be able
to use grub2 in VM images, so this needs to be expressed in the
manpage. So I'm proposing to make a new upstream release with the
patch from 767913 applied, the changes for 767196 made in debian/control
and updates to the grub2 section of the manpage made upstream.
If these changes are not likely to be approved, I'll work on a range
of the other bugs filed against vmdebootstrap and make a 0.5 upstream
tag and release to upload to experimental only. So the debdiff is
not complete at this stage but will contain:
diff --git a/debian/control b/debian/control
index 00518f3..6cb5338 100644
--- a/debian/control
+++ b/debian/control
@@ -17,10 +17,10 @@ Package: vmdebootstrap
Architecture: linux-any
Depends: debootstrap, qemu-utils,
extlinux [amd64 i386],
- grub2-common [!mips !s390x],
kpartx, parted,
python-cliapp, ${python:Depends}, ${misc:Depends}
-Recommends: squashfs-tools, qemu-system, qemu-user-static
+Recommends: grub2-common [!mips !s390x],
+ squashfs-tools, qemu-system, qemu-user-static
Description: Bootstrap Debian into a (virtual machine) disk image
vmdebootstrap is a wrapper around debootstrap to install Debian
into a disk image, which can be used with a virtual machine (such as KVM).
and the patch in the BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=0001-Make-grub-installation-work-even-with-a-boot-partiti.patch;att=1;bug=767913
(applied upstream)
+ changes in the manpage.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
arm64
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8)
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:
https://lists.debian.org/20141116120746.6884.82836.reportbug@sylvester.codehelp
Bug#769780: vmdebootstrap 0.5-1 uploaded to unstable
retitle 769780 unblock: vmdebootstrap/0.5-1
thanks
The final debdiff is attached, including the changes described in
earlier plus the full details of the manpage changes to add information
to a bootloaders section.
unblock vmdebootstrap/0.5-1
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
diffstat for vmdebootstrap-0.4 vmdebootstrap-0.5
debian/changelog | 10 ++
debian/control |4 ++--
vmdebootstrap |4 ++--
vmdebootstrap.8.in | 31 ---
4 files changed, 34 insertions(+), 15 deletions(-)
diff -Nru vmdebootstrap-0.4/debian/changelog vmdebootstrap-0.5/debian/changelog
--- vmdebootstrap-0.4/debian/changelog 2014-10-21 09:04:55.0 +0100
+++ vmdebootstrap-0.5/debian/changelog 2014-11-16 15:27:52.0 +
@@ -1,3 +1,13 @@
+vmdebootstrap (0.5-1) unstable; urgency=medium
+
+ * New upstream bug fix release for Jessie.
+ * Allow parted to reserve space for grub2 on disk when
+also using --bootsize option. (Closes: #767913)
+ * Move grub2-common to Recommends. (Closes: #767196)
+ * Add section on bootloaders to manpage.
+
+ -- Neil Williams codeh...@debian.org Sun, 16 Nov 2014 15:11:34 +
+
vmdebootstrap (0.4-3) unstable; urgency=medium
* Fix syntax for excluding grub2-common on mips and s390x
diff -Nru vmdebootstrap-0.4/debian/control vmdebootstrap-0.5/debian/control
--- vmdebootstrap-0.4/debian/control 2014-10-21 09:04:55.0 +0100
+++ vmdebootstrap-0.5/debian/control 2014-11-16 15:27:52.0 +
@@ -17,10 +17,10 @@
Architecture: linux-any
Depends: debootstrap, qemu-utils,
extlinux [amd64 i386],
- grub2-common [!mips !s390x],
kpartx, parted,
python-cliapp, ${python:Depends}, ${misc:Depends}
-Recommends: squashfs-tools, qemu-system, qemu-user-static
+Recommends: grub2-common [!mips !s390x],
+ squashfs-tools, qemu-system, qemu-user-static
Description: Bootstrap Debian into a (virtual machine) disk image
vmdebootstrap is a wrapper around debootstrap to install Debian
into a disk image, which can be used with a virtual machine (such as KVM).
diff -Nru vmdebootstrap-0.4/vmdebootstrap vmdebootstrap-0.5/vmdebootstrap
--- vmdebootstrap-0.4/vmdebootstrap 2014-10-18 19:35:19.0 +0100
+++ vmdebootstrap-0.5/vmdebootstrap 2014-11-16 15:10:24.0 +
@@ -27,7 +27,7 @@
import time
-__version__ = '0.4'
+__version__ = '0.5'
class VmDebootstrap(cliapp.Application):
@@ -245,7 +245,7 @@
if self.settings['bootsize'] and self.settings['bootsize'] is not '0%':
bootsize = str(self.settings['bootsize'] / (1024 * 1024))
self.runcmd(['parted', '-s', self.settings['image'],
- 'mkpart', 'primary', 'fat16', '0', bootsize])
+ 'mkpart', 'primary', 'fat16', '0%', bootsize])
else:
bootsize = '0%'
self.runcmd(['parted', '-s', self.settings['image'],
diff -Nru vmdebootstrap-0.4/vmdebootstrap.8.in vmdebootstrap-0.5/vmdebootstrap.8.in
--- vmdebootstrap-0.4/vmdebootstrap.8.in 2014-10-18 19:35:19.0 +0100
+++ vmdebootstrap-0.5/vmdebootstrap.8.in 2014-11-16 15:10:24.0 +
@@ -57,16 +57,30 @@
or
.BR qemu (1).
Configure the virtual machine to use the image you've created.
-Then start the virtual machine,
+Then start the virtual machine, (see
+.B EXAMPLES
+)
and log into it via its console to configure it.
-.PP
+The image has an empty root password and will not have networking
+configured by default. Set the root password before you configure
+networking.
+.SH BOOTLOADERS
Unless the \-\-no\-extlinux or \-\-grub options are specified, the
image will use
.BR extlinux (1)
as a boot loader.
-The image has an empty root password and will not have networking
-configured by default. Set the root password before you configure
-networking.
+.B bootsize
+is not recommended when using
+.B extlinux
+- use grub instead.
+Versions of grub2 in wheezy
+can fail to install in the VM, at which point vmdebootstrap will fall back to
+extlinux. It may still be possible to complete the installation of grub2 after
+booting the VM as the problem may be related to the need to use loopback
+devices during the grub-install operation. Details of the error will appear in the
+vmdebootstrap log file, if enabled with the \-\-log option. Note that
+.B grub-legacy
+is not supported.
.SH OPTIONS
.IP \-\-output=FILE
write output to FILE, instead of standard output
@@ -136,12 +150,7 @@
.IP \-\-grub
Disable extlinux installation and configure grub2 instead. grub2 will be added to
the list of packages to install. update-grub will be called once the debootstrap is
-complete and grub-install will be called in the image. Versions of grub2 in wheezy
-can fail to install in the VM, at which point vmdebootstrap will fall back to
-extlinux. It may still be possible to complete the installation of grub2 after
-booting the VM as the problem may be related to the need to use loopback
-devices
Bug#768459: unblock: lshw/02.17-1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package lshw
The version in unstable contains two RC bug fixes.
Closes: 740034 757689
Changes:
lshw (02.17-1.1) unstable; urgency=medium
.
* Non-maintainer upload.
* Disable the memory scanning for all architectures other
than i386 and x86_64. Patch from Leif Lindholm
unixsm...@gmail.com (Closes: #740034)
* Prevent segfault if system has FAT partition(s) Patch from
Alban Browaeys pra...@yahoo.com (Closes: #757689)
debdiff against version in testing is attached.
Thanks.
unblock lshw/02.17-1.1
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
arm64
Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
diffstat for lshw_02.17-1 lshw_02.17-1.1
debian/patches/fat-inspection.patch | 10 ++
debian/patches/smbios-noscan.patch | 178
lshw-02.17/debian/changelog | 11 ++
lshw-02.17/debian/patches/series|2
4 files changed, 201 insertions(+)
diff -u lshw-02.17/debian/changelog lshw-02.17/debian/changelog
--- lshw-02.17/debian/changelog
+++ lshw-02.17/debian/changelog
@@ -1,3 +1,14 @@
+lshw (02.17-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable the memory scanning for all architectures other
+than i386 and x86_64. Patch from Leif Lindholm
+unixsm...@gmail.com (Closes: #740034)
+ * Prevent segfault if system has FAT partition(s) Patch from
+Alban Browaeys pra...@yahoo.com (Closes: #757689)
+
+ -- Neil Williams codeh...@debian.org Thu, 06 Nov 2014 12:16:13 +
+
lshw (02.17-1) unstable; urgency=medium
[ Alex Henrie ]
diff -u lshw-02.17/debian/patches/series lshw-02.17/debian/patches/series
--- lshw-02.17/debian/patches/series
+++ lshw-02.17/debian/patches/series
@@ -12,0 +13,2 @@
+smbios-noscan.patch
+fat-inspection.patch
only in patch2:
unchanged:
--- lshw-02.17.orig/debian/patches/fat-inspection.patch
+++ lshw-02.17/debian/patches/fat-inspection.patch
@@ -0,0 +1,10 @@
+--- a/src/core/fat.cc
b/src/core/fat.cc
+@@ -81,6 +81,7 @@
+ uint8_t dummy2[164];
+ uint8_t pmagic[2];
+ } __attribute__((__packed__)) fat32;
++ char sector[512]; // to make sure the whole struct is at least 512 bytes long
+ } __attribute__((__packed__)) type;
+ } __attribute__((__packed__));
+
only in patch2:
unchanged:
--- lshw-02.17.orig/debian/patches/smbios-noscan.patch
+++ lshw-02.17/debian/patches/smbios-noscan.patch
@@ -0,0 +1,178 @@
+--- a/src/core/dmi.cc
b/src/core/dmi.cc
+@@ -1717,9 +1717,56 @@
+ }
+
+
+-long get_efi_systab_smbios()
++struct dmi_info {
++ u8 smmajver;
++ u8 smminver;
++ u16 dmimaj;
++ u16 dmimin;
++};
++
++
++static bool parse_dmi_header(u32 addr, int fd, hwNode n, struct dmi_info *dmi)
++{
++ unsigned char buf[20];
++ u32 mmoffset = 0;
++ void *mmp = NULL;
++
++ mmoffset = addr % getpagesize();
++ mmp = mmap(0, mmoffset + 0x20, PROT_READ, MAP_SHARED, fd, addr - mmoffset);
++ memset(buf, 0, sizeof(buf));
++ if (mmp != MAP_FAILED)
++ {
++memcpy(buf, (u8 *) mmp + mmoffset, sizeof(buf));
++munmap(mmp, mmoffset + 0x20);
++ }
++ if (mmp == MAP_FAILED)
++ {
++return false;
++ }
++ else if (memcmp(buf, _SM_, 4) == 0)
++ {
++// SMBIOS
++dmi-smmajver = buf[6];
++dmi-smminver = buf[7];
++ }
++ else if (dmi-smmajver (memcmp(buf, _DMI_, 5) == 0)
++checksum(buf, 0x0F))
++ {
++u16 num = buf[13] 8 | buf[12];
++u16 len = buf[7] 8 | buf[6];
++u32 base = buf[11] 24 | buf[10] 16 | buf[9] 8 | buf[8];
++dmi-dmimaj = buf[14] ? buf[14] 4 : dmi-smmajver;
++dmi-dmimin = buf[14] ? buf[14] 0x0F : dmi-smminver;
++dmi_table(fd, base, len, num, n, dmi-dmimaj, dmi-dmimin);
++ }
++
++ return true;
++}
++
++
++u32 get_efi_systab_smbios()
+ {
+- long result = 0;
++ u32 result = 0;
+ vector string sysvars;
+
+ if (loadfile(/sys/firmware/efi/systab, sysvars) || loadfile(/proc/efi/systab, sysvars))
+@@ -1731,7 +1778,8 @@
+
+ if ((variable[0] == SMBIOS) (variable.size() == 2))
+ {
+- sscanf(variable[1].c_str(), %lx, result);
++ sscanf(variable[1].c_str(), %x, result);
++ break;
+ }
+ }
+
+@@ -1741,20 +1789,11 @@
+
+ bool scan_dmi(hwNode n)
+ {
+- unsigned char buf[20];
+- int fd = open(/dev/mem,
+-O_RDONLY);
+- long fp = get_efi_systab_smbios();
+- u32 mmoffset = 0;
+- void *mmp = NULL;
+- bool efi = true;
+- u8 smmajver = 0, smminver = 0;
+- u16 dmimaj = 0, dmimin = 0;
++ int fd = open(/dev/mem, O_RDONLY);
++ u32 fp = get_efi_systab_smbios();
++ struct dmi_info dmi = {0, 0, 0, 0};
+ currentcpu = 0;
+-
+-#if defined(__arm__
Bug#768458: unblock: midori/0.4.3+dfsg-0.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package midori The version in unstable contains a single RC bug fix. Closes: 759959 Changes: midori (0.4.3+dfsg-0.2) unstable; urgency=medium . * Non-maintainer upload. * Drop debian/presubj.in as the webkit text browser GtkLauncher is no longer packaged. (Closes: #759959) debdiff against midori/0.4.3+dfsg-0.1 is attached. midori was removed from testing due to bug #759959, so please unblock so that jessie can have midori. unblock midori/0.4.3+dfsg-0.2 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf arm64 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash diffstat for midori-0.4.3+dfsg midori-0.4.3+dfsg changelog |8 midori.install |1 - presubj.in |7 --- rules | 14 -- 4 files changed, 8 insertions(+), 22 deletions(-) diff -Nru midori-0.4.3+dfsg/debian/changelog midori-0.4.3+dfsg/debian/changelog --- midori-0.4.3+dfsg/debian/changelog 2012-11-24 08:34:26.0 + +++ midori-0.4.3+dfsg/debian/changelog 2014-11-06 14:04:10.0 + @@ -1,3 +1,11 @@ +midori (0.4.3+dfsg-0.2) unstable; urgency=medium + + * Non-maintainer upload. + * Drop debian/presubj.in as the webkit text browser +GtkLauncher is no longer packaged. (Closes: #759959) + + -- Neil Williams codeh...@debian.org Thu, 06 Nov 2014 14:04:07 + + midori (0.4.3+dfsg-0.1) unstable; urgency=low * Non-maintainer upload diff -Nru midori-0.4.3+dfsg/debian/midori.install midori-0.4.3+dfsg/debian/midori.install --- midori-0.4.3+dfsg/debian/midori.install 2011-12-18 13:47:40.0 + +++ midori-0.4.3+dfsg/debian/midori.install 2014-11-06 13:00:03.0 + @@ -1,2 +1 @@ debian/tmp/* -debian/presubj /usr/share/bug/midori/ diff -Nru midori-0.4.3+dfsg/debian/presubj.in midori-0.4.3+dfsg/debian/presubj.in --- midori-0.4.3+dfsg/debian/presubj.in 2011-12-18 13:47:40.0 + +++ midori-0.4.3+dfsg/debian/presubj.in 1970-01-01 01:00:00.0 +0100 @@ -1,7 +0,0 @@ -Sometimes a problem in Midori is caused by a bug in the rendering -engine, Webkit. Please take a moment to try to reproduce bugs with -the Webkit test browser, %GTKLAUNCHER%. -If you are able to reproduce your bug in the Webkit test browser, -report the bug against %LIBWEBKIT_PKG% instead. You may also wish -to see if your bug has already been reported as a webkit bug: -http://bugs.debian.org/src:webkit diff -Nru midori-0.4.3+dfsg/debian/rules midori-0.4.3+dfsg/debian/rules --- midori-0.4.3+dfsg/debian/rules 2012-11-24 00:45:06.0 + +++ midori-0.4.3+dfsg/debian/rules 2014-11-06 12:59:10.0 + @@ -12,8 +12,6 @@ CMD=$(shell echo $@ | sed 's/override_//') -LIBWEBKIT_PKG=$(shell dpkg-query -p libwebkitgtk-dev | grep Depends | sed -r 's/.*(libwebkitgtk[^ ]+).*/\1/') -GTKLAUNCHER=$(shell dpkg-query -L $(LIBWEBKIT_PKG) | grep GtkLauncher) DISTRO=$(shell lsb_release -is) CONFIG_FILE=debian/config/$(DISTRO).h ifneq (0, $(shell test -e $(CONFIG_FILE); echo $$?)) @@ -40,18 +38,6 @@ WAF=WAFDIR=waf-modules ./waf-unpacked -debian/presubj: debian/presubj.in - @echo presubj parameters: - @echo Replacing %LIBWEBKIT_PKG% with $(LIBWEBKIT_PKG) - @echo Replacing %GTKLAUNCHER% with $(GTKLAUNCHER) - test -f /var/lib/dpkg/info/$(LIBWEBKIT_PKG).list - test -f $(GTKLAUNCHER) - test -n $(GTKLAUNCHER) - sed -e s,%LIBWEBKIT_PKG%,$(LIBWEBKIT_PKG),g -e s,%GTKLAUNCHER%,$(GTKLAUNCHER),g $@.in $@ - -override_dh_install: debian/presubj - $(CMD) --fail-missing - override_dh_auto_clean: $(WAF) --nocache distclean rm -rf _build_
Bug#764694: release.debian.org: please whitelist lava-server and django-openid-auth from testing auto-removal
Package: release.debian.org Severity: normal The RC bug chain affecting lava-server has now been fixed but the current autoremoval from testing is scheduled for 2014-10-17 which is earlier than the fixes will migrate into testing. Please can lava-server and django-openid-auth be whitelisted from the testing auto-removals so that libmatheval, django-openid-auth and lava-server can all migrate their relevant RC bug fixes into testing without interrupting the installability of lava-server itself in testing. libmatheval has been scheduled for 2014-11-09 so does not need to be whitelisted. This will also prevent the autoremoval of uwsgi. Alternatively, a rescheduling of the auto-removal of lava-server and django-openid-auth to a date after the expected migration into testing would work too. Thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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: https://lists.debian.org/20141010095528.8311.90596.reportbug@sylvester.codehelp
Re: Please avoid upgrading to django1.7 before Jessie
Control: tags -1 - patch
On Mon, 4 Aug 2014 14:52:07 +0200
Raphael Hertzog hert...@debian.org wrote:
Control: tags -1 patch
Hello Neil,
On Sun, 03 Aug 2014, Neil Williams wrote:
I've now been able to test django-restricted-resource against
django1.7 and what I thought should be a simple test has shown
significant issues.
The changes in django1.7 cause breakage in the
django-restricted-resource testsuite and there will be insufficient
time to fix the test suite (and likely the packages which depend on
django-restricted-resource) ahead of the Jessie freeze.
Really?
I looked into your package. It needs a 3 line patch for the testsuite:
Fixing the testsuite is only one part of it. Checking that the actual
module works with reverse dependencies is where I expect to need the
time. Thanks for the tip though, it does help me start on the package
itself.
A patch which only affects the testsuite isn't going to help packages
using the module.
This also doesn't help django-testscenarios which leads me to think
that this patch is actually against the wrong package (as
django-testscenarios fails the same way and django-restricted-resource
pulls in django-testscenarios).
$ git diff
diff --git a/django_restricted_resource/tests.py
b/django_restricted_resource/tests.py index 8dd1d91..5619eb0 100644
--- a/django_restricted_resource/tests.py
+++ b/django_restricted_resource/tests.py
@@ -34,6 +34,10 @@ from django_restricted_resource.test_utils import (
from django_restricted_resource.models import RestrictedResource
+import django
+if hasattr(django, 'setup'):
+django.setup()
+
class ResourceCleanTests(FixtureHelper, TestCase):
And now:
$ ./setup.py test
Ran 172 tests in 1.737s
OK
Destroying test database for alias 'default' (':memory:')...
Please do not upload django1.7 to unstable at this time.
Please do not pretend you have done a serious investigation when you
haven't.
I am now very short of time for a serious investigation before October.
The issues with django-testscenarios and django-restricted-resource
also block any fixes for lava-server.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
Please avoid upgrading to django1.7 before Jessie
I've now been able to test django-restricted-resource against django1.7 and what I thought should be a simple test has shown significant issues. The changes in django1.7 cause breakage in the django-restricted-resource testsuite and there will be insufficient time to fix the test suite (and likely the packages which depend on django-restricted-resource) ahead of the Jessie freeze. As Django1.7 has not been released upstream, it is premature to force a migration unnecessarily. IMHO there is no good reason to migrate to a django pre-release at this time and insufficient time after the django release to migrate the reverse dependencies. Please do not upload django1.7 to unstable at this time. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: [PKG-Openstack-devel] Bug#755651: horizon: Please ensure it works with Django 1.7
On Tue, 22 Jul 2014 23:51:27 +0800 Thomas Goirand z...@debian.org wrote: We intend to upload Django 1.7 to unstable as soon as it is available because we really want the latest version in jessie and the freeze is approaching fast. In preparation of that, I have uploaded a release candidate in experimental. I'm looking at the same bugs for lava-server, lava-dispatcher and a couple of other packages. So far, it doesn't look like it is a major issue, yet. If the current package works fine, please close this bug (or retitle it as a suggestion to implement Python 3 support and drop its severity to wishlist[1]). Python3 support is a much bigger issue and out of scope for release discussions. No, Horizon 2014.1 is *not* compatible with Django 1.7, and it will *never* be compatible with it. Thomas - that sounds implausible. I've just done a migration from django1.2 all the way up to 1.6. It was not a major issue and lava is really *not* a small package. Also, having OpenStack Juno released only on the 16th of October makes it very tight to have it to reach Jessie before the freeze in a reasonable shape. I do not wish to attempt this, and I am sure that the release team will agree with me. I'm open to this, dependent on exactly how the porting goes. I'll know more in the next few days. While I salute your effort to bring the latest version of Django to Jessie, I am afraid that I have to oppose to it. This is *already too late* to make it to Jessie, especially considering that we had lots of changes to deal with Django 1.6, and if history repeats, that's really too many reverse dependencies to fix. Release team: could you as well voice your opinion on this? Would you agree that it's too late already? Release team: Just as a side-note, this decision affects more than just openstack and I'm willing to reserve judgement on django1.7 until we've done a bit more work on it. However, I agree that time is short if work is required to migrate to 1.7 as lava upstream has other major work ongoing between now and the end of the year - although that work won't be done before the freeze, it nevertheless takes up time which might be needed for a 1.7 fix, if any. Raphael: please expand on why you want 1.7 in Jessie other than it's newest so must be best. I'm perfectly happy to have django1.7 and later available from backports. Which specific *features* in django1.7 are to be considered as justifying the upload to unstable, bearing in mind the reverse dependencies. From the django release notes, there isn't a whole lot of got to have stuff in 1.7. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: qiime REMOVED from testing
On Wed, 22 Jan 2014 08:26:56 +0100 (CET) Steffen Möller steffen_moel...@gmx.de wrote: The problem with the qiime removal imho is less the extra work that you ask for, but the message sent to our users of testing that they cannot rely on us - I know it says testing, but this is exactly what they should be allowed to do reliably. 0: The bug has been open for some time - if there is that much demand, then someone needs to fix the bug. 1: The package is only removed from the repository, not installed systems. The removal only affects new installs. Stop whining and fix the bug already! Researchers using qiime use the latest version since the scientific field (identify the relative abundance of microbiota) develops so quickly. If the package was developing so quickly, why was the package allowed to get sufficiently stale that the bug wasn't fixed? All the bug needed was a new version of the package. The individuals who decided for qiime on Debian (not the upstream-provided binary distribution) find testing a natural environment. They are on the latest scientifically and run on the latest technically. This goes together. Until technical bugs in the software force someone else to do the work instead, i.e. the auto-removal from testing process. Now, when you retract packages for no scientific reason or for a technical reason that would affect them, then they will look to Debian with big eyes asking why did you do this to us? Because the people entrusted with looking after the package in Debian - the maintainers - did not fix the bug. The technical reason does affect them - it blocks updates of other packages, some of which may contain much needed updates. I know, the problem is old. And you may not have any immediate answer that would make me happy. Just kindly think about it anyway. The general process has been thought about long and hard, many, many times and this is the correct solution. If the maintainers cannot find time to fix the bug properly, it is up to Debian to get this package out of the way so that other packages which follow the rules can update correctly. Blocking supported packages with abandonware is a sufficiently important problem that automated removal of packages is entirely warranted. Fix the bug and the entire problem goes away! -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Bits from the release team (freeze time line)
On Fri, 27 Dec 2013 12:53:32 +0100 Peter Palfrader wea...@debian.org wrote: Arm* is a slightly smaller issue because we have no way to remotely power cycle the machines Linaro may be able to help here. We've developed software to allow remote interaction with a selection of APC PDU units and this is routinely used in LAVA when boards fail to soft reboot within a timeout, leading to a fully automated power cycle with configurable delays. It would need the purchase of a suitable APC unit (older models work, support up to 8 boards and can cost £30-50 each, newer 0U rack based PDUs are supported as well) and changes in the lab to connect the power supply to each board into the PDU instead of directly into the mains. The software is designed for use only inside trusted networks and has no authentication support, so it would need to run behind SSH or some other authentication layer. https://git.linaro.org/people/matthew.hart/lavapdu.git I've done some rudimentary packaging but it's alpha software currently, although in routine production use with LAVA. https://git.linaro.org/people/neil.williams/lavapdu.git The software is intended to be extensible to other APC units as the control interface menus have a common structure, but small tweaks may be needed for some units. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: libotr 4.0.0 hasn't entered testing after 55 days
On Sat, 6 Jul 2013 17:30:49 +0200 Thibaut VARENE vare...@debian.org wrote: The two libotr2* are gone, as part of the migration. So all is left to wait for the 3 packages you already mentioned, and as I said, that means that if, for some reason, they're never updated, libotr will never migrate, i.e. slow pokes penalize good citizens. That seems backwards. Seriously so. There's no penalisation here. It is part of the maintenance burden of a library with reverse dependencies. Those reverse dependencies become part of the workflow of the library package. Transitions in the library must be coordinated with the reverse dependencies, otherwise those packages become uninstallable in testing. The release team are charged with stopping that happening - library maintainers need to help. This is all basic to maintaining a library in Debian. It is why we have transitions and it is the biggest part of how maintainers assist the release team in actually getting a release delivered. If you care about libfoo in the next release, coordinate SONAME bumps with *all* reverse dependencies, every time - or orphan the library and let someone else do the work. Those who choose to maintain shared library packages bear an extra burden - the burden of transitions is *not* optional. If people are complaining to the library maintainer then that is correct. It is up to the maintainer of the library to work with the maintainer (s) of all reverse dependencies *and* the release team to get the transition completed. Some packages may get removed but that is still a fix for the transition - however it is done, all reverse deps must be fixed and the library maintainer is the main point of coordination as it was the library which caused the need for a transition by changing the SONAME. The other way to do this is to introduce a NEW source package and wait for reverse dependencies to migrate to the new API individually, e.g. libgtk2 vs libgtk3 etc. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpsuMZBiw9Wr.pgp Description: PGP signature
Re: updates to testing
On Thu, 31 Jan 2013 18:10:45 +0100 Mathieu Malaterre ma...@debian.org wrote: Dear release team, As per §5.13.3. Direct updates to testing, I'd like to ask permission for direct upload to testing for package gdcm. You mean testing-proposed-updates. In order to fix #699379, I would need to upload 2.2.0-14, by-passing the current 2.2.1-1 sitting in unstable. This is more likely to catch the attention of the team if you file it as a bug against release.debian.org, asking for permission for a t-p-u upload. That bug report needs to be accompanied by a full debdiff between the t-p-u build and the current version of the package in testing. Each change in that debdiff needs to be described in the t-p-u changelog. HTH -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpCIsR5OQwiP.pgp Description: PGP signature
Bug#690411: unblock: scim-chewing/0.3.4-1.2
On Tue, 22 Jan 2013 14:39:15 + Jonathan Wiltshire j...@debian.org wrote: On 2013-01-19 18:11, Jonathan Wiltshire wrote: On Sun, Oct 14, 2012 at 12:43:24AM +0100, Neil Williams wrote: I've prepared an NMU (diff attached) for testing-proposed-updates as 0.3.4-1.2 which simply pulls the gtk patch out of the unstable changes and makes no other changes. Please confirm that this is OK to upload to t-p-u. Please go ahead. Uploaded. http://packages.qa.debian.org/s/scim-chewing/news/20130126T144844Z.html Architecture: source i386 Version: 0.3.4-1.2 Distribution: testing-proposed-updates Urgency: low Maintainer: Andrew Lee (李健秋) ajq...@debian.org Changed-By: Neil Williams codeh...@debian.org Description: scim-chewing - Chewing IM engine module for SCIM Closes: 684854 Changes: scim-chewing (0.3.4-1.2) testing-proposed-updates; urgency=low . * Non-maintainer upload. * Apply gtk.patch from unstable upload without extraneous changes. Fixes FTBFS: scim_color_button.cpp (Closes: #684854). Thanks Tz-Huan Huang tzh...@gmail.com from upstream. unblock scim-chewing/0.3.4-1.2 -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpt1MGahw_9L.pgp Description: PGP signature
Re: Please wheezy-ignore #695716
On Thu, 17 Jan 2013 19:51:13 + Robert Lemmen rober...@semistable.com wrote: #695716 is a GFDL-bug, upstream has relicensed their docs and released a new version 0.6.7, I have updated the package and uploaded to unstable. ... which won't get into testing. unfortunately, the new version also contains other changes, so I don't think 0.6.7 can progress to testing. Why couldn't an upload of cgdb 0.6.6-3 have been made with only the changes to the docs licensing? I was hoping we could wheezy-ignore this bug, as it essentially now is a false positive: Not in testing. everyone has a dfsg-free license to the docs contents by means of the new package or the upstream webpage, and a fixed version is in the archive. Users should not have to upgrade stable to new testing (Jessie) to fix RC bugs which could have been fixed in stable. Nor should users be expected to inspect details of the package in versions outside stable to make decisions on the licensing of packages in stable. (Otherwise, we'd keep all the copyright files on a server somewhere and save many Gb of archive space.) If Debian allowed bugs fixed in unstable only to no longer be RC, we might already have released but users would have been no better off. the alternative is to split 0.6.6 into two packages, which is a bit messy considering that it is only for one version... Would have been easier if you'd not uploaded 0.6.7 and then filed an unblock request bug at release.debian.org to allow an upload of 0.6.6-3 to be unblocked, then upload 0.6.7 sometime after 0.6.6-3 had been unblocked and migrated. Now, the bug still isn't fixed in testing and an upload to testing-proposed-updates is going to be needed. Alternatively, cgdb could simply be removed from testing. Whatever happens, it will be a lot easier for the release team to decide on this is you file a bug against release.debian.org instead of this issue getting lost in the traffic from the mailing list. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpU9RAht2HnQ.pgp Description: PGP signature
Bug#693351: RM: kismet/2008-05-R1-4.3
On Wed, 12 Dec 2012 04:18:18 +0100 Nick Andrik nick.and...@gmail.com wrote: First of all I also CC the DD that follows my work on packaging the new version, since I am not an expert on all debian procedures yet. About removing kismet or not, I don't know what are the arguments for and against. I need to know the exact implications in order to give an informed answer. If we include it, what is the disadvantage? The Debian package is not available for new installations. It doesn't show up in apt-cache searches. The advantage is that the poor quality of the package no longer reflects badly on Debian - as it does currently. It is not installed by default anyway, and I don't expect anyone to be using the version shipped with debian. So remove it already. The upstream also provides a .deb which works quite well and my estimation is that everybody uses that one. This means, I don't think anyone will file any new bugs, functionality wise. It also means that there's no loss by removing it. If we remove the package, do we also lose all the bugs filed against it? No. Bugs which only apply to the version(s) in testing or unstable will be closed by the removal, bugs found in versions in oldstable and stable will remain open. (oldstable until the next stable freeze starts). Packages are not removed from stable or oldstable. Bugs are never deleted (except spam ones) - the bug will be closed and archived but it can always be unarchived and reopened (in that order). Some of them are still valid issues which will be addressed in the new package. If the package is reintroduced, the old bugs will be available to be re-opened and tested with the new version. The bug numbers remain the same and because there is a version of the package in stable, the index page for the package will remain too. It is trivial to switch that page to looking at archived bugs instead of the default unarchived. For the functionality bugs, I plan to give a notice to try the new package once it is released and close the ones I get no answer after some period (e.g. 1-2 months) Does that mean you will be adopting kismet as maintainer after the Wheezy release? Also, I think the procedures for uploading new/heavily updated packages is different. During a release freeze, yes - major changes and new packages should be uploaded to experimental only. Outside the freeze, major changes and new packages can go to either experimental or unstable. One should pass through the new queue, the other through experimental. No. A package which has been removed will always go back through NEW if it is reintroduced. After going through the NEW queue, it can go into either experimental or unstable. If the package has not been removed, a new upload won't go through NEW whether it's aimed at experimental or unstable. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpjYa2hGRc9I.pgp Description: PGP signature
Bug#695373: unblock: catdoc/0.94.4-1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package catdoc
This version is an RC bug fix (#692076).
debdiff to the version in testing is attached. The majority of the
patch is the fix for #692073 to remove the .pc subdirectory inadvertently
introduced in the last upstream release and which prevented a sane
fix for the RC bug fix.
Thanks.
unblock catdoc/0.94.4-1.1
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armel
i386
armhf
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
diffstat for catdoc-0.94.3 catdoc-0.94.4
.pc/.quilt_patches |1
.pc/.quilt_series |1
.pc/.version|1
.pc/applied-patches |1
.pc/debian-changes-0.94.3-1/doc/catdoc.txt | 258
.pc/debian-changes-0.94.3-1/doc/catppt.txt | 51 -
.pc/debian-changes-0.94.3-1/doc/xls2csv.txt | 85 -
configure |2
configure.in|2
debian/changelog| 12 +
doc/catdoc.1|2
doc/catppt.1|2
doc/wordview.1 |2
doc/xls2csv.1 |2
src/xlsparse.c |4
tarball.sh | 18 +
16 files changed, 34 insertions(+), 410 deletions(-)
diff -Nru catdoc-0.94.3/configure catdoc-0.94.4/configure
--- catdoc-0.94.3/configure 2012-06-10 14:02:08.0 +0100
+++ catdoc-0.94.4/configure 2012-12-03 18:01:26.0 +
@@ -541,7 +541,7 @@
fi
-catdoc_version=0.94.2
+catdoc_version=0.94.4
# Extract the first word of gcc, so it can be a program name with args.
set dummy gcc; ac_word=$2
echo $ac_n checking for $ac_word... $ac_c 16
diff -Nru catdoc-0.94.3/configure.in catdoc-0.94.4/configure.in
--- catdoc-0.94.3/configure.in 2012-06-10 12:35:25.0 +0100
+++ catdoc-0.94.4/configure.in 2012-12-03 18:01:31.0 +
@@ -1,6 +1,6 @@
dnl Process this file with autoconf to produce a configure script.
AC_INIT(acconfig.h)
-catdoc_version=0.94.2
+catdoc_version=0.94.4
dnl Checks for programs.
AC_PROG_CC
case ${CC} in
diff -Nru catdoc-0.94.3/debian/changelog catdoc-0.94.4/debian/changelog
--- catdoc-0.94.3/debian/changelog 2012-06-10 13:51:32.0 +0100
+++ catdoc-0.94.4/debian/changelog 2012-12-03 18:50:42.0 +
@@ -1,3 +1,15 @@
+catdoc (0.94.4-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * New upstream release to remove .pc subdirectory from
+the orig tarball (Closes: #692073). Includes updating
+version strings in generated manpages.
+ * Remove extra ';' in src/xlsparse.c which turned for loop in
+xlsparse into a buffer overflow (Closes: #692076), applies
+patch by Olly Betts o...@survex.com.
+
+ -- Neil Williams codeh...@debian.org Mon, 03 Dec 2012 18:22:47 +
+
catdoc (0.94.3-1) unstable; urgency=low
* Declare new upstream release
diff -Nru catdoc-0.94.3/doc/catdoc.1 catdoc-0.94.4/doc/catdoc.1
--- catdoc-0.94.3/doc/catdoc.1 2012-06-10 14:04:16.0 +0100
+++ catdoc-0.94.4/doc/catdoc.1 2012-12-03 18:54:22.0 +
@@ -1,4 +1,4 @@
-.TH catdoc 1 Version 0.94.2 MS-Word reader
+.TH catdoc 1 Version 0.94.4 MS-Word reader
.SH NAME
catdoc \- reads MS-Word file and puts its content as plain text on standard output
.SH SYNOPSIS
diff -Nru catdoc-0.94.3/doc/catppt.1 catdoc-0.94.4/doc/catppt.1
--- catdoc-0.94.3/doc/catppt.1 2012-06-10 14:04:16.0 +0100
+++ catdoc-0.94.4/doc/catppt.1 2012-12-03 18:54:22.0 +
@@ -1,4 +1,4 @@
-.TH ppt2text 1 Version 0.94.2 MS-PowerPoint reader
+.TH ppt2text 1 Version 0.94.4 MS-PowerPoint reader
.SH NAME
catppt \- reads MS-PowerPoint file and puts its content on standard output
.SH SYNOPSIS
diff -Nru catdoc-0.94.3/doc/wordview.1 catdoc-0.94.4/doc/wordview.1
--- catdoc-0.94.3/doc/wordview.1 2012-06-10 14:04:16.0 +0100
+++ catdoc-0.94.4/doc/wordview.1 2012-12-03 18:54:22.0 +
@@ -1,4 +1,4 @@
-.TH wordview 1 Version 0.94.2 MS-Word reader
+.TH wordview 1 Version 0.94.4 MS-Word reader
.SH NAME
wordview \- displays text contained in MS-Word file in X window
diff -Nru catdoc-0.94.3/doc/xls2csv.1 catdoc-0.94.4/doc/xls2csv.1
--- catdoc-0.94.3/doc/xls2csv.1 2012-06-10 14:04:16.0 +0100
+++ catdoc-0.94.4/doc/xls2csv.1 2012-12-03 18:54:22.0 +
@@ -1,4 +1,4 @@
-.TH xls2csv 1 Version 0.94.2 MS-Word reader
+.TH xls2csv 1 Version 0.94.4 MS-Word reader
.SH NAME
xls2csv \- reads
Re: Please unblock libcitadel
On Tue, 27 Nov 2012 12:33:42 +0100 Michael Meskes mes...@debian.org wrote: Hi, please unblock libcitadel that was just uploaded. A bug report would be better than a post to the mailing list. Follow the template from `reportbug release.debian.org` It fixes a missing zero termination to a string. There's no bug report mentioned in the changelog entry and no bugs reported in the BTS for the package. Why should this change go into Wheezy? What are the implications? Has it affected users or is this just theoretical? The other changes in the diff are merely cosmetical: adding quilt to apply the patch and replace configure.in with upstream's Changing the build system is not a cosmetic change. This is a dpkg-source format 1.0 package - adding quilt is a major change to how the package builds. version, ours had a test listed twice. Full debdiff attached. ... which includes changes made without using the patch system you added later in the diff... presumably because that change was made without using a patch system. Again, no bug report for this change, no indication of why it needs to be done in Wheezy. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpQ3IkfNiSRo.pgp Description: PGP signature
Pre-approval request for catdoc
I've messed up catdoc and now there are two bugs which need to be fixed. RealLife has been more than a bit chaotic recently and I hadn't noticed the severity of #692076, giving Nick the wrong advice. When preparing 0.94.3 upstream, we caused #692073 as well which makes fixing any bug in catdoc all but impossible. Bad combination. Nick I are the upstream for catdoc but we ran out of time to sanitise the upstream build system for 0.94.3, leading to a broken build and a hack which has now caused the .pc directory to be retained inside the .orig which breaks dpkg-source format 3.0 (quilt) such that dpkg-source --commit now fails to work if any patches are added to the package. #692073 therefore makes catdoc all but impossible to NMU - it makes it all but impossible for me to rebuild 0.94.3. I'm considering raising the severity (probably serious as the catdoc build system in the current version in Debian is not particularly sane). The best fix would be a new .orig - there are no patches in the current debian package and the patch for #692076 could be integrated upstream as the only change from 0.94.3.orig.tar.gz and 0.94.4.orig.tar.gz. That and the removal of the .pc directory would be the only upstream change between 0.94.3 and 0.94.4. After Wheezy, we'll switch the catdoc build to probably cmake and do a backport including some other interim fixes. Is this appropriate as an RC bug fix? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpeEzpi9DGTr.pgp Description: PGP signature
Bug#692327: libotr: Please provide libotr2
On Tue, 6 Nov 2012 10:59:42 +0100 Thibaut VARENE vare...@debian.org wrote: On Tue, Nov 6, 2012 at 10:48 AM, Philipp Kern pk...@debian.org wrote: On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote: I thought that Wheezy having been frozen for quite some time, it was okay to upload new packages to unstable again. I'm sure we would've communicated that on d-d-a if this would've been the case. Okay then. Wheezy has been frozen for 4 months already. Out of curiosity, how long will we have to wait before new software can be pushed again to Debian? If it's targeting experimental, that is already possible and has never been a problem. If it's to target unstable then expect an announcement on d-d-a to the effect that unstable is now open again a few days after the Wheezy release. (Release, not freeze). i.e. around the time that Jessie becomes available as the new testing. Note that from past experience, it's not advisable to upload very soon after the d-d-a announcement anyway. So many other packages get uploaded at that point that many dependencies become uninstallable. Talk to maintainers of packages which your package needs and co-ordinate in advance. If you want it in Debian now, push it into experimental. If you want it Jessie (the next testing), then wait for the d-d-a announcement. If you wanted it in Wheezy it's too late. If you just wanted it in unstable then it's clear that this is not desirable and your only option is experimental. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpitnjZIDhex.pgp Description: PGP signature
Bug#692327: libotr: Please provide libotr2
On Tue, 6 Nov 2012 14:17:05 +0100 Thibaut VARENE vare...@debian.org wrote: On Tue, Nov 6, 2012 at 1:04 PM, Neil Williams codeh...@debian.org wrote: On Tue, 6 Nov 2012 10:59:42 +0100 Thibaut VARENE vare...@debian.org wrote: If you want it in Debian now, push it into experimental. If you want it Jessie (the next testing), then wait for the d-d-a announcement. If you wanted it in Wheezy it's too late. If you just wanted it in unstable then it's clear that this is not desirable and your only option is experimental. Noted. The package was in experimental for several weeks and got zero attention. Hopefully because people are working on the release so that uploads to unstable can be opened again. The quicker we release Wheezy, the quicker this and other packages get into unstable. It's much better to work on RC bugs than to worry about a migration which can't really start until after the freeze. My general understanding is that nobody looks at experimental anyway. Those who do work other than on RC bugs during a release freeze will use experimental. It's where all the updates happen which are not intended for inclusion into the currently frozen testing. Another part of the issue was upstream's will to have it in Ubuntu as soon as possible. Ubuntu autosync doesn't fetch from experimental. Co-ordinate that with Ubuntu - the version of a package in Ubuntu does not affect how Debian makes a stable release. Whilst the wishes of upstream can be met outside of a freeze, there must always be extra barriers to package updates during a freeze or it wouldn't be a freeze. The will of upstream typically becomes a wishlist bug in Debian and wishes can't be met during a freeze, generally. Having a freeze simply means that some package changes *must* be delayed until after the freeze. Experimental works for some, if it doesn't work for you then you cannot update the package in Debian until the release, so maybe help get the release out. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpu7iE8IGeIq.pgp Description: PGP signature
Re: Fixing the Catalyst development environment in Wheezy
On Tue, 28 Aug 2012 21:07:24 +0200 intrigeri intrig...@debian.org wrote: the Catalyst development environment is seriously broken and currently in Debian current testing/sid (to get and idea, see #683656, #680819, #680829, #680826, #665222). Agreed. We, Debian Perl Group, would like to fix that, and we have been working on it during DebCamp and DebConf accordingly. Sorry for the delay since then. Scope: three currently buggy packages are directly under the radar as far as freeze block/unblock decisions are concerned (libcatalystx-simplelogin-perl, libcatalyst-actionrole-acl-perl and libcatalyst-perl), and a few others are directly concerned due to being broken by the versions of libcatalyst-perl currently in testing and unstable. The diffs supplied originally in August are likely to be too large to be acceptable as unblocks and I've been wondering about an alternative solution for Wheezy. An alternative solution would be: 0: RM libcatalystx-simplelogin-perl libcatalystx-simplelogin-perl | 0.15-1 | source, all Checking reverse dependencies... No dependency problem found. Removal of libcatalystx-simplelogin-perl possible. Closes: #680829 (Severity: serious) 1: RM libcatalyst-actionrole-acl-perl libcatalyst-actionrole-acl-perl | 0.06-1 | source, all Checking reverse dependencies... # Broken Build-Depends: libcatalystx-simplelogin-perl: libcatalyst-actionrole-acl-perl Dependency problem found. Dependency problem goes away due to 0: Removal of libcatalyst-actionrole-acl-perl possible. Closes: #680819 (Severity: serious) 2: RM libcatalyst-view-component-subinclude-perl libcatalyst-view-component-subinclude-perl | 0.10-1 | source, all Checking reverse dependencies... # Broken Depends: gitalist: gitalist-common # Broken Build-Depends: gitalist: libcatalyst-view-component-subinclude-perl (= 0.07) Dependency problem found. gitalist: $ rmadison gitalist gitalist | 0.003006+dfsg-2 | sid | source $ bts select source:gitalist severity:grave severity:serious 681435 665223 Removal of libcatalyst-view-component-subinclude-perl possible. Closes: #680843 3: RM gitalist gitalist | 0.003006+dfsg-2 | source gitalist-common | 0.003006+dfsg-2 | all gitalist-fastcgi | 0.003006+dfsg-2 | all Checking reverse dependencies... No dependency problem found. Closes: #681435 Closes: #665223 Not in testing. Worth removing from unstable? - update libcatalystx-simplelogin-perl to 0.17 (compatibility bugfix -only release) Instead: RM - update libcatalyst-actionrole-acl-perl to 0.07 (compatibility bugfix -only release) Instead: RM + libcatalyst-view-component-subinclude-perl, possibly remove gitalist from unstable. I'll file the three RM bugs against release.debian.org (for removal from testing only) later today. I haven't decided whether it's worth removing gitalist at this stage. The one problematic bug is #680826 in libtest-www-mechanize-catalyst-perl libtest-www-mechanize-catalyst-perl | 0.57-1 | source, all Checking reverse dependencies... # Broken Depends: libcatalyst-modules-perl: libcatalyst-modules-perl # Broken Build-Depends: gitalist: libtest-www-mechanize-catalyst-perl libcatalyst-modules-perl: libtest-www-mechanize-catalyst-perl libcatalyst-plugin-unicode-encoding-perl: libtest-www-mechanize-catalyst-perl libmojomojo-perl: libtest-www-mechanize-catalyst-perl gitalist isn't a problem, libcatalyst-modules-perl and libmojomojo-perl are problems for fixing #680826. However, the original email to debian-release did not cover how that particular bug was to be fixed either. http://lists.debian.org/debian-release/2012/08/msg01479.html -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpboIuxC3cCc.pgp Description: PGP signature
Bug#690443: RM: libcatalystx-simplelogin-perl/0.15-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm As part of the fixes for the Catalyst development environment and to close RC bug #680829, I feel it is necessary to remove libcatalystx-simplelogin-perl from testing. libcatalystx-simplelogin-perl | 0.15-1 | source, all Checking reverse dependencies... No dependency problem found. The other parts of this fix relate to libcatalyst-actionrole-acl-perl and libcatalyst-view-component-subinclude-perl for which I am filing RM bugs as well. Full rationale: http://lists.debian.org/debian-release/2012/10/msg00677.html Please remove libcatalystx-simplelogin-perl from testing. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20121014122906.17649.1300.reportbug@sylvester.codehelp
Bug#690446: RM: libcatalyst-actionrole-acl-perl/0.06-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm As part of the fixes for the Catalyst development environment and to close RC bug #680819, I feel it is necessary to remove libcatalyst-actionrole-acl-perl from testing. libcatalyst-actionrole-acl-perl | 0.06-1 | source, all Checking reverse dependencies... # Broken Build-Depends: libcatalystx-simplelogin-perl: libcatalyst-actionrole-acl-perl Dependency problem found. I've also asked for removal of libcatalystx-simplelogin-perl in #690443, so this dependency problem goes away. The other parts of this fix relate to libcatalyst-view-component-subinclude-perl for which I am will be filing an RM bug as well. Full rationale: http://lists.debian.org/debian-release/2012/10/msg00677.html Please remove libcatalyst-actionrole-acl-perl from testing. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20121014123959.18219.4713.reportbug@sylvester.codehelp
Bug#690448: RM: libcatalyst-view-component-subinclude-perl/0.10-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm As part of the fixes for the Catalyst development environment and to close RC bug #680843, I feel it is necessary to remove libcatalyst-view-component-subinclude-perl from testing. libcatalyst-view-component-subinclude-perl | 0.10-1 | source, all Checking reverse dependencies... # Broken Depends: gitalist: gitalist-common # Broken Build-Depends: gitalist: libcatalyst-view-component-subinclude-perl (= 0.07) Dependency problem found. gitalist: $ rmadison gitalist gitalist | 0.003006+dfsg-2 | sid | source $ bts select source:gitalist severity:grave severity:serious 681435 665223 So removing libcatalyst-view-component-subinclude-perl from testing does not affect gitalist and there are no other dependency issues in testing. The other parts of this fix relate to libcatalyst-actionrole-acl-perl and libcatalystx-simplelogin-perl for which I have filed RM bugs as well. Full rationale: http://lists.debian.org/debian-release/2012/10/msg00677.html Please remove libcatalyst-view-component-subinclude-perl from testing. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20121014125131.18788.16766.reportbug@sylvester.codehelp
Bug#690457: RM: twidge/1.0.8.1+nmu1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm twidge needs to be migrated to a modified hoauth API but the RC bug #665254 has had no maintainer input since it was opened in March. (Maintainer is also upstream.) Please remove twidge from testing. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20121014143243.21077.39863.reportbug@sylvester.codehelp
Possible solutions for scim-anthy, scim-prime scim in Wheezy
I can't see any way for the release team to approve the unblock scim for the following reasons: 0: it's a new upstream release which is deemed a significant change 1: the packaging system has changed to compat 9, another significant change. 2: new binary packages have been introduced, a further significant change 3: there is no RC bug fixed in scim itself by this upload 4: the RC bug which does exist (#687401) is, in my estimation, artificial because there appears to be no functional reason for the change in the build-dependency other than to work with a -dev package which was converted to MultiArch unnecessarily. (There is no specification for how to manage -dev packages for MultiArch currently, only shared libraries and changing only the shared library would not have caused problems with the reverse dependencies.) scim-anthy *could* build against the version of scim already in testing if the special handling for the multiarch'd libscim-dev package was removed from debian/rules. So this upload doesn't fix the RC bug, it merely matches what the RC buggy package was instructed to expect in order to meet the changes in the scim package. I have gone through the debdiff between the version of scim in wheezy and the version in sid and I can't see how this meets the Wheezy Freeze Policy [0] either. It fails Rule #1 - there are no bug fixes directly within scim other than one RC bug introduced by the new upstream version itself (#679724). It fails Rule #5 with three different levels of significant changes. The new upstream release contains very large amounts of new code, adding support for libraries and systems not previously support by scim. A release freeze is *not* the time to test such large changes within Debian. I've checked through the one remaining option of using the versions in Squeeze too. I've tried to build the version of scim-anthy in Squeeze within Wheezy but it fails due to GTK3 issues (libscim-dev in Wheezy requires libgtk3-dev. This raises a separate issue that some reverse dependencies of libscim8c2a which is built from scim are linked against libgtk2.0-0 when libscim8c2a itself is linked against libgtk-3-0 - a situation which the Gtk maintainers warn will cause seg faults. This arises partially because libscim-dev Depends on both libgtk2.0-dev and libgtk-3-dev which itself is wrong.) One of the packages affected by this is scim-prime but although there is a fix in unstable, the NMU for scim-prime is *also* unsuitable for an unblock due to substantial changes to the package including 3.0 quilt, removal of dpatch and rewriting all of the existing patches. scim-prime will also need to be removed from wheezy. This rules out the slim option of rolling back to a point before all these changes started by introducing an epoch based on the current scim and scim-anthy packages in squeeze and reintroducing those through unstable with suitable unblocks. The only solution which I can see is that scim-anthy and scim-prime have to be removed from testing and then introduced via wheezy-backports once that becomes available. This will allow users to upgrade and receive the extra hooks for gir*, gtk3 Qt related packages. scim would not be unblocked and would also have to be updated via backports. [0] http://release.debian.org/wheezy/freeze_policy.html -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpmhSSTouymH.pgp Description: PGP signature
Bug#690403: RM: scim-anthy/1.2.7-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm scim-anthy is RC buggy and out of all the possible fixes, the only sensible choice is to remove scim-anthy from testing and reintroduce it via wheezy-backports once that becomes available. The reasons for this removal are that scim-anthy requires an updated version of scim which cannot be reasonably unblocked for migration into wheezy due to substantial changes in the new upstream version. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687401#22 Please remove scim-anthy from testing. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20121013205623.13296.7970.reportbug@sylvester.codehelp
Bug#690402: RM: scim-prime/1.0.0-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm scim-prime is RC buggy in wheezy but the NMU uploaded to unstable contains significant changes including replacing the dpatch build-dependency with source format 3.0 quilt - including rewriting all the old patches and moving to compat 9. As part of the fix for #687401, please remove scim-prime from wheezy so that the fixed version can be uploaded to wheezy-backports once that becomes available after the wheezy release. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687401#22 Please remove scim-prime from testing. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20121013205608.13750.19671.reportbug@sylvester.codehelp
Bug#690411: unblock: scim-chewing/0.3.4-1.2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package scim-chewing
The RC bug #676009 was closed in unstable but then
further uploads were made with unrelated packaging changes
and another RC bug filed for the same issue (#684854),
now merged.
I've prepared an NMU (diff attached) for testing-proposed-updates
as 0.3.4-1.2 which simply pulls the gtk patch out of the
unstable changes and makes no other changes.
Please confirm that this is OK to upload to t-p-u.
unblock scim-chewing/0.3.4-1.2
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armel
i386
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru scim-chewing-0.3.4/debian/changelog scim-chewing-0.3.4/debian/changelog
--- scim-chewing-0.3.4/debian/changelog 2012-04-03 06:51:46.0 +
+++ scim-chewing-0.3.4/debian/changelog 2012-10-13 23:36:14.0 +
@@ -1,3 +1,13 @@
+scim-chewing (0.3.4-1.2) testing-proposed-updates; urgency=low
+
+ * Non-maintainer upload.
+ * Apply gtk.patch from unstable upload without extraneous
+changes. Fixes FTBFS: scim_color_button.cpp
+(Closes: #684854). Thanks Tz-Huan Huang tzh...@gmail.com
+from upstream.
+
+ -- Neil Williams codeh...@debian.org Sat, 13 Oct 2012 23:25:01 +
+
scim-chewing (0.3.4-1.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru scim-chewing-0.3.4/debian/patches/gtk.patch scim-chewing-0.3.4/debian/patches/gtk.patch
--- scim-chewing-0.3.4/debian/patches/gtk.patch 1970-01-01 00:00:00.0 +
+++ scim-chewing-0.3.4/debian/patches/gtk.patch 2012-10-13 23:19:11.0 +
@@ -0,0 +1,859 @@
+commit 3cbe332e6b15ed674513d0b28e1966ff2bae1b45
+Author: Andrew Lee (李健秋) ajq...@debian.org
+Date: Fri Jul 6 01:22:55 2012 +0800
+
+Import upstream snapshot.
+
+diff --git a/src/scim_chewing_imengine_setup.cpp b/src/scim_chewing_imengine_setup.cpp
+index 75a9f51..c14eb74 100644
+--- a/src/scim_chewing_imengine_setup.cpp
b/src/scim_chewing_imengine_setup.cpp
+@@ -165,7 +165,10 @@ static GList *selKey_type_list = 0;
+ static GList *selKey_num_list = 0;
+ static GList *chieng_mode_list = 0;
+ // static GtkWidget* __widget_show_candidate_comment= 0;
++#if GTK_CHECK_VERSION(2, 12, 0)
++#else
+ static GtkTooltips * __widget_tooltips = 0;
++#endif
+
+ static KeyboardConfigData __config_keyboards[] =
+ {
+@@ -322,7 +325,11 @@ static GtkWidget *create_options_page()
+ {
+ GtkWidget *vbox;
+
++#if GTK_CHECK_VERSION(3, 0, 0)
++ vbox = gtk_box_new (GTK_ORIENTATION_VERTICAL, 0);
++#else
+ vbox = gtk_vbox_new (FALSE, 0);
++#endif
+ gtk_widget_show (vbox);
+
+ __widget_add_phrase_forward =
+@@ -336,9 +343,15 @@ static GtkWidget *create_options_page()
+ G_CALLBACK( on_default_toggle_button_toggled ),
+ __config_add_phrase_forward );
+
++#if GTK_CHECK_VERSION(2, 12, 0)
++ gtk_widget_set_tooltip_text(
++ __widget_add_phrase_forward,
++ _( Whether to add Phrase forward or not. ));
++#else
+ gtk_tooltips_set_tip(
+ __widget_tooltips, __widget_add_phrase_forward,
+ _( Whether to add Phrase forward or not. ), NULL );
++#endif
+
+ __widget_phrase_choice_rearward =
+ gtk_check_button_new_with_mnemonic( _( _Rearward phrase choice ) );
+@@ -351,9 +364,15 @@ static GtkWidget *create_options_page()
+ G_CALLBACK( on_default_toggle_button_toggled ),
+ __config_phrase_choice_rearward );
+
++#if GTK_CHECK_VERSION(2, 12, 0)
++ gtk_widget_set_tooltip_text(
++ __widget_phrase_choice_rearward,
++ _( The behavior for phrase choice to be rearward or not. ));
++#else
+ gtk_tooltips_set_tip(
+ __widget_tooltips, __widget_phrase_choice_rearward,
+ _( The behavior for phrase choice to be rearward or not. ), NULL );
++#endif
+
+ __widget_auto_shift_cursor =
+ gtk_check_button_new_with_mnemonic( _( _Automatically shift cursor ) );
+@@ -366,9 +385,15 @@ static GtkWidget *create_options_page()
+ G_CALLBACK( on_default_toggle_button_toggled ),
+ __config_auto_shift_cursor );
+
++#if GTK_CHECK_VERSION(2, 12, 0)
++ gtk_widget_set_tooltip_text(
++ __widget_auto_shift_cursor,
++ _( Automatically shift cursor after selection. ));
++#else
+ gtk_tooltips_set_tip(
+ __widget_tooltips, __widget_auto_shift_cursor,
+ _( Automatically shift cursor after selection. ), NULL );
++#endif
+
+ __widget_esc_clean_all_buffer =
+ gtk_check_button_new_with_mnemonic(_( _Esc key to clean all buffer ) );
+@@ -381,9 +406,15 @@ static GtkWidget *create_options_page()
+ G_CALLBACK( on_default_toggle_button_toggled ),
+ __config_esc_clean_all_buffer );
+
++#if GTK_CHECK_VERSION(2, 12, 0)
++ gtk_widget_set_tooltip_text(
++ __widget_esc_clean_all_buffer,
++ _( Assign Esc key to clean
Bug#689890: unblock: emdebian-crush/2.2.19
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package emdebian-crush
This fixes RC bug 688912. There are po and POT line
number changes but the debdiff comparede to testing
is the same as the one attached to the bug report.
unblock emdebian-crush/2.2.19
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armel
i386
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: debian/changelog
===
--- debian/changelog (working copy)
+++ debian/changelog (working copy)
@@ -1,3 +1,13 @@
+emdebian-crush (2.2.19) unstable; urgency=low
+
+ * Check for MultiArch support in dpkg and force the multiarch
+support in dpkg-cross if the requested architecture is in the
+list of dpkg foreign architectures. (Closes: #688912)
+ * Limit installation to only packages successfully converted using
+dpkg-cross.
+
+ -- Neil Williams codeh...@debian.org Wed, 26 Sep 2012 22:16:57 +0100
+
emdebian-crush (2.2.18) unstable; urgency=low
* Implement the new lintian profile support
Index: xapt/xapt
===
--- xapt/xapt (working copy)
+++ xapt/xapt (working copy)
@@ -203,6 +203,27 @@
$config_str .= -o Dir::State::Status=${dpkgdir}status;
$config_str .= -o Dir::Cache=${dir};
+# use dpkg --print-foreign-architectures dpkg = 1.16.2
+my $cmd = 'dpkg-query -W -f \'${Version}\' dpkg';
+$installed = `$cmd 2/dev/null`;
+my $res = system (dpkg --compare-versions $installed '=' 1.16.2);
+$res = 8;
+if (($res == 0) and (not defined $multiarch)) {
+ $res = system(dpkg --print-foreign-architectures | grep $arch /dev/null);
+ $res = 8;
+ if ($res == 0) {
+ $cmd = 'dpkg-query -W -f \'${Version}\' dpkg-cross';
+ $installed = `$cmd 2/dev/null`;
+ $res = system (dpkg --compare-versions $installed '=' $minver);
+ $res = 8;
+ if ($res != 0) {
+ die (Unsupported combination of old dpkg-cross and new dpkg!\n);
+ }
+ $multiarch++;
+ warn (Warning: Multi-Arch support has been enabled.\n);
+ }
+}
+
print apt-get $config_str update\n;
system (apt-get $config_str update 2/dev/null);
my $str = join ( , @files);
@@ -256,7 +277,7 @@
@list = grep(/\.deb$/, readdir DEBS);
closedir (DEBS);
}
-system (dpkg -i ${dir}output/*.deb)
+system (dpkg -i ${dir}output/*${arch}-cross*.deb)
if ((scalar @list 0) and (not defined $build) and ($host ne $arch));
system (rm -rf ${dir}*) if (not defined $preserve);
Re: Freeze Exceptions for libti*, TiLP, GFM and TilEm
On Mon, 1 Oct 2012 20:44:39 -0400 Albert Huang alberth.deb...@gmail.com wrote: 5. as above, important changes that the maintainer feels are needed before release. http://release.debian.org/wheezy/freeze_policy.html My intent was based on #5 - the current package(s), as they stand, are rather unusable. ... but no bugs have been reported about such problems and it is too late to introduce a new package into Wheezy. The changes would have to be ported to the existing packages instead. None of which are release critical for Debian. Ah - I originally thought that FTBFS was considered RC. Not unless the FTBFS affects a release architecture. For backports, would I ask end users to add that repo once the release occurs? To go into backports, the packages have to be first uploaded to unstable, migrated into testing (which will be Jessie by that stage) and then built on Wheezy and uploaded to wheezy-backports once that becomes available. And backports will NOT ever migrate packages to stable (wheezy), I would assume? Yes. backports never make it into a point release and these packages do not sound like they would be suitable for inclusion into a point release of Wheezy. Users of stable are generally quite familiar with using the relevant backports packages. Users specify exactly which packages are selected from backports. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpq5cbni0CII.pgp Description: PGP signature
Re: Freeze Exceptions for libti*, TiLP, GFM and TilEm
On Mon, 1 Oct 2012 17:39:08 -0400 Albert Huang alberth.deb...@gmail.com wrote: I should've done this earlier, but better late than never, right? Not really. There are time limits and they passed quite a long time ago now...after a considerable period of notice of the time limits themselves... (I was under the impression that the packages must enter unstable before considering any wheezy/testing exceptions.) All the packages you mention are at the same version in testing and unstable currently - if you are proposing updated packages to be uploaded to unstable then, yes, the packages must be already in unstable and without fresh RC bugs before considering a freeze exception. A release freeze is NOT the right time to test new upstream versions of packages! All packages for consideration in a Debian stable release must be allowed time for testing within Debian before the release. I would also like to ask for an exception for a NEW package, tilem. New packages do not meet the criteria for freeze exceptions. 1. fixes for release critical bugs (i.e., bugs of severity critical, grave, and serious) in all packages; 2. changes for release goals, if they are not invasive; 3. fixes for severity: important bugs in packages of priority: optional or extra, only when this can be done via unstable; 4. translation updates and documentation fixes; pre-approved fixes; 5. as above, important changes that the maintainer feels are needed before release. http://release.debian.org/wheezy/freeze_policy.html libticonv: * Fixes #686635 and #678872. The former is a copyright bug that has been fixed by a NMU, which provides a partial fix that is remedied by my update. #678872 is an ITA. If #686635 is only a partial fix, re-open the bug. libticables: * This one fixes a LOT of bugs: None of which are release critical for Debian. ITA bugs are not release critical. I believe that these packages are very beneficial for the Debian/Ubuntu/Mint TI Linux community, and have significant demand. But none have had any testing in Debian and the opportunity for these packages to migrate into Wheezy has been missed. I've pasted the links of all of the debdiffs for the packages. libticonv is the only package that may be considered ready for uploading; the rest are undergoing last minute polish. Nevertheless, all of them are provided for reference. So the packages are not even ready for testing in unstable... just how long is Debian expected to wait for these updates when the window for these uploads closed 3 months ago already? Please consider granting freeze exceptions for these packages! Doesn't look as if any of these prospective uploads meet any of the criteria for a freeze exception. The packages have waited this long for an update, do the upload to unstable after the release and then consider a backport. In the meantime, please consider working on some of the existing RC bugs to help get the release done. That way, everyone gets what they want quickly. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpcvf08q9qre.pgp Description: PGP signature
Re: Squeeze point release (6.0.6)
On Mon, 17 Sep 2012 15:59:09 +0200 Philipp Kern pk...@debian.org wrote: On Mon, Sep 17, 2012 at 03:58:13PM +0200, Philipp Kern wrote: ok, given the replies, let's settle on this: On Fri, Sep 07, 2012 at 09:43:03PM +0200, Philipp Kern wrote: * Sep 29/30: ok from RT side We still need a press officer for somewhen in the evening to send out the announcement, feedback from -live and a note from -kernel if there's still a change staged for the next point release. That should be read as let's settle for Sep 29. Just because I'm lurking, Sept 29th is fine for Emdebian Grip 2.0.6 too. I'll be brushing up the necessary updates tomorrow ready for a simple pull on the day. (BTW, Wheezy will still be 3.0.0 for us - we'll get back into step with Jessie as 8.0.0 via the new dak support. We can skip 4, 5, 6 7.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp5Aflh0KjSZ.pgp Description: PGP signature
Re: libfm pcmanfm stable release.
On Mon, 3 Sep 2012 02:51:43 +0300 Andrej N. Gritsenko and...@rep.kiev.ua wrote: Hello, Debian Release Team! Was there something about the thread on -devel which wasn't clear? I'm talking about libfm and pcmanfm which entered freeze state two months ago and published as 1.0 release in beginning of August. i.e. too late. only by developers and testers. You may look into pcmanfm bugtracker at Sourceforge to see how many bugs were fixed (some of them were reported to Debian BTS as well) - crashes, locks of X server, huge memleaks... The ones reported to the Debian BTS are not release critical, so no update is necessary. That was said in mailing list there was a pre-approval for inclusion of stable releases of those packages into unstable then to Wheezy. Of these actual packages? There seems to be no link to such a statement. Packages with updates already in Debian unstable when the freeze was announced got pre-approval for inclusion into Wheezy. If packages are to be updated in Wheezy afterwards, there need to be bug reports in Debian which are deemed release critical and an upload to unstable which *only* fixes those bugs. A new upstream release is not generally considered as an exception to the freeze at this stage of the release cycle. Specific fixes for specific bugs in the Debian BTS is what the freeze is all about. As maintainers are still busy and I have the source package which was tested thoroughly for compilation and upgrading on Debian Testing, I would like to know how I can help in that. I've uploaded the packages onto Mentors site already (pcmanfm package includes backport patch from upstream for the abovementioned crash). Bug number in the Debian BTS? Tell me what I should do next, please. Thank you in advance! There are currently no RC bugs against these packages filed in Debian. There is nothing to fix. There are, however, many other packages in Debian which *do* have release critical bugs. You could always turn your development skills onto some of those packages. That way, the release team would be able to release Wheezy sooner and we'd all be happy. Please wait for Wheezy to be released with the current versions of these packages and then work with the existing maintainers to get the updates into Jessie. If there are user requests for backports of the updates to Wheezy, those can be handled after the release. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpY9GJygtCiN.pgp Description: PGP signature
Re: libfm pcmanfm stable release.
On Mon, 3 Sep 2012 15:58:35 +0300 Andrej N. Gritsenko and...@rep.kiev.ua wrote: There are currently no RC bugs against these packages filed in Debian. There is nothing to fix. I have found some. It is bug #593607 in BTS. It has severity Critical but tagged as 'squeeze-ignore' so doesn't appear as RC. You've misinterpreted the ignore tag. The current freeze relates to Wheezy and therefore, the bug is not marked as ignore for wheezy, it was ignored at the time of the squeeze freeze. It would be RC if it was still open but it has been closed. RC for the Wheezy release relates to the package as in Wheezy, not Squeeze. It still presents in Wheezy The maintainers and original submitter disagree. The bug is closed. and even me as one of upstream developers cannot tell you which upstream commit fixed that so I cannot backport the fix. A single (closed) bug wouldn't be enough to get both packages updated and the actual fix would need to have been identified anyway. And since nobody seems interested in changing this, let the bug be fixed later backporting 1.x version after Wheezy is released. Fine, then lets let the maintainers maintain the package and leave this as unchanged. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpKwIJrEZuWd.pgp Description: PGP signature
Re: mpg321 - Critical bug that makes package unusable and breaks others also
On Wed, 22 Aug 2012 21:02:33 +0300 Nanakos Chrysostomos nana...@wired-net.gr wrote: Hi all. I have a question to make before proceeding in trying to find a sponsor for one of my packages (mpg321). I want to close one or two bugs (non-RC) Do those bug fixes meet the freeze criteria? http://release.debian.org/wheezy/freeze_policy.html If not, push those changes into experimental and then use wheezy-backports once it is available. Keep extraneous changes out of the version of the package in unstable. Release-criteria changes only. but I want also to DISABLE one new feature that I added recently. This new feature (buffered output) does not perform very well and its not very stable making mpg321 unusable sometimes Nothing stops a maintainer filing an RC bug on their own package. You discovered the problem, you can file (and fix) the bug. Disabling the problematic behaviour could be an appropriate fix for that bug but filing the bug at least makes sure that the release team and package users get a chance to see why the change was necessary. Spell out which packages are affected and what problems can result. (also sometimes breaks packages that use -b option that was not implemented till now because the behavior is non-deterministic). Because debian is in Freeze state for the moment will it be possible for this package to pass from unstable to testing and eventually to stable? Individual emails to this list tend to get missed easily, it is much, much better to file bugs - so that would be a second bug asking for an unblock *after* filing the RC bug and getting a sponsor to upload a version containing only the fix for that bug to unstable. (I'm *not* volunteering as sponsor, at least not yet.) The unblock bug would need the complete debdiff between the version in testing and the version in unstable to be attached. Please CC me because I am not subscribed in the list. Which is another reason to use bug reports. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp4UKs3UJfIY.pgp Description: PGP signature
Re: Please unlock makehuman
On Fri, 17 Aug 2012 22:56:15 -0430 Muammar El Khatib muam...@debian.org wrote: Dear Release team, I'd like to know if you could unlock makehuman. The last changes introduced in revisions -4, and -5 where minimal. You can take a look at them at: That won't work. Please read the freeze policy, especially rule #7: http://release.debian.org/wheezy/freeze_policy.html Turn your request into an unblock bug and attach a complete debdiff between the version currently in testing and the version to unblock. (Rule #3) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp3b9l14j2Ox.pgp Description: PGP signature
Bug#683244: binNMU
Just to help those scanning the RC bug lists, the binNMU request for bobcat is #683244. The binNMU for c++-annotations would need to be requested later. I've done a simple test in a pbuilder chroot and the principle of the request does fix these two RC bugs. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgppB2GuB1m4E.pgp Description: PGP signature
Bug#682908: Is this a done deal?
On Wed, 15 Aug 2012 10:51:49 -0400 Jordi Gutiérrez Hermoso jord...@octave.org wrote: On 15 August 2012 10:47, Adam D. Barratt a...@adam-barratt.org.uk wrote: On 15.08.2012 15:21, Jordi Gutiérrez Hermoso wrote: So is this settled? Emacs 24 appears not to have been released upstream until less than three weeks before the freeze. So it's a done deal, then? Ancient Emacs in Debian for two more years unless you use backports? I fail to see how a release which was considered current by upstream only three weeks before the deadline for the freeze can be considered ancient by anyone. It's not a lot of time to get a major upstream version packaged and tested. Backports exists to allow for packages which are updated at points where there wasn't enough time to get the new version into the release. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpdiaYehd3Mr.pgp Description: PGP signature
Bug#682908: Is this a done deal?
On Wed, 15 Aug 2012 13:15:44 -0400 Jordi Gutiérrez Hermoso jord...@octave.org wrote: On 15 August 2012 12:52, Neil McGovern ne...@debian.org wrote: On Wed, Aug 15, 2012 at 11:27:07AM -0400, Jordi Gutiérrez Hermoso wrote: Emacs 24 has been in pre-release mode So... not actually released then. Just because the Emacs devs are ultra-conservative. 24 has been in use by large swaths of the Emacs community for a long time. Doesn't matter. That version was not released until three weeks before the Debian freeze and did not get uploaded so could not be tested within Debian. That version was not ready for a stable Debian release as it failed to meet Debian quality requirements, despite upstream testing. This very bug report starts with a patch for architecture-specific problems which would have been release-critical, indicating that upstream did not release a version of emacs24 which was acceptable for immediate adoption within Debian. This is quite common, few upstreams have the resources to test on all Debian architectures. Therefore, the use of 24 in the community is irrelevant - the version of emacs24 released so close to the Debian freeze date was *not* suitable for Debian and needed specific work by the maintainer at DebConf to fix. (Thanks to Rob for doing the work.) The fixed version would need testing but there is now no time to get that into Wheezy. Anyways, this doesn't answer my question, which I've asked thrice. Here it goes again: is this a done deal, and we're getting an ancient (yes, ancient) Emacs version for wheezy? You've had your answer. Please don't post on this subject again. No, I have not. I still have not had a clear answer that there is no way to get a modern Emacs into wheezy. Just please say yes if this is the case. Three different people in Debian have already told you that emacs24 will not be in Wheezy. Adding more complaints is not going to encourage anyone to change their minds. emacs23 is in Wheezy and cannot be considered ancient as it was the modern emacs up until a few short weeks before the deadline. The chance to get emacs24 into wheezy has come and gone. emacs24 was not released early enough by upstream to be uploaded into Debian. When it was released by upstream, it was not ready for inclusion into Debian testing without the patch provided by the maintainer, which took time to develop. The upstream release date was just too close to the Debian freeze date. There was not enough time to get the upstream release packaged, fixed and tested within Debian, so there is now no route for emacs24 to get into Wheezy. Important fixes from 24 could be backported to 23 and those may well be approved by the release team, so work with the emacs maintainer. Adam has already pointed this out. The Debian freeze deadline was announced a year in advance, if this was such a pressing issue, you could have started working with the Debian maintainer and upstream months ago to push for an earlier release of 24 and an earlier upload to Debian - maybe by pushing pre-releases of 24 into experimental. The current Debian maintainer has already indicated that he is happy with not having 24 in Wheezy due to the lack of time for testing and the release critical bug in the original emacs24 release which he had to patch. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682908#13 This is my final contribution to this bug - I don't even use emacs. I'm just trying to help the release team concentrate on more useful parts of the freeze rather than repeatedly answering the same question with the same answer. The decision has been made, emacs24 was not and is not ready for inclusion into Wheezy, the window for it to be considered has closed. Wheezy will have emacs23, not emacs24 but emacs24 is certainly a candidate for backports. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp44LrIDdRoJ.pgp Description: PGP signature
Re: Package isc-dhcp
On Sat, 11 Aug 2012 10:50:36 +0200 Marco Maria Luciani marcomaria.luci...@live.it wrote: I've tried install debian testing and stable with ethernet, but the network interface does not recognize internet connection(the ip assigned to rent by dhcp to complete the netinst installation) Thanks for the report, there are ways to fix this but debian-release isn't the right list for installation problems: http://www.debian.org/releases/stable/i386/ch05s04.html (esp. secction 5.4.5 reporting installation problems) I believe that this package needs a patch to configure the Internet connection when installing debian Actually, it's quite likely that the network card for the machine being tested is missing some non-free firmware and isn't being recognised by the kernel but, without logs, no-one can really help with this problem. Please use the docs to see if you can get some debug information out of the installation process and send that in as a bug report. Have you been able to install Debian on this particular machine before? I've tested d-i for testing recently and the network interface came up normally via DHCP, using isc-dhcp. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpIfVuVcsZQ6.pgp Description: PGP signature
Bug#684567: unblock: apache2/2.2.22-11
On Sat, 11 Aug 2012 12:16:29 +0200 Arno Töll a...@debian.org wrote: Switch to xz compression for .deb members. This was done upon request as Apache might end up on Wheezy's CD1 (if we switch to Gnome again) because gnome-user-server reverse depends on it. gnome-user-server ? I think you mean gnome-user-share ? http://packages.debian.org/sid/gnome-user-share -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpX6lhORw3vY.pgp Description: PGP signature
Bug#683247: Bug#683030: unblock: vlc/2.0.3-1
On Mon, 30 Jul 2012 20:16:07 +0200 Julien Cristau jcris...@debian.org wrote: On Mon, Jul 30, 2012 at 11:01:20 -0700, Russ Allbery wrote: Julien Cristau jcris...@debian.org writes: On Mon, Jul 30, 2012 at 09:08:50 +0200, Reinhard Tartler wrote: AFAIUI the multi-arch spec, arch:all packages are not allowed to specify Multi-Arch: foreign, It's the opposite. Arch all packages are not allowed to specify Multi-Arch: same. Setting a value of Multi-Arch: same on a package which is Architecture: all is considered an error. dpkg-deb must refuse to generate a .deb with this combination of values https://wiki.ubuntu.com/MultiarchSpec#Binary_package_control_fields This means that for an Architecture: all package to satisfy the dependencies of a foreign-architecture package, it must be marked Multi-Arch: foreign or Multi-Arch: allowed. https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages so I had the impression that this part was rather obvious to multi-arch experts. Which I am clearly not, so being more explicit in the changelog is very much warrented. That is not true, there's lots of arch:all m-a:foreign packages. It should be close to 100% of the Arch:all packages which are ready for MultiArch. (allowed is rare currently and is only for specialised situations.) Are you sure? That doesn't make sense to me (as opposed to arch:any m-a:foreign packages). Arch:any Multi-Arch: foreign would typically be executables like 'at' (I'm fairly sure Ansgar understands MultiArch). Also base-passwd (Colin Watson, ditto). This is much more likely in the base system packages or where libraries end up depending on executables. As Julien states, in order to install such libraries as Multi-Arch: same, the base system and any executables in the dependency chain need to be available - usually as Multi-Arch: foreign. Surely arch:all packages are already effectively multi-arch without needing to use any of the new support? There are arch:any - arch:all - arch:any dependencies, and without m-a:foreign in the arch:all package, both arch-specific packages have to be from the same arch, AIUI. So yes, pretty sure. Agreed. I don't know if I qualify as a Multiarch expert but I have been testing MultiArch conversions, toolchains and installations as part of Emdebian for ~2 years. The terms used can be confusing - foreign means that the package meets the requirements of a foreign arch package which depends on it. Clearly, Arch:all will nearly always satisfy the dependencies of a foreign arch package. Typical example is debhelper - there is no reason for me to install debhelper:armel on amd64 in order to build stuff for amd64 armel. Foreign means that I just need one version - ideal for Arch:all. i.e. foreign is less constrained than same and foreign packages need only specify Multi-Arch: foreign in debian/control to complete their conversion. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpxCONTUPlZu.pgp Description: PGP signature
givaro: changed API without SONAME bump
notfound 678769 1.1.6~rc0-4.2 reassign 678769 src:givaro affects 678769 linbox affects 678769 fflas-ffpack retitle 678769 givaro: changed ABI without SONAME bump found 678769 3.7.0-2 thanks Justification: Policy 8.1 Every time the shared library ABI changes in a way that may break binaries linked against older versions of the shared library, the SONAME of the library and the corresponding name for the binary package containing the runtime shared library should change. Normally, this means the SONAME should change any time an interface is removed from the shared library or the signature of an interface (the number of parameters or the types of parameters that it takes, for example) is changed. This practice is vital to allowing clean upgrades from older versions of the package and clean transitions between the old ABI and new ABI without having to upgrade every affected package simultaneously. The sequence was as follows: 0: givaro 3.2.13 was uploaded on 2012-05-29, the same day that linbox was NMU'd by doko for a gcc-4.7 FTBFS in linbox. Everything was fine at this point. 1: On 2012-06-10 - close to the known start of the release freeze for Wheezy - givaro 3.7.0-1 was uploaded, followed by 3.7.0-2 on 2012-06-21. AFAICT the release team were not asked about either upload, there was no request to binNMU linbox (it would have failed, had this been done). 2: givaro migrates into testing on 2012-07-02, despite #678769 being filed by Lucas on 24 Jun 2012 against linbox because the linbox maintainer didn't respond to the RC bug or try to work out what was wrong. 3: givaro doesn't use versioned symbols, so none of this was noticed by the givaro maintainer. (If a libgivaro0.symbols file was in use in 3.2.13, 3.7.0 would have failed to build for the givaro maintainer, complaining about missing symbols which *should* have given the hint that the givaro API had changed). givaro 3.7.0 has the following diffstat for just one of the public header files, givinteger.h: givinteger.h | 501 ++- 1 file changed, 361 insertions(+), 140 deletions(-) This consists, mainly, of moving all of the Class IntegerDom public declarations inside a new namespace (Givaro::). Namespacing public functions and classes has the effect of *removing* the symbols as defined in 3.2.13 and *adding* all the same symbols back again with the namespace included as part of the symbol. This is an incompatible API change and requires source code changes in any reverse dependencies which include the affected header file. In this case, linbox. Therefore, givaro should have migrated to libgivaro1 at which point the givaro maintainer would have had to contact the release team for approval of a new transition which, at the time it was done, would likely have been denied. Instead, Debian testing now has a version of givaro which breaks reverse dependencies, a version of linbox which requires numerous source code changes to build against the new givaro (my patch so far includes 12 separate changes in the linbox source code and I've only processed the first few instances) and a version of fflas-ffpack which needs a rebuild against whatever version of givaro we end up with, or removal if that is the decision regarding fixing the givaro mess. My proposal to the release team to fix this mess is that all three packages (givaro, fflas-ffpack and linbox) are removed from testing as each maintainer has failed to spot the problem or prevent the breakage. No other packages would be affected by these removals. fflas-ffpack has the same maintainer as givaro. The reassignment of this bug does not affect the removal as the givaro maintainer should already have noticed that this bug existed and linbox needs substantial source code changes to work with the new givaro API. It does not seem likely to me that the necessary changes will be made given the lack of response to the original RC bug against linbox. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpDh15hW5Rhx.pgp Description: PGP signature
Re: BinNMU changelog handling for Multi-Arch: same packages
On Wed, 11 Jul 2012 17:01:24 -0700 Russ Allbery r...@debian.org wrote: Raphael Hertzog hert...@debian.org writes: The right *temporary* solution then. Remember that this was meant as an intermediary solution until the full changelog (with the bin-nmu entry) is just integrated in the package medata (control.tar). Please don't put that into the files used to prepare content for dpkg -s and apt-cache - that output is large enough as it is. A single step like this could seriously compromise package handling on low resource machines and push apt passed it's memory mapping limits again even on more powerful machines. Oh, yes, absolutely agreed. Sorry for not making that clear. Putting the changelog in the package metadata makes a ton of sense. In fact, if we could also do that with the copyright file, that would eliminate nearly all of our issues with linked doc directories and would simplify a whole currently-contentious area of Policy, replacing it with a much simpler debate about the right interface to view those files for installed packages. ... and that would be even worse if not isolated from the status and cache information at the point where it is unpacked. Wherever the data lives inside the .deb is not the problem. Where the data gets cached, copied, listed and parsed is likely to be a major problem. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpxAKk7tlVeC.pgp Description: PGP signature
Bug#680890: unblock: alsa-base/1.0.25+2+nmu1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package alsa-base for the RC bug fix just uploaded for #673679. The complicating factor here is the udeb. alsa-drivers provides the old alsa-base udeb in testing which is now provided by alsa-base in unstable. 48 days old (needed 10 days) Not touching package due to block-udeb request by freeze (contact debian-release if update is needed) unblock alsa-base/1.0.25+2+nmu1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20120708221837.22140.98699.reportbug@sylvester.codehelp
frei0r patch, opencv transition and cheese
In an attempt to allow Gregor's patch to #657410 to be uploaded to fix cheese, I've investigated the FTBFS of frei0r and I have a patch (attached). debdiff ../frei0r_1.1.22git20091109-1.1.dsc ../frei0r_1.1.22git20091109-1.2.dsc diffstat for frei0r_1.1.22git20091109-1.1 frei0r_1.1.22git20091109-1.2 frei0r-1.1.22git20091109/debian/changelog | 10 ++ frei0r-1.1.22git20091109/debian/control |1 + frei0r-1.1.22git20091109/debian/rules |9 + src/filter/facedetect/facedetect.c|2 +- 4 files changed, 21 insertions(+), 1 deletion(-) The reason for the FTBFS is that libopencv-objdetect-dev contains the /usr/include/opencv2/objdetect/objdetect.hpp header which has had an ABI-incompatible change to cvHaarDetectObjects - removing the definition with 7 arguments and adding a definition with 8. Old: http://www.emgu.com/wiki/files/1.3.0.0/html/55a16889-537c-534f-f2fa-fbbe60e1d8d4.htm The current header adds a maxSize, so the patch simply sets the maxSize to the same as the minSize. frei0r doesn't have a patch system (source format 1.0 - undeclared), so I haven't added one - simply added a suitable clean target so that the autotools changes are handled. The rebuilt package also allows the frei0r-plugins package to install cleanly, so I've merged with 657942. There is an RFS but it doesn't look ready and includes lots more changes than just fixing the FTBFS. http://lists.debian.org/debian-mentors/2012/02/msg00013.html Please let me know if this is OK to upload. -- Neil Williams = http://www.linux.codehelp.co.uk/ diffstat for frei0r_1.1.22git20091109-1.1 frei0r_1.1.22git20091109-1.2 frei0r-1.1.22git20091109/debian/changelog | 10 ++ frei0r-1.1.22git20091109/debian/control |1 + frei0r-1.1.22git20091109/debian/rules |9 + src/filter/facedetect/facedetect.c|2 +- 4 files changed, 21 insertions(+), 1 deletion(-) diff -u frei0r-1.1.22git20091109/debian/control frei0r-1.1.22git20091109/debian/control --- frei0r-1.1.22git20091109/debian/control +++ frei0r-1.1.22git20091109/debian/control @@ -8,6 +8,7 @@ Vcs-Browser: http://git.dyne.org/?r=frei0r Homepage: http://www.piksel.org/frei0r Build-Depends: cdbs, debhelper ( 5.0.0), pkg-config, libcv-dev, libgavl-dev (= 1.1.0), + libtool, autoconf, automake, libcvaux-dev, libhighgui-dev Standards-Version: 3.8.3 diff -u frei0r-1.1.22git20091109/debian/rules frei0r-1.1.22git20091109/debian/rules --- frei0r-1.1.22git20091109/debian/rules +++ frei0r-1.1.22git20091109/debian/rules @@ -8,0 +9,9 @@ +clean:: + $(RM) Makefile.in aclocal.m4 configure doc/Makefile.in + $(RM) doc/html/Makefile.in include/Makefile.in ltmain.sh + $(RM) m4/libtool.m4 m4/ltoptions.m4 m4/ltversion.m4 + $(RM) m4/lt~obsolete.m4 m4/ltsugar.m4 src/Makefile.in + +makebuilddir:: + libtoolize -f + autoreconf -fs diff -u frei0r-1.1.22git20091109/debian/changelog frei0r-1.1.22git20091109/debian/changelog --- frei0r-1.1.22git20091109/debian/changelog +++ frei0r-1.1.22git20091109/debian/changelog @@ -1,3 +1,13 @@ +frei0r (1.1.22git20091109-1.2) unstable; urgency=low + + * Non-maintainer upload. + * Fix FTBFS: filter/facedetect/facedetect.c:231:36: error: too few +arguments to function 'cvHaarDetectObjects' Supply minimum and +maximum sizes to mimic previous single size requirement. +(Closes: #652759) + + -- Neil Williams codeh...@debian.org Sat, 03 Mar 2012 00:13:03 + + frei0r (1.1.22git20091109-1.1) unstable; urgency=low * Non-maintainer upload. only in patch2: unchanged: --- frei0r-1.1.22git20091109.orig/src/filter/facedetect/facedetect.c +++ frei0r-1.1.22git20091109/src/filter/facedetect/facedetect.c @@ -228,7 +228,7 @@ double t = (double)cvGetTickCount(); faces = cvHaarDetectObjects( small_img, cascade, storage, 1.1, 2, 0/*CV_HAAR_DO_CANNY_PRUNING*/, - cvSize(30, 30) ); + cvSize(30, 30), cvSize(30, 30) ); t = (double)cvGetTickCount() - t; //printf( detection time = %gms\n, t/((double)cvGetTickFrequency()*1000.) ); pgpH11xkINabg.pgp Description: PGP signature
Re: frei0r patch, opencv transition and cheese
On Sat, 3 Mar 2012 11:23:47 +0100 Cyril Brulebois k...@debian.org wrote: Hi Neil. Neil Williams codeh...@debian.org (03/03/2012): There is an RFS but it doesn't look ready and includes lots more changes than just fixing the FTBFS. http://lists.debian.org/debian-mentors/2012/02/msg00013.html Please let me know if this is OK to upload. Michael and I have tried to get some news, be it about a fixed version of this RFS (which indeed didn't look like ready), or the status of the new upstream version, but AFAICT, we didn't hear back. So I'm very happy if we can go forward thanks to a targeted NMU. Thanks, uploaded. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpxNrsmxK4EM.pgp Description: PGP signature
Re: taxbird: Version for 2011 available upstream
On Wed, 1 Feb 2012 12:38:09 -0600 Jonathan Nieder jrnie...@gmail.com wrote: (cc-ing release team for a strange release management question) It's not a release team issue. Backports can be used in some situations but this is for updates to packages which are otherwise stable, not those which become useless due to external Would it be feasible to address this somehow in stable? Please forgive my ignorance. See #577760 which would be the correct solution. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp1eyPw9XysV.pgp Description: PGP signature
Emdebian partial archives and testing migrations
I'm ready to move from working on unstable processing now to dependency resolution for testing in Emdebian. We only have 10% of the packages in Debian and I'll automate the process of adding packages to our list when a package we already include gains a dependency which isn't currently in the list. The complication comes about when that updated package wants to migrate into testing. Say foo exists already in Emdebian and at some point in the future, in unstable-grip and testing-grip in Debian. All dependencies of foo are satisfied in unstable-grip and testing-grip. Now a new version of foo gets uploaded to unstable with a new dependency on libbar0 which wasn't included in Emdebian previously but is in Debian. libbar0 hasn't needed an upload for a while and is already in testing at the same version as unstable. I can add libbar0 to Emdebian and unstable-grip via a package upload to unstable. I want to check the release team preference for migrating libbar0 in this case. 0: I could upload libbar0 to unstable-grip when my scripts check the dependencies of libfoo2. This means that the release team scripts would need to notice that libbar0 in unstable-grip needs to migrate to testing-grip when it has already migrated in testing. Does britney already do this? (Is this how armhf is being managed etc.?) How soon would libbar0 migrate in that case - the next britney run or the same time as foo? 1: I could upload libbar0 to a testing-grip queue as well as to unstable-grip. This might need to be arranged with ftp-master and involves two (almost identical) uploads. Preferences? Alternatives? I'm suspecting that 0 is the right choice but I want to be sure before I write the code. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpSpOUet41KC.pgp Description: PGP signature
Re: kfree-* , portmidi, Re: pygame
On Mon, 02 Jan 2012 11:28:45 +0100 A Mennucc mennu...@debian.org wrote: hi, related to the pygame problem [1] is another question: will kfreebsd-* be a release architecture in wheezy? If yes - then portmidi has a release critical bug in it, it should Whether any particular arch is a release arch or not, merely because a particular package is not available for that arch does not mean that the package has an RC bug. If it claims to be available and then fails, that is different but a possible fix for such bugs is to not build the package on that architecture. Many packages are specific to individual architectures. The bugs would be in the reverse dependencies which require the package but are still trying to install on architectures where that package is not (or is no longer) available. e.g. there are plenty of packages which are i386 or amd64 only - those are inevitably missing on armel and mips etc. The only bugs would be if packages in armel or mips etc. depended on these packages. Wherever possible, packages must build on all release architectures but if the architecture itself does not support functionality required for the package (e.g. stuff that is specific to linux kernels) there is usually little point trying to reimplement that functionality in the userspace code. In general, metapackages and Arch:all packages are immune to this requirement - debcheck adds details to the relevant PTS pages but most instances are not a problem. be removed from testing [2], and at the same time pygame should be built w/o it ; The reverse dependencies would appear to need fixing. 0: By removing the reverse dependencies from architectures where the dependency is not available or 1: By patching the reverse dependencies to use something else or not implement that functionality where it does not exist. The current situation is a mess, since 'portmidi' is in testing, but there is no kfreebsd-* binary for it (as if no) - whereas python-pygame is not allowed in (as if yes). The current situation is that portmidi is waiting for it's reverse dependencies to catch up with the requirements of the new version. This is correct - portmidi cannot migrate until it's reverse dependencies are fixed. portmidi does not need to be removed from testing, it is satisfying the release criteria and the migration criteria (hence valid candidate) - what is broken are the reverse dependencies which still expect it to be available on architectures where it cannot actually build or function. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpAPTI4lEn2K.pgp Description: PGP signature
Emdebian integration
I've now got a VM managed by DSA to handle the processing of Emdebian packages using blavet.debian.org and I'm liaising with ftp-master to sort out the GnuPG key to sign uploads. I've already included support for armhf inside the Emdebian scripts, so that will update alongside the other architectures. The full list is now: i386, amd64, armel, armhf, mips, mipsel, powerpc. Emdebian is not proposing to support contrib or non-free nor BSD kernels. The current Lenny and Squeeze releases should stay unchanged, moving Emdebian Grip from 2.0.2 (based on Squeeze 6.0.2) to Emdebian Wheezy-Grip 7.0. I've also investigated CD builds and Steve's happy to provide them once wheezy-grip is in a usable state. My current plan is: 0: Continue development with help from ftp-master and DSA to get the final bugs out of the scripts. 1: Process packages on blavet and dput the resulting .changes files to www.emdebian.org and ensure the processing can keep in sync with the main archive. 2: Decide how to populate the new suites. I am currently working on bringing sid-grip into sync with the main archive and I'd like that set of packages to be sync'd to Debian to initialise sid-grip and (if you want to do it this way) wheezy-grip. Alternatively, create wheezy-grip in a similar manner to how armhf will do it, but this will be for seven architectures, not one - albeit with 3,000 packages each. 3: Switch over to using dput to ftp-master sometime around the New Year. Convert www.emdebian.org to be a mirror of the Emdebian suites. At some point, I'll contact the www team to sort out support in packages.d.o and qa.d.o. How does this sound to you? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp8AeJuOcFVj.pgp Description: PGP signature
Re: library transition
On Sun, 02 Oct 2011 00:06:42 +0200 Richard B. Kreckel krec...@ginac.de wrote: Hi! I realize this must be a FAQ, but I still need a little bit coaching on how to make a library version transition from libginac-1.5.so.0 to libginac.so.2: http://release.debian.org/migration/testing.pl?package=ginac What can I do to make progress? Looks like libsyfi0 still depends on libginac1.5 (= 1.5.0) on all architectures. http://packages.debian.org/sid/libsyfi0 http://packages.qa.debian.org/s/syfi.html says: [2011-09-17] Accepted 1.0-beta-1 in unstable (low) (Johannes Ring) http://packages.qa.debian.org/g/ginac.html says: [2011-07-22] Accepted 1.6.1-1 in unstable (low) (Richard Kreckel) Unfortunately, syfi FTBFS against libginac2/libginac-dev (= 1.6.1-1): [100%] Building CXX object syfi/swig/CMakeFiles/_SyFi.dir/SyFiPYTHON_wrap.cxx.o cd /home/syfi-1.0-beta/obj-x86_64-linux-gnu/syfi/swig /usr/bin/g++ -D_SyFi_EXPORTS -DSYFILIB_VERSION=\1.0.0.beta\ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security =format-security -O2 -g -fPIC -I/home/syfi-1.0-beta/syfi -I/home/syfi-1.0-beta/obj-x86_64-linux-gnu/syfi -I/home/syfi-1.0-beta/syfi/swig -I/home/syfi-1.0-beta/obj-x86_64-linux-gnu/syfi/swig -I/usr/include/python2.7 -I/usr/lib/pymodules/python2.7/numpy/core/include-o CMakeFiles/_SyFi.dir/SyFiPYTHON_wrap.cxx.o -c /home/syfi-1.0-beta/obj-x86_64-linux-gnu/syfi/swig/SyFiPYTHON_wrap.cxx g++: error: =format-security: No such file or directory bug report being filed... -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpMhL1iJrXiL.pgp Description: PGP signature
Re: library transition
On Sun, 2 Oct 2011 12:48:01 +0200 Julien Cristau jcris...@debian.org wrote: On Sun, Oct 2, 2011 at 09:33:59 +0100, Neil Williams wrote: On Sun, 02 Oct 2011 00:06:42 +0200 Richard B. Kreckel krec...@ginac.de wrote: Hi! I realize this must be a FAQ, but I still need a little bit coaching on how to make a library version transition from libginac-1.5.so.0 to libginac.so.2: http://release.debian.org/migration/testing.pl?package=ginac What can I do to make progress? Looks like libsyfi0 still depends on libginac1.5 (= 1.5.0) on all architectures. libsyfi0 is obsolete, and is not in sid. True, my bad - syfi still FTBFS in sid though, #644044, and the version of syfi in sid needs ginac from sid. :-( (new bug after the fix for the last RC FTBFS bug in syfi.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpYxV4ARGtTA.pgp Description: PGP signature
imagemagick result
notfound 634550 8:6.6.9.7-5 quit Now that libwmf is fixed, imagemagick builds successfully in a clean pbuilder chroot without changes. Maybe #634550 should have been re-assigned to libwmf in the first place. During the build, there was a hint about #634194 and the possible reason for the binNMU request: /usr/bin/ld: warning: libjpeg.so.62, needed by /usr/lib/libtiff.so, may conflict with libjpeg.so.8 imagemagick in the archive currently depends on libjpeg62 and my rebuilt version depends on libjpeg8 (but brings in libjpeg62 via libtiff4): Depends: libbz2-1.0, libc6 (= 2.2.5), libfontconfig1 (= 2.8.0), libfreetype6 (= 2.2.1), libglib2.0-0 (= 2.12.0), libgomp1 (= 4.2.1), libice6 (= 1:1.0.0), libjpeg8 (= 8c), liblcms1 (= 1.15-1), liblqr-1-0 (= 0.1.0), libltdl7 (= 2.4), libmagickcore4 (= 8:6.6.9.7), libmagickwand4 (= 8:6.6.9.7), libsm6, libtiff4, libx11-6, libxext6, libxt6, zlib1g (= 1:1.1.4) (imagemagick-extra has the depends on libwmf) Would the best solution here be to binNMU libtiff to close #634194 and then reassign #634550 for an imagemagick binNMU? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgppV8ZFxEFc3.pgp Description: PGP signature
Re: Trinity
On Sat, 11 Jun 2011 12:25:30 +0200 rhism...@vodamail.co.za wrote: Hello, I have been a Debian user since 5.0.3. This query is best directed at the debian-user mailing list. http://lists.debian.org/debian-user/ I recently got 6.0.1a and was perplexed to find out that kde3 was removed. Nobody was willing to maintain KDE3 separately from KDE4 in Debian. The volunteers in Debian wanted to work on KDE4. http://lists.debian.org/debian-devel/2011/05/msg00056.html I found out that Timothy Pearson is continuing development of kde3, called Trinity. It was discussed within Debian - the result was that nobody was willing and able to do the work to maintain KDE3/Trinity. It's a lot of work. I'd like to know if the source dvd's of Debian include a build order or buildscript and how do I build deb packages apt-get source dpkg-buildpackage or use apt-build. Please direct questions to the debian-user list. Release is not the right forum for this discussion. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpWuNhZDVEFr.pgp Description: PGP signature
gnome-pilot transition?
gnome-pilot is orphaned but there is a new upstream release, I'm looking at a QA upload (as I did the last one). Ubuntu have packaged it but not changed the package name. Formerly it was libgnome-pilot2 but now that library has a SONAME of 5 and the library package includes two other libraries, SONAME 3 and SONAME 4. ./usr/lib/libgpilotd.so.5 ./usr/lib/libgpilotdcm.so.4 ./usr/lib/libgpilotdconduit.so.3 AFAICT the only reverse dependency is gnome-pilot-conduits which I've also updated, but won't upload yet. Changes are in SVN: http://svn.debian.org/wsvn/collab-maint/ext-maint/gnome-pilot/trunk/?op=log http://svn.debian.org/wsvn/collab-maint/ext-maint/gnome-pilot-conduits/trunk/?op=log I propose to change gnome-pilot to build libgnome-pilot5_2.32.0-1 which will have to go through NEW. Are there any problems with this mini-transition if gnome-pilot-conduits is not uploaded until gnome-pilot has cleared NEW? (Neither package can migrate without the other as migrating new gnome-pilot will break installations of existing gnome-pilot-conduits.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpDevNjH6ZkE.pgp Description: PGP signature
Bug#610126: RM: chef/0.8.16-4.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm I'm also filing an RM request for ohai due to RC bug 596351. chef is a reverse dependency which needs to be removed at the same time. Please remove chef from testing. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596351#60 -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20110115150123.25881.29009.reportbug@dwarf
Bug#610127: RM: ohai/0.5.6-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596351#60 Please remove ohai from testing (similar bug filed to remove chef as well). -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20110115150306.26186.14784.reportbug@dwarf
Re: Bug#609605: gpdftext: incompatible licenses: GPL-3+/GPL-2
On Mon, 10 Jan 2011 23:09:42 +0100 Jakub Wilk jw...@debian.org wrote: Package: gpdftext Version: 0.1.1-1 Severity: serious gpdftext is licensed under GPLv3+, but it is linked to poppler which is GPLv2-only. These two licenses are incompatible. Now that I come to check, libgtkspell0 is also GPL-2 only. :-( All the code in gpdftext itself is my own and I can relicence to GPL-2only but it will mean a new upstream release to clarify each source code file and replacing COPYING. I can sort this out over the weekend, if the RT agree to a new upstream release (with only the licence changes). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpQCPtqlzO8q.pgp Description: PGP signature
Removing ohai and chef?
On Sat, 25 Dec 2010 21:53:40 +0100 Julien Cristau wrote: On Sun, Dec 19, 2010 at 17:16:46 +, Chris Butler wrote: If it's any use, I ran a quick git bisect on the upstream source, and discovered the commit which seems to have fixed the problem: https://github.com/flori/json/commit/dd06e48aa414674f52e81f9cdc7836b6456c04f8 However, this doesn't apply cleanly to v1.1.9, as it seems the code is now using a different string buffer implementation for its result. I've not looked much further to see how easy it would be to backport the change (it may not be too difficult if the two string buffer implementations have similar APIs). Is there any chance you could do that? :) Bearing in mind Chris' previous comment: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596351#40 If the above is not possible, I return to my previous suggestion of removing ohai chef from squeeze. Once wheezy is up and running, there should be no problem getting the new libjson-ruby package in. There's always the option of providing packages via backports.debian.org once squeeze is released. Personally, I'd say it's time for a pair of RM bugs to be filed at release.debian.org to remove ohai and chef from Squeeze. This bug doesn't warrant blocking Squeeze. I'll file those two tomorrow unless someone comes up with a patch for ohai (or the release team decide to add the hints anyway). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpLVPvIcQBWP.pgp Description: PGP signature
Bug#609252: RM: osso-gwconnect/1.0.12.debian-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm I haven't got a way of testing the package once built and nobody has offered test results. Julien noted that the package should be removed, however that message went against a different bug report: usertag 545625 squeeze-will-remove http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593049#52 The RC bug against osso-gwconnect is 593049 So filing an RM request for the version in testing myself. -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) 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/20110107191621.5758.79577.report...@dwarf.codehelp
Re: Bug#608347: lowering severity
severity 608347 minor
quit
On Thu, 30 Dec 2010 15:55:24 -0800
Jorge Moraleda jorge.moral...@gmail.com wrote:
1) For source code we will use one of the examples that come with the
library. To obtain the example install package tbb-examples.
I was looking for a standalone C file to be used as a test case, as
originally requested, to just pass directly to gcc.
The correct test for a -dbg package would be:
$ gcc -g -o test -ltbb test.c
$ ./test
$ gdb ./test
Then generate a seg fault in test.c or set a breakpoint and make sure
that gdb shows the correct output.
Something similar to this test for libglib2.0-0-dbg:
#include glib.h
int main (void) {
GError * err = NULL;
GHashTable * tbl = g_hash_table_new (g_direct_hash, g_direct_equal);
g_print (%s\n, err-message);
g_print (test program is ok\n);
return 0;
}
Build with debug symbols ( -g ):
$ gcc -g -o test -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lglib-2.0
test.c
Deliberate dereference of a NULL causes the expected seg fault:
$ gdb ./test
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x0040072b in main () at test.c:6
6 g_print (%s\n, err-message);
(gdb) p tbl
$1 = (GHashTable *) 0x602000
(gdb) p *tbl
$2 = {size = 8, mod = 7, mask = 7, nnodes = 0, noccupied = 0,
nodes = 0x601d20, hash_func = 0x400610 g_direct_h...@plt,
key_equal_func = 0x4005d0 g_direct_eq...@plt, ref_count = 1, version = 0,
key_destroy_func = 0, value_destroy_func = 0}
Without the libglib2.0-0-dbg package, the *tbl symbol can't be resolved
- that's what the -dbg package is gives you.
3) The README.debian file now calls to execute make to build all
examples.
That's a separate bug. It doesn't affect the -dbg package which is
meant for a different purpose. IMHO it may be better for the examples
package to omit the Makefiles completely or document clearly that the
supplied Makefiles are only examples too and you need to use the
example source code in your own projects with your own make config.
Unfortunately the Makefiles shipped with the examples have
not been debianized, so they will fail because the directory
structure in debian is not the same one that you get when you install
directly from http://www.threadingbuildingblocks.org/file.php?fid=77,
Distribution setups differing from upstream is not a bug. Your build
needs to compensate.
which is what the current Makefiles expect (this is a separate bug
that should be filed against package tbb-examples), so instead, we
will fix the Makefile for one of the examples:
That's the probable source of this bug. The way to actually use the -dbg
package would be in gdb, not make itself. The code causes the seg
fault, the -dbg package merely gives you information about the symbols
involved. (The /usr/lib/debug/usr/lib/libtbb.so.2 is just a version of
libtbb.so.2 which retains the debugging symbols by not being stripped
before packaging.)
Make the examples where they are in a local build but don't install
anywhere. Then run the examples under gdb and let gdb pick up the
symbols - ensure that the example code is linked against
the /usr/lib/libtbb.so.2 library for
the /usr/lib/debug/usr/lib/libtbb.so.2 symbols to be used correctly.
All you've demonstrated is that a hacky implemetation of a local build
system has problems when built with particular arguments to make. No
surprise there.
5) Now the debug version:
make clean
make debug
./tachyon.tbb
We get a Segmentation fault
To use the -dbg package in the way that it is prepared within Debian,
you would be running the *normal* build of tachyon.tbb, linked
against /usr/lib/ (not a local dir) under gdb.
My guess is that the libraries in debug mode need to be compiled with
some switch in g++ but unfortunately I don't know what it is.
No, it sounds like your hacked Make configuration is simply bust and
trying to link against things in the wrong way (hence complaints about
relocate). Nothing to do with the -dbg package.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpzXf5pTvw3I.pgp
Description: PGP signature
Re: Bug#608347: libtbb2-dbg: Segfault at _dl_relocate_object() dl-reloc.c:242 0x00007ffff7de9b03
On Wed, 29 Dec 2010 22:06:52 -0500 Roberto C. Sánchez robe...@connexer.com wrote: I am curious as to whether the release team thinks that #608347 (quoted below) is really RC. Do I need to target the fix for this to go into Squeeze? I've tried a simple test program to replicate the results but I don't know enough about the library to get it to compile. Is there a snippet of C code which can be compiled with a simple: $ gcc -o test -ltbb test.c ? (Preferably a sample which just #include's the appropriate headers and doesn't have to initialise too much other stuff.) It doesn't seem fair to seek judgement on the importance of the bug report without being able to reproduce the problem or find out whether the problem actually exists on other systems than that of the submitter. When linking against the tbb debug libraries from the package, a segmentation fault occurs at initialization time: It would be very useful to have a test case piece of code from the original use case too. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp1MFuPPwfnC.pgp Description: PGP signature
Re: Bug#594150: downgrading on advice from upstream
severity 594150 important tag 594150 fixed-upstream thanks On Tue, 21 Dec 2010 23:25:47 +0530 Ramakrishnan Muthukrishnan rkrish...@debian.org wrote: On Tue, Dec 21, 2010 at 5:27 AM, Neil Williams codeh...@debian.org wrote: I'm still dubious about this whole bug/patch - especially that this entire process has been only tested against a single setup, the bug only shows up in a single frontend and the bug has not had any input from the maintainer who has been otherwise active with uploads and fixes. I didn't respond to this bug because I don't really know curl or apt internals enough to respond to it. I generally either raise such things to upstream. Daniel Stenberg (the curl upstream author) had been very kind enough to respond directly to many such bug reports. It was Daniel's comments which led me to doubt the fix when the test results were not clear with regard to apt-transport-https: Sun, 14 Nov 2010 12:51:34 +0100 (CET) Daniel Stenberg dan...@haxx.se wrote: This turned out to be a minor bug in curl, yes, and I've fixed it upstream now. BUT, I'd like to stress that the timeout problem was just a false track and it simply made the error reporting a bit confused and now with my fix curl will instead say this: [...] curl: (35) gnutls_handshake() failed: Decryption has failed. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594150#44 I do get that result with the test configuration IF the SSHv3 force option is removed and this minor bug in curl is patched. It does not mean that this bug is the proper fix for the original bug, AFAICT. I'm not going to proceed on what upstream deem a false track and which isn't providing clear information in testing. The patch is the wrong solution to the original issue filed by Johannes. Somewhere through the CVE patches which led to the original manifestation (lenny vs squeeze), apt-transport-https lost the ability to cope with the particular configuration used by the submitter. *If* there is a real bug in that situation, IMHO it is not a bug in curl itself. On this particular issue, I leave it to those of you who know apt and curl internals better than me. I guess Daniel Stenberg may be the right person to comment on this problem and comment on your patch. Thanks. I think Daniel's been clear on the problem, so I'm downgrading this bug, to important initially. Ramakrishnan, feel free to downgrade further. Johannes - please investigate the original issue further within your test setup. That comment about forcing SSHv3 looks like a good place to start. Unless the original apt-transport-https bug can be reproduced with another configuration unrelated to the current test site or some one else is able to provide some more detailed insight into this bug, I'm going to leave any curl part of this to upstream. I'm not going to make any curl upload for this bug. IMHO the bug should not be reassigned to apt-transport-https unless someone can reproduce the issue or isolate the actual problem in apt-transport-https. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpR9rr8mqXPR.pgp Description: PGP signature
Re: Possible curl t-p-u ?
On Mon, 20 Dec 2010 19:44:47 +
Adam D. Barratt a...@adam-barratt.org.uk wrote:
On Fri, 2010-12-17 at 21:29 +, Neil Williams wrote:
I've tidied up the patch which turns this silent error into a more
noisy warning but does not try to fix the underlying issue. The
patch is based on one by Johannes Ernst johannes.er...@gmail.com,
as detailed in the attached patch. (The only other change is to put
the patch into the series file *in the middle* due to problems with
the gnutls changes needing to be last.)
From the bug log, it looks like this hasn't been fixed in unstable
yet; is that correct?
Yes.
I appreciate that the unstable package won't
be able to migrate, but I'd prefer to see this fixed there as well
rather than the patch being dropped straight in to squeeze.
So two uploads? Or shall I clone this bug and mark the clone as found
in the version in sid and this one not found in sid for the maintainer
to look at the underlying problem not fixed by this patch?
I might be missing something, but this change looks wrong:
+ nonblocking?0:(int)timeout_ms?1000:timeout_ms);
If timeout_ms is non-zero, a hard-coded value of 1000 will be used;
otherwise timeout_ms will be passed, which seems to be exactly what
the change was trying to avoid?
You'd think so, so did I. After another run through the tests, it makes
absolutely no difference. Alternative code, expanded for a bit of
clarity:
int repeat = 0;
if(!nonblocking) {
repeat = ((int)timeout_ms) ? timeout_ms : 1000;
}
what = Curl_socket_ready(readfd, writefd, repeat);
With this version of the patch, apt-transport-https works just as it
does with the other version of the patch. Furthermore the change to the
client-cert described in my previous message (commenting out the force
for SSHv3) produces the same handshake error message with the patch and
the timeout message without it.
I'm still dubious about this whole bug/patch - especially that this
entire process has been only tested against a single setup, the bug
only shows up in a single frontend and the bug has not had any input
from the maintainer who has been otherwise active with uploads and
fixes.
This would appear to be a minor bug in curl [0] which either of
these patches does not fix (merely makes more noisy) and the issue
itself only affects apt-transport-https if a particular client setup is
deployed and the example config easily hides the real issue by
retaining a force setting inherited from a previous Lenny setup.
SslForceVersion SSLv3; // This is required to get it to work
// in lenny; not sure why.
Overall, maybe the best solution here is to downgrade this bug rather
than potentially confuse things further with a patch which itself
doesn't provide a clear fix for the original problem and may be based
on a poorly understood test case.
I'd like some feedback from others involved in this bug and from the RT
before downgrading. Alternatively, some kind of indication that there is
more than just one https server/cert/config combination affected by the
top-level apt-transport-https issue.
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594150#44
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpQOTOrBE6A9.pgp
Description: PGP signature
Possible curl t-p-u ?
I've tidied up the patch which turns this silent error into a more noisy warning but does not try to fix the underlying issue. The patch is based on one by Johannes Ernst johannes.er...@gmail.com, as detailed in the attached patch. (The only other change is to put the patch into the series file *in the middle* due to problems with the gnutls changes needing to be last.) #libtool no_com_err runtests_gdb art_http_scripting versioned insecure-negotiation-warning # this must be the last curl_links_with_rt gnutls curl has already had a new upstream release uploaded, so I'm building against testing (pbuilder): Source: curl Version: 7.21.0-1.1 Distribution: testing-proposed-updates Urgency: medium Maintainer: Neil Williams codeh...@debian.org Date: Fri, 17 Dec 2010 21:10:56 + Closes: 594150 Changes: curl (7.21.0-1.1) testing-proposed-updates; urgency=medium . * Non-maintainer upload. * Backport change by Johannes Ernst to Squeeze to supply a useful error message if server attempts insecure renegotiation. (Closes: #594150) * Target t-p-u because a new upstream release is in sid. If the patch works as expected (and the build passes the tests which have proved problematic on this box previously), would a t-p-u upload like this be a suitable fix for the release? I'm guessing medium here, quite happy to change that to suit release team preference. -- Neil Williams = http://www.linux.codehelp.co.uk/ insecure-negotiation-warning Description: Binary data pgpDK8z3IkKmi.pgp Description: PGP signature
test results
-cacher/ftp.us.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz
SSL connection timeout
E: Some index files failed to download, they have been ignored, or old ones
used instead.
Same results for the curl and gnutls test commands as in Squeeze (patched or
not).
More light is shed when the /etc/apt/apt.conf.d/client-cert is edited
to remove the line forcing SSHv3:
With the patched packages installed:
r...@dwarf:~# cat /etc/apt/apt.conf.d/client-cert
Acquire {
https {
Verify-Peer false;
CaPath /etc/ssl/certs;
Verify-Host false;
AllowRedirect true;
SslCert /etc/apt/client-certs/client.apt-test.aviatis.com.crt;
SslKey /etc/apt/client-certs/client.apt-test.aviatis.com.key;
}
}
r...@dwarf:~# apt-get update
Hit http://ftp.uk.debian.org testing Release.gpg
Ign http://ftp.uk.debian.org/debian/ testing/main Translation-en
Hit http://ftp.uk.debian.org testing Release
Hit http://ftp.uk.debian.org testing/main Sources/DiffIndex
Ign https://apt-test.aviatis.com squeeze Release.gpg
Hit http://ftp.uk.debian.org testing/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/
squeeze/main Translation-en
Ign https://apt-test.aviatis.com squeeze Release
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages
Err https://apt-test.aviatis.com squeeze/main amd64 Packages
gnutls_handshake() failed: Decryption has failed.
W: Failed to fetch
https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz
gnutls_handshake() failed: Decryption has failed.
E: Some index files failed to download, they have been ignored, or old ones
used instead.
handshake blamed with the patch
r...@dwarf:~# dpkg -l | grep curl
ii curl7.21.0-1.1 Get a file from
an HTTP, HTTPS or FTP server
ii libcurl37.21.0-1.1 Multi-protocol
file transfer library (OpenSSL)
ii libcurl3-gnutls 7.21.0-1.1 Multi-protocol
file transfer library (GnuTLS)
Downgrading back to Squeeze:
Setting up libcurl3 (7.21.0-1) ...
Setting up curl (7.21.0-1) ...
Setting up libcurl3-gnutls (7.21.0-1) ...
r...@dwarf:~# apt-get update
Hit http://ftp.uk.debian.org testing Release.gpg
Ign http://ftp.uk.debian.org/debian/ testing/main Translation-en
Hit http://ftp.uk.debian.org testing Release
Hit http://ftp.uk.debian.org testing/main Sources/DiffIndex
Hit http://ftp.uk.debian.org testing/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com squeeze Release.gpg
Ign https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/
squeeze/main Translation-en
Ign https://apt-test.aviatis.com squeeze Release
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages/DiffIndex
Ign https://apt-test.aviatis.com squeeze/main amd64 Packages
Err https://apt-test.aviatis.com squeeze/main amd64 Packages
SSL connection timeout
W: Failed to fetch
https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz
SSL connection timeout
E: Some index files failed to download, they have been ignored, or old ones
used instead.
timeout blamed without the patch.
So the patch certainly has the effect of making the test apt source
usable under the original test conditions and it remains unusable
without the patch or with packages from unstable but it leaves me
uncertain about how much of this is down to the specific configuration
of these test conditions. (All testing of this bug has involved this
one test configuration.)
It works but I'd be happier if someone could explain what is actually
happening and why
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpzMDdJpGCsi.pgp
Description: PGP signature
Re: 75 unreported bugs, (mostly?) fixable by rebuilding / could lintian please prevent such packages from being uploaded in future?
On Thu, 16 Dec 2010 19:20:30 +0100 Carsten Hey cars...@debian.org wrote: * Philipp Kern [2010-12-16 19:06 +0100]: On Thu, Dec 16, 2010 at 06:56:13PM +0100, Carsten Hey wrote: Could rebuilding them please be scheduled? We cannot rebuild arch:all packages without sourceful uploads. ... and as Julien pointed out, these are not RC bugs unless you can show that these packages fail to install/uninstall/purge. dpkg-reconfigure is package specific, these problems only matter when 'dpkg --configure -a' becomes broken by such bugs. This prints the non arch:all packages: Simpler to actually include the list: libaa1-dev libalogg-dev bison++ cronolog cutils cvs docbook2x fdutils fileschanged flex-old glame gperf gpm gtalk guile-cairo-dev heroes-common libhyantes-dev libccrtp-dev libiksemel-dev mboxgrep mpatrolc2 nana ncurses-hexedit ocrad opt libreadline5-dev librplay3-dev rplay-client scm teseq time trueprint tua ulog-acctd uucp xzgv yafc yiyantang zgv ocrad Sources: (38) aalib alogg bison++ cronolog cutils cvs docbook2x fdutils fileschanged flex-old glame gperf gpm gtalk guile-cairo heroes hyantesite libccrtp libiksemel mboxgrep mpatrol nana ncurses-hexedit ocrad opt readline5 rplay scm teseq time trueprint tua ulog-acctd uucp xzgv yafc yiyantang zgv -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpEqAdolmZO2.pgp Description: PGP signature
Bug#606745: unblock: libctapimkt/1.0.1-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libctapimkt Closes RC bug #606265 Source: libctapimkt Version: 1.0.1-1.1 Distribution: unstable Urgency: low Maintainer: Neil Williams codeh...@debian.org Date: Tue, 07 Dec 2010 21:37:22 + Closes: 606265 Changes: libctapimkt (1.0.1-1.1) unstable; urgency=low . * Non-maintainer upload. * Move include files from libctapimkt0-dev into a subdirectory. (Closes: #606265) Files in second .changes but not in first - -rw-r--r-- root/root /usr/include/ctapimkt/config.h -rw-r--r-- root/root /usr/include/ctapimkt/ctapi.h Files in first .changes but not in second - -rw-r--r-- root/root /usr/include/config.h -rw-r--r-- root/root /usr/include/ctapi.h unblock libctapimkt/1.0.1-1.1 similar request for towitoko is next... -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) -- 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/20101211130747.16182.82247.report...@dwarf.codehelp
Bug#606746: unblock: towitoko/2.0.7-8.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package towitoko Closes RC bug #557495 Source: towitoko Version: 2.0.7-8.2 Distribution: unstable Urgency: low Maintainer: Neil Williams codeh...@debian.org Date: Tue, 07 Dec 2010 21:29:39 + Closes: 557495 Changes: towitoko (2.0.7-8.2) unstable; urgency=low . * Non-maintainer upload. * Move libtowitoko-dev headers to sub-directory (Closes: #557495) Files in second .changes but not in first - -rw-r--r-- root/root /usr/include/towitoko/ctapi.h -rw-r--r-- root/root /usr/include/towitoko/ctbcs.h Files in first .changes but not in second - -rw-r--r-- root/root /usr/include/ctapi.h -rw-r--r-- root/root /usr/include/ctbcs.h unblock towitoko/2.0.7-8.2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) -- 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/20101211131057.17341.36412.report...@dwarf.codehelp
Bug#606747: unblock: emdebian-grip/2.2.7+i18n
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package emdebian-grip
This is an update of an existing exception to include more translation
updates.
Source: emdebian-grip
Version: 2.2.7+i18n
Distribution: unstable
Urgency: low
Maintainer: Neil Williams codeh...@debian.org
Date: Wed, 01 Dec 2010 19:40:19 +
Closes: 602332 605139
Changes:
emdebian-grip (2.2.7+i18n) unstable; urgency=low
.
* [INTL:fr] French translation (manpages) (Closes: #605139)
* [INTL:ca] update catalonian translation (Closes: #602332)
* Backport the German manpage translation.
* Fix some bugs in genmanpages to ensure all translated manpages are
packaged.
debian/changelog | 10
doc/genmanpages | 20
doc/po/de.po | 6312
+++
doc/po/emdebian-grip.pot |2
doc/po/fr.po | 1040 +++
po/ca.po | 206 -
po/emdebian-grip.pot |2
7 files changed, 6935 insertions(+), 657 deletions(-)
Files in second .changes but not in first
-
-rw-r--r-- root/root /usr/share/man/de/man1/apt-grip.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/dh_gentdeb.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/dpkg-gentdeb.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/em_autogrip.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/em_installtdeb.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/emgrip-build.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/emgrip-dumpsingle.pl.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/emgrip-dupes.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/emgrip-edos.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/emgrip-remove.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/emgrip.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/grip-cron.sh.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/grip-overridearch.pl.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/grip-overridereplace.pl.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/splitout_tdeb.1.gz
-rw-r--r-- root/root /usr/share/man/de/man3/Debian::Packages::Compare.3.gz
-rw-r--r-- root/root /usr/share/man/de/man3/Emdebian::Grip.3.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/dh_gentdeb.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/dpkg-gentdeb.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/em_autogrip.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/emgrip-dumpsingle.pl.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/emgrip-dupes.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/emgrip-remove.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/emgrip.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/grip-overridearch.pl.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/grip-overridereplace.pl.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/splitout_tdeb.1.gz
Control files of package emdebian-grip: lines which differ (wdiff format)
-
Installed-Size: [-264-] {+308+}
Version: [-2.2.7-] {+2.2.7+i18n+}
Control files of package emdebian-grip-server: lines which differ (wdiff
format)
Depends: perl, debhelper, devscripts, dpkg-dev, emdebian-grip, edos-debcheck,
emdebian-tdeb, reprepro (= 3.5.2), libdebian-packages-compare-perl (=
[-2.2.7),-] {+2.2.7+i18n),+} liblocale-gettext-perl, libwww-perl
Installed-Size: [-400-] {+488+}
Version: [-2.2.7-] {+2.2.7+i18n+}
Control files of package emdebian-tdeb: lines which differ (wdiff format)
-
Installed-Size: [-204-] {+268+}
Version: [-2.2.7-] {+2.2.7+i18n+}
Control files of package libdebian-packages-compare-perl: lines which differ
(wdiff format)
---
Installed-Size: [-100-] {+116+}
unblock emdebian-grip/2.2.7+i18n
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
--
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/20101211131507.17658.52986.report...@dwarf.codehelp
Bug#603451: RM: bsc/2.27-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm In the absence of any progress on the RC bug (#597375 data loss if move is cancelled), despite pings, bsc should removed from Squeeze. If there is a fix, it can go into unstable or if no news in another month, bsc can be removed from unstable too. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20101114085847.20317.5628.report...@dwarf.codehelp
Bug#603399: RM: gpib/3.2.11-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm gpib already has a FTFBS (#577321) (open since 2009) and the gpib-modules-source package also fails to build a module (bug #550932). I agree with the comments in 577321, this package should be removed from Squeeze. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20101113181139.27572.858.report...@dwarf.codehelp
Bug#601943: unblock: emdebian-crush/2.2.5.1
On Sun, 31 Oct 2010 09:04:43 +
Neil Williams codeh...@debian.org wrote:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package emdebian-crush @ 2.2.5.1
As part of the fix for #540341 (and, in turn, #591457),
emdebian-crush 2.2.5.1 drops the dependency on apt-cross by removing
the emchain tool which is already deprecated in Emdebian. The package
also includes a fix for the internationalisation
of pdebuild-cross, ported from version 2.2.6 which is targeting
experimental.
Attaching the relevant debdiff info.
Let's try that again. (Not going well, this one - should have
checked what reportbug actually attached.)
Attaching the debdiff info from this version, not the last.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
bash/emdebian-crush | 29 -
buildd/pdebuild-cross |2 +-
buildd/pdebuild-cross-create |4 ++--
buildd/pdebuild-cross-update |6 +++---
debian/NEWS | 16
debian/changelog |8
debian/control|3 +--
debian/emdebian-crush.install |1 -
doc/po/emdebian-crush.pot |2 +-
po/pdebuild-cross.pot |2 +-
10 files changed, 33 insertions(+), 40 deletions(-)
diff -Nru emdebian-crush-2.2.5/bash/emdebian-crush emdebian-crush-2.2.5.1/bash/emdebian-crush
--- emdebian-crush-2.2.5/bash/emdebian-crush 2010-05-30 16:14:01.0 +0100
+++ emdebian-crush-2.2.5.1/bash/emdebian-crush 2010-10-30 20:39:01.0 +0100
@@ -17,35 +17,6 @@
#
# Remember to always put a space at the end of a line of options.
-_get_dpkg_cross_list()
-{
- grep Choices: /var/lib/dpkg/info/dpkg-cross.templates \
- | cut -d':' -f2 | sed -e 's/None, //' | sed -e 's/,//g'
-}
-
-_emchain()
-{
- local cur prev opts cmds help arch quiet
- COMPREPLY=()
- cur=${COMP_WORDS[COMP_CWORD]}
- prev=${COMP_WORDS[COMP_CWORD-1]}
- help=-h -? --help --version
- cmds=-f --force -i --ignore -u --uclibc
- arch=-a --arch
- quiet=--verbose --quiet -v -q
- opts=-w --workdir -l --log
- help=-h -? --help --version
- case $prev in
- -@(a|-arch))
- COMPREPLY=( $( _get_dpkg_cross_list $cur ) )
- ;;
- *)
- COMPREPLY=( $(compgen -W ${arch}${help}${opts}${quiet}${cmds} -- ${cur}) )
- ;;
- esac
-}
-complete -F _emchain -o default emchain
-
_emvendor()
{
local cur prev help cmds
diff -Nru emdebian-crush-2.2.5/buildd/pdebuild-cross emdebian-crush-2.2.5.1/buildd/pdebuild-cross
--- emdebian-crush-2.2.5/buildd/pdebuild-cross 2010-09-25 11:14:22.0 +0100
+++ emdebian-crush-2.2.5.1/buildd/pdebuild-cross 2010-10-30 20:09:33.0 +0100
@@ -24,7 +24,7 @@
export TEXTDOMAINDIR
# use parsechangelog to ensure we're in a debian source tree
if ! dpkg-parsechangelog /dev/null 21 ; then
- echo gettext You must run this from inside a debian source tree (debian/changelog not found)
+ eval_gettext You must run this from inside a debian source tree (debian/changelog not found); echo
fi
cfg=/etc/pdebuild-cross/pdebuild-cross.rc
diff -Nru emdebian-crush-2.2.5/buildd/pdebuild-cross-create emdebian-crush-2.2.5.1/buildd/pdebuild-cross-create
--- emdebian-crush-2.2.5/buildd/pdebuild-cross-create 2010-09-25 11:14:22.0 +0100
+++ emdebian-crush-2.2.5.1/buildd/pdebuild-cross-create 2010-10-30 20:09:14.0 +0100
@@ -36,8 +36,8 @@
fi
if [ -f $BASETGZ ]; then
- eval_gettext \$BASETGZ exists! If you want to create a new one, delete or move '\$BASETGZ'.
- echo gettext Otherwise, use 'pbuilder login --configfile /etc/pdebuild-cross/pdebuild-cross.rc --save-after-login'
+ eval_gettext \$BASETGZ exists! If you want to create a new one, delete or move '\$BASETGZ'.; echo
+ eval_gettext Otherwise, use 'pbuilder login --configfile /etc/pdebuild-cross/pdebuild-cross.rc --save-after-login'; echo
eval_gettext to make changes within the existing \$BASETGZ.; echo
exit 3
fi
diff -Nru emdebian-crush-2.2.5/buildd/pdebuild-cross-update emdebian-crush-2.2.5.1/buildd/pdebuild-cross-update
--- emdebian-crush-2.2.5/buildd/pdebuild-cross-update 2010-09-25 11:14:22.0 +0100
+++ emdebian-crush-2.2.5.1/buildd/pdebuild-cross-update 2010-10-30 20:08:58.0 +0100
@@ -34,10 +34,10 @@
fi
if [ ! -f $BASETGZ ]; then
- echo gettext Need to create a new pbuilder crossbuilding chroot first.
- echo gettext Use pdebuild-cross-create to create one.
+ eval_gettext Need to create a new pbuilder crossbuilding chroot first.; echo
+ eval_gettext Use pdebuild-cross-create to create one.; echo
exit 2
fi
-echo gettext Enter your sudo password if prompted
+eval_gettext Enter your sudo password if prompted; echo
sudo pbuilder update --configfile $cfg
diff -Nru emdebian-crush-2.2.5/debian/changelog emdebian-crush-2.2.5.1/debian/changelog
--- emdebian-crush-2.2.5/debian/changelog 2010-09-25 11:14:22.0 +0100
+++ emdebian
Bug#540341: RM: apt-cross/0.13.4
On Sat, 30 Oct 2010 19:10:04 +0100 Adam D. Barratt a...@adam-barratt.org.uk wrote: tags 540341 + moreinfo thanks On Sat, 2010-10-30 at 14:36 +0100, Neil Williams wrote: I'd like to ask for apt-cross to be removed from Squeeze to fix the RC bug #591457 and a long standing bug, #502433 which, together with other internal issues, make apt-cross unsuitable for release alongside the version of apt already in Squeeze. Checking reverse dependencies... # Broken Depends: emdebian-crush: emdebian-crush We can remove apt-cross if that's what you want, but either emdebian-crush will need to be removed as well, or it'll need to stop depending on apt-cross (I'm not sure how practical that is). Bah. My bad. A new version of emdebian-crush which does not depend on apt-cross is in NEW awaiting experimental because that depends on the new xapt package. As outlined on IRC, I'll upload a version of the emdebian-crush source package which drops the relevant scripts from the emdebian-crush binary package so that apt-cross dependency can be dropped. That version can then go into unstable, I'll ask for a freeze exception and it can migrate, allowing apt-cross to be removed. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp6Ftnw0w53I.pgp Description: PGP signature
apt-cross and xapt
without a way of installing cross dependencies for users using toolchains other than those from Emdebian. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpw92ydp9xit.pgp Description: PGP signature
Re: Choosing a stable+2 release name BEFORE the freeze
On Wed, 06 Oct 2010 00:09:06 +0800 Thomas Goirand z...@debian.org wrote: Philipp Kern wrote: On Tue, Oct 05, 2010 at 05:10:30PM +0800, Thomas Goirand wrote: So, my request is quite simple. Could the name for the release after Wheezy be chosen when Squeeze is release? Nah. And it's not that likely that you could do something useful with it anyway. (Given that we don't support skipping releases and it's possible that you cannot debootstrap the new one with an environment two versions earlier.) Indeed. Nobody can test any packages with Wheezy - as Wheezy will be when it is actually available - so how can it possibly be safe to put a frozen version into a stable release when the target of that version is not even testable? August, Squeeze isn't frozen, in my DTC-Xen, you can choose, as a debootstrap option: Etch, Lenny, Squeeze. I can't have wheezy, because I don't know it's name yet. July, Squeeze is frozen, DTC-Xen is in it, but it wont be able to setup Wheezy. So I had to add it, and ask the release team to accept a change in my package, just in order to add the new name. There was no other way so that the version in stable knows how to install the testing distribution with debootstrap. So yes, I couldn't do anything with the name, except ... have it stored in my package in SID to prepare the future, so that my package in stable can debootstrap stable+1. I understand how this could be thought of as helping with things like debootstrap, multistrap and others but can you really be certain that the version of your package in Squeeze is really going to work with Wheezy? Most of these packages go backwards in time, not forwards. We can test that previous releases work with the tools - future releases are likely to break stuff and you may well need new options or new behaviour to work with future releases. Certainly had this problem with multistrap - apt 0.8.x was updated during the freeze and broke many patterns of previous behaviour and led to a lot of work to get multistrap in Squeeze to even work with Squeeze, let alone Wheezy. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpwHwfb8YcAT.pgp Description: PGP signature
Bug#599214: unblock: multistrap/2.1.7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package multistrap Approval request prior to upload: http://lists.debian.org/debian-release/2010/10/msg00070.html The upload has now been made, please unblock multistrap/2.1.7 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) 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/20101005182503.3791.57054.report...@dwarf.codehelp
Re: multistrap l10n and important bug freeze exception request
On Sun, 03 Oct 2010 16:44:22 +0200 Felipe Augusto van de Wiel (faw) f...@funlabs.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02-10-2010 20:03, Neil Williams wrote: [...] Please let me know if this change is acceptable for a freeze exception - if so, I'll upload multistrap 2.1.7 to unstable tomorrow and 2.1.8 to experimental afterwards. Please, upload. :) Thanks. Uploaded. And are you sure that 2.1.8 is not suitable for Squeeze? The changes in 2.1.8 are aimed at Ubuntu support / flat file archives and I've got some remaining issues to solve in 2.1.8 yet. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpjzEn8R7gUO.pgp Description: PGP signature
multistrap l10n and important bug freeze exception request
I've now got all the l10n updates for multistrap (program output and
manpages) and I'm ready to upload 2.1.7 to unstable.
This upload also fixes one important bug and one GPL-compliance issue:
Source: multistrap
Version: 2.1.7
Distribution: unstable
Urgency: low
Maintainer: Neil Williams codeh...@debian.org
Date: Sat, 02 Oct 2010 16:27:01 +0100
Closes: 595017 595308 595391 597144 597385 597505 598476
Changes:
multistrap (2.1.7) unstable; urgency=low
.
* Add all packages to the source dir, including calculated
dependencies.
* [INTL:pt] Updated Portuguese translation for manpages
(Closes: #595308)
* [INTL:da] Danish translation of multistrap (Closes: #595391)
* [INTL:pt] Updated Portuguese translation for program messages
(Closes: #597144)
* [INTL:fr] French manpage translation (Closes: #597385)
* [INTL:de] german manpage translation (Closes: #597505)
* [INTL:vi] Vietnamese program translation update (Closes: #598476)
* Pre-handle keyring packages using GPG for use with apt = 0.8
(Closes: #595017)
I'm attaching the debdiff output and diffstat.
The debdiff of the .dsc (release.diff) has had all the l10n changes
removed (else it's 200kb)
The GPL-compliance issue is that the old --source-dir behaviour only
downloaded the source for specified packages, not the dependencies of
those packages, despite those dependencies being installed (and
therefore the rootfs had incomplete sources). (This involved preparing
an array of all the packages and passing that array to apt-get source
instead of the original list.)
The important bug fix allows multistrap to work with the changes in apt
during the release freeze (0.8.2 and later) which has radically changed
the SecureApt behaviour of apt 0.7.x The patch in the package is
slightly modified from the one in the bug report. (The fix involves
downloading the specified keyring packages in advance of the main
download, unpack and then process using the external gpg executable.)
Please let me know if this change is acceptable for a freeze exception
- if so, I'll upload multistrap 2.1.7 to unstable tomorrow and 2.1.8 to
experimental afterwards.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .changes but not in first
-
-rw-r--r-- root/root /usr/share/man/de/man1/device-table.pl.1.gz
-rw-r--r-- root/root /usr/share/man/de/man1/multistrap.1.gz
-rw-r--r-- root/root /usr/share/man/fr/man1/device-table.pl.1.gz
-rw-r--r-- root/root /usr/share/man/pt/man1/device-table.pl.1.gz
Control files: lines which differ (wdiff format)
Installed-Size: [-340-] {+404+}
Version: [-2.1.6-] {+2.1.7+}
debian/changelog | 17
doc/po/de.po | 1447 ++
doc/po/fr.po | 491
doc/po/multistrap.pot |7
doc/po/pt.po | 325 ++-
doc/po4a.config |2
multistrap| 50 +
po/da.po | 235
po/fr.po | 364 ++--
po/multistrap.pot | 130 ++--
po/pt.po | 275 -
po/vi.po | 251
pod/multistrap|2
13 files changed, 2584 insertions(+), 1012 deletions(-)
diff -Nru multistrap-2.1.6/debian/changelog multistrap-2.1.7/debian/changelog
--- multistrap-2.1.6/debian/changelog 2010-07-28 19:30:25.0 +0100
+++ multistrap-2.1.7/debian/changelog 2010-10-02 16:27:52.0 +0100
@@ -1,3 +1,20 @@
+multistrap (2.1.7) unstable; urgency=low
+
+ * Add all packages to the source dir, including calculated
+dependencies.
+ * [INTL:pt] Updated Portuguese translation for manpages
+(Closes: #595308)
+ * [INTL:da] Danish translation of multistrap (Closes: #595391)
+ * [INTL:pt] Updated Portuguese translation for program messages
+(Closes: #597144)
+ * [INTL:fr] French manpage translation (Closes: #597385)
+ * [INTL:de] german manpage translation (Closes: #597505)
+ * [INTL:vi] Vietnamese program translation update (Closes: #598476)
+ * Pre-handle keyring packages using GPG for use with apt = 0.8
+(Closes: #595017)
+
+ -- Neil Williams codeh...@debian.org Sat, 02 Oct 2010 16:27:01 +0100
+
multistrap (2.1.6) unstable; urgency=low
* [INTL:fr] French manpage translation update (Closes: #584679)
diff -Nru multistrap-2.1.6/doc/po4a.config multistrap-2.1.7/doc/po4a.config
--- multistrap-2.1.6/doc/po4a.config 2010-07-28 19:34:37.0 +0100
+++ multistrap-2.1.7/doc/po4a.config 2010-10-02 18:23:45.0 +0100
@@ -1,4 +1,4 @@
-[po4a_langs] fr pt
+[po4a_langs] de fr pt
[po4a_paths] doc/po/multistrap.pot $lang:doc/po/$lang.po
[type:pod] pod/multistrap $lang:doc/pod/1/$lang/multistrap
[type:pod] device-table.pl
Re: Freeze exception request for xfsprogs-3.1.3
unarchive 553875 reopen 553875 found 553875 3.1.3 quit On Thu, 30 Sep 2010 14:19:25 +1000 (EST) Nathan Scott nath...@debian.org wrote: - Christian PERRIER bubu...@debian.org wrote: Quoting Nathan Scott (nath...@debian.org): While at it, may you consider #144876? Its not relevent here, where we're discussing fixing actual bugs, and should definately not change at this stage (if at all, and I remain unconvinced). The readline dependency has also been reverted. Re-opening the affected bug. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpZ3mc8xLEjI.pgp Description: PGP signature
Re: freeze exception request for svn-buildpackage l10n update
On Sat, 25 Sep 2010 17:29:21 +0100 Adam D. Barratt a...@adam-barratt.org.uk wrote: On Sat, 2010-09-25 at 17:15 +0100, Neil Williams wrote: Documentation and translation update: Unblocked. Sadly, 5 days after the l10n deadline passed, 4 days after the upload and unblock, I've received an updated translation with apologies from the translator who couldn't get it done any earlier (but didn't tell me). I'm not expecting any other translations for svn-bp. So, I've needed to upload 0.8.3 to close #598478. Could the hint be updated please? Source: svn-buildpackage Version: 0.8.3 Distribution: unstable Urgency: low Maintainer: Neil Williams codeh...@debian.org Date: Wed, 29 Sep 2010 17:15:25 +0100 Closes: 598478 Changes: svn-buildpackage (0.8.3) unstable; urgency=low . * [INTL:vi] Vietnamese program translation update (Closes: #598478) http://packages.qa.debian.org/s/svn-buildpackage/news/20100929T174714Z.html -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpYCezchkl2g.pgp Description: PGP signature
Re: emdebian-crush freeze exception
On Sat, 25 Sep 2010 11:29:51 +0100 Neil Williams codeh...@debian.org wrote: Oops, forgot the changelog: Source: emdebian-crush Version: 2.2.5 Distribution: unstable Urgency: low Maintainer: Neil Williams codeh...@debian.org Date: Wed, 08 Sep 2010 23:08:38 +0100 Closes: 595804 596008 596088 596148 Changes: emdebian-crush (2.2.5) unstable; urgency=low . * [i18n] Add French program translation (Closes: #595804) * Fix build system to put the translation files in the correct place. * [INTL:da] Danish translation of emdebian-crush. (Closes: #596008) * [INTL:ru] Russian program translation (Closes: #596088) * [INTL:pt] Portuguese translation for program messages (Closes: #596148) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpH6J4V6E7gS.pgp Description: PGP signature
