Bug#916279: qemu-system-common: Overwrite /usr/share/doc-base/qemu-system-doc without declaring replacement

[Michael Tokarev]

24.12.2018 6:00, Andreas Beckmann wrote:

Followup-For: Bug #916279
Control: found -1 1:3.1+dfsg-2

Hi,

you are missing a
   Breaks: qemu-system-data (<< 1:3.1+dfsg-1~)
to match the Replaces, otherwise you are permitting partial
upgrade/downgrade paths where files are disappearing whil
dpkg considers everything correctly installed.


it doesn't really break the package in question. All these
packages will be of the same version anwyway, upgraded in
one go, at the very max there will be some docs missing
for a (short) while, until the next apt run.

More, it's just one version which were like that during the
buster development cycle.

Besides, *this* bug is fixed, it does declare a replacement :)

I don't think this bug needs to be acted upon more.  At least
I don't plan a new upload at least before it is migrated to
testing, as time is already too short and this very bug, a
stupid mistake, already took more time than necessary.

Thanks,

/mjt

Bug#917210: revelation: Intent to remove from Debian

[Jeremy Bicha]

Source: revelation
Version: 0.4.14-3
Severity: serious
Tags: buster sid

revelation was removed from Testing a year ago because it depends on
gnome-python and libgnome. relevation is now one of the blockers for
completing the removal of those unmaintained libraries from Debian.
Therefore, I intend to file a removal bug for revelation soon.

Please respond immediately to let me know if you agree to or object to
this removal.

References
--
https://bugs.debian.org/790601
https://lists.debian.org/debian-devel/2018/11/msg00570.html

Thanks,
Jeremy Bicha

Bug#915354: ITA: sent -- simple plaintext presentation tool

[eamanu15]

Hi Dmitry!

Sorry for the delay (holidays issues :-) )

I've just upload `sent` to mentors

https://mentors.debian.net/package/sent

Please, when you have time review it.

Thanks!
Regards!


El jue., 20 de dic. de 2018 a la(s) 15:03, Dmitry Bogatov (
kact...@debian.org) escribió:

>
> [2018-12-19 07:10] eamanu15 
> > *ping Dmitry :-)*
> >
> > I uploaded *sent* to mentors.d.o, but *sent* does not appear on m.d.o =(
>
> mentors.debian.net, you mean?
>
> > And I need permissions on salsa.
>
> I see. Could you please resolve issue with mentors? I'd like to sponsor
> at least one upload before transfering ownership. It would help to have
> repository, that is fast-forwardable from salsa:debian/sent.
>
> Nothing personal, we just never worked together.
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#790584: gjots2: depends on python-gnome2 which is deprecated

[Jeremy Bicha]

Control: tags -1 +pending

I have uploaded gjots2 3.0.2-0.1 to the DELAYED/15 queue. Please let
me know if I should speed up or slow down this upload.

I submitted my packaging to https://github.com/leggewie-DM/gjots2/pulls

Thanks,
Jeremy Bicha

Bug#917124: udev 240-1 break my system too

[John Wong]

On 12/24/18 12:58 PM, John Wong wrote:
> Yes, udev 240-1 break my lvm2 system.
>
Hi, replace /lib/systemd/systemd-udevd with udev version 239's
(/lib/systemd/systemd-udevd), then update-initramfs -u.

I can boot my system again.

-- 
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC

Bug#917209: llvm-toolchain-7: please include upstream commit rL342725 (review D52340) needed by rust

[Ximin Luo]

Source: llvm-toolchain-7
Version: 1:7.0.1-2
Severity: important
Tags: patch upstream

Dear Maintainer,

Please include this upstream commit, which is already merged in trunk but not 
7.0.1.

https://reviews.llvm.org/D52340

The patch is attached to this bug report for convenience, it needs to be
applied with -p2 and then refreshed.

It is needed by latest versions of rustc, otherwise some debuginfo/lto-related
tests will segfault in the test suite.

See https://github.com/rust-lang/rust/issues/54614 for other discussion.

X

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Index: llvm/trunk/lib/Bitcode/Reader/MetadataLoader.cpp
===
--- llvm/trunk/lib/Bitcode/Reader/MetadataLoader.cpp
+++ llvm/trunk/lib/Bitcode/Reader/MetadataLoader.cpp
@@ -1313,7 +1313,7 @@
(Context, Tag, Name, File, Line, Scope, BaseType,
 SizeInBits, AlignInBits, OffsetInBits, Flags,
 Elements, RuntimeLang, VTableHolder, 
TemplateParams,
-Identifier));
+Identifier, Discriminator));
 if (!IsNotUsedInTypeRef && Identifier)
   MetadataList.addTypeRef(*Identifier, *cast(CT));
 
Index: llvm/trunk/test/Assembler/debug-variant-discriminator.ll
===
--- llvm/trunk/test/Assembler/debug-variant-discriminator.ll
+++ llvm/trunk/test/Assembler/debug-variant-discriminator.ll
@@ -0,0 +1,14 @@
+; RUN: llvm-as < %s | llvm-dis | llvm-as | llvm-dis | FileCheck %s
+; RUN: verify-uselistorder %s
+
+; CHECK: !named = !{!0, !1, !2}
+!named = !{!0, !1, !2}
+
+; CHECK: !0 = !DICompositeType(tag: DW_TAG_structure_type, name: "Outer", 
size: 64, align: 64, identifier: "Outer")
+; CHECK-NEXT: !1 = !DICompositeType(tag: DW_TAG_variant_part, scope: !0, size: 
64, discriminator: !2)
+; CHECK-NEXT: !2 = !DIDerivedType(tag: DW_TAG_member, scope: !1, baseType: !3, 
size: 64, align: 64, flags: DIFlagArtificial)
+; CHECK-NEXT: !3 = !DIBasicType(name: "u64", size: 64, encoding: 
DW_ATE_unsigned)
+!0 = !DICompositeType(tag: DW_TAG_structure_type, name: "Outer", size: 64, 
align: 64, identifier: "Outer")
+!1 = !DICompositeType(tag: DW_TAG_variant_part, scope: !0, size: 64, 
discriminator: !2)
+!2 = !DIDerivedType(tag: DW_TAG_member, scope: !1, baseType: !3, size: 64, 
align: 64, flags: DIFlagArtificial)
+!3 = !DIBasicType(name: "u64", size: 64, encoding: DW_ATE_unsigned)

Bug#917124: udev 240-1 break my system too

[John Wong]

Yes, udev 240-1 break my lvm2 system.

--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC

Bug#913852: RM: xword -- RoQA; depends on unmaintained gnome-python-desktop

[Jeremy Bicha]

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

Please remove xword from Debian.

Thank you,
Jeremy Bicha

Bug#881506: xul-ext-gnome-keyring doesn't work with firefox >=57

[Jeremy Bicha]

On Mon, Nov 19, 2018 at 5:20 PM Moritz Mühlenhoff  wrote:
> On Mon, Nov 19, 2018 at 07:22:11AM -0500, Jeremy Bicha wrote:
> > > Given that Xul is still supported in Thunderbird, let maybe drop the 
> > > support for
> > > Firefox/Iceweasel (with a NOTE telling people how to migrate their 
> > > existing
> > > secrets) and upgrade to 0.13?
> >
> > While upgrading to 0.13 would fix one problem, it still wouldn't be
> > able to reach Testing since it depends on libgnome-keyring which is
> > being removed from Debian. See https;//bugs.debian.org/892358
>
> And actually, it's also broken on Thunderbird; I installed it and
> the addon manager in Thunderbird has greyed it out with a message
> stating that it's incompatible with 60.3.
>
> Let's remove it from unstable and stretch?
>
> Cheers,
> Moritz

Ximin, it's been a month with no response. Please reply immediately.
Otherwise, we'll file removal bugs soon.

I see in comment 30 that you are no longer using this extension so
maybe removal is best.

Thanks,
Jeremy Bicha

Bug#914111: RM: liblunar -- RoQA; unused library, depends on pygtksourceview

[Jeremy Bicha]

Control: severity -1 normal
Control: tags -1 -sid -buster
Control: retitle -1 RM: liblunar -- RoQA; unused library, depends on 
pygtksourceview
Control: reassign -1 ftp.debian.org

Please remove liblunar from Debian.

Thank you,
Jeremy Bicha

Bug#917166: Errors on and after upgrade to 2.03.01-2, swap on lvm not mounted

[Piotr Jurkiewicz]

After downgrading udev and libudev1 to 239-15, swap volume is mounted 
properly on boot.


"lvm2-activation-generator: lvmconfig failed" is still produced on boot, 
but only once and seems not to break anything.


Thanks.

Bug#780364: [Pkg-sysvinit-devel] Bug#780364: The problem disappeared, when I removed /etc/adjtime file and rebooted

[Ben Hutchings]

On Fri, 2018-12-21 at 18:54 +, Dmitry Bogatov wrote:
[...]
>  * checking of /usr in `checkfs.sh' is performed by `fsck -A'. Any
>ideas, how should we tell it to skip /usr?

We already do that since:

commit 155bf5e08de00125ba2612834e74751793a363d5
Author: Ben Hutchings 
Date:   Sun Jan 17 04:16:23 2016 +

Add support for mount and fsck of root and /usr by an initramfs

>One possible approach is that if sixth field in `/etc/fstab' is `0',
>`fsck -A' will ignore corresponding file system, but who have
>responsiblity to set it?

The pass number in /etc/fstab *must not* be changed, as initramfs-tools 
will also not run fsck if it is 0.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.




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

Bug#917208: automake: maintainer-clean fails to clean dependencies

[Aiden Woodruff]

Package: automake
Version: 1:1.15-6
Severity: normal
Tags: upstream

Dear Maintainer,

While creating a directory structure similar to the below:

project/
|-- Makefile.am
|-- configure.ac, etc.
+-- src/
|-- Makefile.am
|-- source.cc
|-- source.h
+-- main.cc
+-- test/
|-- Makefile.am
|-- thousand.cc
+-- thousand.sh

Where source defined a class, main ran the main program, and thousand ran a 
test program directly interfacing with it.
thousand.sh was added to the check_SCRIPTS and TESTS, and running `make check` 
ran correctly.
However, running forms of `make *-clean` that removed the .deps folder caused 
error.
When the test Makefile is accessing .Po files in the src directory, they've 
already been deleted by the src Makefile.

I get this error:
  make[1]: Entering directory '/home/user/project/test'
  Makefile:517: ../src/.deps/source.Po: No such file or directory
  make[1]: *** No rule to make target '../src/.deps/source.Po'.  Stop.
  make[1]: Leaving directory '/home/user/project/test'
  Makefile:341: recipe for target 'maintainer-clean-recursive' failed
  make: *** [maintainer-clean-recursive] Error 1

Line 517 is:
  include ../src/$(DEPDIR)/grid.Po

I attempted switching the order of SUBDIRS, and both pass the check but neither 
clean correctly. However, when test/ is first, it removes src/.deps thus 
preventing src/Makefile to include the .Po file.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.6 (stretch)
Release:9.6
Codename:   stretch
Architecture: armv7l

Kernel: Linux 4.9.35-v7+ (SMP w/4 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)

Versions of packages automake depends on:
ii  autoconf   2.69-10
ii  autotools-dev  20161112.1

automake recommends no packages.

Versions of packages automake suggests:
pn  autoconf-doc   
pn  gnu-standards  

-- no debconf information

Bug#916773: r-base: CRAN packages fail to install.

[Dirk Eddelbuettel]

Emmanuel,

We have not found anything genuinely reproducible. With that there is little
we can do here.

I don't doubt that you had an issue. It's just that sometimes repompilation
_is_ necessary.

Best,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#897806: lmms: ftbfs with GCC-8

[Boyuan Yang]

PS: My email sent to *@jasp.net keeps bouncing; I received

550 The message does not meet the trust level of one recipient at least
See http://www.jasp.net/smtp/trust.xhtml
Administrative prohibition

I don't know if you could receive my email but at least you may view the
archived version on https://bugs.debian.org/897806 .

--
Thanks,
Boyuan Yang

Boyuan Yang  于2018年12月24日周一 上午11:42写道：
>
> Hi Javier,
>
> > I asked for an upload two weeks ago.
>
> Are you referring to any request for upload in Debian? I couldn't find
> the place where you asked any upload in Debian, either on
> mentors.debian.net or https://bugs.debian.org/sponsorship-requests .
> Could you provide a reference to it, especially an URL for the source
> package?
>
> I am willing to review and sponsor a upload that either migrates lmms
> to Qt5, fixes FTBFS with gcc-8 or provides other fixes.
>
> --
> Thanks,
> Boyuan Yang

Bug#913116: Needs to depend on chromium-sandbox

[Michael Gilbert]

On Mon, Dec 17, 2018 at 4:40 AM Bastian Blank wrote:
> > Since this can be used in place of chromium's setuid binary, my
> > opinion is that the Depends relationship on chromium-sandbox is no
> > longer required.
>
> Nope, at least if the package is supposed to work without admin
> intervention.

Debian policy does not (currently) demand this for dependency relationships.

Policy states that dependencies represent other packages that are
required for the first to work correctly.  In this case, since
chromium can be set up to work correctly without chromium-sandbox
installed, it thus does not need to be considered a dependency.
Whether or not the set requires administrator intervention is
consequently not relevant, at least with respect to the statement
policy makes about this.

Best wishes,
Mike

Bug#916279: qemu-system-common: Overwrite /usr/share/doc-base/qemu-system-doc without declaring replacement

[Andreas Beckmann]

Followup-For: Bug #916279
Control: found -1 1:3.1+dfsg-2

Hi,

you are missing a 
  Breaks: qemu-system-data (<< 1:3.1+dfsg-1~)
to match the Replaces, otherwise you are permitting partial
upgrade/downgrade paths where files are disappearing while
dpkg considers everything correctly installed.


Andreas

Bug#802539: Please properly configure HTTPS in security.debian.org

[Brian Minton]

Package: security.debian.org
Followup-For: Bug #802539

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I've also seen this error via ipv6:

# curl -Iv https://security.debian.org
*   Trying 2001:4f8:1:c::14...
* TCP_NODELAY set
* Connected to security.debian.org (2001:4f8:1:c::14) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
  * TLSv1.3 (OUT), TLS handshake, Client hello (1):
  * TLSv1.3 (IN), TLS handshake, Server hello (2):
  * TLSv1.2 (IN), TLS handshake, Certificate (11):
  * TLSv1.2 (OUT), TLS alert, unknown CA (560):
  * SSL certificate problem: self signed certificate in certificate
  * chain
  * Closing connection 0
  curl: (60) SSL certificate problem: self signed certificate in
  certificate chain
  More details here: https://curl.haxx.se/docs/sslcerts.html

  curl failed to verify the legitimacy of the server and therefore could
  not
  establish a secure connection to it. To learn more about this
  situation and
  how to fix it, please visit the web page mentioned above.

This should probably go to debian-...@lists.debian.org too.

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

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

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQT5xLt2Dng/DewQpoprjrOgZc+6qQUCXCBJiAAKCRBrjrOgZc+6
qWECAP0ekr+Kcj2byMmpGuLL1y7C/LyCGBR82p/XKF4XVYs7bQD7BOnG5XdBrBkr
2atOmYq03M1D+f0D/65yA4nGQ3dg+O2IdQQBFggAHRYhBO7QFYAT3C5tbgAepDe5
UHrP8gFuBQJcIEmQAAoJEDe5UHrP8gFuf2cBAKGwzY9k6dsRusmrWnez7jOvHo66
Og2Z7uO8KJ1FJvTqAP9r7jn8zvrzpbcUmtd9tJLwH5aprmGe88PQpVMAJ5g0CA==
=dFKz
-END PGP SIGNATURE-

Bug#910251: libpsm2 bug #910485 appears solved for mpgrafic builds - supports closing #910251

[Boud Roukema]

hi all

There was an FTBFS bug #911941 for mpgrafic on 17 and 27 October 2018, which 
were clearly
only because of libpsm2 bug #910485 reporting a timeout to stdout:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910485

The reproducible builds of mpgrafic since then look OK:

https://tests.reproducible-builds.org/debian/history/mpgrafic.html

and commit 3aa6558 for libpsm2 says that an upstream fix is now in debian 
11.2.68-4

https://salsa.debian.org/hpc-team/libpsm2/commit/3aa65581753f79bc09ab776aa89c27e4df7a1877

Bug #910485 has now been closed.

The mpgrafic builds provide circumstantial evidence supporting the
closing of openmpi bug #910251 .

Cheers
Boud

Bug#917207: nanoc: depends on higher version of ruby-adsf

[Ruben]

Package: nanoc
Version: 4.11.0-1
Severity: normal

The "nanoc view" command gives an error and from what I see, the reason
is that it requires a more recent version of ruby-adsf.  Currently only
version 1.2.1 of ruby-adsf is available, and it seems the version should
be at least 1.3.0.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (600, 'testing'), (110, 'unstable'), (80, '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=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nanoc depends on:
ii  pry 0.12.2-1
ii  ruby1:2.5.1
ii  ruby-addressable2.5.2-1
ii  ruby-adsf   1.2.1+dfsg1-1
ii  ruby-brandur-json-schema0.19.1-1
ii  ruby-cri2.15.2-1
ii  ruby-ddmemoize  1.0.0-1
ii  ruby-ddmetrics  1.0.1-1
ii  ruby-ddplugin   1.0.2-1
ii  ruby-listen 3.1.5-1
ii  ruby-parallel   1.12.1-2
ii  ruby-slow-enumerator-tools  1.1.0-1
ii  ruby-tomlrb 1.2.7-1
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.4-1

Versions of packages nanoc recommends:
ii  asciidoc-base   8.6.10-3
pn  asciidoctor 
ii  ruby-builder3.2.3-1
pn  ruby-coffee-script  
ii  ruby-erubi  1.7.1-1
ii  ruby-erubis 2.7.0-3
ii  ruby-haml   4.0.7-1
ii  ruby-hamster3.0.0-2
ii  ruby-kramdown   1.17.0-1
ii  ruby-maruku 0.7.3-1
ii  ruby-mime-types 3.2.2-1
ii  ruby-mustache   1.0.2-1
ii  ruby-nokogiri   1.8.4-1
ii  ruby-nokogumbo  1.4.2+ds-1+b5
ii  ruby-rdiscount  2.1.8-1+b5
ii  ruby-redcarpet  3.4.0-4+b1
ii  ruby-redcloth   4.3.2-3+b1
ii  ruby-ref2.0.0-1
ii  ruby-rouge  3.2.1-1
ii  ruby-rubypants  0.6.0-1
ii  ruby-sass   3.5.3-1
ii  ruby-slim   3.0.7-1
pn  ruby-uglifier   

Versions of packages nanoc suggests:
pn  coderay | ruby-pygments.rb | python-pygments | highlight  
ii  git   1:2.19.2-1
ii  rsync 3.1.2-2.2
pn  ruby-fog  
ii  ruby-rack 1.6.4-6

-- no debconf information

Bug#915721: transition: opencv

[Mo Zhou]

On Wed, Dec 19, 2018 at 11:32:36AM +0100, Emilio Pozuelo Monfort wrote:
> I was going to ack this, but I noticed that opencv failed to build on some
> architectures:
> 
> https://buildd.debian.org/status/package.php?p=opencv=experimental
> 
> Please look at that before we start this.

opencv was given-back on armel several days ago.  minkus (mips) cannot
reproduce the FTBFS on mips so I assume the reason is similar to armel,
so I'll give-back it later. eller (mipsel/mips64el) has successfully
built the opencv package, although buildd still hasn't started the build
yet.

Can we move on without waiting for mipsel and mips64el? The buildd
scheduler puts too small a weight for experimental distribution...

Bug#917206: linux-image-4.9.0-8-amd64: NULL ptr dereference in xhci_hub_control [xhci_hcd] with USB Mass Storage (Kingston)

[Cyril Brulebois]

Package: src:linux
Version: 4.9.135-1
Severity: important

Hi kernel team,

I've reproduced this kernel BUG a few times already, with simple
operations on various USB devices like brand new Kingston DataTraveler
3.0 (8, 16 or 32GB):

[ 1992.998316] BUG: unable to handle kernel NULL pointer dereference at 
001c
[ 1992.998372] IP: [] xhci_hub_control+0x19cf/0x1c10 
[xhci_hcd]


Steps to reproduce:
 - plug a USB device either on an port of the laptop's base, or on the
   USB3 port on the laptop;
 - zero out the /dev/sd? that pops up when the USB device is inserted,
   to make sure any preexisting partitioning is no factor (did that on
   the full device first time, then decided to only wipe out the
   beginning of the block device);
 - partprobe to make extra sure;
 - create a partition table with fdisk (not sure I did anything
   specific here, can double check, probably went for the default);
 - create a single partition with all free space;
 - assign type 'b' (W95 FAT32) to it;
 - use mkfs.vfat -F 32 on the new block device.

At this point, said block device appears in Xfce's file manager, Thunar.
With or without having copied a few files to it, clicking the “eject”
button is sufficient to trigger this BUG. When that happens, input
devices work for a few seconds but it isn't possible to get much done;
an already-running dmesg -w wouldn't show any traces. Only an UEFI
glitch at reboot time would make half a screen appear with a fuzzied
trace…

Here's a capture obtained through netconsole, enabled a bit before
triggering the crash:

[ 1745.198739] console [netcon_ext0] disabled
[ 1745.198753] console [netcon0] disabled
[ 1748.295633] netpoll: netconsole: local port 6665
[ 1748.295637] netpoll: netconsole: local IPv4 address 0.0.0.0
[ 1748.295639] netpoll: netconsole: interface 'eth0'
[ 1748.295640] netpoll: netconsole: remote port 
[ 1748.295642] netpoll: netconsole: remote IPv4 address 192.168.0.1
[ 1748.295644] netpoll: netconsole: remote ethernet address 
d8:cb:8a:98:29:59
[ 1748.295647] netpoll: netconsole: local IP 192.168.0.21
[ 1748.295702] console [netcon0] enabled
[ 1748.295704] netconsole: network logging started
[ 1799.971353] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[ 1800.002355] usb 2-2: New USB device found, idVendor=0951, idProduct=1666
[ 1800.002373] usb 2-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 1800.002380] usb 2-2: Product: DataTraveler 3.0
[ 1800.002386] usb 2-2: Manufacturer: Kingston
[ 1800.002392] usb 2-2: SerialNumber: 60A44C413BF2F270B62830FF
[ 1800.017208] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 1800.017367] scsi host3: usb-storage 2-2:1.0
[ 1801.020259] scsi 3:0:0:0: Direct-Access Kingston DataTraveler 3.0
  PQ: 0 ANSI: 6
[ 1801.021997] sd 3:0:0:0: Attached scsi generic sg1 type 0
[ 1801.022211] sd 3:0:0:0: [sdb] 30218842 512-byte logical blocks: (15.5 
GB/14.4 GiB)
[ 1801.022788] sd 3:0:0:0: [sdb] Write Protect is off
[ 1801.022819] sd 3:0:0:0: [sdb] Mode Sense: 4f 00 00 00
[ 1801.023312] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: 
enabled, doesn't support DPO or FUA
[ 1801.026302]  sdb: sdb1
[ 1801.027383] sd 3:0:0:0: [sdb] Attached SCSI removable disk
[ 1884.87] device eth0 left promiscuous mode
[ 1901.864615]  sdb: sdb1
[ 1939.154007] usb 2-2: USB disconnect, device number 4
[ 1941.618308] usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd
[ 1941.649852] usb 2-2: New USB device found, idVendor=0951, idProduct=1666
[ 1941.649863] usb 2-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 1941.649866] usb 2-2: Product: DataTraveler 3.0
[ 1941.649869] usb 2-2: Manufacturer: Kingston
[ 1941.649872] usb 2-2: SerialNumber: 60A44C413BF2F270B62830FF
[ 1941.659124] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 1941.659303] scsi host3: usb-storage 2-2:1.0
[ 1942.682536] scsi 3:0:0:0: Direct-Access Kingston DataTraveler 3.0
  PQ: 0 ANSI: 6
[ 1942.683352] sd 3:0:0:0: [sdb] 30218842 512-byte logical blocks: (15.5 
GB/14.4 GiB)
[ 1942.683356] sd 3:0:0:0: Attached scsi generic sg1 type 0
[ 1942.683517] sd 3:0:0:0: [sdb] Write Protect is off
[ 1942.683525] sd 3:0:0:0: [sdb] Mode Sense: 4f 00 00 00
[ 1942.683714] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: 
enabled, doesn't support DPO or FUA
[ 1942.687527]  sdb: sdb1
[ 1942.688360] sd 3:0:0:0: [sdb] Attached SCSI removable disk
[ 1978.720932]  sdb: sdb1
[ 1984.327018]  sdb: sdb1
[ 1984.414750]  sdb: sdb1
[ 1984.587241]  sdb: sdb1
[ 1992.998123] usb 2-2: USB disconnect, device number 5
[ 1992.998316] BUG: unable to handle kernel NULL pointer dereference at 
001c
[ 1992.998372] IP: [] xhci_hub_control+0x19cf/0x1c10 
[xhci_hcd]
[ 1992.998418] PGD 0 [ 1992.998433] 
[ 

Bug#917205: dh-fortran-mod: must not act on arch:all packages

[Andreas Beckmann]

Package: dh-fortran-mod
Version: 0.7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects: src:openmpi

Hi,

during a test with piuparts I noticed the postrm snippets inserted by
your package cause errors.

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

  Purging configuration files for openmpi-common (3.1.3-6) ...
  rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15': 
No such file or directory
  dpkg: error processing package openmpi-common (--purge):
   installed openmpi-common package post-removal script subprocess returned 
error exit status 1

This was a test on i386, openmpi-common is an arch:all package
built on amd64. As an arch:all package it must not contain
arch-specific stuff.

Why is anything inserted into the maintainer scripts anyway if
there are no fortran mods at all in the package?


There could be another bug as can be seen in libopenmpi3:amd64:

  Purging configuration files for libopenmpi3:amd64 (3.1.3-6) ...
  rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15': 
No such file or directory
  dpkg: error processing package libopenmpi3:amd64 (--purge):
   installed libopenmpi3:amd64 package post-removal script subprocess returned 
error exit status 1

I don't know if this was built against dh-fortran-mod 0.6 and
should be fixed by rebuilding against 0.7 ...


src:openmpi will need a sourceful upload to rebuild the arch:all
packages against a fixed dh-fortran-mod, again.

And *PLEASE* do *source-only* uploads unless you have something
that needs to go through NEW.


cheers,

Andreas

*not amused*

Bug#917114: ansible: crashes when trying to read vault variables

[Harlan Lieberman-Berg]

On Sat, Dec 22, 2018 at 4:06 PM Yvan Masson  wrote:
> Using testing, Ansible crashes when trying to read vault variables. I
> see this issue since Ansible 2.6 at least.

Interesting!  Can you try to reproduce this with `LC_ALL=C LANG=C` ?

Also, do you get the same error when you run the command without the
verbosity flags? That error appears to be a unicode string problem
related to some debug output.

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#568897: [debhelper-devel] Bug#568897: Bug#568897: debhelper: DEB_BUILD_OPTIONS=nocheck should prevent override_dh_auto_test rule to be run

[Harlan Lieberman-Berg]

Hello all!

Just pinging this again for reconsideration.  I ran into this
recently, and copy/pasting bits of makefile throughout various
packages' debian/rules seems like the wrong solution to me.

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#917202: lm-sensors: Ability to install both libsensors4 and libsensors5?

[Aurelien Jarno]

control: reassign -1 collectd
control: retitle -1 collectd should be updated for libsensors5
control: severity -1 serious

On 2018-12-24 01:11, Xavier Guerrin wrote:
> Package: lm-sensors
> Version: 1:3.5.0-3
> Severity: normal
> 
> Dear Maintainer,
> 
> It does not seem possible to install both libsensors4 and libsensors5 as
> "apt install libsensors5" will remove libsensors4. This is apparently due to
> libsensors-config, which is marked as breaking and replacing libsensors4.

True.

> Alas, this package does not effectively replace libsensors4 since it no longer
> provides libsensors.so.4. This has the side-effect of breaking collectd's
> "sensors" plugin, which relies on libsensors.so.4:
>   $ dpkg -L collectd-core | grep sensors
>   /usr/lib/collectd/sensors.so
>   $ ldd /usr/lib/collectd/sensors.so
>   linux-vdso.so.1 (0x7ffe949f2000)
>   libsensors.so.4 => not found
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc8b4c44000)
>   /lib64/ld-linux-x86-64.so.2 (0x7fc8b4e21000)

This is clearly a bug of collectd which should be updated to use
libsensors5. I am therefore reassigning the bug to this package.

> Another option is to remove libsensors5.. but doing so removes lxqt (through
> lxqt-panel, which explicitly depends on libsensors5).
 
> Is there a significant impediment preventing libsensors4 and libsensors5 from
> living together on the same system?

Yes, bug #915873 which causes the sensors.conf configuration file to be
lost during the upgrade:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915873

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#917204: openbox: undecorated maximized windows have a top border

[Valentin Blot]

Package: openbox
Version: 3.6.1-7
Severity: normal
Tags: patch

When rc.xml contains yes, undecorated maximized
windows still have a top border. A comment in the source code (see 
patch)

justifies this by the fact that the client menu needs to be accessible.
However, the client menu is inaccessible anyway when keepBorder is set 
to "no".
Moreover, the left, right and bottom borders are hidden and it makes 
more
sense to hide the top one as well. This top border is also annoying in 
several
circumstances (e.g. in order to click on a tab in firefox you have to be 
bellow

the top of the screen so you need to be precise with the mouse).Description: Removed top border on undecorated maximized windows
 .
 openbox (3.6.1-7custom) unstable; urgency=medium
 .
   * Removed top border on maximized undecorated windows.
Author: Val 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2018-12-23

--- openbox-3.6.1.orig/openbox/frame.c
+++ openbox-3.6.1/openbox/frame.c
@@ -585,12 +585,6 @@ void frame_adjust_area(ObFrame *self, gb
 
 if (self->decorations & OB_FRAME_DECOR_TITLEBAR)
 self->size.top += ob_rr_theme->title_height + self->bwidth;
-else if (self->max_horz && self->max_vert) {
-/* A maximized and undecorated window needs a border on the
-   top of the window to let the user still undecorate/unmaximize the
-   window via the client menu. */
-self->size.top += self->bwidth;
-}
 
 if (self->decorations & OB_FRAME_DECOR_HANDLE &&
 ob_rr_theme->handle_height > 0)

Bug#917188: radicale: configuration changes for FreedomBox

[Jonas Smedegaard]

Hi James,

Quoting James Valleroy (2018-12-23 21:42:05)
> Currently, FreedomBox makes the following changes to 
> /etc/radicale/config:

Thanks for this bugreport. Very helpful!


> 1. Sets server/hosts to '127.0.0.1:5232, [::1]:5232'.

It is not recommended to use the built-in web service for production.

Debian package ships with uWSGI configuration ready to use, and 
documentation for using that has recently been updated: Please check if 
that is usable for FreedomBox.


> 2. Sets server/base_prefix to '/radicale/'.

with uWSGI, you can declare prefix in a Apache vhost snippet - see 
example snippet shipped with Radicale in unstable.

Please test and tell if it works - I use Radicale only at the root of a 
dedicated vhost.


> 3. Sets well-known/caldav to '/radicale/%(user)s/caldav/'.
> 4. Sets well-known/carddav to '/radicale/%(user)s/carddav/'.

I believe this is no longer needed with Radicale 2.x - please file bugs 
if something like this is needed.


> 5. Sets rights/type to 'owner_only'.

Radicale in unstable use 'from_file' by default, with rights file 
configured similar to owner_only.

Suggestions welcome for improved default setup of rights file.


> Note that rights/type can be further configured through plinth. It can 
> be set to 'owner_only', 'owner_write', or 'authenticated'.

Don't have Plinth edit conffiles ever - it *CANNOT* work reliably!

All Radicale configfiles are currently (and previously too) conffiles.

Here is one way to have adaptable Radicale configuration without risking 
questions during upgrade, for Buster:

 1. Copy radicale files to somewhere under Plinth control:
* /etc/radicale/* → /etc/plinth/radicale/*
* /etc/uwsgi/*/radicale.conf → /etc/uwsgi/*/radicale_plinth.conf
 2. Edit the copied files to use each other
 3. Edit the copied files for the needed adaption
 4. When Plinth is asked to change a setting, do steps 1-3.
 5. When radicale package is updated, do steps 1-3.

I guess step 5 is done with a dpkg trigger, but I have no experience 
with that.

If you want Radicale to offer debconf handling of auth type, then please 
file a separate bugreport to discuss that specifically.  Beware that in 
my experience user-friendly CalDAV/CardDAV clients (read: Apple ical) 
can only make use of "ower_only"-style auth types - only crude clients 
(read: Lightning) can use more "creative" auth types.  I am therefore 
hesitant to spending time making that configurable.  But if needed, 
please file a bugreport and try convince me :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#917203: FTBFS on at least two architectures: test failure in the enigma algorithm

[Steve McIntyre]

Package: src:libmcrypt
Version: 2.5.8-3.3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!

I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild is to identify packages that
might have problems with this configuration.

While doing this, I found that libmcrypt failed its test suite for
armel running on arm64:

...
Algorithm: enigma... failed compatibility
Expected: f3edda7da20f8975884600f014d32c7a08e59d7b
Got: 216540d5d71ec2d57f626a5609a3ebedbb9b32e4
...

I've tested on amd64 and things look fine, but building for arm64 on
arm64 also fails with exactly the same test failure as armel-on-arm64.

Full log at

  
https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/libmcrypt_2.5.8-3.3_armel.log

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 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)

Bug#917166: Errors on and after upgrade to 2.03.01-2, swap on lvm not mounted

[Cesare Leonardi]

On Sun, 23 Dec 2018 15:58:50 +0100 Piotr Jurkiewicz 
 wrote:
On two machines running sid I observed errors during the upgrade to 
2.03.01-2. One of these machines became practically unusable immediately 
after the update (disk IO operations became so slow that even closing 
aptitude took 2 minutes instead usual 3 seconds, I had to reboot it). On 
second machine I observed the same errors in log, but without the 
slowdown (maybe because it was RAID-based).


I suggest you to read this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917124

Probably your boot problems are due to an udev 240 bug and while waiting 
for a solution you'd better to downgrade udev to 239. I've done it using 
snapshot.debian.org.



After the update, both machines generate errors on boot:

Dec 23 15:41:16 sonata lvm2-activation-generator: lvmconfig failed
Dec 23 15:41:16 sonata lvm2-activation-generator: Activation generator 
failed.


These messages are another problem and I've resolved reading this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917164

Cesare.

Bug#917202: lm-sensors: Ability to install both libsensors4 and libsensors5?

[Xavier Guerrin]

Package: lm-sensors
Version: 1:3.5.0-3
Severity: normal

Dear Maintainer,

It does not seem possible to install both libsensors4 and libsensors5 as
"apt install libsensors5" will remove libsensors4. This is apparently due to
libsensors-config, which is marked as breaking and replacing libsensors4.
Alas, this package does not effectively replace libsensors4 since it no longer
provides libsensors.so.4. This has the side-effect of breaking collectd's
"sensors" plugin, which relies on libsensors.so.4:
  $ dpkg -L collectd-core | grep sensors
  /usr/lib/collectd/sensors.so
  $ ldd /usr/lib/collectd/sensors.so
  linux-vdso.so.1 (0x7ffe949f2000)
  libsensors.so.4 => not found
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc8b4c44000)
  /lib64/ld-linux-x86-64.so.2 (0x7fc8b4e21000)

Another option is to remove libsensors5.. but doing so removes lxqt (through
lxqt-panel, which explicitly depends on libsensors5).

Is there a significant impediment preventing libsensors4 and libsensors5 from
living together on the same system?

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 lm-sensors depends on:
ii  libc62.28-3
ii  libsensors5  1:3.5.0-3
ii  lsb-base 10.2018112800
ii  perl 5.28.1-3
ii  sed  4.7-1

lm-sensors recommends no packages.

Versions of packages lm-sensors suggests:
pn  fancontrol  
pn  i2c-tools   
pn  read-edid   

-- no debconf information

Bug#917201: FTBFS: '%s' directive output may be truncated warning with -Werror

[Steve McIntyre]

Package: src:libkqueue
Version: 2.0.3-1.1
Severity: important
Tags: ftbfs

Doing a rebuild on arm64, I saw the following failure:

/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.   
-Wdate-time -D_FORTIFY_SOURCE=2 -I./src/common -I./include -Wall -Wextra 
-Wno-missing-field-initializers -Werror -g -O2 -std=c99 -D_XOPEN_SOURCE=600 
-fvisibility=hidden -g -O2 
-fdebug-prefix-map=/home/steve/debian/build/kqueue/libkqueue-2.0.3=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
src/common/libkqueue_la-kevent.lo `test -f 'src/common/kevent.c' || echo 
'./'`src/common/kevent.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I./src/common -I./include -Wall -Wextra -Wno-missing-field-initializers 
-Werror -g -O2 -std=c99 -D_XOPEN_SOURCE=600 -fvisibility=hidden -g -O2 
-fdebug-prefix-map=/home/steve/debian/build/kqueue/libkqueue-2.0.3=. 
-fstack-protector-strong -Wformat -Werror=format-security -c 
src/common/kevent.c  -fPIC -DPIC -o src/common/.libs/libkqueue_la-kevent.o
src/common/kevent.c: In function 'kevent_dump':
src/common/kevent.c:107:37: error: '%s' directive output may be truncated 
writing up to 1023 bytes into a region of size between 931 and 1004 
[-Werror=format-truncation=]
src/common/kevent.c:98:28:
 return ((const char *) [0]);
~~~   
src/common/kevent.c:107:37:
 "{ ident=%d, filter=%s, %s, %s, data=%d, udata=%p }",
 ^~
src/common/kevent.c:107:13: note: using the range [-2147483648, 2147483647] for 
directive argument
 "{ ident=%d, filter=%s, %s, %s, data=%d, udata=%p }",
 ^~~~
cc1: all warnings being treated as errors

I can reporiduce just the same on amd64. Using -Werror with newere
compilers...

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 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)

Bug#917164: "lvm2-activation-generator: lvmconfig failed" message at boot time

[Cesare Leonardi]

On Sun, 23 Dec 2018 15:36:25 +0100 Xavier Guerrin  
wrote:

I investigated why and what follows are my strace-based conclusions.
As you probably know already, lvm2-activation-generator runs:
  /sbin/lvmconfig global/event_activation global/use_lvmpolld
After the latest lvm2 upgrade, it turns out /etc/lvm/lvm.conf does *not* contain
event_activation in its global section.
Therefore, lvmconfig:
  - outputs "Configuration node global/event_activation not found" on stderr;
  - outputs "use_lvmpolld=1" on stdout;
  - exits with return code 1, hence the reported error.


Excellent bug report Xavier! It was really helpful for me.

I can confirm that setting "event_activation=1" solves all these 
"lvm2-activation-generator: lvmconfig failed" messages.


That option is missing from the Debian setup but is present and enabled 
upstream, as showed by this command:

lvmconfig --typeconfig default --withcomments

Cesare.

Bug#917200: pyside2: build-dependencies no longer satisfiable on mips64el.

[peter green]

Package: pyside2
Version: 5.11.2-1
Severity: serious

It seems that patchelf has been removed on mips64el due to testsuite failures, 
but pyside2 still bulid-depends on it. So pyside cannot be built on mips64el 
anymore.

Possible fixes (in roughly descending order of preferences)
1. Fix the testsuite failures in patchelf
2. Break the dependency chain (I notice the patchelf build-dependency was only 
added recently, is it mandatory?)
3. Request removal of the pyside2 binaries on mips64el

Bug#917199: pivy, unbuildable on mips* due to testsuite failures in patchelf.

[peter green]

Package: pivy
Version: 0.6.4-1
Severity: serious

pivy cannot be built on mips/mipsel because of a depedency on pyside2 which is 
not built on mips/mipsel pyside2 is not being built on those architectures due 
to a dependency on patchelf. patchelf is not currently building on mips* due to 
a testsuite failure.

mips64el also looks like it will become a problem going forward as patchelf is 
not currently available there (but was at the time pyside2 was last built).

Possible solutions (in roughly descending order of preference):

1. Fix the patchelf testsuite failures.
2. Break the dependency chain (only possible if the functionality in question 
is optional, I have not researched that).
3. Request removal of the mips* binaries for pivy and reverse dependencies of 
pivy (if-any).

Bug#916708: python-wicd: misleading error message "Bad password"

[Vincent Lefevre]

On 2018-12-17 19:08:32 +0100, Vincent Lefevre wrote:
> On some wireless network with authentication, I systematically got an
> error "Bad password". Thus I spent hours trying to find the problem
> related to my password, with the impossibility to find the cause of
> this issue.
> 
> With the wpasupplicant upgrade last week-end, it made clear that the
> issue (solved with this upgrade) was not the password, but the TLS
> version.
> 
> This error message should be changed to "Authentication failed" (which
> covers more issues than just a bad password), or something similar.

FYI, this error can also occur when the quality of the wifi is
too low, so that one internally gets an early disconnection.
Nothing related to a bad password!

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

Bug#917197: nullmailer: tests/smtp-auth fails randomly on mips64el

[David Bremner]

Source: nullmailer
Version: 1:2.2-2
Severity: serious
Justification: ftbfs

The mentioned tests seems to fail about 10-20% of the time. I'm not
sure if it's really architecture specific, or just a race condition
that didn't happen on the other buildd's.  When it does fail the test
'Testing auth login success with smtp' fails with exit code
141. AFAIU, that means ../protocols/smtp is getting a SIGPIPE.


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

Kernel: Linux 4.18.0-3-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

-- debconf information excluded

Bug#917198: wpasupplicant: wpa_cli_open_connection does not initializes errno to 0

[Vincent Lefevre]

Package: wpasupplicant
Version: 2:2.6-21
Severity: minor

In wpa_supplicant/wpa_cli.c, wpa_cli_open_connection is expected to
set errno (at least in case of error), as it is used in

if (!global &&
wpa_cli_open_connection(ctrl_ifname, 0) < 0) {
fprintf(stderr, "Failed to connect to non-global "
"ctrl_ifname: %s  error: %s\n",
ctrl_ifname ? ctrl_ifname : "(nil)",
strerror(errno));
return -1;
}

Thus wpa_cli_open_connection should start by setting errno to 0,
to make sure that one does not get an error message that comes
from a previous, unrelated error. Currently this is what would
happen when ifname == NULL.

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

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

Versions of packages wpasupplicant depends on:
ii  adduser   3.118
ii  libc6 2.28-3
ii  libdbus-1-3   1.12.12-1
ii  libnl-3-200   3.4.0-1
ii  libnl-genl-3-200  3.4.0-1
ii  libpcsclite1  1.8.24-1
ii  libreadline7  7.0-5
ii  libssl1.1 1.1.1a-1
ii  lsb-base  10.2018112800

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

Bug#917103: dh_elpa_test: test bytecompilability

[David Bremner]

Sean Whitton  writes:

> In addition to running upstream test suites, dh_elpa_test could test
> whether the package's elisp can be bytecompiled against the version of
> Emacs in sid -- Emacs is already a hard dependency of dh-elpa.
>
> This would catch certain classes of bugs earlier.

1) What do you think about the idea of adding something like a
   "DESDTDIR" to the generated emacsen-common scripts, then running the
   generated emacsen-install file with DESTDIR=/tmp/something. That
   would be slightly risky in the sense that every time we touch
   maintainer scripts there is the potential for user suffering.

2) Should this be done by dh_elpa_test, or by dh_elpa? I can imagine
   that we might disable upstream test suites but still want to run the
   byte compilation.

d

Bug#917193: wpasupplicant: missing newline character in error message

[Vincent Lefevre]

On 2018-12-23 23:51:41 +0100, Vincent Lefevre wrote:
> I got the following error (via wicd logs):
> 
> 2018/12/23 22:11:27 :: wpa_cli -i wlp61s0 terminate
> Failed to connect to non-global ctrl_ifname: wlp61s0  error: No such file or 
> directory
> 
> This should have been:
> 
> Failed to connect to non-global ctrl_ifname: wlp61s0
> error: No such file or directory

wpa_supplicant/wpa_cli.c contains:

if (!global &&
wpa_cli_open_connection(ctrl_ifname, 0) < 0) {
fprintf(stderr, "Failed to connect to non-global "
"ctrl_ifname: %s  error: %s\n",
ctrl_ifname ? ctrl_ifname : "(nil)",
strerror(errno));
return -1;
}

If the goal is to keep the error on the same line, the separator
should be clearer (not just spaces). Or the "error: %s" part could
be surrounded by parentheses.

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

Bug#917194: Acknowledgement (dgit: typo in dgit(7))

[David Bremner]

Oops, it's dgit(1) that thas the problem, not dgit(7).

Bug#917196: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

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

Hi! We are *almost* ready to go ahead with the last Qt transition for Buster.

This time is a simple pure-bugfixes release, to the point that we need it only
for qtbase: qtdeclarative should just work.

It would be great if you could set up the transition page so I can check rdeps
easily. I'll of course ping this bug when we are ready to start the transition.

Ben file:

title = "qtbase-opensource-src";
is_affected = .depends ~ "qtbase-abi-5-11-2" | .depends ~ "qtbase-abi-5-11-3";
is_good = .depends ~ "qtbase-abi-5-11-3";
is_bad = .depends ~ "qtbase-abi-5-11-2";


Thanks!


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

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

Bug#870094: problems with stretch gqrx-sdr

[Matt Taggart]

I am seeing a similar problem as the original reporter of #870094. I'm 
on stretch, gqrx-sdr version 2.6-1+b1. The output I get when running it is:


==
$ gqrx
linux; GNU C++ version 6.3.0 20170221; Boost_106200; 
UHD_003.009.005-0-unknown


Controlport disabled
No user supplied config file. Using "default.conf"
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf 
bladerf rfspace airspy soapy redpitaya

FM demod gain: 1.52789
IQ DCR alpha: 1.04166e-05
terminate called after throwing an instance of 
'boost::exception_detail::clone_impl 
>'

  what():  send_to: Operation not permitted
Aborted
==

The original submitter included some strace output that seemed to 
indicate a missing boost library (libboost_date_time) which is different 
than what I am seeing.

(maybe mine is a permissions issue? does the user need to be in any groups)


ldd output
==
$ ldd /usr/bin/gqrx
linux-vdso.so.1 (0x7ffc88be9000)
	libQt5Network.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Network.so.5 
(0x7f19816e9000)
	libQt5Svg.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Svg.so.5 
(0x7f1981693000)
	libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f1980fab000)
	libboost_program_options.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.62.0 
(0x7f1980d2c000)
	libgnuradio-runtime.so.3.7.10 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10 (0x7f1980a29000)
	libgnuradio-pmt.so.3.7.10 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-pmt.so.3.7.10 (0x7f19807d4000)
	libgnuradio-analog.so.3.7.10 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-analog.so.3.7.10 (0x7f198053b000)
	libvolk.so.1.3 => /usr/lib/x86_64-linux-gnu/libvolk.so.1.3 
(0x7f19801d3000)
	libgnuradio-audio.so.3.7.10 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-audio.so.3.7.10 (0x7f197ff7f000)
	libgnuradio-blocks.so.3.7.10 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-blocks.so.3.7.10 (0x7f197fa86000)
	libgnuradio-digital.so.3.7.10 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-digital.so.3.7.10 (0x7f197f732000)
	libgnuradio-fft.so.3.7.10 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-fft.so.3.7.10 (0x7f197f502000)
	libgnuradio-filter.so.3.7.10 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-filter.so.3.7.10 (0x7f197f215000)
	libgnuradio-osmosdr.so.0.1.4 => 
/usr/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so.0.1.4 (0x7f197ef1e000)
	libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 
(0x7f197eccd000)
	libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 
(0x7f197eac8000)
	libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 
(0x7f197e465000)
	libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 
(0x7f197df2c000)
	libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 
(0x7f197da5d000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f197d6db000)

libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f197d3d7000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f197d1c)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f197ce21000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f197cc04000)

libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f197c9ea000)
	libproxy.so.1 => /usr/lib/x86_64-linux-gnu/libproxy.so.1 
(0x7f197c7c9000)

librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f197c5c1000)
	libboost_date_time.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.62.0 (0x7f197c3b)
	libboost_filesystem.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7f197c197000)
	libboost_regex.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_regex.so.1.62.0 (0x7f197be7e000)
	libboost_thread.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.62.0 (0x7f197bc56000)
	libboost_chrono.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.62.0 (0x7f197ba4f000)
	libboost_atomic.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_atomic.so.1.62.0 (0x7f197b84d000)
	liblog4cpp.so.5 => /usr/lib/x86_64-linux-gnu/liblog4cpp.so.5 
(0x7f197b60f000)
	libfftw3f.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f.so.3 
(0x7f197b201000)
	libfftw3f_threads.so.3 => 
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3 (0x7f197affa000)

libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f197adf6000)
	liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 
(0x7f197ab78000)
	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 
(0x7f197a86b000)

libjack.so.0 => /usr/lib/x86_64-linux-gnu/libjack.so.0 
(0x7f197a624000)
	libportaudio.so.2 => /usr/lib/x86_64-linux-gnu/libportaudio.so.2 
(0x7f197a3f5000)

/lib64/ld-linux-x86-64.so.2 (0x7f1981659000)
	

Bug#917195: FTBFS on mips(el): expected ‘dev_t *’ {aka ‘long long unsigned int *’} but argument is of type ‘long unsigned int *’

[Michael Biebl]

Source: systemd
Version: 240-1
Severity: serious
User: debian-m...@lists.debian.org
Usertags: mipsel mips
Forwarded: https://github.com/systemd/systemd/issues/11247

The latest upstream release of systemd fails to build on mips/mipsel
with the following error message:

[346/1708] cc -Isrc/core/2ac6ece@@core@sta -Isrc/core -I../src/core
-Isrc/basic -I../src/basic -Isrc/shared -I../src/shared -Isrc/systemd
-I../src/systemd -Isrc/journal -I../src/journal -Isrc/journal-remote
-I../src/journal-remote -Isrc/nspawn -I../src/nspawn -Isrc/resolve
-I../src/resolve -Isrc/timesync -I../src/timesync
-I../src/time-wait-sync -Isrc/login -I../src/login -Isrc/udev
-I../src/udev -Isrc/libudev -I../src/libudev -I../src/libsystemd/sd-bus
-I../src/libsystemd/sd-device -I../src/libsystemd/sd-event
-I../src/libsystemd/sd-hwdb -I../src/libsystemd/sd-id128
-I../src/libsystemd/sd-netlink -I../src/libsystemd/sd-network
-I../src/libsystemd/sd-resolve -Isrc/libsystemd-network
-I../src/libsystemd-network -I. -I../ -I/usr/include/libmount
-I/usr/include/blkid -I/usr/include/uuid -flto
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99
-Wextra -Werror=undef -Wlogical-op -Wmissing-include-dirs
-Wold-style-definition -Wpointer-arith -Winit-self -Wfloat-equal
-Wsuggest-attribute=noreturn -Werror=missing-prototypes
-Werror=implicit-function-declaration -Werror=missing-declarations
-Werror=return-type -Werror=incompatible-pointer-types -Werror=format=2
-Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn
-Wimplicit-fallthrough=5 -Wshadow -Wendif-labels -Wstrict-aliasing=2
-Wwrite-strings -Werror=overflow -Werror=shift-count-overflow
-Werror=shift-overflow=2 -Wdate-time -Wnested-externs
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wno-format-signedness -Wno-error=nonnull -Wno-maybe-uninitialized
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-fvisibility=hidden -fstack-protector -fstack-protector-strong
--param=ssp-buffer-size=4 -fPIE -ffunction-sections -fdata-sections
-Werror=shadow -include config.h -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread
-MD -MQ 'src/core/2ac6ece@@core@sta/cgroup.c.o' -MF
'src/core/2ac6ece@@core@sta/cgroup.c.o.d' -o
'src/core/2ac6ece@@core@sta/cgroup.c.o' -c ../src/core/cgroup.c FAILED:
src/core/2ac6ece@@core@sta/cgroup.c.o cc -Isrc/core/2ac6ece@@core@sta
-Isrc/core -I../src/core -Isrc/basic -I../src/basic -Isrc/shared
-I../src/shared -Isrc/systemd -I../src/systemd -Isrc/journal
-I../src/journal -Isrc/journal-remote -I../src/journal-remote
-Isrc/nspawn -I../src/nspawn -Isrc/resolve -I../src/resolve
-Isrc/timesync -I../src/timesync -I../src/time-wait-sync -Isrc/login
-I../src/login -Isrc/udev -I../src/udev -Isrc/libudev -I../src/libudev
-I../src/libsystemd/sd-bus -I../src/libsystemd/sd-device
-I../src/libsystemd/sd-event -I../src/libsystemd/sd-hwdb
-I../src/libsystemd/sd-id128 -I../src/libsystemd/sd-netlink
-I../src/libsystemd/sd-network -I../src/libsystemd/sd-resolve
-Isrc/libsystemd-network -I../src/libsystemd-network -I. -I../
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid -flto
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99
-Wextra -Werror=undef -Wlogical-op -Wmissing-include-dirs
-Wold-style-definition -Wpointer-arith -Winit-self -Wfloat-equal
-Wsuggest-attribute=noreturn -Werror=missing-prototypes
-Werror=implicit-function-declaration -Werror=missing-declarations
-Werror=return-type -Werror=incompatible-pointer-types -Werror=format=2
-Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn
-Wimplicit-fallthrough=5 -Wshadow -Wendif-labels -Wstrict-aliasing=2
-Wwrite-strings -Werror=overflow -Werror=shift-count-overflow
-Werror=shift-overflow=2 -Wdate-time -Wnested-externs
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wno-format-signedness -Wno-error=nonnull -Wno-maybe-uninitialized
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-fvisibility=hidden -fstack-protector -fstack-protector-strong
--param=ssp-buffer-size=4 -fPIE -ffunction-sections -fdata-sections
-Werror=shadow -include config.h -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread
-MD -MQ 'src/core/2ac6ece@@core@sta/cgroup.c.o' -MF
'src/core/2ac6ece@@core@sta/cgroup.c.o.d' -o
'src/core/2ac6ece@@core@sta/cgroup.c.o' -c ../src/core/cgroup.c
../src/core/cgroup.c: In function ‘lookup_block_device’:
../src/core/cgroup.c:405:59: error: passing argument 3 of 
‘device_path_parse_major_minor’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 r = device_path_parse_major_minor(p, _mode, _rdev);
   ^~~
In file included from ../src/core/cgroup.c:22:
../src/basic/stat-util.h:87:78: note: expected ‘dev_t *’ {aka ‘long long 
unsigned int *’} but 

Bug#917194: dgit: typo in dgit(7)

[David Bremner]

Package: dgit
Version: 8.1
Severity: minor

Line 370 of the formatted man page has a .TP in it that looks like it
doesn't belong.


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

Kernel: Linux 4.18.0-3-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 dgit depends on:
ii  apt 1.8.0~alpha2
ii  ca-certificates 20170717
ii  coreutils   8.30-1
ii  curl7.62.0-1
ii  devscripts  2.18.10
ii  dpkg-dev1.19.2
ii  dput-ng [dput]  1.21
ii  git [git-core]  1:2.19.2-1
ii  git-buildpackage0.9.12
pn  libdigest-sha-perl  
ii  libdpkg-perl1.19.2
ii  libjson-perl4.0-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblocale-gettext-perl  1.07-3+b4
ii  libtext-glob-perl   0.10-1
ii  libtext-iconv-perl  1.7-5+b7
ii  libwww-perl 6.36-1
ii  perl5.28.1-3

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.9p1-4

Versions of packages dgit suggests:
ii  sbuild  0.77.1-2

-- no debconf information

Bug#917193: wpasupplicant: missing newline character in error message

[Vincent Lefevre]

Package: wpasupplicant
Version: 2:2.6-21
Severity: minor

I got the following error (via wicd logs):

2018/12/23 22:11:27 :: wpa_cli -i wlp61s0 terminate
Failed to connect to non-global ctrl_ifname: wlp61s0  error: No such file or 
directory

This should have been:

Failed to connect to non-global ctrl_ifname: wlp61s0
error: No such file or directory

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

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

Versions of packages wpasupplicant depends on:
ii  adduser   3.118
ii  libc6 2.28-3
ii  libdbus-1-3   1.12.12-1
ii  libnl-3-200   3.4.0-1
ii  libnl-genl-3-200  3.4.0-1
ii  libpcsclite1  1.8.24-1
ii  libreadline7  7.0-5
ii  libssl1.1 1.1.1a-1
ii  lsb-base  10.2018112800

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

Bug#917192: rustc: Please include patch to fix C ABI on sparc64

[John Paul Adrian Glaubitz]

On 12/23/18 10:55 PM, John Paul Adrian Glaubitz wrote:
> I'm attaching the patch. With the patches from #916818, #917000
> and #917191, the testsuite failures on sparc64 drop to 9 for me.

Minor update to the patch, the commit text contained a wrong reference
to the SPARC Compliance Specification. The correct version number
is 2.4.1, not 4.2.1

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 65dabd6eaf24bbf3b7069a51984411aea2864856 Mon Sep 17 00:00:00 2001
From: Michael Karcher 
Date: Sun, 23 Dec 2018 20:33:52 +0100
Subject: [PATCH] librustc_codegen_llvm: Don't eliminate empty structs in C ABI
 on linux-sparc64

This is in accordance with the SPARC Compliance Definition 2.4.1,
Page 3P-12. It says that structs of up to 8 bytes (which applies
to empty structs as well) are to be passed in one register.
---
 src/librustc_codegen_llvm/abi.rs | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/librustc_codegen_llvm/abi.rs b/src/librustc_codegen_llvm/abi.rs
index b8954dee79..c083137f08 100644
--- a/src/librustc_codegen_llvm/abi.rs
+++ b/src/librustc_codegen_llvm/abi.rs
@@ -456,6 +456,9 @@ impl<'tcx> FnTypeExt<'tcx> for FnType<'tcx, Ty<'tcx>> {
 let linux_s390x = target.target_os == "linux"
&& target.arch == "s390x"
&& target.target_env == "gnu";
+let linux_sparc64 = target.target_os == "linux"
+   && target.arch == "sparc64"
+   && target.target_env == "gnu";
 let rust_abi = match sig.abi {
 RustIntrinsic | PlatformIntrinsic | Rust | RustCall => true,
 _ => false
@@ -526,8 +529,9 @@ impl<'tcx> FnTypeExt<'tcx> for FnType<'tcx, Ty<'tcx>> {
 if arg.layout.is_zst() {
 // For some forsaken reason, x86_64-pc-windows-gnu
 // doesn't ignore zero-sized struct arguments.
-// The same is true for s390x-unknown-linux-gnu.
-if is_return || rust_abi || (!win_x64_gnu && !linux_s390x) {
+// The same is true for s390x-unknown-linux-gnu
+// and sparc64-unknown-linux-gnu.
+if is_return || rust_abi || (!win_x64_gnu && !linux_s390x && !linux_sparc64) {
 arg.mode = PassMode::Ignore;
 }
 }
-- 
2.20.1

Bug#897806: lmms: ftbfs with GCC-8

[Javier Serrano Polo]

I asked for an upload two weeks ago.

smime.p7s
Description: S/MIME cryptographic signature

Bug#901289: breaks boot in containers

[Adam Borowski]

Uh oh...  looks like the logsave issue suddenly became RCish: it prevents
lxc containers from booting unattended:

mordor:[~]# lxc-start -F -n durthang
INIT: version  booting

   OpenRC 0.39 is starting up Linux 4.18.0-0.bpo.3-amd64 (x86_64) [LXC]

 * /proc is already mounted
 * Mounting /run ... * /run/openrc: creating directory
 * /run/lock: creating directory
 * /run/lock: correcting owner
 * Caching service dependencies ... [ ok ]
Setting the system clock.
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --verbose option to see the details of our search for an 
access method.
Unable to set System Clock to: Sun Dec 23 21:54:59 UTC 2018 ... (warning).
Activating swap...done.
Checking file systems.../etc/init.d/checkfs.sh: 94: /etc/init.d/checkfs.sh: 
logsave: not found
failed (code 127).
File system check failed. A log is being saved in /var/log/fsck/checkfs if that 
location is writable. Please repair the file system manually. ... failed!
A maintenance shell will now be started. CONTROL-D will terminate this shell 
and resume system boot. ... (warning).
Give root password for maintenance
(or press Control-D to continue): 


Host: stretch, guest: unstable.
So we need to fix this one way or another...


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917192: rustc: Please include patch to fix C ABI on sparc64

[John Paul Adrian Glaubitz]

Source: rustc
Version: 1.31.0+dfsg1-2
Severity: normal
Tags: upstream patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

The Rust compiler misses some special handling for empty structs in
the C ABI. This was discovered today by Michael Karcher who has
written a patch to address the issue, it's already sent upstream [1].

I'm attaching the patch. With the patches from #916818, #917000
and #917191, the testsuite failures on sparc64 drop to 9 for me.

> [1] https://github.com/rust-lang/rust/pull/57085

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 970747edb47795a1012929ea468c2b75f087b289 Mon Sep 17 00:00:00 2001
From: Michael Karcher 
Date: Sun, 23 Dec 2018 20:33:52 +0100
Subject: [PATCH] librustc_codegen_llvm: Don't eliminate empty structs in C ABI
 on linux-sparc64

This is in accordance with the SPARC Compliance Definition 4.2.1,
Page 3P-12. It says that structs of up to 8 bytes (which applies
to empty structs as well) are to be passed in one register.
---
 src/librustc_codegen_llvm/abi.rs | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/librustc_codegen_llvm/abi.rs b/src/librustc_codegen_llvm/abi.rs
index b8954dee79..c083137f08 100644
--- a/src/librustc_codegen_llvm/abi.rs
+++ b/src/librustc_codegen_llvm/abi.rs
@@ -456,6 +456,9 @@ impl<'tcx> FnTypeExt<'tcx> for FnType<'tcx, Ty<'tcx>> {
 let linux_s390x = target.target_os == "linux"
&& target.arch == "s390x"
&& target.target_env == "gnu";
+let linux_sparc64 = target.target_os == "linux"
+   && target.arch == "sparc64"
+   && target.target_env == "gnu";
 let rust_abi = match sig.abi {
 RustIntrinsic | PlatformIntrinsic | Rust | RustCall => true,
 _ => false
@@ -526,8 +529,9 @@ impl<'tcx> FnTypeExt<'tcx> for FnType<'tcx, Ty<'tcx>> {
 if arg.layout.is_zst() {
 // For some forsaken reason, x86_64-pc-windows-gnu
 // doesn't ignore zero-sized struct arguments.
-// The same is true for s390x-unknown-linux-gnu.
-if is_return || rust_abi || (!win_x64_gnu && !linux_s390x) {
+// The same is true for s390x-unknown-linux-gnu
+// and sparc64-unknown-linux-gnu.
+if is_return || rust_abi || (!win_x64_gnu && !linux_s390x && 
!linux_sparc64) {
 arg.mode = PassMode::Ignore;
 }
 }
-- 
2.20.1

Bug#916654: Acknowledgement (vdr-plugin-epgsearch 2.2.0+git20170817-2)

[klak]

Hallo Maintainer,

after two days (of updates) the bug was gone.

Please close bug#916654.

Greets klak

Bug#917191: rustc: Please include backported patch to fix double_check tests on big-endian

[John Paul Adrian Glaubitz]

Source: rustc
Version: 1.31.0+dfsg1-2
Severity: normal
Tags: upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

The attached patch fixes the double_check tests which currently fail on all
big-endian targets. Upstream has a fix for that [1] which I verified to work
on s390x and sparc64.

Thanks,
Adrian

> [1] https://github.com/rust-lang/rust/pull/55561

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 283f2be1421eca11b1a3abbaac40ca946e806037 Mon Sep 17 00:00:00 2001
From: Samuel Holland 
Date: Sun, 16 Sep 2018 18:27:56 +
Subject: [PATCH] Fix double_check tests on big-endian targets

Since the enums get optimized down to 1 byte long, the bits
set in the usize member don't align with the enums on big-endian
machines. Avoid this issue by shrinking the integer member to the
same size as the enums.
---
 src/test/ui/consts/const-eval/double_check.rs  | 8 
 src/test/ui/consts/const-eval/double_check2.rs | 8 
 src/test/ui/consts/const-eval/double_check2.stderr | 4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/test/ui/consts/const-eval/double_check.rs 
b/src/test/ui/consts/const-eval/double_check.rs
index 81f6e7ddd2..76f9276c05 100644
--- a/src/test/ui/consts/const-eval/double_check.rs
+++ b/src/test/ui/consts/const-eval/double_check.rs
@@ -21,12 +21,12 @@ enum Bar {
 union Union {
 foo: &'static Foo,
 bar: &'static Bar,
-usize: &'static usize,
+u8: &'static u8,
 }
-static BAR: usize = 42;
+static BAR: u8 = 42;
 static FOO: (, ) = unsafe {(
-Union { usize:  }.foo,
-Union { usize:  }.bar,
+Union { u8:  }.foo,
+Union { u8:  }.bar,
 )};
 
 fn main() {}
diff --git a/src/test/ui/consts/const-eval/double_check2.rs 
b/src/test/ui/consts/const-eval/double_check2.rs
index b661ee9247..701632362c 100644
--- a/src/test/ui/consts/const-eval/double_check2.rs
+++ b/src/test/ui/consts/const-eval/double_check2.rs
@@ -19,12 +19,12 @@ enum Bar {
 union Union {
 foo: &'static Foo,
 bar: &'static Bar,
-usize: &'static usize,
+u8: &'static u8,
 }
-static BAR: usize = 5;
+static BAR: u8 = 5;
 static FOO: (, ) = unsafe {( //~ undefined behavior
-Union { usize:  }.foo,
-Union { usize:  }.bar,
+Union { u8:  }.foo,
+Union { u8:  }.bar,
 )};
 
 fn main() {}
diff --git a/src/test/ui/consts/const-eval/double_check2.stderr 
b/src/test/ui/consts/const-eval/double_check2.stderr
index 9dd7570232..28825477c8 100644
--- a/src/test/ui/consts/const-eval/double_check2.stderr
+++ b/src/test/ui/consts/const-eval/double_check2.stderr
@@ -2,8 +2,8 @@ error[E0080]: it is undefined behavior to use this value
   --> $DIR/double_check2.rs:25:1
|
 LL | / static FOO: (, ) = unsafe {( //~ undefined behavior
-LL | | Union { usize:  }.foo,
-LL | | Union { usize:  }.bar,
+LL | | Union { u8:  }.foo,
+LL | | Union { u8:  }.bar,
 LL | | )};
| |___^ type validation failed: encountered invalid enum discriminant 5 at 
.1.
|
-- 
2.20.1

Bug#917190: FTBFS building for armel on arm64

[Steve McIntyre]

Package: src:haskell-cryptonite
Version: 0.25-5
Severity: important

Hi!

I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild is to identify packages that
might have problems with this configuration.

I've tried to build haskell-cryptonite like this, and it's failing its
test suite. I've tried to find out why, but the test suite is not very
helpful for me in identifying actual failures. Full log is online at

  
https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/haskell-cryptonite_0.25-5_armel.log

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 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)

Bug#917189: libi8x 0.0.5-1: FTBFS, alignment problem

[Steve McIntyre]

Source: libi8x
Version: 0.0.5-1
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment

Hi!

I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild is to identify packages that
might have problems with this configuration.

A feature of the arm64 kernel is that it does *not* support fixing up
code with broken alignment, so code that might have built and run OK
on our older armel/armhf build machines due to kernel fixups will now
fail.

When building your package, I've found a bus error (aka alignment
fault). The full log is online at

  
https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/libi8x_0.0.5-1_armel.log

for reference

I've done a quick bit of debugging to find the source of the
bug. Here's a gdb stacktrace and variable printout to demonstrate the
problem.

(sid-armel)steve@mjolnir:~/debian/build/libi8x/libi8x-0.0.5$ gdb 
/home/steve/debian/build/libi8x/libi8x-0.0.5/tests/valid/.libs/test-corpus 
tests/core 
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/home/steve/debian/build/libi8x/libi8x-0.0.5/tests/valid/.libs/test-corpus...done.
[New LWP 5680]
Core was generated by 
`/home/steve/debian/build/libi8x/libi8x-0.0.5/tests/valid/.libs/test-corpus'.
Program terminated with signal SIGBUS, Bus error.
#0  0xf7a9a0a8 in i8x_rb_read_int64_t (rb=rb@entry=0x1e57bc0, 
result=0xff7f4af8, result@entry=0xff7f4af0)
at readbuf.c:158
158 I8X_RB_READ_FIXED_MULTI (64)
warning: File "/home/steve/debian/build/libi8x/libi8x-0.0.5/.gdbinit" 
auto-loading has been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path 
/home/steve/debian/build/libi8x/libi8x-0.0.5/.gdbinit
line to your configuration file "/home/steve/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/steve/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) bt
#0  0xf7a9a0a8 in i8x_rb_read_int64_t (rb=rb@entry=0x1e57bc0, 
result=0xff7f4af8, result@entry=0xff7f4af0)
at readbuf.c:158
#1  0xf7a8d888 in i8x_code_read_operand (rb=0x1e57bc0, type=I8X_OPR_INT64, 
operand=operand@entry=0x1e57988, 
code=) at code.c:246
#2  0xf7a8e3a4 in i8x_code_unpack_bytecode (code=0x1e57908) at code.c:376
#3  i8x_code_init (code=0x1e57908) at code.c:757
#4  i8x_code_new (func=func@entry=0x1e57718, code=code@entry=0x1e57744) at 
code.c:831
#5  0xf7a972d4 in i8x_bcf_init (func=0x1e57718) at function.c:143
#6  i8x_func_new_bytecode (note=, func=0xff7f4bf8) at 
function.c:185
#7  0x0058ad1c in do_test (ctx=0x1dda150, 
filename=0x1ddaec8 
"corpus/i8c/0.0.3/32el/test_load_constant/test_output/0027-0001") at 
valid/test-corpus.c:104
#8  0x0058b094 in ftw_callback (fpath=0x1ddaec8 
"corpus/i8c/0.0.3/32el/test_load_constant/test_output/0027-0001", 
sb=sb@entry=0xff7f6c50, typeflag=) at valid/test-corpus.c:142
#9  0xf7a023fc in process_entry (data=data@entry=0xff7f7290, 
dir=dir@entry=0xff7f6d08, 
name=name@entry=0x1e3f8fb "0027-0001", namlen=, d_type=8) at 
ftw.c:464
#10 0xf7a0284c in ftw_dir (data=data@entry=0xff7f7290, st=0x8, 
st@entry=0xff7f6d58, 
old_dir=0xf7ae1968 <__stack_chk_guard>, old_dir@entry=0xff7f6e08) at 
ftw.c:543
#11 0xf7a02584 in process_entry (data=data@entry=0xff7f7290, 
dir=dir@entry=0xff7f6e08, name=, 
name@entry=0x1e4adf3 "test_output", namlen=, d_type=4) at 
ftw.c:461
#12 0xf7a0284c in ftw_dir (data=data@entry=0xff7f7290, st=0x4, 
st@entry=0xff7f6e58, 
old_dir=0xf7ae1968 <__stack_chk_guard>, old_dir@entry=0xff7f6f08) at 
ftw.c:543
#13 0xf7a02584 in process_entry (data=data@entry=0xff7f7290, 
dir=dir@entry=0xff7f6f08, name=, 
name@entry=0x1df4333 "test_load_constant", namlen=, 
d_type=4) at ftw.c:461
#14 0xf7a0284c in ftw_dir (data=data@entry=0xff7f7290, st=0x4, 
st@entry=0xff7f6f58, old_dir=0xf7ae1968 <__stack_chk_guard>, 
old_dir@entry=0xff7f7008) at ftw.c:543
#15 0xf7a02584 in process_entry 

Bug#917004: emacs: Emacs 26 lacks its manual

[Rob Browning]

Emmanuel Charpentier  writes:

> Why cant't this solution be used for the unversioned emacs ?

It will be soon -- I'm just running behind.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#916948: [Pkg-fonts-devel] Bug#916948: fonts-hack FTBFS: Unable to execute ttfautohint on the Hack-Regular variant set

[Fabian Greffrath]

Control: severity -1 normal
Control: tags -1 +unreproducible

Am Donnerstag, den 20.12.2018, 21:38 +0200 schrieb Adrian Bunk: 
> Warning: Option `-w G' is deprecated!  Use option `-a qsq' instead
> postbuild_processing/tt-hinting/Hack-Regular-TA.txt:3:1: invalid
> glyph name (0x204)
>   uni0023 touch 0,1,2,3,18,19,20,21,22,23,24,25,26,27,28,31 x 0.25  @
> 13
>   ^
> Unable to execute ttfautohint on the Hack-Regular variant set.  Build
> canceled.
> make[2]: *** [Makefile:26: ttf] Error 1

I have just successfully rebuilt the package in a sid chroot without a
single warning.

 - Fabian


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

Bug#917188: radicale: configuration changes for FreedomBox

[James Valleroy]

Source: radicale
Severity: wishlist

Dear Maintainer,

Currently, FreedomBox makes the following changes to /etc/radicale/config:
1. Sets server/hosts to '127.0.0.1:5232, [::1]:5232'.
2. Sets server/base_prefix to '/radicale/'.
3. Sets well-known/caldav to '/radicale/%(user)s/caldav/'.
4. Sets well-known/carddav to '/radicale/%(user)s/carddav/'.
5. Sets rights/type to 'owner_only'.

Here is the diff between the original and modified file:

diff --git a/config b/etc/radicale/config
index 9c89526..179c8c2 100644
--- a/config
+++ b/etc/radicale/config
@@ -58,6 +58,8 @@ key = /etc/ssl/private/ssl-cert-snakeoil.key
 #realm = Radicale - Password Required


+hosts=127.0.0.1:5232, [::1]:5232
+base_prefix=/radicale/
 [encoding]

 # Encoding for responding requests
@@ -90,7 +92,7 @@ type = remote_user

 # Rights backend
 # Value: none | authenticated | owner_only | owner_write | from_file
-type = from_file
+type = owner_only

 # File for rights management from_file
 file = /etc/radicale/rights
@@ -156,3 +158,6 @@ file = /etc/radicale/rights

 # Additional HTTP headers
 #Access-Control-Allow-Origin = *
+[well-known]
+caldav=/radicale/%(user)s/caldav/
+carddav=/radicale/%(user)s/carddav/


Note that rights/type can be further configured through plinth. It can
be set to 'owner_only', 'owner_write', or 'authenticated'.

*Note* Above configs are for radicale 1.x. For 2.x, some changes are
required (at least 'base_prefix' is no longer a valid option).

We would like to see if these configuration can either be made default
for radicale package, or can be offered as a debconf configuration option.

Regards,
James



signature.asc
Description: OpenPGP digital signature

Bug#917158: qemubuilder mishandles multiple entries in OTHERMIRROR

[Yuriy M. Kaminskiy]

On 23.12.2018 15:00, Debian Bug Tracking System wrote:

Trivial patch attached.


... unfortunately, it is not sufficient. sanitize_mirror() function also 
requires adjustments (I'm tempted to move it into shell/sed code, but 
that will cause regressions in the corner cases).

Bug#917187: ITP: golang-github-fzambia-sentinel -- Redis Sentinel support for redigo library

[Aman Verma]

Package: wnpp
Severity: wishlist
Owner: Aman Verma 

* Package name: golang-github-fzambia-sentinel
  Version : 1.0.0+git20180630.52eb513-1
  Upstream Author : Alexander Emelin
* URL : https://github.com/FZambia/sentinel
* License : Apache-2.0
  Programming Lang: Go
  Description : Redis Sentinel support for redigo library

  golang-github-fzambia-sentinel supports redigo library which is a
  Go client for the Redis database.
  This is a dependency of gitlab-workhorse.
  I will maintain this package under the Debian Go Team.

Bug#910373: Confirmed

[Anton Gladky]

Dear maintainer,

I can only confirm it and it is really annoying. Upstream
says that it is already fixed in the git and will be available
in version 3.4. Would be good to have it fixed in Debian.

Regards

Anton

Bug#705208: #705208,ITA: pylibtiff -- wrapper to the libtiff library to Python using ctypes

[Andreas Tille]

I'd be happy if you take pylibtiff, Andreas.

On Sun, Dec 23, 2018 at 08:37:55PM +0100, Antonio Valentino wrote:
> Hello,
> I would like to adopt the pylibtiff [1] package because it is a
> dependency of the new satpy that I'm going to package (#917110).
> 
> The pylibtiff package would become part of the Debian GIS project.
> 
> 
> Please let me know it there is something that prevents the adoption.
> 
> [1] https://tracker.debian.org/pkg/pylibtiff
> 
> 
> kind regards
> 
> -- 
> Antonio Valentino
> 
> 
> 

-- 
http://fam-tille.de

Bug#705208: #705208,ITA: pylibtiff -- wrapper to the libtiff library to Python using ctypes

[Antonio Valentino]

Hello,
I would like to adopt the pylibtiff [1] package because it is a
dependency of the new satpy that I'm going to package (#917110).

The pylibtiff package would become part of the Debian GIS project.


Please let me know it there is something that prevents the adoption.

[1] https://tracker.debian.org/pkg/pylibtiff


kind regards

-- 
Antonio Valentino

Bug#917186: ITP: golang-github-jfbus-httprs -- ReadSeeker for http.Response.Body

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name: golang-github-jfbus-httprs
   Version   : 0.0~git20180614.7861a11-1
   Upstream Author: Jean-François Bustarret
* URL : https://github.com/jfbus/httprs
* License   : Expat
   Programming Lang : Go
   Description : ReadSeeker for http.Response.Body

 httprs is a ReadSeeker for http.Response.Body.

 golang-github-jfbus-httprs is a dependency for gitlab-workhorse and hence
needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#917185: udev 240-1 + sysvinit-core 2.93-1 break input devices + other problems

[Ricardo F. Peliquero]

Package: udev
Version: 240-1
Severity: important

Dear Maintainer,

After updating udev from 239-15 to 240-1 I found these problems:

* Wireless keyboard + mouse don't work under X
  (Genius GK-100012CP/K SlimStar 8000ME)
   - unplugging + plugging again usb receiver re-enables them.
   - /dev/tty[1-6] work ok (e.g. through gpm)

* $ date outputs wrong hour
   - Sun Dec 23 10:43:19 2018: /dev/sdb2: Superblock last mount time is in the 
future.
   - Sun Dec 23 10:43:19 2018:   (by less than a day, probably due to the 
hardware clock being incorrectly set)

* [FAIL] Restoring mixer settings...[] failed. ... failed!
   - [FAIL] startpar: service(s) returned failure: aumix ... failed!

* console ttys render VGA fonts insted of expected
   - cat /etc/default/console-setup
 ACTIVE_CONSOLES="/dev/tty[1-6]"

 CHARMAP="UTF-8"

 CODESET="Lat15"
 FONTFACE="Terminus"
 FONTSIZE="8x16"

 VIDEOMODE=


Downgrading udev + libudev1 back to 239-15 will solve all
mentioned problems.

Kind regards,

Ricardo Peliquero


-- Package-specific info:

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

Kernel: Linux 4.19.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages udev depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libblkid12.33-0.2
ii  libc62.28-3
ii  libkmod2 25-2
ii  libselinux1  2.8-1+b1
ii  libudev1 240-1
ii  lsb-base 10.2018112800
ii  util-linux   2.33-0.2

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
pn  systemd  

-- no debconf information
P: /devices/LNXSYSTM:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYSTM:

P: /devices/LNXSYSTM:00/LNXCPU:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:

P: /devices/LNXSYSTM:00/LNXCPU:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:

P: /devices/LNXSYSTM:00/LNXPWRBN:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXPWRBN:

P: /devices/LNXSYSTM:00/LNXSYBUS:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYBUS:

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:PNP0A03:

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/device:02
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/device:02
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:03
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:03
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:04
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:04
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06/device:07
L: 0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06/device:07
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06/device:08
L: 0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:06/device:08
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09/device:0a
L: 0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09/device:0a
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09/device:0b
L: 0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:05/device:09/device:0b
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:0c
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:0c
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:0d
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:0d
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:0e
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:0e
E: 

Bug#917184: FTBFS building for armel on arm64

[Steve McIntyre]

Package: src:haskell-cipher-aes
Version: 0.2.11-8
Severity: important

Hi!

I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild is to identify packages that
might have problems with this configuration.

I've tried to build haskell-cipher-aes like this, and it's failing its
test suite. I've tried to find out why, but the test suite is not very
helpful at identifying actual failures. Here's a log:

(sid-armel)steve@maul:~/build/haskell-cipher-aes/haskell-cipher-aes-0.2.11$ 
debian/hlibrary.setup test --builddir=dist-ghc --show-details=always -v2
Running 1 test suites...
Test suite test-cipher-aes: RUNNING...
dist-ghc/build/test-cipher-aes/test-cipher-aes
Test suite test-cipher-aes: FAIL
Test suite logged to: dist-ghc/test/cipher-aes-0.2.11-test-cipher-aes.log
0 of 1 test suites (0 of 1 test cases) passed.
(sid-armel)steve@maul:~/build/haskell-cipher-aes/haskell-cipher-aes-0.2.11$ cat 
dist-ghc/test/cipher-aes-0.2.11-test-cipher-aes.log
Test suite test-cipher-aes: RUNNING...
Test suite test-cipher-aes: FAIL
Test suite logged to: dist-ghc/test/cipher-aes-0.2.11-test-cipher-aes.log

I've no idea where to start with debugging this.

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 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)

Bug#917167: systemd: 240 breaks kde (rakes ages to launch)

[Eric Valette]

On 23/12/2018 19:15, Michael Biebl wrote:

Thanks for the info. Very interesting read 
. Learned a few things 
today.


-- eric

Bug#917180: RM: meep-mpich2 [armel] guile-2.2 is not available on armel

[Thorsten Alteholz]

Package: ftp.debian.org
Affects: src:meep-mpich2

guile-2.2 doesn't build on armel currently. Therefore, please remove
meep-mpich2 from armel, as this depends on libctl which depends on 
guile-2.2.


See https://bugs.debian.org/883778 for more details about the guile 
armel issue.


Thanks!
 Thorsten

Bug#917182: RM: meep-openmpi [armel] guile-2.2 is not available on armel

[Thorsten Alteholz]

Package: ftp.debian.org
Affects: src:meep-openmpi

guile-2.2 doesn't build on armel currently. Therefore, please remove
meep-openmpi from armel, as this depends on libctl which depends on
guile-2.2.

See https://bugs.debian.org/883778 for more details about the guile
armel issue.

Thanks!
 Thorsten

Bug#917183: RM: meep-lam4 [armel] guile-2.2 is not available on armel

[Thorsten Alteholz]

Package: ftp.debian.org
Affects: src:meep-lam4

guile-2.2 doesn't build on armel currently. Therefore, please remove
meep-lam4 from armel, as this depends on libctl which depends on 
guile-2.2.


See https://bugs.debian.org/883778 for more details about the guile armel
issue.

Thanks!
 Thorsten

Bug#917181: RM: meep-mpi-default [armel] guile-2.2 is not available on armel

[Thorsten Alteholz]

Package: ftp.debian.org
Affects: src:meep-mpi-default

guile-2.2 doesn't build on armel currently. Therefore, please remove
meep-mpi-default from armel, as this depends on libctl which depends on
guile-2.2.

See https://bugs.debian.org/883778 for more details about the guile
armel issue.

Thanks!
 Thorsten

Bug#917179: RM: meep [armel] guile-2.2 is not available on armel

[Thorsten Alteholz]

Package: ftp.debian.org
Affects: src:meep

guile-2.2 doesn't build on armel currently. Therefore, please remove
meep from armel, as this depends on libctl which depends on guile-2.2.

See https://bugs.debian.org/883778 for more details about the guile armel
issue.

Thanks!
 Thorsten

Bug#917177: RM: mpb [armel] guile-2.2 is not available on armel

[Thorsten Alteholz]

Package: ftp.debian.org
Affects: src:mpb

guile-2.2 doesn't build on armel currently. Therefore, please remove
mpb from armel, as this depends on libctl which depends on guile-2.2.

See https://bugs.debian.org/883778 for more details about the guile armel
issue.

Thanks!
 Thorsten

Bug#917178: RM: libctl [armel] guile-2.2 is not available on armel

[Thorsten Alteholz]

Package: ftp.debian.org
Affects: src:libctl

guile-2.2 doesn't build on armel currently. Therefore, please remove
libctl from armel.

See https://bugs.debian.org/883778 for more details about the guile armel 
issue.


Thanks!
 Thorsten

Bug#917167: Fwd: Bug#917167: systemd: 240 breaks kde (rakes ages to launch)

[Fanael Linithien]

Michael Biebl  wrote:
> For processes that are spawned by PID 1, the limits are set differently
> though, so the unlimited rlimit for PID 1 should have no effect on other
> processes.
>
> Problem is, pam_limits.so in Debian ships a custom patch, which reads
> the limits from PID 1 and set those for login sessions.

Yeah, attaching gdb to kdeinit5 shows that rlim_max is 2^30, so not
quite INT_MAX, but still very high.

> So, ultimately, it's both a bug in pam_limits but also kinit, which
> should behave more sensibly if rlimit is set to a high value.

Arguably it's a bug in linux in that it's incapable of spawning a new
process without inheriting file descriptors from the caller, thus
requiring ugly workarounds like this ;)

> We can work around that in systemd though, which is what I plan to do
> for the time being.
>
> For a (temporary) workaround you can create a file
> /etc/security/limits.d/systemd.conf containing:
>
> * hard nofile 524288
>
> This will make pam_limits behave properly.

Thanks!

Bug#917167: systemd: 240 breaks kde (rakes ages to launch)

[Michael Biebl]

Control: forcemerge -1 917168 917173
Control: severity -1 grave

Am 23.12.18 um 18:27 schrieb Baptiste BEAUPLAT:
> Dear maintainers,
> 
> This issue seems related to #917168, feel free to merge it.
> 
> For the 100% cpu, I think the problem is here in kinit:
> 
> https://github.com/KDE/kinit/blob/master/src/kdeinit/kinit.cpp#L163

Thanks, that helps a lot, Baptiste!

For reference, it's related to
https://github.com/systemd/systemd/issues/10921

In v240, rlimit is bumped to INT_MAX in PID 1.

For processes that are spawned by PID 1, the limits are set differently
though, so the unlimited rlimit for PID 1 should have no effect on other
processes.

Problem is, pam_limits.so in Debian ships a custom patch, which reads
the limits from PID 1 and set those for login sessions.

So, ultimately, it's both a bug in pam_limits but also kinit, which
should behave more sensibly if rlimit is set to a high value.

We can work around that in systemd though, which is what I plan to do
for the time being.

For a (temporary) workaround you can create a file
/etc/security/limits.d/systemd.conf containing:

* hard nofile 524288

This will make pam_limits behave properly.

Regards,
Michael



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

Bug#915559: coreutils: Use renameat2 from glibc instead of syscall

[Michael Stone]

On December 23, 2018 12:51:41 PM EST, Johannes Schauer  wrote:
>Hi,
>
>On Tue, 04 Dec 2018 21:15:35 +0100 Johannes 'josch' Schauer
> wrote:
>> recently (2018-11-29), glibc 2.28 was accepted in unstable. It adds a
>wrapper
>> for the renameat2 syscall. That wrapper is necessary for fakechroot
>because
>> fakechroot cannot intercept system calls but uses a preloaded library
>to
>> intercept library calls.
>> 
>> Up to coreutils 8.30, mv(1) uses the renameat2 syscall which makes
>mv(1)
>> fail under fakechroot. See #909612.
>> 
>> Now that glibc 2.28 offers the renameat2 library function as a
>wrapper
>> to the syscall, coreutils added support for choosing the library
>> function instead of the syscall if the former is available:
>> 
>>
>https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c
>> 
>> I don't know if another coreutils release is likely to happen before
>the
>> freeze but if it isn't please consider the attached patch which
>> backports the commit from the gnulib git to coreutils 8.30.
>> 
>> Without this patch, fakechroot is currently not very useful because
>the
>> mv(1) tool is unusable inside fakechroot. Most prominently, apt uses
>> mv(1) inside its postinst script, so its impossible to install apt
>inside
>> fakechroot and thus one cannot setup a sensible system.
>
>what is the status of this bug? Without this patch, the functionality
>of
>fakechroot and mmdebstrap in the next stable release will be hampered.
>If you
>don't have time, I could also NMU coreutils with the attached patch.
>
>What do you think?
>
>Thanks!
>
>cheers, josch

Please just wait
-- 
Michael Stone
(From phone, please excuse typos)

Bug#917176: Please update libgit2 to 0.27.7

[Jeremy Bicha]

Source: libgit2
Version: 0.27.4+dfsg.1-0.1
Severity: wishlist
X-Debbugs-CC: prav...@debian.org

Please update libgit2 to 0.27.7. The changelog says that 0.27.5 and
0.27.6 fix several security issues.

https://github.com/libgit2/libgit2/releases

Thanks,
Jeremy Bicha

Bug#917167: systemd: 240 breaks kde (rakes ages to launch)

[Baptiste BEAUPLAT]

Dear maintainers,

This issue seems related to #917168, feel free to merge it.

For the 100% cpu, I think the problem is here in kinit:

https://github.com/KDE/kinit/blob/master/src/kdeinit/kinit.cpp#L163

```c
/*
 * Clean up the file descriptor table by closing all file descriptors
 * that are still open.
 *
 * This function is called very early in the main() function, so that
 * we don't leak anything that was leaked to us.
 */
static void cleanup_fds()
{
int maxfd = FD_SETSIZE;
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, ) == 0) {
maxfd = rl.rlim_max;
}
for (int fd = 3; fd < maxfd; ++fd) {
#if KDEINIT_OOM_PROTECT
if (fd != oom_pipe)
#endif
close(fd);
}
}
```

Has anything changed on the limits?

best regards,

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#903372: libgit2: please upload 0.27 to unstable

[Jeremy Bicha]

Version: 0.27.0+dfsg.1-0.6

libgit2 0.27 is now in Testing.

Thanks,
Jeremy Bicha

Bug#915559: coreutils: Use renameat2 from glibc instead of syscall

[Johannes Schauer]

Hi,

On Tue, 04 Dec 2018 21:15:35 +0100 Johannes 'josch' Schauer  
wrote:
> recently (2018-11-29), glibc 2.28 was accepted in unstable. It adds a wrapper
> for the renameat2 syscall. That wrapper is necessary for fakechroot because
> fakechroot cannot intercept system calls but uses a preloaded library to
> intercept library calls.
> 
> Up to coreutils 8.30, mv(1) uses the renameat2 syscall which makes mv(1)
> fail under fakechroot. See #909612.
> 
> Now that glibc 2.28 offers the renameat2 library function as a wrapper
> to the syscall, coreutils added support for choosing the library
> function instead of the syscall if the former is available:
> 
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c
> 
> I don't know if another coreutils release is likely to happen before the
> freeze but if it isn't please consider the attached patch which
> backports the commit from the gnulib git to coreutils 8.30.
> 
> Without this patch, fakechroot is currently not very useful because the
> mv(1) tool is unusable inside fakechroot. Most prominently, apt uses
> mv(1) inside its postinst script, so its impossible to install apt inside
> fakechroot and thus one cannot setup a sensible system.

what is the status of this bug? Without this patch, the functionality of
fakechroot and mmdebstrap in the next stable release will be hampered. If you
don't have time, I could also NMU coreutils with the attached patch.

What do you think?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#917166: I can confirm that my machines and up in the same state

[Yllman, Jens]

I upgraded two machines. Did not see any problem during the upgrade. But
now both of the machines have problem booting. One I can get started by
starting in recovery mode. The other boots anyway. But that machine I
never boot into any GUI.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Cyril Brulebois]

Hi,

Simon McVittie  (2018-12-23):
> To be completely clear about the decision that Ian asked the technical
> committee to overrule:
> 
> In all debootstrap versions since 1.0.102, merged /usr is the default
> (for all variants except --variant=buildd). This means that new
> installations of Debian buster using debian-installer will have merged
> /usr.
> 
> Do the debian-installer and debootstrap maintainers think this should
> continue to be true for the buster release?

As might have been noticed, I haven't been following Debian topics very
closely lately, but on this specific topic: I'm not aware of blockers
that should prevent us from keeping this new default setting.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#706130: Forwarding bugs from Debian bug tracking system

[Andreas Tille]

Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1  pixelmed_di...@yahoogroups.com

Hi,

since some years there are some bugs against the Debian packaged
pixelmed reported.  It seems obvious that no Debian developer will
be able to care for it.  I'd like to forward these bugs to get the
issues at least documented and know for other pixelmed users.  You
can find an overview about all open pixelmed related bugs here:

   https://bugs.debian.org/src:pixelmed

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#547608: closed by Dmitry Bogatov (Re: better URLs for policy doc)

[積丹尼 Dan Jacobson]

My email doesn't bounce (I hope).
I just haven't had time to look at this yet.

Bug#917175: davmail: depends on obsolete libcommons-httpclient-java library

[Markus Koschany]

Package: davmail
Version: 5.0.0.2801-2
Severity: normal

davmail depends on libcommons-httpclient-java, which is obsolete and was
replaced by libhttpclient-java. It has reached EOL status in 2011! It is no
longer supported upstream [1] and was affected by multiple security issues in
the past. davmail should be ported to the new libhttpclient-java
version, so that we can remove the old, unmaintained one. Please forward this
issue upstream, if you can't migrate the package yourself.

Please help us to accomplish this goal. We will bump this issue to important
when the list of rdeps is getting smaller and we think that the removal is
possible. We will eventually raise the severity to serious when the number
of rdeps is small.

If you have any questions don't hesitate to ask and contact us on

debian-j...@list.debian.org


Regards,

Markus

[1]  https://hc.apache.org/httpclient-3.x/

Bug#917173: systemd 240-1 breaks Plasma

[Fanael Linithien]

Sorry, the first message accidentally got sent while I was still
writing it, intended full text below:

Installing systemd 240-1 breaks plasma-workspace: xinit
/usr/bin/startkde hangs with a black screen, with kdeinit5 stuck at
100% CPU usage. Attaching strace to kdeinit5 reveals that it's trying
to close bogus file descriptors:

[…]
close(39936688) = -1 EBADF (Bad file descriptor)
close(39936689) = -1 EBADF (Bad file descriptor)
close(39936690) = -1 EBADF (Bad file descriptor)
close(39936691) = -1 EBADF (Bad file descriptor)
close(39936692) = -1 EBADF (Bad file descriptor)
close(39936693) = -1 EBADF (Bad file descriptor)
close(39936694) = -1 EBADF (Bad file descriptor)
close(39936695) = -1 EBADF (Bad file descriptor)
[…]

Reverting to systemd, libnss-systemd, libpamsystemd and libsystemd0
version 239-15 fixes the issue.

MATE is not affected, so it actually may be a Plasma issue that
systemd just revealed.

Bug#917167: systemd: 240 breaks kde (rakes ages to launch)

[Eric Valette]

Please provide a verbose debug log with precise error messages.
No time to do that. I already wasted two hours today... It was just to 
warn people that this version of udev should have gone to experimental 
or receive more testing before deploying it...


You have now tree bugs on the same subject...

-- eric

Bug#917174: davmail: FTBFS with libjackrabbit-java 2.18.0

[Markus Koschany]

Package: davmail
Version: 5.0.0.2801-2
Severity: serious

Hello,

unfortunately davmail fails to build from source with
libjackrabbit-java 2.18.0. Long deprecated methods have been removed.
Your package build-depends on a very old version of jackrabbit (2.4.3).

See also the deprecated list that explains which methods should be
used instead.

https://jackrabbit.apache.org/api/2.14/deprecated-list.html

Regards,

Markus

Bug#917173: systemd 240-1 breaks Plasma

[Fanael Linithien]

Package: systemd
Version: 240-1
Severity: critical

Installing systemd 240-1 breaks plasma-workspace: xinit
/usr/bin/startkde hangs with a black screen, with kdeinit5 stuck at
100% CPU usage. Attaching strace to kdeinit5 reveals that it's trying
to close bogus file descriptors:

[..]
close(39936688) = -1 EBADF (Bad file descriptor)
close(39936688) = -1 EBADF (Bad file descriptor)
close(39936688) = -1 EBADF (Bad file descriptor)
close(39936688) = -1 EBADF (Bad file descriptor)
close(39936688) = -1 EBADF (Bad file descriptor)
close(39936688) = -1 EBADF (Bad file descriptor)

Bug#917167: systemd: 240 breaks kde (rakes ages to launch)

[Eric Valette]

On 23/12/2018 17:57, Michael Biebl wrote:

Control: tags -1 + moreinfo

Am 23.12.18 um 17:11 schrieb Eric Valette:

Package: systemd
Version: 240-1
Severity: critical
Justification: breaks unrelated software

After upgrading to 240 version, all my system started to take ages to boot. It 
seems related to disk mapping first and then kdeinit5 is stuck for nearly 5 
minutes at 100 cpu.

Downgrading to 239.15 fixes eveyting back. THe report is done from a restaures 
239.15 version.


Are you using lvm?


no


What happens if you only upgrade udev to 240-1?


I only downgraded udev and libudev first because I saw the bug on lvm2. 
No change.



What if you keep udev at 239-15 and upgrade systemd to 240-1?


Does not work.


Please provide a verbose debug log with precise error messages.
No time to do that. I already wasted two hours today... It was just to 
warn people that this version of udev should have gone to experimental 
or receive more testing before deploying it...


-- eric

Bug#917168: systemd: fail to start kde after 240-1 upgrade

[Michael Biebl]

Am 23.12.18 um 17:16 schrieb Baptiste BEAUPLAT:
> Package: systemd
> Version: 240-1
> Severity: important
> 
> Dear Maintainer,
> 
> After updating my system, I'm was not able to start my kde desktop (plasma):
> 
> The problem is kdeinit5, called itself by startkde, running into an infinite
> loop of call to the close() syscall (verified with strace).
> 

I don't use kde myself and have no idea why kdeinit5 behaves that way.
Could you ask the KDE maintainers to help you debug this issue.

With the given information it is not possible to determine what the
problem is.

Michael

-- 
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#917167: systemd: 240 breaks kde (rakes ages to launch)

[Michael Biebl]

Control: tags -1 + moreinfo

Am 23.12.18 um 17:11 schrieb Eric Valette:
> Package: systemd
> Version: 240-1
> Severity: critical
> Justification: breaks unrelated software
> 
> After upgrading to 240 version, all my system started to take ages to boot. 
> It seems related to disk mapping first and then kdeinit5 is stuck for nearly 
> 5 minutes at 100 cpu.
> 
> Downgrading to 239.15 fixes eveyting back. THe report is done from a 
> restaures 239.15 version.

Are you using lvm?
What happens if you only upgrade udev to 240-1?
What if you keep udev at 239-15 and upgrade systemd to 240-1?
Please provide a verbose debug log with precise error messages.




-- 
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#917172: ITP: davs2 -- AVS2 (IEEE 1857.4) decoder

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: davs2
  Version : 1.6
  Upstream Author : Falei LUO 
* URL : https://github.com/pkuvcl/davs2
* License : GPL-2+
  Programming Lang: C
  Description : AVS2 (IEEE 1857.4) decoder

 davs2 is an decoder for the AVS2-P2/IEEE1857.4 video codec.
 .
 Audio Video Coding Standard (AVS) is a standard
 for compression digital audio and digital,
 developed and widely used in China.
 the second generation AVS standard (AVS2)
 primarily targets Ultra HD (High Definition) video,
 with features comparable to MPEG H.265 (HEVC) and VC9.

This package is an (optional) build-depenency of recent ffmpeg.

It will be maintained in the Debian Multimedia team.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwfvX8ACgkQLHwxRsGg
ASHEmA//Q0Z92SDU97W0FEyKPRJCpHW9Bc6G7RFw0qwY5npaFTkGCAco9w7sKozv
zQ8ESsLUwWyUxAqhNYW4nylbunUwE9uXg3aQ7rIDCIF/PA5qSqwmpb3QlaPgy3FP
owdyvOwSmPAOUoVq/71rOl3fYU4RWLKYuu/wG+ybX8Bfu6NzX1YgQ2UAzc2QrlJ/
4FR7cdH51YQHyD0tYgmxjkpgVF3q7Ht3HEeJmY66oYW3TtF3h0a2/gYAa2NGB0j9
V0UIliGs8a5UDe6tnJIpx4JgJo5U4/l7KGBFCzH8nPpA+U4qJlJGxoPbw7/dW8Wu
4kGt7lTAM4zbnStS78R2Jx+MULUOOrSoO6wam1CXABW2LbhaCnrWucEvtVq0T57N
fL3DDrJF29YGQrpQMKXWYMEpCpjm7Irm+c1PbBX0UaYw69xS/xi/Q+abVdFyFH4b
MfHf4ay7SFHHPPDeKW9UcIEQ0hm397amNFxqc4UhXZ9oNmu5iwyzG64NV0r7VfKS
pz2HgplwjdwSPojs0R5unSeRXEvUvPlnGqJXp++D/IPBldgAWQb93qr8FZOi963d
8pgWikzNokSwuWyvrLrfHeL7/7cAxOfH65SOfXc6HlpPzItstCow3J0SvWNV68Ug
dr2IOpatH///xUKpi5iQCtVe8qMDdshFRNRtOCqa0AjW+f8+z84=
=0oo8
-END PGP SIGNATURE-

Bug#915899: Linux: Enable features for newer Allwinner SoCs on ARMMP kernels

[Uwe Kleine-König]

Control: tag -1 + pending

Hello,

On Fri, Dec 07, 2018 at 11:03:26AM -0800, Damon Tarry wrote:
> Package: linux
> Version: 4.19.5-1~exp1
> 
> The following options are not currently enabled on Debian armhf ARMMP
> kernels, but are needed to enable some features on newer
> Allwinner/sunxi SoCs:
> 
> CONFIG_DRM_SUN8I_DW_HDMI
> CONFIG_SND_SUN8I_CODEC
> CONFIG_SND_SUN8I_CODEC_ANALOG
> CONFIG_SUN8I_DE2_CCU

I enabled these as module if possible and also SUNXI_CCU which is a
dependency of SUN8I_DE2_CCU. See https://deb.li/3hcE0 .

I wonder for which machine you need these and if they are relevant for
arm64, too.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#917171: FTBFS on all architectures

[Steve McIntyre]

Package: src:haskell-language-python
Version: 0.5.4-7
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=haskell-language-python
shows current state - failed builds everywhere. Looking at logs,
they're all showing

160 | parens (pretty (endRow span) <> comma <> pretty (endCol span))
|  ^^

src/Language/Python/Common/SrcLocation.hs:160:43: error:
Ambiguous occurrence `<>'
It could refer to either `Prelude.<>',
 imported from `Prelude' at 
src/Language/Python/Common/SrcLocation.hs:15:8-41
 (and originally defined in `GHC.Base')
  or `Language.Python.Common.Pretty.<>',
 imported from `Language.Python.Common.Pretty' at 
src/Language/Python/Common/SrcLocation.hs:37:1-36
 (and originally defined in 
`Text.PrettyPrint.HughesPJ')
|
160 | parens (pretty (endRow span) <> comma <> pretty (endCol span))
|   ^^
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 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)

Bug#917170: ITP: olive -- Professional open-source NLE video editor

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: olive
  Version : 20181130
  Upstream Authors: Olive Team
* URL : https://www.olivevideoeditor.org
* License : GPL 3+
  Description : Professional open-source NLE video editor
 This is a free non-linear video editor.

Package is availabe at http://phd-sid.ethz.ch/debian/olive/

Bug#917168: systemd: fail to start kde after 240-1 upgrade

[Baptiste BEAUPLAT]

Package: systemd
Version: 240-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

After updating my system, I'm was not able to start my kde desktop (plasma):

The problem is kdeinit5, called itself by startkde, running into an infinite
loop of call to the close() syscall (verified with strace).

Downgrading the following package to 239-15 fixed my problem:

- - - udev:amd64 (240-1, 239-15)
- - - libudev1:amd64 (240-1, 239-15)
- - - libsystemd0:amd64 (240-1, 239-15)
- - - libnss-mymachines:amd64 (240-1, 239-15)
- - - libpam-systemd:amd64 (240-1, 239-15)
- - - systemd:amd64 (240-1, 239-15)
- - - libnss-systemd:amd64 (240-1, 239-15)
- - - systemd-container:amd64 (240-1, 239-15)

Note that at least one other person has reported the bug:

https://lists.debian.org/debian-kde/2018/12/msg4.html

- -- Package-specific info:

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.1-3+b1
ii  libaudit11:2.8.4-2
ii  libblkid12.33-0.2
ii  libc62.28-3
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.6-1
ii  libgcrypt20  1.8.4-4
ii  libgnutls30  3.6.5-2
ii  libgpg-error01.33-3
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-2+b1
ii  libkmod2 25-2
ii  liblz4-1 1.8.2-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.33-0.2
ii  libpam0g 1.1.8-3.8
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  239-15
ii  mount2.33-0.2
ii  util-linux   2.33-0.2

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  239-15

Versions of packages systemd suggests:
ii  policykit-10.105-23
ii  systemd-container  239-15

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 239-15

- -- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/logind.conf changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQt4kiVMTxdp/CJ4U4XSUsQeV3XMwUCXB+04AAKCRAXSUsQeV3X
M4iSAQCocmRG/RcCzddRl22aRgS8hpZ8ozfumQisA8j9BkQLgwEAnHGVn5OuVmBL
jiUsRLBCTeMvd1r9lFaTa20yz4TiOgI=
=lDAQ
-END PGP SIGNATURE-

Bug#917169: ITP: bambostracker -- YM2608 (OPNA) music tracker

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: bambootracker
  Version : 0.1.3
  Upstream Authors: Rerrah
* URL : https://github.com/rerrahkr/BambooTracker
* License : GPL-2+
  Description : YM2608 (OPNA) music tracker
 This is a tracker for YM2608 (OPNA) which was used in NEC PC-8801/9801 
series

 computers.

Package is availabe at http://phd-sid.ethz.ch/debian/bambootracker/

Bug#906016: transition: gjs built with mozjs60

[John Paul Adrian Glaubitz]

Hi!

On 12/17/18 4:11 PM, Julien Cristau wrote:
>> We might have a patch for s390x in openSUSE/SLE, I'll have a look. There
>> also might be one in Fedora we could pick for Debian.
>>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1488552 is what I was
> hitting last time around.  That got resolved as fixed a few days ago,
> although it depends on a refactoring that's not in 60.  Still, might be
> worth trying to run SpiderMonkey tests on trunk on 64bit BE and see if
> and how much better it is now.

Interesting, thanks for the link. I would give it a go over the holidays,
I have already put it on my TODO list for the holidays.

Can we postpone the decision until after the holidays? Then I have enough
time for trying to whip up a patch.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#916798: Acknowledgement (firmware-iwlwifi 20180825+dfsg-1 breaks bluetooth on Intel 8265)

[Vroomfondel]

Had some time for some manual tweaking on this today, so on a whim I wanted to 
see if the latest firmware from the kernel git repo worked.

Currently with:
a) the current bluetooth firmware from firmware-iwlwifi 20180518-1
b) the latest iwlwifi-8265-36.ucode from the kernel git (36.9f0a2d68.0 
according to dmesg)

...I can confirm that the bluetooth firmware loads and the adapter works 
correctly. With the version included in 20180825+dfsg-1 (36.e91976c0.0 
according to the changelog), the bluetooth firmware fails to load as per my 
original report.

At the moment I've no idea which of the firmware files inside 
/lib/firmware/intel correspond to the bluetooth firmware for this chip so I've 
left those alone for the time being.

On 2018-12-18 18:21, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 916798: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916798.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Kernel Team 

If you wish to submit further information on this problem, please
send it to 916...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.