Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless

[James Clarke]

Control: retitle -1 libcrypt1: Wrong soname on ia64

On 14 Mar 2020, at 14:20, John Paul Adrian Glaubitz 
 wrote:
> 
> Package: libcrypt1
> Version: 1:4.4.15-1
> Followup-For: Bug #953562
> User: debian-i...@lists.debian.org
> Usertags: ia64
> 
> Hello!
> 
> This actually causes issues on ia64 now:
> 
> Setting up libc6.1:ia64 (2.30-2) ...
> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot 
> open shared object file: No such file or directory
> dpkg: error processing package libc6.1:ia64 (--configure):
> installed libc6.1:ia64 package post-installation script subprocess returned 
> error exit status 127
> Errors were encountered while processing:
> libc6.1:ia64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> apt-get failed.
> E: Package installation failed
> 
> So it's not just a theoretical issue.

This is just the opposite of #947606; ia64 is meant to have libcrypt.so.1, not
libcrypt.so.1.1 like alpha, and so that change needs to be reverted. See [1]
for an old glibc build log to demonstrate the correct name (and note that,
unlike alpha, sysdeps/unix/sysv/linux/ia64/shlib-versions does not override
libcrypt's version).

James

[1] 
https://buildd.debian.org/status/fetch.php?pkg=glibc=ia64=2.28-2=1544971021=0

Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support

[James Clarke]

On 8 Mar 2020, at 22:21, Aurelien Jarno  wrote:
> 
> Source: simgrid
> Version: 3.25+dfsg-1
> Severity: normal
> Tags: patch
> Justification: fails to build from source (but built successfully in the past)
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Dear maintainer,
> 
> ceph fails to build on riscv64 with the following error:
> 
> | dh_install
> | dh_install: warning: Cannot find (any matches for) 
> "usr/lib/libsimgrid-java.so" (tried in ., debian/tmp)
> | 
> | dh_install: warning: libsimgrid-dev missing files: 
> usr/lib/libsimgrid-java.so
> | dh_install: error: missing files, aborting
> | make[1]: *** [debian/rules:89: override_dh_install] Error 25
> | make[1]: Leaving directory '/<>/simgrid-3.25+dfsg'
> | make: *** [debian/rules:39: binary-arch] Error 2
> | dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
> returned exit status 2
> 
> The full build log is available there:
> https://buildd.debian.org/status/fetch.php?pkg=simgrid=riscv64=3.25%2Bdfsg-1=1583603229=0
> 
> The problem is that java support is not enabled on riscv64. After
> enabling it (as well as ns3 which is also available) I have verified that
> simgrid builds fine on riscv64.
> 
> I have attached the patch I have used. Would it be possible to include
> it in the next upload?
> 
> Thanks,
> Aurelien
> 
> [...]
> diff -Nru simgrid-3.25+dfsg/debian/rules simgrid-3.25+dfsg/debian/rules
> --- simgrid-3.25+dfsg/debian/rules2020-02-21 20:31:20.0 +0100
> +++ simgrid-3.25+dfsg/debian/rules2020-03-08 12:05:53.0 +0100
> @@ -21,7 +21,7 @@
>CFLAGS += -O3
>  endif
>  
> -ifneq (,$(findstring $(DEB_HOST_ARCH_CPU),amd64 arm64 armel armhf i386 
> mips64el mipsel ppc64el s390x))
> +ifneq (,$(findstring $(DEB_HOST_ARCH_CPU),amd64 arm64 armel armhf i386 
> mips64el mipsel ppc64el riscv64 s390x))

This code was and still is wrong. It should be filter not findstring (otherwise
any substring of one of those names will match), and DEB_HOST_ARCH_CPU is not
always the same as the last component of the architecture name; specifically,
armel and armhf both have a DEB_HOST_ARCH_CPU of arm, which happens to work
because arm is a substring of armel/armhf, and x32 has a DEB_HOST_ARCH_CPU of
amd64, which happens to work because it already handles amd64.

James

Bug#949716: qa.debian.org: DDPO doesn't show packages with version 0

[James Clarke]

On Thu, Jan 23, 2020 at 11:58:14PM +0100, Adam Borowski wrote:
> Package: qa.debian.org
> Severity: normal
>
> Hi!
> If you have a package with version "0" (a valid version number) -- like
> "fonts-recommended" at the moment, DDPO won't show it.  On the other hand,
> a non-native package versioned "0-1" does show up.
>
> This suggests a type confusion bug, like something equalling string "0" to
> NULL.

Heh. From staring at the code for a little, my guess is that it is the
following snippet in wml/developer.wml's print_package_entry at fault:

> /* don't display this package if it doesn't have any version or wnpp info */
> if (empty(array_filter($version)) and empty($wnpp_info)) return "";

The documentation for array_filter[1] says:

> If no callback is supplied, all entries of array equal to FALSE (see 
> converting to boolean) will be removed.

and if you follow the reference to the implicit boolean conversions
documentation[2], it indeed has the following:

> When converting to boolean, the following values are considered FALSE:
>   ...
>   * the empty string, and the string "0"

(because Javascript isn't the only language with "helpful" design
decisions)

So, I think you have to have *every* version in the archive as "0";
later checks in that function explicitly compare against "".

It's worth noting that there's also

> $pack_array = array_filter(explode(" ", $packages));

in the caller (print_package_entries), so if a src:0 were ever uploaded
to the archive it would feel left out of all the DDPO fun, although such
a source package name would surely be rejected...

As for the fix, you can (ab)use strlen as the callback (though of
*course* you have to pass the function name as a string...), so:

> if (empty(array_filter($version, 'strlen')) and empty($wnpp_info)) return "";

and

> $pack_array = array_filter(explode(" ", $packages), 'strlen');

I use the word "fix" loosely here though, I've only convinced myself
it's correct; it has not seen an interpreter, let alone been tested on
this input!

James

[1] 
https://www.php.net/manual/en/function.array-filter.php#refsect1-function.array-filter-parameters
[2] 
https://www.php.net/manual/en/language.types.boolean.php#language.types.boolean.casting

Bug#948317: gcc-10: Please disable gm2 on ia64

[James Clarke]

On 7 Jan 2020, at 08:57, John Paul Adrian Glaubitz 
 wrote:
> On 1/7/20 9:54 AM, Matthias Klose wrote:
>>> The gcc-10 build currently fails on ia64 when trying to build gm2 [1],
>>> thus I have disabled gm2 for a local test build.
>> 
>> how does it fail?
> 
> The assembler is complaining [1]:
> 
> mv -f $depbase.Tpo $depbase.Plo
> libtool: compile:  /<>/build/./gcc/xgcc 
> -B/<>/build/./gcc/ -B/usr/ia64-linux-gnu/bin/ 
> -B/usr/ia64-linux-gnu/lib/ -isystem /usr/ia64-linux-gnu/include -isystem 
> /usr/ia64-linux-gnu/sys-include -isystem /<>/build/sys-include 
> -fchecking=1 -DHAVE_CONFIG_H -I. -I../../../src/libquadmath -I 
> ../../../src/libquadmath/../include -g -O2 -MT math/clogq.lo -MD -MP -MF 
> math/.deps/clogq.Tpo -c ../../../src/libquadmath/math/clogq.c  -fPIC -DPIC -o 
> math/.libs/clogq.o
> /tmp/ccyNARpA.s: Assembler messages:
> /tmp/ccyNARpA.s:40: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:47: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:81: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:100: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:109: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:116: Error: Wrong number of input operands

I haven't tried building it yet, but suspect it's this:

src/gcc/m2/gm2-gcc/m2block.c:719:  tree instr = m2decl_BuildStringConstant 
("nop", 3);
src/gcc/m2/gm2-gcc/m2block.c-720-  tree string
src/gcc/m2/gm2-gcc/m2block.c-721-  = resolve_asm_operand_names (instr, 
NULL_TREE, NULL_TREE, NULL_TREE);
src/gcc/m2/gm2-gcc/m2block.c-722-  tree note = build_stmt 
(pending_location, ASM_EXPR, string, NULL_TREE,
src/gcc/m2/gm2-gcc/m2block.c-723-  NULL_TREE, 
NULL_TREE, NULL_TREE);

ia64's nop, like s390, is "nop 0", but unlike s390 there is no alias for just
"nop", you need to give the full instruction. Can we not avoid this and use
build_empty_stmt instead of creating inline assembly?

James

Bug#802528: [Reproducible-builds] Bug#802528: valac: make the generated C files reproducible

[James Clarke]

On Tue, Oct 20, 2015 at 11:28:21PM +0300, Niko Tyni wrote:
> Control: tag -1 - patch
>
> On Tue, Oct 20, 2015 at 04:09:16PM -0400, Daniel Kahn Gillmor wrote:
>
> > But doesn't the change from HashSet to List end up changing the behavior
> > with regard to multiple children of the same class?
> >
> > That is, if it's a List, then the same class can appear multiple times,
> > whereas if it's a set, i think it just gets added once.
>
> Yes, I think you're right. Thanks for catching that! I suspect it doesn't
> really matter here, but I'm not quite sure, and it certainly isn't safe
> as a general fix.
>
> > The usual approach would be to sort the output where it's produced from
> > the HashedSet, and not to change the data structure itself to allow
> > duplicates.
>
> Sure, this just seemed such a nice solution :)
>
> Anyway, removing the 'patch' tag for now.

The type you want to use is a TreeSet, which implements SortedSet. I
also notice this patch was committed to the repository 2 years ago[1],
ignoring the discussion here about the behaviour being potentially
incorrect, and not actually closing this bug in the upload.

James

[1] 
https://salsa.debian.org/gnome-team/vala/commit/0056ea4e8d0e25dba13a856fc0aa18646217e4c6

Bug#940090: binutils: Bogus build dependency on libc6-deb on alpha and ia64

[James Clarke]

On 12 Sep 2019, at 14:46, Matthias Klose  wrote:
> 
> On 12.09.19 15:26, John Paul Adrian Glaubitz wrote:
>> On 9/12/19 3:17 PM, Matthias Klose wrote:
> jrtc27@coccia:~$ diff -u <(awk '/^Build-Depends:/{s=$0; next} /^ 
> /&{s=s$0; next} s{print s; s=""} END{if (s) print s}' 
> /srv/mirrors/debian/pool/main/b/binutils/binutils_2.32.51.20190909-1.dsc 
> | sed 's/,/&\n/g') <(tar -O -xf 
> /srv/mirrors/debian/pool/main/b/binutils/binutils_2.32.51.20190909-1.debian.tar.xz
>  debian/control | awk '/^Build-Depends:/{s=$0; next} /^ /&{s=s$0; next} 
> s{print s; s=""} END{if (s) print s}' | sed 's/   */ /g;s/,/&\n/g')
> --- /dev/fd/632019-09-12 09:46:12.544764354 +
> +++ /dev/fd/622019-09-12 09:46:12.532764072 +
> @@ -30,4 +30,4 @@
>g++-i686-linux-gnu [amd64 arm64 ppc64el x32] ,
>g++-x86-64-linux-gnu [arm64 i386 ppc64el x32] ,
>g++-x86-64-linux-gnux32 [amd64 arm64 i386 ppc64el] ,
> - libc6-dev (>= 2.29) | libc6.1-dev (>= 2.29) | libc0.1-dev-i386 (>= 
> 2.29) | libc0.3-dev (>= 2.29)
> +
>>> 
>>> so what is bogus about that? the b-d can be fulfilled, or not?
>> It cannot be fulfilled. buildd.debian.org claims it's BD-Uninstallable.
> 
> that's not an answer to my question.

1. It's in the .dsc but not debian/control so depending on what you use to
   install build dependencies they may not be installed.

2. wanna-build (for unstable) and sbuild (by default/with the apt resolver)
   deliberately strip alternatives.

James

Bug#940090: binutils: Bogus build dependency on libc6-deb on alpha and ia64

[James Clarke]

On 12 Sep 2019, at 10:18, John Paul Adrian Glaubitz 
 wrote:
> 
> Source: binutils
> Severity: normal
> User: debian-i...@lists.debian.org
> Usertags: alpha ia64
> 
> Hello!
> 
> binutils is currently BD-Uninstallable on alpha and ia64 because it 
> build-depends
> on the libc6-dev package on these architectures. However, neither alpha nor 
> ia64
> provide that package, they actually have a libc6.1-dev package.

Also affects kfreebsd (libc0.1) and hurd (libc0.3). This isn't actually a bug
in the source however, but a bug in the .dsc itself uploaded to the archive,
which differs in its Build-Depends field; not sure what happened here...

> jrtc27@coccia:~$ diff -u <(awk '/^Build-Depends:/{s=$0; next} /^ /&{s=s$0; 
> next} s{print s; s=""} END{if (s) print s}' 
> /srv/mirrors/debian/pool/main/b/binutils/binutils_2.32.51.20190909-1.dsc | 
> sed 's/,/&\n/g') <(tar -O -xf 
> /srv/mirrors/debian/pool/main/b/binutils/binutils_2.32.51.20190909-1.debian.tar.xz
>  debian/control | awk '/^Build-Depends:/{s=$0; next} /^ /&{s=s$0; next} 
> s{print s; s=""} END{if (s) print s}' | sed 's/   */ /g;s/,/&\n/g')
> --- /dev/fd/632019-09-12 09:46:12.544764354 +
> +++ /dev/fd/622019-09-12 09:46:12.532764072 +
> @@ -30,4 +30,4 @@
>   g++-i686-linux-gnu [amd64 arm64 ppc64el x32] ,
>   g++-x86-64-linux-gnu [arm64 i386 ppc64el x32] ,
>   g++-x86-64-linux-gnux32 [amd64 arm64 i386 ppc64el] ,
> - libc6-dev (>= 2.29) | libc6.1-dev (>= 2.29) | libc0.1-dev-i386 (>= 2.29) | 
> libc0.3-dev (>= 2.29)
> +

James

Bug#932743: pbuilder: pdebuild --auto-debsign does not sign _source_changes file created after SOURCE_ONLY_CHANGES=yes

[James Clarke]

On 22 Jul 2019, at 17:16, Agustin Martin  wrote:
> 
> Package: pbuilder
> Version: 0.230.4
> tags: +patch
> Severity: important
> 
> Dear Maintainer,
> 
> I am in the process of changing my pbuilder setup to produce source-only
> uploads. For that purpose I added SOURCE_ONLY_CHANGES=yes to my
> .pbuilderrc file.
> 
> However, when using pdebuild --auto-debsign to sign files, only .changes
> file is signed, but not its _source.changes counterpart, which is the file
> I would have to upload. This results in pbuilder not creating properly
> uploadable packages once source-only uploads are mandatory for bullseye. 
> This is why I use severity "important".
> 
> .changes file may be temporarily accepted (it was e.g. for ispell.pt), but
> package will not migrate to testing with "not build on buildd" excuse and
> _source.changes is not signed. 
> 
> Attached patch tries to make sure both .changes and _source.changes files
> are signed with --auto-debsign.
> 
> Best regards,
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers testing
>  APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (200, 
> 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
> Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
> LANGUAGE=es_ES.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages pbuilder depends on:
> ii  debconf [debconf-2.0]  1.5.72
> ii  debootstrap1.0.115
> ii  dpkg-dev   1.19.7
> 
> Versions of packages pbuilder recommends:
> ii  devscripts  2.19.5
> pn  eatmydata   
> ii  fakeroot1.23-1
> ii  iproute25.2.0-1
> ii  net-tools   1.60+git20180626.aebd88e-1
> ii  sudo1.8.27-1
> 
> Versions of packages pbuilder suggests:
> ii  cowdancer   0.88
> ii  gdebi-core  0.9.5.7+nmu3
> 
> -- debconf information excluded
> 
> -- 
> Agustin
> 
> From 25f779881fd0ded624ce5796687277f19ddec71f Mon Sep 17 00:00:00 2001
> From: Agustin Martin Domingo 
> Date: Mon, 22 Jul 2019 17:52:08 +0200
> Subject: [PATCH] pdebuild: Sign both .changes and _source.changes files if
>  present.
> 
> When SOURCE_ONLY_CHANGES=yes is set in .pbuilderrc both .changes and
> _source.changes files will be created.
> 
> However, the _source.changes file will only be signed if no .changes
> is present.
> 
> This patch should make pdebuild sign both if present.
> ---
>  pdebuild | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/pdebuild b/pdebuild
> index 7d5f5ed..b699e6f 100644
> --- a/pdebuild
> +++ b/pdebuild
> @@ -113,10 +113,13 @@ if [ "${AUTO_DEBSIGN}" = "yes" ]; then
>  if [ -n "${DEBSIGN_KEYID}" ]; then
>  DEBSIGN_PARAM[1]="-k${DEBSIGN_KEYID}"
>  fi
> -if [ -f "${BUILDRESULT}/${CHANGES}" ]; then
> -DEBSIGN_PARAM[2]="${BUILDRESULT}/${CHANGES}"
> -elif [ -f "${BUILDRESULT}/${SOURCE_CHANGES}" ]; then
> -DEBSIGN_PARAM[2]="${BUILDRESULT}/${SOURCE_CHANGES}"
> +if [ -f "${BUILDRESULT}/${CHANGES}" ] || [ -f 
> "${BUILDRESULT}/${SOURCE_CHANGES}" ]; then
> + if [ -f "${BUILDRESULT}/${CHANGES}" ]; then
> +DEBSIGN_PARAM[2]="${BUILDRESULT}/${CHANGES}"
> + fi
> + if [ -f "${BUILDRESULT}/${SOURCE_CHANGES}" ]; then
> +DEBSIGN_PARAM[2]="${BUILDRESULT}/${SOURCE_CHANGES}"
> + fi

This will only sign _source.changes, overriding _arch.changes, unlike what your
commit message says.

I don't particularly like --auto-debsign as a maintainer workflow, I feel like
`debsign -S` (little-known fact: run that in the source directory and it will
find the changes file in ../ automatically) should be an explicit step once you
have checked your upload, but if people want to use the option then that's up
to them. I think the most sensible thing to do here is to automatically sign
only the _source.changes, like this patch actually does (though you can remove
your outer if condition, it's pointless), but with the correct commit message,
because if you intend to upload the _arch.changes then why are you bothering to
build a _source.changes too?

James

Bug#922496: GCC 9: gnat ftbs on kfreebsd-*

[James Clarke]

Control: tags -1 patch upstream
Control: forwarded -1 https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00309.html

On Sun, Feb 17, 2019 at 07:44:37AM +0100, Matthias Klose wrote:
> Package: src:gcc-9
> Version: 9-20190216-2
> Tags: important
> Severity: sid bullseye
>
> ftbfs, and we still have local, not forwarded patches for kfreebsd.
>
> s-tpopmo.adb:61:25: expected private type "System.Os_Interface.clockid_t"
> s-tpopmo.adb:61:25: found type universal integer
> s-tpopmo.adb:76:34: expected private type "System.Os_Interface.clockid_t"
> s-tpopmo.adb:76:34: found type universal integer
> ../gcc-interface/Makefile:299: recipe for target 'a-dispat.o' failed
> make[8]: *** [a-dispat.o] Error 1
> make[8]: Leaving directory '/<>/build/gcc/ada/rts'
> gcc-interface/Makefile:622: recipe for target 'gnatlib' failed
> make[7]: *** [gnatlib] Error 2
> make[7]: Leaving directory '/<>/build/gcc/ada'
> gcc-interface/Makefile:714: recipe for target 'gnatlib-shared-dual' failed
> make[6]: *** [gnatlib-shared-dual] Error 2
> make[6]: Leaving directory '/<>/build/gcc/ada'
> gcc-interface/Makefile:811: recipe for target 'gnatlib-shared' failed
> make[5]: *** [gnatlib-shared] Error 2
> make[5]: Leaving directory '/<>/build/gcc/ada'
> Makefile:104: recipe for target 'gnatlib-shared' failed
> make[4]: *** [gnatlib-shared] Error 2

Hi Matthias,
Please add the above patch I've sent upstream, which should fix this.

Thanks,
James

Bug#785101: FTBFS on kfreebsd-* due to test-suite failures

[James Clarke]

On 2 Jul 2019, at 20:15, Michael Biebl  wrote:
> 
> Hi James
> 
> Am 02.07.19 um 20:55 schrieb James Clarke:
>> Control: reopen -1
>> 
>>> On 2 Jul 2019, at 19:53, Michael Biebl  wrote:
>>> 
>>> On Tue, 12 May 2015 13:38:12 +0200 Michael Biebl  wrote:
>>>> Source: rsyslog
>>>> Version: 8.9.0-3
>>>> Severity: important
>>>> User: debian-...@lists.debian.org
>>>> Usertags: kfreebsd
>>>> 
>>>> As can be seen at [1] or [2], rsyslog failed reliably on the kfreebsd-*
>>>> buildds due to failures in the test-suite:
>>>> 
>>>> There are 17 failed tests. It would be great to have help from the
>>>> kfreebsd porting to get those fixed.
>>>> 
>>>> Thanks,
>>>> Michael
>>>> 
>>>> 
>>>> [1] 
>>>> https://buildd.debian.org/status/logs.php?pkg=rsyslog=kfreebsd-amd64
>>>> [2] 
>>>> https://buildd.debian.org/status/logs.php?pkg=rsyslog=kfreebsd-i386
>>>> 
>>> 
>>> 
>>> Since there was not a single response from the kfreebsd porters on this
>>> issue, I don't think it's useful to keep this bug report open any longer.
>> 
>> It's still a bug that exists and thus should remain open until it is fixed or
>> kFreeBSD no longer exists. I just have more important issues to fix on 
>> kFreeBSD
>> right now.
> 
> Don't you think 4 years is long enough to wait?

Even if it were 100 years that wouldn't make the bug suddenly go away on its
own. The bug was filed post-Jessie at a time when attention to the port was
decreasing, and I was not a member of the team for most of that period. I do
want to fix the bug, but nocheck builds do work in practice and I keep finding
other things to fix.

> I'm not sure even if that bug still applies today.

Yes, it still does[1,2]. Down to FAIL:  10 (7 in experimental), but still
non-zero.

James

[1] https://buildd.debian.org/status/package.php?p=rsyslog=sid
[2] https://buildd.debian.org/status/package.php?p=rsyslog=experimental

Bug#931266: e2fsprogs: Build-Depends on udev and systemd on non-Linux architectures

[James Clarke]

Source: e2fsprogs
Version: 1.45.0-1
Severity: important

Hi,
As of the above version, e2fsprogs Build-Depends on udev and systemd
(and cron too which, whilst somewhat perplexing, is not the issue here),
thereby rendering its build dependencies unsatisfiable on non-Linux
architectures, namely GNU/kFreeBSD and GNU/Hurd (the latter being
particularly important given it uses ext2fs as its filesystem). I went
digging to see why this was but the commit[1] that added it isn't any
more enlightening. I haven't tried building it without those packages, but can
only assume the upstream code still works without udev and systemd. Can we
please have this fixed in Debian so e2fsprogs builds everywhere again?

Regards,
James

[1] 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/debian/control?h=debian/master=68e00dc507acc3f3381f8f60bce71ecae371f794

Bug#926539: rootskel: steal-ctty no longer works on at least sparc64

[James Clarke]

Control: reopen -1
Control: reassign -1 src:linux,rootskel
Control: severity -1 serious

(Don't know if this is a blocker for the release, but it should at
least be reviewed before we release IMO, hence the severity)

On Sun, Apr 07, 2019 at 12:53:35AM +0100, Ben Hutchings wrote:
> On Sat, 2019-04-06 at 21:33 +0200, John Paul Adrian Glaubitz wrote:
> > On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> > > My suspicion is that the support multiple consoles in parallel [2] 
> > > introduced
> > > this particular regression. I haven't done any debugging yet though as I'm
> > > not sure where to start, I haven't touched the rootskel package before and
> > > therefore would be interested in any pointers how to debug this.
> >
> > The problem seems to be the fact that the sparc64 kernel uses different 
> > names
> > for /proc/console and the actual console name:
> >
> > root@landau:~# cat /proc/consoles
> > ttyHV0   -W- (EC p  )4:64
> > tty0 -WU (E )4:1
> > root@landau:~# readlink /sys/dev/char/4:64
> > ../../devices/root/f0299a70/f029b788/tty/ttyS0
>
> The inconsistent name seems like a kernel bug...
>
> > root@landau:~#
> >
> > And this is what used to make it work [1]:
> >
> > *) # >= 2.6.38
> > console_major_minor="$(get-real-console-linux)"
> > console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
> > console="${console_raw##*/}"
> > ;;
>
> So maybe rootskel should use that again, but applied to each console's
> char device number.
>
> (Though directly using the symlinks under /dev/char seems cleaner than
> poking in sysfs.)

Just got a report in #debian-cd of a user running into this issue on
s390x with Hercules; a subset of the messages sent in conversation are
below:

[20:12:18]  steal-ctty: No such file or directory
[20:12:29]  will go hunt this down once i find time
[20:12:52]  (DI buster RC2 / s390x)
[21:52:40]  gruetzkopf: cat /proc/consoles ?
[21:54:00]  should give something like:
[21:54:00]  ttyS0-W- (EC p  )4:64
[21:54:22]  rootskel will prefer a console which has the C flag
[21:55:17]  now let's see how to get there
[21:55:57]  (note: running in hercules, not real hw or qemu 
where i'd have virtio console)
[22:01:39]  cat /proc/consoles
[22:01:40]  ttyS0-W- (EC p  )4:64
[22:02:05]  and ls -l /dev/ttyS0?
[22:03:06]  ls: /dev/ttyS0: No such file or directory
[22:03:06]  oh, fun!
[22:04:36]  and ls -l /sys/dev/char/4:64 ?
[22:06:06]  ls -l /sys/dev/char/4:64
[22:06:06]  lrwxrwxrwx1 root root 0 Jun 
26 21:05 /sys/dev/char/4:64 -> .
[22:06:06]  ./../devices/virtual/tty/sclp_line0
[22:06:28]  ok, so, it's not /dev/ttyS0, it's /dev/sclp_line0?
[22:06:32]  (does that exist?)
[22:06:48]  we had an issue like this on sparc64 (#926539)
[22:07:38]  i just found that
[22:07:53]  does that device node exist for you?
[22:08:13]  crw--w1 root root4,  64 Jun 
26 20:58 /dev/sclp_line0
[22:08:43]  (and so does /dev/ttysclp0)

This is the "fault" of drivers/s390/char/sclp_tty.c. I don't know what
the best fix is; we could also patch the kernel to ensure this shows up
as /dev/sclp_line0 in /proc/consoles like sparc64 now does for sunhv,
but I worry now that this might be a game of whack-a-mole and there are
other character device drivers out there that also suffer from this.
Perhaps therefore we need to go back to looking up the device name from
the device number as has been suggested already...

James

Bug#929311: gcc-9: please include fix for pr87338

[James Clarke]

Control: tags -1 pending
(sort of; changelog won't close this bug)

On 21 May 2019, at 14:24, Jason Duerstock  wrote:
> 
> Package: gcc-9
> Version: 9-20190428-1
> Severity: normal
> User: debian-i...@lists.debian.org
> Usertags: ia64
> 
> Dear Maintainer,
> 
> Please include the fix for pr87338 that was previously included in
> gcc-8.  This patch is required for gcc-9 to build under ia64.
> 
> Thank you.

Already done in git[1] less than an hour ago :)

James

[1] 
https://salsa.debian.org/toolchain-team/gcc/commit/8477738a263fd225e71b3d629c29c1bc38faca35

Bug#867822: /usr/bin/pdebuild: Re: pbuilder: pdebuild cannot build source-only packages

[James Clarke]

Control: retitle -1 pbuilder: Breaks with --debbuildopts -S
Control: tags -1 wontfix

On 16 May 2019, at 15:18, Ritesh Raj Sarraf  wrote:
> 
> Package: pbuilder
> Version: 0.230.4
> Followup-For: Bug #867822
> 
> I have run into the same problem and would appreciate if this issue was
> resolved. For one, there's always a (good) reason for people to be doing
> source-only uploads. There are many Debian derivaties.
> 
> Secondly, there's a large number of packages I'd love to see only be
> uploaded through source-only uploads. Especially the ones like node-*,
> and the Java ones.
> 
> Third, like many others have said, for many packages it is a complete
> waste of resources. For example, I had the same problem when maintaining
> Virtualbox. And, as you see below, the same problem with my current
> package: user-mode-linux
> 
> And then, in DBug #928924, you could see another good reason why some
> want source only uploads.
> 
> So please, it'd really help a good many DDs, who have reasons to prefer
> source-only uploads.

Please read the entire thread, in particular [1]. If you want to do a
source-only upload without building binaries at the same time, just use
`dpkg-buildpackage -S`. I really don't think `pdebuild --debbuildopts -S` is a
useful thing to be doing; it's a waste of time with added complexity. We
support source-only uploads using pdebuild/pbuilder with --source-only-changes,
so please do not erroneously assert that we do not support source-only uploads.
We do. But using a chroot to just build a source package is, in my opinion,
pointless (unless using something like --use-pdebuild-internal, but that's
fairly obscure and not so well maintained).

Regards,
James

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867822#10

Bug#928068: ruby2.5: FTBFS on ia64 due to segfault

[James Clarke]

Source: ruby2.5
Version: 2.5.0~preview1-1
Severity: important
Tags: upstream patch
Forwarded: https://github.com/ruby/ruby/pull/2155
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi,
Currently, ruby2.5 FTBFS, segfaulting when building documentation.
Please include the above patch applied[1] upstream (currently only to
trunk) to fix this.

Thanks,
James

[1] https://github.com/ruby/ruby/commit/ecf660e438320f501ce4e05e92a5d6c79fe4d54d

Bug#927976: gcc-8: FTBFS on ia64 due to bootstrap comparison failure

[James Clarke]

Source: gcc-8
Version: 8-20180308-1
Severity: important
Tags: upstream patch
Forwarded: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg01000.html
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi,
A bug in a new GCC 8.1 feature was exposed by an updated binutils with
debug_view support, which causes gcc-8 to FTBFS on ia64 with a bootstrap
comparison failure. Please include the above patch to fix this (possibly
only enabled on ia64 if you want to be conservative, as it has not been
widely tested on other architectures).

Thanks,
James

Bug#927358: segemehl: Please stop building on any-i386

[James Clarke]

Package: segemehl
Version: 0.3.4-1
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#927359: tabix: Please stop building on any-i386

[James Clarke]

Package: tabix
Version: 1.9-10
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#927356: qtltools: Please stop building on any-i386

[James Clarke]

Package: qtltools
Version: 1.1+dfsg-3
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#927351: augustus: Please stop building on any-i386

[James Clarke]

Package: augustus
Version: 3.3.2+dfsg-2
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#927357: samtools: Please stop building on any-i386

[James Clarke]

Package: samtools
Version: 1.9-4
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#927352: delly: Please stop building on any-i386

[James Clarke]

Package: delly
Version: 0.8.1-2
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#927354: libhts2: Please stop building on any-i386

[James Clarke]

Package: libhts2
Version: 1.9-10
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#927355: nanopolish: Please stop building on any-i386

[James Clarke]

Package: nanopolish
Version: 0.11.0-2
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#927353: libhts-dev: Please stop building on any-i386

[James Clarke]

Package: libhts-dev
Version: 1.9-10
Severity: serious

Hi,
This package uses htslib, which is no longer supported on any-i386. #914991
removed the binaries on any-i386, but until any-i386 is removed from
Architecture:, wanna-build will re-build the package, thereby reinstating the
binaries on any-i386. Please upload a new version of the source package with
any-i386 removed from Architecture: for this binary package.

Regards,
James

Bug#924722: ktexteditor: symbols update for riscv64

[James Clarke]

On 16 Mar 2019, at 11:55, Aurelien Jarno  wrote:
> 
> Source: ktexteditor
> Version: 5.54.0-1
> Severity: normal
> Tags: patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hi,
> 
> ktexteditor currently fails to build on the riscv64 architecture due to
> differences on the symbols file, as can be seen on the following build
> log:
> 
> https://buildd.debian.org/status/fetch.php?pkg=ktexteditor=riscv64=5.54.0-1=1552467392=0
> 
> The attached patch update the symbols file. It looks like riscv64
> behaves the same way than armel and mips64el, but I do not necessarily
> understand why. It would be nice if you can include it in the next
> upload.

FWIW, the non-optional (non-template instantiation) lines are down to the
default __gnu_cxx::_Lock_policy, which is defined as follows for multi-threaded
code:

#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
 && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
  _S_atomic;
#else
  _S_mutex;
#endif

However, riscv64 only has _4 and _8, which I assume is due to it only having
lr.w and lr.d. But, at the same time, this is also true for MIPS, which still
defines _1 and _2, expanding them to a masked compare-and-swap, so it seems to
me that GCC should be doing the same on riscv64 and that this is really a GCC
bug. The LLVM backend for RISC-V supports this just like for MIPS (though the
Clang frontend doesn't currently let you use atomics). Aurelien, thoughts?

James

Bug#924390: kfreebsd mount missing libbsd.so.0 -> it is not installed.

[James Clarke]

Control: tags -1 moreinfo

On Tue, Mar 12, 2019 at 01:23:53PM +0100, Thomas Schweikle wrote:
> Package: kfreeBSD-kernel

This package doesn't exist. If you insist on not using reportbug, please
do ensure that you file against a valid package.

However, in this case, I don't actually know where in the stack this bug
report belongs, in part because I don't understand how it could possibly
arise (as described below).

> Booting Debian GNU/kfreeBSD fails because mount does not find
> libbsd.so.0 and mount not build as static or libbsd.so.0 not part of
> boot filesystem.

So, I'm extremely confused as to why you are having an issue, and it's
not helped by the fact that you have not provided any kind of log file.
Please provide one (or some form of error mesage that you get, with
context).

The reasons why I don't understand how this is happening are as follows:

1. There is no initrd/initramfs on GNU/kFreeBSD; the root that gets
   mounted is your real root file system.

2. This root file system gets mounted RW during boot, as configured by
   GRUB, so there should be no need to use a mount binary other than
   much later in boot for other filesystems (the root gets mounted
   directly by the kernel since there is not yet a root).

3. The mount binary itself comes from freebsd-utils, which Depends on
   libbsd0, thus pulling in libbsd.so.0

So, really, it's a mystery to me how on earth you're having issues with
a missing libbsd.so.0 that also breaks mounting the root filesystem;
none of that should matter.

> Any idea on how to recover?

Given I have no idea what your error actually is, I can't possibly hope
to tell you how to work around it.

Regards,
James

Bug#923276: RM: sysbench [armel armhf mips mips64el mipsel s390x alpha hppa hurd-i386 ia64 m68k powerpc sh4 sparc64 x32] -- ROM; Does not build on all architectures it has previously built

[James Clarke]

On Mon, Feb 25, 2019 at 07:31:39PM +0100, Andreas Tille wrote:
> Package: ftp.debian.org
> Severity: normal
>
> Hi,
>
> please remove sysbench for the said architectures to enable its
> migration to testing.

Whilst cleaning up cruft is fine, that's not going to help you migrate
to testing when you Build-Depend on libck-dev and Depend on libck0, both
coming from src:ck which hasn't been in testing for 360 days; see
#906697.

James

Bug#923253: grub-pc: Calculates wrong partition offset for EBR partitions on FreeBSD

[James Clarke]

Package: grub-pc
Version: ...
Tags: upstream patch

Hi,
On FreeBSD, grub uses the "start" rather than the "offset" config
property to calculate the starting sector for partitions, which gives
the wrong value for EBR partitions:

> root@lemon:/home/jrtc27/src/grub2/grub2-2.02+dfsg1# geom part list
> (output trimmed and annotated)
> Geom name: ada0
> scheme: MBR
> Providers:
> 1. Name: ada0s1
>offset: 1048576 # ie 2048 sectors
>start: 2048
> 2. Name: ada0s2
>offset: 64000883712 # ie 125001726 sectors
>start: 125001726
>
> Geom name: ada0s2
> scheme: EBR
> Providers:
> 1. Name: ada0s5
>offset: 1024 # ie 2 sectors; add 125001726 from ada0s2 to get 125001728
>start: 0
> 2. Name: ada0s6
>offset: 183628727296 # ie 358649858 sectors; add 125001726 from ada0s2 to 
> get 483651584
>start: 358647810 # add 125001726 from ada0s2 to get 483649536
> root@lemon:~# fdisk -l /dev/ada0
> Disk /dev/ada0: 238.5 GiB, 256060514304 bytes, 500118192 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x20b8cc40
>
> Device  Boot Start   End   Sectors   Size Id Type
> /dev/ada0p1 * 2048 124999679 124997632  59.6G 83 Linux
> /dev/ada0p2  125001726 500117503 375115778 178.9G  5 Extended
> /dev/ada0p5  125001728 483649535 358647808   171G a5 FreeBSD
> /dev/ada0p6  483651584 500117503  16465920   7.9G 82 Linux swap / Solaris

This clearly shows that the "start" field is wrong and "offset" should
be used instead. The attached patch does this and has been tested on the
above system (consider it Signed-off-by: James Clarke
 if forwarding upstream).

Thanks,
James
Description: osdep/freebsd: Fix partition calculation for EBR entries
 For EBR partitions, "start" is the relative starting sector of the EBR header
 itself, whereas "offset" is the relative starting byte of the partition's
 contents, excluding the EBR header and any padding. Thus we must use "offset",
 and divide by the sector size to convert to sectors.
Author: James Clarke 
Last-Update: 2019-02-25
---
--- a/grub-core/osdep/freebsd/getroot.c
+++ b/grub-core/osdep/freebsd/getroot.c
@@ -338,8 +338,9 @@ grub_util_follow_gpart_up (const char *n
grub_util_follow_gpart_up (name_tmp, , name_out);
free (name_tmp);
LIST_FOREACH (config, >lg_config, lg_config)
- if (strcasecmp (config->lg_name, "start") == 0)
-   off += strtoull (config->lg_val, 0, 10);
+ if (strcasecmp (config->lg_name, "offset") == 0)
+   off += strtoull (config->lg_val, 0, 10)
+  / provider->lg_sectorsize;
if (off_out)
  *off_out = off;
return;

Bug#923197: protobuf: Enable and fix for !linux

[James Clarke]

Source: protobuf
Version: 3.6.1-3
X-Debbugs-Cc: debian-...@lists.debian.org, debian-h...@lists.debian.org

Hi,
For some reason, the "solution" for #837310 was to restrict protobuf to
build only on Linux architectures. That doesn't solve anything other
than remove the red on the buildd.d.o pages. Lots of packages out there
need protobuf to build. Please reinstate the architecture list as
Architecture: any immediately, as this is not a valid reason to restrict
the architecture list, and either debug the issue yourself on a
porterbox or let somebody else do it. Architecture: foo (where foo is
neither any nor all) should *only* be used when a package has large
quantities of architecture-specific code and porting it would be a
serious undertaking (generally kernels, compilers and low-level system
libraries). As a porter it is far more useful to have packages like this
in Build-Attempted/Failed than in Not-For-Us, since the latter are far
less visible at a glance. I also see no attempt to contact either the
GNU/Hurd or GNU/kFreeBSD porters.

James

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[James Clarke]

On 16 Feb 2019, at 22:52, Synthea  wrote:
> 
> Here's the result after installing that lib
> Note: this error seems more likely to happen with notifications

Thanks, that makes it clear what's happening. The DBus connection is being
closed by the remote end, and the exit-on-close property defaults to true,
which causes GLib to send a SIGTERM to the process. This is the intended
behaviour of applications using the session bus as per the documentation, so
you need to figure out why the remote is closing the bus, but it's very much
not HexChat's fault. Maybe GLib is doing something wrong, but more likely
there's something weird in your local setup affecting DBus, given there are no
other reports I know of of people encountering this.

Regards,
James

> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  .html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from hexchat...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/hexchat 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-
> gnu/libthread_db.so.1".
> [New Thread 0x7fffe76e6700 (LWP 25681)]
> [New Thread 0x7fffe6ee5700 (LWP 25682)]
> 
> ** (hexchat:25675): WARNING **: Invalid borders specified for theme
> pixmap:
> /usr/share/themes/Breeze-Dark/gtk-2.0/../assets/line-h.png,
> borders don't fit within the image
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:25675): WARNING **: invalid source position for vertical
> gradient
> 
> Thread 1 "hexchat" received signal SIGTERM, Terminated.
> raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51  ../sysdeps/unix/sysv/linux/raise.c: File o directory non
> esistente.
> (gdb) thread apply all bt
> 
> Thread 3 (Thread 0x7fffe6ee5700 (LWP 25682)):
> #0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
> template.S:84
> #1  0x745c99f6 in g_main_context_poll (priority= out>, n_fds=1, fds=0x7fffd80010c0, timeout=,
> context=0x56fc6b80) at ././glib/gmain.c:4228
> #2  0x745c99f6 in g_main_context_iterate
> (context=0x56fc6b80, block=block@entry=1, dispatch=dispatch@entry=1
> , self=) at ././glib/gmain.c:3924
> #3  0x745c9d82 in g_main_loop_run (loop=0x5597d6f0) at
> ././glib/gmain.c:4125
> #4  0x75b4a656 in gdbus_shared_thread_func
> (user_data=0x5597d730) at ././gio/gdbusprivate.c:247
> #5  0x745f13d5 in g_thread_proxy (data=0x56d64590) at
> ././glib/gthread.c:784
> #6  0x74157494 in start_thread (arg=0x7fffe6ee5700) at
> pthread_create.c:333
> #7  0x73e99acf in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
> 
> Thread 2 (Thread 0x7fffe76e6700 (LWP 25681)):
> #0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
> template.S:84
> #1  0x745c99f6 in g_main_context_poll (priority= out>, n_fds=1, fds=0x7fffe8c0, timeout=,
> context=0x56fc5e50) at 

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[James Clarke]

On 16 Feb 2019, at 21:38, Synthea  wrote:
> 
> Just downgraded hexchat from backports to stable (2.12.4-3), I still
> encounter the same problem. If you won't solve that I will feel obliged
> to use another client, I just cannot use a client that crashes
> everytime in minus that one minute

Please install libglib2.0-0-dbg so the stack trace is clearer.

My initial suspicion though is something about your Breeze-Dark theme is
breaking GLib2.0. You might like to try with Adwaita.

James

> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  .html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from hexchat...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/hexchat 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-
> gnu/libthread_db.so.1".
> [New Thread 0x7fffe76e6700 (LWP 22421)]
> [New Thread 0x7fffe6ee5700 (LWP 22422)]
> 
> ** (hexchat:22413): WARNING **: Invalid borders specified for theme
> pixmap:
> /usr/share/themes/Breeze-Dark/gtk-2.0/../assets/line-h.png,
> borders don't fit within the image
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> ** (hexchat:22413): WARNING **: invalid source position for vertical
> gradient
> 
> Thread 1 "hexchat" received signal SIGTERM, Terminated.
> raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51  ../sysdeps/unix/sysv/linux/raise.c: File o directory non
> esistente.
> (gdb) thread apply all bt
> 
> Thread 3 (Thread 0x7fffe6ee5700 (LWP 22422)):
> #0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
> template.S:84
> #1  0x745c99f6 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #2  0x745c9d82 in g_main_loop_run () from /lib/x86_64-linux-
> gnu/libglib-2.0.so.0
> #3  0x75b4a656 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-
> 2.0.so.0
> #4  0x745f13d5 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #5  0x74157494 in start_thread (arg=0x7fffe6ee5700) at
> pthread_create.c:333
> #6  0x73e99acf in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
> 
> Thread 2 (Thread 0x7fffe76e6700 (LWP 22421)):
> #0  0x73e9067d in poll () at ../sysdeps/unix/syscall-
> template.S:84
> #1  0x745c99f6 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #2  0x745c9b0c in g_main_context_iteration () from /lib/x86_64-
> linux-gnu/libglib-2.0.so.0
> #3  0x745c9b51 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #4  0x745f13d5 in ?? () from /lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #5  0x74157494 in start_thread (arg=0x7fffe76e6700) at
> pthread_create.c:333
> #6  0x73e99acf in clone () at
> 

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[James Clarke]

On 14 Feb 2019, at 03:07, Synthea  wrote:
> 
> Here's the full backtrace with the command you asked:
> 
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  .html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from hexchat...(no debugging symbols found)...done.
> (gdb) thread apply all bt
> (gdb) run

You need to run it at the point when the SIGTERM is received, otherwise it
won't do anything.

James

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[James Clarke]

Control: tags -1 moreinfo
Control: retitle -1 [hexchat] Receives unexpected SIGTERM

On Thu, Feb 14, 2019 at 03:06:32AM +0100, Synthea wrote:
> Package: hexchat
> Version: 2.14.2-3~bpo9+1
> Severity: important
>
> Noticed this problem while running hexchat in gdb
> Thread 1 "hexchat" received signal SIGTERM, Terminated.
> raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51

So this is telling you something (maybe hexchat itself, though likely
not) sent a SIGTERM signal to hexchat. Are you low on memory (since that
could cause the OOM killer to send a SIGTERM to hexchat)? Please run the
"thread apply all bt" command to get a backtrace so we can have more of
an idea what's going on

> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

This is not the error. This is just GDB trying to print out the source
code corresponding to where the debugger as stopped, but since you don't
have glibc's source code unpacked in a location it can find, it instead
prints this message to tell you it can't find the source.

James

Bug#922005: RM: mash [mips mips64el mipsel s390x hppa hurd-i386 ia64 powerpc ppc64 sparc64] -- ROM; Does not build on all architectures due to new Build-Depends

[James Clarke]

Control: tags -1 moreinfo

On Mon, Feb 11, 2019 at 08:08:22AM +0100, Andreas Tille wrote:
> Package: ftp.debian.org
> Severity: normal
>
> Hi,
>
> due to the new dependency libmurmurhash which is not yet build on all
> architectures mash is not build on all architectures where it has build
> before.  The background is that the new version of mash (as many other
> Debian packages) was shipping a code copy of libmurmurhash which was
> even less portable than the libmurmurhash package.  There is work
> ongoing to make libmurmurhash building on all supported architectures
> but since we are approaching the freeze this will not happen right in
> time.  So please remove the said architectures for the time beeing to
> enable mash migrating to testing.
>
> Thank you for your work as ftpmaster

I don't see why this is necessary. Upload a fixed libmurmurhash and then
we don't have to regress. The only reason libmurmurhash is currently not
built on those architectures is because the test suite runs the
non-portable reference implementation, which fails to byte-swap on
big-endian machines and therefore gives a (consistent) different output.
This has been fixed upstream in [1]. Just upload a -3 with this patch.
Unless there's something else I'm missing, I'm disappointed that this is
the action you take rather than spend the 5-10 minutes required to fix
the problem.

James

[1] 
https://github.com/kloetzl/libmurmurhash/commit/3b6fc731ae4b6405a2073a2b839884f75b6e6f31

Bug#921838: ppl: FTBFS (LaTeX error)

[James Clarke]

Looks like this common issue is in fact #921272.
(i.e. the currently-packaged tabu broke with recent TeX Live)

James

Bug#920386: build_user configuration crashes with "uninitialized value $chroot_arch in scalar chomp"

[James Clarke]

On Thu, Jan 24, 2019 at 06:06:30PM -0500, Antoine Beaupre wrote:
> Package: sbuild
> Version: 0.78.0-2
> Severity: normal
>
> I'm trying to setup sbuild so it builds under a different user by
> default. The sbuild.conf(5) manpage says:
>
>BUILD_USER
>   STRING type.  Username used for running dpkg-buildpackage. By 
> default the
>   user  running sbuild is used within the chroot as well but that 
> might al‐
>   low a process from within the chroot to break out of the  
> chroot  by  at‐
>   taching to a process running outside the chroot with eg. gdb 
> and then be‐
>   coming root inside the chroot through schroot and thus be able  
> to  leave
>   the chroot.
>
>   build_user = ...;
>
> I'm assuming the example code there is a typo and should be really:
>
> $build_user = 'sbuild';
>
> ... so I add the above to my `.sbuildrc`. Then I try a build and it
> fails early in the process:
>
> E: read_command failed to execute dpkg
> Use of uninitialized value $chroot_arch in scalar chomp at 
> /usr/share/perl5/Sbui
> ld/Build.pm line 3024.
>
> The "sbuild" user exists in the chroot:
>
> $ schroot -c unstable-amd64-sbuild --directory / id sbuild
> uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)
>
> I have tried to look at the line pointed at by the error message:
>
> chomp(my $chroot_arch = $self->get('Session')->read_command(
>   { COMMAND => ['dpkg', '--print-architecture'],
> USER => $self->get_conf('BUILD_USER'),
> PRIORITY => 0,
> DIR => '/' }));
>
> .. but to figure out what the problem is, you need to dig into
> `read_command`, which is quite a rabbit hole. It calls
> Chroot::read_command which calls pipe_command, which calls
> pipe_command_internal, which calls exec_command, and *then* we hit the
> schroot specific code with get_command_internal, and *finally*
> _get_exec_argv, which shows the user is passed to the `schroot -u`
> argument.
>
> When trying to reproduce the problem outside of sbuild, I therefore
> do:
>
> $ schroot -c unstable-amd64-sbuild --directory / -u sbuild id
> [schroot] password for sbuild:
>
> I think that's where the problem lies: stdin is probably closed which
> makes the command fail. Even if it would be open, the process would
> just hang asking for a password, which doesn't exist (set to '*' in
> /etc/shadow).
>
> If I run schroot as root, that works however:
>
> $ sudo schroot -c unstable-amd64-sbuild --directory / -u sbuild id
> uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)
>
> For what that's worth, the caller is in the `sbuild` group:
>
> $ grep sbuild /etc/group
> sbuild:x:138:anarcat
>
> The schroot has that configuration:
>
> [unstable-amd64-sbuild]
> description=Debian unstable/amd64 autobuilder
> groups=root,sbuild
> root-groups=root,sbuild
> profile=sbuild
> type=directory
> directory=/home/chroot/unstable-amd64-sbuild
> union-type=overlay
>
> So in *theory* it should allow users in the sbuild group to run
> commands without entering a password.
>
> Am I missing something?

Here's the discussion Antoine and I had on IRC about this:

[22:39:57] has anyone ever made $build_user work in sbuild? here 
it crashes with Use of uninitialized value $chroot_arch in scalar chomp at 
/usr/share/perl5/Sbuild/Build.pm line 3024.
[22:53:04]  anarcat: sounds like your chroot doesn't have that user?
[22:53:37]  sorry, *host*
[22:53:43]  the user gets passed as schroot -u
[22:54:01]  that or a perms issue
[22:54:27]  or use pbuilder :P
[23:05:04] i'll file a bug :p
[23:05:13] jrtc27: sudo schroot -u sbuild works
[23:05:19] but not as a regular user
[23:18:30]  sure
[23:18:44]  but you're not running sbuild under sudo
[23:19:25]  so schroot is also run as you
[23:20:30]  $build_user follows the rules of schroot -u argument, 
which is documented in its manpage under AUTHENTICATION
[23:21:32] ...
[23:21:38] so i need to enter the password of the sbuild user?
[23:22:05] this makes no sense to me - i can run schroot as root, 
but not as the sbuild user??
[23:22:31]  agreed that it doesn't make much sense if you're in 
root-users/groups
[23:23:08] there's also the problem that it doesn't "immediately 
fail with permission denied", it crashes with some unrelated, random message
[23:23:35] anyways, enough for today, thanks for the feedback!
[23:23:43]  well, yeah, the error running the command should be 
propagated up rather than the caller choking due to not getting output
[23:23:56] bug is #920386
[23:24:02]  so I guess two bugs, one against sbuild and one against 
schroot :P

Bug#919855: Bug#919857: 2.0.5-1 crashes

[James Clarke]

Control: forcemerge 919855 919857

On Sun, Jan 20, 2019 at 02:22:38PM +, Thorsten Glaser wrote:
> Ben Hutchings dixit:
>
> >the new Debian version crashes on s390x.  It looks like this is due to
> >an address collision between the build ID in the shared library and
> >the code in the executables.
>
>
> Helge Deller dixit:
>
> >[   58.612345] 117 (fstype): Uhuuh, elf segment at 0001 
> >requested but the memory is mapped already
>
>
> Are these two maybe related?

Pretty sure it's the same, given we have it on sparc64 too:

> [9.765691] 426 (fstype): Uhuuh, elf segment at 0010 requested 
> but the memory is mapped already
> Segmentation fault
> [9.777174] aes_sparc64: sparc64 aes opcodes not available.

(second line included to convince you I haven't just copied the error :P)

James

Bug#919688: RM: libppl-c4 libppl-dev libppl14 ppl-dev [s390x] -- ROM; Build dependency swi-prolog no longer available

[James Clarke]

Package: ftp.debian.org
Severity: normal

Hi,
I uploaded a new version of ppl, but since swi-prolog is no longer built
on s390x (due to requiring libunwind), ppl is no longer built on s390x
and thus has these binary packages as cruft. Please remove them, along
with any rdeps.

Thanks,
James

Bug#919399: FTBFS: undefined reference to makedev

[James Clarke]

Control: forcemerge 916062 -1

> On 15 Jan 2019, at 14:05, Ritesh Raj Sarraf  wrote:
> 
> Source: cowdancer
> Version: 0.87

This was already reported as the bug mentioned above and fixed in the 0.88
upload a week ago. Also please don't forward raw multi-part MIME messages; you
end up with the horrendous mess that you can see below.

James

> Severity: serious
> Tags: patch
> Justification: fails to build from source (but built successfully in the past)
> 
> Content-Type: multipart/mixed; boundary="===1317036836604284426=="
> MIME-Version: 1.0
> From: Ritesh Raj Sarraf 
> To: Debian Bug Tracking System 
> Subject: FTBFS: undefined reference to makedev
> Message-ID: 
> <154756077354.13753.2447109323940488229.report...@priyasi.researchut.com>
> X-Mailer: reportbug 7.5.1
> Date: Tue, 15 Jan 2019 19:29:33 +0530
> X-Debbugs-Cc: r...@debian.org
> 
> This is a multi-part MIME message sent by reportbug.
> 
> 
> --===1317036836604284426==
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: base64
> Content-Disposition: inline
> 
> U291cmNlOiBjb3dkYW5jZXIKVmVyc2lvbjogMC44NwpTZXZlcml0eTogc2VyaW91cwpUYWdzOiBw
> YXRjaApKdXN0aWZpY2F0aW9uOiBmYWlscyB0byBidWlsZCBmcm9tIHNvdXJjZSAoYnV0IGJ1aWx0
> IHN1Y2Nlc3NmdWxseSBpbiB0aGUgcGFzdCkKCgpsaWJ0b29sOiBjb21waWxlOiAgZ2NjIC1EUEFD
> S0FHRV9OQU1FPVwiY293ZGFuY2VyXCIgLURQQUNLQUdFX1RBUk5BTUU9XCJjb3dkYW5jZXJcIiAt
> RFBBQ0tBR0VfVkVSU0lPTj1cIjAuODdcIiAiLURQQUNLQUdFX1NUUklORz1cImNvd2RhbmNlciAw
> Ljg3XCIiIC1EUEFDS0FHRV9CVUdSRVBPUlQ9XCJcIiAtRFBBQ0tBR0VfVVJMPVwiXCIgLURQQUNL
> QUdFPVwiY293ZGFuY2VyXCIgLURWRVJTSU9OPVwiMC44N1wiIC1EU1REQ19IRUFERVJTPTEgLURI
> QVZFX1NZU19UWVBFU19IPTEgLURIQVZFX1NZU19TVEFUX0g9MSAtREhBVkVfU1RETElCX0g9MSAt
> REhBVkVfU1RSSU5HX0g9MSAtREhBVkVfTUVNT1JZX0g9MSAtREhBVkVfU1RSSU5HU19IPTEgLURI
> QVZFX0lOVFRZUEVTX0g9MSAtREhBVkVfU1RESU5UX0g9MSAtREhBVkVfVU5JU1REX0g9MSAtREhB
> VkVfRExGQ05fSD0xIC1ETFRfT0JKRElSPVwiLmxpYnMvXCIgLUkuIC1XZGF0ZS10aW1lIC1EX0ZP
> UlRJRllfU09VUkNFPTIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLURDT1dEQU5DRVJfU089XCIvdXNy
> L2xpYi9jb3dkYW5jZXIvbGliY293ZGFuY2VyLnNvXCIgLWcgLU8yIC1mZGVidWctcHJlZml4LW1h
> cD0vYnVpbGQvY293ZGFuY2VyLTAuODc9LiAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdmb3Jt
> YXQgLVdlcnJvcj1mb3JtYXQtc2VjdXJpdHkgLWMgY293ZGFuY2VyLmMgLW8gbGliY293ZGFuY2Vy
> X2xhLWNvd2RhbmNlci5vID4vZGV2L251bGwgMj4mMQpsaWJ0b29sOiBsaW5rOiBnY2MgLWZuby1z
> dHJpY3QtYWxpYXNpbmcgLURDT1dEQU5DRVJfU089XCIvdXNyL2xpYi9jb3dkYW5jZXIvbGliY293
> ZGFuY2VyLnNvXCIgLWcgLU8yIC1mZGVidWctcHJlZml4LW1hcD0vYnVpbGQvY293ZGFuY2VyLTAu
> ODc9LiAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdmb3JtYXQgLVdlcnJvcj1mb3JtYXQtc2Vj
> dXJpdHkgLVdsLC16IC1XbCxyZWxybyAtV2wsLXogLVdsLG5vdyAtbyBjb3didWlsZGVyIGNvd2J1
> aWxkZXIubyBwYXJhbWV0ZXIubyBmb3JrZXhlYy5vIGlsaXN0Y3JlYXRlLm8gbWFpbi5vIGNvd2J1
> aWxkZXJfdXRpbC5vIGxvZy5vICAtbGRsIC1sbmN1cnNlcwpsaWJ0b29sOiBsaW5rOiBnY2MgLWZu
> by1zdHJpY3QtYWxpYXNpbmcgLURDT1dEQU5DRVJfU089XCIvdXNyL2xpYi9jb3dkYW5jZXIvbGli
> Y293ZGFuY2VyLnNvXCIgLWcgLU8yIC1mZGVidWctcHJlZml4LW1hcD0vYnVpbGQvY293ZGFuY2Vy
> LTAuODc9LiAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdmb3JtYXQgLVdlcnJvcj1mb3JtYXQt
> c2VjdXJpdHkgLVdsLC16IC1XbCxyZWxybyAtV2wsLXogLVdsLG5vdyAtbyBxZW11YnVpbGRlciBx
> ZW11YnVpbGRlci1xZW11YnVpbGRlci5vIHFlbXVidWlsZGVyLXBhcmFtZXRlci5vIHFlbXVidWls
> ZGVyLWZvcmtleGVjLm8gcWVtdWJ1aWxkZXItcWVtdWlwc2FuaXRpemUubyBxZW11YnVpbGRlci1x
> ZW11YXJjaC5vIHFlbXVidWlsZGVyLWZpbGUubyBxZW11YnVpbGRlci1tYWluLm8gcWVtdWJ1aWxk
> ZXItbG9nLm8gIC1sZGwgLWxuY3Vyc2VzCi91c3IvYmluL2xkOiBxZW11YnVpbGRlci1xZW11YXJj
> aC5vOiBpbiBmdW5jdGlvbiBgcWVtdV9jcmVhdGVfYXJjaF9zZXJpYWxkZXZpY2UnOgouL3FlbXVh
> cmNoLmM6NjA6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYG1ha2VkZXYnCi91c3IvYmluL2xkOiAu
> L3FlbXVhcmNoLmM6NjI6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYG1ha2VkZXYnCi91c3IvYmlu
> L2xkOiBxZW11YnVpbGRlci1xZW11YXJjaC5vOiBpbiBmdW5jdGlvbiBgcWVtdV9jcmVhdGVfYXJj
> aF9kZXZpY2VzJzoKLi9xZW11YXJjaC5jOjg1OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBtYWtl
> ZGV2JwovdXNyL2Jpbi9sZDogLi9xZW11YXJjaC5jOjg3OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv
> IGBtYWtlZGV2JwovdXNyL2Jpbi9sZDogLi9xZW11YXJjaC5jOjg5OiB1bmRlZmluZWQgcmVmZXJl
> bmNlIHRvIGBtYWtlZGV2JwovdXNyL2Jpbi9sZDogcWVtdWJ1aWxkZXItcWVtdWFyY2gubzouL3Fl
> bXVhcmNoLmM6OTE6IG1vcmUgdW5kZWZpbmVkIHJlZmVyZW5jZXMgdG8gYG1ha2VkZXYnIGZvbGxv
> dwpjb2xsZWN0MjogZXJyb3I6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMKbWFrZVsxXTogKioq
> IFtNYWtlZmlsZTo5OTY6IHFlbXVidWlsZGVyXSBFcnJvciAxCm1ha2VbMV06ICoqKiBXYWl0aW5n
> IGZvciB1bmZpbmlzaGVkIGpvYnMuLi4uCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5ICcvYnVp
> bGQvY293ZGFuY2VyLTAuODcnCmRoX2F1dG9fYnVpbGQ6IG1ha2UgLWo0IHJldHVybmVkIGV4aXQg
> Y29kZSAyCm1ha2U6ICoqKiBbZGViaWFuL3J1bGVzOjY6IGJpbmFyeV0gRXJyb3IgMgpkcGtnLWJ1
> aWxkcGFja2FnZTogZXJyb3I6IGRlYmlhbi9ydWxlcyBiaW5hcnkgc3VicHJvY2VzcyByZXR1cm5l
> ZCBleGl0IHN0YXR1cyAyCkk6IGNvcHlpbmcgbG9jYWwgY29uZmlndXJhdGlvbgpFOiBGYWlsZWQg
> YXV0b2J1aWxkaW5nIG9mIHBhY2thZ2UKSTogdW5tb3VudGluZyAvdmFyL2NhY2hlL2FwdC9hcmNo
> aXZlcy8gZmlsZXN5c3RlbQpJOiB1bm1vdW50aW5nIGRldi9wdG14IGZpbGVzeXN0ZW0KSTogdW5t
> b3VudGluZyBkZXYvcHRzIGZpbGVzeXN0ZW0KSTogdW5tb3VudGluZyBkZXYvc2htIGZpbGVzeXN0
> 

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[James Clarke]

On 2 Jan 2019, at 17:31, Dmitry Shachnev  wrote:
> 
> Hi Adrian and Lisandro!
> 
> On Thu, Dec 27, 2018 at 10:35:25PM +0100, John Paul Adrian Glaubitz wrote:
>> Hello!
>> 
>> Would it be possible that the patch from David [1] gets included in the
>> next upload with the dependencies adjusted in debian/control for the
>> affected architectures?
>> 
>> I know the patch isn't perfect, but it helps us unblocking the reverse
>> dependencies of qttools. Currently, I have manually build qttools with
>> the patch and re-upload every the Qt team uploads a new qttools version
>> which feels like a sisyphos task [2].
> 
> What do you think of splitting qdoc into a separate package?
> 
> This way the packages that need it might explicitly build-depend on that
> package and dep-wait instead of getting build failures on some architectures.
> 
> Also we will be able to use the Architecture: field and a proper install file
> instead of this hack in debian/rules.

That's personally how I think it should be done. We can have the -dev package
Depend: qdoc [arches] during the transitional period until everything needing
qdoc explicitly (Build-)Depends on it.

James

Bug#842634: Bug#851877: fails every time

[James Clarke]

On Sat, Oct 06, 2018 at 11:38:59PM +0200, Santiago Vila wrote:
> On Mon, 15 May 2017, Adam Borowski wrote:
>
> > > Looking at /etc/hosts within the schroot, I see:
> > > 127.0.0.1   localhost
> > > 127.0.0.1   localhost ip6-localhost ip6-loopback
> > > 172.28.17.11abel.debian.org abel
> > >
> > > Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in being able
> > > to reproduce the issue on other machines as well.
> >
> > So it's a fully _reproducible_ bug, with a well-defined immediate cause
> > (even if we haven't identified the indirect cause yet) -- unlike the
> > original report by Santiago Villa.  Thus, it looks we have two different
> > bugs that just happen to trigger the same failure mode.
> >
> > And thus, even if we fix the schroot issue, Santiago's bug likely won't be
> > fixed.
>
> Hello everybody.
>
> I'd like to clarify that most probably there was only one bug here
> after all, namely, the one in schroot (#842634).
>
> I initially reported this as "random" because I had a mix of
> successful builds and failed builds, but most probably the
> autobuilders in which it failed were always the same, the ones in
> which the build succeeded were always the same, and I just failed to
> recognize the pattern.
>
> Fortunately you have found the real reason for the bug (while I was
> missing from the discussion :-), and I believe this was the only
> reason it failed for me last year.
>
> Now a simple question: Do you think the workaround you prepared could
> still be useful at all (I personally don't think so), or should I just
> reassign this to schroot and use "affects"?
>
> Thanks.

The root cause of the bug is glibc's implementation of gethostent. The
chroot's hosts file is filled by schroot by running `getent hosts`, and
this is what prints the wrong information. If you peek inside the source
of glibc's getent program, then this part of it can be extracted to the
following (LGPLv2.1, and formatting is the GNU style so don't blame me):

> #include 
> #include 
> #include 
> #include 
>
> /* putchar_unlocked exists on BSDs, but not fputs_unlocked */
> #define fputs_unlocked fputs
>
> /* This is for hosts */
> static void
> print_hosts (struct hostent *host)
> {
>   unsigned int cnt;
>
>   for (cnt = 0; host->h_addr_list[cnt] != NULL; ++cnt)
> {
>   char buf[INET6_ADDRSTRLEN];
>   const char *ip = inet_ntop (host->h_addrtype, host->h_addr_list[cnt],
>   buf, sizeof (buf));
>
>   printf ("%-15s %s", ip, host->h_name);
>
>   unsigned int i;
>   for (i = 0; host->h_aliases[i] != NULL; ++i)
> {
>   putchar_unlocked (' ');
>   fputs_unlocked (host->h_aliases[i], stdout);
> }
>   putchar_unlocked ('\n');
> }
> }
>
> int
> main (int argc, char **argv)
> {
>   struct hostent *host;
>
>   sethostent (0);
>   while ((host = gethostent ()) != NULL)
> print_hosts (host);
>   endhostent ();
>   return 0;
> }

If you compile and run this on Linux, you will get the same output as
`getent hosts`, with `::1' being turned into `127.0.0.1'. However, on a
BSD (userland) system, you get a more sane output that doesn't rewrite
IPv6 addresses. So, as this demonstrates, the root problem is that
gethostent in glibc mangles its input. What I don't know is if this is
desired behaviour; I guess someone should file a bug report upstream and
see what they say...

Bug#914230: ITP: git-imerge -- incremental merge and rebase for git

[James Clarke]

Package: wnpp
Severity: wishlist
Owner: James Clarke 

* Package name: git-imerge
  Version : 1.1.0
  Upstream Author : Michael Haggerty 
* URL : https://github.com/mhagger/git-imerge
* License : GPLv2+
  Programming Lang: Python
  Description : incremental merge and rebase for git

Performs a merge between two branches incrementally. If conflicts are
encountered, figures out exactly which pairs of commits conflict, and
presents the user with one pairwise conflict at a time for resolution.

I recently discovered this useful tool and now use it for my day-to-day
work dealing with forks of large upstream projects. I intend to maintain
this as part of PAPT (which I've just found out is open to all DDs,
though out of courtesy I've still Cc'ed debian-python).

Regards,
James

Bug#912521: perl: 5.28 FTBFS on kfreebsd: test failures

[James Clarke]

> On 31 Oct 2018, at 22:38, Niko Tyni  wrote:
> 
> Source: perl
> Version: 5.28.0-3
> Severity: important
> X-Debbugs-Cc: debian-...@lists.debian.org
> Tags: ftbfs
> 
> This package failed to build on kfreebsd-amd64.
> 
>  
> https://buildd.debian.org/status/fetch.php?pkg=perl=kfreebsd-amd64=5.28.0-3=1541024336=0
> 
>  Failed 3 tests out of 2544, 99.88% okay.
>   ../dist/Time-HiRes/t/utime.t
>   ../lib/File/Copy.t
>   run/switches.t
> 
> Copying the debian-bsd list. Could you please investigate?
> 
> The timing with the Perl 5.28 transition starting today is unfortunate;
> I didn't notice that the kfreebsd experimental buildds finally got
> around to trying perl a couple of days ago so I wasn't aware of these
> failures.
> 
> You (as in debian-bsd@) might want to consider uploading 5.28.0-3
> binaries built with DEB_BUILD_OPTIONS=nocheck or something for now to
> get the transition binNMUs. But you probably know better than me how
> all that stuff works.

Hi Niko,
I did this two weeks ago, but it turns out one of the failures (run/switches.t)
is important, as it reveals that `perl -pi -e ... /tmp/foo` is broken, which in
turn causes r-base-core's postinst to fail. I've tracked this down and sent a
patch upstream[1]; could you please apply this to the packaging?

Thanks,
James

[1] https://rt.perl.org/Ticket/Display.html?id=133668

Bug#913782: RM: bibletime [alpha hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 m68k powerpcspe ppc64 sh4 sparc64 x32] -- ANAIS; RoM; on non-current archs it depends on broken libsword11v5

[James Clarke]

On 15 Nov 2018, at 16:04, Daniel Glassey  wrote:
> On Thu, Nov 15, 2018 at 5:57 PM James Clarke  wrote:
>> On Thu, Nov 15, 2018 at 11:59:40AM +0700, Daniel Glassey wrote:
>> > Package: ftp.debian.org
>> > Severity: normal
>> >
>> > bibletime 2.11.2 only builds on amd64 arm64 armhf i386 mipsel
>> > bibletime 2.10.1 is still in unstable for the other archs. It depends on a
>> > version of libsword11v5 that does not contain the lib that it was
>> > linked against so is unusable. (same as #913070)
>> 
>> This request doesn't at all make sense and highlights a bug in your
>> package.
>> 
>> Firstly, the fact that 2.10.1 depends on libsword11v5 is irrelevant, but
>> does explain why libsword11v5 is still in the archive despite
>> libsword-1.8.1 being the new package name.
> 
> It isn't irrelevant but hopefully the upload to come will make it so, so no 
> need for me to explain.
>  
>> Secondly, why is it that bibletime is limited to these few
>> architectures? In the changelog and your commit you say "update
>> architectures to satisfy policy 5.6.8", which is completely useless
>> (*why* can we only ever build on those architectures?), and policy has
>> this to say:
>> 
>> > Specifying a list of architectures or architecture wildcards other
>> > than any is for the minority of cases where a program is not portable
>> > or is not useful on some architectures. Where possible, the program
>> > should be made portable instead.
> 
> BibleTime was changed for version 2.11 to use Qt5 instead of Qt4 including a 
> build-dep on qtwebengine5-dev.
> 
> libqt5webengine is only available on those 5 archs so it is all that 
> bibletime 2.11.2 built on.

So? Build dependencies not being available is not a reason to limit the
Architecture field. The *only* reason to have an architecture whitelist is if
your package has lots of architecture-specific code and there is no way it
could ever work on a different architecture without large changes *to the
package itself*. It's always better to use "any" if in doubt; either the build
will fail, so porters are aware the package needs fixing, or it has a build
dependency on something not currently built, and so will just wait until the
dependency is built (drawing attention to the fact that that dependency is
important).

>> Is bibletime really that non-portable? The list of architectures seems
>> extremely specific and unlikely, especially given that bibletime has
>> previously successfully built on many other architectures than these.
>> Unless bibletime has architecture-specific assembly or similar, put this
>> back to "any" and this RM should no longer be necessary.
> 
> But I've found that it turns out that it is supposed to work with qtwebkit5 
> an alternative to qtwebengine5 so I'll close this bug with an upload with an 
> alternative build-dep on qtwebkit5-dev and see how it goes.

Alternative build dependencies are discarded by wanna-build so that doesn't
actually let the package build on architectures with libqt5webkit5-dev. If you
want to use qtwebkit on some architectures, you need the appropriate
architecture restriction lists in your Build-Depends field.

James

Bug#913782: RM: bibletime [alpha hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 m68k powerpcspe ppc64 sh4 sparc64 x32] -- ANAIS; RoM; on non-current archs it depends on broken libsword11v5

[James Clarke]

On Thu, Nov 15, 2018 at 11:59:40AM +0700, Daniel Glassey wrote:
> Package: ftp.debian.org
> Severity: normal
>
> bibletime 2.11.2 only builds on amd64 arm64 armhf i386 mipsel
> bibletime 2.10.1 is still in unstable for the other archs. It depends on a
> version of libsword11v5 that does not contain the lib that it was
> linked against so is unusable. (same as #913070)

This request doesn't at all make sense and highlights a bug in your
package.

Firstly, the fact that 2.10.1 depends on libsword11v5 is irrelevant, but
does explain why libsword11v5 is still in the archive despite
libsword-1.8.1 being the new package name.

Secondly, why is it that bibletime is limited to these few
architectures? In the changelog and your commit you say "update
architectures to satisfy policy 5.6.8", which is completely useless
(*why* can we only ever build on those architectures?), and policy has
this to say:

> Specifying a list of architectures or architecture wildcards other
> than any is for the minority of cases where a program is not portable
> or is not useful on some architectures. Where possible, the program
> should be made portable instead.

Is bibletime really that non-portable? The list of architectures seems
extremely specific and unlikely, especially given that bibletime has
previously successfully built on many other architectures than these.
Unless bibletime has architecture-specific assembly or similar, put this
back to "any" and this RM should no longer be necessary.

James

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[James Clarke]

On 15 Nov 2018, at 00:41, Michael Biebl  wrote:
> 
> Am 15.11.18 um 01:14 schrieb Michael Biebl:
>> Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
>>> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
>> 
> I don't have experience with archive management for non-release
> architectures at all.
 
 The problem that we have is that it's not possible to upload a package
 to Debian which does not build any binaries on the release architectures,
 the archive would be removed from the archive immediately.
>> 
>> Is that really true?
>> Fwiw, the consolekit package, before it was removed completely, was
>> !linux-any, ie. it was only built for non-release architectures.
>> 
> 
> Forgot to add: src:consolekit did not build any arch:all package.
> 
> If you say, that this should not be possible, why did this work for
> consolekit?

Because it's not non-release, it's non-ftp-master, and hurd/kfreebsd are on
ftp-master despite being very non-release.

James

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[James Clarke]

On 14 Nov 2018, at 23:15, Jeremy Bicha  wrote:
> 
> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
>  wrote:
>> 
>> Hi Jeremy!
>> 
>> On 11/14/18 10:52 PM, Jeremy Bicha wrote:
>>> As requested, this is librsvg reintroduced for ports that don't
>>> supported the rustified librsvg yet. The name is because this is
>>> librsvg written in the C programming language (instead of in Rust).
>> 
>> Thanks a lot for your effort and the initiative, I really appreciate
>> the idea. I also apologize for my harsh wording in the heated the
>> discussion we had. I'm very glad that this - as it is always the case
>> in Debian - is leading to a productive solution. Great!
>> 
>>> Currently, the packaging builds the same binary package names as
>>> src:librsvg. There was a suggestion to use different binary names with
>>> versioned Provides (against the existing librsvg binary package
>>> names). I'm not sure that provides much benefit but we can discuss
>>> that.
>>> 
>>> I don't have the ability to do the initial upload for this package
>>> since I don't have easy access to do the binary build required for
>>> ftp-master NEW.
>>> 
>>> I don't have experience with archive management for non-release
>>> architectures at all.
>> 
>> The problem that we have is that it's not possible to upload a package
>> to Debian which does not build any binaries on the release architectures,
>> the archive would be removed from the archive immediately.
>> 
>> I assume what we could do is maybe have a package that is built from
>> multiple sources so that it builds different binary packages for the
>> Rust and non-Rust targets.
>> 
>> I have CC'ed James Clarke and Adrian Bunk who might be interested in
>> this discussion as well and probably can maybe help in the process.
>> 
>> Again, thanks a lot for the efforts and sorry for my heated and
>> unprofessional behavior.
>> 
>> Thanks a lot!
>> Adrian
>> 
>> --
>> .''`.  John Paul Adrian Glaubitz
>> : :' :  Debian Developer - glaub...@debian.org
>> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 
> Would an arch:all librsvg-c-doc package be sufficient for the "must
> build a binary package on a release architecture" requirement?

People might frown on it, but other source packages (ab)use this, and it
certainly works from a technical standpoint. I would hope there are no
objections to this approach. However, kfreebsd-* and hurd-i386 are on
ftp-master and don't (yet) have rust, so those will also keep the source
package around.

James

Bug#911700: cmake: Please include upstream patch to fix GNU/kFreeBSD install directories

[James Clarke]

Source: cmake
Version: 3.12.3-2
Severity: important
Forwarded: https://gitlab.kitware.com/cmake/cmake/merge_requests/2511
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Control: affects -1 src:apt

Hi,
Please include the above patch submitted and applied upstream to fix
GNUInstallDirs's behaviour on GNU/kFreeBSD. This fixes man pages being
installed to the wrong directory, which is causing apt (and I imagine
many other packages) to FTBFS.

Regards,
James

Bug#910359: RM: python3-astropy [kfreebsd-amd64 kfreebsd-i386] -- ROP; old version fails to configure with newer python3

[James Clarke]

Package: ftp.debian.org
Severity: normal

Hi,
Since once of the more recent python3 updates, the old version of
python3-astropy no longer installs, failing with the following:

> Setting up python3-astropy (2.0.2-2) ...
>   File "/usr/lib/python3/dist-packages/astropy/vo/client/conesearch.py", line 
> 14
> from .async import AsyncBase
>   ^
> SyntaxError: invalid syntax
> 
> dpkg: error processing package python3-astropy (--configure):

As we can't build an updated python3-astropy on the buildds until
python3-psutil has been patched to work on kFreeBSD, please remove this
now-broken package from kFreeBSD, otherwise wanna-build will keep
scheduling builds for anything depending on python3-astropy with the
belief that it is installable. Although dak will complain about broken
Depends and Build-Depends, the reality is that they are currently no
longer satisfiable anyway, in effect, so I don't personally view this as
a regression.

Thanks,
James

Bug#904336: pbuilder: pbuilder-satisfydepends: line 29: 14820 Segmentation fault

[James Clarke]

Control: reassign -1 qemu-user-static
Control: forcemerge 816097 -1

On Mon, Jul 23, 2018 at 1:32 PM, Phil Morrell  wrote:
> Package: pbuilder
> Version: 0.228.7
> Severity: important
>
>
> Hi, I got this error while trying to cross-build (amd64->armhf) a local
> backport of the latest pydenticon. I don't know why I tried
> cross-building an arch all package, but hey ho.

No you didn't, that's a native build, and this is a known deficiency with
qemu-user-static. Please use a different resolver instead (if in doubt, use
pbuilder-satisfydepends-apt).

James

> The basepath was
> originally created with:
>
> ARCH=armhf DIST=stretch-backports git-pbuilder create --debootstrap 
> qemu-debootstrap
> ARCH=armhf DIST=stretch-backports git-pbuilder update
> --
> Phil Morrell
>
>
> $ gbp buildpackage --git-dist=stretch-backports --git-arch=armhf
> gbp:info: Building with (cowbuilder) for stretch-backports:armhf
> [...]
> /usr/lib/pbuilder/pbuilder-satisfydepends: line 29: 14820 Segmentation fault  
> $CHROOTEXEC env XDG_CACHE_HOME=/root aptitude -y --without-recommends -o 
> APT::Install-Recommends=false "${APTITUDEOPT[@]}" -o 
> Aptitude::ProblemResolver::StepScore=100 -o 
> "Aptitude::ProblemResolver::Hints::KeepDummy=reject 
> pbuilder-satisfydepends-dummy :UNINST" -o 
> Aptitude::ProblemResolver::Keep-All-Level=55000 -o 
> Aptitude::ProblemResolver::Remove-Essential-Level=maximum install 
> pbuilder-satisfydepends-dummy
> E: pbuilder-satisfydepends failed.
> [...]

Bug#885852: [sparc64] klibc-utils (2.0.4-10) regression, sigserv with fstype

[James Clarke]

On 15 Jul 2018, at 19:50, Ben Hutchings  wrote:
> 
> Control: tag -1 moreinfo
> 
> On Mon, 1 Jan 2018 22:59:59 + James Clarke  wrote:
> [...]
>> Please consider applying the patch forwarded upstream (linked in an
>> earlier control message) soon; this bug means that if the current
>> initramfs is updated, it will no longer boot, as run-init will segfault
>> in klibc. Given sparc64 is not a release architecture I can't make this
>> bug RC, otherwise I'd probably go for critical.
>> 
>> (To be clear, the issue is in 2.0.4-10 simply because that is the first
>> upload to happen since sparc64 has had PIE enabled by default in GCC)
> 
> How exactly did you test this patch?  It looks like it will cause
> pipe() to crash on success.  You put the first instruction of the PIC
> prologue into a branch delay slot, which overwrites the register
> holding the pointer used to store the system call return values.

I guess nothing I ran used pipe... but you're right, I was trying to be clever
with the branch delay slots (taking into account that some them already
clobbered %g4 for a position-dependent errno address calculation) and hadn't
noticed that pipe was using %g4 as a "caller"-saved register (it's clobbered by
userspace calls...). I shall put the nops back in and somehow give it a proper
test.

James

Bug#897416: gcc: Decimal float support is not enabled on kfreebsd-amd64

[James Clarke]

Control: notfound -1 8.1.0-9 7.3.0-24thanks gcc-7/7.3.0-24
Control: found -1 7.3.0-24
Control: tags -1 upstream fixed-upstream
Control: forwarded -1 https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00219.html

On Thu, Jul 05, 2018 at 12:54:37PM +0200, Svante Signell wrote:
> On Thu, 2018-07-05 at 12:37 +0200, Svante Signell wrote:
> > On Tue, 2018-07-03 at 05:42 +0200, Matthias Klose wrote:
> > > On 01.07.2018 00:02, Svante Signell wrote:
> > > > reopen 897416
> > > > found 897416 7.3.0-24, 8.1.0-9
> > > > tags 897416 patch
> > > > thanks
> > > >
> > > > Hi, the patch by Matthias was not enough to make gcc-7,8 to build
> > > > properly. Three configure files were needed to be recreated from
> > > > their
> > > > corresponding configure.ac. Additionally, this patch use x86_64*-
> > > > *-
> > > > gnu*
> > > > to also cover the future implementation of 64bit Hurd.
> > >
> > > this is not applied upstream. Please test the patch on trunk,
> > > forward
> > > it upstream and make sure it gets applied.
> >
> > It is already forwarded upstream (somewhat differently) by James
> > Clarke: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00218.html
>
> Additional info: gcc-7-7.3.2-24 and gcc-8-8.1.0-9 built fine on
> kfreebsd-amd64 with the patch in this bug report.

Hi all,
The patch I submitted upstream (v2) has been applied to trunk (r62452).
I have modified it for the GCC Debian packaging (adding the src/ prefix
to the paths) so it should Just Work; please could you use it for the
next upload?

Thanks,
James
>From 1c703f62283a33508fbd5d2a9b38dd7bfaeb3c83 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Thu, 14 Jun 2018 15:04:47 +0100
Subject: [PATCH v2] Enable decimal float on x86_64 kFreeBSD and Hurd
To: gcc-patc...@gcc.gnu.org

config/
* dfp.m4 (enable_decimal_float): Enable for x86_64*-*-gnu* to
catch x86_64 kFreeBSD and Hurd.

gcc/
* configure: Regenerate.

libdecnumber/
* configure: Regenerate.

libgcc/
* configure: Regenerate.
---
 config/dfp.m4  | 2 +-
 gcc/configure  | 2 +-
 libdecnumber/configure | 2 +-
 libgcc/configure   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/config/dfp.m4 b/src/config/dfp.m4
index 5b29089cec5..a137ddebf8c 100644
--- a/src/config/dfp.m4
+++ b/src/config/dfp.m4
@@ -21,7 +21,7 @@ Valid choices are 'yes', 'bid', 'dpd', and 'no'.]) ;;
 [
   case $1 in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/src/gcc/configure b/src/gcc/configure
index 60d373982fd..35564942bbf 100755
--- a/src/gcc/configure
+++ b/src/gcc/configure
@@ -7458,7 +7458,7 @@ else
 
   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/src/libdecnumber/configure b/src/libdecnumber/configure
index 4cb732e80d4..b1588f4e884 100755
--- a/src/libdecnumber/configure
+++ b/src/libdecnumber/configure
@@ -4709,7 +4709,7 @@ else
 
   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/src/libgcc/configure b/src/libgcc/configure
index b2f3f870844..f395474beac 100644
--- a/src/libgcc/configure
+++ b/src/libgcc/configure
@@ -4647,7 +4647,7 @@ else
 
   case $host in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
-- 
2.17.0

Bug#884105: gdb: bump libunwind version dependency for ia64

[James Clarke]

Control: tags -1 patch

On Fri, Jan 19, 2018 at 01:12:03PM -0500, Jason Duerstock wrote:
> After some discussion on #debian-ports, I believe this should be
> changed from libunwind7-dev to libunwind-dev.
>
> Jason

I have created a merge request on Salsa for this[1].

Regards,
James

[1] https://salsa.debian.org/gdb-team/gdb/merge_requests/2

Bug#902729: Missing Conflicts with libmariadb2

[James Clarke]

Package: libmariadb3
Version: 1:3.0.3-2
Severity: serious

Hi,
Trying to install libmariadb3 on a system which already has libmariadb2
installed fails with:

> Unpacking libmariadb3:amd64 (1:3.0.3-2) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libmariadb3_1%3a3.0.3-2_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/mariadb/plugin/dialog.so', 
> which is also in package libmariadb2:amd64 2.3.3-1

The plugins are in an unversioned directory, present in both packages,
and so the two packages cannot be co-installed. Please add suitable
dependency relationships to the new libmariadb3 package to allow
upgrades to work.

Regards,
James

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

[James Clarke]

On 3 May 2018, at 09:21, Svante Signell <svante.sign...@gmail.com> wrote:
> On Wed, 2018-05-02 at 12:51 +0100, James Clarke wrote:
>> Control: reassign -1 gcc-7
>> Control: retitle -1 gcc: Decimal float support is not enabled on kfreebsd-
>> amd64
>> 
>> On 2 May 2018, at 10:38, Svante Signell <svante.sign...@gmail.com> wrote:
>>> 
>>> Source: mpfr4
>>> Version: 4.0.1-1
>>> Severity: important
>>> Tags: patch
>>> User: debian-...@lists.debian.org
>>> Usertags: kfreebsd
>>> 
>>> Hi,
>>> 
>>> mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the
>>> debian/libmpfr6.symbols
>>> file. Attached is a file with the symbols generated from the build:
>>> libmpfr6.symbols.kfreebsd-amd64.
>>> 
>>> Thanks!
>> 
>> You're right that the symbols file is currently wrong, but IMO gcc should 
>> have
>> decimal float support enabled for kfreebsd-amd64. It's enabled for
>> kfreebsd-i386 by virtue of the fact that i?86*-*-gnu* (for Hurd) matches
>> kfreebsd-i386's tuple, but there's no corresponding x86_64*-*-gnu* for a
>> future
>> 64-bit Hurd, and thus kfreebsd-amd64's tuple is not matched[0].
>> 
>> James
>> 
>> [0] https://github.com/gcc-mirror/gcc/blob/trunk/config/dfp.m4#L23-L26
> 
> Hi James,
> 
> I think it is unfortunate that you reassigned this bug to gcc-7. That will not
> solve the mpfr4 build on the buildds.
> 
> There are two ways to solve this problem:
> 1)
> - reassign this bug back to mpfr4, adding the libfr6.symbols.kfreebsd-amd64 in
> next version 4.0.1-2.

Well, if you wanted to do that, it should be by changing the (arch=...)
restriction lists in the main libfr6.symbols rather than forking a copy for
kfreebsd-amd64.

> - clone this bug to gcc-7, adding a patch to dfp.m4 so it can be integrated in
> next release of gcc-7: 7.3.0-18?

Personally I'd just get gcc patched and give back mpfr4.

> 2) (not preferred)
> - Build an NMUed version of mpfr4, 4.0.1-1.1, and install it at debian-ports. 

Indeed, unreleased uploads are best avoided when possible.

> For GNU/Hurd the entry in sources.list is
> deb http://ftp.ports.debian.org/debian-ports unreleased main
> 
> What about creating
> http://ftp.ports.debian.org/debian-ports/pool-kfreebsd-{amd64,i386} and 
> populate
> the mpfr4 packages there at pool-kfreebsd-amd64/m/. Additionally the buildds
> need to use these packages. Unfortunately I don't know how to do that.

We could, and may well eventually need an unreleased suite, but not now.
Getting the buildds to see the suite would be simple; wanna-build would need a
copy of the hurd code to tell it that unreleased exists, and our buildd setup
scripts would need tweaking to add it to apt's sources in the chroots.

> Then when gcc-7-7.3.0-18 is released, an updated version of mpfr4 is hopefully
> available (if not, what to do, how to get back to using the old version?)

In such a situation, the updated version of mpfr4 in unstable would be picked
by `apt upgrade` as unstable and unreleased get the same priority by default,
just like how you automatically get security updates from stretch/updates for
packages installed from the stretch archive on ftp-master.

James

Bug#897168: proftp: FTBFS on kfreebsd

[James Clarke]

On 2 May 2018, at 20:28, Hilmar Preuße <hill...@web.de> wrote:
> On 30.04.2018 13:17, James Clarke wrote:
> 
> Hi James,
> 
>> The problem here is that kfreebsd-kernel-headers provides
>> sys/extattr.h with these prototypes and so proftpd's configure
>> defines HAVE_SYS_EXTATTR_H, but glibc doesn't implement them, and the
>> Linux equivalents are currently just stubs that return -1 with
>> errno=ENOSYS. Thus for now I suggest you build proftpd with
>> --disable-xattr.
>> 
> Could you check if our current repository status builds on kfreebsd?
> 
> https://salsa.debian.org/debian-proftpd-team/proftpd.git

Yep, builds successfully now.

Thanks,
James

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

[James Clarke]

Control: reassign -1 gcc-7
Control: retitle -1 gcc: Decimal float support is not enabled on kfreebsd-amd64

On 2 May 2018, at 10:38, Svante Signell  wrote:
> 
> Source: mpfr4
> Version: 4.0.1-1
> Severity: important
> Tags: patch
> User: debian-...@lists.debian.org
> Usertags: kfreebsd
> 
> Hi,
> 
> mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the debian/libmpfr6.symbols
> file. Attached is a file with the symbols generated from the build:
> libmpfr6.symbols.kfreebsd-amd64.
> 
> Thanks!

You're right that the symbols file is currently wrong, but IMO gcc should have
decimal float support enabled for kfreebsd-amd64. It's enabled for
kfreebsd-i386 by virtue of the fact that i?86*-*-gnu* (for Hurd) matches
kfreebsd-i386's tuple, but there's no corresponding x86_64*-*-gnu* for a future
64-bit Hurd, and thus kfreebsd-amd64's tuple is not matched[0].

James

[0] https://github.com/gcc-mirror/gcc/blob/trunk/config/dfp.m4#L23-L26

Bug#897383: proftpd-mod-tar: FTBFS on hurd-i386

[James Clarke]

On 1 May 2018, at 22:15, Hilmar Preuße  wrote:
> 
> On 01.05.2018 20:22, Hilmar Preusse wrote:
> 
> Hi,
> 
>> We fail to build from source on Hurd:
>> 
>> https://buildd.debian.org/status/fetch.php?pkg=proftpd-mod-tar=hurd-i386=0.3.3-2=1525171751=0
>> 
> I noticed that there is v0.4 available from upstream. I pushed it to our
> repo. My impression is that it solves the bug.
> 
> https://salsa.debian.org/debian-proftpd-team/proftpd-mod-tar.git
> 
> @Hurd-Porters: could you confirm this. Thanks!

Yep, 51b160e builds fine on exodar.debian.net, the hurd-i386 porterbox.

James

Bug#897178: mozjs52: more fixes for ia64

[James Clarke]

> On 1 May 2018, at 20:31, John Paul Adrian Glaubitz 
>  wrote:
> 
> On 04/29/2018 03:16 PM, Jason Duerstock wrote:
>> Attached please find patches to let mozjs52 build on ia64, and (mostly) pass 
>> the test suite.
>> ia64 currently requires -G0 for linking, but crashes if the current 
>> *MAINT_APPEND strings are
>> used.  Also, the memory allocation fails because the address space 
>> randomizer does not
>> take into account ia64 memory allocation.
> 
> I don't think this is the right approach.
> 
> Rather, you need to make sure the allocator gets limited in its use of higher
> address space ranges like we are doing on sparc64 and arm64.
> 
> I have updated the sparc64 support patch to include "defined(__ia64__)" where
> it's still missing which seems to fix the problem for me. Attaching the
> updated sparc64 patch.

You're still dropping the __aarch64__ from the first patch :)

James

Bug#897335: libc0.1-dev: Dev package exposes extattr_set_fd, extattr_get_fd, etc. system calls

[James Clarke]

Control: retitle -1 extattr prototypes declared in kernel headers sys/extattr.h 
but not implemented by libc0.1
Control: reassign -1 libc0.1,kfreebsd-kernel-headers

On Tue, May 01, 2018 at 03:53:03PM +0200, Hilmar Preuße wrote:
> Package: libc0.1-dev
> Version: 2.27-3
> Severity: normal
>
> Dear Maintainer,
>
> I hope this is the right package to report on.
>
> I noticed that proftp v1.3.6 FTBFS on kfreebsd. James Clarke told me in
> bug #897168 that libc0.1-dev exposes some system calls in header files,
> which are not implement in any lib, hence the link stage fails.
>
> My impression is that functions, which do not exist should not be visible
> in any header files. Consider to fix the header files.

To clarify, kfreebsd-kernel-headers provides sys/extattr.h, which
declare the BSD-ish extended attributes prototypes, but for which there
is no corresponding implementation in libc0.1, not even stubs. Moreover,
libc0.1-dev provides sys/xattr.h with the Linux-ish prototypes, but
those are merely stubs in libc0.1 returning -1 with errno set to ENOSYS.
It probably makes sense to use the BSD-ish ones given they are a
slightly different interface and are OS-specific APIs, in which case
libc0.1 should gain implementations for them, though alternatively the
Linux-ish ones could be used and sys/extattr.h dropped for (non-libc)
userspace.

James

Bug#897168: proftp: FTBFS on kfreebsd

[James Clarke]

On 30 Apr 2018, at 19:22, Hilmar Preuße <hill...@web.de> wrote:
> On 30.04.2018 13:17, James Clarke wrote:
>> On 29 Apr 2018, at 22:06, Hilmar Preuße <hill...@web.de> wrote:
>>> On 29.04.2018 14:01, Hilmar Preuße wrote:
> 
> Hi James,
> 
>>> I just noticed that our package fails to build on kfreebsd:
>>> 
>>> https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg=kfreebsd-amd64=1.3.6-2=1524996945=0
>>> 
>>> Could you help us here? proftp seems to build on FreeBSD in general so
>>> there seems to be something specific to this port.
>>> 
>>> Thanks!
>>> 
>>>>  * What led up to the situation?
>>>> 
>>>> Since we uploaded proftp 1.3.6 to unstable the package fails to build on
>>>> kfreebsd, on i386 and kfreebsd-amd64. The last lines of the log are:
>>>> 
>>>> src/fsio.o: In function `sys_fsetxattr':
>>>> ./fsio.c:1018: undefined reference to `extattr_set_fd'
>>>> src/fsio.o: In function `unix_flistxattr':
>>>> ./fsio.c:640: undefined reference to `extattr_list_fd'
>>>> ./fsio.c:640: undefined reference to `extattr_list_fd'
>>>> src/fsio.o: In function `unix_llistxattr':
>>>> ./fsio.c:621: undefined reference to `extattr_list_file'
>>>> ./fsio.c:621: undefined reference to `extattr_list_file'
>>>> src/fsio.o: In function `unix_listxattr':
>>>> ./fsio.c:602: undefined reference to `extattr_list_file'
>>>> ./fsio.c:602: undefined reference to `extattr_list_file'
>>>> src/fsio.o: In function `sys_fremovexattr':
>>>> ./fsio.c:885: undefined reference to `extattr_delete_fd'
>>>> src/fsio.o: In function `sys_fgetxattr':
>>>> ./fsio.c:529: undefined reference to `extattr_get_fd'
>>>> collect2: error: ld returned 1 exit status
>>>> libtool: link: rm -f ".libs/proftpdS.o"
>>>> 
>>>> I guess some libs, needed for linking are not specified. I file that bug as
>>>> important as FreeBSD is not a release arch.
>>>> 
>> 
>> The problem here is that kfreebsd-kernel-headers provides sys/extattr.h with
>> these prototypes and so proftpd's configure defines HAVE_SYS_EXTATTR_H, but
>> glibc doesn't implement them, and the Linux equivalents are currently just
>> stubs that return -1 with errno=ENOSYS. Thus for now I suggest you build
>> proftpd with --disable-xattr.
>> 
> Huhh. My impression was, that these are rather old system calls, which
> do exist for long time now [1] and there is just another -l$lib
> statement missing. If the kfreebsd port exposes some functions in the
> header files, but finally does not implement it in any library I'd call
> that a bug. Would it make sense to file a bug against the kfreebsd port?

Yeah, please file it against kfreebsd-10 and glibc; either the prototype
should disappear from the headers or it should be implemented.

Thanks,
James

Bug#897168: proftp: FTBFS on kfreebsd

[James Clarke]

On 29 Apr 2018, at 22:06, Hilmar Preuße  wrote:
> 
> On 29.04.2018 14:01, Hilmar Preuße wrote:
> 
> Hi debian-bsd people,
> 
> I just noticed that our package fails to build on kfreebsd:
> 
> https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg=kfreebsd-amd64=1.3.6-2=1524996945=0
> 
> Could you help us here? proftp seems to build on FreeBSD in general so
> there seems to be something specific to this port.
> 
> Thanks!
> 
>>   * What led up to the situation?
>> 
>> Since we uploaded proftp 1.3.6 to unstable the package fails to build on
>> kfreebsd, on i386 and kfreebsd-amd64. The last lines of the log are:
>> 
>> src/fsio.o: In function `sys_fsetxattr':
>> ./fsio.c:1018: undefined reference to `extattr_set_fd'
>> src/fsio.o: In function `unix_flistxattr':
>> ./fsio.c:640: undefined reference to `extattr_list_fd'
>> ./fsio.c:640: undefined reference to `extattr_list_fd'
>> src/fsio.o: In function `unix_llistxattr':
>> ./fsio.c:621: undefined reference to `extattr_list_file'
>> ./fsio.c:621: undefined reference to `extattr_list_file'
>> src/fsio.o: In function `unix_listxattr':
>> ./fsio.c:602: undefined reference to `extattr_list_file'
>> ./fsio.c:602: undefined reference to `extattr_list_file'
>> src/fsio.o: In function `sys_fremovexattr':
>> ./fsio.c:885: undefined reference to `extattr_delete_fd'
>> src/fsio.o: In function `sys_fgetxattr':
>> ./fsio.c:529: undefined reference to `extattr_get_fd'
>> collect2: error: ld returned 1 exit status
>> libtool: link: rm -f ".libs/proftpdS.o"
>> 
>> I guess some libs, needed for linking are not specified. I file that bug as
>> important as FreeBSD is not a release arch.
>> 

The problem here is that kfreebsd-kernel-headers provides sys/extattr.h with
these prototypes and so proftpd's configure defines HAVE_SYS_EXTATTR_H, but
glibc doesn't implement them, and the Linux equivalents are currently just
stubs that return -1 with errno=ENOSYS. Thus for now I suggest you build
proftpd with --disable-xattr.

James

Bug#895540: nx-libs: FTBFS with parallel > 1 due to errors cleaning

[James Clarke]

On 25 Apr 2018, at 17:16, Mike Gabriel <mike.gabr...@das-netzwerkteam.de> wrote:
> 
> Control: reopen -1
> 
> Hi James, hi Adrian, hi Niels,
> (also Cc:ed: Mihai Moldovan, upstream nx-libs)
> 
> On  Do 12 Apr 2018 13:02:45 CEST, James Clarke wrote:
> 
>> Source: nx-libs
>> Version: 3.5.99.16-1
>> Severity: serious
>> 
>> Hi,
>> Currently, nx-libs FTBFS (likely only probabilistically) when built with
>> parallel > 1; this occurred on the ia64 buildd lenz[1], but I have
>> reproduced it locally in an amd64 cowbuilder chroot.
>> 
>> Please either fix the Makefile dependency issues, or disable parallel
>> cleaning.
>> 
>> Regards,
>> James
>> 
>> [1] 
>> https://buildd.debian.org/status/fetch.php?pkg=nx-libs=ia64=2%3A3.5.99.16-1%2Bb1=1523508333=0
> 
> I spent two days with this after my possible fix (running make clean with -j1 
> did not fix the problem).
> 
> One reason for the persistance of the bug is: the build does not fail in 
> clean anymore, but in the build target instead. For the same reason.
> 
> The "cause" of the underlying problem is the fix for debhelper bug #894573 
> (building with -Oline make option). Or at least, if I drop -Oline from the 
> make build calls, the package builds ok.
> 
> Unfortunately, there is not much history on the reasoning behind adding 
> -Oline to DH's make build call. Can any of you provide some background 
> information?
> 
> And: I am aware of the real underlying cause might possibly being a 
> dependency flaw in nx-libs's highly complicated Makefile target stack. 
> However, I spent two days now cleaning that up but to no avail.
> 
> I'd be happy to get some clue from any of you. I also Cc: one of our other 
> upstream devs to follow our discussion here. If any of you dislikes being 
> Cc:ed directly in this thread, please let me know.

All -Oline does is ensure that the output from the parallel commands doesn't
get mixed up:

   -O[type], --output-sync[=type]
When running multiple jobs in parallel with -j, ensure the output
of each job is collected together rather than interspersed with
output from other jobs.  If type is not specified or is target the
output from the entire recipe for each target is grouped together.
If type is line the output from each command line within a recipe
is grouped together.  If type is recurse output from an entire
recursive make is grouped together.  If type is none output
synchronization is disabled.

It should therefore be merely a cosmetic change so reading the build logs is
easier. However, this will of course slightly affect timings, and potentially
briefly block make processes from running whilst their output buffer is full,
so if you do have missing dependencies, the change in timing could be enough to
reveal the bug; the fact that it used to work is merely a coincidence, and
there's no guarantee it would have continued to do so on different systems.

Regards,
James

Bug#887494: mozjs52: FTBFS on sparc64: interpreter segfaults

[James Clarke]

On Tue, Apr 24, 2018 at 08:52:58PM +0200, John Paul Adrian Glaubitz wrote:
> On 01/17/2018 01:43 PM, John Paul Adrian Glaubitz wrote:
> > I can whip up a patch for mozjs52 to add sparc64 support if there is
> > a realistic chance for it to be merged. My m68k [3] and sh4 [4] patches for
> > mozjs52 are still without any reply, for example.
>
> Attaching said patch. I hope to get around sending a pull request on Salsa
> the next days.
>
> The patches should be applied in this order:
>
> - sh4-support.patch (#880692)
> - m68k-support.patch (#880693)
> - sparc64-support.patch (this bug report)
>
> I'll also send a clean one for alpha and ia64 (#887496).
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

> Description: Add support for sparc64
> Author: John Paul Adrian Glaubitz 
> Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
> Last-Update: 2017-06-18
>
> Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
> ===
> --- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
> +++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
> @@ -501,7 +501,7 @@ static inline void*
>  MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
>  int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 
> 0)
>  {
> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || 
> defined(__aarch64__)
> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && 
> (defined(__NetBSD__) || defined(__linux__)))

I don't think you meant to drop the __aarch64__ here (the real commit
upstream keeps it).

>  MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) 
> == 0);
>  #endif
> [...]
> Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
> ===
> --- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
> +++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
> @@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
>  void*
>  mapMemoryAt(void* desired, size_t length)
>  {
> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || 
> defined(__aarch64__)
> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && 
> (defined(__NetBSD__) || defined(__linux__)))

Ditto.

>  MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length 
> - 1) == 0);
>  #endif
> [...]

James

Bug#896084: dose-builddebcheck: Finds invalid solution with versioned provides

[James Clarke]

On Thu, Apr 19, 2018 at 11:40:53AM +0100, James Clarke wrote:
> Package: dose-builddebcheck
> Version: 5.0.1-9
> Tags: upstream
>
> [It's quite likely this should be against libdose3-ocaml(-dev) as I
> imagine this is a bug in the common library code also used by
> dose-distcheck]
>
> Hi,
> Whilst running a new kfreebsd-{amd64,i386} buildd, I noticed that
> dose-builddebcheck doesn't quite handle versioned provides correctly[1],
> when combined with versioned dependencies. This
> stems from the use of MAX_INT32-1 for an unversioned provides, which is
> of course greater than any version number used in the dependency.

It turns out this is the same problem as upstream's two failing
versioned provides tests[1]. The attached patch fixes all of this.

Regards,
James

[1] 
https://lists.gforge.inria.fr/pipermail/dose-devel/2017-September/000660.html
>From 2b89c68f0711880ce06037d3aa2680215f9a0ab1 Mon Sep 17 00:00:00 2001
From: James Clarke <jrt...@jrtc27.com>
Date: Thu, 19 Apr 2018 14:59:49 +0100
Subject: [PATCH] Fix >> and >= constraints against virtual packages

Previously, MAX_INT32-1 was used as the version number for an
unversioned provide (and also generated alongside a versioned provide),
which incorrectly satisfies any >> or >= constraint. Instead,
use --virtual--versioned- as a separate prefix for versioned
provides and constraints, whilst keeping --virtual- for unversioned
provides. This fixes the remaining broken versioned provides test cases.
---
 deb/debcudf.ml | 53 +-
 deb/tests.ml   | 26 -
 2 files changed, 35 insertions(+), 44 deletions(-)

diff --git a/deb/debcudf.ml b/deb/debcudf.ml
index c70ed67..534cb63 100644
--- a/deb/debcudf.ml
+++ b/deb/debcudf.ml
@@ -224,12 +224,16 @@ let get_cudf_version tables (package,version) =
   end
 
 let get_real_name name = 
-  (* Remove --virtual- and architecture encoding *)
+  (* Remove --virtual(--versioned)- and architecture encoding *)
   let dn = (CudfAdd.decode name) in
   let no_virtual =
 if ExtString.String.starts_with dn "--vir"
-then ExtString.String.slice ~first:10 dn
-else dn
+then begin
+  let maybe_versioned = ExtString.String.slice ~first:10 dn in
+  if ExtString.String.starts_with maybe_versioned "-ver"
+  then ExtString.String.slice ~first:11 maybe_versioned
+  else maybe_versioned
+end else dn
   in
   try
 let (n,a) = ExtString.String.split no_virtual ":" in
@@ -260,35 +264,21 @@ let loadl ?native_arch ?package_arch tables l =
   List.flatten (
 List.map (fun ((name,_) as vpkgname,constr) ->
   let encname = add_arch_info ?native_arch ?package_arch vpkgname in
-  match constr with
-  |None ->
+  let (virt_prefix, constr) =
+match constr with
+|None ->
   (* Versioned virtual packages will satisfiy non versioned 
dependencies *)
-  if (OcamlHashtbl.mem tables.virtual_table name) then
-[(encname, None);("--virtual-"^encname,Some(`Eq,Util.max32int - 
1))]
-  else
-[(encname, None)]
-  |Some(op,v) ->
+  ("--virtual-", None)
+|Some(op,v) ->
   (* Non-versioned virtual packages will not satisfy versioned 
dependencies. *)
   let op = Pef.Pefcudf.pefcudf_op op in
-  try
-match SSet.elements !(OcamlHashtbl.find tables.virtual_table name) 
with
-|[] -> assert false
-|l ->
-let dl = 
-  List.filter_map (function
-|(_,None) -> Some 
("--virtual-"^encname,Some(`Eq,Util.max32int))
-|(_,Some _) ->
-let constr = Some(op,get_cudf_version tables (name,v)) 
in
-Some ("--virtual-"^encname,constr)
-  ) l
-in
-if Util.StringHashtbl.mem tables.unit_table name then
-  let constr = Some(op,get_cudf_version tables (name,v)) in
-  (encname,constr)::dl
-else dl
-  with Not_found -> 
-  let constr = Some(op,get_cudf_version tables (name,v)) in
-  [(encname,constr)]
+  let constr = Some(op,get_cudf_version tables (name,v)) in
+  ("--virtual--versioned-",constr)
+  in
+  if (OcamlHashtbl.mem tables.virtual_table name) then
+[(encname, constr);(virt_prefix^encname,constr)]
+  else
+[(encname, constr)]
 ) l
   )
 
@@ -308,12 +298,13 @@ let loadlp ?native_arch ?package_arch tables l =
   List.flatten (
 List.map (fun ((name,_) as vpkgname,constr) ->
 let encname = add_arch_info ?native_arch ?package_arch vpkgname in
-let vencname = "--virtual-"^encname in 
+let vencname = "--virtual-&

Bug#896084: dose-builddebcheck: Finds invalid solution with versioned provides

[James Clarke]

Package: dose-builddebcheck
Version: 5.0.1-9
Tags: upstream

[It's quite likely this should be against libdose3-ocaml(-dev) as I
imagine this is a bug in the common library code also used by
dose-distcheck]

Hi,
Whilst running a new kfreebsd-{amd64,i386} buildd, I noticed that
dose-builddebcheck doesn't quite handle versioned provides correctly[1],
when combined with versioned dependencies. This
stems from the use of MAX_INT32-1 for an unversioned provides, which is
of course greater than any version number used in the dependency.

Below is a tiny example illustrating the problem.

Regards,
James

[1] An example is libsigrok, which build depends on libusb-1.0-0-dev (>=
1.0.16), which doesn't exist on kFreeBSD; instead libusb2 provides
libusb-1.0-0-dev (= 1.0.6). Because dose-builddebcheck thinks this
is satisfiable, wanna-build keeps scheduling builds, but apt keeps
failing to find a solution (since there isn't one).

> jrtc27@deb4g:~/tmp/dose-versioned-provides$ cat Packages
> Package: build-essential
> Version: 1
> Architecture: amd64
>
> Package: binary-package
> Version: 1
> Architecture: amd64
> Provides: provided (= 2)
> jrtc27@deb4g:~/tmp/dose-versioned-provides$ cat Sources
> Package: source-package
> Architecture: any
> Version: 1
> Build-Depends: provided (>= 3)
> jrtc27@deb4g:~/tmp/dose-versioned-provides$ dose-builddebcheck 
> --deb-native-arch=amd64 -es --dump=cudf Packages Sources
> output-version: 1.2
> native-architecture: amd64
> report:
>  -
>   package: source-package
>   version: 1
>   architecture: any
>   type: src
>   status: ok
>   installationset:
>-
> package: source-package
> version: 1
> architecture: any
> type: src
>-
> package: binary-package
> version: 1
> architecture: amd64
>-
> package: build-essential
> version: 1
> architecture: amd64
>
> binary-packages: 3
> source-packages: 1
> broken-packages: 0
> jrtc27@deb4g:~/tmp/dose-versioned-provides$ cat cudf
> preamble:
> property: native: int = [0], multiarch: string = [""], installedsize: int = 
> [0], filename: string = [""], essential: bool = [false], sourceversion: int = 
> [1], sourcenumber: string = [""], source: string = [""], priority: string = 
> [""], recommends: vpkgformula = [true!], replaces: vpkglist = [], 
> architecture: string, type: string, number: string, name: string
>
> package: binary-package%3aamd64
> version: 5
> conflicts: binary-package%3aamd64 , binary-package
> provides: binary-package , --virtual-provided%3aamd64 = 3 , 
> --virtual-provided%3aamd64 = 2147483646
> name: binary-package
> architecture: amd64
> number: 1
> source: binary-package
> sourcenumber: 1
> sourceversion: 5
> native: 1
> type: bin
> filename: Packages
>
> package: src%3asource-package
> version: 2
> depends: build-essential%3aamd64 , --virtual-provided%3aamd64 >= 4
> conflicts: src%3asource-package%3aamd64 , src%3asource-package
> provides: src%3asource-package
> name: source-package
> architecture: any
> number: 1
> source: source-package
> sourcenumber: 1
> sourceversion: 2
> type: src
>
> package: build-essential%3aamd64
> version: 2
> conflicts: build-essential%3aamd64 , build-essential
> provides: build-essential
> name: build-essential
> architecture: amd64
> number: 1
> source: build-essential
> sourcenumber: 1
> sourceversion: 2
> native: 1
> type: bin
> filename: Packages

Bug#887315: libgc FTBFS on armel: missing symbol AO_locks

[James Clarke]

On Sun, Jan 14, 2018 at 11:20:49PM +0200, Adrian Bunk wrote:
> Source: libgc
> Version: 1:7.4.2-8.1
> Severity: serious
>
> https://buildd.debian.org/status/fetch.php?pkg=libgc=armel=1%3A7.4.2-8.1=1515764936=0
>
> ...
>dh_makeshlibs -a
> dh_makeshlibs: Compatibility levels before 9 are deprecated (level 7 in use)
> dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
> file: see diff output below
> dpkg-gensymbols: warning: no debian/symbols file used as basis for generating 
> debian/libgc1c2/DEBIAN/symbols
> --- new_symbol_file (libgc1c2_1:7.4.2-8.1_armel)
> +++ dpkg-gensymbolsCP1Zv9 2018-01-12 13:48:50.806274887 +
> @@ -1,7 +1,7 @@
>  libgc.so.1 libgc1c2 #MINVER#
>   (arch=armel)AO_compare_double_and_swap_double_emulation@Base 1:7.4.2
>   (arch=armel)AO_fetch_compare_and_swap_emulation@Base 1:7.4.2
> - (arch=armel)AO_locks@Base 1:7.4.2
> +#MISSING: 1:7.4.2-8.1# (arch=armel)AO_locks@Base 1:7.4.2
>   (arch=armel)AO_pause@Base 1:7.4.2
>   (arch=armel)AO_pt_lock@Base 1:7.4.2
>   (arch=armel)AO_store_full_emulation@Base 1:7.4.2
> dh_makeshlibs: failing due to earlier errors
> debian/rules:11: recipe for target 'binary-arch' failed
> make: *** [binary-arch] Error 2
>
>
> This might be caused by the recent armv4t -> armv5te armel
> baseline change.
>
> I am completely lost regarding what is going on here,
> starting with the fact that this looks a Libatomic-ops symbol?

This one turned out to be pretty easy; libatomic-ops 7.6.0 made AO_locks
static and therefore a local symbol; from the upstream changelog:

> == [7.6.0] 2017-05-19 ==
> [...]
> * Hide AO_locks symbol

Thus the symbol should be dropped from the symbols file in libgc, which
shouldn't cause any problems, since it was an implementation detail that
was only ever exported on armel so nobody should be using it (but of
course, when has that stopped anyone...).

Regards,
James

Bug#895540: nx-libs: FTBFS with parallel > 1 due to errors cleaning

[James Clarke]

Source: nx-libs
Version: 3.5.99.16-1
Severity: serious

Hi,
Currently, nx-libs FTBFS (likely only probabilistically) when built with
parallel > 1; this occurred on the ia64 buildd lenz[1], but I have
reproduced it locally in an amd64 cowbuilder chroot.

Please either fix the Makefile dependency issues, or disable parallel
cleaning.

Regards,
James

[1] 
https://buildd.debian.org/status/fetch.php?pkg=nx-libs=ia64=2%3A3.5.99.16-1%2Bb1=1523508333=0

Bug#893691: sbuild: Missing Depends on lintian after defaults change

[James Clarke]

Package: sbuild
Version: 0.74.0-1
Severity: serious

Hi,
Now that lintian defaults to enabled in 0.74.0-1, sbuild by default will
need lintian installed, but it has no dependency on it, and thus fails
with:

> Error reading configuration: LINTIAN binary 'lintian' does not exist or is 
> not executable at /usr/share/perl5/Sbuild/Conf.pm line 76

Please fix this (I don't care if it's Depends or the default) so sbuild
isn't broken out of the box.

James

Bug#893608: sbuild: Silent arch:all defaults change breaks buildd setups

[James Clarke]

Package: sbuild
Version: 0.74.0-1
Severity: serious

[Feel free to downgrade severity, but from my PoV this needs addressing before
Buster is released]

Hi,
In the latest upload, #870263 was fixed (which I support, for what it's worth;
any+all builds is the right default for users), meaning that buildd setups now
build arch:all packages, which we *have* to work around by setting
$build_arch_all=0 in sbuild.conf. Without this, uploads are rejected by the
archive (the buildd's signing key does not have upload rights for arch:all
packages, the arch:all packages already exist, etc). This is therefore a
breaking change, and so deserves at least a mention in the NEWS file. Moreover,
having to configure this in sbuild.conf is sub-optimal; ideally, buildd would
pass --no-arch-all to sbuild when an arch:any build is requested by wanna-build;
as far as I know, the assumption is always that a non-Architecture:all build is
arch:any.

We probably also don't want lintian run during buildd builds as it fork-bombs on
packages like gcc-8-cross-ports (#890873), and there's lintian.debian.org doing
that for x86, which is probably good enough, though I suppose in an ideal world
it would be run too.

Regards,
James

Bug#892228: libsphinxbase3: Causes pocketsphinx to FTBFS on 64-bit big-endian architectures (fills testsuite logs on disk with errors)

[James Clarke]

On 7 Mar 2018, at 21:39, Samuel Thibault <sthiba...@debian.org> wrote:
> 
> Hello,
> 
> James Clarke, on mer. 07 mars 2018 00:33:05 +, wrote:
>> The build for pocketsphinx fails on 64-bit big-endian architectures,
> 
> I know, I had already reported the issue a long time ago, without
> feedback.

Yeah, I found the upstream issue after I reported this, but that doesn't
quite convey the problem seen here!

>> failing with "No space left on device", as the testsuite log files
>> fill up with hundreds of gigabytes of warnings.
> 
> Ouch!  Perhaps we should just abort the build before that happens for
> now.

Probably; either abort based on DEB_HOST_ARCH_ENDIAN and DEB_HOST_ARCH_BITS
(though maybe the 32-bit big-endian builds are broken enough to not be useful
and should be disabled too), or I guess we can mark it Not-For-Us on the
wanna-build side.

James

Bug#892234: nut: FTBFS on ia64: symbols not as expected

[James Clarke]

On 7 Mar 2018, at 02:15, Aaron M. Ucko  wrote:
> Source: nut
> Version: 2.7.4-7
> Severity: normal
> User: debian-i...@lists.debian.org
> Usertags: ia64
> 
> Builds of nut for ia64 (admittedly not a release architecture) have
> been failing with .symbols discrepancies, as detailed at [1].  Could
> you please take a look?

Dear maintainer,
SymbolsHelper is a useful tool but, but most of the time is unnecessary and
leads to a whole load of extra work, since it only whitelists/blacklists
architectures rather than looking for patterns. In this case, it looks like a
lot of these symbols should be using arch-bits=32 and arch-bits=64 rather than
whitelisting or blacklisting all the 64-bit architectures.

Regards,
James

Bug#892228: libsphinxbase3: Causes pocketsphinx to FTBFS on 64-bit big-endian architectures (fills testsuite logs on disk with errors)

[James Clarke]

Package: libsphinxbase3
Version: 0.8+5prealalpha+1-1
Severity: important
Tags: upstream
Control: affects -1 src:pocketsphinx

Hi,
The build for pocketsphinx fails on 64-bit big-endian architectures, failing
with "No space left on device", as the testsuite log files fill up with
hundreds of gigabytes of warnings. The first indication of the problem in the
log files is:

> Sorry, this does not support more than 33554432 n-grams of a particular 
> order.  Edit util/bit_packing.hh and fix the bit packing functions

where 33554432 is 0x200, i.e. 32 byte-swapped. This error isn't fatal
though, and libsphinxbase3 continues to try to build the trie, with tons of
duplicate word warnings, as it's reading all kinds of garbage. The issues stem
from a widespread use of using fread to read multi-byte values with no regard
for their endianness, with the first error, the wrong number of n-grams, coming
from reading into the "counts" array in ngram_model_trie_read_bin. The library
has functions like bio_fread which can do the byte-swapping for the caller, so
presumably these should be used instead, though for this file format there does
not seem to be an easy way to determine the endianness of the file based on
some header magic like for some of the others (but maybe it's intended to
always be little-endian).

32-bit big-endian architectures have the same underlying bugs, but it seems
they die a lot earlier, failing to calloc huge sizes (presumably these same
calls are made on 64-bit architectures but can be satisfied thanks to
overcommitting) and thus don't actually try to build the trie and spew all the
warnings.

There are "only" 62 calls to fread in sphinxbase (and a further 45 in
pocketsphinx) so it shouldn't be too hard for someone with knowledge of the
codebase to audit their uses, especially since my guess is that most of them
can be turned into something like `bio_fread(..., IS_BIG_ENDIAN)`. Similarly,
the corresponding fwrite calls should be audited too.

Regards,
James

Bug#892221: python-jpype: FTBFS on hurd-i386: jni_md_platform is not defined

[James Clarke]

Control: clone -1 -2
Control: reassign -2 gcj-6 6.4.0-12
Control: retitle -2 gcj-6: jawt_md.h and jni_md.h are in linux subdirectory on 
kFreeBSD and GNU/Hurd

On 6 Mar 2018, at 22:50, Aaron M. Ucko  wrote:
> 
> Source: python-jpype
> Version: 0.6.2+dfsg-2
> Severity: normal
> Tags: upstream
> User: debian-h...@lists.debian.org
> Usertags: hurd
> 
> Builds of python-jpype for hurd-i386 (admittedly not a release
> architecture) have been failing, as most recently seen in [1]:
> 
>  setup.py:91: UserWarning: Your platform is not being handled explicitly. It 
> may work or not!
>" It may work or not!", UserWarning)
>  Traceback (most recent call last):
>File "setup.py", line 95, in 
>  [os.path.join(java_home, 'include', jni_md_platform)]
>  NameError: name 'jni_md_platform' is not defined
> 
> Per [2], the appropriate directory name here appears to be linux(!).
> Also, sys.platform starts with "gnu" on the Hurd.

I personally think this is a bug in GCJ. OpenJDK puts them in the
$(OPENJDK_TARGET_OS) subdirectory[0] (except Windows uses win32 and macOS uses
darwin), so if it were ported to the Hurd it would presumably use either "gnu"
or "hurd" as the subdirectory name. FreeBSD's fork of OpenJDK uses "freebsd"
for the directory name[1], but GCJ also puts the files in "linux" there[2]. I
guess GCJ should be patched (and the Hurd porters should decide on a directory
name to use).

Regards,
James

[0] 
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/make/copy/CopyCommon.gmk#l31
[1] 
https://svnweb.freebsd.org/ports/head/java/openjdk8/files/patch-bsd?view=markup=460849#l8874
[2] https://github.com/gcc-mirror/gcc/blob/gcc-6-branch/libjava/Makefile.am#L907

https://github.com/gcc-mirror/gcc/blob/gcc-6-branch/libjava/Makefile.am#L942-L945

Bug#891773: [PATCH] ieee1275: Fix crash in of_path_of_nvme when of_path is empty

[James Clarke]

On Thu, Mar 01, 2018 at 05:00:28PM +0100, John Paul Adrian Glaubitz wrote:
> The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme
> support within ofpath) introduced a functional regression:
>
> On systems which are not based on Open Firmware but have at
> least one NVME device, find_obppath will return an empty path
> and appending the disk name to of_path will therefore result
> in a crash. Thus, when of_path is empty, just return the
> disk name in of_path_of_nvme.
>
> Signed-off-by: John Paul Adrian Glaubitz 
> ---
>  grub-core/osdep/linux/ofpath.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c
> index 1c30e7233..daf0f 100644
> --- a/grub-core/osdep/linux/ofpath.c
> +++ b/grub-core/osdep/linux/ofpath.c
> @@ -389,8 +389,13 @@ of_path_of_nvme(const char *sys_devname 
> __attribute__((unused)),
>  }
>  
>of_path = find_obppath (sysfs_path);
> +
> +  if(of_path)
> +strcat (of_path, disk);
> +  else
> +of_path = strdup(disk);
> +

Whitespace issues aside, should it not be returning NULL if of_path is
NULL, like the other users of find_obppath, such as of_path_of_scsi?
This should restore the behaviour from before of_path_of_nvme was added,
as grub_util_devname_to_ofpath would have previously returned NULL due
to the unknown type?

James

>free (sysfs_path);
> -  strcat (of_path, disk);
>return of_path;
>  }
>  
> -- 
> 2.16.2

Bug#891281: DO NOT use file format of /bin/sh for x32 detection!

[James Clarke]

On 1 Mar 2018, at 00:50, Ben Elliston  wrote:
> 
> On Wed, Feb 28, 2018 at 03:55:57PM +0100, Thorsten Glaser wrote:
> 
>> I really have no other idea that???s in scope. After all,
>> CC_FOR_BUILD is the *only* tool guaranteed to correspond to the
>> target (in FreeWRT speak; --build= in GNU autotools speak) system.
> 
> We're trying to guess the build system, not the target. When
> configuring cross-tools, it has always been necessary to specify the
> target triplet with --target.

Thorsten is not doing a cross-compile; the native system is x32, with an
x32->x32 compiler. The exception is that the odd binary is amd64 rather than
x32, so it's not a *pure* system, but build=host=target=x32.

James

> In a native environment, there should be numerous ways of determining
> the system ABI (if it matters) without invoking a C compiler (which is
> often not installed, leading to spurious problem reports from users).
> 
> Ben

Bug#891281: DO NOT use file format of /bin/sh for x32 detection!

[James Clarke]

On 28 Feb 2018, at 10:16, Thorsten Glaser  wrote:
> 
> On Wed, 28 Feb 2018, root wrote:
> 
>> autotools-dev (20180224.1) unstable; urgency=medium
>> 
>>  * Sync to upstream git 2018-02-24
>>[commit bd9626458c30d7faec17d7dfbd85a80617b10007]
>>+ Add detection of x32 ABI for x86_64-*-linux-gnu (closes: #891281)
> 
> Thanks to klibc lacking x32 support, /bin/sh is an amd64
> binary on x32 machines with mksh’s lksh as /bin/sh, when
> lksh is built with klibc (which is the default in Debian),
> because klibc:x32 actually builds amd64 binaries.
> 
> I’d suggest this instead, which is actually dependent on
> the compiler used¹:
> 
>x86_64:Linux:*:*)
>eval "$set_cc_for_build"
>if echo __ILP32__ | $CC_FOR_BUILD -E - 2>/dev/null \
>| grep -q __ILP32__
>then
>echo "$UNAME_MACHINE"-pc-linux-"$LIBC"
>else
>echo "$UNAME_MACHINE"-pc-linux-"$LIBC"x32
>fi
>exit ;;

Hi Thorsten,
This is what I proposed to upstream initially[0], but I was told that
CC_FOR_BUILD was deprecated and being phased out, and that I should be relying
on standard system utilities instead. I chose objdump /bin/sh as another
architecture was already doing that (though with different flags). I agree,
CC_FOR_BUILD is the only real way of determining whether the build architecture
is x32, but the upstream rules are the rules. Do you have a suggestion for
something better that doesn't rely on CC_FOR_BUILD?

James

[0] http://lists.gnu.org/archive/html/config-patches/2018-02/msg00014.html

Bug#891537: qtwebkit: Please disable JIT on ia64

[James Clarke]

Source: qtwebkit
Version: 2.3.4.dfsg-9.1
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi,
I realise that qtwebkit is deprecated and the intention is to remove it
for buster, but kde4libs and other important KDE/Qt packages still
currently use it, and this is blocking a lot of important packages on
ia64 from being built. Could you please apply the attached (trivial)
debdiff to disable the JIT on ia64 so qtwebkit will build? Let me know
if I can help by NMUing.

Thanks,
James
diff -Nru qtwebkit-2.3.4.dfsg/debian/rules qtwebkit-2.3.4.dfsg/debian/rules
--- qtwebkit-2.3.4.dfsg/debian/rules2016-10-21 13:53:04.0 +0200
+++ qtwebkit-2.3.4.dfsg/debian/rules2018-02-25 20:42:37.0 +0100
@@ -50,7 +50,7 @@
#disable JIT assembler on archs where it doesn't compile
#disable WTF_USE_3D_GRAPHICS on ARM where it doesn't compile
#disable forcing SSE2 on all other platforms
-ifneq (,$(filter alpha arm64 armel hppa m68k mips mips64 mips64el mipsel 
powerpc powerpcspe ppc64 ppc64el s390x sh4 sparc64 x32,$(DEB_HOST_ARCH)))
+ifneq (,$(filter alpha arm64 armel hppa ia64 m68k mips mips64 mips64el mipsel 
powerpc powerpcspe ppc64 ppc64el s390x sh4 sparc64 x32,$(DEB_HOST_ARCH)))
./Tools/Scripts/build-webkit --qt DEFINES+=ENABLE_JIT=0 
DEFINES+=ENABLE_YARR_JIT=0 DEFINES+=ENABLE_ASSEMBLER=0 $(QMAKE_ARGS) 
$(MAKE_ARGS)
 else ifeq ($(DEB_HOST_ARCH),armhf)
./Tools/Scripts/build-webkit --qt DEFINES+=WTF_USE_3D_GRAPHICS=0 
DEFINES+=ENABLE_JIT=0 DEFINES+=ENABLE_YARR_JIT=0 DEFINES+=ENABLE_ASSEMBLER=0 
$(QMAKE_ARGS) $(MAKE_ARGS)

Bug#891281: autotools-dev: Please update to new upstream version with x32 detection

[James Clarke]

On 24 Feb 2018, at 15:29, Henrique de Moraes Holschuh <h...@debian.org> wrote:
> On Sat, 24 Feb 2018, James Clarke wrote:
>> Hi,
>> Until today, config.guess (both upstream and in Debian) has lacked
>> support for detecting x32, instead just printing out the tuple for
>> amd64, x86_64-*-linux-gnu, and somehow this has gone unnoticed and not
>> caused much issue (with one exception being llvm-toolchain-*, which ends
>> up building a compiler which has amd64 as its default target). The above
>> commit has just been applied upstream to detect an x32 system; please
>> consider updating to the latest upstream version to include this change,
>> or backport the single commit.
> 
> Will do, expect the upload to unstable later today or tomorrow,

Great, thanks!

> and if
> you want me to, I can backport it to stretch-backports once it makes it
> to testing in 10 days or thereabouts.
> 
> However, if you need a stable *update* (not just a stable backport), I
> will need a much stronger explanation to get the stable release manager
> to approve it...

Given x32 is in debian-ports and thus only has unstable/experimental, having it
backported or included in a stable update is unnecessary, IMO. Of course, there
may be other upstream changes you deem important, but unstable is enough for
x32.

Thanks,
James

Bug#891281: autotools-dev: Please update to new upstream version with x32 detection

[James Clarke]

Source: autotools-dev
Version: 20171216.1
Tags: upstream patch fixed-upstream
User: debian-...@lists.debian.org
Usertags: port-x32
Forwarded: 
http://git.savannah.gnu.org/cgit/config.git/commit/?id=bd9626458c30d7faec17d7dfbd85a80617b10007
X-Debbugs-Cc: glaub...@physik.fu-berlin.de

Hi,
Until today, config.guess (both upstream and in Debian) has lacked
support for detecting x32, instead just printing out the tuple for
amd64, x86_64-*-linux-gnu, and somehow this has gone unnoticed and not
caused much issue (with one exception being llvm-toolchain-*, which ends
up building a compiler which has amd64 as its default target). The above
commit has just been applied upstream to detect an x32 system; please
consider updating to the latest upstream version to include this change,
or backport the single commit.

Regards,
James

Bug#853461: jackd2: ftbfs with GCC-7

[James Clarke]

On Tue, Jan 31, 2017 at 09:32:23AM +, Matthias Klose wrote:
> Package: src:jackd2
> Version: 1.9.10+20150825git1ed50c92~dfsg-4
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-7
>
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The
> severity of this report may be raised before the buster release.
> There is no need to fix this issue in time for the stretch release.
>
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc7-20170126/jackd2_1.9.10+20150825git1ed50c92~dfsg-4_unstable_gcc7.log
> The last lines of the build log are at the end of this report.
>
> To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
>
>   apt-get -t=experimental install g++
>
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-7/porting_to.html

This has been fixed upstream for over half a year, with no commits in
the packaging VCS since 2017-03-29, other than for the mass migration to
Salsa. Please upload a fixed version, either by adding the upstream
patch, or uploading a newer upstream version.

Regards,
James

Bug#890626: pam: FTCBFS due to using host libtool to link build binary

[James Clarke]

Package: src:pam
Version: 1.1.8-3.7
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,
After the latest upload of flex, cross-compiling pam fails with:

> libtool: link: gcc -o padout parse_l.o parse_y.o  
> /usr/lib/aarch64-linux-gnu/libfl.so
> /usr/lib/aarch64-linux-gnu/libfl.so: error adding symbols: File in wrong 
> format

This is because pam uses libtool configured for the host architecture to build
padout, but since flex now ships a libfl.la, libtool expands this out to
/usr/lib/$DEB_HOST_MULTIARCH/libfl.so as specified in libfl.la. The attached
patch fixes this by introducing a separate configure script for the doc/specs
subdirectory, which is configured with the host arch set to the build arch and
generates its own libtool for the subdirectory's host architecture i.e. the
real build architecture. This has been tested for both a native amd64 build as
well as an arm64 cross-build from amd64.

Regards,
James
diff -u pam-1.1.8/debian/patches-applied/series 
pam-1.1.8/debian/patches-applied/series
--- pam-1.1.8/debian/patches-applied/series
+++ pam-1.1.8/debian/patches-applied/series
@@ -29,0 +30 @@
+libtool-build-arch.patch
only in patch2:
unchanged:
--- pam-1.1.8.orig/debian/autoreconf
+++ pam-1.1.8/debian/autoreconf
@@ -0,0 +1,4 @@
+# Since a custom macro is used for the subdirectory configuration rather than
+# AC_CONFIG_SUBDIRS, we don't get any autodetection in autoreconf...
+.
+doc/specs
only in patch2:
unchanged:
--- pam-1.1.8.orig/debian/patches-applied/libtool-build-arch.patch
+++ pam-1.1.8/debian/patches-applied/libtool-build-arch.patch
@@ -0,0 +1,222 @@
+--- a/configure.in
 b/configure.in
+@@ -599,6 +599,8 @@ AC_SUBST([HAVE_KEY_MANAGEMENT], $HAVE_KE
+ 
+ AM_CONDITIONAL([HAVE_KEY_MANAGEMENT], [test "$have_key_syscalls" = 1])
+ 
++PAM_CONFIG_SUBDIRS_FOR_BUILD([doc/specs])
++
+ dnl Files to be created from when we run configure
+ AC_CONFIG_FILES([Makefile libpam/Makefile libpamc/Makefile 
libpamc/test/Makefile \
+   libpam_misc/Makefile conf/Makefile conf/pam_conv1/Makefile \
+@@ -628,7 +630,7 @@ AC_CONFIG_FILES([Makefile libpam/Makefil
+   modules/pam_umask/Makefile \
+   modules/pam_unix/Makefile modules/pam_userdb/Makefile \
+   modules/pam_warn/Makefile modules/pam_wheel/Makefile \
+-  modules/pam_xauth/Makefile doc/Makefile doc/specs/Makefile \
++  modules/pam_xauth/Makefile doc/Makefile \
+   doc/man/Makefile doc/sag/Makefile doc/adg/Makefile \
+   doc/mwg/Makefile examples/Makefile tests/Makefile \
+   xtests/Makefile])
+--- /dev/null
 b/doc/specs/configure.in
+@@ -0,0 +1,29 @@
++dnl Process this file with autoconf to produce a configure script.
++AC_INIT([Linux-PAM], 1.1.8)
++AM_INIT_AUTOMAKE([foreign])
++LT_INIT([disable-static])
++AC_PREREQ([2.61])
++
++dnl This gets called from the root configure script with our host equal to its
++dnl build arch, as we want to build a native padout.
++AC_CANONICAL_HOST
++
++dnl Checks for programs.
++AC_USE_SYSTEM_EXTENSIONS
++AC_PROG_CC
++AC_PROG_YACC
++AM_PROG_LEX
++AC_PROG_INSTALL
++AC_PROG_LN_S
++AC_PROG_MAKE_SET
++AM_PROG_CC_C_O
++PAM_LD_AS_NEEDED
++PAM_LD_NO_UNDEFINED
++PAM_LD_O1
++
++dnl Largefile support
++AC_SYS_LARGEFILE
++
++dnl Files to be created from when we run configure
++AC_CONFIG_FILES([Makefile])
++AC_OUTPUT
+--- /dev/null
 b/m4/config-subdirs-for-build.m4
+@@ -0,0 +1,146 @@
++# config-subdirs-for-build.m4
++
++dnl TODO
++AC_DEFUN([PAM_CONFIG_SUBDIRS_FOR_BUILD],
++  [
++# Remove --cache-file, --srcdir, and --disable-option-checking arguments
++# so they do not pile up. Also remove --host/--target as we will be
++# overriding them, and various arch-dependent --foodir options.
++ac_sub_configure_args=
++ac_prev=
++eval "set x $ac_configure_args"
++shift
++for ac_arg
++do
++  if test -n "$ac_prev"; then
++ac_prev=
++continue
++  fi
++  case $ac_arg in
++  -cache-file | --cache-file | --cache-fil | --cache-fi \
++  | --cache-f | --cache- | --cache | --cach | --cac | --ca | --c)
++ac_prev=cache_file ;;
++  -cache-file=* | --cache-file=* | --cache-fil=* | --cache-fi=* \
++  | --cache-f=* | --cache-=* | --cache=* | --cach=* | --cac=* | --ca=* \
++  | --c=*)
++;;
++  --config-cache | -C)
++;;
++  -srcdir | --srcdir | --srcdi | --srcd | --src | --sr)
++ac_prev=srcdir ;;
++  -srcdir=* | --srcdir=* | --srcdi=* | --srcd=* | --src=* | --sr=*)
++;;
++  -prefix | --prefix | --prefi | --pref | --pre | --pr | --p)
++ac_prev=prefix ;;
++  -prefix=* | --prefix=* | --prefi=* | --pref=* | --pre=* | --pr=* | 
--p=*)
++;;
++  --disable-option-checking)
++;;
++  -host | --host | --hos | --ho)
++ac_prev=host_alias ;;
++  -host=* | --host=* | --hos=* | --ho=*)
++;;
++  -target | --target | --targe | --targ | --tar | --ta | --t)
++ac_prev=target_alias ;;
++  -target=* | 

Bug#889829: ghc: error while loading shared libraries: libHShaskeline-0.7.3.0-ghc8.0.2.so

[James Clarke]

On 12 Feb 2018, at 15:18, John Paul Adrian Glaubitz 
 wrote:
> On 02/12/2018 04:16 PM, Holger Levsen wrote:
>> Downgrading the bug to normal, though I guess you can also close it. The
>> openjdk packages have the same issue. (But maybe you want to keep it
>> open to implement a message to the user saying "arg, /proc not mounted,
>> but we need it, aborting" or some such.)
> The Rust compiler has the same issue. Without /proc, it won't be able
> to find it's shared libraries. I'm not 100% sure, but I guess it's
> an issue when using dlopen() to load the libraries afterwards, but I never
> bothered to look into the details.

Ok, found it: _dl_get_origin tries to readlink /proc/self/exe to find the value
of $ORIGIN, falling back on the (empty) LD_ORIGIN_PATH environment variable
when that fails; I assume it does this instead of using readlink on the value of
AT_EXECFN in auxv due to the possible race condition.

This isn't really a bug in ghc, as it's a system limitation, though I guess for
Debian we could avoid the use of $ORIGIN as we know where ghc will be
installed, though given ghc-stageX are executed during the build that might be
awkward without either re-linking or setting LD_LIBRARY_PATH (or equivalent).

James

Bug#889080: closed by Gianfranco Costamagna <locutusofb...@debian.org> (Bug#889080: fixed in gdbm 1.14.1-3)

[James Clarke]

Control: reopen -1

Whilst bootstrapping gdbm no longer requires bootstrapping dietlibc,
this does not change whether dietlibc FTCBFS, which is what this bug is
about. It is obviously less important now though.

Regards,
James

On Sat, Feb 10, 2018 at 03:12:06PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:dietlibc package:
>
> #889080: dietlibc FTCBFS: dietlibc is difficult
>
> It has been closed by Gianfranco Costamagna .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Gianfranco Costamagna 
>  by
> replying to this email.
>
>
> --
> 889080: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889080
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Sat, 10 Feb 2018 15:08:44 +
> From: Gianfranco Costamagna 
> To: 889080-cl...@bugs.debian.org
> Subject: Bug#889080: fixed in gdbm 1.14.1-3
>
> Source: gdbm
> Source-Version: 1.14.1-3
>
> We believe that the bug you reported is fixed in the latest version of
> gdbm, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 889...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Gianfranco Costamagna  (supplier of updated gdbm 
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> Format: 1.8
> Date: Sat, 10 Feb 2018 13:45:31 +0100
> Source: gdbm
> Binary: libgdbm5 gdbm-l10n libgdbm-dev gdbmtool libgdbm-compat4 
> libgdbm-compat-dev
> Architecture: source
> Version: 1.14.1-3
> Distribution: unstable
> Urgency: medium
> Maintainer: Dmitry Bogatov 
> Changed-By: Gianfranco Costamagna 
> Description:
>  gdbm-l10n  - GNU dbm database routines (translation files)
>  gdbmtool   - GNU dbm database routines (command line tools)
>  libgdbm-compat-dev - GNU dbm database routines (legacy support development 
> files)
>  libgdbm-compat4 - GNU dbm database routines (legacy support runtime version)
>  libgdbm-dev - GNU dbm database routines (development files)
>  libgdbm5   - GNU dbm database routines (runtime version)
> Closes: 889057 889080 889107 889474
> Changes:
>  gdbm (1.14.1-3) unstable; urgency=medium
>  .
>[ Helmut Grohne ]
>* Add pkg.gdbm.nodietlibc build profile. (Closes: #889474)
>  .
>[ Gianfranco Costamagna ]
>* Team upload
>* Fixup typo in breaks, leading to upgrade failures (Closes: #889107)
>  Thanks  for the useful bug report!
>* Remove ia64 from dietlibc (Closes: #889057)
>* Disable for now dietlibc build, it makes bootstrap really problematic,
>  and needs some extra work (Closes: #889080).
> Checksums-Sha1:
>  b79919ae55d83648143dcd7b7763232adfef 2122 gdbm_1.14.1-3.dsc
>  d77215e7feae11c00e30a82af88094000c9fedc0 25932 gdbm_1.14.1-3.debian.tar.xz
>  7d73427cf0e16843d461e5725eaf398914170bd4 6742 gdbm_1.14.1-3_source.buildinfo
> Checksums-Sha256:
>  f74a56e78dbc6308118e272a53bbb5acc5ec1c527510a41c6c9e9ec5f8361083 2122 
> gdbm_1.14.1-3.dsc
>  5d499c3cc64c85636f5cf3cdba6a2dea17d86a6527b23ebf374e29603f79db49 25932 
> gdbm_1.14.1-3.debian.tar.xz
>  0a0008a3b15adc6fda4074bceb263dc20dfbe97fbd189c341df5f9f63717111f 6742 
> gdbm_1.14.1-3_source.buildinfo
> Files:
>  01420d20557fd495e62978bb9dddfd7c 2122 libs important gdbm_1.14.1-3.dsc
>  1dc2100d0f557fa577a0bdab78c7eba5 25932 libs important 
> gdbm_1.14.1-3.debian.tar.xz
>  4c6692759c2dc68dd981e6cefa8d2839 6742 libs important 
> gdbm_1.14.1-3_source.buildinfo
>

> Date: Thu, 1 Feb 2018 21:37:27 +0100
> From: Helmut Grohne 
> To: Debian Bug Tracking System 
> Subject: dietlibc FTCBFS: dietlibc is difficult
> User-Agent: Mutt/1.9.2 (2017-12-15)
>
> Source: dietlibc
> Version: 0.34~cvs20160606-7
> User: helm...@debian.org
> Usertags: rebootstrap
>
> dietlibc fails to cross build from source. The ultimate failure arises
> when it tries to execute diet for the host architecture.
>
> So I looked and what I found was very confusing. There are lots of
> problems. Let me start by quoting the dietlibc FAQ[1]:
>
> | Q: Do you have cross compiling support?
> | A: Yes.  Just type something like "make ARCH=arm CROSS=arm-linux- all".
> |For arm, alpha, mips, ppc, sparc and i386, shortcuts exist.  You can
> |also use "make arm", for example.  You still use the same "diet"
> |

Bug#889829: ghc: error while loading shared libraries: libHShaskeline-0.7.3.0-ghc8.0.2.so

[James Clarke]

On 8 Feb 2018, at 19:46, Holger Levsen  wrote:
> 
> On Thu, Feb 08, 2018 at 03:04:22PM +0100, Petter Reinholdtsen wrote:
>> [Clint Adams]
>>> objdump -p /usr/lib/ghc/bin/ghc-pkg | grep RUNPATH
> 
> $ objdump -p /usr/lib/ghc/bin/ghc-pkg | grep RUNPATH
>   RUNPATH
>   
> $ORIGIN/../terminfo-0.4.0.2:$ORIGIN/../ghc-boot-8.0.2:$ORIGIN/../ghc-boot-th-8.0.2:$ORIGIN/../Cabal-1.24.2.0:$ORIGIN/../process-1.4.3.0:$ORIGIN/../pretty-1.1.3.3:$ORIGIN/../directory-1.3.0.0:$ORIGIN/../unix-2.7.2.1:$ORIGIN/../time-1.6.0.1:$ORIGIN/../filepath-1.4.1.1:$ORIGIN/../binary-0.8.3.0:$ORIGIN/../containers-0.5.7.1:$ORIGIN/../bytestring-0.10.8.1:$ORIGIN/../deepseq-1.4.2.0:$ORIGIN/../array-0.5.1.1:$ORIGIN/../base-4.9.1.0:$ORIGIN/../integer-gmp-1.0.0.1:$ORIGIN/../ghc-prim-0.5.0.0:$ORIGIN/../rts
> 
> is what I get. Do you need any more info? I still see this...

Well that's correct; you can see $ORIGIN/../terminfo-0.4.0.2 in there which is
where it should be getting libHSterminfo-0.4.0.2-ghc8.0.2.so, but for some
reason your ld.so is not looking at RUNPATH; once it fails to find it on the
system search path it's supposed to then print something like:

 15470:  search 
path=/usr/lib/ghc/bin/../terminfo-0.4.0.2:/usr/lib/ghc/bin/../ghc-boot-8.0.2:/usr/lib/ghc/bin/../ghc-boot-th-8.0.2:/usr/lib/ghc/bin/../Cabal-1.24.2.0:/usr/lib/ghc/bin/../process-1.4.3.0:/usr/lib/ghc/bin/../pretty-1.1.3.3:/usr/lib/ghc/bin/../directory-1.3.0.0:/usr/lib/ghc/bin/../unix-2.7.2.1:/usr/lib/ghc/bin/../time-1.6.0.1:/usr/lib/ghc/bin/../filepath-1.4.1.1:/usr/lib/ghc/bin/../binary-0.8.3.0:/usr/lib/ghc/bin/../containers-0.5.7.1:/usr/lib/ghc/bin/../bytestring-0.10.8.1:/usr/lib/ghc/bin/../deepseq-1.4.2.0:/usr/lib/ghc/bin/../array-0.5.1.1:/usr/lib/ghc/bin/../base-4.9.1.0:/usr/lib/ghc/bin/../integer-gmp-1.0.0.1:/usr/lib/ghc/bin/../ghc-prim-0.5.0.0:/usr/lib/ghc/bin/../rts/tls/x86_64/x86_64:/usr/lib/ghc/bin/../rts/tls/x86_64:/usr/lib/ghc/bin/../rts/tls/x86_64:/usr/lib/ghc/bin/../rts/tls:/usr/lib/ghc/bin/../rts/x86_64/x86_64:/usr/lib/ghc/bin/../rts/x86_64:/usr/lib/ghc/bin/../rts/x86_64:/usr/lib/ghc/bin/../rts
 (RUNPATH from file /usr/lib/ghc/bin/ghc-pkg)

What version of glibc do you have? Have you got any interesting (to ld.so)
environment variables exported or configuration files changed?

Regards,
James

Bug#889829: ghc: error while loading shared libraries: libHShaskeline-0.7.3.0-ghc8.0.2.so

[James Clarke]

Control: tags -1 moreinfo

On Wed, Feb 07, 2018 at 05:02:09PM +0100, Holger Levsen wrote:
> Package: ghc
> Version: 8.0.2-11
> Severity: serious
>
> Selecting previously unselected package ghc.
> Preparing to unpack .../ghc_8.0.2-11_amd64.deb ...
> Unpacking ghc (8.0.2-11) ...
> Setting up libbsd-dev:amd64 (0.8.7-1) ...
> Setting up ghc (8.0.2-11) ...
> /usr/lib/ghc/bin/ghc: error while loading shared libraries:
> libHShaskeline-0.7.3.0-ghc8.0.2.so: cannot open shared object file: No
> such file or directory
> update-alternatives: using /usr/bin/ghc to provide
> /usr/bin/haskell-compiler (haskell-compiler) in auto mode
> /usr/lib/ghc/bin/ghc-pkg: error while loading shared libraries:
> libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No
> such file or directory
> dpkg: error processing package ghc (--configure):
>  installed ghc package post-installation script subprocess returned
>  error exit status 127
>  Processing triggers for man-db (2.8.0-2) ...
>  Errors were encountered while processing:
>   ghc
>   E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
> This is from a sid schroot which I first upgraded as usual, which failed
> like the above, so I removed ghc and tried to install it again, which
> then produced the output above.

Hi,
I just upgraded my sid system without issue. I also tried installing ghc
in an up-to-date cowbuilder chroot and it all worked. Can you run
`/usr/lib/ghc/bin/ghc-pkg --version` successfully? Please try running
with LD_DEBUG=libs,files and post the output.

Regards,
James

Bug#889786: ats2-lang: New upstream version available

[James Clarke]

On 6 Feb 2018, at 23:54, Matthew Danish <matthew.r.dan...@gmail.com> wrote:
> On 6 February 2018 at 21:57, James Clarke <jrt...@debian.org> wrote:
>> Package: src:ats2-lang
>> Version: 0.2.9-1
>> Severity: wishlist
>> 
>> Hi,
>> The current upstream version of ATS2 is 0.3.9; please consider updating
>> to this version.
>> 
>> Regards,
>> James
> 
> Thanks - basically the stopper has been that Hongwei changed the build system 
> and I simply haven't had the time to sort out the new binaries and libraries 
> he added.
> 
> I know someone was looking at creating a patch but that seems to have 
> disappeared... sorry.

Fair enough. I see you have no Vcs-* headers in debian/control; do you have a
repository for the packaging? If so, putting it on salsa.debian.org would be
useful. Otherwise if you like I can import the old versions with
git-buildpackage and create a repository for it at
https://salsa.debian.org/Debian/ats2-lang (or you could have an ats2 team to
put it under). I may have some time to update the package.

Regards,
James

Bug#889786: ats2-lang: New upstream version available

[James Clarke]

Package: src:ats2-lang
Version: 0.2.9-1
Severity: wishlist

Hi,
The current upstream version of ATS2 is 0.3.9; please consider updating
to this version.

Regards,
James

Bug#889727: nm.debian.org: [GIT PULL] Django 1.10 and misc fixes; Date header capitalisation

[James Clarke]

Package: nm.debian.org
Severity: normal
Tags: patch

Hi,
As mentioned on IRC, here is a series of patches for Django 1.10
compatibility, a few miscellaneous bitrot bug fixes, future-proofing
TestEmail.test_django for Django 1.11 and a somewhat unnecessary (but
the original motivation for checking out nm2.git) fix so the Date header
in emails sent via Django is capitalised.

Thanks,
James

The following changes since commit 14fa3d4cbf1f8bacd6323eca7b3acd0ba868ac89:

  Updated link in wsgi.py (2018-02-04 09:55:36 +0100)

are available in the Git repository at:

  https://salsa.debian.org/jrtc27/nm2.git

for you to fetch changes up to 07328d04eeb9f9cea6b0e4f693cf65d31a2967b7:

  Use capitalised Date header for Django emails (2018-02-06 11:41:05 +)


James Clarke (5):
  Use new-style management command options; fix keycheck command
  Fix import command now fpr is not a field in Person
  Fix uid validation when NULL causing test failures
  Fix TestEmail.test_django on Django 1.11
  Use capitalised Date header for Django emails

 backend/management/commands/export.py  |  8 
 backend/management/commands/import.py  | 28 

 backend/management/commands/process_mbox_stats.py  | 12 ++--
 backend/models.py  |  2 +-
 keyring/management/commands/keycheck.py| 23 
++-
 keyring/management/commands/keyringmaint_changes.py| 10 +-
 maintenance/management/commands/legacy_import.py   | 18 --
 maintenance/management/commands/list_emails.py | 14 --
 maintenance/management/commands/weekreport.py  | 16 
 minechangelogs/management/commands/index_changelogs.py |  8 
 process/email.py   |  2 +-
 process/tests/test_email.py| 45 
+++--
 12 files changed, 110 insertions(+), 76 deletions(-)

Bug#889657: dput(1): Final paragraph in PROFILES section ends abruptly

[James Clarke]

Package: dput-ng
Version: 1.16
Severity: normal

Hi,
The final paragraph in the PROFILES section of dput(1) ends with "When
both types of files are present," with no continuation, and it seems
this has always been the case since that text was added[0]. Please
finish the sentence so we can finally resolve the mystery of what
happens when both types of files are present!

Regards,
James

[0] 
https://anonscm.debian.org/git/collab-maint/dputng.git/commit/docs/man/dput.1.man?id=1896eb6d4e4c9ae6406b3eed9f71c244520a724d

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

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

Versions of packages dput-ng depends on:
ii  python   2.7.14-4
ii  python-dput  1.16

Versions of packages dput-ng recommends:
ii  bash-completion  1:2.1-4.3
ii  python-paramiko  2.0.0-1

dput-ng suggests no packages.

-- no debconf information

Bug#889147: abyss: PairedDBG_LoadAlgorithm test fails on sparc64 due to strict alignment violation

[James Clarke]

user debian-sp...@lists.debian.org
usertags sparc64
thanks

(You missed the User: pseudoheader)

> On 2 Feb 2018, at 14:46, David Matthew Mattli  wrote:
> 
> Package: abyss
> Severity: normal
> Tags: patch upstream
> Usertags: sparc64
> 
> Dear Maintainer,
> 
> This package currently FTBFS on sparc64 due to the
> PairedDBG_LoadAlgorithm test failing with a SIGBUS. The Kmer.load and
> Kmer.storeReverse methods in the Common/Kmer.cpp file cast a uint8_t*
> to a size_t* without ensuring the pointer value has the proper
> alignment.
> 
> To fix this I added an aligned stack allocated buffer and memcpy to
> that. Stack allocated is appropriate because the buffer size is
> small(32 bytes) and known at compile time.

Hi,
As a sparc64 porter, thanks for fixing packages! Just a couple of
comments on the patch.

> --- a/Common/Kmer.cpp
> +++ b/Common/Kmer.cpp
> @@ -188,9 +188,10 @@
>   Seq seq;
>  #if MAX_KMER > 96
>  # if WORDS_BIGENDIAN
> - const size_t *s = reinterpret_cast(src);
> + size_t buf[Kmer::NUM_BYTES];

Should be divided by sizeof(size_t). Also, why not call it s? That should
reduce the number of changes.

> + memcpy(buf, src, Kmer::NUM_BYTES);
>   size_t *d = reinterpret_cast( + 1);
> - copy(s, s + Kmer::NUM_BYTES/sizeof(size_t), 
> reverse_iterator(d));
> + copy(buf, buf + Kmer::NUM_BYTES/sizeof(size_t), 
> reverse_iterator(d));
>  # else
>   uint8_t *d = reinterpret_cast();
>   memcpy(d, src, sizeof seq);
> @@ -235,9 +236,10 @@
>  #if MAX_KMER > 96
>  # if WORDS_BIGENDIAN
>   const size_t *s = reinterpret_cast();
> - size_t *d = reinterpret_cast(dest);
> + size_t d[Kmer::NUM_BYTES];

Ditto for the size (this time you used the same name as before).

>   copy(s, s + Kmer::NUM_BYTES/sizeof(size_t),
>   reverse_iterator(d +  
> Kmer::NUM_BYTES/sizeof(size_t)));
> + memcpy(dest, d, Kmer::NUM_BYTES);
>   reverse(dest, dest + Kmer::NUM_BYTES);
>  # else
>   memcpy(dest, , Kmer::NUM_BYTES);

Regards,
James

Bug#886175: cross-toolchain-base-ports: Please add support for ia64

[James Clarke]

[sorry if HTML; replying from my phone]

> On 25 Jan 2018, at 15:17, John Paul Adrian Glaubitz 
>  wrote:
> 
>> On 01/08/2018 03:18 AM, Matthias Klose wrote:
>> Control: tags -1 - patch
>> doesn't work, using gcc-7 7.2.0-19
>> (...)
>> ia64-linux-gnu-ld.bfd.exe: cannot find -lunwind
>> collect2: error: ld returned 1 exit status
>> Makefile:977: recipe for target 'libgcc_s.so' failed
>> make[5]: *** [libgcc_s.so] Error 1
> 
> I *think* this is because libunwind-dev has to be [ia64] as well in
> debian/control.source.in, but I am not 100% sure yet. Testing now.

Well, if it didn’t work without [ia64], it won’t work with.

The problem is you need the target’s libunwind-dev, so 
cross-toolchain-base-ports needs to build it itself, I assume, if the target is 
ia64.

James

Bug#888286: openmpi: Please disable java on ia64

[James Clarke]

Source: openmpi
Version: 2.1.1-7
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi,
Currently openmpi FTBFS on ia64 as default-jdk is using gcj, which is
too old. Whilst we intend to get openjdk-8 working on ia64, that won't
happen for a while, so in the meantime please apply the attached patch
to disable java on ia64 like hppa and hurd-i386; I have verified that
openmpi successfully builds with it.

Regards,
James
diff -u -r openmpi-2.1.1/debian/rules openmpi-2.1.1.new/debian/rules
--- openmpi-2.1.1/debian/rules  2017-09-27 12:33:11.0 +
+++ openmpi-2.1.1.new/debian/rules  2018-01-24 15:12:35.076342597 +
@@ -19,7 +19,7 @@
 PSM_ARCH:= amd64 i386
 BUILTIN_ATOMICS_ARCH:= s390x
 NO_CMA_ARCH:= s390x mipsel hppa alpha armhf armel m68k sparc64
-NO_JAVA_ARCH:= hppa hurd-i386
+NO_JAVA_ARCH:= hppa hurd-i386 ia64
 NO_TEST_ARCH:= hppa hurd-i386
 
 

Bug#880332: libgudev: FTBFS: Test failures

[James Clarke]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=792845
Control: tag -1 upstream patch

On Mon, Oct 30, 2017 at 09:09:12PM +0100, Lucas Nussbaum wrote:
> Source: libgudev
> Version: 232-1
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20171030 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
> > gtkdoc-mkhtml 2>&1 --help | grep  >/dev/null "\-\-path"; \
> > if test "$?" = "0"; then \
> >   mkhtml_options="$mkhtml_options --path=\"/<>/docs\""; \
> > fi; \
> > cd html && gtkdoc-mkhtml $mkhtml_options --path=/<>/docs 
> > --path=/<>/docs gudev ../gudev-docs.xml
> > gtkdoc-fixxref --module=gudev --module-dir=html 
> > --html-dir=/usr/share/gtk-doc/html >/dev/null 2>&1
> > touch html-build.stamp
> > Making all in tests
> > gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 
> > -I/usr/include/umockdev-1.0 -I/usr/include/glib-2.0 
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I.. -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -c -o 
> > test_enumerator_filter-test-enumerator-filter.o `test -f 
> > 'test-enumerator-filter.c' || echo './'`test-enumerator-filter.c
> > /bin/bash ../libtool  --tag=CC   --mode=link gcc 
> > -I/usr/include/umockdev-1.0 -I/usr/include/glib-2.0 
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I.. -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security  -Wl,-z,relro -o test-enumerator-filter 
> > test_enumerator_filter-test-enumerator-filter.o -lumockdev -lgobject-2.0 
> > -lglib-2.0 ../libgudev-1.0.la
> > libtool: link: gcc -I/usr/include/umockdev-1.0 -I/usr/include/glib-2.0 
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I.. -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wl,-z -Wl,relro -o .libs/test-enumerator-filter 
> > test_enumerator_filter-test-enumerator-filter.o  -lumockdev -lgobject-2.0 
> > -lglib-2.0 ../.libs/libgudev-1.0.so -pthread
> > TEST: test-enumerator-filter... (pid=87060)
> > **
> > ERROR:test-enumerator-filter.c:77:main: assertion failed: 
> > (umockdev_in_mock_environment ())
> > FAIL: test-enumerator-filter
> > Makefile:646: recipe for target 'test' failed
>
> The full build log is available from:
>http://aws-logs.debian.net/2017/10/30/libgudev_232-1_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

This is caused by the newer umockdev; details and a proposed patch are
in the upstream bug report linked above.

Regards,
James

Bug#886744: libcgroup: FTBFS on ia64

[James Clarke]

Source: libcgroup
Version: 0.41-8
Tags: upstream patch
User: debian-i...@lists.debian.org
Usertags: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi,
Currently libcgroup FTBFS on ia64. This is a result of cgrulesengd.h
defining __USE_GNU itself after features.h has been included, and since
_GNU_SOURCE was not defined before features.h was included, this breaks
assumptions in the glibc headers about the implications of the different
__USE_FOO macros, eventually leading to siginfo-consts-arch.h being
included but TRAP_TRACE not having been defined (which is guarded by
__USE_XOPEN_EXTENDED). The attached patch fixes this on ia64, although
is untested elsewhere.

Regards,
James
--- a/src/daemon/cgrulesengd.c
+++ b/src/daemon/cgrulesengd.c
@@ -31,6 +31,10 @@
  * TODO Stop using netlink for communication (or at least rewrite that part).
  */
 
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE
+#endif
+
 #include "libcgroup.h"
 #include "cgrulesengd.h"
 #include "../libcgroup-internal.h"
--- a/src/daemon/cgrulesengd.h
+++ b/src/daemon/cgrulesengd.h
@@ -15,8 +15,6 @@
 #ifndef _CGRULESENGD_H
 #define _CGRULESENGD_H
 
-#include 
-
 __BEGIN_DECLS
 
 #include "config.h"
@@ -24,14 +22,6 @@ __BEGIN_DECLS
 #include 
 #include 
 
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
-
-#ifndef __USE_GNU
-#define __USE_GNU
-#endif
-
 /* The following ten macros are all for the Netlink code. */
 #define SEND_MESSAGE_LEN (NLMSG_LENGTH(sizeof(struct cn_msg) + \
sizeof(enum proc_cn_mcast_op)))

Bug#886688: packages.debian.org: Add ia64 from debian-ports

[James Clarke]

Package: www.debian.org
Tags: patch
User: www.debian@packages.debian.org
Usertag: packages
User: debian-i...@lists.debian.org
Usertag: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi,
Within debian-ports we have readded ia64 for sid/experimental and have
started bootstrapping, with automated builds hopefully starting within a
few days once we have uploaded the few remaining packages for the base
chroot. The attached untested patch should hopefully make
packages.debian.org aware of its existence; the extra code is because
ia64 still exists on ftp-master for wheezy.

Thanks,
James
>From e3e077a71660ed8029d52510361485ade7cf Mon Sep 17 00:00:00 2001
From: James Clarke <jrt...@jrtc27.com>
Date: Mon, 8 Jan 2018 15:21:33 +
Subject: [PATCH] Add ia64 from debian-ports

---
 bin/parse-contents | 8 +---
 config.sh.sed.in   | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/bin/parse-contents b/bin/parse-contents
index f228e0d..19b405d 100755
--- a/bin/parse-contents
+++ b/bin/parse-contents
@@ -51,9 +51,11 @@ my @sections = @SECTIONS;
 # Add empty section, need to search Contents directly at dist root, for 
debports compat
 push(@sections, "");
 
-my %debports_hash;
+my %debports_arch_hash;
 # copy from config.sh ${arch_debports}
-@debports_hash{qw( alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32 )} = ();
+@debports_arch_hash{qw( alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32 )} = 
();
+my %debports_suite_hash;
+@debports_suite_hash{qw( sid unstable experimental rc-buggy )} = ();
 
 $DBDIR .= "/contents";
 mkdirp( $DBDIR );
@@ -173,7 +175,7 @@ for my $suite (@suites) {
 
activate($filelist_db);
#FIXME: hardcoded archs. (debports has no contrib/non-free)
-   if (not exists $debports_hash{$arch}) {
+   if (not exists $debports_arch_hash{$arch} or not exists 
$debports_suite_hash{$suite}) {
system("ln", "-sf", basename($filelist_db),
   "$DBDIR/filelists_${suite}_all.db") == 0
   or die "Oops";
diff --git a/config.sh.sed.in b/config.sh.sed.in
index c88bbb6..45b4f4f 100644
--- a/config.sh.sed.in
+++ b/config.sh.sed.in
@@ -67,7 +67,7 @@ ext_stretch=gz
 # Refresh this architecture list using this command:
 # wget -qO - 
http://ftp.ports.debian.org/debian-ports/dists/{sid,experimental}/Release | sed 
-n 's/Architectures: //p' | tr ' ' '\n' | sort -u
 # Please remember to also update the architecture list in bin/parse-contents
-arch_debports="alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32"
+arch_debports="alpha hppa ia64 m68k powerpcspe ppc64 sh4 sparc64 x32"
 
 # Miscellaneous
 #
-- 
2.15.1

Bug#886119: e2fsprogs: FTBFS on big-endian architectures

[James Clarke]

Source: e2fsprogs
Version: 1.43.8-1
Severity: serious
Tags: upstream patch

Hi,
The latest upload of e2fsprogs FTBFS on all big-endian architectures due
to two problems in swapfs.c:

> ../../../../lib/ext2fs/swapfs.c: In function 'ext2fs_swap_super':
> ../../../../lib/ext2fs/swapfs.c:132:2: warning: implicit declaration of 
> function 'EXT2FS_BUILD_BUG_ON'; did you mean 'EXT2FS_NUM_B2C'? 
> [-Wimplicit-function-declaration]
>   EXT2FS_BUILD_BUG_ON(sizeof(sb->s_reserved) != 98 * sizeof(__le32));
>   ^~~
>   EXT2FS_NUM_B2C
> ../../../../lib/ext2fs/swapfs.c: In function 'ext2fs_swap_inode_full':
> ../../../../lib/ext2fs/swapfs.c:361:29: error: 'ext2_inode_large' undeclared 
> (first use in this function)
>   EXT2FS_BUILD_BUG_ON(sizeof(ext2_inode_large) != 160);
>  ^~~~
> ../../../../lib/ext2fs/swapfs.c:361:29: note: each undeclared identifier is 
> reported only once for each function it appears in
> Makefile:657: recipe for target 'swapfs.o' failed

Please apply the attached patch to include ext2fsP.h (for
EXT2FS_BUILD_BUG_ON) and add the missing "struct" keyword before
ext2_inode_large, which has been tested on sparc64.

Regards,
James
--- a/lib/ext2fs/swapfs.c
+++ b/lib/ext2fs/swapfs.c
@@ -19,6 +19,7 @@
 
 #include "ext2_fs.h"
 #include "ext2fs.h"
+#include "ext2fsP.h"
 #include 
 
 #ifdef WORDS_BIGENDIAN
@@ -358,7 +359,7 @@ void ext2fs_swap_inode_full(ext2_filsys
if (inode_includes(inode_size, i_projid))
 t->i_projid = ext2fs_swab16(f->i_projid);
/* catch new static fields added after i_projid */
-   EXT2FS_BUILD_BUG_ON(sizeof(ext2_inode_large) != 160);
+   EXT2FS_BUILD_BUG_ON(sizeof(struct ext2_inode_large) != 160);
 
i = sizeof(struct ext2_inode) + extra_isize + sizeof(__u32);
if (bufsize < (int) i)

Bug#885852: [sparc64] klibc-utils (2.0.4-10) regression, sigserv with fstype

[James Clarke]

Control: severity -1 important

On Sat, Dec 30, 2017 at 03:48:07PM +0300, Anatoly Pugachev wrote:
> Package: klibc-utils
> Version: 2.0.4-10
> Severity: normal
>
> Dear Maintainer,
>
> Upgrading klibc-utils from 2.0.4-9 to 2.0.4-10 started to produce sigserv in 
> fstype
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> using latest version 2.0.4-10 :
>
> $ dpkg -l klibc-utils
> ||/ Name   VersionArchitecture
>Description
> +++-==-==-==-=
> ii  klibc-utils2.0.4-10   sparc64 
>small utilities built with klibc for early boot
>
> $ /usr/lib/klibc/bin/fstype
> Segmentation fault (core dumped)
>
> $ sudo /usr/lib/klibc/bin/fstype /dev/vdiska2
> Segmentation fault
>
> I tried with upstream klibc.git repo, but getting sigserv as well, and since
> klibc.git does not have changed files almost a year now, not sure gdb 
> backtrace
> could be relevant, please see
> http://www.zytor.com/pipermail/klibc/2017-December/003965.html
>
>
>* What outcome did you expect instead?
>
> using older package version of 2.0.4-9 :
>
> # dpkg -i *.deb
> dpkg: warning: downgrading klibc-utils from 2.0.4-10 to 2.0.4-9
> (Reading database ... 68475 files and directories currently installed.)
> Preparing to unpack klibc-utils_2.0.4-9_sparc64.deb ...
> Unpacking klibc-utils (2.0.4-9) over (2.0.4-10) ...
> dpkg: warning: downgrading libklibc from 2.0.4-10 to 2.0.4-9
> Preparing to unpack libklibc_2.0.4-9_sparc64.deb ...
> Unpacking libklibc (2.0.4-9) over (2.0.4-10) ...
> Setting up libklibc (2.0.4-9) ...
> Setting up klibc-utils (2.0.4-9) ...
> root@ttip:~/1# exit
>
> mator@ttip:~/linux-2.6$ dpkg -L klibc-utils | grep fstype
> /usr/lib/klibc/bin/fstype
>
> mator@ttip:~/linux-2.6$ /usr/lib/klibc/bin/fstype
> stdin: Illegal seek
>
> mator@ttip:~$ dpkg -l klibc-utils
> ||/ Name   VersionArchitecture
>Description
> +++-==-==-==-=
> ii  klibc-utils2.0.4-9sparc64 
>small utilities built with klibc for early boot
>
> mator@ttip:~$ sudo /usr/lib/klibc/bin/fstype /dev/vdiska2
> FSTYPE=ext4
> FSSIZE=15002910720

Please consider applying the patch forwarded upstream (linked in an
earlier control message) soon; this bug means that if the current
initramfs is updated, it will no longer boot, as run-init will segfault
in klibc. Given sparc64 is not a release architecture I can't make this
bug RC, otherwise I'd probably go for critical.

(To be clear, the issue is in 2.0.4-10 simply because that is the first
upload to happen since sparc64 has had PIE enabled by default in GCC)

Regards,
James

Bug#842995: dh-make: invalid Vcs-Git stanza

[James Clarke]

On Wed, Nov 02, 2016 at 03:17:10PM +0100, IOhannes m zmölnig wrote:
> Package: dh-make
> Version: 2.201608
> Severity: normal
>
> Dear Maintainer,
>
> the Vcs-Git stanza generated by dh-make is simply wrong.
> It reads:
>https://anonscm.debian.org/collab-maint/${PKGNAME}.git
> Whereas it should read:
>https://anonscm.debian.org/git/collab-maint/${PKGNAME}.git

Hi,
The fix for this has been sitting in git for over a year[1] (with the
follow-on fixed over half a year ago[2]); could you please upload it
soon?

Thanks,
James

[1] 
https://anonscm.debian.org/cgit/collab-maint/dh-make.git/commit/?id=b5a2903efa716e898c141397a6e471ec6fd9febb
[2] 
https://anonscm.debian.org/cgit/collab-maint/dh-make.git/commit/?id=b5a2903efa716e898c141397a6e471ec6fd9febb