Bug#908456: invesalius is no longer installable

[Adrian Bunk]

Package: invesalius
Version: 3.1.1-1
Severity: grave

The following packages have unmet dependencies:
 invesalius : Depends: python-gdcm but it is not going to be installed
  Depends: python-vtkgdcm but it is not going to be installed

Bug#908455: pax-utils: frequent parallel FTBFS

[Adrian Bunk]

Source: pax-utils
Version: 1.2.3-1
Severity: important
Tags: ftbfs

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

...
Note: Writing dumpelf.1
Note: Writing dumpelf.1
Note: Writing dumpelf.1
Note: Writing dumpelf.1
Note: Writing pspax.1
Note: Writing pspax.1
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 
-ffile-prefix-map=/build/1st/pax-utils-1.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wunused -Wimplicit -Wshadow -Wformat=2 
-Wmissing-declarations -Wno-missing-prototypes -Wwrite-strings 
-Wbad-function-cast -Wnested-externs -Wcomment -Winline -Wchar-subscripts 
-Wcast-align -Wno-format-nonliteral -Wsequence-point -Wold-style-definition 
-Wextra -no-undefined -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o libpaxutils.la 
 paxelf.lo paxinc.lo paxldso.lo paxmacho.lo security.lo xfuncs.lo  -lcap
Note: Writing pspax.1
Note: Writing pspax.1
libtool: link: ar cru .libs/libpaxutils.a .libs/paxelf.o .libs/paxinc.o 
.libs/paxldso.o .libs/paxmacho.o .libs/security.o .libs/xfuncs.o 
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libpaxutils.a
libtool: link: ( cd ".libs" && rm -f "libpaxutils.la" && ln -s 
"../libpaxutils.la" "libpaxutils.la" )
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 
-ffile-prefix-map=/build/1st/pax-utils-1.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wunused -Wimplicit -Wshadow -Wformat=2 
-Wmissing-declarations -Wno-missing-prototypes -Wwrite-strings 
-Wbad-function-cast -Wnested-externs -Wcomment -Winline -Wchar-subscripts 
-Wcast-align -Wno-format-nonliteral -Wsequence-point -Wold-style-definition 
-Wextra  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o dumpelf dumpelf.o 
libpaxutils.la ./autotools/gnulib/libgnu.a  -lcap
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 
-ffile-prefix-map=/build/1st/pax-utils-1.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wunused -Wimplicit -Wshadow -Wformat=2 
-Wmissing-declarations -Wno-missing-prototypes -Wwrite-strings 
-Wbad-function-cast -Wnested-externs -Wcomment -Winline -Wchar-subscripts 
-Wcast-align -Wno-format-nonliteral -Wsequence-point -Wold-style-definition 
-Wextra  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o pspax pspax.o 
libpaxutils.la ./autotools/gnulib/libgnu.a  -lcap
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 
-ffile-prefix-map=/build/1st/pax-utils-1.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -Wunused -Wimplicit -Wshadow -Wformat=2 
-Wmissing-declarations -Wno-missing-prototypes -Wwrite-strings 
-Wbad-function-cast -Wnested-externs -Wcomment -Winline -Wchar-subscripts 
-Wcast-align -Wno-format-nonliteral -Wsequence-point -Wold-style-definition 
-Wextra  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o scanmacho scanmacho.o 
libpaxutils.la ./autotools/gnulib/libgnu.a  -lcap
Note: Writing scanelf.1
libtool: link: gcc -g -O2 -ffile-prefix-map=/build/1st/pax-utils-1.2.3=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wunused 
-Wimplicit -Wshadow -Wformat=2 -Wmissing-declarations -Wno-missing-prototypes 
-Wwrite-strings -Wbad-function-cast -Wnested-externs -Wcomment -Winline 
-Wchar-subscripts -Wcast-align -Wno-format-nonliteral -Wsequence-point 
-Wold-style-definition -Wextra -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed 
-o scanmacho scanmacho.o  ./.libs/libpaxutils.a ./autotools/gnulib/libgnu.a 
-lcap
libtool: link: gcc -g -O2 -ffile-prefix-map=/build/1st/pax-utils-1.2.3=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wunused 
-Wimplicit -Wshadow -Wformat=2 -Wmissing-declarations -Wno-missing-prototypes 
-Wwrite-strings -Wbad-function-cast -Wnested-externs -Wcomment -Winline 
-Wchar-subscripts -Wcast-align -Wno-format-nonliteral -Wsequence-point 
-Wold-style-definition -Wextra -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed 
-o pspax pspax.o  ./.libs/libpaxutils.a ./autotools/gnulib/libgnu.a -lcap
Note: Writing scanelf.1
libtool: link: gcc -g -O2 -ffile-prefix-map=/build/1st/pax-utils-1.2.3=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wunused 
-Wimplicit -Wshadow -Wformat=2 -Wmissing-declarations -Wno-missing-prototypes 
-Wwrite-strings -Wbad-function-cast -Wnested-externs -Wcomment -Winline 
-Wchar-subscripts -Wcast-align -Wno-format-nonliteral -Wsequence-point 
-Wold-style-definition -Wextra -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed 
-o dumpelf dumpelf.o  ./.libs/libpaxutils.a ./autotools/gnulib/libgnu.a -lcap
Note: Writing scanelf.1
Note: Writing scanelf.1
Note: Writing scanmacho.1
Note: Writing scanmacho.1
make[4]: Leaving directory '/build/1st/pax-utils-1.2.3/man'
make[4]: Leaving directory '/build/1st/pax-utils-1.2.3/man'
Note: Writing scanmacho.1
Note: Writing scanmacho.1
make[4]: Leaving directory '/build/1st/pax-utils-1.2.3/man'
rm: cannot remove 'scanelf.1.tmp': No such file or directory
make[4]: *** [Makefile:8: man] Error 1


Ideally the makefiles 

Bug#908454: linux-image-4.9.0-8-amd64: [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A

[Nazar Zhuk]

Package: src:linux
Version: 4.9.110-3+deb9u4
Severity: minor

Dear Maintainer,

I noticed messages like this in syslog:

[drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe
A (start=7921 end=7922) time 163 us, min 1788, max 1799, scanline start
1784, end 1802

They appear periodically and I don't see any pattern in timing or
relation to what I am doing.

No functionality seems to be affected and there are no visual artifacts
that I can see.

Searching for the error led me to suggestions to add i915.enable_psr=0
to kernel boot parameters. That didn't make a difference. Also, even
without it 'cat /sys/module/i915/parameters/enable_psr' shows 0.

I installed intel-microcode package and it didn't help.


-- Package-specific info:
** Version:
Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-8-amd64 root=/dev/mapper/xps--vg-root ro 
video=1920x1080-32 apparmor=1 security=apparmor quiet splash

** Not tainted

** Kernel log:
[   30.054199] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   30.054335] iTCO_wdt: Found a Intel PCH TCO device (Version=4, 
TCOBASE=0x0400)
[   30.054436] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   30.057835] int3403 thermal: probe of INT3403:03 failed with error -22
[   30.058281] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
[   30.058477] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   30.064319] input: PC Speaker as /devices/platform/pcspkr/input/input12
[   30.064887] EFI Variables Facility v0.08 2004-May-17
[   30.089930] intel_rapl: Found RAPL domain package
[   30.089932] intel_rapl: Found RAPL domain core
[   30.089933] intel_rapl: Found RAPL domain uncore
[   30.089934] intel_rapl: Found RAPL domain dram
[   30.091000] pstore: using zlib compression
[   30.091155] pstore: Registered efi as persistent store backend
[   30.091160] ath10k_pci :3a:00.0: enabling device ( -> 0002)
[   30.093427] ath10k_pci :3a:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 
reset_mode 0
[   30.093669] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not 
initialized!
[   30.093671] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not 
initialized!
[   30.093672] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not 
initialized!
[   30.093674] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not 
initialized!
[   30.093748] input: Integrated_Webcam_HD as 
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input13
[   30.093875] usbcore: registered new interface driver uvcvideo
[   30.093876] USB Video Class driver (1.1.1)
[   30.113817] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 
subsystem
[   30.115286] EXT4-fs (nvme0n1p2): mounted filesystem without journal. Opts: 
(null)
[   30.124396] dcdbas dcdbas: Dell Systems Management Base Driver (version 
5.6.0-3.2)
[   30.128340] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3246: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   30.128343] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   30.128344] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[   30.128345] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   30.128346] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   30.128347] snd_hda_codec_realtek hdaudioC0D0:  Headset Mic=0x19
[   30.128349] snd_hda_codec_realtek hdaudioC0D0:  Headphone Mic=0x1a
[   30.128350] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[   30.150904] dell_wmi: Detected Dell WMI interface version 1
[   30.150968] input: Dell WMI hotkeys as /devices/virtual/input/input16
[   30.154320] Adding 16658428k swap on /dev/mapper/xps--vg-swap_1.  
Priority:-1 extents:1 across:16658428k SSFS
[   30.162481] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[   30.163375] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[   30.163428] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input17
[   30.163475] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input18
[   30.163569] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input19
[   30.342578] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[   30.356699] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   30.356700] Bluetooth: BNEP filters: protocol multicast
[   30.356703] Bluetooth: BNEP socket layer initialized
[   30.360295] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   30.383614] ath10k_pci :3a:00.0: firmware: failed to load 
ath10k/pre-cal-pci-:3a:00.0.bin (-2)
[   30.383617] ath10k_pci :3a:00.0: Direct firmware load for 
ath10k/pre-cal-pci-:3a:00.0.bin failed with error -2
[   

Bug#908453: Also checked 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10

[Keith Bare]

In my initial bug submission, I indicated I saw the problem in version
4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9, as that was what my system was
running when I first noticed Xen ignoring type = 'pvh'.

I saw there was an update: 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10.  Since
it looks like it's using a newer upstream version, I wanted to check whether
it also ignores type = 'pvh'.  I could imagine maybe some of the comet
changes were merged in...

But, even with the deb9u10 package, I'm still seeing that DomUs will boot in
PV mode when their configuration specifies type = 'pvh'.

--Keith Bare

Bug#852585: sg3-utils: Update udevadm path

[Michael Biebl]

On Tue, 20 Jun 2017 14:55:37 +0200 Michael Biebl  wrote:
> On Wed, 25 Jan 2017 14:42:36 +0100 bi...@debian.org wrote:
> > Package: sg3-utils
> > Version: 1.42-2
> > Severity: normal
> > User: pkg-systemd-maintain...@lists.alioth.debian.org
> > Usertags: udevadm
> > 
> > Hi,
> > 
> > since Jessie, the udevadm binary is available as /bin/udevadm.
> > To not break existing scripts, which use the old /sbin/udevadm path,
> > the udev package currently ships a compat symlink which we would like
> > to drop eventually (in buster or buster+1).
> > 
> > According to codesearch [1] your package sg3-utils does hard-code the
> > udevadm path as /sbin/udevadm.
> > 
> > Please change that to /bin/udevadm.
> 
> With stretch being released and buster open for development, it would be
> a great opportunity to get this fixed now. So please consider adding
> this change in your next upload.
> 
> If you are worried about backports: /bin/udevadm is already available in
> Debian jessie (oldstable) or Ubuntu trusty (14.04LTS). So it's safe to
> use the /bin/udevadm path.
> 
> You might also consider not hard-coding the path altogether, and simply
> rely on PATH being set properly. This should be a safe assumption,
> especially since the binary is now in /bin


Another friendly ping

-- 
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#852575: powerpc-utils: Update udevadm path

[Michael Biebl]

On Tue, 20 Jun 2017 15:01:54 +0200 Michael Biebl  wrote:
> On Wed, 25 Jan 2017 14:42:37 +0100 bi...@debian.org wrote:
> > According to codesearch [1] your package powerpc-utils does hard-code the
> > udevadm path as /sbin/udevadm.
> 
> You might also consider not hard-coding the path at all, and simply rely
> on PATH being set properly. This should be a safe assumption, especially
> since the binary is now in /bin


Another friendly ping

-- 
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#852571: open-infrastructure-system-boot: Update udevadm path

[Michael Biebl]

On Sat, 9 Sep 2017 08:48:04 +0200 Daniel Baumann
 wrote:
> tag 852571 pending
> thanks
> 
> got a few other changes to test, will upload new release tomorrow.

Another friendly ping

-- 
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#908358: Display stays off after computer resumes from suspend

[Michael Biebl]

Am 09.09.18 um 18:37 schrieb Dave Smith:

>  ATI Mobility Radeon 9600 and radeon.

You are still missing the information from
reportbug --template systemd

I need that to properly reassign this issue to the kernel image.
Otherwise I'll just have to close this bug report.

Regards,
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#908453: xen-utils-common: README.comet seems to no longer apply to the current Xen packages

[Keith Bare]

Package: xen-utils-common
Version: 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
Severity: important

Dear Maintainer,

   * What led up to the situation?

I needed to build a new Xen DomU.  Since I had seen that Debian had picked
up the 4.8 "comet" changes and pvshim, I wanted to experiment with Xen's PVH
mode and have the DomU run the Linux 4.17 kernel in stretch-backports, which
should be new enough to support PVH.

It seemed like this should work, given instructions in
/usr/share/doc/xen-utils-common/README.comet
 
* Converting a PV config to a PVH config

If you have a kernel capable of booting PVH, then PVH mode is both
faster and more secure than PV or PVH-shim mode.

- Remove any reference to 'builder' (e.g., `builder="generic"`)
- Add the following line:
  type="pvh"



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

I ran xen-create-image (from the xen-tools package) with --dist=stretch to
build the DomU and its configuration.  I also used --pygrub so Xen would
boot the kernel installed in the DomU's filesystem.

I temporarily edited the DomU's Xen/xl configuration to use the pvshim, per
the instructions in README.comet (type = 'pvh' / pvshim = 1), started the
DomU, added the stretch-backports repository, and installed
linux-image-amd64 from backports.  I then shut down the DomU, edited the
DomU's configuration to remove the pvshim = 1 line, and re-started the DomU.


   * What was the outcome of this action?

It appeared the DomU was running in PV mode, despite my having added type =
'pvh' to its Xen/xl configuration.

It was difficult to tell, but I believed the DomU was running in PV mode as
its kernel printed:

 - [0.00] Hypervisor detected: Xen PV
 - [0.00] Kernel/User page tables isolation: disabled on XEN PV.

Some Internet searching also seemed to indicate that "xl list -l "
should mention "pvh" if the DomU is running in PVH mode.  However, I only
saw:

 - "type": "pv",

There was no mention of "pvh" in the output.


   * What outcome did you expect instead?

I expected the DomU to run in PVH mode.  I wasn't sure what this was
supposed to look like, but I did some experiments (installed the old
4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 packages and worked around
bootloader being broken for PVH) and saw that in fact, with that version of
the Xen packages, the DomU kernel prints:

 - [0.00] Hypervisor detected: Xen HVM
 - [0.00] Booting paravirtualized kernel on Xen PVH
 - [0.00] Kernel/User page tables isolation: enabled

And xl list -l  shows:

 - "type": "pvh",


   * More thoughts/discussion.

It looks like the Debian packages lost support for booting DomUs in PVH mode
with version 4.8.3+xsa262+shim4.10.0+comet3-1+deb9u6.  Probably because:

Update to new upstream version 4.8.3+xsa262+shim4.10.0+comet3.
(This is the upstream staging-4.8 branch, which is ahead of the
upstream CI-tested stable-4.8 branch by precisely the three
most recent XSA fixes.  We are switching away from the special
upstream 4.8 comet branch.)

And maybe that's fine... if the mitigation comet and the pvshim provided is
also effectively provided by XPTI changes that were present in the
stable-4.8 branch, then I guess it isn't really necessary for anybody to use
(and thus PVH-mode boot) the shim anymore.  However, if that's the case,
then it probably doesn't make sense to include README.comet and continue
packaging the shim in the Debian packages anymore.

The thing that's nefarious (and could be grounds for increasing the bug
severity), is that anybody that followed the README.comet instructions and
configured DomUs to boot a PVH-capable kernel without the shim is now,
probably to their surprise, running their DomU in PV mode.  This means
they've lost Linux's KPTI protections from Meltdown within their DomU.  The
underlying issue is that the xl command seems to silently ignore
configuration directives it doesn't understand--which, without the 4.8
comet2 changes, includes 'type'!

This isn't a huge deal for me and my deployment (at the CMU Computer Club).
Our Xen infrastructure was running jessie/Xen 4.4 at best when the
Meltdown/Spectre news broke.  So our initial mitigation was to switch
everything to run in HVM mode (and we've continued doing so since then).  I
was interested in exploring PVH mode though, since it looked like it was
more similar to PV mode in some ways that would make it work better with
various tooling (e.g., xen-tools).  The fact it didn't work with the Debian
packages the way I thought it would was surprising, and I figured it might
be surprising for other people too.

--Keith Bare


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

Kernel: Linux 4.9.0-7-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: 

Bug#906539: magic-wormhole: Please provide python-magic-wormhole library its needed by new version of tahoe-lafs

[Vasudev Kamath]

Antoine Beaupré  writes:

> I'm happy to accept patches to ship a Python2 debian package of the
> wormhole library, but I do not have time to make the change myself. NMU,
> patches welcome.

I will see what I can do.
>
> I would also strongly recommend pushing tahoe-lafs to port to Py3
> already. Python 2 will be unsupported by the time our next Debian
> release is published and its future is uncertain, at best.
>

Well I agree but it seems like some dependencies are delaying porting to
python3 hence for the time being it will be good to provide python2 lib
so we can ship newer versions of tahoe-lafs.

Cheers,

Bug#908452: webext-proxy-switcher: reports extension installation and version to add0n.com from new profiles

[Paul Wise]

Package: webext-proxy-switcher
Version: 0.3.3.1-1
Severity: normal
Usertags: privacy

When I start Firefox with a new profile, the extension opens a tab that
submits an unencrypted HTTP GET request to add0n.com with the add-on
name and version number, example URL below. This is a privacy issue
unless the user also uses the -offline option when starting Firefox.
The correct solution is either to ship the information to be conveyed
to the user with the package itself (like Privacy Badger does) or to
ask the user if they would like to load the remote page (only for
information that must be updated separately to the package). Looking at
the source code, it also loads the add0n.com website when the add-on is
upgraded or removed (URLs below).

$ firefox -profile $(mktemp -d tmp-firefox-profile-XX)

http://add0n.com/proxy-switcher.html?version=0.3.3.1=install
http://add0n.com/proxy-switcher.html?version=0.3.3.1=upgrade
http://add0n.com/proxy-switcher.html?rd=feedback=Proxy%20Switcher%20and%20Manager=0.3.3.1

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

webext-proxy-switcher depends on no packages.

Versions of packages webext-proxy-switcher recommends:
ii  firefox  62.0-1

webext-proxy-switcher suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#908451: multistrap: Wrong apt-get options for noauth case.

[André Caldas]

Package: multistrap
Version: 2.2.9
Severity: important

Dear Maintainer,

When executing multistrap with --no-auth option, apt-get fails with

Get:1 http://ftp.br.debian.org/debian testing InRelease [150 kB]
Err:1 http://ftp.br.debian.org/debian testing InRelease
  The following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010 NO_PUBKEY 
04EE7237B7D453EC
Reading package lists... Done
W: GPG error: http://ftp.br.debian.org/debian testing InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010 NO_PUBKEY 04EE7237B7D453EC
E: The repository 'http://ftp.br.debian.org/debian testing InRelease' is not 
signed.
N: Updating from such a repository can't be done securely, and is therefore 
disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration 
details.
apt update failed. Exit value: 100

The problem seems to be with a missing option
-o Acquire::AllowInsecureRepositories=true
that should be passed to apt-get.


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

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

Versions of packages multistrap depends on:
ii  apt1.6.4
ii  libconfig-auto-perl0.44-1
ii  liblocale-gettext-perl 1.07-3+b3
ii  libparse-debian-packages-perl  0.03-2
ii  perl   5.26.2-7

multistrap recommends no packages.

Versions of packages multistrap suggests:
pn  fakeroot  

-- no debconf information

Bug#908450: webext-bulk-media-downloader: reports extension installation and version to add0n.com from new profiles

[Paul Wise]

Package: webext-bulk-media-downloader
Version: 0.2.1-3
Severity: normal
Usertags: privacy

When I start Firefox with a new profile, the extension opens a tab that
submits an unencrypted HTTP GET request to add0n.com with the add-on
name and version number, example URL below. This is a privacy issue
unless the user also uses the -offline option when starting Firefox.
The correct solution is either to ship the information to be conveyed
to the user with the package itself (like Privacy Badger does) or to
ask the user if they would like to load the remote page (only for
information that must be updated separately to the package). Looking at
the source code, it also loads the add0n.com website when the add-on is
upgraded or removed (URLs below).

$ firefox -profile $(mktemp -d tmp-firefox-profile-XX)

http://add0n.com/media-tools.html?version=0.2.1=install
http://add0n.com/media-tools.html?version=0.2.1=upgrade
http://add0n.com/feedback.html?name=Bulk%20Media%20Downloader=0.2.1

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

webext-bulk-media-downloader depends on no packages.

Versions of packages webext-bulk-media-downloader recommends:
ii  firefox  62.0-1

webext-bulk-media-downloader suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#908365: Package fails to build reproducibly

[Michael Biebl]

Thanks Chris

Am 09.09.18 um 21:31 schrieb Chris Lamb:
> Spent a couple moments on this. The first thing that can be addressed
> is the absolute CATALOG_DIR which ends up in the /usr/lib/systemd/
> tests/test-catalog binary in the systemd-tests package.
> 
> This dir is currently "useless" in that it will fail on (almost) all
> end- user systems as it points into the original build path, eg, /tmp/
> buildd.

test-catalog is an odd one indeed. We already special-case it in our
autopkgtests:
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/tests/root-unittests#L6

I've filed https://github.com/systemd/systemd/issues/10045, maybe we can
find a proper solution for this or stop installing the test binary.



-- 
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#908291: developers-reference, section 5.11.4: Add a note on versioning scheme when reverting an NMU

[Joseph Herlant]

Hi Ian,

On Sun, Sep 9, 2018 at 7:39 AM Ian Jackson
 wrote:
> Maybe adding a link or xref to policy 5.6.12.1 would be helpful.

Good point, thanks! I updated the MR to include the reference to the policy.

Joseph

Bug#907731: closed by Michael Gilbert (Bug#907731: fixed in steam 1.0.0.56-1)

[Evan Goers]

This partially fixed the issue for me. The controller works fine in wired
mode to a point. In wireless mode, the USB dongle still did not pair to the
controller(with X+GUIDE as is required to pair) unless the permissions MODE
is modified to 0666 in /lib/udev/rules.d/60-steam-input.rules. I also have
issues performing various firmware modification tasks(rollback/upgrading to
bluetooth firmware) for the controller in wired mode without 0666.

On Sun, Sep 2, 2018 at 11:39 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the steam-devices package:
>
> #907731: steam-devices: Steam Controller undetected in Steam due to
> incorrect udev rules from steam-devices package
>
> It has been closed by Michael Gilbert .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Michael Gilbert <
> mgilb...@debian.org> by
> replying to this email.
>
>
> --
> 907731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907731
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Michael Gilbert 
> To: 907731-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 03 Sep 2018 03:36:09 +
> Subject: Bug#907731: fixed in steam 1.0.0.56-1
> Source: steam
> Source-Version: 1.0.0.56-1
>
> We believe that the bug you reported is fixed in the latest version of
> steam, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 907...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Michael Gilbert  (supplier of updated steam package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Mon, 03 Sep 2018 02:42:51 +
> Source: steam
> Binary: steam steam-devices
> Architecture: source
> Version: 1.0.0.56-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Games Team 
> Changed-By: Michael Gilbert 
> Description:
>  steam  - Valve's Steam digital software delivery system
>  steam-devices - Device support for Steam-related hardware
> Closes: 907731 907813
> Changes:
>  steam (1.0.0.56-1) unstable; urgency=medium
>  .
>* New upstream release
>* Update standards version.
>* Drop zenity from the recommended packages.
>* Add uaccess to the udev rules (closes: #907731).
>* Recommend fontconfig and ca-certificates (closes: #907813).
> Checksums-Sha1:
>  8d015cd496562c7e9ee4e4d4dee17e1456896cd2 2587 steam_1.0.0.56-1.dsc
>  f62dc01c9822443b7fe9ebae1d52d15c6c60de14 1530024
> steam_1.0.0.56.orig.tar.xz
>  7eb61d396f42772ea867a4bf81eadd56274ae46c 23336
> steam_1.0.0.56-1.debian.tar.xz
>  28d3aeca0f9b47da98fbb380e45a3ad357cf9943 6646
> steam_1.0.0.56-1_source.buildinfo
> Checksums-Sha256:
>  abd5d29856c2e2d7d80e3c6ecb4711db3af17634283744f284e4dadc61ae6203 2587
> steam_1.0.0.56-1.dsc
>  e7ad7b47bcf94156409c272bb7a1c674ea4254584c83092d37e9f498a2f2b469 1530024
> steam_1.0.0.56.orig.tar.xz
>  3eba2026e3a681092e4ef3272a07e3171cd21fb22690360673a2c8a37a2a8aac 23336
> steam_1.0.0.56-1.debian.tar.xz
>  a6ba5aa7fd80e3df311b4b9730a2313c62d4cbe13bb12711a092cac224727219 6646
> steam_1.0.0.56-1_source.buildinfo
> Files:
>  276d961c810a1f124b5aa42cef92f8e5 2587 non-free/games optional
> steam_1.0.0.56-1.dsc
>  ebd85376ff7542f90e7c86a2bb32910a 1530024 non-free/games optional
> steam_1.0.0.56.orig.tar.xz
>  c51a9de3128ca9dfe0effa1f2471b0d5 23336 non-free/games optional
> steam_1.0.0.56-1.debian.tar.xz
>  20b820fe7b6d54502fdc242924614483 6646 non-free/games optional
> steam_1.0.0.56-1_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQQzBAEBCgAdFiEEluhy7ASCBulP9FUWuNayzQLW9HMFAluMqM4ACgkQuNayzQLW
> 9HOT7yAAg7RNOMtYJDzJ7Xja9g02fT/6QsdzwK9Hg747Y46I/a4RxVAR3hlY4Wqp
> AeidcGjV3JGOiviNTIwCADvyj070fcJsCpqhpUSSz06xKkfB+AIFjTkA9p0bNosG
> 4ocAPgIii3G1P3mVFMtlpCChRwFpmtrAjfwvbP9ZDU6v285lYQZahwTkJpcl7mHw
> wK2sA8AzTExg8bWyGZcuonKTXvyEkDK97CLutFVK5azcVh3txWPGVzrq+dCZ5UYD
> ddhzfhThKNzEo0VO/RBhuM1hQ+3JWhVZhFntuhJpYNgeauahp9VCsv8JclZ05+Xu
> iXSApwUUePdFPNF1IkyYrxQj4ZcDWPAQSY2BauinktgxxGT5KpxQfUbGYMLWugfE
> adVcPYvwPFHKhBVa54msB1//z1w3gb3+ayQLYvx9marM+qt5d02HEYxDLi3M6Tgm
> 7g/2gm3ScCtxWA0czpKzoP3HU8s99rxN3dZLWfEe7CGHOUmi2acrYH3Y4o15P6Ek
> I/W1UttH6pWqWXy05wplQR40EukzFBNIIiXV6Qp5NfQfFwk+Ydp6/iO02R8nP2We
> ba15M/adzz6nRdjL65mCXEuB9mb5XDghXT0xFM33nkb+QDf3IQz8BHPY+U4SQCI1
> 

Bug#908449: (no subject)

[bugs]

Package: firefox-esr
Version: 60.2.0esr-1~deb9u2
Severity: grave

Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)


After updating from firefox-esr:i386 52.9.0esr-1~deb9u1 to 60.2.0esr-1~deb9u2, 
it no longer works.

It opens the crashreporter every time when trying to open it:
«Firefox had a problem and crashed. We’ll try to restore your tabs and 
windows when it restarts.

To help us diagnose and fix the problem, you can send us a crash report.»
and choosing to restart it only leads to that same window.

Running under gdb shows it is trying to run an unsupported instruction:
Thread 1 "firefox-esr" received signal SIGILL, Illegal instruction.
0xb352826f in ?? () from /usr/lib/firefox-esr/libxul.so

(gdb) x/i 0xb352826f
=> 0xb352826f:  movsd  -0x18(%ebp),%xmm0

or in intel syntax:
(gdb) set disassembly-flavor intel
(gdb) x/i 0xb352826f
=> 0xb352826f:  movsd  xmm0,QWORD PTR [ebp-0x18]


and indeed, this instruction is not accepted on the -admittedly old- computer 
where the fault happened.

/proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 
instruction [1]


1- https://en.wikipedia.org/wiki/X86_instruction_listings#SSE2_instructions

Bug#622933: [Pkg-zsh-devel] Bug#622933: Bug#622933: zsh: Enable completions by default, unless skip_global_compinit is set

[Daniel Shahaf]

Frank Terbeck wrote on Mon, 10 Sep 2018 02:27 +0200:
> In the meantime (it's been more  than seven years), I've changed my mind
> about this.  I think a vendor should  do as little as  possible in their
> global configuration files.

Agreed, but there's more to it.  compinit is an incredibly useful
setting and it should be easy for new users to discover it.

Debian does this via /etc/zsh/newuser.zshrc.recommended.  Upstream does
this via zsh-newuser-install.  Both of these already set up compinit.

Upstream's default settings are minimal, and I don't know if that
will change, but there is interest upstream in making it easy for new
users to discover useful settings, such as the zstyle settings  in
upstream's StartupFiles/zshrc.

So, I guess what Frank and I are saying is: if you want better defaults,
work with upstream on making that happen.

Cheers,

Daniel

P.S. How about adding a mention of newuser.zshrc.recommended to
   README.Debian, so it's more discoverable?

> ¹ A case could be made that this is overstepping the boundaries already.
>   And maybe that's  true. Getting keyboard handling in  a terminal right
>   is a hard task, however. It  requires intimate knowledge about some of
>   the subtleties of how terminals work  and about the facilities zsh of-
>   fers to work with  those. It would be much better, if  zsh did some of
>   this out  of the box,  but alas it doesn't.  (The rationale is  to not
>   break existing setups — and that's a valid argument, too.)

Bug#907725: xfonts packages are not using the x11 section in practice

[Russ Allbery]

Chris Lamb  writes:

>> Change Lintian to expect those packages to be in fonts, I think?

> Sounds good; was curious whether you were planning on waiting for the
> webpages to change. Fixed in Git, pending upload:

Thanks!  I don't think there's anything for me personally to do here,
since my package uses the same section as the archive uses in
debian/control.  (Well, I could have made the change in Lintian... one of
these days I'll get back to doing that.)

-- 
Russ Allbery (r...@debian.org)   

Bug#907855: racket-mode: testsuite failure on arm64

[David Bremner]

Gianfranco Costamagna  writes:

>  Hello, unfortunately it didn't work...and now I'm getting another
>  failure too

   http://autopkgtest.ubuntu.com/packages/r/racket-mode/cosmic/arm64

Do you have any ideas on how to duplicate the problem interactively?
Ideally in a debian environment.

d

Bug#622933: [Pkg-zsh-devel] Bug#622933: zsh: Enable completions by default, unless skip_global_compinit is set

[Frank Terbeck]

Hi,

TS wrote:
[...]
> Replying here because i think the patch that never got applied
> should look like:

In the meantime (it's been more  than seven years), I've changed my mind
about this.  I think a vendor should  do as little as  possible in their
global configuration files. We already do a fair bit with regard to key-
board setup.¹ But compsys is much more expensive in  comparison, and al-
most all zsh user will call this  in their zshrc file anyway. And all of
those people, we'll force  to create a .zshenv file just  to to revert a
change in a vendor file.

In short, I am firmly against doing this.


Regards, Frank

¹ A case could be made that this is overstepping the boundaries already.
  And maybe that's  true. Getting keyboard handling in  a terminal right
  is a hard task, however. It  requires intimate knowledge about some of
  the subtleties of how terminals work  and about the facilities zsh of-
  fers to work with  those. It would be much better, if  zsh did some of
  this out  of the box,  but alas it doesn't.  (The rationale is  to not
  break existing setups — and that's a valid argument, too.)

Bug#908447: working after upgrade and reboot

[Jiri Kanicky]

Hi.

So it seems that its working after upgrade and reboot. The FN +
dedicated Laptop key also works to switch displays.

-- 

Jiri

Bug#908448: RFS: osmose-emulator/1.3-1 -- Sega Master System and Game Gear console emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "osmose-emulator"

 * Package name: osmose-emulator
   Version : 1.3-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/osmose-emulator
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  osmose-emulator - Sega Master System and Game Gear console emulator

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/osmose-emulator

  Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/o/osmose-emulator/osmose-emulator_1.3-1.dsc

  More information about Osmose Emulator can be obtained from 
https://gitlab.com/coringao/osmose-emulator/wikis.

  Changes since the last upload:

  osmose-emulator (1.3-1) unstable; urgency=medium

  * New upstream release (Closes: #844779, #868499)
  * debian/control:
+ Declare compliance with Debian Policy: 4.2.1
  * debian/copyright:
+ Year updated on 'Files: *'
  * Removed manpage from debian directory
  * d/manpage: Changed the localized path of the manpage
  * Removed autopkgtest considered an unjustified advantage
  * Year updated in debian/upstream/metadata
  * Updated d/watch

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#908447: plasma: Switch Display shortcut keys do not work in KDE Wayland

[Jiri Kanicky]

Package: plasma-desktop
Version: 4:5.13.5-1
Severity: normal
File: plasma

Dear Maintainer,

Switch Display shortcut keys (Meta + P) does not seem to work in KDE  Wayland 
while it works under X.

Repro steps:
Log into KDE Wayland
Attach second monitor
Press Meta + P
Nothing happens



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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.13.4-1
ii  kactivitymanagerd5.13.5-1
ii  kde-cli-tools4:5.13.5-1
ii  kded55.49.0-1
ii  kio  5.49.0-1
ii  kpackagetool55.49.0-1
ii  libappstreamqt2  0.12.2-2
ii  libc62.27-6
ii  libcanberra0 0.30-6
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-5
ii  libkf5activities55.49.0-1
ii  libkf5activitiesstats1   5.49.0-1
ii  libkf5archive5   5.49.0-1
ii  libkf5auth5  5.49.0-1
ii  libkf5baloo5 5.49.0-1
ii  libkf5codecs55.49.0-1
ii  libkf5completion55.49.0-1
ii  libkf5configcore55.49.0-1
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5declarative5   5.49.0-1
ii  libkf5emoticons-bin  5.49.0-1
ii  libkf5emoticons5 5.49.0-1
ii  libkf5globalaccel-bin5.49.0-1
ii  libkf5globalaccel5   5.49.0-1
ii  libkf5guiaddons5 5.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5iconthemes55.49.0-1
ii  libkf5itemmodels55.49.0-1
ii  libkf5itemviews5 5.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kcmutils5  5.49.0-1
ii  libkf5kdelibs4support5   5.49.0-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiofilewidgets55.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5newstuff5  5.49.0-1
ii  libkf5notifications5 5.49.0-1
ii  libkf5notifyconfig5  5.49.0-1
ii  libkf5package5   5.49.0-1
ii  libkf5parts5 5.49.0-1
ii  libkf5people55.49.0-1
ii  libkf5peoplewidgets5 5.49.0-1
ii  libkf5plasma55.49.0-1
ii  libkf5plasmaquick5   5.49.0-1
ii  libkf5quickaddons5   5.49.0-1
ii  libkf5runner55.49.0-1
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5solid5 5.49.0-1
ii  libkf5sonnetui5  5.49.0-1
ii  libkf5wallet-bin 5.49.0-1
ii  libkf5wallet55.49.0-1
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libkfontinst54:5.13.5-1
ii  libkfontinstui5  4:5.13.5-1
ii  libkworkspace5-5 4:5.13.5-1
ii  libphonon4qt5-4  4:4.10.1-1
ii  libpulse-mainloop-glib0  11.1-5
ii  libpulse011.1-5
ii  libqt5concurrent55.11.1+dfsg-7
ii  libqt5core5a 5.11.1+dfsg-7
ii  libqt5dbus5  5.11.1+dfsg-7
ii  libqt5gui5   5.11.1+dfsg-7
ii  libqt5network5   5.11.1+dfsg-7
ii  libqt5printsupport5  5.11.1+dfsg-7
ii  libqt5qml5   5.11.1-5
ii  libqt5quick5 5.11.1-5
ii  libqt5quickwidgets5  5.11.1-5
ii  libqt5sql5   5.11.1+dfsg-7
ii  libqt5svg5   5.11.1-2
ii  libqt5widgets5   

Bug#908439: gtk+3.0: FTBFS with gdk-pixbuf 2.38: /Default Values/GdkPixbuf: g_bytes_new: assertion 'data != NULL || size == 0' failed

[Simon McVittie]

Control: clone -1 -2
Control: severity -2 normal
Control: retitle -2 Assertion failure accessing pixel-bytes of 
default-constructed GdkPixbuf: data != NULL || size == 0
Control: forwarded -2 https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/91
Control: reassign -2 libgdk-pixbuf2.0-0 2.38.0+dfsg-4

I'm using #908439 for the gtk+3.0 FTBFS and the new clone for the
gdk-pixbuf bug.

On Mon, 10 Sep 2018 at 00:31:13 +0100, Simon McVittie wrote:
> (/srv/tmp/smcv/build-area/gtk+3.0-3.24.0/debian/build/deb/testsuite/gtk/.libs/defaultvalue:8467):
>  GLib-CRITICAL **: 00:19:27.089: g_bytes_new: assertion 'data != NULL || size 
> == 0' failed

#4  0x76ce4450 in gdk_pixbuf_get_property (object=0x55784b00, 
prop_id=9, value=0x7fffdad0, pspec=0x5582ad40) at 
../gdk-pixbuf/gdk-pixbuf.c:1345

Line 1345 is:

  case PROP_PIXEL_BYTES:
  g_value_set_boxed (value, gdk_pixbuf_read_pixel_bytes 
(pixbuf));

In the mode where the GdkPixbuf is backed by mutable pixels and not an
immutable GBytes structure, this returns:

return g_bytes_new (pixbuf->s.pixels.pixels,
gdk_pixbuf_get_byte_length (pixbuf));

where gdk_pixbuf_get_byte_length() returns:

   return ((pixbuf->height - 1) * pixbuf->rowstride +
pixbuf->width * ((pixbuf->n_channels * pixbuf->bits_per_sample 
+ 7) / 8));

(gdb) p *(GdkPixbuf *)object
$1 = {parent_instance = {g_type_instance = {Python Exception  No type named TypeNode.:
g_class = }, ref_count = 2, qdata = 0x0},
  colorspace = GDK_COLORSPACE_RGB, n_channels = 3, bits_per_sample = 8, width = 
1, height = 1, rowstride = 1,
  storage = STORAGE_PIXELS, s = {pixels = {pixels = 0x0, destroy_fn = 0x0, 
destroy_fn_data = 0x0}, bytes = {
  bytes = 0x0}}, has_alpha = 0}

So the calculation is that this 1x1 GdkPixbuf should have 3 bytes of
data, namely the R,G,B values of its single pixel.

You can reproduce this quicker in Python:

>>> from gi.repository import GdkPixbuf
>>> GdkPixbuf.Pixbuf().props.pixel_bytes
__main__:1: Warning: g_bytes_new: assertion 'data != NULL || size == 0' failed

Before 2.38 it would have returned NULL whenever not backed by a GBytes,
even if there was a non-NULL pixel data blob (which also seems like
a bug).

I think this is really a gdk-pixbuf bug, but we can work around it by not
testing the GdkPixbuf type in this way.

smcv

Bug#908445: geocode-glib: should run installed-tests as autopkgtests

[Jeremy Bicha]

Source: geocode-glib
Version: 3.26.0-1
Severity: wishlist

geocode-glib includes installed tests (which are used by
dh_auto_test). We should look into shipping the tests (probably in a
separate package named geocode-glib-tests), and run those tests with
autopkgtest.

Thanks,
Jeremy Bicha

Bug#908417: dgit does not handle debian/.gitignore missing from source package

[David Bremner]

Sean Whitton  writes:

> Based on discussion on IRC, I believe that the problem is that the
> options that dgit passes to dpkg-source, while sufficient to ensure that
> .gitignore is included in the resultant source package, are not
> sufficient to ensure that debian/.gitignore is included.  I.e. they do
> not properly override tar-ignore.
>
> David, could you provide steps to reproduce?  I.e. a repository and a
> git commit hash.

Hash: 8feec188a0bb3ed5dcda2c0e22c7645ca0d8f618
Repo:   https://git.notmuchmail.org/git/notmuch

If you look at branch release, you can see the dgit created merge after
that commit, and before the actual archive tag.

Bug#908444: RM: burn -- ROM; incompatible with current library interfaces

[Ben Finney]

Package: ftp.debian.org
Severity: normal

Please remove the package ‘burn’ from Debian. It uses libraries that
are no longer compatible with this program (see Bug#908296) and has
had no releases for many years.

-- 
 \   “An idea isn't responsible for the people who believe in it.” |
  `\  —Donald Robert Perry Marquis |
_o__)  |
Ben Finney

Bug#908443: eog: should run installed-tests as autopkgtests

[Jeremy Bicha]

Source: eog
Version: 3.28.3-1
Severity: wishlist

eog has an installed_tests option (defaults to false). We should look
into enabling the option, shipping the tests (probably in a separate
package named eog-tests), and run those tests with autopkgtest.

Thanks,
Jeremy Bicha

Bug#868499: osmose-emulator: No sound

[Carlos Donizete Froes]

tags 868499 fixed
thanks

Hi,

In this emulator, the audio device is not compatible with the "pulseaudio".

Even replacing "plughw:0,0" to "default" device will not work for some ordinary
laptop hardware sound cards.

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#908296: burn: Fails immediately with ImportError

[Ben Finney]

Control: tags -1 + confirmed upstream
Control: severity -1 severe
Control: retitle -1 burn: Fails immediately with ImportError

On 08-Sep-2018, Manuel Frassinetti wrote:

> ImportError: No module named eyeD3

Thank you for reporting this. It appears that the libraries ‘burn’
relies on, including eyeD3 and PyOgg, no longer work the way ‘burn’
expects.

I think this means the package is no longer suitable for Debian until
a major re-write of the upstream package is performed.

-- 
 \“The number of UNIX installations has grown to 10, with more |
  `\ expected.” —Unix Programmer's Manual, 2nd Ed., 1972-06-12 |
_o__)  |
Ben Finney 

signature.asc
Description: PGP signature

Bug#908442: lintian: package-contains-documentation-outside-usr-share-doc still false positives

[Jeremy Bicha]

Package: lintian
Version: 2.5.101
Severity: minor
X-Debbugs-CC: r...@debian.org

This is a follow-up from https://bugs.debian.org/907734
https://salsa.debian.org/lintian/lintian/commit/f6941026e6c0

Please make the template check more generic. I suggest looking for the
string "template" anywhere in the path name instead of just
"/templates/".

My specific test case is:
I: gnome-builder: package-contains-documentation-outside-usr-share-doc
usr/share/gnome-builder/plugins/autotools_templates/resources/CONTRIBUTING.md
I: gnome-builder: package-contains-documentation-outside-usr-share-doc
usr/share/gnome-builder/plugins/autotools_templates/resources/README.md

Thanks,
Jeremy Bicha

Bug#908441: Displays garbage in the prompt under screen, vim, nvim

[Josh Triplett]

Package: libvte-2.91-common
Version: 0.54.0-1
Severity: important
File: /etc/profile.d/vte-2.91.sh

The latest version of libvte changed this script to attempt to use the
single-byte versions of OSC and ST.  Unfortunately, this breaks in
screen, vim, nvim, and potentially other terminal programs, which don't
seem to handle that approach. Upstream reverted this change today, in
commit b3b3c3585528754a0923fcfc7a74126cd839784f. Could you please
cherry-pick that commit into the Debian package?

Thank you.

Bug#908440: gtk+3.0: should run installed-tests as autopkgtests

[Simon McVittie]

Source: gtk+3.0
Version: 3.22.30-2
Severity: wishlist

gtk+3.0 has had installed-tests since 3.9.2. These should probably be
installed in either gtk-3-examples or a new gtk-3-tests package, and
run by autopkgtest.

Regards,
smcv

Bug#887045: iwlwifi: TX_STATUS_FAIL_DEST_PS at iwlwifi/mvm/tx.c:1363 using hostapd

[Nye Liu]

Yes, this patch fixes the issue but I don't think it will actually appear in a 
release until 4.19 or even later. For now I have to hand patch home built 
kernels.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

[Dirk Eddelbuettel]

On 9 September 2018 at 18:10, Dirk Eddelbuettel wrote:
| 
| On 9 September 2018 at 18:49, John David Anglin wrote:
| | On 2018-09-09 6:45 PM, Dirk Eddelbuettel wrote:
| | > Now, one thing has me puzzled.  You say the build failed, but on the on
| | > status page hppa looks "green":
| | >
| | > https://buildd.debian.org/status/package.php?p=quantlib-swig
| | >
| | > Mind you, the entry is 'only' 21 hours old.  Everything else built four 
days ago.
| | I did a couple of builds to test the possibilities.  The only one that 
| | worked used -mlong-calls.
| | 
https://buildd.debian.org/status/logs.php?pkg=quantlib-swig=1.13-5=hppa
| 
| Great -- did not know you had access as you hadn't use a @d.o address, and I
| don't think we had met (or if so, my apologies).
| 
| That said, do you by chance overlap with the mips64el team or can get them?
| Their build needs a longer timeout :-/   It's a big package and it got killed
| after 150 of inactivity.  That can happen on low-power / low-memory machines.

I added mips64el to another one of the low-mem settings.  Current build diff 
below:

2 files changed, 13 insertions(+), 4 deletions(-)
debian/changelog |  7 +++
debian/rules | 10 ++

modified   debian/changelog
@@ -1,3 +1,10 @@
+quantlib-swig (1.13-6) unstable; urgency=medium
+
+  * debian/rules: Additional settings for hppa, plus cleanup. Thanks to
+John David Anglin for the -mlong-calls suggestion. (Closes: #908408)
+
+ -- Dirk Eddelbuettel   Sun, 09 Sep 2018 18:14:47 -0500
+
 quantlib-swig (1.13-5) unstable; urgency=medium
 
   [Michael Hudson-Doyle]
modified   debian/rules
@@ -37,9 +37,10 @@ cxxcompiler  = g++
 ## edd 26 Oct 2007  turn strict aliasing warning off
 ## edd 01 May 2011  add -fpermissive as g++ is more of a stickler
 ## edd 06 May 2011  remove -fpermissive with QL 1.1 betas
+## edd 09 Sep 2018  bringing over a few extra settings for hppa
 compilerflags  = -O2 -Wall -Wno-strict-aliasing -DBOOST_NO_AUTO_PTR
 ifeq ($(cpu),hppa)
-compilerflags   = -O2 -ffunction-sections -DBOOST_NO_AUTO_PTR
+compilerflags   = -O0 -g0 -mlong-calls -ffunction-sections --param 
ggc-min-expand=20 -DBOOST_NO_AUTO_PTR 
 #cxxcompiler   = g++-3.0
 endif
 
@@ -51,9 +52,10 @@ endif
 ## edd 27 May 2012  added mips/mipsel/armel/armhf here too
 ## edd 11 Mar 2015  remove powerpc and armhf from the list as they built 
on Ubuntu (cf
 ##  
https://launchpad.net/ubuntu/+source/quantlib-swig/1.5-1ubuntu1) and #779720)
-##  also remove mips, mipsel as they are getting care of 
below
+##  also remove mips, mipsel as they are getting taken 
care of below
+## edd 09 Sep 2018  adding mips64el here as well as it recently timed out
 #ifneq "$(findstring $(cpu), m68k arm armeb s390 powerpc armel armhf mips 
mipsel)" ""
-ifneq "$(findstring $(cpu), m68k arm armeb s390 armel)" ""
+ifneq "$(findstring $(cpu), m68k arm armeb s390 armel mips64el)" ""
 compilerflags   = -O0 -g0 -DBOOST_NO_AUTO_PTR
 endif
 
@@ -72,7 +74,7 @@ compilerflags   = -O0 -g0 --param ggc-min-expand=20 
-DBOOST_NO_AUTO_PTR
 endif
 
 ## edd 22 Aug 2018  trying to help a few other systems with their memory 
exhaustion
-ifneq "$(findstring $(cpu), hppa hurd-i386 kfreebsd-i386 m68k powerpc x32)" ""
+ifneq "$(findstring $(cpu), hurd-i386 kfreebsd-i386 m68k powerpc x32)" ""
 compilerflags   = -O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR
 endif
 

Again, big thank you for looking into hppa!

Dirk


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

Bug#908439: gtk+3.0: FTBFS with gdk-pixbuf 2.38: /Default Values/GdkPixbuf: g_bytes_new: assertion 'data != NULL || size == 0' failed

[Simon McVittie]

Source: gtk+3.0
Version: 3.24.0-1
Severity: serious
Justification: fails to build from source

While trying to address #908120 by reverting upstream commit 49b17e6c
"imwayland: clear preedit on focus out", I hit this unrelated test
failure (sorry, no debug symbols yet):

% debian/build/deb/libtool --mode=execute gdb 
debian/build/deb/testsuite/gtk/defaultvalue
...
(gdb) run
...
/Default Values/GdkPixbufError: OK
/Default Values/GdkPixbufFormat: OK
/Default Values/GdkPixbuf:
(/srv/tmp/smcv/build-area/gtk+3.0-3.24.0/debian/build/deb/testsuite/gtk/.libs/defaultvalue:8467):
 GLib-CRITICAL **: 00:19:27.089: g_bytes_new: assertion 'data != NULL || size 
== 0' failed

Thread 1 "defaultvalue" received signal SIGTRAP, Trace/breakpoint trap.
0x761779f5 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0  0x761779f5 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x76178d0d in g_logv () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x76178edf in g_log () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7614ad68 in g_bytes_new () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x76ce4450 in  () at 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#5  0x7625c8b8 in g_object_get_property () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x8838 in test_type (data=) at 
../../../../../testsuite/gtk/defaultvalue.c:373
#7  0x76198e7a in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x76198d34 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x76199132 in g_test_run_suite () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x76199151 in g_test_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x779b in main (argc=, argv=)
at ../../../../../testsuite/gtk/defaultvalue.c:495

Downgrading libgdk-pixbuf2.0-dev and closely related packages from
2.38.0+dfsg-4 to 2.36.12-2 resolves this. This might be either a
gdk-pixbuf or gtk+3.0 bug, I'm not sure yet.

Regards,
smcv

Bug#844779: osmose-emulator FTBFS on armel and armhf

[Carlos Donizete Froes]

tags 844779 fixed
thanks

Hi,

Fixed installation on ARM architectures since package version 1.2.

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

[Dirk Eddelbuettel]

On 9 September 2018 at 18:49, John David Anglin wrote:
| On 2018-09-09 6:45 PM, Dirk Eddelbuettel wrote:
| > Now, one thing has me puzzled.  You say the build failed, but on the on
| > status page hppa looks "green":
| >
| > https://buildd.debian.org/status/package.php?p=quantlib-swig
| >
| > Mind you, the entry is 'only' 21 hours old.  Everything else built four 
days ago.
| I did a couple of builds to test the possibilities.  The only one that 
| worked used -mlong-calls.
| 
https://buildd.debian.org/status/logs.php?pkg=quantlib-swig=1.13-5=hppa

Great -- did not know you had access as you hadn't use a @d.o address, and I
don't think we had met (or if so, my apologies).

That said, do you by chance overlap with the mips64el team or can get them?
Their build needs a longer timeout :-/   It's a big package and it got killed
after 150 of inactivity.  That can happen on low-power / low-memory machines.

Dirk

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

Bug#908417: dgit does not handle debian/.gitignore missing from source package

[Sean Whitton]

Hello,

On Sun 09 Sep 2018 at 06:07PM +0100, Ian Jackson wrote:

> I'm sorry to be dim, but I don't understand what you think the bug in
> dgit is ?  dgit's design principle is that the source package and git
> tree are idnntical.  Are you arguing that this is not correct ?

Based on discussion on IRC, I believe that the problem is that the
options that dgit passes to dpkg-source, while sufficient to ensure that
.gitignore is included in the resultant source package, are not
sufficient to ensure that debian/.gitignore is included.  I.e. they do
not properly override tar-ignore.

David, could you provide steps to reproduce?  I.e. a repository and a
git commit hash.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#907737: liblucy-perl: Project Lucy has retired

[Dominic Hargreaves]

On Sat, Sep 01, 2018 at 05:48:22PM +0100, Dominic Hargreaves wrote:
> On Sat, Sep 01, 2018 at 04:42:36PM +0200, Jonas Smedegaard wrote:
> > Quoting Xavier Guimard (2018-09-01 08:46:22)
> > > Package: liblucy-perl
> > > Version: Project Lucy has retired
> > > Severity: important
> > > 
> > > As announced in http://lucy.apache.org/, project Lucy has retired. I
> > > think we should remove it from buster
> > 
> > liblucy-perl has two reverse dependencies:
> > 
> >   * openguides
> >   * libcatmandu-store-lucy-perl
> > 
> > It is fine by me to drop libcatmandu-store-lucy-perl with liblucy-perl: 
> > Other Catmandu search backends exist but need to be packaged, but 
> > shipping no Catmandu search backend is better than shipping a backend 
> > dead upstream!
> > 
> > @Dominique: Is it ok to drop openguides, or can it be made to not depend 
> > on liblucy-perl?
> 
> I am still interested in OpenGuides (I run several instances using
> the Debian package).
> 
> I suspect not that many users use Lucy, so I'm fine with dropping that
> dependency. Please ping me in a couple of weeks if I haven't got around
> to that.

That's now done in openguides 0.82-2.

Thanks,
Dominic.

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

[John David Anglin]

On 2018-09-09 6:45 PM, Dirk Eddelbuettel wrote:

Now, one thing has me puzzled.  You say the build failed, but on the on
status page hppa looks "green":

https://buildd.debian.org/status/package.php?p=quantlib-swig

Mind you, the entry is 'only' 21 hours old.  Everything else built four days 
ago.
I did a couple of builds to test the possibilities.  The only one that 
worked used -mlong-calls.

https://buildd.debian.org/status/logs.php?pkg=quantlib-swig=1.13-5=hppa

--
John David Anglin  dave.ang...@bell.net

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

[Dirk Eddelbuettel]

On 9 September 2018 at 18:17, John David Anglin wrote:
| On 2018-09-09 3:01 PM, Dirk Eddelbuettel wrote:
| > | #    CXXFLAGS="-O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR
| > | -mlong-calls"                 \
| >
| > Right.
| -ffunction-sections isn't enough.  We need -mlong-calls.  We also need 
| the memory exhaustion
| work around.

Thank you. I think I should probably "fuse" the two entries for hppa.

Now, one thing has me puzzled.  You say the build failed, but on the on
status page hppa looks "green":

   https://buildd.debian.org/status/package.php?p=quantlib-swig

Mind you, the entry is 'only' 21 hours old.  Everything else built four days 
ago.

Dirk

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

Bug#908410: Fwd: Bug#908410: Acknowledgement (RFS: gradle-apt-plugin/0.10-1 [ITP])

[Emmanuel Bourg]

Hi Miroslav,

Le 09/09/2018 à 17:26, Miroslav Kravec a écrit :

> could you please take a look at this package, and sponsor upload, if
> the packaging correct?

Uploaded. Very good packaging, well done!

Emmanuel Bourg

Bug#908438: cubietruck wifi reversion

[Joey Hess]

Source: linux
Version: 4.17.17-1
Severity: normal

On a cubietruck board, the linux-image-4.17.0-3-armmp-lpae kernel kernel
fails to enable the builtin wifi:

Sep 09 17:52:52 honeybee kernel: brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43362-sdio for chip BCM43362/1
Sep 09 17:52:52 honeybee kernel: usbcore: registered new interface driver 
brcmfmac
Sep 09 17:52:52 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading 
firmware brcm/brcmfmac43362-sdio.bin
Sep 09 17:52:52 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading 
firmware brcm/brcmfmac43362-sdio.txt
Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on 
timeout
Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_bus_started: failed: -110
Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_attach: dongle is not 
responding: err=-110
Sep 09 17:52:55 honeybee kernel: brcmfmac: brcmf_sdio_firmware_callback: 
brcmf_attach failed

This was working using linux-image-4.14.0-3-armmp-lpae and earlier kernels
including stable's, so seems to be a reversion.

I have firmware-brcm80211 installed. I tried downgrading it to the same
version I was using with the older kernel (20170823-1), but that did not help,
so I don't think it's a problem with the firmware.

Here it is working with the older kernel, for comparison:

Sep 09 18:06:10 honeybee kernel: brcmfmac: brcmf_fw_map_chip_to_name: using 
brcm/brcmfmac43362-sdio.bin for chip 0x00a962(43362) rev 0x01
Sep 09 18:06:10 honeybee kernel: usbcore: registered new interface driver 
brcmfmac
Sep 09 18:06:10 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading 
firmware brcm/brcmfmac43362-sdio.bin
Sep 09 18:06:10 honeybee kernel: brcmfmac mmc1:0001:1: firmware: direct-loading 
firmware brcm/brcmfmac43362-sdio.txt
Sep 09 18:06:10 honeybee kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware 
version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

[John David Anglin]

On 2018-09-09 3:01 PM, Dirk Eddelbuettel wrote:

| #    CXXFLAGS="-O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR
| -mlong-calls"                 \

Right.
-ffunction-sections isn't enough.  We need -mlong-calls.  We also need 
the memory exhaustion

work around.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#898306: [spl] Conflicts with splat, but should not

[Antonio Russo]

This is really bug 894608 again. The long and short of that is: uninstall spl.
You do not need it (spl-dkms, on the other hand, is ABSOLUTELY essential).

Bug#906462: i will ITS this

[bill auger]

please do try to keep this package from being dropped

i am the upstream maintainer and i have been trying for about 18 months to 
contact debian user piem about this package; and working with the MIA team for 
over a year - the upstream repo is is good shape with up-to-date autotools, 
with the current debian patches applied, and several other bug fixes

starting in october, there is set to be a new package salvaging procedure in 
place and i was advised by tobias on the MIA team that i could start the 
procedure for adopting the package at that time

Bug#908369: Terminal cursor disappears if terminal loses focus

[Simon McVittie]

Control: reassign -1 libgtk-3-0 3.24.0-1
Control: forcemerge 908120 -1

On Sun, 09 Sep 2018 at 00:56:39 -0700, Cody Brownstein wrote:
> When I open a terminal, e.g., `gnome-terminal` or `tilix`, the cursor
> will display normally as long I do not switch to another window.
> However, once I switch to another window, then switch back to the
> terminal, the cursor disappears.

This appears to be a GTK+ 3.24 regression. For now please downgrade
libgtk-3-0 to version 3.22.x from testing.

smcv

Bug#908434: gnome-terminal: Text cursor disappears when focus lost in Wayland

[Simon McVittie]

Control: reassign -1 libgtk-3-0 3.24.0-1
Control: forcemerge 908120 -1

On Sun, 09 Sep 2018 at 22:29:34 +0200, Claudio Sacerdoti Coen wrote:
> when gnome-terminal is started in a Wayland session, when the terminal
> looses focus the blinking cursor disappears and it remains invisible
> forever. The only way to make it re-appear is to switch to another tab
> and back.

This is #908120, a GTK+ regression. For now please downgrade libgtk-3-0
(and the other packages that are in lockstep with it) to version 3.22.x
from testing.

> The bug applies to lxterminal as well.

This is a heavy hint that it is a bug in either a library or the desktop
environment, not in gnome-terminal.

smcv

Bug#908422: Cursor disappears after switching away from and back to gnome-terminal

[Simon McVittie]

Control: reassign -1 libgtk-3-0 3.24.0-1
Control: forcemerge -1 908120
Control: affects 908120 gnome-terminal
Control: affects 908120 libvte-2.91-0
Control: severity 908120 serious

On Sun, 09 Sep 2018 at 12:54:46 -0700, Josh Triplett wrote:
> Since upgrading to gnome-terminal 3.30, the cursor in the widow
> disappears when switching away from the gnome-terminal window and back.
> Switching tabs makes it reappear, but nothing else seems to do so.

This is believed to be a GTK regression, #908120.

smcv

Bug#906878: xul-ext-sage no longer works with firefox-esr 60

[Moritz Mühlenhoff]

On Tue, Aug 21, 2018 at 09:52:20PM +0300, Adrian Bunk wrote:
> Package: xul-ext-sage
> Version: 1.5.4-2
> Severity: serious
> 
> XUL addons are no longer supported. 

Per https://github.com/petea/sage/issues/154 I doubt this will get
ported, removal seems like the sanest option (also for stretch).

Cheers,
Moritz

Bug#908120: Bug#908422: Cursor disappears after switching away from and back to gnome-terminal

[Josh Triplett]

On Sun, Sep 09, 2018 at 04:17:22PM -0400, Jeremy Bicha wrote:
> On Sun, Sep 9, 2018 at 3:57 PM Josh Triplett  wrote:
> > Since upgrading to gnome-terminal 3.30, the cursor in the widow
> > disappears when switching away from the gnome-terminal window and back.
> > Switching tabs makes it reappear, but nothing else seems to do so.
> 
> I believe this and https://bugs.debian.org/908369 are duplicates of
> https://bugs.debian.org/908120 which we believe is a GTK 3.24 bug.
> 
> By the way, I think your test case isn't specific enough. It depends
> on how you switch to the terminal window. On GNOME Wayland, I wasn't
> able to reproduce with Alt+Tab or regular clicking on the window but I
> could if I used the Activities Overview.

I'm running latest GNOME from unstable, on Wayland, and I see the issue
whether I switch windows with alt-tab, clicking, the overview, or by
opening/closing a new window.

Bug#874961: [Pkg-kde-extras] Bug#874961: kmymoney: not ready for Qt5

[Pino Toscano]

In data domenica 9 settembre 2018 15:11:52 CEST, Micha Lenk ha scritto:
> This is a short heads up that I intend to remove support for Qt4 from
> libgwenhywfar on September 13th 2018. This will be done by dropping the
> binary packages libgwengui-qt4-0 and libgwengui-qt4-dev from the
> archive. As a consequence this will cause kmymoney to fail to build from
> source in unstable due to the build dependency libgwengui-qt4-dev
> becoming unavailable.

Well, thanks for the uncooperative pressure.  This is not helpful,
given the current state of kmymoney (see below).

> A fixed version of kmymoney that doesn't fail to build is already
> available in experimental. So, please consider uploading that version to
> unstable to fix this issue.

kmymoney 5.0.0 was the first version ported to Qt5/KF5, and was released
after more than 2 years of upstream work, which included the actual
Qt4->Qt5 and kdelibs4->KF5 switch. From my inspection of the release,
there were bugs and regressions, and even the bugfix release 5.0.1 does
not fix all of them.
Sadly, the status of the development upstream is:
- lots of refactoring commits, much less about fixing actual issues
- stable branches sometimes get fixes, but then upstream almost does
  not get to stabilize them into new bugfix releases (e.g. one year
  between 4.8.0 and 4.8.1)

Upstream should release a 5.0.2 at the end of this month. My plan is to
upload that to experimental, and see what's the feedback from users
(not only Debian ones).

Considering that kmymoney is not a game nor a text editor, but an
application that deals with personal money (and performs also online
financial transactions), I was not confortable in uploading a new 5.0.0
(or even 5.0.1) to unstable "just because". Of course YMMV on this.

Bottom line: if you make the rest of the work in unstable, even for
the kdelibs4 version, harder for us (or me, at least), that would be
very uncooperative, and really uncalled for.

And yes, I already know that kmymoney will be autoremoved from testing
on 13th: this is thanks to another uncooperative DD, who likes to poke
his nose into packages who he has no idea about.

Thanks,
-- 
Pino Toscano

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

Bug#908437: firefox: black screen if AppArmor blocks /dev/shm/org.chromium.*

[Rebecca N. Palmer]

Package: apparmor-profiles
Version: 2.13-8
Control: tags -1 patch
Control: affects -1 src:firefox src:firefox-esr

Firefox now uses /dev/shm in its multiprocess sandboxing.  If AppArmor 
blocks this (I was using a custom profile, but the packaged profile 
appears to have the same problem), the Firefox window (both webpage area 
and toolbars) is all-black.


This affects Firefox 60 but not 52, in stretch.

Fix: add these lines to the profile:
  owner /dev/shm/org.chromium.* rwlk,
  owner /dev/shm/org.mozilla.* rwlk,

(60 uses org.chromium.* , later uses org.mozilla.* : 
https://hg.mozilla.org/mozilla-central/rev/83bab8cf29bf )


Reported elsewhere as
https://bugzilla.mozilla.org/show_bug.cgi?id=1334748
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1660031

(The additional permissions suggested in
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1770600
are *not* currently required to make Firefox work, and probably can't 
enable the user-namespace-based sandboxing because 
/proc/sys/kernel/unprivileged_userns_clone is off by default.)

Bug#908115: RM: downthemall -- ROM; not useful anymore

[Adam D. Barratt]

On Sun, 2018-09-09 at 22:42 +0200, Moritz Mühlenhoff wrote:
> On Thu, Sep 06, 2018 at 12:20:23PM +0200, Michael Meskes wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > With the xul extension going away this package is no longer useful.
> > Please remove.
> 
> With the migration to ESR60, this also affects stretch. Please also
> request a removal from stable via the release.debian.org pseudo bug.

That's already #908404.

Regards,

Adam

Bug#874237: z3: diff for NMU version 4.4.1-0.4

[Adrian Bunk]

Control: tags 874237 + patch
Control: tags 874237 + pending

Dear maintainer,

I've prepared an NMU for z3 (versioned as 4.4.1-0.4) and uploaded
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru z3-4.4.1/debian/changelog z3-4.4.1/debian/changelog
--- z3-4.4.1/debian/changelog	2016-09-26 08:28:12.0 +0300
+++ z3-4.4.1/debian/changelog	2018-09-09 22:28:32.0 +0300
@@ -1,3 +1,11 @@
+z3 (4.4.1-0.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove the incorrect Multi-Arch: same of python-z3,
+thanks to Helmut Grohne. (Closes: #874237)
+
+ -- Adrian Bunk   Sun, 09 Sep 2018 22:28:32 +0300
+
 z3 (4.4.1-0.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru z3-4.4.1/debian/control z3-4.4.1/debian/control
--- z3-4.4.1/debian/control	2016-07-20 14:07:58.0 +0300
+++ z3-4.4.1/debian/control	2018-09-09 22:28:32.0 +0300
@@ -61,7 +61,6 @@
 Package: python-z3
 Section: python
 Architecture: any
-Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: libz3-dev (= ${binary:Version}), ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
 Description: theorem prover from Microsoft Research - Python bindings

Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64

[Hans van Kranenburg]

On 06/09/2018 18:23, Hans van Kranenburg wrote:
> 
> Anyway, I think the future proof solution here is to have clear
> documentation about how to configure related settings, instead of trying
> to find values that suit all users and that are not ridiculously high.

I just assisted a user in #xen on freenode with this exact issue again.

The user had already experienced three maintenance windows in which it
was tried to upgrade a domU with quite some big sized disks and cpus
from Jessie to Stretch, every time failing again with random symptoms.
Disk doesn't work, network does not ping, and had spent quite some hours
searching for solutions already.

This reminded me of something else... which is better error logging when
the issue happens. This is an upstream thing to fix I guess, if
possible. As soon as there's a useful error message in logging or on the
console of the domU, then the user has something specific to search for
on ze interwebz.

Hans

Bug#908195: openssh-server: agent forwarding broken in incoming ssh connections

[Timo Weingärtner]

Hallo Giacomo Mulas,

08.09.18 10:16 Giacomo Mulas:
> On Fri, 7 Sep 2018, Timo Weingärtner wrote:
> > So the connection to some ssh-agent is working. Please check which process
> > owns the socket pointed to by $SSH_AUTH_SOCK. If it is not sshd you have
> > another problem; perhaps something like libpam-ssh is starting a new
> > ssh-agent for your ssh session?
> 
> ls -l $SSH_AUTH_SOCK yields
> 
> srw--- 1 gmulas ssh 0 set  8 10:05 /tmp/ssh-TteIoyXhPTF2/agent.14983=
> 
> whereas lsof $SSH_AUTH_SOCK yields nothing run as regular user and
> lsof /tmp/ssh-TteIoyXhPTF2/agent.14983= run as root yields
> 
> COMMAND PID   USER   FD   TYPE DEVICE SIZE/OFFNODE NAME
> ssh-agent 14984 gmulas3u  unix 0x4846ae07  0t0 6314996
> /tmp/ssh-TteIoyXhPTF2/agent.14983 type=STREAM
> 
> the parent ID of this ssh-agent is 1 (?)

That's normal when it was started without a command to run.

> I hope this can help. Please let me know if there is something else I can do
> to track the problem.

For me the problem can be reproduced by installing libpam-ssh.

openssh 7.8 + libpam-ssh: broken
openssh 7.4 + libpam-ssh: works
any openssh + no libpam-ssh: works

The problem might be that libpam-ssh starts an ssh-agent and sets 
SSH_AUTH_SOCK regardless of whether an agent is forwarded and newer openssh-
server doesn't change SSH_AUTH_SOCK pointing to its own socket?


Grüße
Timo

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

Bug#908436: AttributeError: 'AWSHTTPSConnection' object has no attribute 'ssl_context'

[Ruben Undheim]

Package: python3-boto3
Version: 1.4.2-1
Severity: important
Tags: stretch


Dear Maintainer,

Calling client.upload_file with the python3-boto3 version in Stretch crashes.
In sid it works fine.
:

  Traceback (most recent call last):
File "./upload.py", line 23, in 
  tofile)  # Name for remote file
File "/usr/lib/python3/dist-packages/boto3/s3/inject.py", line 105, in 
upload_file
  extra_args=ExtraArgs, callback=Callback)
File "/usr/lib/python3/dist-packages/boto3/s3/transfer.py", line 245, in 
upload_file
  future.result()
File "/usr/lib/python3/dist-packages/s3transfer/futures.py", line 71, in 
result
  return self._coordinator.result()
File "/usr/lib/python3/dist-packages/s3transfer/futures.py", line 231, in 
result
  raise self._exception
File "/usr/lib/python3/dist-packages/s3transfer/tasks.py", line 126, in 
__call__
  return self._execute_main(kwargs)
File "/usr/lib/python3/dist-packages/s3transfer/tasks.py", line 150, in 
_execute_main
  return_value = self._main(**kwargs)
File "/usr/lib/python3/dist-packages/s3transfer/upload.py", line 679, in 
_main
  client.put_object(Bucket=bucket, Key=key, Body=body, **extra_args)
File "/usr/lib/python3/dist-packages/botocore/client.py", line 251, in 
_api_call
  return self._make_api_call(operation_name, kwargs)
File "/usr/lib/python3/dist-packages/botocore/client.py", line 526, in 
_make_api_call
  operation_model, request_dict)
File "/usr/lib/python3/dist-packages/botocore/endpoint.py", line 141, in 
make_request
  return self._send_request(request_dict, operation_model)
File "/usr/lib/python3/dist-packages/botocore/endpoint.py", line 170, in 
_send_request
  success_response, exception):
File "/usr/lib/python3/dist-packages/botocore/endpoint.py", line 249, in 
_needs_retry
  caught_exception=caught_exception, request_dict=request_dict)
File "/usr/lib/python3/dist-packages/botocore/hooks.py", line 227, in emit
  return self._emit(event_name, kwargs)
File "/usr/lib/python3/dist-packages/botocore/hooks.py", line 210, in _emit
  response = handler(**kwargs)
File "/usr/lib/python3/dist-packages/botocore/retryhandler.py", line 183, 
in __call__
  if self._checker(attempts, response, caught_exception):
File "/usr/lib/python3/dist-packages/botocore/retryhandler.py", line 251, 
in __call__
  caught_exception)
File "/usr/lib/python3/dist-packages/botocore/retryhandler.py", line 269, 
in _should_retry
  return self._checker(attempt_number, response, caught_exception)
File "/usr/lib/python3/dist-packages/botocore/retryhandler.py", line 317, 
in __call__
  caught_exception)
File "/usr/lib/python3/dist-packages/botocore/retryhandler.py", line 223, 
in __call__
  attempt_number, caught_exception)
File "/usr/lib/python3/dist-packages/botocore/retryhandler.py", line 359, 
in _check_caught_exception
  raise caught_exception
File "/usr/lib/python3/dist-packages/botocore/endpoint.py", line 204, in 
_get_response
  proxies=self.proxies, timeout=self.timeout)
File "/home/ruben/.local/lib/python3.5/site-packages/requests/sessions.py", 
line 618, in send
  r = adapter.send(request, **kwargs)
File "/home/ruben/.local/lib/python3.5/site-packages/requests/adapters.py", 
line 440, in send
  timeout=timeout
File 
"/home/ruben/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", 
line 601, in urlopen
  chunked=chunked)
File 
"/home/ruben/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", 
line 346, in _make_request
  self._validate_conn(conn)
File 
"/home/ruben/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", 
line 850, in _validate_conn
  conn.connect()
File 
"/home/ruben/.local/lib/python3.5/site-packages/urllib3/connection.py", line 
311, in connect
  if self.ssl_context is None:
  AttributeError: 'AWSHTTPSConnection' object has no attribute 'ssl_context'


Probably related to #854382


Best regards
Ruben


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

Kernel: Linux 4.9.0-8-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)

Versions of packages python3-boto3 depends on:
ii  python3 3.5.3-1
ii  python3-botocore1.4.70-1
ii  python3-jmespath0.9.0-2
ii  python3-requests2.12.4-1
ii  python3-s3transfer  0.1.9-1
ii  python3-six 1.10.0-3

python3-boto3 recommends no packages.

python3-boto3 suggests no packages.

-- debconf-show failed

Bug#855092: beets: FTBFS randomly (failing tests)

[Santiago Vila]

Hello Stefano.

You wrote this in the changelog:

 * Skip some tests that seem to commonly fail in builds /
 autopkgtests, and are causing more annoyance than value. This will
 probably need to be extended.

Indeed, it needs to be extended.

Here is an updated bunch of build logs for the current version:

https://people.debian.org/~sanvila/build-logs/beets/

Thanks.

Bug#908115: RM: downthemall -- ROM; not useful anymore

[Moritz Mühlenhoff]

On Thu, Sep 06, 2018 at 12:20:23PM +0200, Michael Meskes wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> With the xul extension going away this package is no longer useful. Please 
> remove.

With the migration to ESR60, this also affects stretch. Please also request
a removal from stable via the release.debian.org pseudo bug.

Cheers,
   Moritz

Bug#878425: it's all text will stop working in Firefox 57

[Moritz Mühlenhoff]

On Fri, Oct 13, 2017 at 10:53:28AM -0400, Antoine Beaupre wrote:
> Package: xul-ext-itsalltext
> Version: 1.9.2-2
> Severity: normal
> Tags: upstream
> 
> Once Firefox 57 hits the archive, this extension will completely stop
> working, as it relies on the older XUL API. It also cannot be ported
> to the new web-ext API cleanly, as it is a fundamental shift in the
> way it works:

This is now affecting even stable. Upstream makes it clear that no
conversion to web extensions is planned (as it would require a complete
rewrite).

@David, let's turn this into a removal bug.

Cheers,
Moritz

Bug#908435: RFS: downtimed/1.0-2

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal


  Dear mentors,

  I am looking for a sponsor for my package "downtimed"

   Package name: downtimed
   Version : 1.0-2
   Upstream Author : Janne Snabb 
   URL : https://dist.epipe.com/downtimed/
   License : BSD-2-clause
   Section : admin

  It builds those binary packages:

downtimed  - monitor of downtime, shutdown, and crashes

  To access further information about this package, please visit the
following URL:

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


  Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/d/downtimed/downtimed_1.0-2.dsc

or

  git: https://jff.email/cgit/downtimed.git/?h=release%2Fdebian%2F1.0-2


  
  Changes since the last upload:

  * Change to my new email address.
  * New README.source to explain the branching model used.
  * Migrate to debhelper 11:
- Change debian/compat to 11.
- Bump minimum debhelper version in debian/control to >= 11.
- Remove --with=systemd from debian/rules.
- Remove build depends dh-systemd from debian/control.
  * Declare compliance with Debian Policy 4.2.1 (No changes needed).
  * Remove deprecated upstart file downtimed.upstart.
  * Remove old unused patches.
  * debian/control:
- Change Vcs-* to point to the new repository.
- Change Priority extra to optional.
  * debian/copyright:
- Use secure URI for copyright format and source.
- Move paragraph for * to frist position.
- Refresh years for debian/*.
  * debian/watch:
- Use secure URI.


  Regards,
   Jörg Frings-Fürst


- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAluVg0IACgkQCfifPIyh
0l1jsRAAi4rwiHKf92Id5gGbf3tUjPE4INu3h57zoqoIJp8VhCsbAHb68nzy8Wy4
hALYfnDl3uwo2ZcoHaSOc3JUoKwYs47g6Zxe6DpOiAOrYRlBzSRGScKi6Rkcr0Z0
zOYMkUiAySmVbvJ8aZjcqeDjlA2oFPOwUPEjcqoEeiHMgPWnQngdoYZCrBWJK0sU
J+kpV162SbCR+TumvmseWegnUYR+7gqMBehDigoCu2V6yM9RabyNjrwYoXTbGr4A
eb3vattplbs76vNXBq3WpxXuXZt7Dh85jFudvIF1uRDDvqr0VoM6pLfPgDThy4YJ
j6k3F1wjO1pnE0SDfzWbphVbYbYW90kD9nwe+x4DFhdt9r0oKyBj7i06LhyIP3cv
h7xPaLNx118DTbWS1ZtCcscbNQHCqeLiHJLp+QI8PMeVSowuF1Wm7at3I4jgkN9k
r6j/p1GlgEP6d3FsPyF6MwdkTidZk9WPDwpsd7lKMjwOOKFE1YPkZaJZzYjbcMwl
7wxiNaap2rIHF+xgft53PlG6XSxkknJxljecAwgPWCVv7djnC+v4clgD31zMDZ2V
AJT/cksMw4dE33km1EJ2muvKQpZft4iAQHb2KEvgc+Gjel4is3PY4sCzPSRXEncm
t5u6ar6ubHSlzvl2t3XuOt70mZdVjgwBwmE0oDMFpsvbLhY1CSw=
=ystd
-END PGP SIGNATURE-

Bug#908434: gnome-terminal: Text cursor disappears when focus lost in Wayland

[Claudio Sacerdoti Coen]

Package: gnome-terminal
Version: 3.30.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

when gnome-terminal is started in a Wayland session, when the terminal
looses focus the blinking cursor disappears and it remains invisible
forever. The only way to make it re-appear is to switch to another tab
and back.

The bug applies to lxterminal as well. Starting lxterminal with
GDK_BACKEND=x11 or starting gnome in X11 makes the bug disappear.

Notes:
1. I noticed the bug last Friday when gnome-terminal was 3.28.2-1. I
waited for the 3.30.xx version, but the bug is still here
2. The bug was not there before upgrading gnome-shell, mutter and
related libs to 3.29/3.30. Therefore I suspect that the bug is due to
one of them.

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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.0-1
ii  gnome-terminal-data   3.30.0-1
ii  gsettings-desktop-schemas 3.28.0-1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libdconf1 0.30.0-1
ii  libglib2.0-0  2.58.0-3
ii  libgtk-3-03.24.0-1
ii  libpango-1.0-01.42.4-3
ii  libuuid1  2.32.1-0.1
ii  libvte-2.91-0 0.54.0-1
ii  libx11-6  2:1.6.6-1
Versions of packages gnome-terminal recommends:
ii  gvfs   1.36.2-1
ii  nautilus-extension-gnome-terminal  3.30.0-1
ii  yelp   3.30.0-1

gnome-terminal suggests no packages.

-- no debconf information

-- 
Prof. Claudio Sacerdoti Coen
Department of Computer Science and Engineering
University of Bologna

Bug#908120: Bug#908422: Cursor disappears after switching away from and back to gnome-terminal

[Jeremy Bicha]

On Sun, Sep 9, 2018 at 3:57 PM Josh Triplett  wrote:
> Since upgrading to gnome-terminal 3.30, the cursor in the widow
> disappears when switching away from the gnome-terminal window and back.
> Switching tabs makes it reappear, but nothing else seems to do so.

I believe this and https://bugs.debian.org/908369 are duplicates of
https://bugs.debian.org/908120 which we believe is a GTK 3.24 bug.

By the way, I think your test case isn't specific enough. It depends
on how you switch to the terminal window. On GNOME Wayland, I wasn't
able to reproduce with Alt+Tab or regular clicking on the window but I
could if I used the Activities Overview.

Thanks,
Jeremy Bicha

Bug#908433: skimage build depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Source: skimage
Version: 0.14.0-1
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#908432: xul-ext-webdeveloper depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: xul-ext-webdeveloper
Version: 1.2.13-1
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#908430: salt-doc depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: salt-doc
Version: 2017.7.4+dfsg1-1
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#622933: zsh: Enable completions by default, unless skip_global_compinit is set

[TS]

Hello Frank,

again i learned sth. useful. THANKS!

Replying here because i think the patch that never got applied
should look like:

-  ((#i)on|yes|enable|1) ;;
+  ((#i)(on|yes|enable|1)) ;;

best regards,


 Thilo

Bug#908431: sympa depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: sympa
Version: 6.2.32~dfsg-2
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#908364: [Pkg-rust-maintainers] Bug#908364: Bug#908366: librust-cc+parallel-dev: unsatisfiable dependency on librust-rayon-1+default-dev

[Ximin Luo]

Ximin Luo:
> Steve Langasek:
>> On Sun, Sep 09, 2018 at 05:14:00PM +, Ximin Luo wrote:
>>> Please see bug 904485 https://bugs.debian.org/904485
>>
>>> The bug is not in this package but in the speed of our packaging and the
>>> NEW queue.  If you help us package nodrop-union etc that will help the
>>> situation.
>>
>> On Sun, Sep 09, 2018 at 05:14:00PM +, Ximin Luo wrote:
>>
>>> The bug is not in this package but in the speed of our packaging and the
>>> NEW queue.  If you help us package nodrop-union etc that will help the
>>> situation.
>>
>> I have no interest in working on the packaging for these packages, I am only
>> trying to work out why unreleasable packages are finding their way into
>> Ubuntu as part of package syncs.
>>
>> This is definitely not caused by issues of NEW queue processing speed as the
>> dependencies in question are not in the NEW queue at all.  This is a matter
>> of dependency stacks being uploaded out of order.  Why are rust packages
>> being uploaded to Debian out of dependency order?
>>
> 
> There are three types of dependencies, it is being uploaded in dependency 
> order of one type but not the other two types. This is inevitable due to 
> cargo's design, see https://github.com/kpcyrd/cargo-debstatus/issues/2 for 
> details.
> 

Furthermore there is also a bug in Britney which is why you might be seeing 
some issues in Ubuntu package sync, see 
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2018-September/002574.html
 for details.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#908429: r-cran-shiny (build) depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: r-cran-shiny
Version: 1.1.0+dfsg-1
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#908427: nzbget depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: nzbget
Version: libjs-twitter-bootstrap
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#908428: php-codecoverage (build) depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: php-codecoverage
Version: 6.0.7+dfsg-1
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#908364: [Pkg-rust-maintainers] Bug#908364: Bug#908366: librust-cc+parallel-dev: unsatisfiable dependency on librust-rayon-1+default-dev

[Ximin Luo]

Steve Langasek:
> On Sun, Sep 09, 2018 at 05:14:00PM +, Ximin Luo wrote:
>> Please see bug 904485 https://bugs.debian.org/904485
> 
>> The bug is not in this package but in the speed of our packaging and the
>> NEW queue.  If you help us package nodrop-union etc that will help the
>> situation.
> 
> On Sun, Sep 09, 2018 at 05:14:00PM +, Ximin Luo wrote:
> 
>> The bug is not in this package but in the speed of our packaging and the
>> NEW queue.  If you help us package nodrop-union etc that will help the
>> situation.
> 
> I have no interest in working on the packaging for these packages, I am only
> trying to work out why unreleasable packages are finding their way into
> Ubuntu as part of package syncs.
> 
> This is definitely not caused by issues of NEW queue processing speed as the
> dependencies in question are not in the NEW queue at all.  This is a matter
> of dependency stacks being uploaded out of order.  Why are rust packages
> being uploaded to Debian out of dependency order?
> 

There are three types of dependencies, it is being uploaded in dependency order 
of one type but not the other two types. This is inevitable due to cargo's 
design, see https://github.com/kpcyrd/cargo-debstatus/issues/2 for details.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#908426: metaphlan2 depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: metaphlan2
Version: 2.7.6-1
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#908425: grafana-data depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: grafana-data
Version: 2.6.0+dfsg-3
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#895640: [PKG-Openstack-devel] Bug#895640: closed by Thomas Goirand (Bug#895640: fixed in openstack-trove 1:10.0.0-1)

[Thomas Goirand]

On 09/09/2018 01:02 PM, Adrian Bunk wrote:
> Control: reopen -1
> 
> On Sat, Sep 08, 2018 at 03:21:04PM +, Debian Bug Tracking System wrote:
>> ...
>>  openstack-trove (1:10.0.0-1) unstable; urgency=medium
>> ...
>>* New upstream release:
>>  - Fixes FTBFS: test failures (Closes: #895640).
>> ...
> 
> Doesn't seem so:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/openstack-trove.html
> 
> cu
> Adrian
> 

Adrian,

I've tried adding:
export http_proxy=127.0.0.1:9 ; \
export https_proxy=127.0.0.1:9 ; \
export HTTP_PROXY=127.0.0.1:9 ; \
export HTTPS_PROXY=127.0.0.1:9 ; \
RES_OPTIONS=attempts:0 \

before running unit tests, but they still do pass on my laptop.

I also compared a few dependencies downloaded by sbuild, just in case
having http://incoming.debian.org/debian-buildd in my .gbp.conf is an
issue, but found nothing either.

Now I'm out of idea...

I really don't know how to reproduce the thing seen at
reproduciblebuild.org. Any idea?

Cheers,

Thomas Goirand (zigo)

Bug#908424: python-flower (build) depends on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Package: python-flower
Version: 0.8.3+dfsg-3
Severity: serious
Control: block 907724 by -1

See #907724 for background.

Bug#908423: python{,3}-django-oauth-toolkit depend on libjs-twitter-bootstrap that will not be in buster

[Adrian Bunk]

Source: django-oauth-toolkit
Version: 1.1.2-1
Severity: serious
Control: block 907724 by -1
Control: affects -1 python-django-oauth-toolkit python3-django-oauth-toolkit

See #907724 for background.

Bug#908422: Cursor disappears after switching away from and back to gnome-terminal

[Josh Triplett]

Package: gnome-terminal
Version: 3.30.0-1
Severity: important

[Severity because this represents a major usability issue in
gnome-terminal.]

Since upgrading to gnome-terminal 3.30, the cursor in the widow
disappears when switching away from the gnome-terminal window and back.
Switching tabs makes it reappear, but nothing else seems to do so.

I've confirmed that this occurs regardless of the value of the
org.gnome.desktop.interface.cursor-blink setting.


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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.0-1
ii  gnome-terminal-data   3.30.0-1
ii  gsettings-desktop-schemas 3.28.0-1
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.27-6
ii  libdconf1 0.30.0-1
ii  libglib2.0-0  2.58.0-3
ii  libgtk-3-03.24.0-1
ii  libpango-1.0-01.42.4-3
ii  libuuid1  2.32.1-0.1
ii  libvte-2.91-0 0.54.0-1
ii  libx11-6  2:1.6.6-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.36.2-1
pn  nautilus-extension-gnome-terminal  
ii  yelp   3.30.0-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#908349: Aw: Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2

[Stephan Goll]

> Re: Bug#908349: firefox-esr: no sound after upgrading from 52.9 to 60.2
>
> Hello,
> 
> Stephan Goll, le sam. 08 sept. 2018 21:11:46 +0200, a ecrit:
> > Seems that this build is not compiled with alsa, but the dependencies does 
> > not require pulseaudio.
> > Please rebuild this ff with --enable-alsa.
> 
> Unfortunately AIUI upstream has stopped supporting ALSA, so we are stuck
> with pulseaudio for firefox.
> 
> Samuel
> 
Thanks Samuel,
I was afraid of this. Can we have jack instead of pulseaudio? Will 
--enamle-jack work with the new firefox? Please have a look at 
http://www.zamaudio.com/?p=1580
-- 
Stephan

Bug#908365: Package fails to build reproducibly

[Chris Lamb]

Chris Lamb wrote:

> (Sorry to be a downer but I wouldn't want to give the impression this
> was so "easily" remedied. Alas.)

Spent a couple moments on this. The first thing that can be addressed
is the absolute CATALOG_DIR which ends up in the /usr/lib/systemd/
tests/test-catalog binary in the systemd-tests package.

This dir is currently "useless" in that it will fail on (almost) all
end- user systems as it points into the original build path, eg, /tmp/
buildd.

Can this variable be provided on the command line? If so, you will need
to also ship the actual catalogs too.


Alternatively, you could do something dumb like:
  
  --- a/debian/rules  2018-09-09 17:51:44.321868919 +0100
  --- b/debian/rules  2018-09-09 20:28:31.894763652 +0100
  @@ -255,6 +255,9 @@
  install --mode=755 debian/extra/set-cpufreq 
debian/systemd/lib/systemd/
   endif
   
  +   # Unreproducible?
  +   rm -f debian/systemd-tests/usr/lib/systemd/tests/test-catalog
  +
   override_dh_missing:
  dh_missing --sourcedir debian/install/deb $(DH_MISSING)

I haven't tested this specifcally, nor checked whether this makes the
entire package reproducible but this is the most obvious thing atm.

Enjoy...


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#908364: Bug#908366: librust-cc+parallel-dev: unsatisfiable dependency on librust-rayon-1+default-dev

[Steve Langasek]

On Sun, Sep 09, 2018 at 05:14:00PM +, Ximin Luo wrote:
> Please see bug 904485 https://bugs.debian.org/904485

> The bug is not in this package but in the speed of our packaging and the
> NEW queue.  If you help us package nodrop-union etc that will help the
> situation.

On Sun, Sep 09, 2018 at 05:14:00PM +, Ximin Luo wrote:

> The bug is not in this package but in the speed of our packaging and the
> NEW queue.  If you help us package nodrop-union etc that will help the
> situation.

I have no interest in working on the packaging for these packages, I am only
trying to work out why unreleasable packages are finding their way into
Ubuntu as part of package syncs.

This is definitely not caused by issues of NEW queue processing speed as the
dependencies in question are not in the NEW queue at all.  This is a matter
of dependency stacks being uploaded out of order.  Why are rust packages
being uploaded to Debian out of dependency order?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#908403: ci.debian.net: Test experimental too

[Mathieu Parent (Debian)]

Le dimanche 9 septembre 2018, Paul Gevers  a écrit :
> Control: tags -1 confirmed
>
> Hi Mathieu,
>
> On 09/09/18 16:48, Mathieu Parent wrote:
>> Can you test experimental versions too?
>
> Yes.
>
>> A first test would be with adding the experimental suite and taking
>> the tested package from it (other packages coming from testing,
>> unless required by deps, which is the default behavior).
> And this you can already do NOW yourself via the debci API.

Great

>> A second test would be with adding the experimental suite with the
>> same priority as testing (using /etc/apt/preferences): All packages
>> will come from experimental if they exists.
> I assume you mean unstable here? Albeit personally I would be interested
> to see this tested in the same way as we test testing now.
>
> Personally, I have other prios first, but this is already on my todo for
> a long time.

Good. Thanks.
(I meant unstable and not testing)

-- 
Mathieu Parent

Bug#908168: okular: CVE-2018-1000801

[Simon Quigley]

Control: owner -1

I can take care of this on behalf of the Qt/KDE Team.

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

[Dirk Eddelbuettel]

On 9 September 2018 at 14:44, John David Anglin wrote:
| On 2018-09-09 11:56 AM, Dirk Eddelbuettel wrote:
| > Thanks for the hint and its testing!
| >
| > I'll add this. Before I do so can you quickly check if the tests in
| > debian/rules identify the platform correctly?  Ie did you test it with this
| > block:
| >
| > ## edd 01 Feb 2002  allow -ffunction-sections on hppa
| > ## edd 26 Oct 2007  turn strict aliasing warning off
| > ## edd 01 May 2011  add -fpermissive as g++ is more of a stickler
| > ## edd 06 May 2011  remove -fpermissive with QL 1.1 betas
| > compilerflags   = -O2 -Wall -Wno-strict-aliasing -DBOOST_NO_AUTO_PTR
| > ifeq ($(cpu),hppa)
| > compilerflags   = -O2 -ffunction-sections -DBOOST_NO_AUTO_PTR
| > #cxxcompiler= g++-3.0
| > endif
| No.  I modified this hunk which comes later:
| 
| ## edd 22 Aug 2018  trying to help a few other systems with their 
| memory exhaustion
| ifneq "$(findstring $(cpu), hppa hurd-i386 kfreebsd-i386 m68k powerpc 
| x32)" ""
| compilerflags   = -O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR
| endif
| 
| It overrides the previous define for compilerflags on hppa.

My bug, likely :-/

| I think we need to do a couple more builds.  If -ffunction-sections fixes
| the stub table problem, it's  a better solution than -mlong-calls.

It may be, and it may be what I used before.  See the old comments there.

Do you have local access to hppa so that we can tune this?  I only have the
Debian build system spraying it onto all machines.
 
| We also need to determine whether "-O0 -g0 --param ggc-min-expand=20" is 
| needed to avoid
| memory exhaustion.
| 
| The build log for the uploaded build is here:
| 
https://buildd.debian.org/status/fetch.php?pkg=quantlib-swig=hppa=1.13-5=1536453367=0
| 
| You can see the flags used:
| #(cd Ruby &&                            \
| #    CXX="g++"                     \
| #    CFLAGS="-O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR 
| -mlong-calls"                 \
| #    CXXFLAGS="-O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR 
| -mlong-calls"                 \

Right.

Dirk

| 
| Dave
| 
| -- 
| John David Anglin  dave.ang...@bell.net
| 

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

Bug#908420: Buster: KVIrc forgets to use settings folder from previous installation

[local10]

Package: kvirc 
Version: 4:4.9.3~git20180404+dfsg-1

Hi,

Have "/home/luser/.config/kvirc/" folder from a previous version of KVIrc. In 
Buster, Kvirc keeps opening the Setup Wizard even if I have selected "Use 
settings folder from previous installation" before.

Here's what I did:

1. Launch Kvirc
2. Kvirc opens the Setup Wizard
3. Select "Use settings folder from previous installation" and point it to 
"/home/luser/.config/kvirc/"
4. Click Next
5. Click Finish
6. Kvirc opens and functions fine, all the settings from previous installation 
seem to have been successfully imported
7. Close Kvirc then launch it again. Kvirc again opens the Setup Wizard and I 
have to go through steps 2-6 above again to get my old settings imported.

 Thanks


# uname -a
Linux tstsvr 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 
GNU/Linux

Bug#908419: Adding DebConf19 local team to debconf-sponsors-team

[Louis-Philippe Véronneau]

Package: lists.debian.org
Severity: whistlist

Hi!

Can you add these people to debconf-sponsors-team ? They are from the
DC19 local team:

* Helen Koike - helen.ko...@collabora.com
* Samuel Henrique - samuel...@debian.org
* Paulo Henrique de Lima Santana - p...@softwarelivre.org
* Rodrigo Siqueira de Melo - rodrigosiqueiram...@gmail.com

Thanks,

-- 
  ,''`.
 : :'  : Louis-Philippe Véronneau
 `. `'`  po...@debian.org / veronneau.org
   `-



signature.asc
Description: OpenPGP digital signature

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

[John David Anglin]

On 2018-09-09 11:56 AM, Dirk Eddelbuettel wrote:

Thanks for the hint and its testing!

I'll add this. Before I do so can you quickly check if the tests in
debian/rules identify the platform correctly?  Ie did you test it with this
block:

## edd 01 Feb 2002  allow -ffunction-sections on hppa
## edd 26 Oct 2007  turn strict aliasing warning off
## edd 01 May 2011  add -fpermissive as g++ is more of a stickler
## edd 06 May 2011  remove -fpermissive with QL 1.1 betas
compilerflags   = -O2 -Wall -Wno-strict-aliasing -DBOOST_NO_AUTO_PTR
ifeq ($(cpu),hppa)
compilerflags   = -O2 -ffunction-sections -DBOOST_NO_AUTO_PTR
#cxxcompiler= g++-3.0
endif

No.  I modified this hunk which comes later:

## edd 22 Aug 2018  trying to help a few other systems with their 
memory exhaustion
ifneq "$(findstring $(cpu), hppa hurd-i386 kfreebsd-i386 m68k powerpc 
x32)" ""

compilerflags   = -O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR
endif

It overrides the previous define for compilerflags on hppa.  I think we 
need to do a couple
more builds.  If -ffunction-sections fixes the stub table problem, it's 
a better solution than

-mlong-calls.

We also need to determine whether "-O0 -g0 --param ggc-min-expand=20" is 
needed to avoid

memory exhaustion.

The build log for the uploaded build is here:
https://buildd.debian.org/status/fetch.php?pkg=quantlib-swig=hppa=1.13-5=1536453367=0

You can see the flags used:
#(cd Ruby &&                            \
#    CXX="g++"                     \
#    CFLAGS="-O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR 
-mlong-calls"                 \
#    CXXFLAGS="-O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR 
-mlong-calls"                 \


Dave

--
John David Anglin  dave.ang...@bell.net

Bug#907061: dh_strip: Unable to recognize the format of guile 2.2 files

[Rob Browning]

Rob Browning  writes:

> Ahh, apologies, I'd just carelessly assumed they were roughly the same.
> I'll check a bit more carefully when I get a chance -- and if I can't
> figure it out, I imagine someone will know on #guile (freenode) or of
> course guile-devel.

Oh, and for what it's worth -- I suspect if nothing else, we
(guile-related package maintainers) can just exclude the guile .go
containing dirs from dh_strip.  I expect the .go files to be well
segregated in typical cases, i.e. in /usr/lib/.../guile...

I mean it'd be nice if dh_strip could handle it automatically, but
offhand, I don't think that's critical.

-- 
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#902820: [Debian-med-packaging] Bug#902820: gmap: FTBFS on stretch/amd64 if CPU has SSE2 and nothing more

[Santiago Vila]

On Wed, 18 Jul 2018, Alex Mestiashvili wrote:

> > AFAIK on Debian/amd64 only SSE2 is allowed to be assumed by default.
> > 
> > I tried to compare my build logs with official ones, but there is none:
> > 
> > https://buildd.debian.org/status/package.php?p=gmap
> > 
> > (( Could you please consider source-only uploads? i.e. "dpkg-buildpackage 
> > -S" )).
> 
> I just uploaded a new version 2018-07-04-1, but forgot to build source
> only upload. I'll do it for the next upload.
> Meanwhile could you please try to build the new version?

Sorry for the late reply.

I lost access to the low-end machines where this used to fail for me,
so I can't test it any longer. I trust that you did the right thing.

Please note that the autopkgtests are failing:

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gmap/962092/log.gz

Note: gmap.sse42 does not exist.  For faster speed, may want to compile package 
on an SSE4.2 machine
Note: gmap.sse41 does not exist.  For faster speed, may want to compile package 
on an SSE4.1 machine
Note: gmap.ssse3 does not exist.  For faster speed, may want to compile package 
on an SSSE3 machine
Note: gmap.sse2 does not exist.  For faster speed, may want to compile package 
on an SSE2 machine


Also, since this is a baseline violation, I would try to upload for
stable as well, for the next point release, but this is up to you.

Thanks.

Bug#893713: debootstrap-udeb: containts too many scripts files (most of them are symlink but...)

[Hideki Yamane]

On Sat, 25 Aug 2018 09:11:45 +0200
Raphael Hertzog  wrote:
> you should really add some automated test
> to catch the regressions.

 Well, limited to this time, how did I catch its regression with test?


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#907855: racket-mode: testsuite failure on arm64

[Gianfranco Costamagna]

 Hello, unfortunately it didn't work...and now I'm getting another failure 
toohttp://autopkgtest.ubuntu.com/packages/r/racket-mode/cosmic/arm64


Still trying to connect to racket-command process on port 6 ...
Still trying to connect to racket-command process on port 6 ...
Test racket-tests/repl backtrace:
  racket--cmd-connect-finish()
  racket--cmd/async-raw((syms) #[257 "\300\240\207" [(RACKET-REPL-AWA
  racket--cmd/await((syms))
  racket--completion-candidates()
  racket--completion-candidates-for-prefix("with-inp")
  #[771 "\211\242\302=\206\n�\211\303=?\2053�r\301\204�p\202(�\304 \3
  try-completion("with-inp" #[771 "\211\242\302=\206\n�\211\303=?\2053
  completion-basic-try-completion("with-inp" #[771 "\211\242\302=\206\
  #[257 "\300
\2368\301\242\302\242\303\304\242$\207" [1 ("with-inp")
  completion--some(#[257 "\300
\2368\301\242\302\242\303\304\242$\207
  completion--nth-completion(1 "with-inp" #[771 "\211\242\302=\206\n�\
  completion-try-completion("with-inp" #[771 "\211\242\302=\206\n�\211
  completion--do-completion(# 36)
  completion--in-region-1(# 36)
  #[1028 "\n\203!�\304!\203�\202�\305!\305\306\"F\307\310
  apply(#[1028 "\n\203!�\304!\203�\202�\305!\305\306\"F\3
  #[771 ":\2030�@\301=\203�\300\242\302A\"\303#\207\304@\305\30
  completion--in-region(# 36 #[771 "\21
  completion-in-region(# 36 #[771 "\211
  completion-at-point()
  indent-for-tab-command(nil)
  funcall-interactively(indent-for-tab-command nil)
  call-interactively(indent-for-tab-command nil nil)
  command-execute(indent-for-tab-command)
  execute-kbd-macro([9])
  (let ((blink-matching-paren nil)) (execute-kbd-macro (string-to-vect
  racket-tests/type("   ")
  racket-tests/press("TAB")
  racket-tests/type("with-inp" "TAB")
  (save-current-buffer (set-buffer repl-buffer) (let ((fn-0 (function 
  (progn (save-current-buffer (set-buffer repl-buffer) (let ((fn-0 (fu
  (if repl-buffer (progn (save-current-buffer (set-buffer repl-buffer)
  (let ((repl-buffer (get-buffer racket--repl-buffer-name))) (if repl-
  (let ((tab-always-indent (quote complete)) (racket--cmd-connect-time
  (lambda nil (let ((tab-always-indent (quote complete)) (racket--cmd-
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test racket-tests/repl "Start REPL. Conf
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test r
  ert-run-tests(t #[385 "\306\307\"\203G�\211\211G\310U\203�\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  eval((ert-run-tests-batch-and-exit))
  command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
  command-line()
  normal-top-level()
Test racket-tests/repl condition:
(error "Could not connect to racket-command process on port 6")
   FAILED  3/5  racket-tests/repl
Still trying to connect to racket-command process on port 6 ...
Connected to racket-command process on port 6 after 1 attempt(s)
Test racket-tests/run backtrace:
  (if (unwind-protect (setq value-37 (apply fn-35 args-36)) (setq form
  (let (form-description-39) (if (unwind-protect (setq value-37 (apply
  (let ((value-37 (quote ert-form-evaluation-aborted-38))) (let (form-
  (let ((fn-35 (function racket-tests/see)) (args-36 (list (concat "\n
  (save-current-buffer (set-buffer repl-buffer) (let ((fn-35 (function
  (progn (save-current-buffer (set-buffer repl-buffer) (let ((fn-35 (f
  (if repl-buffer (progn (save-current-buffer (set-buffer repl-buffer)
  (let ((repl-buffer (get-buffer racket--repl-buffer-name))) (if repl-
  (let* ((racket--cmd-connect-timeout racket-tests/timeout) (racket-co
  (lambda nil (let* ((racket--cmd-connect-timeout racket-tests/timeout
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test racket-tests/run nil (lambda nil (l
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test r
  ert-run-tests(t #[385 "\306\307\"\203G�\211\211G\310U\203�\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  eval((ert-run-tests-batch-and-exit))
  command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
  command-line()
  normal-top-level()
Test racket-tests/run condition:
(ert-test-failed
 ((should
   (racket-tests/see
(concat "
" name "> ")))
  :form
  (racket-tests/see "
test4767luU.rkt> ")
  :value nil :explanation
  (actual . "Welcome to Racket v6.12.
> 
42
test4767luU.rkt> with-inp")))
   FAILED  4/5  racket-tests/run
   passed  5/5  racket-tests/smart-open-bracket

Ran 5 tests, 3 results as expected, 2 unexpected (2018-09-09 16:35:16+)

2 unexpected results:
   FAILED  racket-tests/repl
   FAILED  racket-tests/run

dh_elpa_test: emacs -batch -Q -l package --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval 
"(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" 
-f package-initialize -L . -L test -l racket-tests.el --eval 

Bug#794410: Installer hangs during 'select and install software'

[Wayne Gray]

Updated bios before starting installation. Still had persistent
hanging following 'installed discover.' Installed Jessie

On Mon, Aug 27, 2018 at 4:30 PM Jean-Louis Deniest
 wrote:
>
> Hi,
>
> This problem has been solved by updating the bios. Then installation of
> 9.5.0 went without problems.
>
>
>
> On 23/07/18 21:15, Jean-Louis Deniest wrote:
> > Thanks Cyril.
> >
> > Here is it.
> > usb key : debian 9, DVD version
> >
> > I made screenshots of vt4 during :
> > - error when searching mirrors - no mirrors were accepted, even usa -
> > debian. I selected then 'continue with no mirror' (see screenshot 1 &
> > 2). It has happened a few times. > screenshots 1 and 2
> > - just before the hanging, at the phase of installing discover.
> >
> > Then, I runned another time the install, and made a few screenshots of
> > /var/log/syslog, until it hangs.
> >
> > All screenshots here : https://cloud.owncube.com/s/FyPgZMi9bzQEPoj
> >
> > Hope it helps...
> >
> >
> > On 22/07/18 20:02, Cyril Brulebois wrote:
> >> Hi Jean-Louis,
> >>
> >> Jean-Louis Deniest  (2018-07-21):
> >>> Hello, I have the same issue.
> >>>
> >>> Installing debian 9 stretch, both cd
> >>> (debian-9.5.0-amd64-xfce-CD-1.iso) and
> >>> the dvd versions.
> >>>
> >>> Hangs at 12% : at the phase of installing "discover (amd64)"
> >>>
> >>> I tried about 10 times.
> >>>
> >>> Laptop is Packard Bell ENLG71BM-C05U
> >>>
> >>> I used the additional drivers (from
> >>> http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/stretch/20180714/),
> >>> and I put these .deb packages on another usb key : the effect is that I
> >>> don't have the step where they search for firmware for
> >>> rtlwifi/rtl8723befw.bin and rtl_nic/rtl8168g-2.fw
> >>>
> >>> I don't have options to disable APCI in the bios.
> >>>
> >>> I managed to install Opensuse on this computer, and there was
> >>> Windows 10
> >>> working properly.
> >>>
> >>> Any suggestion is welcome...
> >> Can you please switch to vt4 and tell us what the last lines look like?
> >> Bonus points if you can extract the whole /var/log/syslog file (e.g. by
> >> using netcat to another machine); a photograph would probably work too.
> >>
> >> Thanks already.
> >>
> >>
> >> Cheers,
> >
> >
>
> --
> To unsubscribe, send mail to 794410-unsubscr...@bugs.debian.org.

Bug#901172: update 7release-notes script to use the git repo of "release-notes"

[Baptiste Jammet]

Hello, 

Now that #901180 has been corrected & closed (in the 3 branches wheezy,
jessie & stretch), could you take a look at publishing again the
release-notes ?

Thanks.

Baptiste
diff --git a/parts/7release-notes b/parts/7release-notes
index 395607f..570661c 100755
--- a/parts/7release-notes
+++ b/parts/7release-notes
@@ -10,22 +10,23 @@ savelog -g debwww -m 664 $notesdir/build.log >/dev/null
 
 date > $notesdir/build.log
 
-# Add the release name once released/branched out of trunk
 for release in wheezy jessie stretch ; do
 echo "rebuilding the release notes for $release" >> $notesdir/build.log
-if ! [ -d "$notesdir/$release" ] ; then
-echo "directory $notesdir/$release does not exist. checking out SVN" >> $notesdir/build.log
-cd $notesdir
-if [ "$release" = "stretch" ]; then
-svn checkout svn://svn.debian.org/svn/ddp/manuals/trunk/release-notes $release >> $notesdir/build.log 2>&1
-else
-svn checkout svn://svn.debian.org/svn/ddp/manuals/branches/release-notes/$release >> $notesdir/build.log 2>&1
-fi
+cd $notesdir
+if ! [ -d $notesdir/release-notes/.git ]; then
+echo "Directory $notesdir/release-notes is not a git repository. Cloning from git." >> $notesdir/build.log
+git clone https://salsa.debian.org/ddp-team/release-notes.git >> $notesdir/build.log 2>&1
+fi
+cd $notesdir/release-notes
+if [ "$release" = "stretch" ]; then
+# Stay on master
+git checkout master >> $notesdir/build.log 2>&1 && git pull >> $notesdir/build.log 2>&1
 else
-(cd $notesdir/$release && svn update) >> $notesdir/build.log 2>&1
+# Switch to $release branch
+git checkout $release >> $notesdir/build.log 2>&1 && git pull >> $notesdir/build.log 2>&1
 fi
- make -C $notesdir/$release publish \
- PUBLISHTARBALL=yes PUBLISHDIR=$webtopdir/www/releases/$release >> $notesdir/build.log 2>&1
+make -C $notesdir/release-notes publish \
+PUBLISHTARBALL=yes PUBLISHDIR=$webtopdir/www/releases/$release >> $notesdir/build.log 2>&1
 done
 
 date >> $notesdir/build.log


pgp_KsKI9TEfZ.pgp
Description: Signature digitale OpenPGP

Bug#908393: jq: error while loading shared libraries: libonig.so.2

[George B.]

Package: jq
Followup-For: Bug #908393

I figured it out - my ldd shows libjq in /usr/local/lib and that was
being loaded by the binary instead of Debian libjq. Doing "rm
/usr/local/lib/libjq*" fixed the issue.

This is from a machine that I don't log into often and must have been
left over from a time I compiled my own jq to get round some bugs and
never cleaned it up properly.

I'll close this bug out, sorry for the wild goose chase.

Bug#908417: dgit does not handle debian/.gitignore missing from source package

[Ian Jackson]

Ian Jackson writes ("Re: Bug#908417: dgit does not handle debian/.gitignore 
missing from source package"):
> I'm sorry to be dim, but I don't understand what you think the bug in
> dgit is ?  dgit's design principle is that the source package and git
> tree are idnntical.  Are you arguing that this is not correct ?
> 
> Or is the problem that dgit cannot be used to nmu a package with
> tar-ignore in debian/source/options ?  dgit passes an explicit -I
> option to dpkg-source which I think should override
> debian/source/options.  And if the uploader did not use dgit push then
> the .gitignore would be missing anyway.

Also, it's possible that --quilt=dpm could be used to work around the
problem, although that seems much less desirable than removing
tar-exclude from debian/source/options...

(I guess you weren't using --quilt-gbp since that would make a patch
for .gitignore in the dgit view.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#908364: librust-nodrop+nodrop-union-dev: unsatisfiable dependency on librust-nodrop-union-0.1+default-dev

[Ximin Luo]

Control: notfound -1 0.1.12-1
Control: close -1

Please see bug 904485 https://bugs.debian.org/904485

The bug is not in this package but in the speed of our packaging and the NEW 
queue. If you help us package nodrop-union etc that will help the situation.

Steve Langasek:
> Package: librust-nodrop+nodrop-union-dev
> Version: 0.1.12-1
> Severity: grave
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic
> 
> The rust-nodrop source package creates a binary package
> librust-nodrop+nodrop-union-dev with a dependency on
> librust-nodrop-union-0.1+default-dev which does not exist as a real or
> virtual package in Debian.
> 
> There is no package called 'rust-nodrop-union' in either Debian or in the
> NEW queue, so it's not clear what is supposed to provide the package that
> satisfies this dependency.
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git