Bug#918662: ITS: bchunk

[Gürkan Myczko]

Package: bchunk
Version: 1.2.0-12.1
Severity: wishlist

Dear bchunk maintainer,

After checking the qualification criteria, I am filing this Intent To
Salvage (ITS) bug, following the process outlined in:

  
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging


For reference:


After the 21 days delay, if no answer has been sent to the bug [..]


… I make this the 29st January 2019.


Best wishes,

Bug#918661: pdns-server: EDNS Compliance Steps

[Dean Hamstead]

Package: pdns-server
Version: 3.4.1-4+deb8u8
Severity: normal

Dear Maintainer,

It seems that 'certain work arounds' are being removed on the 1st of Feb 2019 
according to https://dnsflagday.net/

I have generated this report https://ednscomp.isc.org/ednscomp/154f9de8ce 
(nothing secret about it), but am not clear what step I should/can/need to take 
with powerdns. Google hasnt yielded results - please prove me wrong.

Your guidance is much appreciated

Dean


-- System Information:
Debian Release: 8.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-042stab127.2 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pdns-server depends on:
ii  adduser 3.113+nmu3
ii  debconf [debconf-2.0]   1.5.56+deb8u1
ii  init-system-helpers 1.22
ii  libboost-program-options1.55.0  1.55.0+dfsg-3
ii  libboost-serialization1.55.01.55.0+dfsg-3
ii  libbotan-1.10-0 1.10.8-2+deb8u2
ii  libc6   2.19-18+deb8u10
ii  libcrypto++95.6.1-6+deb8u3
ii  libgcc1 1:4.9.2-10+deb8u2
ii  libgmp102:6.0.0+dfsg-6
ii  liblua5.1-0 5.1.5-7.1
ii  libpolarssl71.3.9-2.1+deb8u4
ii  libsqlite3-03.8.7.1-1+deb8u3
ii  libstdc++6  4.9.2-10+deb8u2
ii  lsb-base4.1+Debian13+nmu1
ii  ucf 3.0030

pdns-server recommends no packages.

Versions of packages pdns-server suggests:
ii  pdns-backend-pgsql [pdns-backend]  3.4.1-4+deb8u8
pn  pdns-recursor  

-- debconf information:
* pdns-server/localaddress: 0.0.0.0
* pdns-server/allowrecursion: 127.0.0.1

Bug#918660: exim4: request exim4.conf.template include extra .ifdefs to simplify ssl/tls setup

[Gary Dale]

Package: exim4
Version: 4.92~RC3-1
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I switched ISPs and once again had a lot of trouble configuring exim4 to work 
with it

   * What exactly did you do (or not do) that was effective (or ineffective)?
I spent hours trying out different suggestions from various sources.

   * What was the outcome of this action?
I eventually got it to work but it involved editing the exim4.conf.template 
file among others.

   * What outcome did you expect instead?
The template file should be the LAST file to touch since it is one the 
developers use to
define much of the behaviour of exim4. Special setups should, IMHO, be able to 
be done through
exim4.conf.localmacros setting up the various exim4 flags and switches.

In particular, I ended up adding the following lines to .localmacros AFTER 
modifying .template
to handle the last two:
REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
MAIN_TLS_ENABLE = 1
TLS_ON_CONNECT_PORTS = 465
REQUIRE_PROTOCOL = smtps

I changed the .template file to include:
.ifdef REQUIRE_PROTOCOL
  protocol = REQUIRE_PROTOCOL
.endif

and 

.ifdef TLS_ON_CONNECT_PORTS
  tls_on_connect_ports = TLS_ON_CONNECT_PORTS
.endif

This allows the complete and correct definitions to be inserted without having 
to dig into
the .template file.


*** End of the template - remove these template lines ***


-- Package-specific info:
Exim version 4.92-RC3 #5 built 26-Dec-2018 15:07:52
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)

Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC 
Event OCSP PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

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

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

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  exim4-base 4.92~RC3-1
ii  exim4-daemon-light 4.92~RC3-1

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf information:
* exim4/drec:

Bug#918659: Debootstrap started to fail with Busybox

[Piotr Jurkiewicz]

Package: debootstrap
Version: 1.0.113

Debootstrap started to fail with busybox since version 1.0.113. 
Previously it worked flawlessly with busybox. It fails silently, but 
debootstrap.log contains the following error:


date: invalid date 'Tue, 15 Jan 2019 02:23:06 UTC'

The reason is commit: 75cd76ca821bfe92434b26503b1716ca6b99fd0c, which 
parses Valid-Until using `date -d` command. Busybox's date command does 
not parse RFC 2822 dates.


Please do not use `date -d` command for parsing Valid-Until field.

Or, at least, shortcut with NO_CHECK_VALID_UNTIL **before** `date -d` 
command is called (so one will use --no-check-valid-until on Busybox to 
prevent debootstrap from silent fail).

Bug#906017: java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM

[tony mancill]

Source: jameica
Followup-For: Bug #906017

Hi,

This bug was due to an issue with how SWT GTK was built on Debian and
should be addressed with the upload of swt4-gtk 4.10.0-3 [1].  

jameica is working for me locally.  Therefore, I will reassign the bug
and mark it fixed as of that version.

Thank you,
tony

[1] 
https://tracker.debian.org/news/1018341/accepted-swt4-gtk-4100-3-source-into-unstable/

Bug#706643: Block ios PlayStation Xbox one and family members third parties and business uninstall all on other devices retrieve my data and business uninstall all on other devices retrieve my data an

[Jamie Spruce]

Block

Bug#914814: spades: FTBFS with jemalloc/experimental

[Faidon Liambotis]

Hi Anton,

I'm Debian's jemalloc maintainer; I know next to nothing about SPAdes.

SPAdes seems to ship a modified jemalloc 3.2.0, from 2015. I ran a diff
between stock 3.2.0 and with a cursory look your actual code changes
seem to be minimal -- basically the addition of the cactive_max stat
(which is now moot), plus OS X default zones fixes (that are included
upstream). Do your performance optimizations have to do with the
configuration of jemalloc rather than the code itself? (You seem to
using CMake for building jemalloc, so diff'ing that wasn't as trivial)

Regardless, upstream has released dozens of versions since (including
two major versions), and in their extensive changelogs they claim
substantial performance improvements. I'd encourage you to try 5.1.0 and
see whether it benefits your workload or alleviates some of your earlier
performance concerns.

If not, I'd recommend to raise those issues with upstream -- I've worked
with them on a number of issues in the past and they've been very
responsive and collaborative, and I'm sure they'd love to hear about
workloads for which jemalloc doesn't perform well and help towards
optimizing those.

Regards,
Faidon

On Sat, Jan 05, 2019 at 11:54:53PM +0100, Andreas Tille wrote:
> Hi Anton,
> 
> thanks for your quick response.  I admit if we have some evidence that
> the modified source provides some relevant performance gain I think we
> need to reconsider using the Debian packaged version.
> 
> Could you please point us to some relevant discussion with jemalloc
> upstream?  We would include this into the package documentation to
> provide reasons why we derive in this case from Debian policy.  On
> the other hand if you could provide your changes as patches to the
> recent jemalloc version we might be able to convince the jemalloc
> Debian maintainer to accept these patches.
> 
> Kind regards
> 
>Andreas.
> 
> On Sat, Jan 05, 2019 at 05:08:03PM +0300, Anton Korobeynikov wrote:
> > Hi Andreas,
> > 
> > Thanks for the report.
> > 
> > SPAdes ships its own version of jemalloc for a reason, because we
> > modified it and configured exactly for SPAdes needs. And these changes
> > do make a huge difference in terms of performance & users' experience
> > of doing genome assemblies with SPAdes.
> > 
> > Given that SPAdes package that Debian ships is already broken &
> > limited due to Debian local patches and the vendor is not willing to
> > hear about our reasons & design choices we actually do not care about
> > these patches anymore.
> > 
> > Users could always either build SPAdes from sources, use pre-built
> > binaries or use other package managers like linuxbrew or conda.
> > 
> > Thanks for your understansing.
> > 
> > On Sat, Jan 5, 2019 at 2:35 PM Andreas Tille  wrote:
> > >
> > > Hi,
> > >
> > > the Debian package is using the Debian packaged jemalloc as per Debian
> > > policy which says you should not use code copies of packaged software.
> > > Since there was a conflict with the new jemalloc ABI there was a bug
> > > report
> > >
> > > http://bugs.debian.org/914814
> > >
> > > about a break with jemalloc 5.1 which will be soon the default in
> > > Debian.
> > >
> > > The attached mail is giving some hints for the spades developers which
> > > I'm hereby forwarding.
> > >
> > > Kind regards
> > >
> > >   Andreas.
> > >
> > > - Forwarded message from Faidon Liambotis  -
> > >
> > > Date: Sat, 5 Jan 2019 11:05:38 +0200
> > > From: Faidon Liambotis 
> > > To: Andreas Tille , 914...@bugs.debian.org
> > > Cc: Adam Borowski 
> > > Subject: Re: Bug#914814: spades: FTBFS with jemalloc/experimental
> > >
> > > tags 914814 - help + patch
> > > thanks
> > >
> > > Hi there,
> > >
> > > jemalloc (wannabe) maintainer here :) Thanks Adam for filing this!
> > >
> > > On Sat, Dec 01, 2018 at 07:34:45AM +0100, Andreas Tille wrote:
> > > > Spades is originally carrying a code copy.  I'm afraid upstream will
> > > > give the advise to use the code they are shipping which we want to
> > > > avoid.  Could you possibly provide some patch which I could use and
> > > > provide to upstream once tested?  Unfortunately I have no idea about
> > > > jemalloc.
> > >
> > > It looks like spades is using rallocm(), which was an experimental API
> > > that was deprecated in 3.5.0 in favor of the *allocx variants, and
> > > eventually removed in 4.0. (Debian currently carries 3.6.0, and the
> > > intention is to move to 5.1.0.)
> > >
> > > The whole block is a bit odd, as it's trying to grow the allocation
> > > in-place and then fall back to malloc/memcpy/free... which is really
> > > something that the allocator (any allocator!) can just do automatically
> > > with (je_)realloc(). Unfortunately the class' method is already poorly
> > > named as "realloc" and conflicts with a realloc() invocation. While
> > > upstream renaming that method to avoid the conflict would be a trivial
> > > fix, it would be a more invasive patch that I'd be comfortable with to
> > > ca

Bug#914814: spades: FTBFS with jemalloc/experimental

[Faidon Liambotis]

severity 914814 serious
retitle 914814 spades: FTBFS with jemalloc 5
thanks

Hi,

With the release team's permission, jemalloc 5.1.0-2 was uploaded to
unstable today, and it also involves a transition from libjemalloc1 to
libjemalloc2.

This package will now become uninstallable in unstable and binNMUs will
fail due to this FTBFS, so raising the severity to serious.

Regards,
Faidon

Bug#918658: [networkd] crash on resume in 240

[Christopher Martin]

Package: systemd
Version: 240-2
Severity: normal
Tags: patch

After upgrading to systemd 240, networkd started crashing when
resuming from a suspended state. About 30 seconds (give or take) after
resume, systemd restarted networkd and thus brought the network back
up, but the damage had been done.

This is the error from the journal:

systemd-networkd[458]: Assertion 'IN_SET(link->state,
LINK_STATE_CONFIGURING, LINK_STATE_FAILED, LINK_STATE_LINGER)' failed
at ../src/network/networkd-link.c:934, function address_handler().
Aborting.

The same error was reported and fixed upstream as
https://github.com/systemd/systemd/issues/11272, although the reported
circumstances were different. Regardless, fixes have been committed
upstream, and grabbing the latest version of the relevant file
(systemd/src/network/networkd-link.c) and rebuilding systemd fixes the
issue on my machine as well.

I bring this to your attention only because the freeze is near and 241
may be a ways off...

Thanks,
Christopher Martin

Bug#917859: vim FTBFS building for armel,armhf on arm64

[James McCoy]

On Mon, Jan 07, 2019 at 09:08:37PM -0500, James McCoy wrote:
> On Mon, Jan 07, 2019 at 10:04:30AM +, Edmund Grimley Evans wrote:
> > I'd guess this is a problem with the locale. In my case an unknown
> > locale adds 8, rather than 10, additional lines, but still:
> > 
> > $ LANG=C ./foo.pl
> > Global symbol "$foo" requires explicit package name at ./foo.pl line 3.
> > Execution of ./foo.pl aborted due to compilation errors.
> > $ LANG=sq ./foo.pl
> > perl: warning: Setting locale failed.
> 
> Ah, right.  I forgot about this.  For now, I can ensure the tests run in
> the C.UTF-8 locale (since that's always available in our builds).

Actually, that's already happening, so this particular failure shouldn't
have happened.  I guess the build environment wasn't quite as expected
for a buildd.

> I'll
> also send a patch upstream to simply check if the expected string is
> found, not on a specific line.

Regardless, this will fix this overall issue.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#892295: jemalloc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Faidon Liambotis]

On Tue, Jan 08, 2019 at 12:35:28AM +0100, Manuel A. Fernandez Montecelo wrote:
> I am not sure what are your modifications, but I tried with the
> patch/debdiff attached, compared to 5.1.0-1 (-2 is/was not yet in
> snapshot or deb.debian.org) and everything went fine:
> 
>  Test suite summary: pass: 43/52, skip: 9/52, fail: 0/52

Hm, interesting! Thanks for testing this -- I'm not sure what went wrong
in my setup. Probably something related to qemu-user-static...

So, I pushed this patch to the master branch in the salsa repo, and also
pushed this upstream: https://github.com/jemalloc/jemalloc/pull/1402

5.1.0-2 was uploaded to unstable shortly before my previous email, so it
should start appearing on mirrors etc. soon. This upload involves a
transition, so I'll hold any changes until this plays out.

I'll take of this once that's done, but I'm curious to hear what
upstream will say in the meantime :)

Thanks!
Faidon

Bug#917859: vim FTBFS building for armel,armhf on arm64

[James McCoy]

On Mon, Jan 07, 2019 at 10:04:30AM +, Edmund Grimley Evans wrote:
> I'd guess this is a problem with the locale. In my case an unknown
> locale adds 8, rather than 10, additional lines, but still:
> 
> $ LANG=C ./foo.pl
> Global symbol "$foo" requires explicit package name at ./foo.pl line 3.
> Execution of ./foo.pl aborted due to compilation errors.
> $ LANG=sq ./foo.pl
> perl: warning: Setting locale failed.

Ah, right.  I forgot about this.  For now, I can ensure the tests run in
the C.UTF-8 locale (since that's always available in our builds).  I'll
also send a patch upstream to simply check if the expected string is
found, not on a specific line.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#888447: radsecproxy fails with pthread_attr_setstacksize failed

[Faidon Liambotis]

Hi Nathan,

On Thu, Jan 25, 2018 at 11:44:02AM -0700, Nathan Rini wrote:
>* What led up to the situation?
> installing radsecproxy on ppc64le
> 
> 
> 
> Jan 25 11:38:36 stargate4 systemd[1]: Starting radsecproxy...
> Jan 25 11:38:36 stargate4 radsecproxy[2193]: pthread_attr_setstacksize failed
> Jan 25 11:38:36 stargate4 systemd[1]: radsecproxy.service: Control process 
> exited, code=exited status=1
> Jan 25 11:38:36 stargate4 systemd[1]: Failed to start radsecproxy.
> Jan 25 11:38:36 stargate4 systemd[1]: radsecproxy.service: Unit entered 
> failed state.
> Jan 25 11:38:36 stargate4 systemd[1]: radsecproxy.service: Failed with result 
> 'exit-code'.

Apologies for the very late response. I just uploaded radsecproxy
1.7.2-1 and during the course of those changes, I was also investigating
this bug.

Unfortunately, I'm unable to reproduce this, even on a ppc64el system
(plummer.debian.org specifically). I looked closely at the code as well,
and I don't see anything wrong with this particular piece of code (other
than, potentially, not ignoring this error).

Perhaps you have custom limits set for RLIMIT_STACK? Is there anything
of note in your /etc/security/limits.conf? What are the values of
"ulimit -s -S" and "ulimit -s -H" on your system? What is the output of
"grep -r 'define PTHREAD_STACK_MIN' /usr/include/" on this system?

Kree,
Faidon

Bug#918655: msmtp: Apparmor causing Permission denied when creating tmp files and logging

[Simon Deziel]

Hello,

On 2019-01-07 6:56 p.m., Ondra Kudlík wrote:
> Package: msmtp
> Version: 1.8.1-1
> Severity: important
> 
> Hello,
> 
> after yesterdays update I'm unable to use msmtp because of new apparmor
> profile.
> 
> Error:
> 
> msmtp: cannot create temporary file: Permission denied
> 
> It looks like apparmor profile is expecting msmtp to create temporary files
> with name
> staring with "msmtp" which is not true (at least I can't see it in msmtp 
> source
> code).
> 
> Changing line to:
> 
>   owner /tmp/*   rw,
> 
> fixes problem for me.

In my tests with 1.6.6-1, it always created files like /tmp/msmtpMjeJLc
which is why I hardcoded that msmtp prefix. I'm afraid that I had
forgotten about #883354 so the actual profile evolved in parallel. I was
kind of caught by surprise by it's inclusion, my bad and sorry Emmanuel.

> Second issue is that I have log files in ~/.msmtp*.log which is maybe specific
> to my
> setup but it is widely used at least from various wikis and docs I saw.
> 
> I suggest to add line to fix this issue as well.
> 
>   owner @{HOME}/.msmtp*.log   rwk,

Sounds good to me.

> Btw. I think this is major change and should be announced through news
> mechanism,
> especially because many users have their own paths. I could save at least an
> hour
> when trying to find source of problem.

I agree, I should have thought of that. How about adding the text from
README.Debian as a NEWS entry?

I will do some testing with 1.8.1-1 but in the meantime, please find
attached a more up to date profile that received more testing and also
incorporates your feedback (thanks!).

Regards,
Simon
# Author: Simon Deziel 

#include 

/usr/bin/msmtp flags=(attach_disconnected) {
  #include 
  #include 
  #include 
  #include 
  #include 

  /usr/bin/msmtp  mr,
  /etc/aliasesr,
  /etc/msmtprcr,
  /etc/netrc  r,
  owner @{HOME}/.msmtp*   r,
  owner @{HOME}/.netrcr,
  owner @{HOME}/.tls-crls r,

  owner @{HOME}/.msmtp*.log wk,
  /var/log/msmtpwk,

  @{PROC}/@{pid}/loginuid r,
  /tmp/   rw,
  owner /tmp/*rw,

  # to type password interactively
  owner /dev/pts/[0-9]*   rw,

  # secret helpers
  /usr/bin/secret-toolPUx,
  /usr/bin/gpg{,2}PUx,

  #include 
}

Bug#918657: network-manager: Problem with Wi-Fi accepting CLIENT MODE

[carl]

Package: network-manager
Version: 1.14.4-4
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Enabling wifi using the applet.
Selecting add new network.. enter wifi password... refuses to connect.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
If I go under edit network I am able to select "HOTSPOT" then.. it will
recognize the network.. however it it NOT a hotspot it's a
client/infrastructure network.
It won't connect without using HOTSPOT

   * What was the outcome of this action?
I was able to connect.(hotspot mode only)

   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.12-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-2
ii  libbluetooth3  5.50-1
ii  libc6  2.28-2
ii  libcurl3-gnutls7.62.0-1
ii  libglib2.0-0   2.58.1-2
ii  libgnutls303.6.5-2
ii  libjansson42.12-1
ii  libmm-glib01.8.2-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.4-4
ii  libpam-systemd 240-2
ii  libpolkit-agent-1-00.105-23
ii  libpolkit-gobject-1-0  0.105-23
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0240-2
ii  libteamdctl0   1.27-1
ii  libudev1   240-2
ii  libuuid1   2.33-0.2
ii  lsb-base   10.2018112800
ii  policykit-10.105-23
ii  udev   240-2
ii  wpasupplicant  2:2.6-21

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-3
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.8.2-1
ii  ppp  2.4.7-2+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#916100: Updated title and tag

[Alban Vidal]

Control: retitle -1 deborphan: [INTL:it] Italian po program translation update
Control: tag -1 l10n

-- 
Alban Vidal




signature.asc
Description: OpenPGP digital signature

Bug#918233: Updated title, severity and tags

[Alban Vidal]

Control: retitle -1 deborphan: [INTL:pt] Updated Portuguese package translation
Control: severity -1 wishlist
Control: tag -1 l10n
Control: tag -1 patch




signature.asc
Description: OpenPGP digital signature

Bug#918656: cruft: Update filters for emacs

[Jörg Sommer]

Package: cruft-common
Version: 0.9.36
Severity: normal

Hi,

I'm getting many hits like

/usr/share/emacs/site-lisp/elpa/magit-2.90.1
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/Install.log.gz
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/git-rebase.el
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/git-rebase.elc
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-apply.el
/usr/share/emacs/site-lisp/elpa/magit-2.90.1/magit-apply.elc
…

/usr/share/emacs/site-lisp/elpa/yasnippet-snippets-0.7/yasnippet-snippets.el

/usr/share/emacs/site-lisp/elpa/yasnippet-snippets-0.7/yasnippet-snippets.elc

A new filter for Emacs might be necessary:

/usr/share/emacs/site-lisp/**/Install.log.gz
/usr/share/emacs/site-lisp/**/*.el
/usr/share/emacs/site-lisp/**/*.elc

Regards Jörg

-- 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)
Foreign Architectures: i386

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

-- no debconf information

-- 
Erfahrung heißt gar nichts. Man kann seine Sache auch 35 Jahre schlecht
machen.
(Kurt Tucholsky)


signature.asc
Description: PGP signature

Bug#918655: msmtp: Apparmor causing Permission denied when creating tmp files and logging

[Ondra Kudlík]

Package: msmtp
Version: 1.8.1-1
Severity: important

Hello,

after yesterdays update I'm unable to use msmtp because of new apparmor
profile.

Error:

msmtp: cannot create temporary file: Permission denied

It looks like apparmor profile is expecting msmtp to create temporary files
with name
staring with "msmtp" which is not true (at least I can't see it in msmtp source
code).

Changing line to:

  owner /tmp/*   rw,

fixes problem for me.

Second issue is that I have log files in ~/.msmtp*.log which is maybe specific
to my
setup but it is widely used at least from various wikis and docs I saw.

I suggest to add line to fix this issue as well.

  owner @{HOME}/.msmtp*.log   rwk,

Btw. I think this is major change and should be announced through news
mechanism,
especially because many users have their own paths. I could save at least an
hour
when trying to find source of problem.

Cheers

Kepi



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

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

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-4
ii  libgnutls303.6.5-2
ii  libgsasl7  1.8.0-8+b2
ii  ucf3.0038+nmu1

Versions of packages msmtp recommends:
ii  ca-certificates  20180409

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- Configuration Files:
/etc/apparmor.d/usr.bin.msmtp changed:
/usr/bin/msmtp {
  #include 
  #include 
  #include 
  #include 
  #include 
  /usr/bin/msmtp  r,
  /etc/aliasesr,
  /etc/msmtprcr,
  /etc/netrc  r,
  owner @{HOME}/.msmtp*   r,
  owner @{HOME}/.msmtp*.log   rwk,
  owner @{HOME}/.netrcr,
  owner @{HOME}/.tls-crls r,
  /tmp/   rw,
  owner /tmp/*rw,
  # to type password interactively
  owner /dev/pts/[0-9]*   rw,
  # secret helpers
  /usr/bin/secret-toolPUx,
  /usr/bin/gpg{,2}PUx,
  #include 
}


-- debconf information excluded

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Laurence Abbott]

I can confirm that adding "-v" to the two udevadm trigger commands,i.e.,

udevadm trigger --type=subsystems --action=add -v
udevadm trigger --type=devices --action=add -v

does indeed load the missing modules (on the second command) for me,
too, and boot proceeds normally once I exit the initramfs shell.

(I also tried with "-n" instead of "-v" but got no output.)

Laz

Bug#918654: libnvidia-egl-wayland1: file installation conflict with nvidia-egl-wayland-common

[Luca Boccassi]

Package: libnvidia-egl-wayland1
Version: 1:1.1.1-1
Severity: serious
Tags: patch

Dear Maintainer,

nvidia-egl-wayland-common in stable and libnvidia-egl-wayland1 in
unstable both install:

/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json

https://packages.debian.org/stretch/amd64/nvidia-egl-wayland-common/filelist
https://packages.debian.org/sid/amd64/libnvidia-egl-wayland1/filelist

But the latter does not declare a Conflicts+Replaces on the latter, so
upgrading fails:

$ sudo apt install libnvidia-egl-wayland1=1:1.1.1-1+b1
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following NEW packages will be installed:
  libnvidia-egl-wayland1
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 0 B/18.0 kB of archives.
After this operation, 66.6 kB of additional disk space will be used.
Selecting previously unselected package libnvidia-egl-wayland1:amd64.
(Reading database ... 438463 files and directories currently installed.)
Preparing to unpack .../libnvidia-egl-wayland1_1%3a1.1.1-1+b1_amd64.deb ...
Unpacking libnvidia-egl-wayland1:amd64 (1:1.1.1-1+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libnvidia-egl-wayland1_1%3a1.1.1-1+b1_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json', which is also 
in package nvidia-egl-wayland-common 384.130-1
Errors were encountered while processing:
 /var/cache/apt/archives/libnvidia-egl-wayland1_1%3a1.1.1-1+b1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Setting the severity to delay the migration to buster. The trivial fix
is provided on Salsa:

https://salsa.debian.org/debian/egl-wayland/merge_requests/1

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

Bug#913274: Changing the _is_real_file() function

[Stuart Prescott]

Hi Colin,

Many thanks for the additional information about how python-apt has changed 
and for looking over this change. It is much appreciated.

> I might be inclined to suggest renaming _is_real_file, since its name is
> a little misleading now.  Maybe _has_fileno?

Yes, that sounds like a very good idea.

regards
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#892295: jemalloc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Manuel A. Fernandez Montecelo]

Hi!

2019-01-07 23:15 Faidon Liambotis:

reopen 892295
tags 892295 + help - fixed-upstream patch
thanks

[...]

I uploaded 5.1.0-2 to unstable moments ago, which includes the
aforementioned commit.

Unfortunately, it seems like the build fails due to atomics-related
complications, which judging from similar bug reports, could be fixed by
passing -pthread instead of -lpthread. I filed this upstream[1] and that
seemed like a good idea to them.

1: https://github.com/jemalloc/jemalloc/issues/1401

I then experimented with building with that option on a riscv64
qemu-user-static container locally, but I came across random issues when
running the test suite, like some allocation issues, or processes
hanging etc. The build with the same option on amd64 seems to have
worked fine. I wonder if this has something to do with jemalloc or my
(weirdly emulated) environment, bug regardless... I would love your
help, if you have a spare moment :)


First of all, thanks for taking care.

I am not sure what are your modifications, but I tried with the
patch/debdiff attached, compared to 5.1.0-1 (-2 is/was not yet in
snapshot or deb.debian.org) and everything went fine:

 Test suite summary: pass: 43/52, skip: 9/52, fail: 0/52

More info about the build, which I'll proceed to upload to unreleased:

 Build Architecture: riscv64
 Build Type: full
 Build-Space: 763036
 Build-Time: 2051
 Distribution: unreleased
 Host Architecture: riscv64
 Install-Time: 40
 Job: .../jemalloc/jemalloc_5.1.0-1+0.riscv64.1.dsc
 Machine Architecture: riscv64
 Package: jemalloc
 Package-Time: 2122
 Source-Version: 5.1.0-1+0.riscv64.1
 Space: 763036
 Status: successful
 Version: 5.1.0-1+0.riscv64.1

This is on real hardware, I trust that it will also work fine in the
buildds (qemu-system), but if not we can take another look.

Not sure if the patch is correct or it's better to fix it in another
way, I hope that you or upstream can figure that out, or if not we can
iterate over it and try different things.

Hope that helps.  Thanks again!

--
Manuel A. Fernandez Montecelo 
Index: jemalloc-5.1.0/Makefile.in
===
--- jemalloc-5.1.0.orig/Makefile.in
+++ jemalloc-5.1.0/Makefile.in
@@ -400,7 +400,7 @@ $(objroot)test/unit/%$(EXE): $(objroot)t
 
 $(objroot)test/integration/%$(EXE): $(objroot)test/integration/%.$(O) $(C_TESTLIB_INTEGRATION_OBJS) $(C_UTIL_INTEGRATION_OBJS) $(objroot)lib/$(LIBJEMALLOC).$(IMPORTLIB)
 	@mkdir -p $(@D)
-	$(CC) $(TEST_LD_MODE) $(LDTARGET) $(filter %.$(O),$^) $(call RPATH,$(objroot)lib) $(LJEMALLOC) $(LDFLAGS) $(filter-out -lm,$(filter -lrt -lpthread -lstdc++,$(LIBS))) $(LM) $(EXTRA_LDFLAGS)
+	$(CC) $(TEST_LD_MODE) $(LDTARGET) $(filter %.$(O),$^) $(call RPATH,$(objroot)lib) $(LJEMALLOC) $(LDFLAGS) $(filter-out -lm,$(filter -lrt -pthread -lstdc++,$(LIBS))) $(LM) $(EXTRA_LDFLAGS)
 
 $(objroot)test/integration/cpp/%$(EXE): $(objroot)test/integration/cpp/%.$(O) $(C_TESTLIB_INTEGRATION_OBJS) $(C_UTIL_INTEGRATION_OBJS) $(objroot)lib/$(LIBJEMALLOC).$(IMPORTLIB)
 	@mkdir -p $(@D)
Index: jemalloc-5.1.0/configure.ac
===
--- jemalloc-5.1.0.orig/configure.ac
+++ jemalloc-5.1.0/configure.ac
@@ -1503,7 +1503,7 @@ if test "x$abi" != "xpecoff" ; then
   AC_CHECK_HEADERS([pthread.h], , [AC_MSG_ERROR([pthread.h is missing])])
   dnl Some systems may embed pthreads functionality in libc; check for libpthread
   dnl first, but try libc too before failing.
-  AC_CHECK_LIB([pthread], [pthread_create], [JE_APPEND_VS(LIBS, -lpthread)],
+  AC_CHECK_LIB([pthread], [pthread_create], [JE_APPEND_VS(LIBS, -pthread)],
[AC_SEARCH_LIBS([pthread_create], , ,
AC_MSG_ERROR([libpthread is missing]))])
   wrap_syms="${wrap_syms} pthread_create"
diff -Nru jemalloc-5.1.0/debian/changelog jemalloc-5.1.0/debian/changelog
--- jemalloc-5.1.0/debian/changelog 2018-05-26 23:36:03.0 +0200
+++ jemalloc-5.1.0/debian/changelog 2019-01-07 23:28:11.0 +0100
@@ -1,3 +1,10 @@
+jemalloc (5.1.0-1+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64: use -pthread
+
+ -- Manuel A. Fernandez Montecelo   Mon, 07 Jan 2019 22:28:11 
+
+
 jemalloc (5.1.0-1) experimental; urgency=medium
 
   * New upstream release.
diff -Nru jemalloc-5.1.0/debian/patches/riscv64-support.dch 
jemalloc-5.1.0/debian/patches/riscv64-support.dch
--- jemalloc-5.1.0/debian/patches/riscv64-support.dch   1970-01-01 
01:00:00.0 +0100
+++ jemalloc-5.1.0/debian/patches/riscv64-support.dch   2019-01-07 
23:28:11.0 +0100
@@ -0,0 +1,26 @@
+Index: jemalloc-5.1.0/Makefile.in
+===
+--- jemalloc-5.1.0.orig/Makefile.in
 jemalloc-5.1.0/Makefile.in
+@@ -400,7 +400,7 @@ $(objroot)test/unit/%$(EXE): $(objroot)t
+ 
+ $(objroot)test/integration/%$(EXE): $(objroot)test/integration/%.$(O) 
$(C_TESTLIB_INTEGRATION_OBJS) $(C_UTIL_I

Bug#918606: systemd: Missing portablectl and portabled in systemd 239+

[Michael Biebl]

Am 07.01.19 um 19:52 schrieb D.S. Ljungmark:
> Is there an easy way for us to rebuild the systemd package with the
> feature enabled?

Something like the attached patch should do the trick




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debian/rules b/debian/rules
index 0d2fcdf..0fb6a6b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -62,7 +62,6 @@ CONFFLAGS = \
 	-Dvconsole=false \
 	-Dfirstboot=false \
 	-Dxkbcommon=false \
-	-Dportabled=false \
 	-Dwheel-group=false \
 	-Dntp-servers="$(DEFAULT_NTP_SERVERS)" \
 	-Dlink-udev-shared=false \
@@ -88,6 +87,7 @@ CONFFLAGS_deb = \
 	-Dnss-resolve=true \
 	-Dnss-systemd=true \
 	-Dresolve=true \
+	-Dportabled=true \
 	-Dlink-systemctl-shared=false
 
 ifeq (, $(filter stage1, $(DEB_BUILD_PROFILES)))
@@ -151,6 +151,7 @@ CONFFLAGS_udeb = \
 	-Dnss-resolve=false \
 	-Dnss-systemd=false \
 	-Dresolve=false \
+	-Dportabled=false \
 	-Dpolkit=false \
 	-Dacl=false \
 	-Dgcrypt=false \
diff --git a/debian/systemd.install b/debian/systemd.install
index f0fa42c..91fd7d5 100644
--- a/debian/systemd.install
+++ b/debian/systemd.install
@@ -4,6 +4,7 @@ bin/journalctl
 bin/loginctl
 bin/machinectl
 bin/networkctl
+bin/portablectl
 bin/systemd-notify
 bin/systemd-tty-ask-password-agent
 bin/systemd-ask-password


signature.asc
Description: OpenPGP digital signature

Bug#918653: egl-wayland: misplaced Conflicts+Replaces

[Andreas Beckmann]

Source: egl-wayland
Version: 1:1.1.1-1
Severity: serious

Hi,

the Conflicts+Replaces need to be added to the library package, not to
the -dev package. The library package contains the files that were
placed in other packages, too.
I'm not sure about the Ubuntu packages, in case they shipped a .so link,
they should have a C+R in the -dev package too.
The Debian packages should never have shipped a .so symlink.


Andreas

Bug#918652: leaflet: fails to clean after build: rm: cannot remove './debian/js': Is a directory

[Andreas Beckmann]

Source: leaflet
Version: 1.0.3~dfsg-2
Severity: serious

Hi,

leaflet fails to build twice in a row because cleaning afte rthe first
build errors out:

 debian/rules clean
dh clean
   dh_clean
rm: cannot remove './debian/js': Is a directory
dh_clean: rm -f -- debian/libjs-leaflet.substvars ./debian/js debian/files 
returned exit code 1
make: *** [debian/rules:4: clean] Error 1


You probably need to add a trailing slash to directory trees to be removed
via debian/clean.


Andreas


leaflet_1.0.3~dfsg-2_twice.log.gz
Description: application/gzip

Bug#917681: ibus-table-others: FTBFS: FileExistsError: [Errno 17] File exists: '/<>/debian/fakehome/.local/share/ibus-table'

[Adrian Bunk]

On Mon, Jan 07, 2019 at 04:56:21PM -0500, Boyuan Yang wrote:
>...
> I could not reproduce this problem locally either using debuild or using
> sbuild. Could you please provide with more information on it?

The problem seem to be several ibus-table-createdb processes in parallel
trying to create a directory in the fakehome.

I can reproduce the problem with:
cd tables
rm -rf *.db ../debian/fakehome/.local
HOME=../debian/fakehome make -j20

> Besides, I just prepared 1.3.9-4 upload which disables parallel build. Please
> let me know if that fixes the problem.

I would expect that it does.

> Thanks,
> Boyuan Yang
> 
> On Sat, 29 Dec 2018 22:43:21 +0100 Lucas Nussbaum  wrote:
> > Source: ibus-table-others
> > Version: 1.3.9-3
> > Severity: serious
> > Justification: FTBFS on amd64
> > Tags: buster sid
> > Usertags: ftbfs-20181229 ftbfs-buster
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> > 
> > Relevant part (hopefully):
> > > make[2]: Entering directory '/<>/tables'
> > > /usr/bin/ibus-table-createdb  -n compose.db -s compose.txt
> > > /usr/bin/ibus-table-createdb  -n ipa-x-sampa.db -s ipa-x-sampa.txt
> > > Traceback (most recent call last):
> > >   File "/usr/share/ibus-table/engine/tabcreatedb.py", line 455, in
> 
> > > main()
> > >   File "/usr/share/ibus-table/engine/tabcreatedb.py", line 175, in main
> > > create_database=True)
> > >   File "/usr/share/ibus-table/engine/tabsqlitedb.py", line 262, in
> __init__
> > > import ibus_table_location
> > >   File "/usr/share/ibus-table/engine/ibus_table_location.py", line 102, in
> 
> > > __module_init = __ModuleInitializer()
> > >   File "/usr/share/ibus-table/engine/ibus_table_location.py", line 96, in
> __init__
> > > _init()
> > >   File "/usr/share/ibus-table/engine/ibus_table_location.py", line 76, in
> _init
> > > os.makedirs(IBUS_TABLE_LOCATION['data_home'])
> > >   File "/usr/lib/python3.7/os.py", line 221, in makedirs
> > > mkdir(name, mode)
> > > FileExistsError: [Errno 17] File exists:
> '/<>/debian/fakehome/.local/share/ibus-table'
> > > make[2]: *** [Makefile:519: ipa-x-sampa.db] Error 1
> > 
> > The full build log is available from:
> >
> http://aws-logs.debian.net/2018/12/29/ibus-table-others_1.3.9-3_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.
> > 
> > 



cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#918648: watcher: FTBFS (autobuilder hangs)

[Santiago Vila]

severity 918648 serious
retitle 918648 watcher: FTBFS (autobuilder hangs)
thanks

Hi.

Unfortunately, my autobuilders still hang when I disable eatmydata,
and they do it all the time (100% reproducible). Retitling accordingly.

Note that this hangs for me and it "just" FTBFS in reproducible-builds:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/watcher.html

I have no idea why this different behaviour, maybe because they use
pbuilder and I use sbuild, but I don't really know.

As usual, if you need a test machine to reproduce it, just say so.

Thanks.

Bug#903491: marble: OSM Address Lookup Broken

[Christopher Howard]

I wanted to report that the patch submitted by Adrien worked for me
after I rebuilt the debs.

If anybody doesn't want to wait for the official bug fix release, and
wants to contact me directly, I can provide the rebuilt debs.

Bug#918341: transition: jemalloc

[Faidon Liambotis]

Hi,

On Mon, Jan 07, 2019 at 06:10:02PM +0100, Emilio Pozuelo Monfort wrote:
> > So, I'd like to ask for permission to upload jemalloc 5.1.0-2 to sid:
> 
> 
> Please go ahead.

Thank you Emilio & team, appreciate it! I've went ahead and uploaded
5.1.0-2, seems it was successfully built on most architectures already.

Let me know if there's anything else needed from my side.

Regards,
Faidon

Bug#918499: libreoffice: fails with 'ERROR 4 forking process'

[Rene Engelhard]

severity 918499 serious
tag 918499 - unreproducible
tag 918499 - moreinfo
tag 918499 + confirmed
tag 918499 + pending
thanks

Hi,

On Mon, Jan 07, 2019 at 09:20:12PM +0700, Tunggul Arif Siswoyo wrote:
> On Mon, 7 Jan 2019 20:46:28 +0700 Tunggul Arif Siswoyo  
> wrote:
> 
> [skip]
> 
> I think it is related with apparmor configs. I'm not sure what caused it

Ah, good point.

[...]
> 1 profiles are in complain mode.  
>   
> 
>libreoffice-oopslash   
>   
> 
Note that this in complain mode only. But where is soffice.bin? ...

> Jan 07 20:13:09 ikigai apparmor[430]: AppArmor parser error for 
> /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin in 
> /etc/apparmor.d/usr.lib.libreoffice.pr…ractions/mesa'
> Jan 07 20:13:09 ikigai apparmor[430]:  failed!
> Jan 07 20:13:09 ikigai systemd[1]: apparmor.service: Main process exited, 
> code=exited, status=123/n/a
> Jan 07 20:13:09 ikigai systemd[1]: apparmor.service: Failed with result 
> 'exit-code'.
> Jan 07 20:13:09 ikigai systemd[1]: Failed to start Load AppArmor profiles.
> Hint: Some lines were ellipsized, use -l to show in full.
> 
> Error message above caused by invalid config in apparmor profile for
> soffice.bin in line 90 :

.. ah. here... :(

> root@ikigai:~# aa-remove-unknown
> AppArmor parser error for 
> /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin in 
> /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin at line 90: Could not 
> open 'abstrac
> tions/mesa'

Aha. :-(

But this is present in testings apparmor

rene@frodo:~$ dpkg -S /etc/apparmor.d/abstractions/mesa 
dpapparmor: /etc/apparmor.d/abstractions/mesa
rene@frodo:~$ dpkg -l apparmor
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
 Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name   Version  Architektur  Beschreibung
+++-==---==
ii  apparmor   2.13.1-3+b1  amd64user-space parser utility for 
AppArmor

In your other mail you (well, reportbug...) writes:

| Versions of packages libreoffice-common recommends:   

  
| ii  apparmor2.13-8 

Why that old version of apparmor?

Testing has 2.13.1 since last year November,
actually even a newer one migrated today. See
https://packages.qa.debian.org/a/apparmor.html

But indeed the Recommends is not strict enough, according to
http://bugs.debian.org/918499 this must be >= 2.13.1 instead of just
>= 2.13. Will fix. (And add a conflicts against older apparmors.)

But you should properly upgrade your system nevertheless.

Regards,

Rene

Bug#918651: reproducible: re-deploy ff4a

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal

ff4a-armhf-rb.debian.net had a disk failure, and thus needed to be
re-installed.

It has now been reinstalled, awaiting configuration.

New ssh keys:

256 SHA256:IpOeA378iY1R3z+tBaKQDYB/9oVZgjeweHOIXlpIblk root@ff4a (ECDSA)
256 SHA256:TWTizdJIVZUpWSSQCzKOIsaOgUBHjSe1daLdQ4EORZc root@ff4a (ED25519)
2048 SHA256:9tQVACgwqgVrqvRdvsCFkqarB4kYNd0hjPFnLkrVzHg root@ff4a (RSA)

All other settings should basically be the same, and I don't think it's
been removed from jenkins git yet, but let me know if you have
difficulties re-enabling.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#918650: python3-pdfminer: missing Breaks+Replaces: python-pdfminer (<< 20181108)

[Andreas Beckmann]

Package: python3-pdfminer
Version: 20181108+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-pdfminer_20181108+dfsg-1_all.deb ...
  Unpacking python3-pdfminer (20181108+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-pdfminer_20181108+dfsg-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/dumppdf', which is also in package 
python-pdfminer 20140328+dfsg-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-pdfminer_20181108+dfsg-1_all.deb


cheers,

Andreas


python-pdfminer=20140328+dfsg-2_python3-pdfminer=20181108+dfsg-1.log.gz
Description: application/gzip

Bug#903428: deduplicating jquery/

[Emmanuel Bourg]

Le 07/01/2019 à 23:02, Samuel Thibault a écrit :

> I'd rather cripple the documentation a bit than removing it :)

The issue is, we keep getting more and more javadoc related issues with
each OpenJDK upgrade. This jquery "issue" is a bit the straw that breaks
the camel's back, and we would rather cut the loss now than investing
even more time on these low popcon packages. The Java Team is
understaffed, we struggle to keep up with the JDK upgrades and update
the important packages, so the documentation issues are really low
priority items.


> Could jh_build perhaps just drop the embedded jquery copy to just avoid
> the issue? AFAIK, jquery is only used to implement the "search" feature,
> which can sometimes be convenient, but can be done by users with greps &
> such.

jh_build is only part of the picture. Most javadoc packages are
generated by Maven, so the maven-javadoc-plugin would have to be patched
as well.

Emmanuel Bourg

Bug#918646:

[J. Smith]

Maybe this helps?

http://lists.gnu.org/r/emacs-diffs/2018-12/msg00377.html
    

Bug#918584: os-autoinst FTBFS on i386: FAIL: 01-test_needle.t

[Hideki Yamane]

control: forwarded -1 https://progress.opensuse.org/issues/45782

On Mon, 07 Jan 2019 17:48:40 +0200
Adrian Bunk  wrote:
> not ok 14 - found area is the original one too
> #   Failed test 'found area is the original one too'
> #   at ./01-test_needle.t line 73.
> #  got: '944'
> # expected: '108'

 Thanks, I got same result with upstream master, forwarded to
 them.


-- 
Hideki Yamane 

Bug#892295: jemalloc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Faidon Liambotis]

reopen 892295
tags 892295 + help - fixed-upstream patch
thanks

Hi Manuel,

On Wed, Mar 07, 2018 at 10:44:25PM +0100, Manuel A. Fernandez Montecelo wrote:
> We need support in this package for RISC-V, to bootstrap the riscv64
> architecture.
> 
> Patches have been submitted upstream months ago, targetting development
> versions:
> 
>   
> https://github.com/jemalloc/jemalloc/commit/749caf14ae73a9ab1c48e538a8af09addbb35ee7
> 
>   (the file was named differently before, I didn't bother to get the VCS 
> history
>   to chase all commits, but it's clear enough).
> 
> Since we're still including older versions in unstable (and even 
> experimental),
> and in Debian we can get by by defining LG_QUANTUM in d/rules, instead of
> patching the upstream source code I propose a patch for debian/rules instead,
> attached.
> 
> It would be great if you could include it as a patch and release a new version
> for unstable.

I uploaded 5.1.0-2 to unstable moments ago, which includes the
aforementioned commit.

Unfortunately, it seems like the build fails due to atomics-related
complications, which judging from similar bug reports, could be fixed by
passing -pthread instead of -lpthread. I filed this upstream[1] and that
seemed like a good idea to them.

1: https://github.com/jemalloc/jemalloc/issues/1401

I then experimented with building with that option on a riscv64
qemu-user-static container locally, but I came across random issues when
running the test suite, like some allocation issues, or processes
hanging etc. The build with the same option on amd64 seems to have
worked fine. I wonder if this has something to do with jemalloc or my
(weirdly emulated) environment, bug regardless... I would love your
help, if you have a spare moment :)

Regards,
Faidon

Bug#915112: closed by Alastair McKinstry (fixed in 2.1.0-3)

[Andreas Beckmann]

Control: reopen -1
Control: retitle -1 glew: incompatible with glext.h from current mesa

On 2019-01-07 22:45, Debian Bug Tracking System wrote:
> fixed 2.1.0-3

Nope.


Andreas

Bug#918649: coffeescript: Please upgrade to 2.x

[Xavier Guimard]

Package: coffeescript
Version: 1.12.8~dfsg-2
Severity: wishlist

Please upgrade to 2.x version and remove workaround-918491.patch

Opened to remember to remove this workaround.

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

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

Versions of packages coffeescript depends on:
ii  nodejs  10.15.0~dfsg-8

coffeescript recommends no packages.

Versions of packages coffeescript suggests:
pn  coffeescript-doc
ii  libjs-coffeescript  1.12.8~dfsg-2

-- no debconf information

Bug#918645: dfwinreg: FTBFS (failing tests)

[Santiago Vila]

Package: src:dfwinreg
Version: 20181214-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
dh build-indep --with=python2,python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython2_2.7_dfwinreg/build/dfwinreg

[... snipped ...]

warning: no files found matching '*.py' under directory 'examples'
writing manifest file 'dfwinreg.egg-info/SOURCES.txt'
copying dfwinreg/dtfabric.yaml -> 
/<>/.pybuild/cpython2_2.7_dfwinreg/build/dfwinreg
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/key_paths.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/interface.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/fake.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/py2to3.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/definitions.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/__init__.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/glob2regex.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/decorators.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/errors.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/virtual.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/regf.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/registry.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
copying dfwinreg/registry_searcher.py -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
running egg_info
writing dfwinreg.egg-info/PKG-INFO
writing dependency_links to dfwinreg.egg-info/dependency_links.txt
writing top-level names to dfwinreg.egg-info/top_level.txt
reading manifest file 'dfwinreg.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files found matching '.gitignore'
warning: no previously-included files found matching '*.pyc'
warning: no previously-included files matching '*.pyc' found under directory 
'dfwinreg'
warning: no files found matching '*.py' under directory 'examples'
writing manifest file 'dfwinreg.egg-info/SOURCES.txt'
copying dfwinreg/dtfabric.yaml -> 
/<>/.pybuild/cpython3_3.7_dfwinreg/build/dfwinreg
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
python run_tests.py
Using Python version 2.7.15+ (default, Nov 28 2018, 16:27:22) 
[GCC 8.2.0]
Checking availability and versions of dependencies.
[OK]dfdatetime version: 20181025
[OK]dtfabric version: 20180808
[OK]pyregf version: 20170130
[FAILURE]   missing: yaml

make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:10: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dfwinreg.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#918647: morfologik-stemming: FTBFS (cannot find symbol IntIntOpenHashMap)

[Santiago Vila]

Package: src:morfologik-stemming
Version: 1.9.0+dfsg-0.1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
test -x debian/rules
mkdir -p "."
/usr/share/maven-debian-helper/copy-repo.sh 
/<>/morfologik-stemming-1.9.0+dfsg/debian
mh_patchpoms -plibmorfologik-stemming-java --debian-build --keep-pom-version 
--maven-repo=/<>/morfologik-stemming-1.9.0+dfsg/debian/maven-repo  
--build-no-docs
touch debian/stamp-poms-patched
# before-build target may be used to unpatch the pom files, so we need to check 
if
# patching the pom files is needed here, normally not
if [ ! -f pom.xml.save ]; then \
/usr/bin/make -f debian/rules patch-poms; \
fi
cd . && /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar: 
-Dproperties.file.manual=/<>/morfologik-stemming-1.9.0+dfsg/debian/maven.properties
 -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<>/morfologik-stemming-1.9.0+dfsg
 org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml 
-Dmaven.repo.local=/<>/morfologik-stemming-1.9.0+dfsg/debian/maven-repo
  package -DskipTests
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
com.google.inject.internal.cglib.core.$ReflectUtils$1 
(file:/usr/share/maven/lib/guice.jar) to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)

[... snipped ...]

[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.FSA5Serializer
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/FSA5Serializer.java:[72,13]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.FSA5Serializer
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/FSAInfo.java:[55,60]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.FSAInfo.FinalStateVisitor
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/FSAUtils.java:[184,15]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.FSAUtils
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/FSAUtils.java:[184,47]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.FSAUtils
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/CFSA2Serializer.java:[63,45]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.CFSA2Serializer
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/CFSA2Serializer.java:[68,45]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.CFSA2Serializer
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/CFSA2Serializer.java:[219,15]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.CFSA2Serializer
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/CFSA2Serializer.java:[386,9]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.CFSA2Serializer
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/CFSA2Serializer.java:[386,45]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.CFSA2Serializer
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/FSA5Serializer.java:[67,45]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.FSA5Serializer
[ERROR] 
/<>/morfologik-stemming-1.9.0+dfsg/morfologik-fsa/src/main/java/morfologik/fsa/FSA5Serializer.java:[72,45]
 cannot find symbol
[ERROR]   symbol:   class IntIntOpenHashMap
[ERROR]   location: class morfologik.fsa.FSA5Serializer
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with 
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug 
logging.
[ERROR] 
[ERROR] For more informatio

Bug#918648: watcher: FTBFS (autobuilder hangs when built with eatmydata)

[Santiago Vila]

Package: src:watcher
Version: 1.12.0-1
Tags: ftbfs

Hello Thomas.

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python3,systemd,sphinxdoc
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_autoreconf -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions

[... snipped ...]

2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default 
cursor.execute(statement, parameters)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default 
sqlite3.OperationalError: no such table: services
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default 
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default The above 
exception was the direct cause of the following exception:
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default 
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default Traceback 
(most recent call last):
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/usr/lib/python3/dist-packages/apscheduler/executors/base.py", line 125, in 
run_job
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default retval = 
job.func(*job.args, **job.kwargs)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/<>/watcher/api/scheduling.py", line 43, in get_services_status
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default services 
= objects.service.Service.list(context)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/usr/lib/python3/dist-packages/oslo_versionedobjects/base.py", line 184, in 
wrapper
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default result = 
fn(cls, context, *args, **kwargs)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/<>/watcher/objects/service.py", line 103, in list
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default 
sort_dir=sort_dir)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/<>/watcher/db/sqlalchemy/api.py", line 1061, in get_service_list
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default *args, 
**kwargs)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/<>/watcher/db/sqlalchemy/api.py", line 327, in _get_model_list
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default sort_key, 
sort_dir, query)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/<>/watcher/db/sqlalchemy/api.py", line 103, in _paginate_query
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default return 
query.all()
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 2843, in all
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default return 
list(self)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 2995, in __iter__
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default return 
self._execute_and_instances(context)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3018, in 
_execute_and_instances
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default result = 
conn.execute(querycontext.statement, self._params)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 948, in execute
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default return 
meth(self, multiparams, params)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 269, in 
_execute_on_connection
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default return 
connection._execute_clauseelement(self, multiparams, params)
2019-01-07 18:17:22.046 14358 ERROR apscheduler.executors.default   File 
"/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1060, in 
_

Bug#918646: emacs: FTBFS (failing tests)

[Santiago Vila]

Package: src:emacs
Version: 1:26.1+1-3
Severity: serious
Tags: ftbfs

Hello Rob.

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel
   debian/rules override_dh_testdir
make[1]: Entering directory '/<>/emacs-26.1+1'
dh_testdir debian/emacsVAR.postinst
make[1]: Leaving directory '/<>/emacs-26.1+1'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/emacs-26.1+1'
rm -rf debian/build-src debian/build-gtk debian/build-lucid debian/build-nox
mkdir debian/build-src
cp -a $(ls -A | egrep -v '^(\.git|\.pc|debian)$') debian/build-src
cp -a /usr/share/misc/config.guess /usr/share/misc/config.sub \
  debian/build-src
cd debian/build-src && ./autogen.sh

[... snipped ...]

  ELC  
/<>/emacs-26.1+1/debian/build-src/test/src/process-tests.elc
  GEN  src/process-tests.log
  ELC  /<>/emacs-26.1+1/debian/build-src/test/src/regex-tests.elc
  GEN  src/regex-tests.log
  ELC  /<>/emacs-26.1+1/debian/build-src/test/src/syntax-tests.elc
  GEN  src/syntax-tests.log
  ELC  
/<>/emacs-26.1+1/debian/build-src/test/src/textprop-tests.elc
  GEN  src/textprop-tests.log
  ELC  /<>/emacs-26.1+1/debian/build-src/test/src/thread-tests.elc
  GEN  src/thread-tests.log
  ELC  /<>/emacs-26.1+1/debian/build-src/test/src/undo-tests.elc

In toplevel form:
../../build-src/test/src/undo-tests.el:262:6:Warning: `delete-forward-char' is
for interactive use only; use `delete-char' instead.
../../build-src/test/src/undo-tests.el:317:6:Warning: `delete-forward-char' is
for interactive use only; use `delete-char' instead.
../../build-src/test/src/undo-tests.el:353:47:Warning: `delete-forward-char'
is for interactive use only; use `delete-char' instead.
../../build-src/test/src/undo-tests.el:370:13:Warning: `delete-forward-char'
is for interactive use only; use `delete-char' instead.
../../build-src/test/src/undo-tests.el:394:19:Warning: `delete-forward-char'
is for interactive use only; use `delete-char' instead.
../../build-src/test/src/undo-tests.el:433:11:Warning: `delete-forward-char'
is for interactive use only; use `delete-char' instead.
  GEN  src/undo-tests.log
  ELC  /<>/emacs-26.1+1/debian/build-src/test/src/xml-tests.elc
  GEN  src/xml-tests.log
make[5]: Leaving directory '/<>/emacs-26.1+1/debian/build-lucid/test'
make[4]: [Makefile:263: check-doit] Error 2 (ignored)

SUMMARY OF TEST RESULTS
---
Files examined: 185
Ran 2563 tests, 2513 results as expected, 1 unexpected, 49 skipped
1 files contained unexpected results:
  lisp/eshell/em-ls-tests.log
make[4]: *** [Makefile:264: check-doit] Error 1
make[4]: Leaving directory '/<>/emacs-26.1+1/debian/build-lucid/test'
make[3]: *** [Makefile:239: check] Error 2
make[3]: Leaving directory '/<>/emacs-26.1+1/debian/build-lucid/test'
make[2]: *** [Makefile:946: check] Error 2
make[2]: Leaving directory '/<>/emacs-26.1+1/debian/build-lucid'
make[1]: *** [debian/rules:340: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>/emacs-26.1+1'
make: *** [debian/rules:204: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/emacs.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#918606: systemd: Missing portablectl and portabled in systemd 239+

[Michael Biebl]

Hi Andreas

Am 07.01.19 um 19:47 schrieb Andreas Henriksson:
> Relevant commit on debian packaging:
> https://salsa.debian.org/systemd-team/systemd/commit/03ae999bb5a731812a2cd1412478b0f337bfbfab
> 
>   "This is still an experimental feature."
> 
> Since systemd 240 the portable thing moved from experimental to
> "supported". From upstream 240 NEWS entry:
> 
> * portablectl is now officially supported and has thus moved to
>   /usr/bin/.
> 
> I thus think it makes sense to consider enable and ship it as a 
> wishlist request also (or primarily) for unstable/testing. Thus marking
> it as found in that version as well.

I'm leaning towards enabling this feature in buster+1 even if upstream
has declared it supported in v240. My gut feeling is that it's not quite
ready yet for a release in Debian stable, i.e. buster.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#918508: Should golang-1.10 be shpped in buster?

[Dr. Tobias Quathamer]

Am 06.01.2019 um 21:11 schrieb Adrian Bunk:
> Source: golang-1.10
> Severity: serious
> 
> With golang-1.11 as default now, should golang-1.10
> be shipped in buster?

Hi Adrian,

probably not, but I'd like to keep it in buster for a little longer,
just to make sure that golang-1.11 is a sane default. If everything
breaks apart, we could still use golang-1.10 ... :-)

I'll make sure to remove it from unstable (and testing) before we're
deep into the freeze.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#918644: vice: After the lastest update VICE does not use its otherwiese well known configuration files

[Ankman]

Package: vice
Version: 3.3.0.dfsg-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Starting for example x64 complains that the rom file for chargen and other 
support roms were not found and bails out.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Just invoking x64 (also x128 and others) on the command prompt.

   * What was the outcome of this action?

VICE threw an error message about missing support roms and terminated.

Important note: when I call "x64 -config ~/.vice/vicerc" instead it works. 
Hence after the latest update VICE "forgot" where the default config files are.

   * What outcome did you expect instead?

VICE should just start.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (1001, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), 
LANGUAGE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vice depends on:
ii  dpkg 1.19.2
ii  install-info 6.5.0.dfsg.1-4+b1
ii  libasound2   1.1.7-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-2
ii  libcairo-gobject21.16.0-2
ii  libcairo21.16.0-2
ii  libfontconfig1   2.13.1-2
ii  libgcc1  1:8.2.0-13
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libgl1   1.1.0-1
ii  libglew2.1   2.1.0-3
ii  libglib2.0-0 2.58.2-3
ii  libgtk-3-0   3.24.2-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpng16-16  1.6.36-2
ii  libpulse012.2-2
ii  libreadline7 7.0-5
ii  libstdc++6   8.2.0-13
ii  zlib1g   1:1.2.11.dfsg-1

vice recommends no packages.

vice suggests no packages.

-- no debconf information

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Isaac Gelado]

I am having this very same issue. If I run

udevadm trigger --type=subsystems --action=add
udevadm trigger --type=devices --action=add

in the initramdfs shell, it does nothing at all. However, if I run

udevadm trigger --type=subsystems --action=add -v
udevadm trigger --type=devices --action=add -v

it loads the necessary modules. Adding the extra `-v` to the
initramfs-tools script seems to work, but makes the boot quite bloated
of text :-)

Bug#844484: Warning: slow font initialization + graph not displayed in the window

[Vincent Lefevre]

Control: found -1 5.2.5+dfsg1-1

Another issue is that the warning message doesn't end with a newline
character.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#903428: deduplicating jquery/

[Samuel Thibault]

Emmanuel Bourg, le lun. 07 janv. 2019 22:25:35 +0100, a ecrit:
> Le 07/01/2019 à 21:13, Nicholas D Steeves a écrit :
> > Do you have any suggestions for working with the following?: (please
> > reply to -devel)
> 
> We've discussed this topic in #903428 and the consensus is roughly that
> it's a waste of time and we would rather drop the mostly unused javadoc
> packages than implementing this.

I'd rather cripple the documentation a bit than removing it :)

Could jh_build perhaps just drop the embedded jquery copy to just avoid
the issue? AFAIK, jquery is only used to implement the "search" feature,
which can sometimes be convenient, but can be done by users with greps &
such.

Samuel

Bug#918643: fails to import on python 3

[Jelmer Vernooij]

Package: python3-mpltoolkits.basemap
Version: 1.1.0+dfsg-3
Severity: important


mpl_toolkits.basemap fails to import on Python 3:

# pydoc3 mpl_toolkits.basemap
problem in mpl_toolkits.basemap - ImportError: cannot import name 'is_scalar' 
from 'matplotlib.cbook' 
(/usr/lib/python3/dist-packages/matplotlib/cbook/__init__.py)


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

Kernel: Linux 4.19.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 python3-mpltoolkits.basemap depends on:
ii  libc62.28-4
ii  libgeos-c1v5 3.7.1-1
ii  python-mpltoolkits.basemap-data  1.1.0+dfsg-3
ii  python3  3.7.1-3
ii  python3-matplotlib   3.0.2-2
ii  python3-pyproj   1.9.6-1
ii  python3-pyshp2.0.1+ds-1

Versions of packages python3-mpltoolkits.basemap recommends:
ii  python3-pil  5.3.0-1

Versions of packages python3-mpltoolkits.basemap suggests:
pn  python3-owslib  
pn  python3-scipy   

-- no debconf information

Bug#918617: wml: Apparent wrong usage of DEB_TARGET_*

[Axel Beckert]

Control: tag -1 + confirmed

Hi Guillem,

Guillem Jover wrote:
> I noticed while reading the latest changelog entry that this package
> is using DEB_TARGET_* variables, which seems incorrect.

Hrmmm.

> These are intended to be used when building cross-compilers, not for
> general cross-compiling.

Ah, indeed. This is not explained under VARIABLES, only above under
TERMS.

> I've skimmed over the packaging, and it appears to me you should be
> using DEB_HOST_* instead?

Yeah, I took DEB_HOST_* for DEB_BUILD_* and DEB_TARGET_* for
DEB_HOST_*. So I basically had the right idea, but got the terms
wrong.

> Please refer to the dpkg-architecture(1) man page for further
> details on the intended usage of each of these variables. :)

Maybe a hint on the TERMS section inside the VARIABLES section would
have avoided this. (Especially when using man pages as a reference,
they're not read top-down. :-)

Anyway, thanks for the bug report and the hints!

Will be part of the next upload. I though intent to let 2.12.0~ds1-4
migrate to testing (should be the case in a few hours) and upload the
fix afterwards.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#918607: ITP: kthresher -- Purge Unused Kernels

[Eduard Bloch]

Hallo,
* Darshaka Pathirana [Mon, Jan 07 2019, 07:30:24PM]:
> Package: wnpp
> Severity: wishlist
> Owner: Darshaka Pathirana 
> 
> * Package name: kthresher
>   Version : 1.3.1
>   Upstream Author : Rackspace US, Inc.
> * URL : https://github.com/rackerlabs/kthresher
> * License : Apache
>   Programming Lang: Python
>   Description : Purge Unused Kernels
> 
> Tool to remove unused kernels that were installed automatically
> This tool removes those kernel packages marked as candidate for autoremoval.
> Those packages are generally installed via Unattended upgrade or
> meta-packages. By default the latest kernel and manual installations are
> marked to Never Auto Remove.

Please point out the difference to "deborphan --guess-kernel" somewhere
along the lines.

Best Regards,
Eduard.
-- 
error compiling committee.c: too many arguments to function

Bug#918443: sl-modem: ftbfs on i386: undefined reference to `minor'

[Ben Hutchings]

Control: tag -1 patch

I just ran into this and am attaching a patch for it.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


From: Ben Hutchings 
Date: Mon, 07 Jan 2019 21:21:23 +
Subject: modem_main: Fix build with glibc 2.28

Starting with glibc 2.28, the major() and minor() macros are defined
in  which is not included by another header.

 does not exist in older glibc versions, so we
shouldn't include it unconditionally.  Add a check for availability of
the header to the Makefile and define a macro to tell modem_main.c the
result.

---
--- a/modem/Makefile
+++ b/modem/Makefile
@@ -44,6 +44,10 @@ CFLAGS+= -DSUPPORT_ALSA=1
 LDFLAGS+= -lasound
 endif
 
+ifeq ($(shell echo '\#include ' | $(CC) $(CFLAGS) $(CPPFLAGS) $(EXTRA_CFLAGS) -E -x c -o /dev/null - 2>&1),)
+CFLAGS+= -DHAVE_SYS_SYSMACROS_H
+endif
+
 slmodemd:
 	$(CC) -o slmodemd modem_main.o $(all-objs) $(LDFLAGS)
 
--- a/modem/modem_main.c
+++ b/modem/modem_main.c
@@ -55,6 +55,9 @@
 #include 
 #include 
 #include 
+#ifdef HAVE_SYS_SYSMACROS_H
+#include 
+#endif
 #include 
 #include 
 #include 


signature.asc
Description: This is a digitally signed message part

Bug#915514: pysph: diff for NMU version 0~20180411.git1ae58e1-2.1

[Adrian Bunk]

Control: tags 915514 + pending

Dear maintainer,

I've prepared an NMU for pysph (versioned as 0~20180411.git1ae58e1-2.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru pysph-0~20180411.git1ae58e1/debian/changelog pysph-0~20180411.git1ae58e1/debian/changelog
--- pysph-0~20180411.git1ae58e1/debian/changelog	2018-05-20 18:43:24.0 +0300
+++ pysph-0~20180411.git1ae58e1/debian/changelog	2019-01-07 23:30:08.0 +0200
@@ -1,3 +1,13 @@
+pysph (0~20180411.git1ae58e1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing build dependencies on python-pytest
+and python-pytest-runner, thanks to Steve Langasek.
+(Closes: #915514)
+  * Update Homepage: to the current upstream location.
+
+ -- Adrian Bunk   Mon, 07 Jan 2019 23:30:08 +0200
+
 pysph (0~20180411.git1ae58e1-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru pysph-0~20180411.git1ae58e1/debian/control pysph-0~20180411.git1ae58e1/debian/control
--- pysph-0~20180411.git1ae58e1/debian/control	2018-05-20 18:43:05.0 +0300
+++ pysph-0~20180411.git1ae58e1/debian/control	2019-01-07 23:30:08.0 +0200
@@ -11,6 +11,8 @@
python-mock,
python-nose,
python-numpy,
+   python-pytest,
+   python-pytest-runner,
python-sphinx,
python-sphinx-rtd-theme,
python-traits,
@@ -18,7 +20,7 @@
 Standards-Version: 4.1.4
 Vcs-Browser: https://salsa.debian.org/science-team/pysph
 Vcs-Git: https://salsa.debian.org/science-team/pysph.git
-Homepage: http://pysph.googlecode.com
+Homepage: https://github.com/pypr/pysph
 
 Package: python-pysph
 Architecture: any

Bug#851189: keyboard-configuration: ALT+Cursor-Left switches consoles instead of working on app in focus

[Mike McGuire]

It's a xenial chroot and it indeed doesn't have that test in 
keyboard-configuration.postinst. Perhaps just an ubuntu issue then, sorry for 
the noise. ;-)

Bug#918641: pkg_resources.DistributionNotFound: The 'cheroot' distribution was not found and is required by fava

[Stefano Zacchiroli]

Package: python3-fava
Version: 1.9-3
Severity: serious

As per subject, running fava fails with the following traceback:

  Traceback (most recent call last):
File "/usr/bin/fava", line 6, in 
  from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3126, 
in 
  @_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3110, 
in _call_aside
  f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3139, 
in _initialize_master_working_set
  working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 581, 
in _build_master
  ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 898, 
in require
  needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 784, 
in resolve
  raise DistributionNotFound(req, requirers)
  pkg_resources.DistributionNotFound: The 'cheroot' distribution was not found 
and is required by fava

this should ideally be fixed by having cheroot ship an egg-info dir, but it's
being filed against fava for now to avoid testing migration.

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

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

Versions of packages python3-fava depends on:
ii  python3  3.7.1-3
ii  python3-babel2.6.0+dfsg.1-1
ii  python3-beancount2.1.3+hg20181225-3
ii  python3-click6.7+git20180829-1
ii  python3-flask1.0.2-3
ii  python3-flask-babel  0.11.2-2
ii  python3-jinja2   2.10-1
ii  python3-markdown22.3.7-1
ii  python3-ply  3.11-3
ii  python3-simplejson   3.15.0-1+b1

python3-fava recommends no packages.

python3-fava suggests no packages.

-- no debconf information

Bug#776450: Xen PVH support for grub-xen in Buster

[Colin Watson]

On Mon, Jan 07, 2019 at 09:53:36PM +0100, Hans van Kranenburg wrote:
> Note that:
> 
> Installing for x86_64-xen platform.
> grub-install: warning: no hints available for your platform. Expect
> reduced performance.
> Installation finished. No error reported.
> 
> ...which means that it only has /boot/grub/x86_64-xen with a copy of the
> modules. Maybe that's something to think about for the part of the story
> that actually expects those modules to be there? Maybe just always throw
> all of the three different types in there?

Oh right, I indeed forgot that bit.  I've pushed a fix (though no need
to retest).  i386-xen can only boot a 32-bit kernel and so isn't usable
with an amd64 userspace, but i386-xen_pvh can be used either way.

> Anyway, the first thing we're testing doesn't rely on that, so let's
> continue. In the xen config file, I use...
> 
>  >8 
> kernel = "/usr/lib/grub-xen/grub-i386-xen_pvh.bin"
> type = "pvh"
>  >8 
> 
> ...and yes, blue grub screen and it boots.

Excellent; thanks a lot for the test!

> Suggestion:
> 
> From usability point of view, it would actually also be nice if
> console=hvc0 would be added by default in the GRUB_CMDLINE_LINUX_DEFAULT
> for inside the Xen domU.
> 
> The default is now "quiet", but if you remove "quiet", it stays as
> quiet, and for a new user, it doesn't have to be super obvious what to
> do in this case.

It would be helpful not to collect too many not-very-closely-related
issues into this single bug.  In any case, if you install via the Debian
installer then it arranges for this to happen; we could look into doing
it somewhere else if there were a compelling reason to do so, but I'm a
little wary of shuffling all that fairly delicate machinery around as we
approach release, and d-i already sets up a number of other similar
things so is in a good position to do this.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#918640: gwcs: autopkgtest regression: missing versioned dependency?

[Paul Gevers]

Source: gwcs
Version: 0.10.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of gwcs the autopkgtest of gwcs fails in testing
when that autopkgtest is run with the binary packages of gwcs from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
gwcs   from testing0.10.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. As the test
passes in unstable, it seems to me that you are missing a versioned
dependency somewhere.

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gwcs

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gwcs/1658972/log.gz

autopkgtest [05:58:25]: test command1: [---
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/gwcs/__init__.py", line 22, in

from .wcs import *   # noqa
  File "/usr/lib/python3/dist-packages/gwcs/wcs.py", line 8, in 
from .api import GWCSAPIMixin
  File "/usr/lib/python3/dist-packages/gwcs/api.py", line 7, in 
from astropy.wcs.wcsapi import BaseHighLevelWCS, BaseLowLevelWCS
ModuleNotFoundError: No module named 'astropy.wcs.wcsapi'
autopkgtest [05:58:26]: test command1: ---]
autopkgtest [05:58:26]: test command1:  - - - - - - - - - - results - -
- - - - - - - -
command1 FAIL non-zero exit status 1
autopkgtest [05:58:26]: test command1:  - - - - - - - - - - stderr - - -
- - - - - - -
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/gwcs/__init__.py", line 22, in

from .wcs import *   # noqa
  File "/usr/lib/python3/dist-packages/gwcs/wcs.py", line 8, in 
from .api import GWCSAPIMixin
  File "/usr/lib/python3/dist-packages/gwcs/api.py", line 7, in 
from astropy.wcs.wcsapi import BaseHighLevelWCS, BaseLowLevelWCS
ModuleNotFoundError: No module named 'astropy.wcs.wcsapi'



signature.asc
Description: OpenPGP digital signature

Bug#917468: pelican BTS info

[Geert Stappers]

Control: tag -1 confirmed

On Sun, Jan 06, 2019 at 12:46:59AM -0500, Jeremy Bicha wrote:
> Source: pelican
> Version: 3.7.1+dfsg-2
> 
> pelican fails to build. I notice that a dependency on python3-feedparser
> was added, but pelican appears to be a Python2 package.

Acknowledge.
The upload for version: 3.7.1+dfsg-2 was only for fixing VCS fields
 ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917468 )

However, the latest VCS changes are temporary
at https://salsa.debian.org/stappers/pelican


The plan for fixing this #918447 is with #875255, provide version of
packege under Python 3, and #913875, new upstream version.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875255
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913875


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#918545: qtdeclarative-opensource-src: FTBFS on x32: mis-detected as having amd64 JIT

[Dmitry Shachnev]

Hi Thorsten!

On Mon, Jan 07, 2019 at 12:15:25PM +0100, Thorsten Glaser wrote:
> src/qml/jsruntime/qv4global_p.h line 94 always triggers,
> because x32 is detected as amd64 (Q_PROCESSOR_X86 and
> Q_PROCESSOR_X86_64 are defined and QT_POINTER_SIZE is 8)
> by qtbase5-dev (src/corelib/global/qprocessordetection.h).

Are you sure it’s line 94 and not line 91?

QT_POINTER_SIZE is taken directly from GCC’s __SIZEOF_POINTER__, and
according to the comment [1] it “catches all known cases of ILP32 builds”.
So its value should be 4, not 8 on x32. If for some reason it’s not the
case, then we should fix _that_ in the first place.

In case it is line 91, then simply changing defined(Q_PROCESSOR_X86) to
defined (Q_PROCESSOR_X86_32) should be enough. Can you try that and
see if it helps?

I should add that this code used to rely on __ILP32__ macro, however it was
replaced with QT_POINTER_SIZE checks in [2].

[1]: 
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qprocessordetection.h?h=5.11#n349
[2]: https://code.qt.io/cgit/qt/qtdeclarative.git/commit/?id=0fada59c49a06cec

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#918635: node-buble: autopkgtest regression

[Paul Gevers]

Source: node-buble
Version: 0.19.4-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of node-buble the autopkgtest of node-buble fails
in testing when that autopkgtest is run with the binary packages of
node-buble from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
node-buble from testing0.19.4-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
to testing [1] and without fix, this version will not be in buster. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=node-buble

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-buble/1658900/log.gz

compile-self FAIL stderr:
autopkgtest [05:31:55]: test compile-self:  - - - - - - - - - - stderr -
- - - - - - - - -

src/index.js → dist/buble.es.js, dist/buble.cjs.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
acorn-jsx/inject (imported by src/index.js)
acorn-dynamic-import/lib/inject (imported by src/index.js)
regexpu-core (imported by src/program/types/Literal.js)
created dist/buble.es.js, dist/buble.cjs.js in 1.3s

src/index.js → ./dist/buble-browser.es.js, ./dist/buble-browser.cjs.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
acorn-jsx/inject (imported by src/index.js)
acorn-dynamic-import/lib/inject (imported by src/index.js)
regexpu-core (imported by src/program/types/Literal.js)
created ./dist/buble-browser.es.js, ./dist/buble-browser.cjs.js in 943ms

src/index.js → dist/buble-browser-deps.umd.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
acorn (imported by src/index.js)
acorn-jsx/inject (imported by src/index.js)
acorn-dynamic-import/lib/inject (imported by src/index.js)
magic-string (imported by src/program/Program.js)
regexpu-core (imported by src/program/types/Literal.js)
(!) Missing global variable names
Use options.globals to specify browser global variable names
corresponding to external modules
acorn (guessing 'acorn')
acorn-jsx/inject (guessing 'acornJsx')
acorn-dynamic-import/lib/inject (guessing 'acornDynamicImport')
magic-string (guessing 'MagicString')
regexpu-core (guessing 'rewritePattern')
created dist/buble-browser-deps.umd.js in 794ms

src/index.js → dist/buble.es.js, dist/buble.cjs.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
acorn-jsx/inject (imported by src/index.js)
acorn-dynamic-import/lib/inject (imported by src/index.js)
regexpu-core (imported by src/program/types/Literal.js)
created dist/buble.es.js, dist/buble.cjs.js in 1.3s

src/index.js → ./dist/buble-browser.es.js, ./dist/buble-browser.cjs.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
acorn-jsx/inject (imported by src/index.js)
acorn-dynamic-import/lib/inject (imported by src/index.js)
regexpu-core (imported by src/program/types/Literal.js)
created ./dist/buble-browser.es.js, ./dist/buble-browser.cjs.js in 909ms

src/index.js → dist/buble-browser-deps.umd.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
acorn (imported by src/index.js)
acorn-jsx/inject (imported by src/index.js)
acorn-dynamic-import/lib/inject (imported by src/index.js)
magic-string (imported by src/program/Program.js)
regexpu-core (imported by src/program/types/Literal.js)
(!) Missing global variable names
Use options.globals to specify browser global variable names
corresponding to external modules
acorn (guessing 'acorn')
acorn-jsx/inject (guessing 'acornJsx')
acorn-dynamic-import/lib/inject (guessing 'acornDynamicImport')
magic-string (guessing 'MagicString')
regexpu-core (guessing 'rewritePattern')
created dist/buble-browser-deps.umd.js in 774ms

src/index.js → dist/buble.es.js, dist/buble.cjs.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/wiki/Troubleshooting#treating-module-as-external-dependency
acorn-jsx/inject (imported by src/index.js)
acorn-dynamic-import/lib/inject (imported by src/index.js)
regexpu-core (imported by src/program/types/Literal.js)
created dist/buble.es.js, dist/buble.cjs.js in 1.3s

src/index.js → ./dist/buble-browser.es.js, ./dist/buble-browser.cjs.js...
(!) Unresolved dependencies
https://github.com/rollup/rollup/w

Bug#918318: hyphen-pl: please provide symlinks for generic language hyphenation dictionaries

[Daniel Kahn Gillmor]

Control: clone 918318 -2
Control: reassign -2 hyphen-pl
Control: retitle -2 hyphen-pl: please provide symlinks for generic language 
hyphenation dictionaries

On Mon 2019-01-07 18:25:08 +0100, Mattia Rizzolo wrote:
> On Fri, Jan 04, 2019 at 06:45:18PM -0500, Daniel Kahn Gillmor wrote:
>> pl → pl_PL (hyphen-pl)
>
> Also this, comes from src:openoffice.org-hyphenation-pl
>
> -- 
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#918318: please provide symlinks for generic language hyphenation dictionaries

[Daniel Kahn Gillmor]

Control: clone 918318 -2
Control: reassign -2 hyphen-ru
Control: retitle -2 hyphen-ru: please provide symlinks for generic language 
hyphenation dictionaries
Control: clone 918318 -3
Control: reassign -3 hyphen-te
Control: retitle -3 hyphen-te: please provide symlinks for generic language 
hyphenation dictionaries

On Mon 2019-01-07 18:30:32 +0100, Mattia Rizzolo wrote:
> On Fri, Jan 04, 2019 at 06:45:18PM -0500, Daniel Kahn Gillmor wrote:
>> ru → ru_RU (hyphen-ru)
>
> and this (from src:hyphen-ru)
>
>> te → te_IN (hyphen-te)
>
> and this (from src:hyphen-indic)
>
>
> :)
>
> -- 
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#918318: hyphen-lv: please provide symlinks for generic language hyphenation dictionaries

[Daniel Kahn Gillmor]

Control: clone 918318 -2
Control: reassign -2 hyphen-lv
Control: retitle -2 hyphen-lv: please provide symlinks for generic language 
hyphenation dictionaries

On Mon 2019-01-07 18:22:16 +0100, Mattia Rizzolo wrote:
> On Fri, Jan 04, 2019 at 06:45:18PM -0500, Daniel Kahn Gillmor wrote:
>> lv → lv_LV (hyphen-lv)
>
> This comes from a different source package, so please redirect this
> request over there.
>
> -- 
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#918634: python-pydub: autopkgtest regression

[Paul Gevers]

Source: python-pydub
Version: 0.23.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of python-pydub the autopkgtest of python-pydub
fails in testing when that autopkgtest is run with the binary packages
of python-pydub from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python-pydub   from testing0.23.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It looks like
you are missing a test dependency.

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-pydub

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pydub/1658928/log.gz

autopkgtest [05:41:56]: test command1: python -c "from pydub import
AudioSegment"
autopkgtest [05:41:56]: test command1: [---
pydub/utils.py:165: RuntimeWarning: Couldn't find ffmpeg or avconv -
defaulting to ffmpeg, but may not work
  warn("Couldn't find ffmpeg or avconv - defaulting to ffmpeg, but may
not work", RuntimeWarning)
autopkgtest [05:41:56]: test command1: ---]


autopkgtest [05:41:59]: test command2: python3 -c "from pydub import
AudioSegment"
autopkgtest [05:41:59]: test command2: [---
/tmp/autopkgtest-lxc.7hsbcu7v/downtmp/build.NvP/src/pydub/utils.py:165:
RuntimeWarning: Couldn't find ffmpeg or avconv - defaulting to ffmpeg,
but may not work
  warn("Couldn't find ffmpeg or avconv - defaulting to ffmpeg, but may
not work", RuntimeWarning)
autopkgtest [05:41:59]: test command2: ---]



signature.asc
Description: OpenPGP digital signature

Bug#918633: why3-coq: package should Depend on a specific Coq version

[Benjamin Barenblat]

Package: why3-coq
Version: 1.1.1-1
Severity: serious

why3-coq Depends on coq, but it contains compiled .vo files that can
only be read by Coq 8.6. (In general, Coq .vo files are tied to the
minor version of Coq that produced them.) why3-coq should Depend on the
minor version of Coq that compiled it (like 8.6 or 8.8).

Bug#776450: Xen PVH support for grub-xen in Buster

[Hans van Kranenburg]

On 1/7/19 2:13 PM, Hans van Kranenburg wrote:
> On 1/7/19 12:48 PM, Colin Watson wrote:
>> [...]
> 
>> Would you mind trying out the temporary pvh branch of
>> https://salsa.debian.org/grub-team/grub ?  I'd like to know whether the
>> resulting grub-xen-host binary package does the right thing, when built
>> in the ordinary way (I've test-built this branch using sbuild).
> 
> Sure. I'll have a look at it today.

Ok, I've built it in sid pbuilder.

On dom0 (this is actually a buster one):

-# dpkg -L grub-xen-host |grep bin
/usr/lib/grub-xen/grub-i386-xen.bin
/usr/lib/grub-xen/grub-i386-xen_pvh.bin
/usr/lib/grub-xen/grub-x86_64-xen.bin

In domU I installed grub-xen-bin grub-xen grub2-common grub-common.

Note that:

Installing for x86_64-xen platform.
grub-install: warning: no hints available for your platform. Expect
reduced performance.
Installation finished. No error reported.

...which means that it only has /boot/grub/x86_64-xen with a copy of the
modules. Maybe that's something to think about for the part of the story
that actually expects those modules to be there? Maybe just always throw
all of the three different types in there?

Anyway, the first thing we're testing doesn't rely on that, so let's
continue. In the xen config file, I use...

 >8 
kernel = "/usr/lib/grub-xen/grub-i386-xen_pvh.bin"
type = "pvh"
 >8 

...and yes, blue grub screen and it boots.

Suggestion:

>From usability point of view, it would actually also be nice if
console=hvc0 would be added by default in the GRUB_CMDLINE_LINUX_DEFAULT
for inside the Xen domU.

The default is now "quiet", but if you remove "quiet", it stays as
quiet, and for a new user, it doesn't have to be super obvious what to
do in this case.

Hans

Bug#918632: simplejson breaks json-schema-validator autopkgtest

[Paul Gevers]

Source: simplejson, json-schema-validator
Control: found -1 simplejson/3.16.0-1
Control: found -1 json-schema-validator/2.3.1-3
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of simplejson the autopkgtest of
json-schema-validator fails in testing when that autopkgtest is run with
the binary packages of simplejson from unstable. It passes when run with
only packages from testing. In tabular form:
   passfail
simplejson from testing3.16.0-1
json-schema-validator  from testing2.3.1-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
of simplejson to testing [1]. Due to the nature of this issue, I filed
this bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=simplejson

https://ci.debian.net/data/autopkgtest/testing/amd64/j/json-schema-validator/1658943/log.gz

==
FAIL: test_validation_error_has_proper_message
(tests.test_validator.ValidatorFailureTests)
tests.test_validator.ValidatorFailureTests.test_validation_error_has_proper_message
(type_boolean_got_empty_string)
--
_StringException: Traceback (most recent call last):
  File
"/usr/lib/python2.7/dist-packages/json_schema_validator/tests/test_validator.py",
line 501, in test_validation_error_has_proper_message
self.assertEqual(ex.message, self.raises.message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
411, in assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: "'' does not match type
'boolean'" != "u'' does not match type 'boolean'"


==
FAIL: test_validation_error_has_proper_message
(tests.test_validator.ValidatorFailureTests)
tests.test_validator.ValidatorFailureTests.test_validation_error_has_proper_message
(type_null_got_empty_string)
--
_StringException: Traceback (most recent call last):
  File
"/usr/lib/python2.7/dist-packages/json_schema_validator/tests/test_validator.py",
line 501, in test_validation_error_has_proper_message
self.assertEqual(ex.message, self.raises.message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
411, in assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: "'' does not match type 'null'"
!= "u'' does not match type 'null'"


--
Ran 302 tests in 0.067s

FAILED (failures=2)



signature.asc
Description: OpenPGP digital signature

Bug#917660: NMU of pyhamcrest to fix FTBFS in vim-youcompleteme

[David Kalnischkies]

Hi,

On Mon, Dec 31, 2018 at 12:06:53AM +0100, David Kalnischkies wrote:
> As the freeze is drawing near I would appreciate a reply in the next
> week so that we can proceed accordingly – I am e.g. happy to sponsor
> uploads if need be. On the other hand, if I get no reply I plan to
> upload at least a no-change -2 revision soon to resolve at least the

I just uploaded -1.1 to DELAYED/2 as I wanted to wait for the 5 year
anniversary of the last upload. ;)

It's a strange diff in the binary python3-hamcrest package causing
a FTBFS (and hence serious) bug in at least one package I care about
fixed just by a rebuild, not a patch, so I hope its okay that I was
waiting only 7 (+2) days in between years before NMUing.

Feel free to drop me a line if I should cancel the upload OR override
with an upload of your own – I am also happy to sponsor an upload if
need be!


Debdiff attached – which beside my changelog-only change includes also
the so far not uploaded trivial changes in the VCS as it seemed like
a good idea to point to an existing VCS (even if I have no access as
I am not a member of python modules team) and correcting b-d. I have a
branch locally with the NMU if you would prefer that.


Best regards

David Kalnischkies
diff -Nru pyhamcrest-1.8.0/debian/changelog pyhamcrest-1.8.0/debian/changelog
--- pyhamcrest-1.8.0/debian/changelog   2014-01-09 22:27:04.0 +0100
+++ pyhamcrest-1.8.0/debian/changelog   2019-01-07 18:49:27.0 +0100
@@ -1,3 +1,20 @@
+pyhamcrest (1.8.0-1.1) unstable; urgency=medium
+
+  [ David Kalnischkies ]
+  * No-change non-maintainer upload to have python3-hamcrest rebuild without
+the use of deprecated collections ABI usage causing FTBFS in at least
+src:vim-youcompleteme (Closes: #917660)
+
+  [ Ondřej Nový ]
+  * Fixed VCS URL (https)
+  * d/control: Set Vcs-* to salsa.debian.org
+  * Convert git repository from git-dpm to gbp layout
+
+  [ Piotr Ożarowski ]
+  * Add dh-python to Build-Depends
+
+ -- David Kalnischkies   Mon, 07 Jan 2019 18:49:27 +0100
+
 pyhamcrest (1.8.0-1) unstable; urgency=low
 
   * New release
diff -Nru pyhamcrest-1.8.0/debian/control pyhamcrest-1.8.0/debian/control
--- pyhamcrest-1.8.0/debian/control 2014-01-09 22:27:04.0 +0100
+++ pyhamcrest-1.8.0/debian/control 2019-01-07 18:49:27.0 +0100
@@ -5,14 +5,15 @@
 Uploaders: Debian Python Modules Team 

 Build-Depends:
  debhelper (>= 7.0.50),
+ dh-python,
  python-all (>= 2.6.6-3),
  python-setuptools (>= 0.6b3),
  python3-all,
  python3-setuptools
 Standards-Version: 3.9.5
 Homepage: http://code.google.com/p/hamcrest
-Vcs-Svn: svn://anonscm.debian.org/python-modules/packages/pyhamcrest/trunk/
-Vcs-Browser: 
http://anonscm.debian.org/viewvc/python-modules/packages/pyhamcrest/trunk/
+Vcs-Git: https://salsa.debian.org/python-team/modules/pyhamcrest.git
+Vcs-Browser: https://salsa.debian.org/python-team/modules/pyhamcrest
 
 Package: python-hamcrest
 Architecture: all


signature.asc
Description: PGP signature

Bug#918631: python-pyramid: autopkgtest regression

[Paul Gevers]

Source: python-pyramid
Version: 1.10.1+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of python-pyramid the autopkgtest of python-pyramid
fails in testing when that autopkgtest is run with the binary packages
of python-pyramid from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python-pyramid from testing1.10.1+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-pyramid

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pyramid/1658962/log.gz

autopkgtest [05:56:32]: test command2: cd $AUTOPKGTEST_TMP; for p in
$(pyversions -s) $(py3versions -s); do $p -m unittest discover -v
pyramid.tests; done
autopkgtest [05:56:32]: test command2: [---
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
  File "/usr/lib/python2.7/unittest/__main__.py", line 12, in 
main(module=None)
  File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__
self.parseArgs(argv)
  File "/usr/lib/python2.7/unittest/main.py", line 113, in parseArgs
self._do_discovery(argv[2:])
  File "/usr/lib/python2.7/unittest/main.py", line 214, in _do_discovery
self.test = loader.discover(start_dir, pattern, top_level_dir)
  File "/usr/lib/python2.7/unittest/loader.py", line 204, in discover
raise ImportError('Start directory is not importable: %r' % start_dir)
ImportError: Start directory is not importable: 'pyramid.tests'
autopkgtest [05:56:32]: test command2: ---]



signature.asc
Description: OpenPGP digital signature

Bug#908492: NMU diff for nat-rtsp 0.7+4.18-0.1

[Ben Hutchings]

I made an NMU fixing this issue (with a new upstream version).  I also
updated the package to follow current policy and to fix some other
lintian complaints.

The new version is exported from the upstream tag 4.18 (commit
3a4a4866890e7daee96010291feb72396a99d9ed) so I used the upstream
version 0.7+4.18.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.

diff -Nru nat-rtsp-0.7+1.g2ea3cb6/debian/changelog nat-rtsp-0.7+4.18/debian/changelog
--- nat-rtsp-0.7+1.g2ea3cb6/debian/changelog	2013-12-12 16:56:57.0 +
+++ nat-rtsp-0.7+4.18/debian/changelog	2019-01-07 20:38:10.0 +
@@ -1,3 +1,17 @@
+nat-rtsp (0.7+4.18-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New upstream release:
+- Add support to linux 4.18 (Closes: #908492)
+  * Update to policy version 4.3.0:
+- debian/copyright: Use https: URL for copyright format
+- debian/control: Change priority to optional
+- debian/control: Set Rules-Requires-Root: no
+  * debian/source/options: Delete as redundant
+  * Use debhelper compatibility level 12
+
+ -- Ben Hutchings   Mon, 07 Jan 2019 20:38:10 +
+
 nat-rtsp (0.7+1.g2ea3cb6-1) unstable; urgency=low
 
   * Initial release (Closes: #732026)
diff -Nru nat-rtsp-0.7+1.g2ea3cb6/debian/compat nat-rtsp-0.7+4.18/debian/compat
--- nat-rtsp-0.7+1.g2ea3cb6/debian/compat	2013-12-07 00:26:35.0 +
+++ nat-rtsp-0.7+4.18/debian/compat	2019-01-07 20:16:43.0 +
@@ -1 +1 @@
-8
+12
diff -Nru nat-rtsp-0.7+1.g2ea3cb6/debian/control nat-rtsp-0.7+4.18/debian/control
--- nat-rtsp-0.7+1.g2ea3cb6/debian/control	2013-12-13 14:31:08.0 +
+++ nat-rtsp-0.7+4.18/debian/control	2019-01-07 20:35:53.0 +
@@ -1,10 +1,11 @@
 Source: nat-rtsp
 Section: kernel
-Priority: extra
+Priority: optional
 Maintainer: Julien Muchembled 
-Build-Depends: debhelper (>= 8.0.0), dkms
-Standards-Version: 3.9.5
+Build-Depends: debhelper (>= 12~), dkms
+Standards-Version: 4.3.0
 Homepage: https://github.com/maru-sama/rtsp-linux
+Rules-Requires-Root: no
 
 Package: nat-rtsp-dkms
 Architecture: all
diff -Nru nat-rtsp-0.7+1.g2ea3cb6/debian/copyright nat-rtsp-0.7+4.18/debian/copyright
--- nat-rtsp-0.7+1.g2ea3cb6/debian/copyright	2013-12-12 16:21:45.0 +
+++ nat-rtsp-0.7+4.18/debian/copyright	2019-01-07 20:25:23.0 +
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: rtsp-linux
 Source: https://github.com/maru-sama/rtsp-linux
 
diff -Nru nat-rtsp-0.7+1.g2ea3cb6/debian/source/options nat-rtsp-0.7+4.18/debian/source/options
--- nat-rtsp-0.7+1.g2ea3cb6/debian/source/options	2013-12-11 13:14:28.0 +
+++ nat-rtsp-0.7+4.18/debian/source/options	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-compression = xz
diff -Nru nat-rtsp-0.7+1.g2ea3cb6/nf_nat_rtsp.c nat-rtsp-0.7+4.18/nf_nat_rtsp.c
--- nat-rtsp-0.7+1.g2ea3cb6/nf_nat_rtsp.c	2013-04-03 18:22:19.0 +0100
+++ nat-rtsp-0.7+4.18/nf_nat_rtsp.c	2018-08-22 20:00:35.0 +0100
@@ -534,7 +534,9 @@
 
 static void nf_nat_rtsp_expected(struct nf_conn* ct, struct nf_conntrack_expect *exp)
 {
-#if LINUX_VERSION_CODE < KERNEL_VERSION(3,3,0) || LINUX_VERSION_CODE >= KERNEL_VERSION(3,7,0)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,18,0)
+	struct nf_nat_range2 range;
+#elif LINUX_VERSION_CODE < KERNEL_VERSION(3,3,0) || LINUX_VERSION_CODE >= KERNEL_VERSION(3,7,0)
 	struct nf_nat_range range;
 #else
 	struct nf_nat_ipv4_range range;


signature.asc
Description: This is a digitally signed message part

Bug#918630: TLS 1.3 not working

[Josu]

Package: pure-ftpd
Version: 1.0.43-3

Filezilla, lftp, and others clients that try to use TLSv1.3, and dont
have a fallback to TLSv1.2 version, fails in the renegotiation and close
the connection.

https://wiki.openssl.org/index.php/TLS1.3#Renegotiation
[...]
TLSv1.3 does not have renegotiation so calls to SSL_renegotiate() or
SSL_renegotiate_abbreviated() will immediately fail if invoked on a
connection that has negotiated TLSv1.3.
[...]

pure-ftpd issue:
https://github.com/jedisct1/pure-ftpd/issues/94

pure-ftpd patch:
https://github.com/jedisct1/pure-ftpd/commit/4a495c61ce22c893aed5ee57f6ce0b43c3be59ad

I have tested the patch and it works fine.


Josu Arenas.

Bug#917457: libilmbase23: 2.3.0-3 bumped so name without transition (breaks digikam, gimp, ...)

[Andreas Beckmann]

Followup-For: Bug #917457

Hi,

this seems to be fixed in 2.3.0-4 by introducing a libilmbase24 package,
but this lacks
  Breaks+Replaces: libilmbase23 (>= 2.3)
to properly upgrade from the buggy package in case someone installed
libilmbase23 from experimental.
Apparently people did ... and found this bug.


Andreas

Bug#918629: dnscrypt-proxy FTBFS with Go 1.11

[Adrian Bunk]

Source: dnscrypt-proxy
Version: 2.0.19+ds1-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dnscrypt-proxy.html

...
github.com/jedisct1/dnscrypt-proxy/dnscrypt-proxy
# github.com/jedisct1/dnscrypt-proxy/dnscrypt-proxy
github.com/aead/chacha20/chacha.supportsAVX2: relocation target 
runtime.support_avx not defined
github.com/aead/chacha20/chacha.supportsAVX2: relocation target 
runtime.support_avx2 not defined
github.com/aead/poly1305.supportsAVX2: relocation target runtime.support_avx2 
not defined
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/build/1st/dnscrypt-proxy-2.0.19\+ds1/obj-x86_64-linux-gnu/src\"
 
-asmflags=all=\"-trimpath=/build/1st/dnscrypt-proxy-2.0.19\+ds1/obj-x86_64-linux-gnu/src\"
 -v -p 15 github.com/jedisct1/dnscrypt-proxy/dnscrypt-proxy returned exit code 2
make: *** [debian/rules:12: build] Error 2

Bug#918627: node-cacache FTBFS with nodejs 10.15.0

[Adrian Bunk]

Source: node-cacache
Version: 10.0.4-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-cacache.html

...
270 passing (1m)
  7 pending
  2 failing

  1) test/content.write.js Cannot call write after a stream was destroyed:
 Error: Cannot call write after a stream was destroyed
  at WriteStream.end (/usr/lib/nodejs/flush-write-stream/index.js:43:41)

  2) test/put.js errors if input stream errors returns the error from input 
stream:
 Error: returns the error from input stream
  at pipe.then.catch.err (test/put.js:138:7)
  at tryCatcher (/usr/lib/nodejs/bluebird/js/release/util.js:16:23)
  at Promise._settlePromiseFromHandler 
(/usr/lib/nodejs/bluebird/js/release/promise.js:512:31)
  at Promise._settlePromise 
(/usr/lib/nodejs/bluebird/js/release/promise.js:569:18)
  at Promise._settlePromise0 
(/usr/lib/nodejs/bluebird/js/release/promise.js:614:10)
  at Promise._settlePromises 
(/usr/lib/nodejs/bluebird/js/release/promise.js:689:18)
  at Async._drainQueue (/usr/lib/nodejs/bluebird/js/release/async.js:133:16)
  at Async._drainQueues 
(/usr/lib/nodejs/bluebird/js/release/async.js:143:10)
  at Immediate.Async.drainQueues [as _onImmediate] 
(/usr/lib/nodejs/bluebird/js/release/async.js:17:14)

make[1]: *** [debian/rules:14: override_dh_auto_test] Error 1

Bug#918628: node-stream-splicer FTBFS with nodejs 10.15.0

[Adrian Bunk]

Source: node-stream-splicer
Version: 2.0.0-3
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-stream-splicer.html

...
  76 passing (3m)
  3 failing

  1) test/nested.js should be equivalent:
 Error: should be equivalent
  at Error: should be equivalent
  at at Test.assert [as _assert] 
(/usr/lib/nodejs/tape/lib/test.js:235:54)
  at at Test.bound [as _assert] (/usr/lib/nodejs/tape/lib/test.js:87:32)
  at at Test.tapeDeepEqual (/usr/lib/nodejs/tape/lib/test.js:432:10)
  at at Test.bound [as deepEqual] 
(/usr/lib/nodejs/tape/lib/test.js:87:32)
  at at test/nested.js:29:11
  at at ConcatStream. 
(/usr/lib/nodejs/concat-stream/index.js:37:43)
  at at finishMaybe (_stream_writable.js:641:14)
  at at endWritable (_stream_writable.js:649:3)
  at at ConcatStream.Writable.end (_stream_writable.js:589:5)

  2) test/nested_middle.js should be equivalent:
 Error: should be equivalent
  at Error: should be equivalent
  at at Test.assert [as _assert] 
(/usr/lib/nodejs/tape/lib/test.js:235:54)
  at at Test.bound [as _assert] (/usr/lib/nodejs/tape/lib/test.js:87:32)
  at at Test.tapeDeepEqual (/usr/lib/nodejs/tape/lib/test.js:432:10)
  at at Test.bound [as deepEqual] 
(/usr/lib/nodejs/tape/lib/test.js:87:32)
  at at test/nested_middle.js:35:11
  at at ConcatStream. 
(/usr/lib/nodejs/concat-stream/index.js:37:43)
  at at finishMaybe (_stream_writable.js:641:14)
  at at endWritable (_stream_writable.js:649:3)
  at at ConcatStream.Writable.end (_stream_writable.js:589:5)

  3) test/pop.js should be equivalent:
 Error: should be equivalent
  at Error: should be equivalent
  at at Test.assert [as _assert] 
(/usr/lib/nodejs/tape/lib/test.js:235:54)
  at at Test.bound [as _assert] (/usr/lib/nodejs/tape/lib/test.js:87:32)
  at at Test.tapeDeepEqual (/usr/lib/nodejs/tape/lib/test.js:432:10)
  at at Test.bound [as deepEqual] 
(/usr/lib/nodejs/tape/lib/test.js:87:32)
  at at test/pop.js:38:11
  at at ConcatStream. 
(/usr/lib/nodejs/concat-stream/index.js:37:43)
  at at finishMaybe (_stream_writable.js:641:14)
  at at endWritable (_stream_writable.js:649:3)
  at at ConcatStream.Writable.end (_stream_writable.js:589:5)

make[1]: *** [debian/rules:14: override_dh_auto_test] Error 1

Bug#918626: node-loader-utils FTBFS with nodejs 10.15.0

[Adrian Bunk]

Source: node-loader-utils
Version: 1.1.0-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-loader-utils.html

...
  89 passing (476ms)
  1 failing

  1) parseQuery()
   when passed string is any other string not starting with ?
 should throw an error:
 TypeError [ERR_AMBIGUOUS_ARGUMENT]: The "error/message" argument is 
ambiguous. The error message "A valid query string passed to parseQuery should 
begin with '?'" is identical to the message.
  at expectsError (assert.js:629:15)
  at Function.throws (assert.js:690:3)
  at Context.it (test/parseQuery.test.js:76:11)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:354:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:560:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:366:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
  at Immediate._onImmediate (/usr/lib/nodejs/mocha/lib/runner.js:334:5)



make[1]: *** [debian/rules:13: override_dh_auto_test] Error 1

Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns

[Anton Dollmaier]

Hi all,


On Fri, 5 Oct 2018 14:02:41 +0200 Sven Hartge  wrote:

On Wed, 27 Jun 2018 10:39:51 +0200 Martijn Grendelman
 wrote:

> Some of our Debian Stretch based Apache webservers suffer from
> intermittent connection timeouts.
> 
> We have been trying to pin down the problem for a while, and eventually,

> we found this bug report in Apache's Bugzilla, that seems to fit our
> problem perfectly:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60956


I can verifiy and this bug and also had to change to mpm_worker to work
around this bug.

A backport of the changes in mpm_event made for 2.4.28 would be very
nice, just like mod_http2 was backported from a newer version of apache2.


After suffering (probably) from this issue on multiple systems, I'd 
appreciate backporting the fix from Apache 2.4.28 to Stretch as well.


It could be just my personal impression, but it seems like this is 
affecting more systems over time. We spotted the issue (Apache hangs 
without warning and without logs until restarted or the timeout clears) 
on just one system, now multiple systems are affected, even with low or 
even just internal (browser clients behind VPN) traffic.


Switching to MPM_Worker helped to solve this in the meantime.

Best,
Anton Dollmaier

Bug#918625: astropy-healpix: autopkgtest deprecation warning due to new version of python-numpy

[Paul Gevers]

Source: astropy-healpix
Version: 0.4-1
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python-numpy

[X-Debbugs-CC: debian...@lists.debian.org, python-nu...@packages.debian.org]

Dear maintainers,

With a recent upload of python-numpy the autopkgtest of astropy-healpix
fails in testing when that autopkgtest is run with the binary packages
of python-numpy from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python-numpy   from testing1:1.16.0~rc2-1
astropy-healpixfrom testing0.4-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. Your
autopkgtest fails on a Deprecation Warning. If possible, please fix your
autopkgtest to not do that at all, but at least fix this issue.

Currently this regression is contributing to the delay of the migration
of python-numpy to testing [1]. Of course, python-numpy shouldn't just
break your autopkgtest (or even worse, your package), but it seems to me
that the change in python-numpy was intended and your package needs to
update to the new situation. If needed, please change the bug's severity.

I am going have this regression ignored for the python-numpy migration.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
python-numpy/1:1.16.0~rc2-1. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=python-numpy

https://ci.debian.net/data/autopkgtest/testing/amd64/a/astropy-healpix/1658971/log.gz

=== FAILURES
===
_ test_vec2pix
_

@given(nside_pow=integers(0, 29), nest=booleans(),
>  x=floats(-1, 1, allow_nan=False,
allow_infinity=False).filter(lambda x: abs(x) > 1e-10),
   y=floats(-1, 1, allow_nan=False,
allow_infinity=False).filter(lambda y: abs(y) > 1e-10),
   z=floats(-1, 1, allow_nan=False,
allow_infinity=False).filter(lambda z: abs(z) > 1e-10))

/usr/lib/python3/dist-packages/astropy_healpix/tests/test_healpy.py:118:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/hypothesis/core.py:519: in execute
result = self.test_runner(data, run)
/usr/lib/python3/dist-packages/hypothesis/executors.py:58: in
default_new_style_executor
return function(data)
/usr/lib/python3/dist-packages/hypothesis/core.py:517: in run
return test(*args, **kwargs)
/usr/lib/python3/dist-packages/astropy_healpix/tests/test_healpy.py:118:
in test_vec2pix
x=floats(-1, 1, allow_nan=False, allow_infinity=False).filter(lambda
x: abs(x) > 1e-10),
/usr/lib/python3/dist-packages/hypothesis/core.py:464: in test
result = self.test(*args, **kwargs)
/usr/lib/python3/dist-packages/astropy_healpix/tests/test_healpy.py:124:
in test_vec2pix
ipix1 = hp_compat.vec2pix(nside, x, y, z, nest=nest)
/usr/lib/python3/dist-packages/astropy_healpix/healpy.py:124: in vec2pix
theta = np.asscalar(theta)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

a = array([ 0.95531662])

@array_function_dispatch(_asscalar_dispatcher)
def asscalar(a):
"""
Convert an array of size 1 to its scalar equivalent.

.. deprecated:: 1.16

Deprecated, use `numpy.ndarray.item()` instead.

Parameters
--
a : ndarray
Input array of size 1.

Returns
---
out : scalar
Scalar representation of `a`. The output data type is the
same type
returned by the input's `item` method.

Examples

>>> np.asscalar(np.array([24]))
24

"""

# 2018-10-10, 1.16
warnings.warn('np.asscalar(a) is deprecated since NumPy v1.16, use '
> 'a.item() instead', DeprecationWarning, stacklevel=1)
E   DeprecationWarning: np.asscalar(a) is deprecated since NumPy
v1.16, use a.item() instead

/usr/lib/python3/dist-packages/numpy/lib/type_check.py:546:
DeprecationWarning
-- Hypothesis
--
Falsifying example: test_vec2pix(nside_pow=0, x=1.000827403713e-10,
y=1.000827403713e-10, z=1.000827403713e-10, nest=False)
__ test_vec2pix_shape
__

def test_vec2pix_shape():
>   ipix = hp_compat.vec2pix(8, 1., 2., 3.)

/usr/lib/python3/dist-packages/astropy_healpix/tests/test_healpy.p

Bug#918410: [qtcreator] qtcreator freezes during startup

[Johannes Zarl-Zierl]

Hello Bernhard,

Am Montag, 7. Jänner 2019, 01:00:13 CET schrieb Bernhard Übelacker:
> thanks for your fast respone.

You're welcome.

> Can you repeat that gdb command with following additional
> dbgsym packages installed, to complete the backtraces:
> 
> libxcb1-dbgsym libqt5gui5-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym
> libqt5dbus5-dbgsym libqt5core5a-dbgsym libglib2.0-0-dbgsym
> libgl1-mesa-dri-dbgsym libqt5qml5-dbgsym

Of course. See the attached log.

> If it shows up just sometimes you probably can describe your
> cpu and number of cores?

It's an Intel core 2 quad core processor. (See attached cpuinfo)

> Is it hanging too, if you start qtcreator with following command:
> 
> taskset -c 0 qtcreator

Yes.

Cheers,
  Johannes

Attaching to process 6830
[New LWP 6838]
[New LWP 6839]
[New LWP 6840]
[New LWP 6841]
[New LWP 6842]
[New LWP 6843]
[New LWP 6850]
[New LWP 6851]
[New LWP 6852]
[New LWP 6853]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f30b472bbe9 in __GI___poll (fds=fds@entry=0x7ffe6eb51908, nfds=nfds@entry=1, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29	../sysdeps/unix/sysv/linux/poll.c: Datei oder Verzeichnis nicht gefunden.

Thread 11 (Thread 0x7f3071ab4700 (LWP 6853)):
#0  0x7f30b472bbe9 in __GI___poll (fds=0x7f3064003ce0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
resultvar = 18446744073709551100
sc_cancel_oldtype = 0
sc_ret = 
#1  0x7f30b38cf016 in g_main_context_poll (priority=, n_fds=1, fds=0x7f3064003ce0, timeout=, context=0x7f3064000bf0) at ../../../glib/gmain.c:4221
ret = 
errsv = 
poll_func = 0x7f30b38de730 
poll_func = 
ret = 
errsv = 
#2  g_main_context_iterate (context=context@entry=0x7f3064000bf0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:3915
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 1
allocated_nfds = 1
fds = 0x7f3064003ce0
#3  0x7f30b38cf13c in g_main_context_iteration (context=0x7f3064000bf0, may_block=may_block@entry=1) at ../../../glib/gmain.c:3981
retval = 
#4  0x7f30b4e92153 in QEventDispatcherGlib::processEvents (this=0x7f3064000b20, flags=...) at kernel/qeventdispatcher_glib.cpp:422
d = 0x7f3064000b40
canWait = true
savedFlags = {i = 0}
result = 
#5  0x7f30b4e3f14b in QEventLoop::exec (this=this@entry=0x7f3071ab3e00, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:140
d = 0x7f3064004770
locker = {val = 93913471330160}
ref = {d = 0x7f3064004770, locker = @0x7f3071ab3d88, exceptionCaught = true}
app = 
#6  0x7f30b4c8e106 in QThread::exec (this=this@entry=0x5569ef192670) at ../../include/QtCore/../../src/corelib/global/qflags.h:120
d = 0x5569ef192700
locker = {val = 93913471330160}
eventLoop = { = {_vptr.QObject = 0x7f30b50c63c8 , static staticMetaObject = {d = {superdata = 0x0, stringdata = 0x7f30b4fc04e0 , data = 0x7f30b4fc03c0 , static_metacall = 0x7f30b4e70840 , relatedMetaObjects = 0x0, extradata = 0x0}}, d_ptr = {d = 0x7f3064004770}, static staticQtMetaObject = {d = {superdata = 0x0, stringdata = 0x7f30b4fc32a0 , data = 0x7f30b4fc0600 , static_metacall = 0x0, relatedMetaObjects = 0x0, extradata = 0x0}}}, static staticMetaObject = {d = {superdata = 0x7f30b50bea40 , stringdata = 0x7f30b4fbaf80 , data = 0x7f30b4fbaf20 , static_metacall = 0x7f30b4e3ee70 , relatedMetaObjects = 0x0, extradata = 0x0}}}
returnCode = 
#7  0x7f30b44e8375 in QQmlThreadPrivate::run (this=0x5569ef192670) at qml/ftw/qqmlthread.cpp:148
No locals.
#8  0x7f30b4c97cd7 in QThreadPrivate::start (arg=0x5569ef192670) at thread/qthread_unix.cpp:367
thr = 0x5569ef192670
data = 
eventDispatcher = 
__clframe = {__cancel_routine = 0x7f30b4c97200 , __cancel_arg = 0x5569ef192670, __do_it = 1, __cancel_type = }
#9  0x7f30b4b27fa3 in start_thread (arg=) at pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139846042208000, 5836240979638185000, 140730755782894, 140730755782895, 139846042208000, 0, -5864076587482649560, -5863942509390238680}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
#10 0x7f30b473689f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

Thread 10 (Thread 0x7f3072ffd700 (LWP 6852)):
#0  0x7f30b472bbe9 in __GI___poll (fds=0x7f306c004a00, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
resultvar = 18446744073709551100
sc_cancel_oldtype = 0
sc_ret = 
#1  0x7f30b38cf016 in g_main_context_poll (priority=, n_fds=1, fds=0x7f306c004a00, timeout=, context=0x7f306c000

Bug#918623: dizzy: Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT

[Bernhard Übelacker]

Package: dizzy
Version: 0.3-3
Severity: normal

Dear Maintainer,

this is the output of dizzy when started
on a desktop PC with amd graphics
or a qemu amd64 VM, both running current buster:

  $ dizzy
  GPU features: [x] GLSL [x] FBOs
  Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT, used at 
/usr/share/perl5/Dizzy/TextureGenerator.pm line 101.

I tested the same qemu VM with stretch and there it was working.
After some tests I found it stopped working when
libopengl-perl in version 0.7000+dfsg-1
entered testing in 2017-08-12.
But I am uncertain if the fault is
in package dizzy or libopengl-perl.

Kind regards,
Bernhard



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

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

Versions of packages dizzy depends on:
ii  libconvert-color-perl  0.11-2
ii  libopengl-perl 0.7000+dfsg-1+b1
ii  libsdl-perl2.548-1+b1
ii  perl   5.28.1-3

dizzy recommends no packages.

dizzy suggests no packages.

-- no debconf information

Bug#918624: openvpn: No password prompt under systemd

[Vlastimil Zima]

Package: openvpn
Version: 2.4.6-1
Severity: important

Dear Maintainer,

I have troubles using openvpn. I use private key protected by password,
but when I start openvpn through systemd:

sudo systemctl start openvpn@work.service

no password prompt is requested. When I start openvpn directly using

sudo openvpn --config /etc/openvpn/work.conf

everything works fine.

I'd expect the systemd to ask for password when I start the openvpn
service. It used to work for me before reinstall of computer some time
ago, but I'm not sure which version of openvpn I had.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  iproute2   4.19.0-2
ii  libc6  2.28-2
ii  liblz4-1   1.8.2-1
ii  liblzo2-2  2.10-0.1
ii  libpam0g   1.1.8-3.8
ii  libpkcs11-helper1  1.25.1-1
ii  libssl1.1  1.1.1a-1
ii  libsystemd0240-2
ii  lsb-base   10.2018112800

Versions of packages openvpn recommends:
ii  easy-rsa  3.0.5-1

Versions of packages openvpn suggests:
ii  openssl 1.1.1a-1
ii  resolvconf  1.79

-- Configuration Files:
/etc/default/openvpn changed [not included]

-- debconf information excluded

Bug#918621: Merge request

[Ondrej Novy]

MR: https://salsa.debian.org/lintian/lintian/merge_requests/116

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Alberto Bertogli]

On Sun, Jan 06, 2019 at 11:26:01PM +0100, Chris Lamb wrote:

[Adding albert...@blitiri.com.ar to CC]

Dear Santiago,


It is a "just in case". The offer to ssh into my machine is a blurb
which I now add to all my bug reports when the problem is "weird",
for example, when it does not seem to happen in buildd.debian.org or
reproducible-builds.


Awesome -- I just checking as it is somewhat unusual to receive
that offer and I was just 100% confirming before I potenaily spent
cycles on this and I was missing something..

I'm tempted to think that upstream (CC'd) might have an idea at this
stage...? :)


I don't!

libfiu doesn't particularly care for data persistency, there's not a 
single sync/fsync/etc. call.


But it could be a tight race in the build rules that eatmydata makes it 
more prone to manifest.


I'll follow up on the ssh offer separately and post my findings later. 
It could be a couple of weeks before I get time to do this though, as 
I'm away on holidays and this seems to be low priority.


Thanks!
Alberto

Bug#864440: xclip: Please package new upstream version 0.13

[Alessandro Ghedini]

On Sun, Dec 09, 2018 at 04:28:00PM -0500, Boyuan Yang wrote:
> X-Debbugs-CC: gh...@debian.org
> 
> Hi Alessandro,

Hello,

> On Thu, 08 Jun 2017 18:38:55 +0200 "W. Martin Borgert" <
> deba...@debian.org> wrote:
> > Package: xclip
> > Version: 0.12+svn84-4
> > Severity: wishlist
> > 
> > Upstream moved to github and published a new version:
> > https://github.com/astrand/xclip/releases/tag/0.13
> > "This release features several new features and bugfixes
> > done over the last 6 years. See ChangeLog for details."
> > I looks like the only Debian patch can be dropped then.
> 
> The new upstream release seems to be around for quite a few years. I'm
> wondering if you could make another upload before Buster release with
> new upstream version or make another upload without new upstream
> release to deal with existing bugs since xclip hasn't seen any upload
> for 4 years. Please let me know if NMU is okay to fix some obvious
> problems (Vcs-*, Homepage, etc).

If you are interested in maintaining xclip you are very welcome to join as
co-maintainer (or even only maintainer as I don't a whole lot of time to
dedicate to it).

The git repo is on salsa https://salsa.debian.org/debian/xclip so you are
welcome to do changes there.

CHeers


signature.asc
Description: PGP signature

Bug#918622: ruby-leaflet-rails FTBFS with rails 5.2

[Adrian Bunk]

Source: ruby-leaflet-rails
Version: 0.7.7-1
Severity: serious
Tags: ftbfs buster sid
Control: close -1 1.3.1-1

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-leaflet-rails.html

...
┌──┐
│ Run tests for ruby2.5 from debian/ruby-tests.rake│
└──┘

RUBYLIB=. 
GEM_PATH=debian/ruby-leaflet-rails/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
 ruby2.5 -S rake -f debian/ruby-tests.rake
/usr/bin/ruby2.5 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb --format 
documentation
config.eager_load is set to nil. Please update your config/environments/*.rb 
files accordingly:

  * development - set it to false
  * test - set it to false (unless you use a tool that preloads your test 
environment)
  * production - set it to true


An error occurred while loading ./spec/view_helpers_spec.rb.
Failure/Error: app.config.assets.precompile += %w(layers-2x.png layers.png 
marker-icon-2x.png marker-icon.png marker-shadow.png)

NoMethodError:
  undefined method `assets' for 
#
  Did you mean?  asset_host
# ./lib/leaflet-rails.rb:13:in `block in '
# ./spec/spec_helper.rb:31:in `'
# ./spec/view_helpers_spec.rb:1:in `'
No examples found.

Finished in 0.00066 seconds (files took 2.7 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples

/usr/bin/ruby2.5 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb --format 
documentation failed
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install 
/build/1st/ruby-leaflet-rails-0.7.7/debian/ruby-leaflet-rails returned exit 
code 1
make: *** [debian/rules:7: binary] Error 1



This is fixed in the package in experimental.

Bug#917861: NMU diff for kpatch 0.6.0-0.2

[Ben Hutchings]

I made an NMU fixing this and the other RC bug, plus a double-build
failure I noticed while preparing it.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


diff -Nru kpatch-0.6.0/debian/changelog kpatch-0.6.0/debian/changelog
--- kpatch-0.6.0/debian/changelog	2018-06-15 23:23:46.0 +0100
+++ kpatch-0.6.0/debian/changelog	2019-01-07 19:39:23.0 +
@@ -1,3 +1,13 @@
+kpatch (0.6.0-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * kmod: Fix symbol lookup on Linux 4.19 (Closes: #917861)
+  * dkms: Pass target kernel version to the upstream clean target
+(Closes: #917860)
+  * kpatch-build: Fix clean target
+
+ -- Ben Hutchings   Mon, 07 Jan 2019 19:39:23 +
+
 kpatch (0.6.0-0.1) unstable; urgency=medium
 
   [Simon Ruderich]
diff -Nru kpatch-0.6.0/debian/kpatch-dkms.dkms kpatch-0.6.0/debian/kpatch-dkms.dkms
--- kpatch-0.6.0/debian/kpatch-dkms.dkms	2018-06-15 23:23:46.0 +0100
+++ kpatch-0.6.0/debian/kpatch-dkms.dkms	2019-01-07 19:24:43.0 +
@@ -2,7 +2,7 @@
 BUILT_MODULE_NAME="kpatch"
 BUILT_MODULE_LOCATION="kmod/core"
 DEST_MODULE_LOCATION="/updates/dkms"
-CLEAN="make -C kmod/ clean"
+CLEAN="make -C kmod/ KPATCH_BUILD=/lib/modules/${kernelver}/build clean"
 PACKAGE_NAME="kpatch"
 PACKAGE_VERSION=#MODULE_VERSION#
 REMAKE_INITRD="no"
diff -Nru kpatch-0.6.0/debian/patches/kmod-fix-symbol-lookup-on-linux-4.19.patch kpatch-0.6.0/debian/patches/kmod-fix-symbol-lookup-on-linux-4.19.patch
--- kpatch-0.6.0/debian/patches/kmod-fix-symbol-lookup-on-linux-4.19.patch	1970-01-01 01:00:00.0 +0100
+++ kpatch-0.6.0/debian/patches/kmod-fix-symbol-lookup-on-linux-4.19.patch	2019-01-07 19:38:41.0 +
@@ -0,0 +1,41 @@
+From: Ben Hutchings 
+Date: Mon, 07 Jan 2019 19:19:42 +
+Subject: kmod: Fix symbol lookup on Linux 4.19
+
+Since Linux 4.19, symbols may contain either an absolute address or a
+self-relative offset, depending on
+CONFIG_HAVE_ARCH_PREL32_RELOCATIONS.  The function to resolve the
+address is unfortunately not inline or exported, so copy it here.
+
+Since the configuration symbol didn't exist before, we don't need to
+add an explicit kernel version check.
+
+---
+--- a/kmod/core/core.c
 b/kmod/core/core.c
+@@ -636,6 +636,16 @@ static int kpatch_find_object_symbol(con
+ 	return -EINVAL;
+ }
+ 
++/* Copied from kernel/module.c */
++static unsigned long kernel_symbol_value(const struct kernel_symbol *sym)
++{
++#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
++	return (unsigned long)offset_to_ptr(&sym->value_offset);
++#else
++	return sym->value;
++#endif
++}
++
+ /*
+  * External symbols are located outside the parent object (where the parent
+  * object is either vmlinux or the kmod being patched).
+@@ -651,7 +661,7 @@ static int kpatch_find_external_symbol(c
+ 	sym = find_symbol(name, NULL, NULL, true, true);
+ 	preempt_enable();
+ 	if (sym) {
+-		*addr = sym->value;
++		*addr = kernel_symbol_value(sym);
+ 		return 0;
+ 	}
+ 
diff -Nru kpatch-0.6.0/debian/patches/kpatch-build-fix-clean-target.patch kpatch-0.6.0/debian/patches/kpatch-build-fix-clean-target.patch
--- kpatch-0.6.0/debian/patches/kpatch-build-fix-clean-target.patch	1970-01-01 01:00:00.0 +0100
+++ kpatch-0.6.0/debian/patches/kpatch-build-fix-clean-target.patch	2019-01-07 19:38:19.0 +
@@ -0,0 +1,17 @@
+From: Ben Hutchings 
+Date: Mon, 07 Jan 2019 19:37:04 +
+Subject: kpatch-build: Fix clean target
+
+The clean target uses brace-expansion which is a bash extension not
+supported by e.g. dash.  Force use of bash for this target.
+
+---
+--- a/kpatch-build/Makefile
 b/kpatch-build/Makefile
+@@ -43,5 +43,6 @@ uninstall:
+ 	$(RM) -R $(LIBEXECDIR)
+ 	$(RM) $(BINDIR)/kpatch-build
+ 
++clean: SHELL = /bin/bash
+ clean:
+ 	$(RM) $(TARGETS) *.{o,d} insn/*.{o,d} gcc-plugins/*.{so,d}
diff -Nru kpatch-0.6.0/debian/patches/series kpatch-0.6.0/debian/patches/series
--- kpatch-0.6.0/debian/patches/series	2018-06-15 23:23:46.0 +0100
+++ kpatch-0.6.0/debian/patches/series	2019-01-07 19:38:32.0 +
@@ -1,2 +1,4 @@
 kpatch-build-adjust-dirs.patch
 Fix-build-err-by-Werror-maybe-uninitialized.patch
+kmod-fix-symbol-lookup-on-linux-4.19.patch
+kpatch-build-fix-clean-target.patch


signature.asc
Description: This is a digitally signed message part

Bug#851189: keyboard-configuration: ALT+Cursor-Left switches consoles instead of working on app in focus

[Samuel Thibault]

Mike McGuire, le lun. 07 janv. 2019 18:57:18 +, a ecrit:
> I did just try this myself and you're right, this didn't trigger it. Which 
> got me to think more of what could have and I did recently build wine in an 
> ubuntu chroot which is a plausible cause, I think?

That could have triggered running the keyboard-configuration indeed.

Which version of ubuntu is this?  I only have a 16.04 version under my
hand, and that does not contain the check for /lib/debian-installer.d
that the Debian package has since 2010, so it seems ubuntu dropped it
for some reason without taking enough care. The script does check for
$DISPLAY, but that won't work when running inside unattended-upgrade,
which runs out of X.

Samuel

Bug#918621: lintian: unnecessary-testsuite-autopkgtest-field with Testsuite: autopkgtest-python

[Ondřej Nový]

Package: lintian
Version: 2.5.119
Severity: normal

unnecessary-testsuite-autopkgtest-field is wrongly emited if d/tests/control
file exists and d/control have Testsuite: autopkgtest-python.

=== d/tests/control and not Testsuite field ===
# ls debian/tests/control
debian/tests/control
# grep 'Testsuite' debian/control
#
# lintian | grep unnecessary-testsuite-autopkgtest-field
#

CORRECT

=== d/tests/control and Testsuite: autopkgtest ===
# ls debian/tests/control
debian/tests/control
# grep 'Testsuite' debian/control
Testsuite: autopkgtest
# lintian | grep unnecessary-testsuite-autopkgtest-field
W: python-holidays source: unnecessary-testsuite-autopkgtest-field

CORRECT

=== d/tests/control and Testsuite: autopkgtest-python ===
# ls debian/tests/control
debian/tests/control
# grep 'Testsuite' debian/control
Testsuite: autopkgtest-pkg-python
# lintian | grep unnecessary-testsuite-autopkgtest-field
W: python-holidays source: unnecessary-testsuite-autopkgtest-field

WRONG

===

Thanks for fixing.

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-1
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

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

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#917303: Request for help with MariaDB 10.3 / libdbd-mysql-perl packaging

[Otto Kekäläinen]

Hello!

gregor herrmann  kirjoitti pe 4. tammikuuta 2019 klo
1.23:

> On Thu, 03 Jan 2019 22:04:48 +0200, Otto Kekäläinen wrote:
>
> > Just checking: are you Georg or Gregor currently working on this
> > issue, and do you have any estimate when we could expect either a
> > patch to MariaDB Connector C or a new upload of DBD-mysql so this
> > issue would be resolved?
>
> I had a look at DBD::mysql and DBD::MariaDB but without any success.
> I hope that someone with a better understanding than me from the
> Debian perl Group can try and find a solution.
>
> I've now pinged the upstream issue at:
> https://github.com/perl5-dbi/DBD-mysql/issues/275


Thanks Gregor for working with upstreams to fix this. Nice Eric Herman was
also involved ;)

Georg Richter, I hope you can review
https://github.com/MariaDB/mariadb-connector-c/pull/95 shortly, thanks!


>

Bug#918620: console-setup: autopkgtest delayed due to binary-all package not installable on amd64

[Adrian Bunk]

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

https://tracker.debian.org/pkg/console-setup

console-setup-freebsd/amd64 unsatisfiable Depends: vidcontrol
console-setup-freebsd/amd64 unsatisfiable Depends: kbdcontrol
uninstallable on arch amd64, autopkgtest delayed there
Required age increased by 40 days because of autopkgtest



That's due to an Architecture: all package that can only
be installed on *-kfreebsd.

Bug#850669: ansible: Enable python3

[Lee]

Hi everyone,

I uploaded ansible in experimental that now builds and runs via the python3
interpreter. Please test it extensively and report back any bugs/quirks you
find so I can document them in the NEWS file.

One thing I found until now is that py2 symantics in jinja2 templates don't
work anymore (like `for key, value in foo.iteritems()`), so that's one thing
to keep an eye out for.

At least once I was able to get ansible to break with a backtrace, but I
haven't been able to reproduce it since.

Greets,
Lee

Bug#918618: golang-github-grpc-ecosystem-grpc-gateway FTBFS: github.com/grpc-ecosystem/grpc-gateway/runtime [build failed]

[Adrian Bunk]

Source: golang-github-grpc-ecosystem-grpc-gateway
Version: 1.3.0-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-grpc-ecosystem-grpc-gateway.html

...
# github.com/grpc-ecosystem/grpc-gateway/runtime_test 
[github.com/grpc-ecosystem/grpc-gateway/runtime.test]
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:71:46: too few 
values in &wrappers.FloatValue literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:72:47: too few 
values in &wrappers.DoubleValue literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:73:46: too few 
values in &wrappers.Int64Value literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:74:46: too few 
values in &wrappers.Int32Value literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:75:47: too few 
values in &wrappers.UInt64Value literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:76:47: too few 
values in &wrappers.UInt32Value literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:77:45: too few 
values in &wrappers.BoolValue literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:78:47: too few 
values in &wrappers.StringValue literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:118:46: too 
few values in &wrappers.FloatValue literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:119:47: too 
few values in &wrappers.DoubleValue literal
src/github.com/grpc-ecosystem/grpc-gateway/runtime/query_test.go:119:47: too 
many errors
FAILgithub.com/grpc-ecosystem/grpc-gateway/runtime [build failed]
?   github.com/grpc-ecosystem/grpc-gateway/runtime/internal [no test files]

Bug#918366: FTBFS for armhf on arm64, fails some tests

[Yavor Doganov]

Steve McIntyre wrote:
> On Mon, Jan 07, 2019 at 06:24:23PM +, Steve McIntyre wrote:
> >On Sun, Jan 06, 2019 at 10:38:55AM +0200, Yavor Doganov wrote:
> >>
> >>I see that libffi was also built on arm-arm-01.  It would help a lot
> >>if you can retry the gnustep-base build with libffi built on armhf.
> >
> >I'll see what I can do.
> 
> No joy I'm afraid. I've just built libffi on the armhf porter box
> (abel), installed all the packages in my chroot, rebuilt and tested
> again and:
> 
> ...
> base/NSInvocation/general.m:
> Failed test: general.m:208 ... Can send/return NSRect

OK, thanks a lot.

Can you run the test under gdb (it's already compiled and the binary
should be Tests/base/NSInvocation/obj/general), put a break at line
207 and print rret, rarg and rprx?  I suppose one of these is a zero
rect, or more likely, garbage.

Bug#918619: golang-github-go-errors-errors FTBFS with Go 1.11

[Adrian Bunk]

Source: golang-github-go-errors-errors
Version: 1.0.1-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-go-errors-errors.html

...
=== RUN   TestStackFormat
--- FAIL: TestStackFormat (0.00s)
error_test.go:33: Stack trace does not contain source line: 'a: b(5)'
error_test.go:34: 
/build/1st/golang-github-go-errors-errors-1.0.1/obj-x86_64-linux-gnu/src/github.com/go-errors/errors/error_test.go:21
 (0x4f5f35)
TestStackFormat.func1: e, expected := Errorf("hi"), callers()
/usr/lib/go-1.11/src/runtime/asm_amd64.s:522 (0x455b3b)
call32: CALLFN(·call32, 32)
/usr/lib/go-1.11/src/runtime/panic.go:513 (0x429df9)
gopanic: reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), 
uint32(d.siz), uint32(d.siz))

/build/1st/golang-github-go-errors-errors-1.0.1/obj-x86_64-linux-gnu/src/github.com/go-errors/errors/error_test.go:245
 (0x4f38ff)
TestStackFormat: panic('a')
/usr/lib/go-1.11/src/testing/testing.go:827 (0x4b573f)
tRunner: fn(t)
/usr/lib/go-1.11/src/runtime/asm_amd64.s:1333 (0x4576d1)
goexit: BYTE$0x90   // NOP
...

Bug#918617: wml: Apparent wrong usage of DEB_TARGET_*

[Guillem Jover]

Source: wml
Version: 2.12.0~ds1-4
Severity: normal

Hi!

I noticed while reading the latest changelog entry that this package
is using DEB_TARGET_* variables, which seems incorrect. These are
intended to be used when building cross-compilers, not for general
cross-compiling.

I've skimmed over the packaging, and it appears to me you should be
using DEB_HOST_* instead? Please refer to the dpkg-architecture(1)
man page for further details on the intended usage of each of these
variables. :)

Thanks,
Guillem

Bug#913674: Preparing p-u upload

[Hilko Bengen]

Hi Adam,

> That's rather large for a regression fix.

Agreed. I had previously tried fixing the patch that broke Yubikey NEO
support, but I was unsuccessful. This is documented in #910786.

I can understand concerns about updating the upstream version; the only
other option I see would involve removing one if not all patches that
were added in opensc/0.16.0-3+deb9u1 -- and re-introducing CVE-worthy
bugs.

I had the impression that updating to a new upstream version was a done
deal. Quoting yourself
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913674#10):

,
| Firstly, one needs to identify whether the same issue affects the
| package in unstable.
| 
| Once it's been confirmed that unstable is no{t, longer} affected,
| someone should produce a fixed package and open a p-u bug to document
| uploading that to proposed-updates.
`

Part 1 is done: I can attest that the version in unstable (0.19.0-1) is
NOT affected by the Yubikey NEO issue.

Part 2 is also basically done, I was just asking for advice on what to
include in the changelog.

Cheers,
-Hilko

Bug#917210: RM: revelation -- RoQA; unmaintained, depends on gnome-python

[Jeremy Bicha]

Control: severity -1 normal
Control: tags -1 -sid -buster
Control: retitle -1 RM: revelation -- RoQA; unmaintained, depends on 
gnome-python
Control: reassign -1 ftp.debian.org

Please remove revelation from Debian.

Thank you,
Jeremy Bicha

Bug#918141: RE: [Pkg-samba-maint] Bug#918141: samba-common: samba-tool domain provision fails due to missing ad-schema files

[Andreas Boland]

Ahh, this was missing!

Sorry for opening this as a bug.

Bug#918366: FTBFS for armhf on arm64, fails some tests

[Steve McIntyre]

On Mon, Jan 07, 2019 at 06:24:23PM +, Steve McIntyre wrote:
>On Sun, Jan 06, 2019 at 10:38:55AM +0200, Yavor Doganov wrote:
>>
>>I see that libffi was also built on arm-arm-01.  It would help a lot
>>if you can retry the gnustep-base build with libffi built on armhf.
>>If it succeeds it would certainly mean that the problem is in libffi.
>>Otherwise, it may well be a GNUstep bug which we'll need to
>>investigate somehow.
>
>I'll see what I can do.

No joy I'm afraid. I've just built libffi on the armhf porter box
(abel), installed all the packages in my chroot, rebuilt and tested
again and:

...
base/NSInvocation/general.m:
Failed test: general.m:208 ... Can send/return NSRect
--- Running tests in base/NSInvocationOperation ---
--- Running tests in base/NSJSONSerialization ---
...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone