Bug#1053293: ghdl-llvm: Does not work, ghdl1-llvm not found

[Andreas Bombe]

Package: ghdl-llvm
Version: 3.0.0+dfsg-1
Severity: important

ghdl-llvm has become unusable with 3.0.0+dfsg-1. Running ghdl-llvm
immediately aborts with the message:

  /usr/bin/ghdl-llvm:error: installation problem: ghdl1-llvm not found

According to build logs, the testsuite for the LLVM build already fails
with the same message.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ghdl-llvm depends on:
ii  gcc  4:13.2.0-1
ii  ghdl-common  3.0.0+dfsg-1
ii  libc62.37-11
ii  libgcc-s113.2.0-4
ii  libgnat-12   12.3.0-9
ii  libllvm161:16.0.6-15
ii  libstdc++6   13.2.0-4
ii  zlib1g-dev   1:1.2.13.dfsg-3

ghdl-llvm recommends no packages.

ghdl-llvm suggests no packages.

-- no debconf information

Bug#1036737: libsoapysdr0.8: please add Breaks: libsoapysdr0.7 for smoother upgrades from bullseye

[Andreas Bombe]

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#1028246: transition: liquid-dsp

[Andreas Bombe]

On Sun, Jan 08, 2023 at 11:47:42PM +0200, Adrian Bunk wrote:
> On Sun, Jan 08, 2023 at 10:11:46PM +0100, Andreas Bombe wrote:
> >...
> > i386 only, where some
> > floats don't match exactly, which I'm still investigating.
> >...
> 
> That's "better" results due to x87 excess precison.
> 
> The patch below fixes the tests for me.

Thanks very much, I suspected something in the direction of x87 80-bit
floats messing with this, but I didn't know an easy way to fix that.
Also fixed the qs1dsearch failures, but I'm leaning towards this still
being a gcc misoptimization issue.

Just unfortunate that this might make the code slower and the library
has no autodetection of SIMD units.

Bug#1028246: transition: liquid-dsp

[Andreas Bombe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: liquid-...@packages.debian.org
Control: affects -1 + src:liquid-dsp

This is a new version of liquid-dsp where upstream now defined a
versioned soname. Reverse dependencies are cubicsdr and inspectrum, both
maintained in the ham radio team, that built and appear to work fine.

The autobuilders in experimental failed on i386 and mipsel during the
testsuite. I identified an array overrun which only causes trouble on
mipsel, apparently mangling a return address, which I can patch. The
other is one function getting wrongly optimized by gcc apparently, which
I can work around. And actually one more, also i386 only, where some
floats don't match exactly, which I'm still investigating.

The auto-liquid-dsp tracker appears correct.

Ben file:

title = "liquid-dsp";
is_affected = .depends ~ "libliquid3d" | .depends ~ "libliquid1";
is_good = .depends ~ "libliquid1";
is_bad = .depends ~ "libliquid3d";

Bug#1027853: transition: muparserx

[Andreas Bombe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: mupars...@packages.debian.org
Control: affects -1 + src:muparserx

This is still a package with a soname coupled to its release number, so
there isn't really anything significantly changed.

It has genomicsdb, otb and qiskit-aer as rdepds and I successfully built
all three against the new version. For both genomicsdb and qiskit-aer
the build time testsuite completed without failures. otb does not appear
to have a testsuite.

The auto-muparserx ben tracker appears correct.

Ben file:

title = "muparserx";
is_affected = .depends ~ "libmuparserx4.0.8" | .depends ~ "libmuparserx4.0.11";
is_good = .depends ~ "libmuparserx4.0.11";
is_bad = .depends ~ "libmuparserx4.0.8";

Bug#1027747: gtkwave: Drop ghwdump in favor of ghdl's version

[Andreas Bombe]

Package: gtkwave
Version: 3.3.104-2+b1
Severity: normal

Currently ghwdump is shipped with gtkwave, however it is outdated and
will fail when used in the current ghdl's testsuite. Upstream for
gtkwave has dropped ghwdump and upstream for ghdl has included it.

In the new ghdl packages I have included ghwdump in a temporary location
in /usr/lib/ghdl so that it can be used in the testsuite by
autopkgtests. I intend to create a new binary package "ghwdump" as part
of the ghdl packaging, and for that I'd like to move ownership of
/usr/bin/ghwdump from gtkwave to that package.

As newer versions of gtkwave drop ghwdump from their sources this will
happen anyway, but will require coordination on part of the dependency
relationships between those packages.

Bug#1027745: gtkwave: New upstream version available

[Andreas Bombe]

Package: gtkwave
Version: 3.3.104-2+b1
Severity: wishlist

There have been new upstream releases in the meantime, up to 3.3.114.
Additionally the upstream package can be switched to gtkwave-gtk3 to get
a variant that should work with gtk3 (the gtkwave upstream package is
still gtk1/gtk2 only) and solve #967502.

The included ghwdump has been dropped in the meantime in favor of its
distribution with ghdl. While packaging the current ghdl release I had
to include its ghwdump in order to allow autopkgtests to function as the
gtkwave ghwdump is too old to understand current ghw files. I will file
a separate bug about that.

Bug#1026392: transition: gnat-12

[Andreas Bombe]

On Sat, Dec 31, 2022 at 04:33:12PM +0100, Nicolas Boulenguez wrote:
> ghdl (red line):
> is removed from testing and should not block the transition.
> The version in unstable depends on gnat-10 (lots of RC bugs).
> The version in experimental depends on gcc-12 (a few RC bugs).
> What do you recommend?
> - avoid risking an interferenc with other packages
> - reupload from experimental to unstable
> - ?

I could have reuploaded the experimental ghdl to unstable, but I wanted
to change the gcc backend configuration so that it would hopefully
resolve the build failures seen on some architectures. That is taking
some wrestling with the build process that I hope to resolve shortly.

How the testsuite failures from LLVM generated code on some
architectures can be solved I don't know yet (as in, whether that's a
LLVM or GHDL bug), I'll probably make these tests non-fatal for the time
being to investigate. So in short, I'll upload a package shortly that
should be able to build on all architectures and complete this
transition on the GHDL side.

Bug#1007098: transition: liquid-dsp

[Andreas Bombe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi release team,

I request a transition slot for a small transition for liquid-dsp. Just
2 reverse dependencies, and both build and run fine with the new library
version. The auto-liquid-dsp tracker looks good.

Thanks.



Ben file:

title = "liquid-dsp";
is_affected = .depends ~ "libliquid2d" | .depends ~ "libliquid3d";
is_good = .depends ~ "libliquid3d";
is_bad = .depends ~ "libliquid2d";

Bug#1005153: ykls man page does not describe ykls

[Andreas Bombe]

Package: ykls
Version: 1.3.4-2+b5
Severity: minor

The man page ykls(1) does not even mention ykls except in the title.
Instead, it seems to be some sort of README for go-ykpiv and is not
formatted like a section 1 manpage.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-3-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ykls depends on:
ii  libc6  2.33-5
ii  libykpiv2  2.2.0-1
ii  pcscd  1.9.5-1

ykls recommends no packages.

ykls suggests no packages.

-- no debconf information

Bug#993699: SoapySDR transition is in progress

[Andreas Bombe]

severity 993699 serious
thanks


The SoapySDR transition is starting, so I am raising the severity of
this bug to serious.

Bug#993701: SoapySDR transition is in progress

[Andreas Bombe]

severity 993701 serious
thanks


The SoapySDR transition is starting, so I am raising the severity of
this bug to serious.

Bug#993698: SoapySDR transition is in progress

[Andreas Bombe]

severity 993698 serious
thanks


The SoapySDR transition is starting, so I am raising the severity of
this bug to serious.

Bug#993702: transition: soapysdr

[Andreas Bombe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi release team,

I request a transition slot for libsoapysdr that changed its ABI
version. This also includes all soapysdr driver modules that are also
versioned and will transition together. soapysdr and all module
providing packages are in experimental.

The auto-soapysdr tracker looks right, the other auto-soapy* and
auto-limesuite transitions can be ignored as these are from the
versioned modules packages.

Test building of dependency level 2 packages showed that soapysdr
changed one function signature and hacktv, libxtrx and srslte fail to
build as a result. Bugs have been filed and the fixes should be trivial,
for two upstream already has them. The other packages build fine.

Ben file generated by reportbug, but probably not needed since
auto-soapysdr is fine:

title = "soapysdr";
is_affected = .depends ~ "libsoapysdr0.7" | .depends ~ "libsoapysdr0.8";
is_good = .depends ~ "libsoapysdr0.8";
is_bad = .depends ~ "libsoapysdr0.7";


Thanks.

Bug#993701: srslte: FTBFS with libsoapysdr 0.8

[Andreas Bombe]

Source: srslte
Version: 18.06.1+ds.1
Severity: important
Tags: ftbfs

I am building rdeps of libsoapysdr in preparation of the transition to
version 0.8. This version has changed the SoapySDRDevice_setupStream()
function signature to return the SoapySDRStream directly rather than
through a pointer:

*   Recommended keys to use in the args dictionary:
*- "WIRE" - format of the samples between device and host
* \endparblock
  - * \return 0 for success or error code on failure
  + * \return the stream pointer or nullptr for failure
*/
  -SOAPY_SDR_API int SoapySDRDevice_setupStream(SoapySDRDevice *device,
  -SoapySDRStream **stream,
  +SOAPY_SDR_API SoapySDRStream *SoapySDRDevice_setupStream(SoapySDRDevice 
*device,
   const int direction,
   const char *format,
   const size_t *channels,

This change causes a build failure in srslte when building against the
new libsoapysdr. I can see upstream has already fixed that in their
sources. Log of the failed build:

/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c: In function 
'rf_soapy_open_multi':
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:52: warning: 
passing argument 2 of 'SoapySDRDevice_setupStream' makes integer from pointer 
without a cast [-Wint-conversion]
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  |^~~~
  ||
  |SoapySDRStream **
In file included from 
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:37:
/usr/include/SoapySDR/Device.h:307:15: note: expected 'int' but argument is of 
type 'SoapySDRStream **'
  307 | const int direction,
  | ~~^
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:74: warning: 
passing argument 3 of 'SoapySDRDevice_setupStream' makes pointer from integer 
without a cast [-Wint-conversion]
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  | 
 ^~~~
  | 
 |
  | 
 int
In file included from 
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:37:
/usr/include/SoapySDR/Device.h:308:17: note: expected 'const char *' but 
argument is of type 'int'
  308 | const char *format,
  | ^~
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:88: error: passing 
argument 4 of 'SoapySDRDevice_setupStream' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  | 
   ^~
  | 
   |
  | 
   char *
In file included from 
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:37:
/usr/include/SoapySDR/Device.h:309:19: note: expected 'const size_t *' {aka 
'const long unsigned int *'} but argument is of type 'char *'
  309 | const size_t *channels,
  | ~~^~~~
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:104: warning: 
passing argument 5 of 'SoapySDRDevice_setupStream' makes integer from pointer 
without a cast [-Wint-conversion]
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  | 
   ^~~~
  | 
   |
  | 
   void *
In file included from 
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:37:
/usr/include/SoapySDR/Device.h:310:18: note: expected 'size_t' {aka 'const long 
unsigned int'} but argument is of type 'void *'
  310 | const size_t numChans,
  | ~^~~~
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:8: error: too many 
arguments to function 'SoapySDRDevice_setupStream'
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  |^~
In file included from 

Bug#993699: libxtrx: FTBFS with libsoapysdr 0.8

[Andreas Bombe]

Source: libxtrx
Version: 0.0.1+git20191219.98458ce-1
Severity: important
Tags: ftbfs upstream


I am building rdeps of libsoapysdr in preparation of the transition to
version 0.8. This version has changed the SoapySDRDevice_setupStream()
function signature to return the SoapySDRStream directly rather than
through a pointer:

*   Recommended keys to use in the args dictionary:
*- "WIRE" - format of the samples between device and host
* \endparblock
  - * \return 0 for success or error code on failure
  + * \return the stream pointer or nullptr for failure
*/
  -SOAPY_SDR_API int SoapySDRDevice_setupStream(SoapySDRDevice *device,
  -SoapySDRStream **stream,
  +SOAPY_SDR_API SoapySDRStream *SoapySDRDevice_setupStream(SoapySDRDevice 
*device,
   const int direction,
   const char *format,
   const size_t *channels,

This causes a build failure in libxtrx when building against the new
libsoapysdr. Upstream appears to have switched to the new call signature
in their current code, dropping compatibility with libsoapysdr 0.7 at
the same time. A way to be compatible with both would be using
preprocessor directives to discriminate between API version using
SOAPY_SDR_API_VERSION.

Log of the failed build:

/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c: In function 
'main':
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:41: 
warning: passing argument 2 of 'SoapySDRDevice_setupStream' makes integer from 
pointer without a cast [-Wint-conversion]
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  | ^
  | |
  | SoapySDRStream **
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:307:15: note: expected 'int' but argument is of 
type 'SoapySDRStream **'
  307 | const int direction,
  | ~~^
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:52: 
warning: passing argument 3 of 'SoapySDRDevice_setupStream' makes pointer from 
integer without a cast [-Wint-conversion]
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  |^~~~
  ||
  |int
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:308:17: note: expected 'const char *' but 
argument is of type 'int'
  308 | const char *format,
  | ^~
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:66: 
warning: passing argument 4 of 'SoapySDRDevice_setupStream' from incompatible 
pointer type [-Wincompatible-pointer-types]
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  |  
^~
  |  |
  |  char *
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:309:19: note: expected 'const size_t *' {aka 
'const long unsigned int *'} but argument is of type 'char *'
  309 | const size_t *channels,
  | ~~^~~~
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:82: 
warning: passing argument 5 of 'SoapySDRDevice_setupStream' makes integer from 
pointer without a cast [-Wint-conversion]
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  | 
 ^~~~
  | 
 |
  | 
 void *
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:310:18: note: expected 'size_t' {aka 'const long 
unsigned int'} but argument is of type 'void *'
  310 | const size_t numChans,
  | ~^~~~
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:9: error: 
too many arguments to function 'SoapySDRDevice_setupStream'
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  | ^~
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:306:31: note: declared here
  306 | SOAPY_SDR_API 

Bug#993698: hacktv: FTBFS with libsoapysdr 0.8

[Andreas Bombe]

Source: hacktv
Version: 0+git20201203-1
Severity: important
Tags: ftbfs upstream upstream

I am building rdeps of libsoapysdr in preparation of the transition to
version 0.8. This version has changed the SoapySDRDevice_setupStream()
function signature to return the SoapySDRStream directly rather than
through a pointer:

*   Recommended keys to use in the args dictionary:
*- "WIRE" - format of the samples between device and host
* \endparblock
  - * \return 0 for success or error code on failure
  + * \return the stream pointer or nullptr for failure
*/
  -SOAPY_SDR_API int SoapySDRDevice_setupStream(SoapySDRDevice *device,
  -SoapySDRStream **stream,
  +SOAPY_SDR_API SoapySDRStream *SoapySDRDevice_setupStream(SoapySDRDevice 
*device,
   const int direction,
   const char *format,
   const size_t *channels,

This causes a build failure in hacktv when building against the new
libsoapysdr. Upstream does not appear to have a fix yet, one way would
be using preprocessor directives to discriminate between API version
using SOAPY_SDR_API_VERSION.

Log of the failed build:

soapysdr.c: In function 'rf_soapysdr_open':
soapysdr.c:135:39: warning: passing argument 2 of 'SoapySDRDevice_setupStream' 
makes integer from pointer without a cast [-Wint-conversion]
  135 |  if(SoapySDRDevice_setupStream(rf->d, >s, SOAPY_SDR_TX, 
SOAPY_SDR_CS16, NULL, 0, NULL) != 0)
  |   ^~
  |   |
  |   SoapySDRStream **
In file included from soapysdr.c:20:
/usr/include/SoapySDR/Device.h:307:15: note: expected 'int' but argument is of 
type 'SoapySDRStream **'
  307 | const int direction,
  | ~~^
soapysdr.c:135:61: warning: passing argument 4 of 'SoapySDRDevice_setupStream' 
from incompatible pointer type [-Wincompatible-pointer-types]
  135 |  if(SoapySDRDevice_setupStream(rf->d, >s, SOAPY_SDR_TX, 
SOAPY_SDR_CS16, NULL, 0, NULL) != 0)
  | 
^~
  | |
  | char *
In file included from soapysdr.c:20:
/usr/include/SoapySDR/Device.h:309:19: note: expected 'const size_t *' {aka 
'const long unsigned int *'} but argument is of type 'char *'
  309 | const size_t *channels,
  | ~~^~~~
soapysdr.c:135:77: warning: passing argument 5 of 'SoapySDRDevice_setupStream' 
makes integer from pointer without a cast [-Wint-conversion]
  135 |  if(SoapySDRDevice_setupStream(rf->d, >s, SOAPY_SDR_TX, 
SOAPY_SDR_CS16, NULL, 0, NULL) != 0)
  | 
^~~~
  | 
|
  | 
void *
In file included from soapysdr.c:20:
/usr/include/SoapySDR/Device.h:310:18: note: expected 'size_t' {aka 'const long 
unsigned int'} but argument is of type 'void *'
  310 | const size_t numChans,
  | ~^~~~
soapysdr.c:135:5: error: too many arguments to function 
'SoapySDRDevice_setupStream'
  135 |  if(SoapySDRDevice_setupStream(rf->d, >s, SOAPY_SDR_TX, 
SOAPY_SDR_CS16, NULL, 0, NULL) != 0)
  | ^~
In file included from soapysdr.c:20:
/usr/include/SoapySDR/Device.h:306:31: note: declared here
  306 | SOAPY_SDR_API SoapySDRStream *SoapySDRDevice_setupStream(SoapySDRDevice 
*device,
  |   ^~

Bug#987528: closed by Debian FTP Masters

[Andreas Bombe]

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)

[Andreas Bombe]

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#929656: Merge GHDL issues

[Andreas Bombe]

tags 929656 + pending
thanks

On Thu, Jan 28, 2021 at 04:46:26PM -0800, Graeme Smecher wrote:
> As I understand it [1], the IEEE recently changed their license and uses
> Apache 2.0. License technicalities are beyond me -- offhand, do you know
> if this is sufficient to get a more complete build of GHDL into Debian?
> 
> [1]:
> https://opensource.ieee.org/vasg/Packages/-/commit/98ecff1a0b80d57c4eb9df7dc0288483cd46b264

As it so happens, I finished updating the GHDL package in that regard
and uploaded it just yesterday. It uses the IEEE library sources instead
of the OpenIEEE replacement and offers VHDL-2008 support as a result.

Since it also introduces a new ghdl-common package to prevent a circular
dependency that previously existed, it is going through the NEW queue
and will take some time until it appears in the Debian archive.

Bug#979185: transition: muparserx

[Andreas Bombe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

This package has been sitting in experimental for… a while (and there
was no upstream release in the meantime, so at least there's that). It's
just a small transition so this should be quick and easy to get out of
the way.

There are only 2 rdepends, and of those only otb is actually in testing.
I made a successful test build of otb with the new package.

Ben file (but the auto-ben file also looks good):

title = "muparserx";
is_affected = .depends ~ "libmuparserx4.0.7" | .depends ~ "libmuparserx4.0.8";
is_good = .depends ~ "libmuparserx4.0.8";
is_bad = .depends ~ "libmuparserx4.0.7";


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-5-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971030: soapysdr, libaudioSupport: libarmmem-${PLATFORM}.so => libarmmem-v7l.so

[Andreas Bombe]

tags 971030 + moreinfo
thanks

On Sat, Sep 26, 2020 at 03:35:40PM +0200, Frans van Berckel wrote:
> Package: soapysdr0.6-module-audio
> Version: 0~git20160607-3
> 
> On a Pi: Found a strange link, with name brackets, when exec ldd.
> 
> $ ldd /usr/lib/arm-linux-
> gnueabihf/SoapySDR/modules0.6/libaudioSupport.so
> 
> linux-vdso.so.1 (0xbefe5000)
> /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-
> linux-gnueabihf/libarmmem-v7l.so (0xb6f51000)
> libhamlib.so.2 => /usr/lib/arm-linux-gnueabihf/libhamlib.so.2
> (0xb6ca4000)

I've been looking into this and I don't think this is a Debian thing. It
looks like Raspbian which, from what I understand, preloads this
library by default. At least I don't see a reference to libarmmem in the
Debian binaries.

Can you please confirm whether this is on Raspbian or not?

Bug#916485: ghdl has circular Depends on ghdl-gcc

[Andreas Bombe]

On Fri, Dec 14, 2018 at 11:08:57PM +0100, Bill Allombert wrote:
> Package: ghdl
> Version: 0.35+git20181129+dfsg-2
> Severity: important
> 
> Hello ghdl-llvm maintainers,
> 
> There is a circular dependency between ghdl and ghdl-gcc:
> 
> ghdl  :Depends: ghdl-mcode | ghdl-gcc | ghdl-llvm
> ghdl-gcc  :Depends: ghdl (= 0.35+git20181129+dfsg-2)
> 
> Circular dependencies are known to cause problems
> during upgrade between stable releases, so we should try to avoid them.

This dependency is because of the ghdl package containing the common
files. I haven't considered circular dependencies when I decided to do
that instead of a separate package.

I will move the common files out into a new ghdl-common package and
leave the ghdl package as a mostly empty dependency package.

Bug#955257: neomutt: Creates broken mbox headers when saving from Maildir

[Andreas Bombe]

Package: neomutt
Version: 20191207+dfsg.1-1.1
Severity: important

While reading a Maildir folder with neomutt I accidentally saved mails
into an existing mbox file rather than another Maildir as I meant to,
but when I opened that mbox file I could not see these mails (and not
with mutt either).

Debug log shows that the date in the header is wrong:

[2020-03-28 20:16:18]<1> is_from()  expected weekday, got: Sa Mär 28 02:33:48 
2020

[2020-03-28 20:16:18]<1> is_from()  expected weekday, got: Mi Feb 12 11:45:21 
2020

[2020-03-28 20:16:18]<1> is_from()  expected weekday, got: Mi Feb 12 05:07:36 
2020

[2020-03-28 20:16:18]<1> is_from()  expected weekday, got: Do Feb 13 13:45:56 
2020

As you can see, the dates are localized to German which they aren't
supposed to be. This does not happen when I save with mutt instead, or
when I use neomutt to save from mbox to mbox.

I'm not sure about the timing, but the same mbox contains good messages
from when I saved to it earlier, so possibly this bug appeared only in
the latest neomutt upload.

Marked this as important since it constitutes a sort of silent data
loss. The messages aren't really lost (they can be restored by manual
editing of the mbox), but neither mutt nor neomutt even make any mention
that they are not displaying messages because of errors outside the
debug log.


-- Package-specific info:
NeoMutt 20191207
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.4.0-4-amd64 (x86_64)
ncurses: ncurses 6.2.20200212 (compiled with 6.2.20200212)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
libnotmuch: 5.2.0
hcache backends: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-bCiSXv/neomutt-20191207+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  -autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime 
  -sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.30-4
ii  libgnutls30   3.6.12-2
ii  libgpg-error0 1.37-1
ii  libgpgme111.13.1-7
ii  libgssapi-krb5-2  1.17-7
ii  libidn11  1.33-2.2
ii  liblua5.3-0   5.3.3-1.1+b1
ii  libncursesw6  6.2-1
ii  libnotmuch5   0.29.3-1+b2
ii  libsasl2-22.1.27+dfsg-2
ii  libtinfo6 6.2-1
ii  libtokyocabinet9  1.4.48-12

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2
ii  locales   2.30-4
ii  mime-support  3.64

Versions of packages neomutt suggests:
ii  aspell 0.60.8-1
ii  ca-certificates20190110
ii  exim4-daemon-light [mail-transport-agent]  4.93-13
ii  gnupg   

Bug#942658: lintian: False positive for Python 2 python-package-missing-depends-on-python

[Andreas Bombe]

Package: lintian
Version: 2.28.0
Severity: normal

I'm starting to get a python-package-missing-depends-on-python error on
a package that didn't have it in its previous revision (with only minor
changes).

Comparing the built packages shows that the latest version of dh-python
now generates dependencies on python2 instead of python. However,
lintian only considers python and python-minimal as a valid Python 2
dependency.

Adding python2 and python2-minimal to the list of Python 2 package names
should be sufficient to fix this.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils 2.33.1-1
ii  bzip21.0.8-2
ii  diffstat 1.62-1+b1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b2
ii  libarchive-zip-perl  1.67-1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.8.7-3
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-7
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.33.1-1
ii  libhtml-parser-perl3.72-3+b4
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#942554: transition: soapysdr

[Andreas Bombe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi release team,

I want to transition soapysdr and limesuite with it. These would be the
auto-soapysdr and auto-limesuite trackers that appear to look fine.

There are a whole bunch of additional auto-soapy* trackers that
correspond to all the plugin module packages that are in a cross
dependency situation with the core soapysdr. They can be ignored as they
will be uploaded together with soapysdr (all of them are ready in
experimental).

limesuite provides a soapysdr plugin that needs to transition
together with the others, but it also has its own library transition
going. My fault, I haven't been paying attention to a team member upload
when preparing soapysdr. But it adds only one package, so rather than
disentangle I'd like to do both in one go.

I've test built the reverse dependencies and they all compiled fine with
the exception of srslte, which is already FTBFS due to libbladerf
changes, and gr-limesdr, which is FTBFS in unstable but has a fixed
version in experimental.


Ben file:
title = "soapysdr+limesuite";
is_affected = .depends ~ "libsoapysdr0.6" | .depends ~ "liblimesuite18.06-1" | 
.depends ~ "libsoapysdr0.7" | .depends ~ "liblimesuite19.04-1";
is_good = .depends ~ "libsoapysdr0.7" | .depends ~ "liblimesuite19.04-1";
is_bad = .depends ~ "libsoapysdr0.6" | .depends ~ "liblimesuite18.06-1";

Bug#939561: soapybladerf ftbfs in unstable

[Andreas Bombe]

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#919621: lvm2: Update unexpectedly activates system ID check, bypassing impossible

[Andreas Bombe]

Package: lvm2
Version: 2.03.02-1
Severity: important

There are possibly 2 different bugs in here, please clone as needed.

This computer has multiple VGs and had last been updated on Dec 13
before I ran an update on Jan 13. After this update it wouldn't complete
boot because one VG would not be activated due to system ID mismatch.

It dropped me into a root/rescue shell where I had full access to lvm
tools since the root filesystem was not in the affected VG.

The affected VG is ancient and has moved between computers and disks. It
has a system ID set from way back when (it includes a hostname I haven't
used for possibly more than a decade) while the newer, unaffected VGs
have blank system IDs. The system is configured to have no system ID
(system_id_source = "none").


Bug 1:

This has worked for all these years until the update, which rejects the
VG with system ID without advance warning during package upgrade. Systems
may become unbootable after upgrade if these VGs contain filesystems
that are mounted in /etc/fstab.


Bug 2:

Overriding system IDs does not work. I have tried setting
local/extra_system_ids as described in lvmsystemid(7) but this appears
to have no effect whatsoever. I could neither access the VG nor use
vgchange to clear its system ID, access was still rejected. I tried both
setting the variable in /etc/lvmlocal.conf and on the command line, and
confirmed with lvmconfig that the option is seen.

The only way to get access was to set global/system_id_source =
"lvmlocal" and set local/system_id to the affected VG's system ID.


I found this thread on the debian-user list where someone else appears
to have exactly the same problems:
https://lists.debian.org/msgid-search/20190113161023.ge10...@zaphod.galacticempire.org.us
 

-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-1
ii  dmsetup   2:1.02.155-1
ii  libaio1   0.3.111-1
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-5
ii  libdevmapper-event1.02.1  2:1.02.155-1
ii  libdevmapper1.02.12:1.02.155-1
ii  libreadline5  5.2+dfsg-3+b2
ii  libselinux1   2.8-1+b1
ii  libsystemd0   240-4
ii  libudev1  239-15
ii  lsb-base  10.2018112800

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.6-2

lvm2 suggests no packages.

-- Configuration Files:
/etc/lvm/lvm.conf changed [not included]
/etc/lvm/lvmlocal.conf changed [not included]

-- no debconf information

Bug#905522: ghdl: Incomplete debian/copyright?

[Andreas Bombe]

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#824883: bug#824883

[Andreas Bombe]

On Fri, Jan 05, 2018 at 08:46:37PM +0100, Fabio Scotoni wrote:
> This issue is still current; I just wanted to add that SIMH has also
> published bug fixes for 3.9-0 on their website:
> http://simh.trailing-edge.com/interim/
> 
> Supposedly, these include "important fixes  for the VAX780, PDP-11, and
> 1401". It may be worth to include those in an update to 3.9.
> 
> The most recent file on there is from 2014, however. The same goes for
> beta releases on GitHub. I'm unsure of the versioning policy that SIMH
> follows; maybe it is worth considering picking a specific git commit for
> the time being and stabilizing that.

I have been working on an update for some time. As you found out, 3.9 is
obsolete already and the development has moved to GitHub.  The current
upstream maintainers are not interested in making releases so I will
have to package git snapshots.

SIMH being a collection of lots of different simulators with often
different licenses, not to mention plenty of embedded (non-free or
completely unclear licensed) firmware, it takes a lot of time to get
right while I am also working on other complex packages.

For that matter I have already packaged simtools (still in
experimental), which are all the tools that were split out of SIMH
upstream into their own repository.

Bug#881884: cc65: Override the "Git N/A" in version string with Debian version

[Andreas Bombe]

Package: cc65
Version: 2.16-1
Severity: wishlist
Tags: patch

The build embeds the git hash of the source checkout, if it finds one,
into the version string. It makes sense for upstream to see from which
commit it was built, not so much in package building where it's "Git
N/A" if git wasn't used for maintaining the package.

The attached patch changes it to embed the Debian package version
instead to look like:

  % bin/cc65 --version
  cc65 V2.16 - Debian 2.16-1

The embedded patch to src/Makefile and src/common/version.c should be
upstreamable later since it doesn't change the behaviour if the new
variable PKG_VERSION isn't defined during build.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cc65 depends on:
ii  libc6  2.24-17

cc65 recommends no packages.

cc65 suggests no packages.

-- no debconf information
diff --git a/debian/patches/package-version b/debian/patches/package-version
new file mode 100644
index 000..10a35be
--- /dev/null
+++ b/debian/patches/package-version
@@ -0,0 +1,47 @@
+Description: Allow overriding git hash in version string with package version
+ When compiling cc65, it will place the git hash of the checked out commit in
+ the version string which isn't useful when building a distribution package
+ since there either won't be an upstream git hash if there is one at all. Make
+ it so that if the variable PKG_VERSION is defined when building, its contents
+ will be placed into the version string instead of the git hash.
+Author: Andreas Bombe <a...@debian.org>
+Last-Update: 2017-11-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: cc65work/src/Makefile
+===
+--- cc65work.orig/src/Makefile 2017-11-16 01:54:30.795532327 +0100
 cc65work/src/Makefile  2017-11-16 02:21:19.661770273 +0100
+@@ -62,11 +62,16 @@
+   endif
+ endif
+ 
++ifdef PKG_VERSION
++  $(info PKG_VERSION: $(PKG_VERSION))
++  DEF_PKGVER := -DPKG_VERSION="$(PKG_VERSION)"
++endif
++
+ CFLAGS += -MMD -MP -O -I common \
+   -Wall -Wextra -Wno-char-subscripts $(USER_CFLAGS) \
+   -DCA65_INC=$(CA65_INC) -DCC65_INC=$(CC65_INC) 
-DCL65_TGT=$(CL65_TGT) \
+   -DLD65_LIB=$(LD65_LIB) -DLD65_OBJ=$(LD65_OBJ) 
-DLD65_CFG=$(LD65_CFG) \
+-  -DGIT_SHA=$(GIT_SHA)
++  -DGIT_SHA=$(GIT_SHA) $(DEF_PKGVER)
+ 
+ LDLIBS += -lm
+ 
+Index: cc65work/src/common/version.c
+===
+--- cc65work.orig/src/common/version.c 2017-11-16 01:54:30.815532304 +0100
 cc65work/src/common/version.c  2017-11-16 02:07:10.974699766 +0100
+@@ -61,7 +61,9 @@
+ /* Returns the version number as a string in a static buffer */
+ {
+ static char Buf[60];
+-#if defined(GIT_SHA)
++#if defined(PKG_VERSION)
++xsnprintf (Buf, sizeof (Buf), "%u.%u - %s", VER_MAJOR, VER_MINOR, 
STRINGIZE (PKG_VERSION));
++#elif defined(GIT_SHA)
+ xsnprintf (Buf, sizeof (Buf), "%u.%u - Git %s", VER_MAJOR, VER_MINOR, 
STRINGIZE (GIT_SHA));
+ #else
+ xsnprintf (Buf, sizeof (Buf), "%u.%u", VER_MAJOR, VER_MINOR);
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..b124d3e
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+package-version
diff --git a/debian/rules b/debian/rules
index 33e2c66..e7dd4d7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,8 +4,11 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+include /usr/share/dpkg/pkg-info.mk
+include /usr/share/dpkg/vendor.mk
+
 override_dh_auto_build:
-   dh_auto_build -- prefix=/usr
+   dh_auto_build -- prefix=/usr PKG_VERSION="$(DEB_VENDOR) $(DEB_VERSION)"
$(MAKE) -C doc html
 
 override_dh_auto_install:

Bug#881874: cc65 package should suggest cc65-doc package

[Andreas Bombe]

Package: cc65
Version: 2.16-1
Severity: wishlist

This doesn't appear to be in policy, but common practice is that the
main package at least Suggests: the documentation package (some packages
use Recommends:).

Currently only the opposite (cc65-doc Recommends: cc65) is in effect.
There does not seem to be consensus among doc packages on that. Some do
Suggests:, some Recommends:, some nothing at all. So I guess there is no
reason to change that.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cc65 depends on:
ii  libc6  2.24-17

cc65 recommends no packages.

cc65 suggests no packages.

-- no debconf information

Bug#880942: ITP: ghdl -- VHDL 2008/93/87 simulator

[Andreas Bombe]

On Thu, Nov 09, 2017 at 02:45:37PM +0800, Paul Wise wrote:
> On Mon, Nov 6, 2017 at 7:51 AM, Andreas Bombe wrote:
> 
> > Back then we all agreed that writing free replacements was the way to go
> > but I never got around to help out with that. Turns out upstream has
> > implemented that in the meantime (not yet for VHDL 2008 though) so I
> > guess now is the time to really bring it back.
> 
> Please note the extra steps required when reintroducing packages:
> 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

I haven't contacted the previous maintainer because he orphaned the
package long before it was removed (citing changed interests) and
because he is hardly active in Debian anymore.

Since upstream now offers LLVM and its own code generator as backends in
addition to GCC and I want to package all of these, packaging
requirements have changed considerably so most of it will be new.

Is there anything else I forgot to address?

Bug#880942: ITP: ghdl -- VHDL 2008/93/87 simulator

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: ghdl
  Version : 0.35-dev
  Upstream Author : Tristan Gingold
* URL : https://github.com/tgingold/ghdl
* License : GPL-2+
  Programming Lang: Ada, VHDL
  Description : VHDL 2008/93/87 simulator

 GHDL is a simulator for hardware designs written in VHDL. It is not an
 interpreter, it generates machine code from your design for high speed
 simulation. GHDL fully supports IEEE 1076-1987, IEEE 1076-1993, IEEE
 1076-2002 and partially the IEEE 1076-2008 version of VHDL.


This package has been in Debian previously and stagnated due to slow
upstream activity at the time (last maintainer upload 2010, orphaned
2012) and was finally removed from the archive last year. I was briefly
involved in an attempt to revive the package in Debian but I considered
the non-free license of the IEEE sources for the essential standard
library definitions problematic (even though it has been in Debian in
that state for over a decade).

Back then we all agreed that writing free replacements was the way to go
but I never got around to help out with that. Turns out upstream has
implemented that in the meantime (not yet for VHDL 2008 though) so I
guess now is the time to really bring it back.

I am not yet a member of the Debian Electronics Team, but I think this
package should fit in there (like the Verilog simulator iverilog).

Bug#871117: festival: FTBFS: /bin/sh: 1: g++-6: not found

[Andreas Bombe]

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

[Andreas Bombe]

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#878257: ITP: simtools -- Various converter tools and assemblers for simh

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: simtools
  Version : git 20170329 (no releases available)
  Upstream Author : Robert M. Supnik
* URL : https://github.com/simh/simtools
* License : Various Expat, BSD
  Programming Lang: C
  Description : Tools and assemblers useful in conjunction with simh

This package contains a collection of tools useful in conjunction with
the simh computer emulation suite. Among the tools are file converters
to create simh image files from other formats and a set of MACRO
compatible cross-assemblers for the PDP-1, PDP-7, PDP-8 and PDP-11.


Note that this package isn't exactly new, currently the simh package
merges the contents of the simh and simtools tarballs into one package.
Since upstream development has moved to GitHub and into separate
repositories, I intend to split out simtools into its own package as
part of updating simh.

Bug#874626: nmu: gnuradio_3.7.11-1 gr-osmosdr_0.1.4-12

[Andreas Bombe]

On Fri, Sep 08, 2017 at 11:41:51AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 08 Sep 2017, Raphaël Hertzog wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > 
> > nmu gnuradio_3.7.11-1 . ANY . unstable . -m "Rebuild for codecs2 transition"
> 
> Here it seems to be last and only update needed of the codecs2 
> (uncoordinated) transition.
> 
> > nmu gr-osmosdr_0.1.4-12 . ANY . unstable . -m "Rebuild for soapysdr 
> > transition"
> 
> But this one seems to be part of two unreported transitions that affect more 
> packages:
> https://release.debian.org/transitions/html/auto-uhd.html
> (and soapysdr that has no auto-tracker page but which seems to be complete 
> after the gr-osmosdr
> bin-nmu)

soapysdr is completed, it's just that there are cross dependencies
between soapysdr and soapysdr modules so it triggered almost a dozen
auto transitions. Last thing missing was gr-osmosdr, which wasn't in
testing. Transition dependencies would have been uhd → soapyuhd →
soapysdr.

> Maitland, Andreas, it would be nice if you could handle library transitions
> in coordination with the release team:
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions

I thought I could handle it by myself since there was only one
dependency (gr-osmosdr) where I wasn't uploader. After reviewing the
process and seeing how my first soapysdr transition panned out, I'll
follow the official process in the future.

Bug#869380: limesuite: Please update to newer release

[Andreas Bombe]

On Sat, Jul 22, 2017 at 11:07:26PM +0200, Sebastian Reichel wrote:
> Please update limesuite again. It is required for newer
> firmware. While I do not know the exact changelog for
> the newer firmware it fixes a power management related
> issue. Before the LimeSDR reached high temperatures in
> no time while doing nothing. After updating the firmware
> it only warms up by 5-10° in idle mode.

Like the rest of packages providing SoapySDR modules, I'm waiting for
my SoapySDR upload to be accepted (binary-NEW due to soname change). I
will make uploads of all these packages soon afterwards.

Bug#858591: limesuite: Please update to newer release

[Andreas Bombe]

On Fri, Mar 24, 2017 at 08:27:15AM +0100, Sebastian Reichel wrote:
> I received my LimeSDR yesterday and it comes with a newer FW than
> expected by limesuite resulting in incorrect behaviour in lots of
> places. The following information is printed to standard output:

This is rather unfortunate concerning that we are already in a release
freeze. If it is useless for the batch of boards that reached the
majority of buyers (I had the same problem with my own new LimeSDR) then
I should try to get the newer package into the release.

For now, I will upload to experimental shortly.

Bug#827710: ITP blocked by missing non-free JSON in poco

[Andreas Bombe]

block 827710 by 856192
thanks

Pothos uses the JSON component of the Poco library, which is missing due
to the Evil license. Packaging can't move forward until there is a
solution to that.

Bug#856985: systemd: Uninstalling systemd-cron hangs/crashes systemd

[Andreas Bombe]

On Tue, Mar 07, 2017 at 10:05:38AM +0100, Michael Biebl wrote:
> Andreas, can you confirm that stopping the cron-update.path unit prior
> to the removal avoids the crash? You will have to edit
> /lib/systemd/system/cron-update.path to remove
>  RefuseManualStart=true
>  RefuseManualStop=true

I did:
- install systemd-cron again
- remove those lines
- systemctl daemon-reload (to pick up these changes)
- systemctl stop cron-update.path
- installed cron at the same time systemd-cron is uninstalled

Now I have seen no crash or other problems.

Bug#856985: systemd: Uninstalling systemd-cron hangs/crashes systemd

[Andreas Bombe]

For the record, my bug appears to have been reported before as #776863.

I have generated a more complete backtrace from the same core:

[New LWP 2615]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `init -z   '.
Program terminated with signal SIGABRT, Aborted.
#0  0x7fc21779775b in raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#0  0x7fc21779775b in raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = 0
pid = 
#1  0x7fc217bed4a8 in crash.lto_priv.235 (sig=6) at ../src/core/main.c:158
rl = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615}
sa = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0 }}, sa_flags = 0, sa_restorer = 0x0}
__func__ = "crash"
__PRETTY_FUNCTION__ = "crash"
#2  
No locals.
#3  0x7fc217412067 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 1
selftid = 1
#4  0x7fc217413448 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0, 0, 0, 140723367238544, 8470013455670654208, 
140471598453408, 140471599596034, 140471599626432, 2, 0, 140471599487084, 1312, 
140471599167644, 140471602020864, 140471606932912, 0}}, sa_flags = 406101440, 
sa_restorer = 0x7fc2183b7590}
sigs = {__val = {32, 0 }}
#5  0x7fc217c95ec2 in log_assert_failed (text=text@entry=0x7fc217cbef00 
"s->exec_command[SERVICE_EXEC_START]", file=file@entry=0x7fc217cb8202 
"../src/core/service.c", line=line@entry=1312, func=func@entry=0x7fc217cbf8c0 
<__PRETTY_FUNCTION__.15381> "service_enter_start") at ../src/shared/log.c:709
No locals.
#6  0x7fc217c65c0f in service_enter_start (s=s@entry=0x7fc218349dc0) at 
../src/core/service.c:1312
c = 
pid = 32706
r = 
__PRETTY_FUNCTION__ = "service_enter_start"
__func__ = "service_enter_start"
#7  0x7fc217c67d41 in service_sigchld_event.lto_priv.376 (u=0x7fc218349dc0, 
pid=, code=, status=0) at 
../src/core/service.c:2337
f = SERVICE_SUCCESS
__PRETTY_FUNCTION__ = "service_sigchld_event"
__func__ = "service_sigchld_event"
#8  0x7fc217c9ab87 in manager_dispatch_sigchld (m=0x7fc2182d9380) at 
../src/core/manager.c:1639
name = 0x7fc2182ea490 "systemctl"
u = 
si = {si_signo = 17, si_errno = 0, si_code = 1, _sifields = {_pad = 
{2599, 0 }, _kill = {si_pid = 2599, si_uid = 0}, _timer = 
{si_tid = 2599, si_overrun = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, 
_rt = {si_pid = 2599, si_uid = 0, si_sigval = {sival_int = 0, sival_ptr = 
0x0}}, _sigchld = {si_pid = 2599, si_uid = 0, si_status = 0, si_utime = 0, 
si_stime = 0}, _sigfault = {si_addr = 0xa27, si_addr_lsb = 0}, _sigpoll = 
{si_band = 2599, si_fd = 0}, _sigsys = {_call_addr = 0xa27, _syscall = 0, _arch 
= 0}}}
__PRETTY_FUNCTION__ = "manager_dispatch_sigchld"
__func__ = "manager_dispatch_sigchld"
#9  0x7fc217c9c645 in manager_dispatch_signal_fd.lto_priv.926 (source=0x1, 
fd=1, revents=6, userdata=0x7fc2182d9380) at ../src/core/manager.c:1890
sfsi = {ssi_signo = 17, ssi_errno = 0, ssi_code = 1, ssi_pid = 2599, 
ssi_uid = 0, ssi_fd = 0, ssi_tid = 0, ssi_band = 0, ssi_overrun = 0, ssi_trapno 
= 0, ssi_status = 0, ssi_int = 0, ssi_ptr = 0, ssi_utime = 0, ssi_stime = 0, 
ssi_addr = 0, __pad = '\000' }
__PRETTY_FUNCTION__ = "manager_dispatch_signal_fd"
__func__ = "manager_dispatch_signal_fd"
#10 0x7fc217bf10b0 in source_dispatch (s=0x7fc2182d9a50) at 
../src/libsystemd/sd-event/sd-event.c:2016
__PRETTY_FUNCTION__ = "source_dispatch"
__func__ = "source_dispatch"
#11 0x7fc217bf22ff in sd_event_run (e=0x7fc2182d81a0, timeout=) at ../src/libsystemd/sd-event/sd-event.c:2314
ev_queue = 
ev_queue_max = 
p = 
r = 0
i = 
m = 3
timedout = false
__PRETTY_FUNCTION__ = "sd_event_run"
#12 0x7fc217c9b951 in manager_loop (m=0x7fc2182d9380) at 
../src/core/manager.c:2009
wait_usec = 1
rl = {interval = 100, begin = 838679736, burst = 5, num = 7}
__PRETTY_FUNCTION__ = "manager_loop"
__func__ = "manager_loop"
#13 0x7fc217be9a56 in main (argc=3, argv=) at 
../src/core/main.c:1748
m = 0x7fc2182d9380
r = 
retval = 1
before_startup = 
after_startup = 
timespan = 
"s\302x\356.cx\204\221U_\025J=G\363BE\325\354/cx\204\060cx\204\221x\251ݹ\373\062\000\362?\355s\240sU\241\063S\247\273\313\333\343\370D\366H\023\067|h%\332\f\026\211"
fds = 0x0
reexecute = false
shutdown_verb = 0x0
initrd_timestamp = {realtime = 0, monotonic = 0}
userspace_timestamp = {realtime = 1488663133807319, 

Bug#856985: systemd: Uninstalling systemd-cron hangs/crashes systemd

[Andreas Bombe]

It was pointed out to me that there should be core dumps and indeed
there were from both instances of it happening to me. Here is one
backtrace, the other looks identical:

#0  0x7fc21779775b in raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x7fc217bed4a8 in crash.lto_priv.235 (sig=6) at ../src/core/main.c:158
#2  
#3  0x7fc217412067 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#4  0x7fc217413448 in __GI_abort () at abort.c:89
#5  0x7fc217c95ec2 in log_assert_failed (text=text@entry=0x7fc217cbef00 
"s->exec_command[SERVICE_EXEC_START]", 
file=file@entry=0x7fc217cb8202 "../src/core/service.c", 
line=line@entry=1312, 
func=func@entry=0x7fc217cbf8c0 <__PRETTY_FUNCTION__.15381> 
"service_enter_start") at ../src/shared/log.c:709
#6  0x7fc217c65c0f in service_enter_start (s=s@entry=0x7fc218349dc0) at 
../src/core/service.c:1312
#7  0x7fc217c67d41 in service_sigchld_event.lto_priv.376 (u=0x7fc218349dc0, 
pid=, code=, status=0)
at ../src/core/service.c:2337
#8  0x7fc217c9ab87 in manager_dispatch_sigchld (m=0x7fc2182d9380) at 
../src/core/manager.c:1639
#9  0x7fc217c9c645 in manager_dispatch_signal_fd.lto_priv.926 (source=0x1, 
fd=1, revents=6, userdata=0x7fc2182d9380)
at ../src/core/manager.c:1890
#10 0x7fc217bf10b0 in source_dispatch (s=0x7fc2182d9a50) at 
../src/libsystemd/sd-event/sd-event.c:2016
#11 0x7fc217bf22ff in sd_event_run (e=0x7fc2182d81a0, timeout=) at ../src/libsystemd/sd-event/sd-event.c:2314
#12 0x7fc217c9b951 in manager_loop (m=0x7fc2182d9380) at 
../src/core/manager.c:2009
#13 0x7fc217be9a56 in main (argc=3, argv=) at 
../src/core/main.c:1748

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[Andreas Bombe]

On Thu, Dec 29, 2016 at 10:18:07PM +0100, John Paul Adrian Glaubitz wrote:
> That's correct. But I usually rather prefer fixing a package everywhere
> than just saying "Works on amd64, I don't care about the rest because
> I don't use anything else.".
>
> My point is, if you upload it now, you have more testing time for the
> package on all release architectures being part of testing and more
> time to make sure the patch is not breaking anything else.

If I upload now, it won't be part of the stretch release. I'd definitely
have a lot of time for testing then, but who guarantees that mips and
mipsel will still be release architectures for buster?

So I'd rather have it work on all release architectures and actually be
in the release.


Andreas

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[Andreas Bombe]

On Wed, Dec 28, 2016 at 04:29:52PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/28/2016 04:18 PM, Radovan Birdic wrote:
> > Here is new generic patch that should work for all architectures.
> > I added "--as-needed" flag that ensures linking with latomic library only 
> > if it is necessary.
> > 
> > With this patch package builds successfully on mips, mipsel, mips64el and 
> > i386.
> 
> And on powerpc as well, just verified on the porterbox.
> 
> Thanks for the updated patch!

Thanks for the work. I was aware of the build failure but I will wait
until the package has made it to testing before uploading a fix.

That patch would also enable --as-needed generally as I understand it. I
didn't try that, but if it works so much the better.

I will upload this fix in a few days then.


Andreas

Bug#849536: limesuite FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[Andreas Bombe]

On Thu, Dec 29, 2016 at 10:02:01PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/29/2016 09:57 PM, Andreas Bombe wrote:
> > Thanks for the work. I was aware of the build failure but I will wait
> > until the package has made it to testing before uploading a fix.
> 
> Not sure why. It affects two release architectures, so the package would
> be missing in testing for release architectures. I would upload it right
> away to have the package fixed everywhere on all release architectures
> as soon as possible, but it's, of course, up to you.

1) Right now would still be too late with the 10 day transition in
   effect.
2) Unless I'm mistaken, a build failure on release architectures is only
   a blocker if it previously built on that architecture. At least the
   testing excuses list appears to only mention age < 10 days to block
   transition.

Either way, an upload right now would be no help at best.


Andreas

Bug#848201: dosfstools: fails to format fat-32 500Mb partition in installer 'guided LVM' install

[Andreas Bombe]

On Thu, Dec 15, 2016 at 02:16:30AM +, Wookey wrote:
> This was all going well until I picked 'Guided LVM' install. 
> It wanted to format
> sdb1  499MB fat (ESP partition)
> sdb2  250MB ext2 (/boot)
> sdb3  rest of 1GB drive (LVM partition)
> 
> This failed with a message about 'partition too small for fat-32'.
> 
> Some investigation found that running:
> # mkfs.fat /dev/sdb1 
> did indeed fail: WARNING: Not enough clusters for a 32-bit FAT

This is a problem, as it appears it decided to do FAT32 and then found
that there are not enough clusters. It shouldn't automatically select
FAT32 in that case.

That alone wouldn't make it fail though, but the result isn't valid as
the number of clusters is how FAT12/FAT16/FAT32 are properly identified.

> whilst 
> # mkfs.fat -F 16 /dev/sdb1 worked fine.
> 
> This is odd because a 500MB fat-32 partition is recommended
> (mandated?) for the UEFI ESP partition, so this really ought to work. 

Could it possibly have a sector size larger than 512 Bytes? In any case,
if you could run mkfs.fat with the -v option, the output might show more
clearly what leads it to selecting the wrong format.

Bug#847798: ITP: limesuite -- tools and drivers for Lime Microsystems LMS7002M RFIC

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: limesuite
  Version : git
  Upstream Author : Lime Microsystems <i...@limemicro.com>
* URL : https://myriadrf.org/projects/lime-suite/
* License : Apache-2.0
  Programming Lang: C++
  Description : tools and drivers for Lime Microsystems LMS7002M RFIC

The Lime Suite is a collection of tools of software supporting several
hardware platforms including the LimeSDR, drivers for the LMS7002M
transceiver RFIC, and other tools for developing with LMS7-based
hardware. It contains a SoapySDR driver module and tools to calibrate,
test and update the devices.


This will be maintained in the hamradio team.

Bug#847796: ITP: soapyredpitaya -- RedPitaya device support for SoapySDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapyredpitaya
  Version : 0.1.0
  Upstream Author : Pavel Demin
* URL : https://github.com/pothosware/SoapyRedPitaya/wiki
* License : GPL-3+
  Programming Lang: C++
  Description : RedPitaya device support for SoapySDR

The Soapy RedPitaya project provides a SoapySDR module for using the
RedPitaya hardware platform as a SDR transceiver.

This will be maintained in the hamradio team.

Bug#847795: ITP: soapyosmo -- use gr-osmosdr drivers in SoapySDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapyosmo
  Version : 0.2.4
  Upstream Author : Josh Blum <j...@pothosware.com>
* URL : https://github.com/pothosware/SoapyOsmo/wiki
* License : GPL-3
  Programming Lang: C++
  Description : OsmoSDR device support for SoapySDR

The SoapyOsmo project provides SoapySDR modules to access the OsmoSDR,
Mirics SDR, and RFSpace SDR hardware through the drivers in gr-osmosdr.

This will be maintained in the hamradio team.

Bug#847797: ITP: soapyairspy -- Airspy device support for SoapySDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapyairspy
  Version : 0.1.0
  Upstream Author : Charles J. Cliffe
* URL : https://github.com/pothosware/SoapyAirspy/wiki
* License : MIT
  Programming Lang: C++
  Description : Airspy device support for SoapySDR

The Soapy Airspy project provides a SoapySDR module for using the
Airspy Software Defined Radio receiver.


This will be maintained in the hamradio team.

Bug#846651: ITP: muparserx -- mathematical expression parser library

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: muparserx
  Version : 4.0.7
  Upstream Author : Ingo Berg <mupars...@beltoforion.de>
* URL : http://articles.beltoforion.de/article.php?a=muparserx=en
* License : BSD-2-clause
  Programming Lang: C++
  Description : mathematical expression parser library

  The evaluation of a mathematical expression is a standard task
  required in many applications. It can be solved by either using a
  standard math expression parser such as muparser or by embedding a
  scripting language such as Lua. There are however some limitations:
  Although muparser is pretty fast it will only work with scalar values
  and although Lua is very flexible it does neither support binary
  operators for arrays nor complex numbers. So if you need a math
  expression parser with support for arrays, matrices and strings
  muparserx may be able to help you. It was originally based on the
  original muparser engine but has since evolved into a standalone
  project with a completely new parsing engine.


I am packaging this because it is the dependency of pothos, which I will
also package.

Bug#838822: jfsutils: diff for NMU version 1.1.15-2.2

[Andreas Bombe]

Package: jfsutils
Version: 1.1.15-2.1
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for jfsutils (versioned as 1.1.15-2.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
reverted:
--- jfsutils-1.1.15/libfs/log_work.c
+++ jfsutils-1.1.15.orig/libfs/log_work.c
@@ -2406,7 +2406,6 @@
 	int32_t xlen, xlength;
 	int16_t nword;
 	int8_t upd_possible = 0;
-	struct dinode dip_local; /* Local copy of dinode data for alignment purposes */
 
 	if (ld->length <= 0)
 		return (0);
@@ -2709,8 +2708,7 @@
 			 */
 
 			if (ino_rem == 0) {	/* inode base segment  */
+dip = (struct dinode *) data;
-			  	memcpy(_local, data, size_dinode);
-dip = _local;
 if (ln == 1) {
 	/* ibase only */
 	if (db->db_ibase & mask_8)
diff -u jfsutils-1.1.15/debian/changelog jfsutils-1.1.15/debian/changelog
--- jfsutils-1.1.15/debian/changelog
+++ jfsutils-1.1.15/debian/changelog
@@ -1,3 +1,17 @@
+jfsutils (1.1.15-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Raise compat level for the cdbs invoked debhelper to 9 (Closes: #817508)
+  * Format utility list in description as properly list (Closes: #609793)
+  * Move 1.1.12-2.1 changes into its own patch file
+debian/patches/sparc-memory-alignment-fix.patch 
+  * Add ${misc:Depends} debhelper variables to Depends lines
+  * Add patch fix-mkfs-man-comment.patch to correct ./" unknown commands to
+.\" comments as they are intended
+  * Bump Standards-Version to 3.9.8, no changes required
+
+ -- Andreas Bombe <a...@debian.org>  Sun, 25 Sep 2016 13:37:53 +0200
+
 jfsutils (1.1.15-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u jfsutils-1.1.15/debian/compat jfsutils-1.1.15/debian/compat
--- jfsutils-1.1.15/debian/compat
+++ jfsutils-1.1.15/debian/compat
@@ -1 +1 @@
-4
+9
diff -u jfsutils-1.1.15/debian/control jfsutils-1.1.15/debian/control
--- jfsutils-1.1.15/debian/control
+++ jfsutils-1.1.15/debian/control
@@ -2,13 +2,13 @@
 Section: admin
 Priority: optional
 Maintainer: Stefan Hornburg (Racke) <ra...@linuxia.de>
-Build-Depends: cdbs, debhelper (>= 4.1.0), uuid-dev, quilt
-Standards-Version: 3.8.0
+Build-Depends: cdbs, debhelper (>= 9), uuid-dev, quilt
+Standards-Version: 3.9.8
 Homepage: http://jfs.sourceforge.net/
 
 Package: jfsutils
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: utilities for managing the JFS filesystem
  Utilities for managing IBM's Journaled File System (JFS) under Linux.
  .
@@ -18,20 +18,21 @@
  e-business file servers.
  .
  The following utilities are available:
- fsck.jfs - initiate replay of the JFS transaction log, and check and repair a
- JFS formatted device.
- logdump - dump a JFS formatted device's journal log.
- logredo - "replay" a JFS formatted device's journal log.
- mkfs.jfs - create a JFS formatted partition.
- xchkdmp - dump the contents of a JFS fsck log file created with xchklog.
- xchklog - extract a log from the JFS fsck workspace into a file.
- xpeek - shell-type JFS file system editor.
+  * fsck.jfs - initiate replay of the JFS transaction log, and check and
+repair a JFS formatted device.
+  * logdump - dump a JFS formatted device's journal log.
+  * logredo - "replay" a JFS formatted device's journal log.
+  * mkfs.jfs - create a JFS formatted partition.
+  * xchkdmp - dump the contents of a JFS fsck log file created with
+xchklog.
+  * xchklog - extract a log from the JFS fsck workspace into a file.
+  * xpeek - shell-type JFS file system editor.
 
 Package: jfsutils-udeb
 XC-Package-Type: udeb
 Architecture: any
 Section: debian-installer
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: A stripped-down version of jfsutils, for debian-installer
  This package is a jfsutils package built for reduced size, so that it
  can help to save space in debian-installer.
diff -u jfsutils-1.1.15/debian/patches/series jfsutils-1.1.15/debian/patches/series
--- jfsutils-1.1.15/debian/patches/series
+++ jfsutils-1.1.15/debian/patches/series
@@ -2,0 +3,2 @@
+sparc-memory-alignment-fix.patch
+fix-mkfs-man-comment.patch
only in patch2:
unchanged:
--- jfsutils-1.1.15.orig/debian/patches/fix-mkfs-man-comment.patch
+++ jfsutils-1.1.15/debian/patches/fix-mkfs-man-comment.patch
@@ -0,0 +1,78 @@
+--- a/mkfs/jfs_mkfs.8
 b/mkfs/jfs_mkfs.8
+@@ -38,43 +38,43 @@
+ 
+ .SH OPTIONS
+ 
+-./"*
+-./"*  block size has not been implemented yet  *
+-./"*
+-./".TP
+-./".BI \-b " block_size"
+-./"Set the block size for a new JFS partition
+-./".RS
+-./"
+-./"Options for
+-./".I block_size
+-./"are:
+-./".BR 512 ","
+-./".BR 1024 ","
+-./".BR 2048 ", or"
+-./".BR 4096 "."

Bug#817495: hp-ppd: diff for NMU version 0.9-0.3

[Andreas Bombe]

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#838314: ITP: soapyremote -- access SoapySDR devices over the network

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapyremote
  Version : 0.3.1
  Upstream Author : Josh Blum <j...@pothosware.com>
* URL : https://github.com/pothosware/SoapyRemote/wiki
* License : Boost Software License 1.0
  Programming Lang: C++
  Description : Access SoapySDR devices over the network

The SoapyRemote project provides both a server and a client module that
allow you to use a SoapySDR supported SDR device on a remote machine
just like a local device.


This will be maintained in the hamradio team.

Bug#838313: ITP: soapyuhd -- UHD plugins for SoapySDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapyuhd
  Version : 0.3.1
  Upstream Author : Josh Blum <j...@pothosware.com>
* URL : https://github.com/pothosware/SoapyUHD/wiki
* License : GPL-3
  Programming Lang: C++
  Description : UHD plugins for SoapySDR

The Soapy UHD project provides a SoapySDR module to use devices supported by
the Universal Hardware Driver by Ettus Research within the SoapySDR API and
software that supports SoapySDR. In addition, the project provides a UHD module
to use any SoapySDR device within the UHD API and UHD supported software.


This will be maintained in the hamradio team.

Bug#834379: ITP: soapyhackrf -- HackRF device support for SoapySDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapyhackrf
  Version : 0.2.1
  Upstream Author : jiangwei0...@gmail.com
* URL : https://github.com/pothosware/SoapyHackRF/wiki
* License : MIT
  Programming Lang: C++
  Description : HackRF device support for SoapySDR

The Soapy HackRF project provides a SoapySDR module for using the
HackRF open source Software Defined Radio transceiver.


This will be maintained in the hamradio team. I originally mentioned
this as part of the SoapySDR ITP, but now I decided to send separate
ITPs for the modules after all.

Bug#834380: ITP: soapybladerf -- BladeRF device support for SoapySDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapybladerf
  Version : 0.3.2
  Upstream Author : Josh Blum <j...@pothosware.com>
* URL : https://github.com/pothosware/SoapyBladeRF/wiki
* License : LGPL-2.1
  Programming Lang: C++
  Description : BladeRF device support for SoapySDR

The Soapy BladeRF project provides a SoapySDR module for using the
BladeRF Software Defined Radio transceiver.


This will be maintained in the hamradio team. I originally mentioned
this as part of the SoapySDR ITP, but now I decided to send separate
ITPs for the modules after all.

Bug#834381: ITP: soapyaudio -- Audio device support for SoapySDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapyaudio
  Version : 0.0
  Upstream Author : Charles J. Cliffe <c...@cubicproductions.com>
* URL : https://github.com/pothosware/SoapyAudio/wiki
* License : MIT
  Programming Lang: C++
  Description : Audio device support for SoapySDR

The Soapy Audio project provides a SoapySDR module for using Software
Defined Radio devices that are connected through audio interfaces.
It uses hamlib to provide control of tuning and other functions where
available.


This will be maintained in the hamradio team. I originally mentioned
this as part of the SoapySDR ITP, but now I decided to send separate
ITPs for the modules after all.

Bug#834378: ITP: soapyrtlsdr -- RTL-SDR device support for SoapySDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapyrtlsdr
  Version : 0.2.1
  Upstream Author : Charles J. Cliffe <c...@cubicproductions.com>
* URL : https://github.com/pothosware/SoapyRTLSDR/wiki
* License : MIT
  Programming Lang: C++
  Description : RTL-SDR device support for SoapySDR

The Soapy RTL-SDR project provides a SoapySDR module for using low cost
DVB-T/DAB+ USB dongles based on the Realtek RTL2832U chip as receivers.


This will be maintained in the hamradio team. I originally mentioned
this as part of the SoapySDR ITP, but now I decided to send separate
ITPs for the modules after all.

Bug#832114: ITP: liquid-dsp -- digital signal processing library for SDR

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: liquid-dsp
  Version : 1.2.0
  Upstream Author : Joseph D. Gaeddert <jos...@liquidsdr.org>
* URL : https://github.com/jgaeddert/liquid-dsp
* License : MIT
  Programming Lang: C
  Description : digital signal processing library for SDR

liquid is a digital signal processing (DSP) library designed
specifically for software-defined radios on embedded platforms. The aim
is to provide a lightweight DSP library that does not rely on a myriad
of external dependencies or cumbersome frameworks. All signal processing
elements are designed to be flexible, scalable, and dynamic, including
filters, filter design, oscillators, modems, synchronizers, and complex
mathematical operations. 


This library is a dependency of CubicSDR which I am packaging. Note that
the 1.2.0 version released in 2012 is still licensed as GPL, it is
relicensed as MIT in current git. This package will be maintained within
the hamradio team.

Bug#829516: ITP: cubicsdr -- software defined radio receiver

[Andreas Bombe]

On Sun, Jul 03, 2016 at 09:36:01PM -0400, A. Maitland Bottoms wrote:
> I have been considering packaging the liquidsdr library too.

Do you still consider it? I wouldn't mind if one or two dependencies of
my ITPs get packaged by someone else.

> For CubicSDR, I think the existing fonts-dejavu package could be used
> instead of the CubicSDR/font directory.

I haven't yet looked into how the program works yet, why would it be
desirable to not use the included font?


> Good luck,
> -Maitland

Thanks,
Andreas

Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1

[Andreas Bombe]

On Sun, Jun 26, 2016 at 09:27:57AM +0200, Petter Reinholdtsen wrote:
> 
> Andreas, while I wait for a reply from the release managers, it would be
> great to know the answer to this question:
> 
> [Petter Reinholdtsen]
> > OK to push it to the collab-maint git repo before upload, or should I
> > wait until it is accepted?

If you strongly expect it to be accepted as it is, then push it.

Or wait with tagging until it is accepted. Moving tags and releases that
aren't releases after all is something I'd like to avoid.

Bug#829516: ITP: cubicsdr -- software defined radio receiver

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: cubicsdr
  Version : 0.2.0-beta-rc2
  Upstream Author : Charles J. Cliffe <c...@cubicproductions.com>
* URL : http://cubicsdr.com
* License : GPL
  Programming Lang: C++
  Description : software defined radio receiver

CubicSDR is a cross-platform graphical Software-Defined Radio
application providing waterfall displays which allows you to navigate
the radio spectrum and demodulate any signals you might discover. It
currently includes several common analog demodulation schemes such as FM
and AM including single sideband modes.

Any hardware supported by a SoapySDR module can be used as a receiver by
CubicSDR.

Bug#827709: ITP: soapysdr -- software defined radio interface library

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: soapysdr
  Version : 0.4.3
  Upstream Author : Josh Blum / Pothosware
* URL : https://github.com/pothosware/SoapySDR/wiki
* License : Boost Software License
  Programming Lang: C++
  Description : software defined radio interface library

SoapySDR is a library providing a common interface to SDR (software
defined radio) hardware. Support for different hardware is added through
external modules.


This is a dependency of the SDR support in pothos (see my other ITP). I
intend to package the hardware support for audio, UHD, BladeRF, Osmo,
RTL-SDR, HackRF, RedPitaya and Airspy (these add GPL3 and MIT to the set
of licenses). Since these are separate projects without a common release
schedule, it appears I will have to package them as separate source
packages.

Bug#827710: ITP: pothos -- data flow programming framework with computational offload capability

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe <a...@debian.org>

* Package name: pothos
  Version : 0.3.3
  Upstream Author : Pothosware / Josh Blum
* URL : https://github.com/pothosware/pothos/wiki
* License : Boost Software License
  Programming Lang: C++
  Description : data flow programming framework with computational offload 
capability

The Pothos project is a complete data-flow framework for creating
topologies of interconnected processing blocks. Topologies can be
designed and tested graphically, and deployed over a network. The Pothos
framework API is sleek and smart, enabling users to quickly create
custom processing blocks with minimal boiler-plate. Processing blocks
can support computational offload and integration with DMA devices. The
project also has a diverse set of processing and hardware support
toolkits. 


I intend this ITP to include those submodules in the upstream git that
are also projects under the pothosware umbrella (audio, blocks, comms,
gui, plotters, python, sdr, widgets). There's also pothos-serialization
which is a copy of the Boost serialization with everything renamed to
avoid a dependency on Boost. I'll have to see what to do about that.

Basically I came across this because of the not-yet-funded LimeSDR[1]
crowdfunding project, pothos is the framework most demos were created
in. In that use case the obvious alternative is GNU Radio. Compared to
that the GUI looks more powerful and pleasant (multiple pages per app
for less cramped design, editing of blocks while the app is running,
placing GUI objects interactively).

[1] https://www.crowdsupply.com/lime-micro/limesdr

It can also integrate GNU Radio processing blocks, although that needs
some changes to GNU Radio that apparently aren't upstreamed so far.

Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1

[Andreas Bombe]

On Sat, Jun 18, 2016 at 09:21:58AM +0200, Petter Reinholdtsen wrote:
> [Andreas Bombe]
> > Also, I wonder if the fix for
> > https://github.com/dosfstools/dosfstools/issues/11 (which is
> > 2aad1c83c) shouldn't also be included while we're at it. It has no
> > CVE, the out of bounds memory access itself isn't all that bad but it
> > might create improper date values.
> >
> > https://github.com/dosfstools/dosfstools/commit/2aad1c83c7d010de36afbe79c9fde22c50aa2f74
> 
> It is fine with me, but it is up to the release managers.  Is there a
> Debian bug about this?  I believe it is a requirement for getting a fix
> into stable.
> 
> Is this error supposed to be detected by Valgrind?  I was unable to get
> any warning about out of bounds memory access by valgrind when I tested.

I think there was one issue that only showed up as a memory error on
i386 and not amd64 and this might have been the one.

Also on second thought, never mind… This date conversion is used only to
display information about files, so worst case is that index -1 of a
static array is read and a nonsensical date is displayed to the user. I
don't think it's worth extra effort to include it.


Andreas

Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1

[Andreas Bombe]

On Fri, Jun 17, 2016 at 06:37:03AM +0100, Adam D. Barratt wrote:
> On Fri, 2016-06-17 at 05:00 +0200, Andreas Bombe wrote:
> > On Mon, Jun 13, 2016 at 09:26:52AM +0200, Petter Reinholdtsen wrote:
> [...]
> > > https://security-tracker.debian.org/tracker/CVE-2016-4804 >
> > > https://security-tracker.debian.org/tracker/CVE-2016-4804 >.
> > > 
> > > The issues were fixed in Wheezy by the LTS team (DLA-474-1) and is also
> > > fixed in unstable.  I would like to get it fixed in stable too, to get
> > > it out of my debsecan list.
> > > 
> > > The attached patch is based on the patches in wheezy, and should solve
> > > the problems.
> > > 
> > > Is it OK to upload the fix for stable?
> > 
> > Yes, please go ahead after taking into account the remark below. Thank
> > you.
> 
> Note that Andreas is not a member of the release team.

Whoops, my misunderstanding of the context, sorry.


On Fri, Jun 17, 2016 at 11:28:04AM +0200, Petter Reinholdtsen wrote:
> [Petter Reinholdtsen]
> > I will.  But the comment below seem to indicate that the update in
> > Wheezy was incomplete?
> 
> Looking at the code, I am quite sure the Wheezy fix missed the change in
>  https://github.com/dosfstools/dosfstools/commit/07908124838afcc99c577d1d3e84cef2dbd39cb7
>  >.
> Who should be notified about this?

I didn't look closely when the wheezy update was uploaded, so it looks
like it missed it.

For reference, this is the original report including a test file:
https://github.com/dosfstools/dosfstools/issues/12

The problem is fixed if fsck'ing that file under valgrind shows no
valgrind memory errors. Crashing without valgrind is not guaranteed.


Also, I wonder if the fix for https://github.com/dosfstools/dosfstools/issues/11
(which is 2aad1c83c) shouldn't also be included while we're at it. It
has no CVE, the out of bounds memory access itself isn't all that bad
but it might create improper date values.

https://github.com/dosfstools/dosfstools/commit/2aad1c83c7d010de36afbe79c9fde22c50aa2f74


Andreas

Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1

[Andreas Bombe]

On Mon, Jun 13, 2016 at 09:26:52AM +0200, Petter Reinholdtsen wrote:
> 
> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-CC: Andreas Bombe <a...@debian.org>
> 
> On my Debian Jessie machine, I would like to fix the two security issues
> in dosfstools that show up in the debsecan report:
> https://security-tracker.debian.org/tracker/CVE-2016-4804 >
> https://security-tracker.debian.org/tracker/CVE-2016-4804 >.
> 
> The issues were fixed in Wheezy by the LTS team (DLA-474-1) and is also
> fixed in unstable.  I would like to get it fixed in stable too, to get
> it out of my debsecan list.
> 
> The attached patch is based on the patches in wheezy, and should solve
> the problems.
> 
> Is it OK to upload the fix for stable?

Yes, please go ahead after taking into account the remark below. Thank
you.

> I plan to push the changes to a debian/jessie branch on collab-maint
> once I know the changes are acceptable for a stable update.



> --- /dev/null
> +++ b/debian/patches/CVE-2015-8872.diff
> @@ -0,0 +1,22 @@
> +https://github.com/dosfstools/dosfstools/commit/07908124838afcc99c577d1d3e84cef2dbd39cb7
> +
> +Index: dosfstools-collab/src/fat.c
> +===
> +--- dosfstools-collab.orig/src/fat.c 2016-06-13 08:07:44.669688617 +0200
>  dosfstools-collab/src/fat.c  2016-06-13 08:07:44.665688587 +0200
> +@@ -197,10 +197,12 @@
> + data[1] = new >> 4;
> + } else {
> + FAT_ENTRY subseqEntry;
> +-get_fat(, fs->fat, cluster + 1, fs);
> ++if (cluster != fs->clusters - 1)
> ++get_fat(, fs->fat, cluster + 1, fs);
> ++else
> ++subseqEntry.value = 0;
> + data[0] = new & 0xff;
> +-data[1] = (new >> 8) | (cluster == fs->clusters - 1 ? 0 :
> +-(0xff & subseqEntry.value) << 4);
> ++data[1] = (new >> 8) | ((0xff & subseqEntry.value) << 4);
> + }
> + size = 2;
> + break;

This is commit 39ce90fe7 [*] which fixed a possible read access one byte
beyond the end of an array, pretty harmless since the value wouldn't be
used when the read shouldn't have happened. The following commit
079081248 is the meatier of the fixes and the one actually fixing the
CVE (and the one referenced in the URL above). It needs to be integrated
here.

[*] 
https://github.com/dosfstools/dosfstools/commit/39ce90fe75661ed8842551cd44ea7fec278a60a1

Bug#826727: anki: Anki does not start anymore

[Andreas Bombe]

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

[Andreas Bombe]

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

[Andreas Bombe]

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

[Andreas Bombe]

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

[Andreas Bombe]

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

[Andreas Bombe]

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)

[Andreas Bombe]

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)

[Andreas Bombe]

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)

[Andreas Bombe]

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#159584: reverse dependency list should show actual dependency

[Andreas Bombe]

On Thu, Jan 28, 2016 at 08:07:50PM +, Manuel A. Fernandez Montecelo wrote:
> Control: tags -1 + pending
> 
> 
> Hi Andreas,
> 
> 2002-09-04 13:23 Andreas Bombe:
> >Package: aptitude
> >Version: 0.2.11.1-3
> >Severity: wishlist
> >
> >When showing the reverse dependencies aptitude only shows the package
> >names and versions.  This makes it difficult to see whether the reverse
> >depends really requires that exact package or if it's just one
> >alternative.  You have to enter every package description to find out.
> >
> >It would be immediately visible if there was a way to display the
> >dependency leading to the reverse depends in the list.
> 
> I changed this to show it in this way:
> 
>  --\ Packages which depend on iceweasel (480)
>  --- Depends (348)
>  --\ Depends on provided gnome-www-browser (1)
>  p cinnamon-desktop-environment 2.8.0
>  --\ Depends on provided www-browser (69)
>  p bibus-doc-en 1.5.2-4
>  p browser-plugin-packagekit 1.0.11-1
>  p c-cpp-reference 2.0.2-8
>  p cppreference-doc-en-html 20151129+dfsg0-1
>  p drgeo-doc 1.5-7
>  p fish 2.2.0-3
>  p fsl-5.0-core 5.0.8-5
>  p gimp-help-ca 2.8.2-0.1
>  p gimp-help-de 2.8.2-0.1
>  p gimp-help-el 2.8.2-0.1
>  p gimp-help-en 2.8.2-0.1
>  p gimp-help-es 2.8.2-0.1
>  p gimp-help-fr 2.8.2-0.1
>  p gimp-help-it 2.8.2-0.1
>  p gimp-help-ja 2.8.2-0.1
>  p gimp-help-ko 2.8.2-0.1
>  [...]
>  --- Recommends (30)
>  --- Recommends on provided www-browser (67)
>  --- Suggests (34)
>  --- Suggests on provided www-browser (125)
>  --- Enhances (66)
>  --- Conflicts (2)
>   
> 
> It doesn't help for all cases with alternatives, but at least if one
> sees that the dependency is on a provided package, one can easily find
> if there are other alternatives that might fit the bill.
> 
> For example, if there is any package installed which "Depends" on
> iceweasel (like "iceweasel-l10-ms" or "xul-ext-blah"), probably cannot
> be uninstalled, but if the only ones installed are those depending on
> "www-browser" provided by iceweasel, one can substitute iceweasel for
> another browser.
> 
> Showing the OR dependencies and alternatives is quite difficult to
> implement in the way that things work, that's probably why the bug has
> been unfixed for 13+ years, and quite might be quite computationally
> intensive for packages with hundreds of rev-deps, so I think that this
> is an acceptable fix.

As you say, it's not quite the complete solution I wished for, but if
the complete solution is impractical then that will have to do. In any
case, I haven't tried to figure out how a proper solution would even
look like, I just wrote a generic wishlist bug there.

Also, thank you for working on a 13 year old wishlist bug! I didn't
expect for anything to come out of it after all this time and just left
it open because there was no real reason to close it, so this is pretty
awesome.

Bug#803755: texmaker: diff for NMU version 4.4.1-1.1

[Andreas Bombe]

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

[Andreas Bombe]

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#788585: dsh: overwrites host list with a symlink

[Andreas Bombe]

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#795690: libcdio: FTBFS under some timezones (eg. GMT-14)

[Andreas Bombe]

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#803755: texmaker: diff for NMU version 4.4.1-1.1

[Andreas Bombe]

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

[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.

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

[Andreas Bombe]

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#795500: dosfstools: mkfs.vfat -F32 don't work correctly

[Andreas Bombe]

On Fri, Aug 14, 2015 at 08:17:39PM +0200, aimless wrote:
 I can't create a FAT32 partition with this command dosfstools: mkfs.vfat -F32.
 
 For example, you can try this :
 
 $dd if=/dev/zero of=OSMC_TGT.img bs=1M count=256
 256+0 enregistrements lus
 256+0 enregistrements écrits
 268435456 octets (268 MB) copiés, 1,05195 s, 255 MB/s
 $parted -s OSMC_TGT.img mklabel msdos
 $parted -s OSMC_TGT.img mkpart primary fat32 1M 256M
 $kpartx -a OSMC_TGT.img
 mkfs.fat 3.0.27 (2014-11-12)
 unable to get drive geometry, using default 255/63
 $mount /dev/mapper/loop0p1 /mnt
 $touch /mnt/file.txt
 $umount /mnt
 $sync
 $kpartx -d OSMC_TGT.img
 loop deleted : /dev/loop0

I tried this, and it works. Just like it appears to work for you.
What is the problem here exactly?

 Before, I don't have this message : unable to get drive geometry, using 
 default
 255/63
 
 Can you help me please ?

With suppressing an informational message? Your bug report doesn't point
to anything actually a bug, as far as I can see.

Please explain better, otherwise I can only close this bug report.

Bug#775242: gnome-clocks: Uses ridiculous amount of CPU time for timer and stop watch

[Andreas Bombe]

forwarded 775242 https://bugzilla.gnome.org/show_bug.cgi?id=738469
thanks

This bug has been reported upstream by Michael Biebl a few months before
I submitted my bug report. So let's just use his report as the forwarded
address.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785420: vice: No man page for xscpu64

[Andreas Bombe]

Package: vice
Version: 2.4.dfsg+2.4.19-1
Severity: minor

I see the common man page was reworked to mention the new xscpu64
program. However, unlike for the other vice binaries, there is no link
under xscpu64 and man xscpu64 will only report that the man page is
missing.


Regards,

Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775242: gnome-clocks: Uses ridiculous amount of CPU time for timer and stop watch

[Andreas Bombe]

Package: gnome-clocks
Version: 3.14.1-1
Severity: minor

I found that the amount of CPU time gnome-clocks uses for rendering a
running stop watch or timer and even more what it causes Xorg and in a
smaller way gnome-shell to consume is simply way out of proportion.

The combined (gnome-clocks + Xorg + gnome-shell) CPU usage on this
laptop as reported by top goes over 50% (of one core, that is), same on
my desktop machine (intel and radeon graphics, respectively). This makes
it somewhat unsuitable to run on battery power.

Given the relatively simple graphic effects it displays, I would expect
much less resource consumption.


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-clocks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  geoclue-2.0  2.1.10-2
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-13
ii  libcairo-gobject21.14.0-2.1
ii  libcairo21.14.0-2.1
ii  libcanberra0 0.30-2.1
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libgeocode-glib0 3.14.0-1
ii  libglib2.0-0 2.42.1-1
ii  libgnome-desktop-3-103.14.1-1
ii  libgtk-3-0   3.14.5-1
ii  libgweather-3-6  3.14.1-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3

gnome-clocks recommends no packages.

gnome-clocks suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771091: fsck.fat: large memory footprint

[Andreas Bombe]

severity 771091 wishlist
thanks


Sorry to let you wait.

On Wed, Nov 26, 2014 at 06:10:18PM +0100, Arnout Vandecappelle (Essensium/Mind) 
wrote:
  So, what do you think about this? Would you be willing to accept patches for
 the mmap() conversion? Any hints about how to approach it? Can I assume that
 mmap() is always available?

mmap() is always available on Debian architectures, there's no ports to
no-MMU targets. As for other targets outside of Debian, I don't know
where it is used. There are some dependencies on a Linux environment in
dosfstools right now.

Note that I have adopted dosfstools including upstream not too long ago,
so I can't judge the implications of your suggestions until I take a
closer look. Anyway, I'll take a look at your patches.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771979: unblock: anki/2.0.31+dfsg-1

[Andreas Bombe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package anki

Okay, this is the flash card learning program with that syncing feature
to an upstream server that refuses to sync with older versions such as
2.0.30 which is in jessie currently. I asked how to handle that on the
mailing list a few weeks back.

Anyway, I decided to upload the latest upstream release to unstable
since it is just such a small change. Upstream lists Fix a problem
where large regular syncs sometimes timed out. as the only change, and
you can see in the diff that a size limit is the only code change beside
the version number (the version number likely being responsible for
getting rejected by the server or not).

I also added a README.Debian explaining this issue which would be nice
to have in jessie. This fixes bug #768398 (which is about being unable
to sync, naturally). I hope this is acceptable for an unblock.


Source debdiff (stripped by changes caused by version number in created
files):

diff -Nru anki-2.0.30+dfsg/anki/__init__.py anki-2.0.31+dfsg/anki/__init__.py
--- anki-2.0.30+dfsg/anki/__init__.py   2014-10-18 08:09:32.0 +0200
+++ anki-2.0.31+dfsg/anki/__init__.py   2014-10-19 10:00:20.0 +0200
@@ -30,6 +30,6 @@
 sys.path.insert(0, os.path.join(ext, py2.%d-%s % (
 sys.version_info[1], arch[0][0:2])))
 
-version=2.0.30 # build scripts grep this line, so preserve formatting
+version=2.0.31 # build scripts grep this line, so preserve formatting
 from anki.storage import Collection
 __all__ = [Collection]
diff -Nru anki-2.0.30+dfsg/anki/sync.py anki-2.0.31+dfsg/anki/sync.py
--- anki-2.0.30+dfsg/anki/sync.py   2014-10-18 08:08:57.0 +0200
+++ anki-2.0.31+dfsg/anki/sync.py   2014-10-19 09:56:36.0 +0200
@@ -321,7 +321,7 @@
 
 def chunk(self):
 buf = dict(done=False)
-lim = 2500
+lim = 250
 while self.tablesLeft and lim:
 curTable = self.tablesLeft[0]
 if not self.cursor:
diff -Nru anki-2.0.30+dfsg/debian/changelog anki-2.0.31+dfsg/debian/changelog
--- anki-2.0.30+dfsg/debian/changelog   2014-10-19 00:45:40.0 +0200
+++ anki-2.0.31+dfsg/debian/changelog   2014-12-02 02:15:09.0 +0100
@@ -1,3 +1,12 @@
+anki (2.0.31+dfsg-1) unstable; urgency=medium
+
+  * New upstream version 2.0.31+dfsg
+- Having a current version fixes Anki server refusing to sync
+  (Closes: 768398)
+  * Add README.Debian with some info about why network syncing may fail
+
+ -- Andreas Bombe a...@debian.org  Tue, 02 Dec 2014 01:54:04 +0100
+
 anki (2.0.30+dfsg-1) unstable; urgency=medium
 
   * New upstream version 2.0.30+dfsg
diff -Nru anki-2.0.30+dfsg/debian/README.Debian 
anki-2.0.31+dfsg/debian/README.Debian
--- anki-2.0.30+dfsg/debian/README.Debian   1970-01-01 01:00:00.0 
+0100
+++ anki-2.0.31+dfsg/debian/README.Debian   2014-12-02 02:15:09.0 
+0100
@@ -0,0 +1,13 @@
+What to do when syncing to the Anki server stops working
+
+
+Syncing depends on a server that is run by the Anki creator who understandably
+only supports his own most recent version of Anki. This means that older
+versions stop being able to sync soon after a new version is released.
+
+If you need the syncing feature, the only way to keep using it is to always run
+the latest version of Anki. However, the releases of Debian don't directly get
+new versions of most packages during their lifetime. So if you want to use Anki
+with syncing in a release, please look at http://backports.debian.org/ for
+information on how to get an up to date version of this package for the release
+you use.


unblock anki/2.0.31+dfsg-1

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.0-rc6-00165-g7a5a4f9 (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
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769508: apt-spacewalk: diff for NMU version 1.0.6-4.1

[Andreas Bombe]

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-dist-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

[Andreas Bombe]

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-dist-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

[Andreas Bombe]

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-dist-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

[Andreas Bombe]

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

[Andreas Bombe]

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#770642: mk-build-deps: Depencency typo in generated package description

[Andreas Bombe]

Package: devscripts
Version: 2.14.10
Severity: minor
File: /usr/bin/mk-build-deps
Tags: patch

Just a small typo: The dependency packages created by mk-build-deps say
they are a Depencency package in their description.
From 0813bc1d905628a3d2e160adb33b863b9af556f6 Mon Sep 17 00:00:00 2001
From: Andreas Bombe a...@debian.org
Date: Sat, 22 Nov 2014 22:17:36 +0100
Subject: [PATCH] Correct Depencency misspelling in packages created by
 mk-build-deps

---
 scripts/mk-build-deps.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/mk-build-deps.pl b/scripts/mk-build-deps.pl
index 012c814..15958d5 100755
--- a/scripts/mk-build-deps.pl
+++ b/scripts/mk-build-deps.pl
@@ -415,7 +415,7 @@ sub build_equiv
 print EQUIVS Version: $version\n;
 
 print EQUIVS Description: build-dependencies for $opts-{name}\n .
- Depencency package to build the '$opts-{name}' package\n;
+ Dependency package to build the '$opts-{name}' package\n;
 
 close EQUIVS;
 
-- 
2.1.3

Bug#769916: installation-reports: d-i jessie daily 20141116-5 on Lenovo ThinkPad X1 Carbon

[Andreas Bombe]

Package: installation-reports
Severity: normal

-- Package-specific info:

Boot method: USB stick
Image version: 20141116-5/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: 2014-11-16

Machine: Lenovo ThinkPad X1 Carbon (current 20A7 model)
Partitions:
Dateisystem Typ  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt 
auf
/dev/mapper/lvcore-root xfs   58564672 4425256  541394168% /
udevdevtmpfs 10240   0 102400% /dev
tmpfs   tmpfs  16145729188   16053841% /run
tmpfs   tmpfs  40364241040   40353841% /dev/shm
tmpfs   tmpfs 5120   4  51161% /run/lock
tmpfs   tmpfs  4036424   0   40364240% 
/sys/fs/cgroup
/dev/sda1   ext4944120   343088446364% /boot
/dev/sda2   vfat974972 1329748401% /boot/efi
tmpfs   tmpfs   807288  368072521% 
/run/user/1000

This is the result of manual partitioning overwriting the preinstalled
Windows. I created one partition for use as /boot, one EFI system
partition and one LUKS partition containing one LVM physical volume
containing one LVM logical volume for /.


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [E]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Besides disabling Secure Boot, I had to enable the CSM in the firmware
configuration. Without it, the installer would not be recognized by the
firmware as a bootable OS (and neither would the installed system
later). With the CSM, it booted correctly in UEFI mode.

The installer told me it would need the firmware files
iwlwifi-7260-9.ucode iwlwifi-7260-8.ucode twice. When you tell it to
go ahead and try to load them and it fails and returns to that dialog,
it will add these two files to the list of required firmware files
again. This is repeatable with the list of files growing longer with
each round.

Firmware loading is finicky. It would not load them even with a stick
connected containing these files. It did on a previous run though, but
only if the files are in a firmware subdirectory and not in the root
as the installation manual says should be possible. On this run I could
not load the firmware even in multiple attempts, although the previously
described bug may have interfered with something.

I did not need WLAN for the installation since I used Ethernet, so I
proceeded without the firmware files.

I marked install tasks as error because I was offered only a single
standard stuff task. This is possibly connected to the following
problem.

The installed system had no active binary package sources except
security.debian.org jessie/updates. jessie, jessie-updates and
jessie-backports were # Line commented out by installer because it
failed to verify:. There could have been a transient network/server
problem for all I know, but there was no warning during the installation
process. I haven't checked the logs yet.

The installed system booted fine into text mode (due to missing task
selection no GUI was installed).


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION=Debian GNU/Linux installer
DISTRIB_RELEASE=8 (jessie) - installer build 20141116-00:04
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM 
Controller [8086:0a04] (rev 0b)
lspci -knn: Subsystem: Lenovo Device [17aa:2218]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 
Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b)
lspci -knn: Subsystem: Lenovo Device [17aa:2218]
lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio 
Controller [8086:0a0c] (rev 0b)
lspci -knn: Subsystem: Lenovo Device [17aa:2218]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI 
HC [8086:9c31] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:2218]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: