Bug#1036737: libsoapysdr0.8: please add Breaks: libsoapysdr0.7 for smoother upgrades from bullseye
severity 1036737 normal tags 1036737 - patch thanks [resend just to the bug because it was still archived before] On Thu, May 25, 2023 at 03:08:22AM +0200, Andreas Beckmann wrote: > The soapysdr library stacks from bullseye and bookworm are not > co-installable, but the transitive conflict behind longer dependency > chains is not always easy detectable by apt. Therefore several upgrade > paths result in old libraries being kept installed and some upgradable > packages being kept at an older version. It is unfortunate that I neglected the package at that time and did not look at the underlying issue. I reverted the Breaks added in the team upload now, in any case. The SoapySDR library and module packages are designed to be co-installable across SONAME versions and if something prevents that it is an issue that needs fixing. Could you tell me what the specific issue was that prevented co-installation?
Bug#987528: closed by Debian FTP Masters
On Sun, Apr 25, 2021 at 11:39:51PM +0300, Adrian Bunk wrote: > Control: reopen -1 > Control: tags -1 ftbfs > > On Sun, Apr 25, 2021 at 07:06:25PM +, Debian Bug Tracking System wrote: > >... > > ghdl (1.0.0+dfsg-2) unstable; urgency=medium > > . > >* Add Built-Using field to ghdl-gcc to record use of gcc source package > > (Closes: 987528) > >... > > ghdl-gcc needs a Built-Using for gcc: > > https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using > > Built-Using: gcc-10-source (= 10.2.1-6) > > This is wrong and resulted in REJECT by dak, Built-Using must record the > name and version of the *source* package gcc-10 (= 10.2.1-6). Ugh, didn't pay enough attention to the details. Will fix in a moment.
Bug#981576: ghdl-common: missing Breaks+Replaces: ghdl (<< 0.37+dfsg2)
On Mon, Feb 01, 2021 at 06:20:18PM +0100, Andreas Beckmann wrote: > From the attached log (scroll to the bottom...): > > Preparing to unpack .../ghdl-common_0.37+dfsg2-1_amd64.deb ... > Unpacking ghdl-common (0.37+dfsg2-1) ... > dpkg: error processing archive > /var/cache/apt/archives/ghdl-common_0.37+dfsg2-1_amd64.deb (--unpack): >trying to overwrite '/usr/bin/ghdl', which is also in package ghdl:amd64 > 0.37+dfsg-3 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > Errors were encountered while processing: >/var/cache/apt/archives/ghdl-common_0.37+dfsg2-1_amd64.deb Ah, I didn't notice that as I haven't tried installing ghdl-common on its own with the older ghdl packages installed. > BTW, did you really intend to move /usr/bin/ghdl to the -common package? > That's rather unusual. > (But you need the B+R also for splitting out the /usr/lib bits to -common.) /usr/bin/ghdl is a shell script that selects one of the installed ghdl variants and executes that, and it can be influenced by an environment variable. In hindsight, I could have let /usr/bin/ghdl be handled by the alternatives system and let users select a non-default ghdl by executing the desired executable (ghdl-mcode, ghdl-gcc or ghdl-llvm) directly. But as it is now it is in -common so that every ghdl installation also provides /usr/bin/ghdl.
Bug#939561: soapybladerf ftbfs in unstable
On Thu, Sep 12, 2019 at 04:42:53PM +0100, peter green wrote: > tags 939561 +fixed-upstream > tags 939561 +patch > thanks > > Some googling revealed that upstream had fixed this issue > https://github.com/pothosware/SoapyBladeRF/pull/19 . I was able to take the > upstream pull request, turn it into a patch series and apply it to the Debian > package. > > I have uploaded my fix to raspbian, a debdiff can be found at > http://debdiffs.raspbian.org/main/s/soapybladerf/soapybladerf_0.3.5-1+rpi1.debdiff > , no intent to NMU in Debian. Thanks for this, I'm going to use it to upload a fixed revision of the current version to Debian. I am working on updating all soapysdr modules now, but with the ABI version change all the transitioning will take a while so this is a welcome help to cover for the time until that completes.
Bug#905522: ghdl: Incomplete debian/copyright?
On Sun, Aug 05, 2018 at 03:58:00PM +0100, Chris Lamb wrote: > Source: ghdl > Version: 0.35+git20180503+dfsg-1 > Severity: serious > Justication: Policy 12.5 > X-Debbugs-CC: Andreas Bombe , ftpmas...@debian.org, Thorsten > Alteholz > > Hi, > > I just ACCEPTed ghdl from NEW but the FTP team noticed it was missing the > entire text of the CC license. First, thanks for the ACCEPT. The missing text of the CC license was the reason the package was rejected months ago. I included the full text in debian/copyright, among many other changes that came with using a more recent upstream which changes the library organization. Is there really still something missing (and what) or is this maybe some outdated ftpmaster notes for ghdl sticking around?
Bug#871117: festival: FTBFS: /bin/sh: 1: g++-6: not found
block 871117 by 871089 thanks This problem is caused by #871089 because it is using the same configuration files for building. Changing the hardcoded g++-6 to plain g++ (in the gcc-6 patch to speech-tools) fixes the build issue. This bug should be fixed when the other bug is fixed.
Bug#853692: ufraw: diff for NMU version 0.22-1.2
Control: tags 853692 + patch
Control: tags 853692 + pending
Dear maintainer,
I've prepared an NMU for ufraw (versioned as 0.22-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru ufraw-0.22/debian/changelog ufraw-0.22/debian/changelog
--- ufraw-0.22/debian/changelog 2017-02-27 14:31:26.0 +0100
+++ ufraw-0.22/debian/changelog 2017-10-20 23:56:09.0 +0200
@@ -1,3 +1,11 @@
+ufraw (0.22-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch to avoid using abs() on unsigned values which will fail on gcc 7
+due to ambiguous overload resolution. (Closes: #853692)
+
+ -- Andreas Bombe <a...@debian.org> Fri, 20 Oct 2017 23:56:09 +0200
+
ufraw (0.22-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru ufraw-0.22/debian/patches/04_no-unsigned-abs.patch ufraw-0.22/debian/patches/04_no-unsigned-abs.patch
--- ufraw-0.22/debian/patches/04_no-unsigned-abs.patch 1970-01-01 01:00:00.0 +0100
+++ ufraw-0.22/debian/patches/04_no-unsigned-abs.patch 2017-10-20 23:53:40.0 +0200
@@ -0,0 +1,24 @@
+Description: Don't use abs() on unsigned values
+ With gcc 7, compilation will fail since the overload resolution for unsigned
+ int is ambiguous. Cast the unsigned int to int rather than removing abs(),
+ since the next if condition a few lines below points to unsigned values being
+ used as containers for signed values.
+ .
+ This is a minimal patch that doesn't change or improve the questionable code
+ on a larger scale. A proper fix should figure what is going on here and how to
+ improve it.
+Author: Andreas Bombe <a...@debian.org>
+Last-Update: 2017-10-20
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/dcraw.cc
b/dcraw.cc
+@@ -9245,7 +9245,7 @@
+ if (make[0] == 'O') {
+ i = find_green (12, 32, 1188864, 3576832);
+ c = find_green (12, 32, 2383920, 2387016);
+- if (abs(i) < abs(c)) {
++ if (abs((int)i) < abs((int)c)) {
+ SWAP(i,c);
+ load_flags = 24;
+ }
diff -Nru ufraw-0.22/debian/patches/series ufraw-0.22/debian/patches/series
--- ufraw-0.22/debian/patches/series 2017-02-27 14:30:30.0 +0100
+++ ufraw-0.22/debian/patches/series 2017-10-20 23:28:22.0 +0200
@@ -1,3 +1,4 @@
01_no-gimp-remote.patch
02_CVE-2015-8366.patch
03_fix-unsigned-char.patch
+04_no-unsigned-abs.patch
Bug#817495: hp-ppd: diff for NMU version 0.9-0.3
Control: tags 817495 + patch
Control: tags 817495 + pending
Dear maintainer,
I've prepared an NMU for hp-ppd (versioned as 0.9-0.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru hp-ppd-0.9/debian/changelog hp-ppd-0.9/debian/changelog
--- hp-ppd-0.9/debian/changelog 2011-10-05 17:25:18.0 +0200
+++ hp-ppd-0.9/debian/changelog 2016-09-24 16:27:06.0 +0200
@@ -1,3 +1,12 @@
+hp-ppd (0.9-0.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Move from debhelper compat level 4 to 9 thanks to the Ubuntu patch by Logan
+Rosen <lo...@ubuntu.com> (Closes: #817495)
+ * Increase Standards-Version to 3.9.8, no changes necessary
+
+ -- Andreas Bombe <a...@debian.org> Sat, 24 Sep 2016 16:27:06 +0200
+
hp-ppd (0.9-0.2) unstable; urgency=low
* Non-maintainer upload.
diff -Nru hp-ppd-0.9/debian/compat hp-ppd-0.9/debian/compat
--- hp-ppd-0.9/debian/compat 2006-03-29 06:54:07.0 +0200
+++ hp-ppd-0.9/debian/compat 2016-09-24 16:01:45.0 +0200
@@ -1 +1 @@
-4
+9
diff -Nru hp-ppd-0.9/debian/control hp-ppd-0.9/debian/control
--- hp-ppd-0.9/debian/control 2006-07-28 12:43:48.0 +0200
+++ hp-ppd-0.9/debian/control 2016-09-24 16:24:24.0 +0200
@@ -2,14 +2,15 @@
Section: utils
Priority: optional
Maintainer: A Mennucc1 <mennu...@debian.org>
-Build-Depends: debhelper
+Build-Depends: debhelper (>= 9)
Build-Depends-Indep: python
-Standards-Version: 3.7.2
+Standards-Version: 3.9.8
Package: hp-ppd
Architecture: all
+Depends: ${misc:Depends}
Suggests: linuxprinting.org-ppds
-Description: HP Postscript Printer Definition (PPD) files
+Description: HP Postscript Printer Definition (PPD) files
Because PostScript is just a page description language,
there is a need to provide a mechanism for a print spooler to
customize the PostScript Job to the actual printer device.
diff -Nru hp-ppd-0.9/debian/rules hp-ppd-0.9/debian/rules
--- hp-ppd-0.9/debian/rules 2008-01-28 00:17:39.0 +0100
+++ hp-ppd-0.9/debian/rules 2016-09-24 16:01:45.0 +0200
@@ -5,7 +5,9 @@
#download:
# wget -r --no-parent -A html,ppd http://www.linuxprinting.org/download/PPD/HP/
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
build-stamp:
dh_testdir
# Add here commands to compile the package.
@@ -26,7 +28,7 @@
install: build
dh_testdir
dh_testroot
- dh_clean -k
+ dh_prep
dh_installdirs
# Add here commands to install the package into debian/.
Bug#826727: anki: Anki does not start anymore
merge 826727 784612 thanks On Wed, Jun 08, 2016 at 02:08:08PM +0200, Matthias Wimmer wrote: > Package: anki > Version: 2.0.32+dfsg-1 > Severity: grave > Justification: renders package unusable > > Anki does not start anymore. When called from the command line, I get the > following traceback: > > = > Traceback (most recent call last): > File "/usr/bin/anki", line 7, in > import aqt > File "/usr/share/anki/aqt/__init__.py", line 12, in > from aqt.qt import * > File "/usr/share/anki/aqt/qt.py", line 22, in > from PyQt4.QtWebKit import QWebPage, QWebView, QWebSettings > ImportError: No module named QtWebKit > = Yes, QtWebKit was removed from the Qt4 in Debian. There is no fix other than a Qt5 port of anki.
Bug#784612: [anki] Qt4's WebKit removal
On Mon, May 30, 2016 at 02:42:19AM +0200, Nicolas Kuttler wrote: > For anybody else wondering about this, the maintainer has already > contacted upstream and they are aware of the problem, > https://anki.tenderapp.com/discussions/ankidesktop/16516 Right, until there's a Qt5 port, little can be done. I have actually experimentally ported it a while ago and ran into a few significant problems. I need to update my code to the latest upstream git and submit it for consideration. The significant problems are that it has plugins and Qt4/Qt5 don't work together in the same program. The other big problem is that the configuration is a serialized dump of some Python data and some Qt4 package name is encoded in it. Loading old configuration in the Qt5 port will make it crash. So yeah, even if I submit my port ASAP there are still some showstoppers to iron out.
Bug#798401: gdb-python2 does not actually link to python2, but python3
On Sun, May 29, 2016 at 10:59:47AM +0200, Hector Oron wrote: > Thanks very much for the fix, it just came in the right time. I am > planning to prepare a GDB release soon and I was considering on > dropping gdb-python2. However, now that there seems to be interest on > it, I'd like to know what use cases do you have for gdb-python2 and if > you really think we should release stretch with it and why. Personally, my motivation was "I'm at a bug squashing party and this looks doable". Sorry, I'm not personally invested in having a python2 variant of gdb. > > I have fixed these in the attached patch and will shortly upload a NMU > > with this fix to DELAYED/5-day. > > It is probably not needed, we (pkg-gdb team) plan to do an upstream > update and few packaging changes. Should I remove the NMU from DELAYED then? Andreas
Bug#824463: elektra: diff for NMU version 0.8.14-5.1
Control: tags 824463 + patch Control: tags 824463 + pending Dear maintainer, I've prepared an NMU for elektra (versioned as 0.8.14-5.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. diff -Nru elektra-0.8.14/debian/changelog elektra-0.8.14/debian/changelog --- elektra-0.8.14/debian/changelog 2015-12-13 20:41:17.0 +0100 +++ elektra-0.8.14/debian/changelog 2016-05-29 15:42:05.0 +0200 @@ -1,3 +1,11 @@ +elektra (0.8.14-5.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add patch to fix build failure due to missing include in kdbtimer.hpp +(Closes: #824463) + + -- Andreas Bombe <a...@debian.org> Sun, 29 May 2016 15:41:47 +0200 + elektra (0.8.14-5) unstable; urgency=medium * Replace patch lua-fix-Key-tostring.diff with upstream diff -Nru elektra-0.8.14/debian/patches/fix-missing-vector-include.diff elektra-0.8.14/debian/patches/fix-missing-vector-include.diff --- elektra-0.8.14/debian/patches/fix-missing-vector-include.diff 1970-01-01 01:00:00.0 +0100 +++ elektra-0.8.14/debian/patches/fix-missing-vector-include.diff 2016-05-29 15:35:37.0 +0200 @@ -0,0 +1,10 @@ +--- a/src/bindings/cpp/include/kdbtimer.hpp b/src/bindings/cpp/include/kdbtimer.hpp +@@ -4,6 +4,7 @@ + #include + #include + #include ++#include + + #ifdef __GNUC__ + #define TIMER_NOINLINE __attribute__((noinline)) diff -Nru elektra-0.8.14/debian/patches/series elektra-0.8.14/debian/patches/series --- elektra-0.8.14/debian/patches/series 2015-12-13 20:14:20.0 +0100 +++ elektra-0.8.14/debian/patches/series 2016-05-29 15:34:47.0 +0200 @@ -5,3 +5,4 @@ upstream_lua-fix-Key-tostring.patch upstream_bindings-fix-size-of-KEY_FLAGS-value.patch upstream_convert-hosts-switch-to-bash.patch +fix-missing-vector-include.diff
Bug#798401: gdb-python2 does not actually link to python2, but python3
On Sat, May 28, 2016 at 10:20:12AM -0700, Ben Longbons wrote: > Thanks, is there any chance you could look at the related-but-wishlist > bug 798405 while you have this package's debian/rules in your brain's > cache? The chance is rather low to be honest. Actually the bug was caused by duplicating the gdb package improperly and having a gdb-common used by (let's say) gdb-python3 and gdb-python2 may simplify things a bit. However, I am not familiar with the CDBS build system and the gdb package is a quite complex specimen at that, so I'd rather not. Fixing this particular bug was enough work. Andreas
Bug#798401: gdb-python2 does not actually link to python2, but python3
tags 798401 + patch thanks On Tue, Sep 08, 2015 at 12:59:06PM -0700, Ben Longbons wrote: > The gdb-python2 package does not actually contain a version of gdb > linked to python2. Rather, it is a byte-for-byte identical copy of the > /usr/bin/gdb shipped in the gdb package, which links to python3. > > I noticed that gdb-python2 has "Depends: libpython3.4", I presume this > is automatic from the list of linked shared libs. I have verified on snapshot.debian.org that gdb-python2 has been broken since it was introduced. Basically the python2 linked version gets built and then ignored. There were more problems such as files missing in gdb-python2. I have fixed these in the attached patch and will shortly upload a NMU with this fix to DELAYED/5-day. >From 1e932c1100e1e5af7310f88d9399a8a1839872ea Mon Sep 17 00:00:00 2001 From: Andreas Bombe <a...@debian.org> Date: Sat, 28 May 2016 16:50:01 +0200 Subject: [PATCH] Fix build of gdb-python2 package Remove the installation of the python3 gdb from gdb-python2.install and install the gdb linked against python2 in debian/rules instead. Add the installation of gcore in gdb-python2.install. Duplicate the section installing gdbinit in /etc and in /usr/bin gdb-add-index and gdbtui back to the gdb post-install target and modify the section in gdb-python2 post-install to actually install into gdb-python2. Don't install the testsuite logs of the python3 build into gdb-python2. Do the installation of the run binary and man page with install instead of mv so that the second package to be built also has them available. Closes: #798401 Signed-off-by: Andreas Bombe <a...@debian.org> --- debian/gdb-python2.install | 2 +- debian/rules | 36 ++-- 2 files changed, 23 insertions(+), 15 deletions(-) diff --git a/debian/gdb-python2.install b/debian/gdb-python2.install index 9f20418..6747d0d 100644 --- a/debian/gdb-python2.install +++ b/debian/gdb-python2.install @@ -1,2 +1,2 @@ -usr/bin/gdb +usr/bin/gcore usr/share/gdb diff --git a/debian/rules b/debian/rules index 55bb258..ebde65e 100755 --- a/debian/rules +++ b/debian/rules @@ -236,9 +236,9 @@ clean:: binary-post-install/gdb$(TS) :: if [ -x debian/tmp/usr/bin/run ]; then\ - mv debian/tmp/usr/bin/run \ + install -m 755 debian/tmp/usr/bin/run \ debian/gdb$(TS)/usr/bin/$(DEB_TARGET_ALIAS)-run; \ - mv debian/tmp/usr/share/man/man1/run.1 \ + install -m 644 debian/tmp/usr/share/man/man1/run.1 \ debian/gdb$(TS)/usr/share/man/man1/$(DEB_TARGET_ALIAS)-run.1; \ fi ifeq ($(run_tests),yes) @@ -247,29 +247,37 @@ ifeq ($(run_tests),yes) debian/gdb$(TS)/usr/share/doc/gdb/check.log endif +ifneq ($(DEB_CROSS),yes) + # Only ship a global gdbinit for the native GDB. + install -d debian/gdb$(TS)/etc/gdb + install -m 644 debian/gdbinit debian/gdb$(TS)/etc/gdb/ + # Likewise gdb-add-index + install -m 755 gdb/contrib/gdb-add-index.sh debian/gdb$(TS)/usr/bin/gdb-add-index +endif + + rm -f debian/gdb$(TS)/usr/bin/$(TP)gdbtui + install -m 755 debian/gdbtui debian/gdb$(TS)/usr/bin/$(TP)gdbtui + binary-post-install/gdb-python2$(TS) :: + install -d debian/gdb-python24$(TS)/usr/bin + install -s -m 755 $(BUILDDIRPYTHON2)/gdb/gdb debian/gdb-python2$(TS)/usr/bin/gdb if [ -x debian/tmp/usr/bin/run ]; then\ - mv debian/tmp/usr/bin/run \ + install -m 755 debian/tmp/usr/bin/run \ debian/gdb-python2$(TS)/usr/bin/$(DEB_TARGET_ALIAS)-run; \ - mv debian/tmp/usr/share/man/man1/run.1 \ + install -m 644 debian/tmp/usr/share/man/man1/run.1 \ debian/gdb-python2$(TS)/usr/share/man/man1/$(DEB_TARGET_ALIAS)-run.1; \ fi -ifeq ($(run_tests),yes) - install -d debian/gdb-python2$(TS)/usr/share/doc/gdb - install -m 644 $(DEB_BUILDDIR)/gdb/testsuite/gdb.sum \ - debian/gdb-python2$(TS)/usr/share/doc/gdb/check.log -endif ifneq ($(DEB_CROSS),yes) # Only ship a global gdbinit for the native GDB. - install -d debian/gdb$(TS)/etc/gdb - install -m 644 debian/gdbinit debian/gdb$(TS)/etc/gdb/ + install -d debian/gdb-python2$(TS)/etc/gdb + install -m 644 debian/gdbinit debian/gdb-python2$(TS)/etc/gdb/ # Likewise gdb-add-index - install -m 755 gdb/contrib/gdb-add-index.sh debian/gdb$(TS)/usr/bin/gdb-add-index + install -m 755 gdb/contrib/gdb-add-index.sh debian/gdb-python2$(TS)/usr/bin/gdb-add-index endif - rm -f debian/gdb$(TS)/usr/bin/$(TP)gdbtui - install -m 755 debian/gdbtui debian/gdb$(TS)/usr/bin/$(TP)gdbtui + rm -f debian/gdb-python2$(TS)/usr/bin/$(TP)gdbtui + install -m 755 debian/gdbtui debian/gdb-python2$(TS)/usr/bin/$(TP)gdbtui binary-post-install/gdb-multiarch :: install -d debian/gdb-multiarch/usr/bin -- 2.8.1
Bug#823881: dosfstools: mmd fails right after mkfs.msdos (sectors/tracks mismatch)
On Wed, May 11, 2016 at 05:32:17AM +0200, Cyril Brulebois wrote: > [ Poke Steve. ] > > Andreas Bombe <a...@debian.org> (2016-05-11): > > On Tue, May 10, 2016 at 02:15:42PM +0200, Andreas Bombe wrote: > > > Since 416 blocks is a rather odd value, the default is used and that has > > > changed. I think mtools is overzealous in checking those values and > > > refusing to work. Still, it probably makes sense to use 64/32 as the > > > default for smaller filesystem sizes (up to 512 MB possibly) and I'll > > > prepare a version that implements this. > > > > Uploading this now. > > > > As far as I'm concerned, I consider this an aesthetic change. There is > > still no guarantee that the total number of sectors is a multiple of > > sectors per track. It just happens to work with the current values. > > Steve → we probably don't want to be hardcoding such things in so many > places right? 3 calls in src:debian-installer, plus debian-cd, and maybe > others? In my opinion all that effort to placate mtools is the quintessential tail wagging the dog. I don't know the installer environment, but disabling those checks in /etc/mtools.conf or ~/.mtoolsrc would be the way to go. > > If you want to make this robust, you'll either have to explicitly > > specify matched size/sectors/heads on the command line to mkfs.msdos or > > disable the bogus mtools check like everyone else does when encountering > > that error. > > Thanks for your input and the proposed change. > > I think Steven mentioned (when we first diagnosed this) a possibly > bogus/overzealous check on mtools side as well. You seem to agree. So, > if this check is bogus, why not fix it/remove it upstream then? Upstream for mtools does not seem to be particularly active, last release was in 2013. The problem with this check is that it is at best a heuristic. Total sectors not being a multiple of sectors per track means that some sectors in the last track are left unused. And nobody would just waste some of the scarce space on a floppy, right? That might indicate something is fishy, but it's not an actual error. It's definitely meaningless in the linear addressing case of larger disks where the 255/63 dummy values are used. > > Seriously, searching for that error message in your favorite search > > engine will give you pages upon pages of hits, all of them describing > > how to turn it off. > > Seriously, I read the man^Winfo page and implemented a workaround in > src:debian-installer already. I didn't mean to come across as sarcastic or whatever, I just wanted to note how there are so many people affected by this while I couldn't find anyone treating it as anything but a nuisance error. So yeah, the consensus seems to be it's a bogus check. Andreas
Bug#823881: dosfstools: mmd fails right after mkfs.msdos (sectors/tracks mismatch)
On Tue, May 10, 2016 at 02:15:42PM +0200, Andreas Bombe wrote: > Since 416 blocks is a rather odd value, the default is used and that has > changed. I think mtools is overzealous in checking those values and > refusing to work. Still, it probably makes sense to use 64/32 as the > default for smaller filesystem sizes (up to 512 MB possibly) and I'll > prepare a version that implements this. Uploading this now. As far as I'm concerned, I consider this an aesthetic change. There is still no guarantee that the total number of sectors is a multiple of sectors per track. It just happens to work with the current values. If you want to make this robust, you'll either have to explicitly specify matched size/sectors/heads on the command line to mkfs.msdos or disable the bogus mtools check like everyone else does when encountering that error. Seriously, searching for that error message in your favorite search engine will give you pages upon pages of hits, all of them describing how to turn it off. Andreas
Bug#823881: dosfstools: mmd fails right after mkfs.msdos (sectors/tracks mismatch)
On Tue, May 10, 2016 at 01:53:24AM +0200, Cyril Brulebois wrote:
> The version bump from 3.0.28-2 to 4.0-1 led to a new FTBFS on all EFI
> archs for debian-installer (amd64, arm64, i386), where the following
> operations are happening:
> | + mkfs.msdos -C ./tmp/netboot-gtk/grub_efi/efi.img 416
> | mkfs.fat 4.0 (2016-05-06)
> | + mmd -i ./tmp/netboot-gtk/grub_efi/efi.img ::efi
> | Total number of sectors (832) not a multiple of sectors per track (63)!
> | Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
> | + cleanup
> | + [ -z efi-image.7vXUPq ]
> | + rm -f efi-image.7vXUPq
> | + [ -z efi-image.u4utfz ]
> | + rm -rf efi-image.u4utfz
> | config/x86.cfg:38: recipe for target 'x86_grub_efi' failed
>
> This can be reproduced with:
> | make -C build build_netboot-gtk USE_UDEBS_FROM=sid
>
> after having added "set -x" at the top of build/util/efi-image in
> src:debian-installer.
>
> After a quick look, it seems the d-i build system is only passing a
> number of blocks to mkfs.{msdos,fat}, without specifying strange
> parameters for sectors or trackers, so it looks to me that mkfs's
> or mmd's behaviour is buggy.
>
> Incidently, 832 isn't a multiple of 63, but is a multiple of 64. Could
> there be some off-by-one somewhere?
Not an off-by-one, these are constants. Unless the media parameters can
be established (by HDIO_GETGEO or FDGETPRM ioctls) a set of defaults is
used. In 4.0 (I am also upstream) I massively simplified it to basically
use the common dummy 255/63 values unless the size matches one of the
well-known floppy sizes:
https://sources.debian.net/src/dosfstools/4.0-1/src/mkfs.fat.c/#L512
Previously, it would set values based on well-known floppy sizes or use
64/32 as default if the target was either a file or the device major
number truncated to 8 bits matched 2 (floppy) or 7 (loop device) and
otherwise assume it's a hard disk device so use 255/63 if HDIO_GETGEO
fails:
https://sources.debian.net/src/dosfstools/3.0.28-2/src/mkfs.fat.c/#L512
Since 416 blocks is a rather odd value, the default is used and that has
changed. I think mtools is overzealous in checking those values and
refusing to work. Still, it probably makes sense to use 64/32 as the
default for smaller filesystem sizes (up to 512 MB possibly) and I'll
prepare a version that implements this.
Andreas
Bug#803755: texmaker: diff for NMU version 4.4.1-1.1
On Tue, Nov 24, 2015 at 08:36:23PM +0100, Andreas Tille wrote: > Would you mind commiting your changes to Debian Science svn. It has > ACLs set to grant commit permissions to any DD. Not quite correctly, it seems: | Sendingdebian/changelog | Adding debian/patches/fix-qtlocalpeer-compilation | Sendingdebian/patches/series | Transmitting file data ...done | Committing transaction... | svn: E13: Commit failed (details follow): | svn: E13: Can't create directory '/svn/debian-science/db/transactions/47186-1.txn': Permission denied Unless there's an error on my part — I haven't used svn in many years and checked this out with debcheckout --auth. Also, I assume this means it is accepted and I can move the NMU from delayed to immediate? Note, I have looked at the upstream 4.5 release and it already has the same fix. My patch needs to be dropped again when the new version gets packaged.
Bug#804840: stormbaancoureur: diff for NMU version 2.1.6-1.1
On Sun, Nov 22, 2015 at 07:38:03PM +0100, Markus Koschany wrote: > Am 22.11.2015 um 18:45 schrieb Andreas Bombe: > > Control: tags 804840 + patch > > Control: tags 804840 + pending > > > > Dear maintainer^Wgames team, > > > > I've prepared an NMU for stormbaancoureur (versioned as 2.1.6-1.1) and > > uploaded it to DELAYED/5. Please feel free to tell me if I > > should delay it longer. > > Hello Andreas, > > thank you for the RC fix. Please feel free to upload without delay. Reuploaded into normal queue, thanks.
Bug#795690: libcdio: FTBFS under some timezones (eg. GMT-14)
On Sun, Aug 16, 2015 at 10:53:55AM +0100, Chris Lamb wrote: > Source: libcdio > Version: 0.83-4.2 > Severity: serious > Justification: fails to build from source > > Dear Maintainer, > > libcdio fails to build from source on unstable/amd64 under some > timezones (eg. TZ="/usr/share/zoneinfo/Etc/GMT-14"): > > [..] > /usr/bin/make check-TESTS [...] > FAIL: testiso9660 [...] I have looked into this and there appear to be two problems. One is that the ISO9660 format, as far as I can see, still has no support for the GMT-14 time zone. It was introduced in 1995 and the limits in ISO9660 have not yet adapted, being restricted to GMT+12 and GMT-13. There probably needs to be special handling for GMT-14 to ignore test failure there as it seems inevitable. The other is that I *think* there are sign errors in the upstream time zone handling and therefore more time zones fail than should. | $ TZ=GMT+13 test/testiso9660 | ++ WARN: string 'ABC!123' is getting truncated to 2 characters | ++ WARN: Converted ISO 9660 timezone -52 is less than -48. Adjusted | $ TZ=GMT-13 test/testiso9660 | ++ WARN: string 'ABC!123' is getting truncated to 2 characters | ++ WARN: Converted ISO 9660 timezone -52 is less than -48. Adjusted | GMT offsets aren't equal. get: 46800, set 43200 | local time retrieved with iso9660_get_ltime() not | same as that set with iso9660_set_ltime(). As you can see both offsets get the westward 12 hour limit applied, probably in different functions using different signs. There are multiple time functions in lib/iso9660/iso9660.c and there is code like | #ifdef HAVE_TM_GMTOFF | /* Convert seconds to minutes */ | timezone = p_tm->tm_gmtoff / 60; | #else | timezone = (p_tm->tm_isdst > 0) ? -60 : 0; | #endif tm_gmtoff is seconds east of UTC and thus the offset to add. DST is also a positive offset but is given as a negative. The dtime function uses the sign of the passed timezone, the ltime function inverts it. Both limit the time zone value to -48 and 52. I'm not familiar with the intricacies of ISO9660 time values, but this needs a good looking over I think.
Bug#788585: dsh: overwrites host list with a symlink
severity 788585 grave block 788585 by 421344 thanks (Severity reduced to grave since the data loss does not extend beyond files associated with the package.) On Sat, Jun 13, 2015 at 01:04:58AM +0200, Christoph Anton Mitterer wrote: > Hi. > > dsh installs the file /etc/dsh/group/all as a symlink to "../machines.list". > > Since I didn't like the way that all host lists would be in /etc/dsh/group/ > and just the -a list is in /etc/dsh/machines.list I reverted that to: > - /etc/dsh/group/all being the regular file > - /etc/dsh/machines.list being the symlink to the former > > In violation of the policy, /etc/dsh/group/all is not a conffile, > thus the host list, with precious data, is removed without further > asking and installation of the package yields an error: > Setting up dsh (0.25.10-1.1) ... > dpkg: warning: dsh: config file '/etc/dsh/machines.list' is a circular link > (= > '/etc/dsh/group/../group/../group/../group/../group/../group/../group/../group/../group/../group/../group/../group/../group/all') The symlink is not marked as a conffile because debhelper (specifically dh_installdeb) does not mark symlinks to be installed in /etc as conffiles. According to #421346 this is intentional as dpkg does not work correctly with conffile symlinks (#421344, #690051). Thus the apparent fix of marking it as a conffile explicitly is likely unwise.
Bug#803755: texmaker: diff for NMU version 4.4.1-1.1
Control: tags 803755 + patch Control: tags 803755 + pending Dear maintainers, I've prepared an NMU for texmaker (versioned as 4.4.1-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. diff -Nru texmaker-4.4.1/debian/changelog texmaker-4.4.1/debian/changelog --- texmaker-4.4.1/debian/changelog 2014-12-09 20:46:15.0 +0100 +++ texmaker-4.4.1/debian/changelog 2015-11-22 19:23:09.0 +0100 @@ -1,3 +1,11 @@ +texmaker (4.4.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add patch to add missing QDataStream include in singleapp/qtlocalpeer.cpp +to fix compilation with current QT5. (Closes: #803755) + + -- Andreas Bombe <a...@debian.org> Sun, 22 Nov 2015 19:23:01 +0100 + texmaker (4.4.1-1) unstable; urgency=medium * New upstream release. diff -Nru texmaker-4.4.1/debian/patches/fix-qtlocalpeer-compilation texmaker-4.4.1/debian/patches/fix-qtlocalpeer-compilation --- texmaker-4.4.1/debian/patches/fix-qtlocalpeer-compilation 1970-01-01 01:00:00.0 +0100 +++ texmaker-4.4.1/debian/patches/fix-qtlocalpeer-compilation 2015-11-22 19:12:47.0 +0100 @@ -0,0 +1,12 @@ +Index: texmaker-4.4.1/singleapp/qtlocalpeer.cpp +=== +--- texmaker-4.4.1.orig/singleapp/qtlocalpeer.cpp texmaker-4.4.1/singleapp/qtlocalpeer.cpp +@@ -41,6 +41,7 @@ + + #include "qtlocalpeer.h" + #include ++#include + #include + + #if defined(Q_OS_WIN) diff -Nru texmaker-4.4.1/debian/patches/series texmaker-4.4.1/debian/patches/series --- texmaker-4.4.1/debian/patches/series 2014-12-09 20:08:23.0 +0100 +++ texmaker-4.4.1/debian/patches/series 2015-11-22 19:03:36.0 +0100 @@ -1,3 +1,4 @@ 10_spelling_dict.patch 20-add-keywords-desktop-file.patch use-system-synctex.patch +fix-qtlocalpeer-compilation
Bug#804840: stormbaancoureur: diff for NMU version 2.1.6-1.1
Control: tags 804840 + patch Control: tags 804840 + pending Dear maintainer^Wgames team, I've prepared an NMU for stormbaancoureur (versioned as 2.1.6-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. diff -u stormbaancoureur-2.1.6/debian/changelog stormbaancoureur-2.1.6/debian/changelog --- stormbaancoureur-2.1.6/debian/changelog +++ stormbaancoureur-2.1.6/debian/changelog @@ -1,3 +1,12 @@ +stormbaancoureur (2.1.6-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Remove remaining hard coded libode paths from Makefile including +a prerequisite on a system installed library with wrong path +(Closes: #804840) + + -- Andreas Bombe <a...@debian.org> Sun, 22 Nov 2015 18:38:09 +0100 + stormbaancoureur (2.1.6-1) unstable; urgency=low [ Barry deFreese ] diff -u stormbaancoureur-2.1.6/debian/patches/makefile.patch stormbaancoureur-2.1.6/debian/patches/makefile.patch --- stormbaancoureur-2.1.6/debian/patches/makefile.patch +++ stormbaancoureur-2.1.6/debian/patches/makefile.patch @@ -1,8 +1,12 @@ Index: stormbaancoureur-2.1.6/src-stormbaancoureur/Makefile === stormbaancoureur-2.1.6.orig/src-stormbaancoureur/Makefile 2009-12-03 19:59:57.0 -0500 -+++ stormbaancoureur-2.1.6/src-stormbaancoureur/Makefile 2009-12-03 20:00:06.0 -0500 -@@ -8,6 +8,8 @@ +--- stormbaancoureur-2.1.6.orig/src-stormbaancoureur/Makefile stormbaancoureur-2.1.6/src-stormbaancoureur/Makefile +@@ -4,24 +4,26 @@ VERSION=2.1.6-generic + + GLPREFIX=/usr + PLIBPREFIX=/usr +-ODEPREFIX=/usr CXX=g++ LIBDIRNAME=lib @@ -11,7 +15,9 @@ # END OF CUSTOM SETTINGS CXXFLAGS=\ -@@ -17,11 +19,13 @@ + -I$(GLPREFIX)/include \ +- -I$(ODEPREFIX)/include \ + -I$(PLIBPREFIX)/include \ -I../src-common \ -I. \ -DGAMEVERSION=$(VERSION) \ @@ -27,7 +33,7 @@ OBJS=\ -@@ -39,7 +43,7 @@ +@@ -39,7 +41,7 @@ OBJS=\ LIBS=\ @@ -38,0 +45,9 @@ +@@ -47,7 +49,7 @@ LIBS=\ + all: stormbaancoureur + + +-stormbaancoureur: $(OBJS) $(ODEPREFIX)/$(LIBDIRNAME)/libode.a ++stormbaancoureur: $(OBJS) + $(CXX) -o stormbaancoureur $(OBJS) $(LFLAGS) $(LIBS) + + staticworldobject.o: ../src-common/staticworldobject.cxx ../src-common/staticworldobject.h ../src-common/worldobject.h
Bug#788852: liblognorm: diff for NMU version 1.1.2-1.1
Control: tags 788852 + patch
Control: tags 788852 + pending
Dear maintainer,
I've prepared an NMU for liblognorm (versioned as 1.1.2-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru liblognorm-1.1.2/debian/changelog liblognorm-1.1.2/debian/changelog
--- liblognorm-1.1.2/debian/changelog 2015-09-26 10:53:59.0 +0200
+++ liblognorm-1.1.2/debian/changelog 2015-11-21 18:19:50.0 +0100
@@ -1,3 +1,10 @@
+liblognorm (1.1.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add Breaks for every package in Replaces (Closes: #788852)
+
+ -- Andreas Bombe <a...@debian.org> Sat, 21 Nov 2015 18:18:45 +0100
+
liblognorm (1.1.2-1) unstable; urgency=medium
* Imported Upstream version 1.1.2
diff -Nru liblognorm-1.1.2/debian/control liblognorm-1.1.2/debian/control
--- liblognorm-1.1.2/debian/control 2015-09-26 10:49:37.0 +0200
+++ liblognorm-1.1.2/debian/control 2015-11-21 18:10:23.0 +0100
@@ -36,6 +36,7 @@
Section: libs
Architecture: any
Replaces: liblognorm0, liblognorm1
+Breaks: liblognorm0, liblognorm1
Depends: ${shlibs:Depends}, ${misc:Depends}
Pre-Depends: ${misc:Pre-Depends}
Multi-Arch: same
Bug#769508: apt-spacewalk: diff for NMU version 1.0.6-4.1
On Sun, Nov 23, 2014 at 10:47:34AM +0100, Bernd Zeimetz wrote: Hi, Thanks for the upload, please move it from the delayed/5 to delayed/0 or upload it to the normal queue again. I'll ask for an unblock. I have reuploaded it to the normal queue and also committed the changes to your repository in collab-maint. Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769269: rep-gtk: FTBFS in jessie/i386: /usr/lib/rep/i486-pc-linux-gnu/libtool: line 7834: i486-linux-gnu-gcc: command not found
block -1 by 769642 thanks /usr/lib/rep/i486-pc-linux-gnu/libtool ... This error is caused by the libtool shipped with librep-dev and already reported there as #769642. Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769259: golang-testify: FTBFS in jessie/i386: dh_auto_test: go test -v github.com/stretchr/testify github.com/stretchr/testify/assert github.com/stretchr/testify/http github.com/stretchr/testify/m
On Sat, Nov 15, 2014 at 09:57:17PM +0100, Lucas Nussbaum wrote:
On 15/11/14 at 21:18 +0100, Jelmer Vernooij wrote:
Hi Lucas,
On Wed, Nov 12, 2014 at 11:46:23AM +0100, Lucas Nussbaum wrote:
Source: golang-testify
Version: 0.0~git20140717-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20141112 qa-ftbfs
Justification: FTBFS in jessie on i386
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on i386.
Are you able to reproduce this locally? The buildds didn't have any problem
with this
version of the package earlier, and I'm also having trouble reproducing it
with
the current state of the archive.
Hi,
It builds fine on amd64, but fails on i386. The first failing test seem
to be:
if !Equal(mockT, int64(123), uint64(123)) {
t.Error(Equal should return true)
}
I could reproduce it again in a chroot on EC2. I don't have a local i386
chroot unfortunately.
FWIW, I reproduced it with cowbuilder using a jessie i386 chroot (host
system is amd64).
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768889: efibootmgr: diff for NMU version 0.11.0-1.1
Control: tags 768889 + patch Control: tags 768889 + pending Dear maintainer, I've prepared an NMU for efibootmgr (versioned as 0.11.0-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. I have not pushed but have attached the two commits to the collab-maint repository that I used to create this upload. Regards. diff -Nru efibootmgr-0.11.0/debian/changelog efibootmgr-0.11.0/debian/changelog --- efibootmgr-0.11.0/debian/changelog 2014-10-29 05:41:15.0 +0100 +++ efibootmgr-0.11.0/debian/changelog 2014-11-22 15:56:31.0 +0100 @@ -1,3 +1,11 @@ +efibootmgr (0.11.0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Skip dh_auto_install, it installs binary into /usr/sbin and is not +actually needed with the current packaging (Closes: 768889) + + -- Andreas Bombe a...@debian.org Sat, 22 Nov 2014 15:38:43 +0100 + efibootmgr (0.11.0-1) unstable; urgency=medium * New upstream version diff -Nru efibootmgr-0.11.0/debian/rules efibootmgr-0.11.0/debian/rules --- efibootmgr-0.11.0/debian/rules 2014-10-29 05:29:33.0 +0100 +++ efibootmgr-0.11.0/debian/rules 2014-11-22 15:56:31.0 +0100 @@ -8,6 +8,10 @@ %: dh $@ +# upstream build installs into /usr/sbin ignoring target directory; +# since the install step is not actually needed just skip it +override_dh_auto_install: + override_dh_installman: dh_installman From de77fa2d54cad7f1db21ae1ade470e4b40803102 Mon Sep 17 00:00:00 2001 From: Andreas Bombe a...@debian.org Date: Sat, 22 Nov 2014 15:12:12 +0100 Subject: [PATCH 1/2] Skip dh_auto_install, it installs binary into /usr/sbin The standard target directory redirection attempted by dh_auto_install is ignored by the upstream build framework and it installs efibootmgr into /usr/sbin. Since the install step is not actually needed (the files are installed directly from the build dir), simply omit dh_auto_install instead of attempting to fix it. Closes: 768889 --- debian/rules | 4 1 file changed, 4 insertions(+) diff --git a/debian/rules b/debian/rules index 2efe014..b587b86 100755 --- a/debian/rules +++ b/debian/rules @@ -8,6 +8,10 @@ export DH_OPTIONS=-v %: dh $@ +# upstream build installs into /usr/sbin ignoring target directory; +# since the install step is not actually needed just skip it +override_dh_auto_install: + override_dh_installman: dh_installman -- 2.1.3 From 4ccb6c7f7608790cf936e9982b9428e7a01ee5a8 Mon Sep 17 00:00:00 2001 From: Andreas Bombe a...@debian.org Date: Sat, 22 Nov 2014 15:55:16 +0100 Subject: [PATCH 2/2] Changelog for NMU upload 0.11.0-1.1 --- debian/changelog | 8 1 file changed, 8 insertions(+) diff --git a/debian/changelog b/debian/changelog index 0b3f902..5943fe2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +efibootmgr (0.11.0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Skip dh_auto_install, it installs binary into /usr/sbin and is not +actually needed with the current packaging (Closes: 768889) + + -- Andreas Bombe a...@debian.org Sat, 22 Nov 2014 15:38:43 +0100 + efibootmgr (0.11.0-1) unstable; urgency=medium * New upstream version -- 2.1.3
Bug#769508: apt-spacewalk: diff for NMU version 1.0.6-4.1
Control: tags 769508 + patch
Control: tags 769508 + pending
Dear maintainer,
I've prepared an NMU for apt-spacewalk (versioned as 1.0.6-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer. Also attached are the two commits which I
haven't pushed to collab-maint yet (I will push them later).
Regards.
diff -u apt-spacewalk-1.0.6/debian/changelog apt-spacewalk-1.0.6/debian/changelog
--- apt-spacewalk-1.0.6/debian/changelog
+++ apt-spacewalk-1.0.6/debian/changelog
@@ -1,3 +1,11 @@
+apt-spacewalk (1.0.6-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Check for post_invoke.py to exist before attempting to invoke it
+(Closes: 769508)
+
+ -- Andreas Bombe a...@debian.org Sat, 22 Nov 2014 18:42:41 +0100
+
apt-spacewalk (1.0.6-4) unstable; urgency=medium
* [99f9479e] Integrate NMU that went missing.
only in patch2:
unchanged:
--- apt-spacewalk-1.0.6.orig/50spacewalk
+++ apt-spacewalk-1.0.6/50spacewalk
@@ -11,5 +11,5 @@
}
};
DPkg::Post-Invoke {
-/usr/lib/apt-spacewalk/post_invoke.py;
+[ ! -e /usr/lib/apt-spacewalk/post_invoke.py ] || /usr/lib/apt-spacewalk/post_invoke.py;
};
From 085f07ace47fc5a852b14ebd2dbc1e47d892ed79 Mon Sep 17 00:00:00 2001
From: Andreas Bombe a...@debian.org
Date: Sat, 22 Nov 2014 18:38:14 +0100
Subject: [PATCH 1/2] Check for post_invoke.py to exist before attempting to
invoke it
This is run as DPkg::Post-Invoke, but during package removal the file
stops existing before the Post-Invoke is actually started. Checking for
its existance beforehand prevents the Post-Invoke reporting an error.
Closes: 769508
---
50spacewalk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/50spacewalk b/50spacewalk
index 2c3264c..e86ffa1 100644
--- a/50spacewalk
+++ b/50spacewalk
@@ -11,5 +11,5 @@ APT {
}
};
DPkg::Post-Invoke {
-/usr/lib/apt-spacewalk/post_invoke.py;
+[ ! -e /usr/lib/apt-spacewalk/post_invoke.py ] || /usr/lib/apt-spacewalk/post_invoke.py;
};
--
2.1.3
From aa35cae6a4421cb499b488b2f6bf09e41ce717d3 Mon Sep 17 00:00:00 2001
From: Andreas Bombe a...@debian.org
Date: Sat, 22 Nov 2014 18:44:05 +0100
Subject: [PATCH 2/2] Changelog for NMU upload 1.0.6-4.1
---
debian/changelog | 8
1 file changed, 8 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 4adf866..0479a87 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+apt-spacewalk (1.0.6-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Check for post_invoke.py to exist before attempting to invoke it
+(Closes: 769508)
+
+ -- Andreas Bombe a...@debian.org Sat, 22 Nov 2014 18:42:41 +0100
+
apt-spacewalk (1.0.6-4) unstable; urgency=medium
* [99f9479e] Integrate NMU that went missing.
--
2.1.3
Bug#768909: dosfstools: fatlabel clobbers existing entry in root directory
Package: dosfstools Version: 3.0.26-4 Severity: grave Tags: upstream Justification: causes non-serious data loss I found this bug reported against the same version of the package in Fedora reported by user ghborrmann and reproduced it. Original report: https://bugzilla.redhat.com/show_bug.cgi?id=1158101 Quoting the steps to reproduce: 1. Use mkfs.fat to create a fat system on a file. Do not specify a volume label. 2. Mount the file and copy a file to the new system. I used a 9-character name to ensure that it would generate a long file name type of entry. 3. Unmount the file and label it using fatlabel. 4. Mount the file again and list the directory with ls 5. Unmount the file and run fsck.fat Actual results: In step 4, the listing gives the short file name (all caps, ending in ~1) In step 5, fsck complains about a long file name overwritten by the short name. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-rc3-00108-g661b99e (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dosfstools depends on: ii libc6 2.19-13 dosfstools recommends no packages. dosfstools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753286: v4l-utils and media-ctl: error when trying to install together
On Mon, Jun 30, 2014 at 02:38:33PM +0200, Gregor Jasny wrote: Hi, I did not notice that there is already an existing media-ctl package. Otherwise I'd have done an more coordinated upload. How do we want to go from here? It seems that upstream decided to add the code to v4l-utils. Yes, when I was packaging it he mentioned to me that he might eventually put it there. I didn't know this has happened now. Is it reasonable if I add a conflict against media-ctl and you remove the package completely? Yes, I will take care of removing my package then. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673032: anki: Package missing needed dependence on python-sqlalchemy version
severity 673032 minor quit On Tue, May 15, 2012 at 09:51:26AM -0500, Matt Elder wrote: File /usr/share/anki/anki/db.py, line 33, in module from sqlalchemy.exc import DBAPIError, OperationalError ImportError: No module named exc After upgrading python-sqlalchemy (which automatically upgraded python-sqlalchemy-ext), anki appears to work just fine. I'm not sure what my old version of python-sqlalchemy was, though. I checked and found that the sqlalchemy.exc module was introduced in version 0.5.0. But we have to go back to oldstable aka Debian 5.0 lenny to find a pre-0.5.0 python-sqlalchemy package. So while there is a bug in that the versioned dependency is not quite enough, installing packages from unstable into oldstable is not exactly a supported operation. Therefore this bug does not deserve a severity more than minor in my opinion (grave would have been to high in any case). If you haven't been trying to install anki from unstable to oldstable, I strongly suspect you had a broken installation of python-sqlalchemy (missing files). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#419618: /usr/bin/pdftops: pdftops segfault, additional file
Package: xpdf-utils Version: 3.01-9 Followup-For: Bug #419618 This segfault on print bug seems to be solely the fault of pdftops segfaulting somewhere down the line. Handing the file directly to CUPS via lp also fails with a pdftops signal 11 reported in the error log. The file I encountered the bug on is available at http://www.kba.de/Stabsstelle/ZentraleRegister/VZR/FormularVZRneu1.pdf Most other PDFs I tried seem to work, a few also crash pdftops. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-vserver-k7 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xpdf-utils depends on: ii libc6 2.5-1 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libpaper1 1.1.21 Library for handling paper charact ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii xpdf-common 3.01-9 Portable Document Format (PDF) sui xpdf-utils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370793: fix for reportbug_submit.py
Package: reportbug
Version: 3.21
Tags: patch
Followup-For: Bug #370793
The included patch by Adam Porter had wrong indentation and was missing
a colon at the end of an if-expression. Patch attached.
--- reportbug_submit.py.orig2006-06-07 00:23:33.0 +0200
+++ reportbug_submit.py 2006-06-07 00:21:43.0 +0200
@@ -350,34 +350,34 @@
toaddrs = [x[1] for x in alist]
smtp_message = re.sub(r'(?m)^[.]', '..', message)
- # Modified by AP 2006-03-29
- while failed != True:
- ewrite(Connecting to %s via SMTP...\n, smtphost)
- try:
- conn = smtplib.SMTP(smtphost)
- if smtptls:
- conn.starttls()
- if smtpuser:
- if not smtppasswd:
- smtppasswd = ui.get_password(
- 'Enter SMTP password
for [EMAIL PROTECTED]: ' %
- (smtpuser, smtphost))
- conn.login(smtpuser, smtppasswd)
- conn.sendmail(fromaddr, toaddrs, smtp_message)
- conn.quit()
- except (socket.error, smtplib.SMTPException), x:
-
- # If wrong password, try again...
- if smtplib.SMTPResponseException.smtp_code ==
'535'
- ewrite('SMTP error: authentication
failed. Try again.')
- continue
-
- failed = True
- ewrite('SMTP send failure: %s\n', x)
- fh, msgname = TempFile(prefix=tfprefix)
- fh.write(message)
- fh.close()
- ewrite('Wrote bug report to %s\n', msgname)
+# Modified by AP 2006-03-29
+while failed != True:
+ewrite(Connecting to %s via SMTP...\n, smtphost)
+try:
+conn = smtplib.SMTP(smtphost)
+if smtptls:
+conn.starttls()
+if smtpuser:
+if not smtppasswd:
+smtppasswd = ui.get_password(
+'Enter SMTP password for [EMAIL PROTECTED]: ' %
+(smtpuser, smtphost))
+conn.login(smtpuser, smtppasswd)
+conn.sendmail(fromaddr, toaddrs, smtp_message)
+conn.quit()
+except (socket.error, smtplib.SMTPException), x:
+
+# If wrong password, try again...
+if smtplib.SMTPResponseException.smtp_code == '535':
+ewrite('SMTP error: authentication failed. Try again.')
+continue
+
+failed = True
+ewrite('SMTP send failure: %s\n', x)
+fh, msgname = TempFile(prefix=tfprefix)
+fh.write(message)
+fh.close()
+ewrite('Wrote bug report to %s\n', msgname)
else:
try:
pipe.write(message)
Bug#369626: schroot: rm -rf in file chroot cleanup destroys real /home if umount fails
On Wed, May 31, 2006 at 10:53:18AM +0100, Roger Leigh wrote: Andreas Bombe [EMAIL PROTECTED] writes: The session cleanup in 10mount ignores failures of umount invocations and cleanup continues. In the case of file chroots with a /home bind mount that failed to umount, the rm -rf in 05file blindly descends into the system /home with obvious unpretty results. I'm awfully sorry if this caused you to lose any data. No worries, I suspected what happened and killed the rm and everything that got deleted I had available elsewhere for restoring. There are a few possibilities here. 1) 10mount should exit with an error if umount fails. Caveat: if the session is ended with the setup scripts having failed, this would require manual cleanup by the system admin. This needs additional work in session::setup_chroot() in sbuild-session.cc, so that the session is not ended if the scripts fail. This means not removing the session file from /var/lib/schroot/session/ on failure. Currently, because of the above consideration, the setup-stop phase of the session scripts can not fail. If a umount fails it will require manual admin intervention anyway so that wouldn't make much of a difference. Making the rm -rf safe is still required in any case, I'd say. 2) 05file must check if any filesystems are mounted under the chroot root before running rm -rf. Is there a portable and reliable way of doing this? Would if mount | grep $CHROOT_MOUNT_LOCATION; then : else rm -rf $CHROOT_MOUNT_LOCATION || true fi be sufficient? I don't think that is safe. It depends on all mounts being recorded in /etc/mtab, which is not the case if something *inside* the chroot mounted something, for example. I thought about rm with a do not cross filesystems option, still that wouldn't help because binds may well be on the same filesystem. There are no usable criteria for using find ... -exec rm ... either. The only way I know to be sure there are no submounts is to mount --bind the chroot to a temporary location and rm -rf there, then unmount the temporary bind and rmdir the chroot. The rmdir will fail safely if the chroot isn't empty then. Even before, the rm -rf of the temp bind will fail safely upon trying to remove an empty directory used as a mount point in the chroot. -- Andreas Bombe [EMAIL PROTECTED]GPG key 0x04880A44 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369626: schroot: rm -rf in file chroot cleanup destroys real /home if umount fails
Package: schroot Version: 0.2.10-1 Severity: critical Justification: causes serious data loss The session cleanup in 10mount ignores failures of umount invocations and cleanup continues. In the case of file chroots with a /home bind mount that failed to umount, the rm -rf in 05file blindly descends into the system /home with obvious unpretty results. The bind mount may fail to umount whenever something gets mounted under the bind. In my case I was foolishly trying to rbind instead of bind /home in 10mount because my $HOME is a separate mount, and I wanted to have it available in the chroot. Apart from making a failed umount abort the session cleanup, I see as another possible solution to rm -rf only a bind mount of the chroot to be sure there are no sub mounts, then umount this and only rmdir the actual chroot. This would fail harmlessly if umounts failed (results only in a leftover session to be manually cleaned up). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-1-k7 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages schroot depends on: ii libboost-prog 1.33.1-4 program options library for C++ ii libc6 2.3.6-9GNU C Library: Shared libraries ii libgcc1 1:4.1.0-4 GCC support library ii liblockdev1 1.0.3-1Run-time shared library for lockin ii libpam0g 0.79-3.1 Pluggable Authentication Modules l ii libstdc++64.1.0-4The GNU Standard C++ Library v3 ii libuuid1 1.38+1.39-WIP-2006.04.09-2 universally unique id library schroot recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295294: splitting different security issues for armagetron
clone 295294 -1 retitle -1 armagetron server DOS by fake players (CAN-2005-0371) retitle 295294 multiple security holes (CAN-2005-0370 CAN-2005-0369) thanks I'm splitting this security bug report as the crashes as everything is fixed except for the last DOS attack so that I can put that in the changelog. And maybe the pure DOS bug can be reduced in severity. -- Andreas Bombe [EMAIL PROTECTED]GPG key 0x04880A44 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295294: multiple security holes (CAN-2005-0371 CAN-2005-0370 CAN-2005-0369)
On Mon, Feb 14, 2005 at 04:31:34PM -0500, Joey Hess wrote: It's not clear whether the crashes allow for executing arbetrary code or whether this is limited to a denial of service attack. Also, if it's right that upstream is no longer supporting it, we may need to patch it ourselves or drop the package. Armagetron Advanced has picked up where Armagetron stopped due to inactivity and now the original upstream joined them, too. It's not unmaintained anymore, the upstream changed to a new project (http://sf.net/projects/armagetronad/). I'm now looking into it. -- Andreas Bombe [EMAIL PROTECTED]GPG key 0x04880A44 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
