Bug#939307: ITP: ruby-necromancer -- Conversion from one object type to another with a bit of black magic

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-necromancer
  Version : 0.5.0
  Upstream Author : Piotr Murach 
* URL : https://github.com/piotrmurach/necromancer
* License : Expat
  Programming Lang: Ruby
  Description : Conversion from one object type to another with a bit of 
black magic

Necromancer provides independent type conversion component for TTY toolkit.

Conversion between Ruby core types frequently comes up in projects but is
solved by half-baked solutions. This library aims to provide an independent
and extensible API to support a robust and generic way to convert between core
Ruby types.


This is a requirement for ruby-tty-prompt, which in turn is a requirement for
puppet-development-kit, which I'm working to package.

I intend to maintain this package within the ruby team, and will ask for a
sponsor within the team.

Bug#939308: gkrellm2-cpufreq_0.6.4-5_mips64el.changes REJECTED

[Aurelien Jarno]

Package: gkrellm2-cpufreq
Version: 0.6.4-5
Severity: serious

On 2019-09-02 23:19, Debian FTP Masters wrote:
> gkrellm-cpufreq_0.6.4-5_mips64el.deb: Missing mandatory field 
> gkrellm-cpufreq_0.6.4-5_mips64el.deb.
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#935390: RFS: vnstat/2.4-1 [NMU] [ITA]

[Sven Hoexter]

On Sun, Sep 01, 2019 at 09:23:06AM -0700, Rob Savoury wrote:
> Package: sponsorship-requests

>   dget -x
> https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.4-0.1.dsc


Hey Rob and Christian,
the package looks good to me. I've uploaded it to delayed-3 in case
Christian objects the upload. From what I understood he's fine with the
NMU, but just in case.

So Christian in case you object to this upload give me a short notice
and I can cancel it within the next three days.

Rob the "ITA" tag in the bug is a bit misleading in the sense that if you
want to adopt someting (ITA - Intent To Adopt), you usually set yourself
as the package maintainer in debian/control.

I'm not sure what Christian is up to, but maybe it makes sense to move the
package to https://salsa.debian.org/debian and have it group maintained.
But that's up to Christian to decide.

Sven

Bug#894602: here is the trace output

[Michael Tokarev]

So here's the cron output after adding `set +x' and `env' to
/etc/cron.daily/dpkg and /usr/bin/savelog.

The first error is from `cp' - can't create dpkg.status, EEXIST.
Well, cp shouldn't get this erro, it should just replace the
file content and be done with that, but okay, at least we can
assume this file exist. Fine.

Next error is from savelog, `mv'. Here:

 + rm -f -- .//dpkg.status.6 .//dpkg.status.6.gz

so it removed dpkg.status.6.gz, it shouldn't be there. Ok.

 + [ -f .//dpkg.status.5.gz ]

so dpkg.status.5.gz does exist

 + mv -f -- .//dpkg.status.5.gz .//dpkg.status.6.gz
 mv: cannot stat './/dpkg.status.5.gz': No such file or directory

and now suddenly it doesn't exist anymore. How very useful.

Some weird thing is happening here. Both errors shouldn't be there.
I'll dig further. Overrall it smells like some issue with the
filesystem or the kernel.

Below is the complete email from cron.

Thanks,

/mjt

Date: Tue, 03 Sep 2019 06:25:03 +0300
To: root
Subject: Cron  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.daily )
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 

/etc/cron.daily/dpkg:
+ env
HOME=/var/root
OLDPWD=/var/root
LOGNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
SHELL=/bin/sh
PWD=/
+ cd /var/backups
+ dbchanged=no
+ dbfiles=arch status diversions statoverride
+ cmp -s dpkg.arch.0 /var/lib/dpkg/arch
+ dbchanged=yes
+ break
+ [ yes = yes ]
+ [ -e /var/lib/dpkg/arch ]
+ continue
+ [ -e /var/lib/dpkg/status ]
+ cp -p /var/lib/dpkg/status dpkg.status
cp: cannot create regular file 'dpkg.status': File exists
+ savelog -c 7 dpkg.status
+ export 
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
+ COMPRESS=gzip
+ COMPRESS_OPTS=-f
+ COMPRESS_STRENGTH_DEF=-9
+ DOT_Z=.gz
+ date +%Y%m%d%H%M%S
+ DATUM=20190903062502
+ exitcode=0
+ basename /usr/bin/savelog
+ prog=savelog
+ mode=
+ user=
+ group=
+ touch=
+ forceclean=
+ rolldir=
+ datum=
+ preserve=
+ hookscript=
+ quiet=0
+ rotateifempty=yes
+ count=7
+ getopts m:u:g:c:r:CdD:tlphjJ123456789x:nq opt
+ count=7
+ getopts m:u:g:c:r:CdD:tlphjJ123456789x:nq opt
+ shift 2
+ [ 7 -lt 2 ]
+ [ -n gzip ]
+ which gzip
+ [ -z /bin/gzip ]
+ [ -n  ]
+ COMPRESS_OPTS=-f -9
+ [ 1 -gt 0 ]
+ filename=dpkg.status
+ shift
+ [ -e dpkg.status ]
+ [ ! -f dpkg.status ]
+ [ ! -s dpkg.status ]
+ [ ! -e dpkg.status ]
+ dirname -- dpkg.status
+ savedir=.
+ [ -z . ]
+ savedir=./
+ [ ! -d ./ ]
+ [ ! -w ./ ]
+ basename -- dpkg.status
+ newname=dpkg.status
+ newname=.//dpkg.status
+ cycle=6
+ rm -f -- .//dpkg.status.6 .//dpkg.status.6.gz
+ [ 6 -gt 1 ]
+ oldcycle=6
+ cycle=5
+ [ -f .//dpkg.status.5.gz ]
+ mv -f -- .//dpkg.status.5.gz .//dpkg.status.6.gz
mv: cannot stat './/dpkg.status.5.gz': No such file or directory
+ [ -f .//dpkg.status.5 ]
+ [ 5 -gt 1 ]
+ oldcycle=5
+ cycle=4
+ [ -f .//dpkg.status.4.gz ]
+ mv -f -- .//dpkg.status.4.gz .//dpkg.status.5.gz
mv: cannot stat './/dpkg.status.4.gz': No such file or directory
+ [ -f .//dpkg.status.4 ]
+ [ 4 -gt 1 ]
+ oldcycle=4
+ cycle=3
+ [ -f .//dpkg.status.3.gz ]
+ mv -f -- .//dpkg.status.3.gz .//dpkg.status.4.gz
mv: cannot stat './/dpkg.status.3.gz': No such file or directory
+ [ -f .//dpkg.status.3 ]
+ [ 3 -gt 1 ]
+ oldcycle=3
+ cycle=2
+ [ -f .//dpkg.status.2.gz ]
+ mv -f -- .//dpkg.status.2.gz .//dpkg.status.3.gz
mv: cannot stat './/dpkg.status.2.gz': No such file or directory
+ [ -f .//dpkg.status.2 ]
+ [ 2 -gt 1 ]
+ oldcycle=2
+ cycle=1
+ [ -f .//dpkg.status.1.gz ]
+ mv -f -- .//dpkg.status.1.gz .//dpkg.status.2.gz
mv: cannot stat './/dpkg.status.1.gz': No such file or directory
+ [ -f .//dpkg.status.1 ]
+ [ 1 -gt 1 ]
+ [ -f .//dpkg.status.0 ]
+ [ -z gzip ]
+ newfile=.//dpkg.status.1.gz
+ gzip -f -9 .//dpkg.status.0
gzip: .//dpkg.status.0: No such file or directory
+ mv -- .//dpkg.status.0.gz .//dpkg.status.1.gz
mv: cannot stat './/dpkg.status.0.gz': No such file or directory
+ fixfile .//dpkg.status.1.gz
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ test -n
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ newfilename=.//dpkg.status.0
+ [ -f dpkg.status ]
+ [ -n  ]
+ mv -- dpkg.status .//dpkg.status.0
mv: cannot stat 'dpkg.status': No such file or directory
+ [ ! -f .//dpkg.status.0 ]
+ fixfile .//dpkg.status.0
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ [ -n  ]
+ test 0 -eq 1
+ date
+ echo Rotated `dpkg.status' at Tue Sep  3 06:25:02 MSK 2019.
+ [ 0 -gt 0 ]
+ exit 0
+ [ -e /var/lib/dpkg/diversions ]
+ cp -p /var/lib/dpkg/diversions dpkg.diversions
+ savelog -c 7 dpkg.diversions
+ export 
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
+ COMPRESS=gzip
+ COMPRESS_OPTS=-f
+ COMPRESS_STRENGTH_DEF=-9
+ DOT_Z=.gz
+ date +%Y%m%d%H%M%S
+ DATUM=20190903062502
+ exitcode=0
+ basename /usr/bin/savelog
+ prog=savelog
+ mode=
+ user=
+ group=
+ touch=
+ forceclean=
+ rolldir=
+ datum=
+ preserve=
+ hookscript=
+ quiet=0
+ rotateifempt

Bug#939308: gkrellm2-cpufreq_0.6.4-5_mips64el.changes REJECTED

[John Paul Adrian Glaubitz]

Hello Aurelien!

On 9/3/19 9:19 AM, Aurelien Jarno wrote:
> Package: gkrellm2-cpufreq
> Version: 0.6.4-5
> Severity: serious
> 
> On 2019-09-02 23:19, Debian FTP Masters wrote:
>> gkrellm-cpufreq_0.6.4-5_mips64el.deb: Missing mandatory field 
>> gkrellm-cpufreq_0.6.4-5_mips64el.deb.

Can you elaborate what the actual bug is? I updated and uploaded the
package as usual. Why did it get rejected?

Thanks,
Adrian

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

Bug#939294: network-manager: After upgrade to 1.20.0-1, mac address of wlan0 is randomized

[Jörn Heissler]

On Tue, Sep 03, 2019 at 00:55:59 +0200, Michael Biebl wrote:
> network-manager did always randomize the mac, unless you have a package
> explicitly overriding this behaviour.

After a reboot it worked again.
I had a closer looks at the logs: It appears like NM always changes mac address
before scanning:

device (wlan0): set-hw-addr: set MAC address to 7E:83:4F:92:E9:72 (scanning)

And changing it back when connecting:

device (wlan0): set-hw-addr: reset MAC address to <---redacted---> (preserve)

I wasn't even aware of the feature, but it makes sense. That happened
before the upgrade too.


During the upgrade, NM started a scan for some reason and changed the address.
Then the NM process was terminated. The new instance of NM assumed wrongly
that the current mac address is the real one.

Logs looked like:

device (wlan0): set-hw-addr: set MAC address to C6:E8:D3:FB:55:4B (scanning)
exiting (success)
---
NetworkManager (version 1.20.0) is starting... (after a restart)
device (wlan0): set-hw-addr: set MAC address to 52:8C:79:7C:65:5E (scanning)
device (wlan0): set-hw-addr: reset MAC address to C6:E8:D3:FB:55:4B (preserve)


The flaw can be triggered easily:

# systemctl restart wpa_supplicant.service; sleep 1.5; systemctl restart 
NetworkManager.service

Restart of wpa_supplicant.service causes a rescan which appears to take
about 3 seconds. During rescan, NM is restarted. Afterwards the MAC
address is wrong.

A workaround without reboot is to stop NM, change the mac adress
manually (ip link set dev wlan0 down; ip link set dev wlan0 address 
zz:yy:xx:ww:vv:uu),
then start NM again.


So, I believe this is really a bug in NetworkManager which should be
fixed. But might well be an upstream bug.


signature.asc
Description: PGP signature

Bug#939309: redmine: Postinstallation script fails

[Alvaro G. M.]

Package: redmine
Version: 4.0.4-1
Severity: grave

Dear Maintainer,

This version seems uninstallable because post script script fails:

Setting up redmine (4.0.4-1) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to 
/etc/dbconfig-common/redmine/instances/default.conf
redmine/instance already exists and has privileges on redmine_default.
creating database redmine_default: already exists.
dbconfig-common: flushing administrative password
rake aborted!
NameError: uninitialized constant Rake::TestTask
/usr/share/redmine/plugins/redmine_ldap_sync/lib/tasks/testing.rake:37:in 
`block (4 levels) in '
/usr/share/redmine/plugins/redmine_ldap_sync/lib/tasks/testing.rake:35:in 
`block (3 levels) in '
/usr/share/redmine/plugins/redmine_ldap_sync/lib/tasks/testing.rake:20:in 
`block (2 levels) in '
/usr/share/redmine/plugins/redmine_ldap_sync/lib/tasks/testing.rake:19:in 
`block in '
/usr/share/redmine/plugins/redmine_ldap_sync/lib/tasks/testing.rake:18:in `'
/usr/share/redmine/lib/tasks/redmine.rake:190:in `load'
/usr/share/redmine/lib/tasks/redmine.rake:190:in `block in '
/usr/share/redmine/lib/tasks/redmine.rake:190:in `each'
/usr/share/redmine/lib/tasks/redmine.rake:190:in `'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:650:in
 `load'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:650:in
 `block in run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:650:in
 `each'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:650:in
 `run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/application.rb:515:in
 `run_tasks_blocks'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/engine.rb:459:in
 `load_tasks'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/railtie.rb:190:in
 `public_send'
/usr/share/rubygems-integration/all/gems/railties-5.2.3/lib/rails/railtie.rb:190:in
 `method_missing'
/usr/share/redmine/Rakefile:6:in `'
(See full trace by running task with --trace)
dpkg: error processing package redmine (--configure):
 installed redmine package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 redmine
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- System Information:
Debian Release: 10.0
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages redmine depends on:
ii  dbconfig-common 2.0.12
ii  debconf [debconf-2.0]   1.5.73
ii  libjs-jquery3.3.1~dfsg-3
ii  libjs-jquery-ui 1.12.1+dfsg-5
ii  libjs-raphael   2.1.0-1
ii  redmine-mysql   4.0.4-1
ii  ruby1:2.5.1
ii  ruby-actionpack-action-caching  1.2.0-2
ii  ruby-actionpack-xml-parser  2.0.1-3
ii  ruby-bundler1.17.3-3
ii  ruby-coderay1.1.2-2
ii  ruby-csv3.0.2-1
ii  ruby-i18n   1.5.3-1
ii  ruby-jquery-rails   4.3.3-1
ii  ruby-mail   2.7.1+dfsg1-1
ii  ruby-mime-types 3.2.2-1
ii  ruby-mimemagic  0.3.2+dfsg-1
ii  ruby-mini-mime  1.0.1-1
ii  ruby-net-ldap   0.16.1-1
ii  ruby-nokogiri   1.10.4+dfsg1-1
ii  ruby-openid 2.7.0debian-1
ii  ruby-rack   2.0.6-3
ii  ruby-rack-openid1.4.2-1
ii  ruby-rack-test  0.7.0-1
ii  ruby-rails  2:5.2.3+dfsg-1
ii  ruby-rails-dom-testing  2.0.3-3
ii  ruby-rails-observers0.1.5-1
ii  ruby-rbpdf  1.19.5+ds.1-1
ii  ruby-redcarpet  3.4.0-4+b1
ii  ruby-request-store  1.3.0-1
ii  ruby-rmagick2.16.0-6
ii  ruby-roadie 3.5.0-1
ii  ruby-roadie-rails   1.3.0-1
ii  ruby-rouge  3.8.0-1

Versions of packages redmine recommends:
ii  passenger  5.0.30-1.1

Versions of packages redmine suggests:
pn  bzr 
pn  cvs 
pn  darcs   
ii  git 1:2.23.0-1
pn  mercurial   
pn  ruby-fcgi   
ii  subversion  1.10.6-1

-- debconf information:
  redmine/current-instances: default
  redmine/instances/default/pgsql/method: TCP/IP
  redmine/instances/default/db/dbname: redmine_default
  redmine/instances/default/remote/host: localhost
  redmine/instances/default/install-error: abort
  redmine/instances/default/internal/reconfiguring: false
  redmine/instances/default/upgrade-backup: true
  redmine/instances/default/dbconfig-remove: true
  redmine/instances/default/remote/newhost:
  re

Bug#936053: qemu-system-x86_64 "bdrv_error_action: Assertion `error >= 0' failed."

[Michael Tokarev]

Control: tag -1 + moreinfo

29.08.2019 16:36, Stephan Breitrainer wrote:
> Package: qemu-system-x86
> Version: 1:2.1+dfsg-12+deb8u11
> Severity: normal
> 
> Dear Maintainer,
> 
> when starting a qemu process, the process terminates suddenly leaving this 
> error message in /var/log/libvirt/qemu/.log:
> 
> qemu-system-x86_64: /build/qemu-2.1+dfsg/block.c:3606: bdrv_error_action: 
> Assertion `error >= 0' failed.

How very useful.. not. Okay.

> The qemu command used:
> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
> QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name testmachine -S
> -machine pc-i440fx-2.1,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 
> 2,sockets=2,cores=1,threads=1 -uuid cc300f3e-cdc9-465f-95b3-f208b92ad4ac
> -no-user-config -nodefaults -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/testmachine.monitor,server,nowait
>  -mon
> chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot 
> strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
> file=/data/one/0/322/disk.0,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=unmap,aio=native
>  -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
>  -drive
> file=/data/one/0/testmachine/disk.2,format=raw,if=none,id=drive-virtio-disk1,cache=none,discard=unmap,aio=native
>  -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1
>  -drive
> file=/data/one/0/testmachine/disk.1,format=raw,if=none,id=drive-ide0-0-0,readonly=on
>  -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0
> -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=43 -device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=02:00:ac:10:01:88,bus=pci.0,addr=0x3
> -vnc 0.0.0.0:322  -device 
> cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg
> timestamp=on

Thank you for providing the qemu command line, it is not often when bug 
reporters do this,
and without it it's usually difficult to say anything about the bug.  Ok.

Now, I can't say exactly what is happening here, but at least we can assume 
there's
something wrong with your setup.

This assert() is in a routine which handles I/O errors in the block layer or 
qemu. The thing is,
some error happened while handling an I/O request from your virtual machine, 
eg, a read or write
to the virtio drive failed, and qemu tried to tell your machine about this 
error. And we hit a
bug on the qemu side somewhere in the error handling path (path which is 
usually not tested well
enough).

I suggest you to recreate the images (maybe just copy 'em with qemu-img) and 
try running your
guest again - the error hopefully will just go away.

Overall, qemu 2.1 is in oldstable, and the code in there has been changed 
significantly since
then, please try a more recent version. If current version will show this 
error, we'll try to
debug it further.

Thanks,

/mjt

Bug#936856: libfiu: Python2 removal in sid/bullseye

[Chris Lamb]

Hi Alberto,

> FYI, I just wrote a patch to remove the Python 2 dependency for build 
> and testing (Python 3 is used instead):
[..]
> It will be included in the next release, which is probably due by now :)

Neat. Can we tempt you into releasing this whilst I have Python 2.x on
my mind?


Best wishes,

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

Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Julien Cristau]

On Mon, Sep  2, 2019 at 23:42:44 +0100, Steve McIntyre wrote:

> control: reassign -1 task-xfce-desktop
> 
> Hi Karthik,
> 
> On Sat, Aug 24, 2019 at 04:10:53PM +0530, karthik wrote:
> >Package: cdimage.debian.org
> >Severity: normal
> >
> >Dear Maintainer,
> >
> >*** Reporter, please consider answering these questions, where appropriate 
> >***
> >
> >   * What led up to the situation?
> > After a fresh install of xfce CD testing weekly iso on lenovo x230 
> > laptop, I have noticed that the touchpad options were missing in mouse & 
> > touchpad settings
> >   * What exactly did you do (or not do) that was effective (or
> > ineffective)?
> > installed xserver-xorg-input-synaptics package 
> >   * What was the outcome of this action?
> > touchpad options were visible back again!
> >   * What outcome did you expect instead?
> > same as above
> >
> >Please include this package in upcoming iso builds, It is an important one.
> 
> If it's important that it's available, then a better place for the bug
> would be against the task-xfce-desktop package. That way it will be
> pulled in automatically via dependencies for the CD build.
> 
The synaptics Xorg driver is obsolete and should not be installed by
default.

Cheers,
Julien

Bug#939309: Solved

[Alvaro Gamez]

Please, close this bug, as I've already found what was the issue.

This system had a very old and deprecated version of redmine that was
manually installed and it was conflicting with the new package.

Sorry for the inconvenience, I was way too fast on reporting this!


-- 
Álvaro Gámez Machado

Bug#939310: missing systray icon for blueman-applet

[Peter Palfrader]

Package: blueman
Version: 2.0.8-1
Severity: normal

Hi!

I run awesomewm with KDE.

When I start blueman-applet, an icon briefly flickers in my awesomewm
systray, but then is no longer visible and I don't see any way to get it
to stay visible.

If I edit /usr/lib/python3/dist-packages/blueman/plugins/applet/AppIndicator.py
to set self.Applet.Plugins.StatusIcon.props.visible to True at the end
of on_load() then everything works as it should and I see and can
interact with blueman-applet's icon.

It would be great if editing files in /usr wasn't necessary for that,
though :)

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#939308: gkrellm2-cpufreq_0.6.4-5_mips64el.changes REJECTED

[Aurelien Jarno]

On 2019-09-03 09:25, John Paul Adrian Glaubitz wrote:
> Hello Aurelien!
> 
> On 9/3/19 9:19 AM, Aurelien Jarno wrote:
> > Package: gkrellm2-cpufreq
> > Version: 0.6.4-5
> > Severity: serious
> > 
> > On 2019-09-02 23:19, Debian FTP Masters wrote:
> >> gkrellm-cpufreq_0.6.4-5_mips64el.deb: Missing mandatory field 
> >> gkrellm-cpufreq_0.6.4-5_mips64el.deb.
> 
> Can you elaborate what the actual bug is? I updated and uploaded the
> package as usual. Why did it get rejected?
 
No idea, I have just forwarded the mail from dak. I think you should
contact the ftp-masters for more details.

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

Bug#884994: systemd: shutdown does not send its warning messages when time is more than ten minutes

[Christoph Pleger]

Hello,


Can you be more specific, how sysvinit behaved.
When exactly did sysvinit start with the notification messages, what 
was

the initial interval and how exactly did the interval change on each
iteration.


I am sorry, I do not remember more than I already wrote and 
unfortunately, I have no machine with sysvinit any more.


Regards
  Christoph

Bug#939311: monero: FTBFS on arm64: final link failed: file in wrong format

[Jonathan Wiltshire]

Source: monero
Version: 0.14.1.2-1
Severity: serious
Justification: ftbfs

Hi,

monero fails to build from source in sid on arm64, tail of the log is:

| /usr/bin/ld: can not size stub section: invalid operation
| /usr/bin/ld: linker stubs: file class ELFCLASSNONE incompatible with 
ELFCLASS64
| /usr/bin/ld: final link failed: file in wrong format
| collect2: error: ld returned 1 exit status

https://buildd.debian.org/status/fetch.php?pkg=monero&arch=arm64&ver=0.14.1.2-1&stamp=1566559455&raw=0

-- System Information:
Debian Release: 10.1
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#934023: resiprocate missing in buster

[Bogdan Veringioiu]

Thanks for the info!

We actually managed to build the package on buster. Not yet tested though...

About maintaining it, we will check.

Bogdan

On 27.08.19 07:57, Petter Reinholdtsen wrote:

[Bogdan Veringioiu]

resiprocate source is not being built in buster anymore.
We are using it in a sip client app.
Is there any chance that resiprocate will be reinserted in buster?

As far as I can tell from
https://tracker.debian.org/pkg/resiprocate >, it was removed
from unstable (and thus buster) because it was unmaintained.

If it is important to you, perhaps you can reintroduce it and
maintain it?

Bug#884994: systemd: shutdown does not send its warning messages when time is more than ten minutes

[Ansgar]

Christoph Pleger writes:
>> Can you be more specific, how sysvinit behaved.
>> When exactly did sysvinit start with the notification messages, what
>> was
>> the initial interval and how exactly did the interval change on each
>> iteration.
>
> I am sorry, I do not remember more than I already wrote and
> unfortunately, I have no machine with sysvinit any more.

This should be the `needwarning()` function in sysvinit's
src/shutdown.c[1].  With the default setting QUIET_NONE you get:

 - a warning every minute in the last 10 minutes
 - a warning every 15 minutes in the last hour
 - a warning every 30 minutes in the last 3 hours
 - a warning every hour before that

Ansgar

  [1] https://sources.debian.org/src/sysvinit/2.93-8/src/shutdown.c/#L467

Bug#835086: RFP: nextcloud -- self-hosted cloud services

[Adrien Grellier]

Hi,

Does the situation has evolved since 2018 ? I see that the client tools
are now in Debian, but is there any chance to have NextCloud server in
Debian ?

Upstream does not seems to provide any repository at all, contrary to
ownCloud.

Kind regards,

Adrien

-- 

Adrien Grellier  (02 40 37 15 55)
Informaticien du LHEEA
CNRS – École Centrale de Nantes

Bug#939312: freetds-bin: handle different encoding when retrieve rows got strange chars

[Pawel Szajna]

Package: freetds-bin
Version: 1.00.104-1
Severity: normal

Dear Maintainer,

After upgrade from Debian Stretch (FreeTDS 0.91) to Debian Buster (FreeTDS 
1.00.104), FreeTDS 0.91 worked fine all chars were ok, but 1.00.104 causes 
weird chars show in results:
FreeTDS 0.91:
Rymanów
FreeTDS 1.00.104:
Ryman�w

Database encoding is CP1250.

This bug is described in details here:
https://github.com/FreeTDS/freetds/issues/260

version 1.1.6 (testing) is also affected with this bug.

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

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

Versions of packages freetds-bin depends on:
ii  freetds-common1.00.104-1
ii  libc6 2.28-10
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgnutls30   3.6.7-4
ii  libgssapi-krb5-2  1.17-3
ii  libhogweed4   3.4.1-1
ii  libncurses6   6.1+20181013-2
ii  libnettle63.4.1-1
ii  libodbc1  2.3.6-0.1
ii  libreadline7  7.0-5
ii  libsybdb5 1.00.104-1
ii  libtinfo6 6.1+20181013-2

freetds-bin recommends no packages.

freetds-bin suggests no packages.

-- no debconf information

Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Bjørn Mork]

Julien Cristau  writes:

> The synaptics Xorg driver is obsolete and should not be installed by
> default.

Maybe the xserver-xorg-input-synaptics package could hint about this and
point to xserver-xorg-input-libinput?  As it is now, I don't understand
how anyone is supposed to figure out that this is an obsolete package;

Package: xserver-xorg-input-synaptics
Version: 1.9.1-1
Installed-Size: 324
Maintainer: Debian X Strike Force 
Architecture: amd64
Replaces: xorg-driver-synaptics
Provides: xorg-driver-input, xorg-driver-synaptics
Depends: libc6 (>= 2.15), libevdev2 (>= 1.3), libx11-6, libxi6 (>= 2:1.2.0), 
libxtst6, xorg-input-abi-24, xserver-xorg-core (>= 2:1.18.99.901)
Suggests: gpointing-device-settings, touchfreeze
Conflicts: xorg-driver-synaptics
Breaks: kde-config-touchpad (<< 0.8.1-2~)
Description-en: Synaptics TouchPad driver for X.Org server
 This package provides an input driver for the X.Org X server to enable
 advanced features of the Synaptics Touchpad including:
 .
  * Movement with adjustable, non-linear acceleration and speed
  * Button events through short touching of the touchpad
  * Double-Button events through double short touching of the touchpad
  * Dragging through short touching and holding down the finger on the touchpad
  * Middle and right button events on the upper and lower corner of the touchpad
  * Vertical scrolling (button four and five events) through moving the finger
on the right side of the touchpad
  * The up/down button sends button four/five events
  * Horizontal scrolling (button six and seven events) through moving the finger
on the lower side of the touchpad
  * The multi-buttons send button four/five events, and six/seven events for
horizontal scrolling
  * Adjustable finger detection
  * Multifinger taps: two finger for middle button and three finger for right
button events. (Needs hardware support. Not all models implement this
feature.)
  * Run-time configuration using shared memory. This means you can change
parameter settings without restarting the X server (see synclient(1)).
  * It also provides a daemon to disable touchpad while typing at the keyboard
and thus avoid unwanted mouse movements (see syndaemon(1)).
Description-md5: 6f7a84d9a52f4dc44fd0ad7cc265853b
Tag: hardware::input, hardware::laptop, implemented-in::c, role::plugin,
 role::program, use::driver, x11::xserver
Section: x11
Priority: optional
Filename: 
pool/main/x/xserver-xorg-input-synaptics/xserver-xorg-input-synaptics_1.9.1-1_amd64.deb
Size: 219712
MD5sum: 6f95416d63be90a95acf862dc12b8904
SHA256: 36bb385f930b1731a6a39f9aedab474942d779b5c1fda33c5814eec9f5923752



Compare that to the rather sparse description of the replacement:


Package: xserver-xorg-input-libinput
Version: 0.28.2-2
Installed-Size: 138
Maintainer: Debian X Strike Force 
Architecture: amd64
Provides: xorg-driver-input
Depends: libc6 (>= 2.7), libinput10 (>= 1.11.1), xorg-input-abi-24, 
xserver-xorg-core (>= 2:1.18.99.901)
Description-en: X.Org X server -- libinput input driver
 This package provides the driver for input devices using libinput library.
 It can handle keyboards, mice and touchpads, and essentially replaces the
 separate -evdev and -synaptics drivers.
 .
 This package is built from the X.org xf86-input-libinput driver module.
Description-md5: f8bfd1aa5c6b0f14ea81809036429317
Homepage: https://www.x.org
Section: x11
Priority: optional
Filename: 
pool/main/x/xserver-xorg-input-libinput/xserver-xorg-input-libinput_0.28.2-2_amd64.deb
Size: 61472
MD5sum: 1a4f2f8168f4995c98c71a8640e729a0
SHA256: 96ed7234dec3aea8bec57850064ad2258ada2d53cbf3741da1490799b073f69b



Exactly which packages does it replace?  And "essentially"?  Does it
replace them, or not?  If so, then why isn't there any "Replaces" field?

But you can't really expect users to look at xserver-xorg-input-libinput
at all.  Why should they?  There is no pointer to it from the "obsolete"
package.  What kind of deprecation is that? Most users will probably
read the first lines of the verbose xserver-xorg-input-synaptics
description, see "enable advanced features of the Synaptics Touchpad",
and think "YES! I want that!".




Bjørn

Bug#939313: buster-pu: package swi-prolog/8.0.2+dfsg-3

[Lev Lamberov]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi release team,

SWI-Prolog upsteam migrated to HTTPS (from HTTP). Unfortunately,
because of that package installation of SWI-Prolog packages doesn't
work now (please, see #939257). I've prepared a backport of an
upstream patch to fix this problem. Changes are tiny and harmless.
I've built the package for buster with the patch and tested it.
Please, find the debdiff between 8.0.2+dfsg-3 (currently in buster)
and 8.0.2+dfsg-3+deb10u1 attached.

The changelog is

swi-prolog (8.0.2+dfsg-3+deb10u1) stable; urgency=medium

  * Add patch to fix pack-server (Closes: #939257)

 -- Lev Lamberov   Tue, 03 Sep 2019 00:15:43 +0500

Also, I've created a branch for buster (branch name is buster) in
swi-prolog Salsa repository, and since I use gbp to work on the
package I've changed d/gbp.conf from debian-branch = master to
debian-branch = buster.

Please, take a look at the proposed changes.

With regards,
Lev Lamberov

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru swi-prolog-8.0.2+dfsg/debian/changelog 
swi-prolog-8.0.2+dfsg/debian/changelog
--- swi-prolog-8.0.2+dfsg/debian/changelog  2019-03-12 14:52:05.0 
+0500
+++ swi-prolog-8.0.2+dfsg/debian/changelog  2019-09-03 00:15:43.0 
+0500
@@ -1,3 +1,9 @@
+swi-prolog (8.0.2+dfsg-3+deb10u1) stable; urgency=medium
+
+  * Add patch to fix pack-server (Closes: #939257)
+
+ -- Lev Lamberov   Tue, 03 Sep 2019 00:15:43 +0500
+
 swi-prolog (8.0.2+dfsg-3) unstable; urgency=medium
 
   * Add better handling of symlink creation (by means of CMake).
diff -Nru swi-prolog-8.0.2+dfsg/debian/gbp.conf 
swi-prolog-8.0.2+dfsg/debian/gbp.conf
--- swi-prolog-8.0.2+dfsg/debian/gbp.conf   2019-03-12 14:52:05.0 
+0500
+++ swi-prolog-8.0.2+dfsg/debian/gbp.conf   2019-09-03 00:15:43.0 
+0500
@@ -4,7 +4,7 @@
 # the default branch for upstream sources:
 upstream-branch = upstream
 # the default branch for the debian patch:
-debian-branch = master
+debian-branch = buster
 # the default tag formats used:
 upstream-tag = upstream/%(version)s
 debian-tag = debian/%(version)s
diff -Nru swi-prolog-8.0.2+dfsg/debian/patches/series 
swi-prolog-8.0.2+dfsg/debian/patches/series
--- swi-prolog-8.0.2+dfsg/debian/patches/series 2019-03-12 14:52:05.0 
+0500
+++ swi-prolog-8.0.2+dfsg/debian/patches/series 2019-09-03 00:15:43.0 
+0500
@@ -2,3 +2,4 @@
 use-local-jquery.diff
 no_extra_documentation.diff
 jpl-install.diff
+use_https_for_pack-server.diff
diff -Nru swi-prolog-8.0.2+dfsg/debian/patches/use_https_for_pack-server.diff 
swi-prolog-8.0.2+dfsg/debian/patches/use_https_for_pack-server.diff
--- swi-prolog-8.0.2+dfsg/debian/patches/use_https_for_pack-server.diff 
1970-01-01 05:00:00.0 +0500
+++ swi-prolog-8.0.2+dfsg/debian/patches/use_https_for_pack-server.diff 
2019-09-03 00:15:43.0 +0500
@@ -0,0 +1,20 @@
+From 2f36f408be0abc1f6d4915534334fece26af5450 Mon Sep 17 00:00:00 2001
+From: Jan Wielemaker 
+Date: Fri, 14 Jun 2019 09:48:16 +0200
+Subject: [PATCH] FIXED: Use https to contact the pack server.
+
+---
+ library/prolog_pack.pl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/library/prolog_pack.pl
 b/library/prolog_pack.pl
+@@ -90,7 +90,7 @@ makes installed packages available as li
+  *  CONSTANTS   *
+  ***/
+ 
+-:- setting(server, atom, 'http://www.swi-prolog.org/pack/',
++:- setting(server, atom, 'https://www.swi-prolog.org/pack/',
+'Server to exchange pack information').
+ 
+ 

Bug#939165: nmh: spost execs /usr/lib/mh/nmh/post, could do with s:nmh/::

[Alexander Zangerl]

On Sun, 01 Sep 2019 21:33:34 +0200, Robert Waldner writes:
>Upgraded jessie->strecch->buster, spost no longer coooperated. When used
>via exmh I got
>"/usr/lib/mh/spost: 13: exec: /usr/lib/mh/nmh/post: not found"

thanks. i'll fix that in the next upload. however: spost has been
marked deprecated and superseded by post since the 1.6 release, and
you should very likely change your postproc in .mh_profile to post.

cheers
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
A)bort, R)etry, P)ee in drive door


signature.asc
Description: Digital Signature

Bug#939314: BUG: scheduling while atomic

[Michael De Backer]

Package: src:linux
Version: 4.19.37-5+deb10u2
Severity: important

Hello,

Debian Buster systems often hangs with the rt kernel.
The mouse cursor still moves, the keyboard does not respond except to magic
keys.
The system still answers from the network.

I'm using an AMD graphic card with xserver-xorg-video-amdgpu driver.

This happened with xorg, during heavy opengl load:
Aug 27 13:35:52 amsterdam kernel: [ 5596.067265] BUG: scheduling while atomic:
Xorg/1335/0x0003
Aug 27 13:35:52 amsterdam kernel: [ 5596.067265] Modules linked in: asix usbnet
mii libphy fuse binfmt_misc pl2303 usbserial intel_rapl joydev intel_powerclamp
coretemp kvm irqbypass intel_cstate eeepc_wmi asus_wmi intel_uncore
sparse_keymap snd_hda_codec_realtek sg rfkill wmi_bmof snd_hda_codec_generic
intel_rapl_perf pcspkr snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support
snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm evdev snd_timer
mei_me pcc_cpufreq snd soundcore mei parport_pc ppdev lp parport ip_tables
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb
algif_skcipher af_alg dm_crypt dm_mod amdgpu chash gpu_sched hid_generic usbhid
hid ata_generic sd_mod radeon crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel pcbc i2c_algo_bit ttm ahci libahci xhci_pci drm_kms_helper
aesni_intel ehci_pci
Aug 27 13:35:52 amsterdam kernel: [ 5596.067291]  xhci_hcd ehci_hcd aes_x86_64
libata crypto_simd drm cryptd usbcore glue_helper scsi_mod lpc_ich i2c_i801
e1000e usb_common thermal fan video mxm_wmi wmi button
Aug 27 13:35:52 amsterdam kernel: [ 5596.067297] Preemption disabled at:
Aug 27 13:35:52 amsterdam kernel: [ 5596.067302] []
reservation_object_add_shared_fence+0x2b1/0x4a0
Aug 27 13:35:52 amsterdam kernel: [ 5596.067304] CPU: 3 PID: 1335 Comm: Xorg
Not tainted 4.19.0-5-rt-amd64 #1 Debian 4.19.37-5+deb10u2
Aug 27 13:35:52 amsterdam kernel: [ 5596.067305] Hardware name: System
manufacturer System Product Name/SABERTOOTH Z77, BIOS 2104 08/13/2013
Aug 27 13:35:52 amsterdam kernel: [ 5596.067305] Call Trace:
Aug 27 13:35:52 amsterdam kernel: [ 5596.067312]  dump_stack+0x5c/0x80
Aug 27 13:35:52 amsterdam kernel: [ 5596.067314]  ?
reservation_object_add_shared_fence+0x2b1/0x4a0
Aug 27 13:35:52 amsterdam kernel: [ 5596.067316]
__schedule_bug.cold.84+0x44/0x51
Aug 27 13:35:52 amsterdam kernel: [ 5596.067317]  __schedule+0x5ca/0x6c0
Aug 27 13:35:52 amsterdam kernel: [ 5596.067319]  ?
_raw_spin_lock_irq+0x1a/0x40
Aug 27 13:35:52 amsterdam kernel: [ 5596.067321]  schedule+0x39/0xe0
Aug 27 13:35:52 amsterdam kernel: [ 5596.067322]
rt_spin_lock_slowlock_locked+0x10e/0x2b0
Aug 27 13:35:52 amsterdam kernel: [ 5596.067323]
rt_spin_lock_slowlock+0x50/0x80
Aug 27 13:35:52 amsterdam kernel: [ 5596.067326]
__wake_up_common_lock+0x61/0xb0
Aug 27 13:35:52 amsterdam kernel: [ 5596.067346]
radeon_fence_is_signaled+0x6d/0x90 [radeon]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067349]
reservation_object_add_shared_fence+0x327/0x4a0
Aug 27 13:35:52 amsterdam kernel: [ 5596.067364]
radeon_vm_bo_update+0x41c/0x660 [radeon]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067380]
radeon_gem_va_ioctl+0x412/0x4f0 [radeon]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067395]  ?
radeon_gem_pread_ioctl+0x11/0x20 [radeon]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067408]  ?
radeon_gem_get_tiling_ioctl+0x120/0x120 [radeon]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067420]  drm_ioctl_kernel+0xa1/0xf0
[drm]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067430]  drm_ioctl+0x206/0x3a0 [drm]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067443]  ?
radeon_gem_get_tiling_ioctl+0x120/0x120 [radeon]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067445]  ? unpin_current_cpu+0x3a/0x80
Aug 27 13:35:52 amsterdam kernel: [ 5596.067447]  ? migrate_enable+0x1db/0x360
Aug 27 13:35:52 amsterdam kernel: [ 5596.067448]  ?
_raw_spin_unlock_irqrestore+0x20/0x60
Aug 27 13:35:52 amsterdam kernel: [ 5596.067458]  radeon_drm_ioctl+0x49/0x80
[radeon]
Aug 27 13:35:52 amsterdam kernel: [ 5596.067461]  do_vfs_ioctl+0xa4/0x630
Aug 27 13:35:52 amsterdam kernel: [ 5596.067462]  ? __fget+0x6e/0xa0
Aug 27 13:35:52 amsterdam kernel: [ 5596.067464]  ksys_ioctl+0x60/0x90
Aug 27 13:35:52 amsterdam kernel: [ 5596.067466]  __x64_sys_ioctl+0x16/0x20
Aug 27 13:35:52 amsterdam kernel: [ 5596.067468]  do_syscall_64+0x53/0x110
Aug 27 13:35:52 amsterdam kernel: [ 5596.067470]
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Aug 27 13:35:52 amsterdam kernel: [ 5596.067471] RIP: 0033:0x7f1294693427
Aug 27 13:35:52 amsterdam kernel: [ 5596.067473] Code: 00 00 90 48 8b 05 69 aa
0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00
00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8
64 89 01 48
Aug 27 13:35:52 amsterdam kernel: [ 5596.067473] RSP: 002b:7ffd4d2650d8
EFLAGS: 0246 ORIG_RAX: 0010
Aug 27 13:35:52 amsterdam kernel: [ 5596.067474] RAX: ffda RBX:
0002 RCX: 7f1294693427
Aug 27 13:35:52 amsterdam kernel: [ 5596.067475] RDX

Bug#939294: [Pkg-utopia-maintainers] Bug#939294: network-manager: After upgrade to 1.20.0-1, mac address of wlan0 is randomized

[Michael Biebl]

Am 03.09.19 um 09:20 schrieb Jörn Heissler:
> 
> The flaw can be triggered easily:
> 
> # systemctl restart wpa_supplicant.service; sleep 1.5; systemctl restart 
> NetworkManager.service

This works just fine here (using iwlwifi).

-- 
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#939316: cups-browsed: ERROR: Unable to create print queue, ignoring printer.

[Paul Menzel]

Package: cups-browsed
Version: 1.24.0-1
Severity: important
Tags: upstream
Forwarded: https://github.com/OpenPrinting/cups-filters/issues/148

Dear Debian folks,


Printing fails with cups-browsed 1.25.3, and 1.25.4 with the error
below.

> No destination host name supplied by cups-browsed for printer 
> \"EPSON_WF_2660_Series\", is cups-browsed running?

cups-browsed is indeed not running, and starting it manually with
`--debug` there are errors.

> Tue Sep  3 09:06:54 2019 Could not determine system default printer!
> Tue Sep  3 09:06:54 2019 find_previous_queue() in THREAD 140164762878016
> Tue Sep  3 09:06:54 2019 get-printer-attributes IPP call failed on printer 
> epson_wf_2660_series (implicitclass://EPSON_WF_2660_Series/).
> Tue Sep  3 09:06:54 2019 ERROR: Unable to create print queue, ignoring 
> printer.
> Tue Sep  3 09:06:54 2019 ERROR: Unable to allocate memory.

Please find more details in the upstream issue [1].

I was tempted to set the severity to *grave*, but as version 1.25.3
is in testing already, and there are not more bug reports about this
in the Debian BTS, I assume it does not affect so many people.


Kind regards,

Paul


[1]: https://github.com/OpenPrinting/cups-filters/issues/148



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#939315: ITS: ledmon maintenance

[Woodrow Shen (Shye-Tzeng Shen)]

Package: ledmon
Severity: important

Hello,

We're addressing ledmon maintenance internally as Intel is the current upstream
on github[1], and they are developing/fixing all the time. Moreover, they'd
like to have the latest version on Debian/Ubuntu because there are missing
patches that need to be landed.

Jared is a current maintainer listed in ledmon package and he intends to orphan
ledmon due to resources lacking, so that's purpose I try to start applying
package salvaging process.

According to package salvaging wiki[2], current ledmon package matches several
criteria:

1. Missing upstream releases (Now it's 0.90-1 and we need to upstream 0.92
version at least.); AND
2. There is the need to upload the package to deal with these issues[3]; AND
3. The last upload was an NMU and there was no maintainer upload within one
year[4]

Consequently, from my understanding, now ledmon should be eligible for package
salvaging, as long as Jared agrees above.

Any objections will be welcome, thank you.

[1] intel/ledmon: Enclosure LED Utilities - https://github.com/intel/ledmon
[2] PackageSalvaging, https://wiki.debian.org/PackageSalvaging
[3] https://bugs.launchpad.net/ubuntu/+source/ledmon
[4] https://tracker.debian.org/pkg/ledmon

Cheers,
Woodrow

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-58-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to zh_TW.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#939317: anjuta: Anjuta crashes when clicking or using keyboard shortcut

[Michael De Backer]

Package: anjuta
Version: 2:3.28.0-5
Severity: important
Tags: patch

Hello,

Clicking in the gui or using keyboard shortcuts (ie Build) sometimes makes
Anjuta crash.
It happens on a regular basis, a few times a day, but i'm unable to trigger it.

Here are some backtraces that may be helpful:

Thread 1 "anjuta" received signal SIGSEGV, Segmentation fault.
0x774dd545 in g_type_check_instance_is_fundamentally_a () from
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(gdb) bt
#0  0x774dd545 in g_type_check_instance_is_fundamentally_a () at
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x774bdc95 in g_object_unref () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#2  0x77ac10ed in gtk_style_context_set_frame_clock () at
/lib/x86_64-linux-gnu/libgtk-3.so.0
#3  0x77b5eacc in gtk_widget_unrealize () at /lib/x86_64-linux-
gnu/libgtk-3.so.0
#4  0x77b6ae1d in gtk_widget_unparent () at /lib/x86_64-linux-
gnu/libgtk-3.so.0
#5  0x778fc8b9 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#6  0x774bbfff in g_cclosure_marshal_VOID__OBJECTv () at
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x774b8ec6 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x774d538d in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#9  0x774d597f in g_signal_emit () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#10 0x7794b6a6 in gtk_container_remove () at /lib/x86_64-linux-
gnu/libgtk-3.so.0
#11 0x77b61233 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x774bf5f8 in g_object_run_dispose () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#13 0x77b0e1b5 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x77b0eb48 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#15 0x774b8c8d in g_closure_invoke () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#16 0x774cc4b4 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x774d52be in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#18 0x774d597f in g_signal_emit () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#19 0x774bd364 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x774bf801 in g_object_notify () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#21 0x774b8c8d in g_closure_invoke () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#22 0x774cc365 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x774d52be in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#24 0x774d597f in g_signal_emit () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#25 0x774bd364 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x774bcc6e in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#27 0x774c0c41 in g_object_set_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#28 0x774c179c in g_object_set () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#29 0x7fffe31ef4c1 in update_module_ui (bb_plugin=) at
plugin.c:1874
#30 0x773088f8 in  () at /lib/x86_64-linux-gnu/libanjuta-3.so.0
#31 0x774b8c8d in g_closure_invoke () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#32 0x774cc365 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#33 0x774d52be in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#34 0x774d5e56 in g_signal_emit_by_name () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#35 0x55560b54 in anjuta_window_remove_value (shell=,
name=0x7079d530 "document_manager_current_document", error=)
at anjuta-window.c:1107
#36 0x55560d2e in anjuta_window_add_value (shell=0x558fa3a0,
name=0x7079d530 "document_manager_current_document", value=0x7fffd160,
error=0x0) at anjuta-window.c:1034
#37 0x7078c288 in on_document_changed (docman=,
doc=0x561ed1a0, plugin=0x55b70c50) at plugin.c:1183
#38 0x774b8c8d in g_closure_invoke () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#39 0x774cc365 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#40 0x774d52be in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#41 0x774d5e56 in g_signal_emit_by_name () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#42 0x774b8c8d in g_closure_invoke () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#43 0x774cc365 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#44 0x774d52be in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#45 0x774d597f in g_signal_emit () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#46 0x77a3f3ff in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#47 0x77baa274 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#48 0x774b8ec6 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#49 0x774d4d74 in g_signal_emit_valist () at /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#50 0x774d597f

Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Julien Cristau]

On Tue, Sep  3, 2019 at 10:32:11 +0200, Bjørn Mork wrote:

> But you can't really expect users to look at xserver-xorg-input-libinput
> at all.  Why should they?  There is no pointer to it from the "obsolete"
> package.  What kind of deprecation is that? Most users will probably
> read the first lines of the verbose xserver-xorg-input-synaptics
> description, see "enable advanced features of the Synaptics Touchpad",
> and think "YES! I want that!".
> 
Users shouldn't have to think about it.  It's our job to make our
install process do the right thing in the first place.

Cheers,
Julien

Bug#939308: gkrellm2-cpufreq_0.6.4-5_mips64el.changes REJECTED

[John Paul Adrian Glaubitz]

Dear FTP Masters!

> On 2019-09-02 23:19, Debian FTP Masters wrote:
>> gkrellm-cpufreq_0.6.4-5_mips64el.deb: Missing mandatory field 
>> gkrellm-cpufreq_0.6.4-5_mips64el.deb.
>>
>>
>>
>> ===
>>
>> Please feel free to respond to this email if you don't understand why
>> your files were rejected, or if you upload new files which address our
>> concerns.

I don't quite understand what the problem with this particular upload is and 
therefore
don't know how to fix it. Could someone give me a quick heads-up why the binary
packages built on the release buildds got rejected?

FWIW, the builds on the ports buildds were installed without any problems, so
it must be DAK-specific.

Thanks,
Adrian

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

Bug#939318: RFP: megacmd -- a command line client for Mega.nz

[Kobus van Schoor]

Package: megacmd
Severity: wishlist

megacmd is a command line client for the popular Mega.nz file hosting
platform. The repository for the source code can be found at
https://github.com/meganz/MEGAcmd - there is already debian packages
available on their official website. The package is licensed under the GNU
General Public License. There is already a megatools package in the repos
but this is not the official client and doesn't have all the features that
the official client has.

Bug#938925: xmds2: fails mpi hdf5 tests

[Drew Parsons]

Package: xmds2
Version: 3.0.0+dfsg-2
Followup-For: Bug #938925
Control: tags -1 + ftbfs

The test failure also means xmds2 FTBFS.

Bug#939315: ITS: ledmon maintenance

[Woodrow Shen (Shye-Tzeng Shen)]

Package: ledmon
Followup-For: Bug #939315

Loop maintainer and related

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-58-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to zh_TW.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#537284: Ligature fi becoming ø in avant garde

[Hilmar Preuße]

On 16.07.09 19:27, Anthony DeRobertis wrote:

Hi Anthony,

> The following input:
> 
>   \documentclass{article}
>   \usepackage{avant}
>   \usepackage[T1]{fontenc}
>   \begin{document}
> 
>   first
> 
>   \textsf{first}
> 
>   \end{document}
> 
> with the following command:
> 
>   mk4ht htlatex a.tex "html,uni-html4,css2,charset=utf-8,info" " -cunihtf 
> -utf8"
> 
> gets the following HTML output:
> 
>   first
> 
>   ørst 
> 
> Notice how the fi (fi; U+FB01) ligature becomes ø (small o stroke; U+00F8).
> 
We got the following two statements from upstream:

Michal Hoftich:

Thanks for the report. The 8-bit fonts can be sometimes a bit mess. Even
if a standard encoding is used, some characters, especially ligatures
can be non-standard, which results in such errors. tex4ht uses special
files with conversion tables between font characters and Unicode. These
tables were originally written by hand, so they may contain errors.

I've fixed the files using Htfgen [1], tool that can generate conversion
tables automatically. I've fixed lot of bugs and added new features to
this tool, so the updates for text fonts should be mostly automatic in
the future.
Math fonts are a different story, as they often contain unique glyphs
that are not even in Unicode.

Karl Berry:

I committed the new versions of the adobe htf files to TeX Live (r51905).

I also realized that a number of htf files were being generated in
tex4ht dev but weren't in TL yet, so I committed those too (r51906).

Finally, I noticed that three files in TL were no longer being generated
(as far as I could see), so I removed them:
unicode/ec/eccc.htf
unicode/pxfonts/pxbsyc.htf
unicode/txfonts/t1x.htf
(in texmf-dist/tex4ht/ht-fonts). Guess we'll see if that causes trouble.

More discrepancies remain between dev and tl, but we'll resolve those
another time. Closing this ...


Now your minimal example works and also the other font families you
mentioned later one, except "chancery". I guess I have to open another
bug w/ lower prio to have this part of the issue solved too.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#937549: pystemmer: Python2 removal in sid/bullseye

[Dmitry Shachnev]

Hi Stefano,

On Mon, Sep 02, 2019 at 11:32:00AM -0300, Stefano Rivera wrote:
> Control: block 937549 with 938426 938528 883146
>
> Happy to, but there are still a couple of reverse-deps:
>
> [...]
>
> Reverse-Build-Depends-Indep
> ===
> * sphinx

Sphinx is not going to be fixed anytime soon:

$ reverse-depends -b python-sphinx -l | wc -l
279

I can switch it to use python-snowballstemmer (pure Python generated code),
but that won't change much, as we won't be able to remove *that* package.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#939318:

[Kobus van Schoor]

Package: wnpp

Bug#933320: abcm2ps: diff for NMU version 8.14.5-0.1

[Nicolas Boulenguez]

Control: tags 933320 + patch
Control: tags 933320 + pending


Dear maintainer,

I've prepared an NMU for abcm2ps (versioned as 8.14.5-0.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru abcm2ps-8.14.2/abcm2ps.c abcm2ps-8.14.5/abcm2ps.c
--- abcm2ps-8.14.2/abcm2ps.c	2018-12-18 16:18:26.0 +0100
+++ abcm2ps-8.14.5/abcm2ps.c	2019-07-17 09:44:10.0 +0200
@@ -2,14 +2,14 @@
  * abcm2ps: a program to typeset tunes written in ABC format
  *	using PostScript or SVG
  *
- * Copyright (C) 1998-2017 Jean-François Moine (http://moinejf.free.fr)
+ * Copyright (C) 1998-2019 Jean-François Moine (http://moinejf.free.fr)
  *
- * Adapted from abc2ps-1.2.5:
- *  Copyright (C) 1996,1997  Michael Methfessel (m...@ihp-ffo.de)
+ * Adapted from abc2ps
+ * Copyright (C) 1996-1998  Michael Methfessel (https://github.com/methf/abc2ps/)
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
+ * abcm2ps is free software: you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation, either version 3 of the License, or
  * (at your option) any later version.
  */
 
diff -Nru abcm2ps-8.14.2/abcm2ps.h abcm2ps-8.14.5/abcm2ps.h
--- abcm2ps-8.14.2/abcm2ps.h	2018-12-18 16:18:26.0 +0100
+++ abcm2ps-8.14.5/abcm2ps.h	2019-07-17 09:44:10.0 +0200
@@ -312,6 +312,7 @@
 #define S_SHIFTUNISON_2	0x0400	/* %%shiftunison 2 */
 #define S_NEW_SY	0x0800	/* staff system change (%%staves) */
 #define S_RBSTART	0x1000	// start of repeat bracket
+#define S_OTTAVA	0x2000	// ottava decoration (start or stop)
 	struct posit_s posit;	/* positions / directions */
 	signed char stem;	/* 1 / -1 for stem up / down */
 	signed char combine;	/* voice combine */
diff -Nru abcm2ps-8.14.2/abcparse.c abcm2ps-8.14.5/abcparse.c
--- abcm2ps-8.14.2/abcparse.c	2018-12-18 16:18:26.0 +0100
+++ abcm2ps-8.14.5/abcparse.c	2019-07-17 09:44:10.0 +0200
@@ -1,12 +1,14 @@
 /*
  * Generic ABC parser.
  *
- * Copyright (C) 1998-2018 Jean-François Moine
- * Adapted from abc2ps, Copyright (C) 1996, 1997 Michael Methfessel
+ * This file is part of abcm2ps.
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
+ * Copyright (C) 1998-2019 Jean-François Moine (http://moinejf.free.fr)
+ * Adapted from abc2ps, Copyright (C) 1996-1998 Michael Methfessel
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; either version 3 of the License, or
  * (at your option) any later version.
  */
 
diff -Nru abcm2ps-8.14.2/buffer.c abcm2ps-8.14.5/buffer.c
--- abcm2ps-8.14.2/buffer.c	2018-12-18 16:18:26.0 +0100
+++ abcm2ps-8.14.5/buffer.c	2019-07-17 09:44:10.0 +0200
@@ -3,12 +3,12 @@
  *
  * This file is part of abcm2ps.
  *
- * Copyright (C) 1998-2017 Jean-François Moine
- * Adapted from abc2ps, Copyright (C) 1996,1997 Michael Methfessel
+ * Copyright (C) 1998-2019 Jean-François Moine
+ * Adapted from abc2ps, Copyright (C) 1996-1998 Michael Methfessel
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; either version 3 of the License, or
  * (at your option) any later version.
  */
 
diff -Nru abcm2ps-8.14.2/configure abcm2ps-8.14.5/configure
--- abcm2ps-8.14.2/configure	2018-12-18 16:18:26.0 +0100
+++ abcm2ps-8.14.5/configure	2019-07-17 09:44:10.0 +0200
@@ -1,8 +1,8 @@
 #! /bin/sh
 
 # (automatic update)
-VERSION=8.14.2
-VDATE=2018-12-18
+VERSION=8.14.5
+VDATE=2019-07-17
 
 CC=gcc
 CFLAGS="-g -O2 -Wall -pipe"
diff -Nru abcm2ps-8.14.2/debian/changelog abcm2ps-8.14.5/debian/changelog
--- abcm2ps-8.14.2/debian/changelog	2019-01-27 18:50:50.0 +0100
+++ abcm2ps-8.14.5/debian/changelog	2019-09-03 12:07:16.0 +0200
@@ -1,3 +1,13 @@
+abcm2ps (8.14.5-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release closes: #933320.  No more patches.
+  * Set build flags as ./configure arguments, the environment is ignored.
+  * Drop --as-needed linker flag, now the default in GCC-9.
+  * Standards-Version: 4.4.0. No changes.
+
+ -- Nicolas Boulenguez   Tue, 03 Sep 2019 12:07:16 +0200
+
 abcm2ps (8.14.2-0.2) unstable; urgency=medium
 
   * 

Bug#939320: RM: python-plwm -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

No upstream releases since 2009.

Popcon 41.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#939319: RM: python-contract -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

No upstream releases since 2007.

Popcon 46.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#939321: debfoster: Add option -y (to be used with -f) that will pass throught to apt, so debfoster can be run non-interactively

[David Wakelin]

Package: debfoster
Version: 2.7-2.1
Severity: wishlist

Dear Maintainer,

It is currently not possible to run debfoster entirely non-interactivly
when removing packages.

I suggest adding a -y option that will pass to apt and remove all the
packages without prompting.

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages debfoster depends on:
ii  libc6 2.27-3ubuntu1
ii  libgc1c2  1:7.4.2-8ubuntu1

Versions of packages debfoster recommends:
ii  apt  1.6.11

debfoster suggests no packages.

-- no debconf information

Bug#938165: python-setoptconf: Python2 removal in sid/bullseye

[Andrey Rahmatullin]

This is blocked by its autopkgtest: the build process runs 2to3 but the
test runs on the unmodified, py2-only source, and fails.


signature.asc
Description: PGP signature

Bug#937797: python-gnutls: Python2 removal in sid/bullseye

[Andrey Rahmatullin]

This can be RMed but has popcon 491.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#939081: RM: spykeviewer -- RoQA; RC buggy, unmaintained, obsolete libs (python2 and Qt4)

[Scott Kitterman]

On Sun, 01 Sep 2019 00:45:00 -0400 Scott Kitterman  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Also, depends on RC buggy packages.  Out of testing for over two years
> and missed the last release.

Confirmed by yoh dead upstream, can be removed.

Scott K

Bug#939082: RM: spykeutils -- RoQA; RC buggy, unmaintained, obsolete libs (python2)

[Scott Kitterman]

On Sun, 01 Sep 2019 00:46:39 -0400 Scott Kitterman  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Also depends on RC buggy libs.  Out of Testing for over two years.
> Missed the last stable release.

Confirmed by yoh dead upstream, can be removed.

Scott K

Bug#936883: libkate: Python2 removal in sid/bullseye

[Scott Kitterman]

On Fri, 30 Aug 2019 07:23:42 + Matthias Klose  wrote:
> Package: src:libkate
> Version: 0.4.1-9
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
...

This looks pretty dead upstream.  Any reason not to go ahead an remove this?

Scott K

Bug#939150: Fw: Bug#939150: Acknowledgement (libglib2.0: libglib2.0 fails to install)

[Jeroen Diederen]

Dear reader,

Please remove my bug report or close it. I no longer have the problem.

Regards,
Jeroen Diederen

Begin forwarded message:

Date: Sun, 01 Sep 2019 15:12:04 +
From: "Debian Bug Tracking System" 
To: Jeroen Diederen 
Subject: Bug#939150: Acknowledgement (libglib2.0: libglib2.0 fails to
install)


Thank you for filing a new Bug report with Debian.

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

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

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

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

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

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

-- 
939150: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939150
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#937797: [Python-modules-team] Bug#937797: python-gnutls: Python2 removal in sid/bullseye

[Scott Kitterman]

On Tuesday, September 3, 2019 6:43:24 AM EDT Andrey Rahmatullin wrote:
> This can be RMed but has popcon 491.

Since it's a module, not an app (so no one should be installing it just 
because), I think it can still go.

Scott K

Bug#939322: firefox-esr telling me firefox is running out of disk space when it isn't.

[shirish शिरीष]

Package: firefox-esr
Version: 68.0.2esr-1
Severity: normal

Hi all,

I get the message everytime I use firefox-esr . Firefox is running out
of disk space. Website contents may not display properly. Visit "Learn
More" to optimize your disk usage for better browsing experience.
Clicking on it sends me to
https://support.mozilla.org/en-US/kb/storage?redirectlocale=en-US&as=u&redirectslug=permission-store-data&utm_source=inproduct
which doesn't help me in anyway. It only wants to me clean cookies
etc. I have no way to tell which are stale cookies (not needed) and
which are fresh cookies which I need .

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (500,
'stable-debug'), (100, 'unstable-debug'), (100, 'experimental'), (100,
'unstable'), (50, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6.3
ii  fontconfig2.13.1-2+b1
ii  libasound21.1.8-1
ii  libatk1.0-0   2.33.3+really2.32.0-4
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.9.1-4
ii  libgcc1   1:9.2.1-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.60.6-2
ii  libgtk-3-03.24.10-1
ii  libjsoncpp1   1.7.4-3+b1
ii  libnspr4  2:4.21-2
ii  libnss3   2:3.45-1
ii  libpango-1.0-01.42.4-7
ii  libsqlite3-0  3.29.0-2
ii  libstartup-notification0  0.12-6
ii  libstdc++69.2.1-4
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2+b1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.1.4-1+b2

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-6
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.99.2-1

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#939323: haskell-serialise: huge build logs

[Julien Cristau]

Source: haskell-serialise
Version: 0.2.1.0-3
Severity: serious

root@arm-arm-01:~# ls -lh 
/home/buildd/logs/haskell-serialise_0.2.1.0-3_armhf-2019-09-02T09\:05\:13Z 
-rw-rw-r-- 1 buildd buildd 11G Sep  3 11:11 
/home/buildd/logs/haskell-serialise_0.2.1.0-3_armhf-2019-09-02T09:05:13Z

Most of it is "tests: lost signal due to full pipe: 7" repeated over and over 
again.

Cheers,
Julien

Bug#935915: The problem went away

[sixerjman]

The last 4 or 5 days have seen a return to LAN speed transfers. I have no
idea why
it appeared or why it went away. There have been lots of WLAN errors as
reported
by my router. That may not have been the root cause but it certainly
wouldn't help.
Also, the Intel WiFi modem on one of the clients has been taking firmware,
so
that may have been a contributing factor.  Falls in 'The bug one that got
away'
category I guess. OK to close.

Bug#939322: See the attached picture and space in /home/shirish

[shirish शिरीष]

Dear all,

See the attached picture and the following output -

$ df -h /home
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda8   1.3T  1.2T  574M 100% /home

For some reason 500 MB seems to be less for firefox. And this is when
I have 24 GB of memory.

~$ free -h
  totalusedfree  shared  buff/cache   available
Mem:   23Gi   3.6Gi13Gi   297Mi   6.5Gi19Gi
Swap:  59Gi  0B59Gi

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#854197: systemd: please handle the case where socket activation leads to restart loop better

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Christian

On Sun, 5 Feb 2017 00:05:03 +0100 Christian Seiler 
wrote:
> while helping out on debian-mentors@ with #854192 I noticed that systemd
> doesn't appear to handle the case very well when dbus is installed but not
> configured properly (this was due to a bug in the usbguard package that
> missed a dependency on dbus), trying to start a Type=dbus service (that
> does DBus requests) will cause a nasty restart loop that you can only get
> out of if you stop dbus.socket - but it's very non-obvious that that is
> what you should do.
> 
> Steps to reproduce:
> 
>  - install a stretch system, minimal (tasksel empty), no DBus
>  - Recreate a broken DBus installation:
>   apt-get download libdbus-1-3 dbus
>   dpkg --install libdbus-1-3_*.deb
>   dpkg --unpack dbus_*.deb
>  - Create a dummy service:
>   cat > /etc/systemd/system/dummy.service
>   [Service]
>   BusName=org.example.dummy
>   ExecStart=/usr/bin/dbus-monitor --system
>   (Ctrl+D)
>  - Try to start that service
>   systemctl daemon-reload
>   systemctl start dummy
> 
> The dbus-monitor startup will cause dbus.socket to be triggered, which
> in turn will cause systemd to try to start dbus.service. Problem here is
> that dbus's postinst won't have run yet, so the "messagebus" user won't
> exist, so dbus-daemon won't start up propery.
> 
> Problem: this creates a restart loop, since systemd tries to restart
> the service over and over again because there's data on the DBus socket.
> I'm pretty sure you could also reproduce that with other services that
> are socket activated, but this definitely reproduces this.
> 

It seems I can't reproduce the problem with the steps you provided in
stretch VM. This is what I get:

> Sep 03 13:29:45 debian systemd[1]: Listening on D-Bus System Message Bus 
> Socket.
> Sep 03 13:29:45 debian systemd[1]: Starting dummy.service...
> Sep 03 13:29:45 debian systemd[1]: Started D-Bus System Message Bus.
> Sep 03 13:29:45 debian dbus-daemon[856]: Failed to start message bus: Could 
> not get UID and GID for username "messagebus"
> Sep 03 13:30:10 debian systemd[1]: Failed to subscribe to NameOwnerChanged 
> signal for 'org.example.dummy': Connection timed out
> Sep 03 13:30:10 debian systemd[1]: Failed to subscribe to NameOwnerChanged 
> signal for 'org.freedesktop.login1': Connection timed out
> Sep 03 13:30:10 debian systemd[1]: Failed to subscribe to activation signal: 
> Connection timed out
> Sep 03 13:30:10 debian systemd[1]: Failed to register name: Connection timed 
> out
> Sep 03 13:30:10 debian systemd[1]: Failed to set up API bus: Connection timed 
> out
> Sep 03 13:30:10 debian systemd[1]: dbus.service: Main process exited, 
> code=exited, status=1/FAILURE
> Sep 03 13:30:10 debian systemd[1]: dbus.service: Unit entered failed state.
> Sep 03 13:30:10 debian systemd[1]: dbus.service: Failed with result 
> 'exit-code'.
> Sep 03 13:31:15 debian systemd[1]: dummy.service: Start operation timed out. 
> Terminating.
> Sep 03 13:31:15 debian systemd[1]: Failed to start dummy.service.
> Sep 03 13:31:15 debian systemd[1]: dummy.service: Unit entered failed state.
> Sep 03 13:31:15 debian systemd[1]: dummy.service: Failed with result 
> 'timeout'.

I.e. the usual 90s timeout kicks in, after which the systemctl start
attempt fails.

Can you please double check that this is really still an issue with
stretch (and ideally with buster as well).

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#939325: lynis: Always aborts with "204: .: Can't open /usr/share/lynis/include/consts" if run as non-privileged user

[Axel Beckert]

Package: lynis
Version: 2.6.2-1
Severity: important
Tags: patch
Justification: major effect on the usability of a package, without rendering it 
completely unusable to everyone

Dear Francisco,

if I call lynis as non-privileged user, lynis always aborts with
"/usr/sbin/lynis: 204: .: Can't open /usr/share/lynis/include/consts".

But according to the lynis(8) man page, root privileges are not
necessarily needed to use lynis:

> Root permissions (e.g. sudo) are not required, however provide more
> details during the audit.

This issue is caused by /usr/share/lynis/include/consts only being
readable by root:

-rw--- 1 root root 9902 Feb 20  2018 /usr/share/lynis/include/consts

Actually all files in /usr/share/lynis/include/ have the wrong
permissions.

So please give all files under /usr/share/lynis/include/ standard 644
file permissions.

The following patch suffices and also removes the bogus lintian override:

--- debian/rules~   2018-01-23 16:27:01.0 +0100
+++ debian/rules2019-09-03 12:46:24.74752 +0200
@@ -58,7 +58,7 @@
dh_install
dh_link
dh_compress
-   dh_fixperms -Xinclude
+   dh_fixperms
dh_lintian -plynis
dh_installdeb
dh_gencontrol
--- debian/lynis.lintian-overrides~ 2018-01-23 16:27:01.0 +0100
+++ debian/lynis.lintian-overrides  2019-09-03 12:49:52.352114048 +0200
@@ -1,2 +1 @@
-lynis: non-standard-file-perm
 lynis: script-not-executable
\ No newline at end of file

P.S.: Yes, I am aware that this has been introduced in 1.3.9-1 and
1.6.0-1, but unfortunately the debian/changelog entry does only state
that this was needed, but doesn't explain at all, _why_ this was
needed. So I assume it's no more needed nowadays — in contrary, it's
harmful as of now.

-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), 
(400, 'proposed-updates-debug'), (400, 'proposed-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lynis depends on:
ii  e2fsprogs  1.44.5-1+deb10u1

Versions of packages lynis recommends:
ii  menu  2.1.47+b1

Versions of packages lynis suggests:
pn  aide  
ii  apt-listbugs  0.1.28
ii  debsecan  0.4.19
ii  debsums   2.2.3
ii  dnsutils  1:9.11.5.P4+dfsg-5.1
ii  fail2ban  0.10.2-2.1
pn  samhain   
pn  tripwire  

-- no debconf information

Bug#939222: libgcab-dev: missing dependency on libglib2.0-dev

[Stephen Kitt]

Hi Simon,

On Mon, 2 Sep 2019 10:53:32 +0100, Simon McVittie  wrote:
> Without libglib2.0-dev installed, invoking
> `pkg-config --cflags --libs libgcab-1.0` will fail. See attached patch
> 0001 for the obvious fix.
> 
> Please consider adding a superficial autopkgtest: this is easy to do
> for -dev packages, and proves that the development library can be used
> successfully. See attached patch 0002. I've been adding these to GNOME
> team libraries, and started writing one for gcab before I realised it
> wasn't a GNOME-team-maintained library :-)

Thanks, this and the follow-up patch are great, adding (good) autopkgtests is
fantastic!

Regarding the latter point, it would probably make sense for gcab to be
GNOME-team-maintained, but we can sort that out later...

> (A more involved autopkgtest using gcab-self-test requires upstream
> changes, which I'll propose separately.)

I’ve applied everything, thanks again.

Regards,

Stephen


pgpXvIDYnuvg4.pgp
Description: OpenPGP digital signature

Bug#939324: elixir: cannot be installed without Erlang from unstable

[Michal Sidor]

Source: elixir
Version: 1.9.1.dfsg-1~bpo10+1
Severity: normal

Dear Maintainer,

I tried installing elixir 1.9.1.dfsg-1~bpo10+1 from buster-backports.
Apt marked it broken and told me to upgrade erlang-base to a version
only available in unstable, even though installed version seemed to
match the requirement.

I think it may have something to do with #930497 because non-backports
elixir 1.7.4-0.1 depends on

erlang-base (>= 1:19) | erlang-base-hipe (>= 1:19),

while elixir 1.9.1.dfsg-1~bpo10+1 depends on

erlang-base:any (>= 1:20) | erlang-base-hipe:any (>= 1:20)

and it seems buster versions of erlang don't have Multi-Arch: allowed.

I'm not familiar enough with Debian packaging to try and suggest a fix.


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

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

Bug#939327: RM: python-gnutls -- RoM; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

The upstream code doesn't support Python 3 and there is no ongoing effort
or even an upstream issue about this.

Popcon 491. This is probably caused by sagemath, which depends on it in
oldstable but not in stable and has similar popcon values.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#939326: [gmsh] Could you please restore MED support?

[Christophe Trophime]

Package: gmsh
Version: 4.4.1+ds1-2
Severity: normal

MED support has been disabled in latest build.
This is very annoying.

Could we consider restore it?

I understand that it implies to rebuild with MPI support
since MED is compiled with MPI support.

Best
C

Bug#918672: same issue with bash scripts

[Thibault Roulet]

Hi,

Experiencing the same kind of problems with bash scripts.

Indentation is working fine under stretch but got some problems under
buster. Should I open a new case ?

Thibault

Bug#939328: linux-image-4.19.0-5-amd64: buster and stretch-backports kernel causes interfaces rename back to ethX on HPe DL360g10

[Sven Hoexter]

Package: src:linux
Version: 4.19.37-5+deb10u2
Severity: normal

Hi,
installing the latest update caused our NICs to be renamed from "enoX" back to 
"ethX". We first experienced
this issue on Debian/buster on HPe DL360g10 and now found the same issue with 
the latest upload of the same
kernel to stretch-backports.

We're now working around this issue by using
$ cat /etc/systemd/network/101-onboard-rd.link 
[Link]
NamePolicy=onboard kernel database slot path
MACAddressPolicy=none


That said on a system still running Debian/stretch with the old working kernel, 
without
the systemd workaround applied I've the following:

svenhoexter@docker-018:~$ uname -a
Linux docker-018 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-4~bpo9+1 
(2019-06-19) x86_64 GNU/Linux

svenhoexter@docker-018:~$ udevadm test-builtin net_id /sys/class/net/eno5 
2>/dev/null
ID_NET_NAME_ONBOARD=eno5
ID_NET_NAME_PATH=enp93s0f0

svenhoexter@docker-018:~$ SYSTEMD_LOG_LEVEL=debug udevadm test-builtin 
net_setup_link /sys/class/net/eno5
calling: test-builtin
=== trie on-disk ===
tool version:  232
file size: 8441068 bytes
header size 80 bytes
strings1846908 bytes
nodes  6594080 bytes
Load module index
Found container virtualization none
timestamp of '/etc/systemd/network' changed
Skipping overridden file: /lib/systemd/network/99-default.link.
Parsed configuration file /etc/systemd/network/99-default.link
Created link configuration context.
ID_NET_DRIVER=i40e
No matching link configuration found.
Unload module index
Unloaded link configuration context.


On a system with the new kernel and the applied workaround we've:

svenhoexter@docker-019:~$ uname -a
Linux docker-018 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) 
x86_64 GNU/Linux

svenhoexter@docker-019:~$ udevadm test-builtin net_id /sys/class/net/eno5 
2>/dev/null
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_ONBOARD=eno5
ID_NET_NAME_PATH=enp93s0f0

svenhoexter@docker-019:~$ SYSTEMD_LOG_LEVEL=debug udevadm test-builtin 
net_setup_link /sys/class/net/eno5
=== trie on-disk ===
tool version:  241
file size: 9492053 bytes
header size 80 bytes
strings2069269 bytes
nodes  7422704 bytes
Load module index
Failed to read $container of PID 1, ignoring: Permission denied
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Skipping overridden file '/usr/lib/systemd/network/99-default.link'.
Parsed configuration file /etc/systemd/network/99-default.link
Parsed configuration file /etc/systemd/network/101-onboard-rd.link
Created link configuration context.
ID_NET_DRIVER=i40e
Config file /etc/systemd/network/101-onboard-rd.link applies to device eno5
link_config: autonegotiation is unset or enabled, the speed and duplex are not 
writable.
link_config: could not set ethtool features for eno5
Could not set offload features of eno5: Operation not permitted
eno5: Device has name_assign_type=4
Using default interface naming scheme 'v240'.
eno5: Policy *onboard* yields "eno5".
ID_NET_LINK_FILE=/etc/systemd/network/101-onboard-rd.link
ID_NET_NAME=eno5
Unload module index
Unloaded link configuration context.


Any hint on how to provide additional input is appreciated.

Sven

Bug#861789: Please provide database.target as a synchronization point for applications providing databases and needing databases

[Michael Biebl]

Control: tags -1 + moreinfo

On Thu, 4 May 2017 17:47:17 +0200 Christian Hofstaedtler
 wrote:
> How will a database.target solve anything in those not so uncommon
> setups:
> 
> - database is remote
> 
> or
> 
> - one database needs another to start?
> 
> Please consider: if you end up with a solution that only works
> for 90% of installations - fails on 10% - is that actually
> solving your problem?


I don't understand the use case here.

Certainly, in a default apache and mysql configuration, there is no need
to delay the start of apache and wait until mysql, mariadb or whatever
other db has started (if multiple databases are installed, would we wait
for one of them, all of them?)
So introducing this artificial delay feels like a regression.

If there there is the need to actually start apache after mysql due to
how the system is configured for a specific use case, it's very easy to
achieve that with systemd by creating a drop-in snippet.

To pick up Christian's analogy:
If such a database.target is not useful for 90% of its users and
actually introduces artificial delays, does this relay outweigh the
benefit for those 10% who might benefit from it?

I feel like I need better arguments that such a target / synchronization
point is a good idea.
Especially, how and by which packages such a target should be used (and
this would probably need documentation as well)

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#939329: named crashes when setting nsec3param

[linux]

Package: bind9
Version: 1:9.11.5.P4+dfsg-5.1

Woke up this morning to the following in syslog. Looks to maybe be a
race condition when reloading zones that have changed and setting
nsec3params immediately after/during the reload.

Sep  3 05:56:06 odroid-dns named[29241]: zone bluematt.me/IN (unsigned):
loaded serial 2015412479
Sep  3 05:56:06 odroid-dns named[29241]: received control channel
command 'signing -nsec3param 1 0 100 D1D6B923 mattcorallo.com'
Sep  3 05:56:06 odroid-dns named[29241]: ../../../lib/dns/rbtdb.c:1494:
REQUIRE(rbtdb->future_version == ((void *)0)) failed, back trace
Sep  3 05:56:06 odroid-dns named[29241]: #0 0xdda1f958 in ??
Sep  3 05:56:06 odroid-dns named[29241]: #1 0xb3437944 in ??
Sep  3 05:56:06 odroid-dns named[29241]: #2 0xb3a1368c in ??
Sep  3 05:56:06 odroid-dns named[29241]: #3 0xb3ad4bd4 in ??
Sep  3 05:56:06 odroid-dns named[29241]: #4 0xb345dca0 in ??
Sep  3 05:56:06 odroid-dns named[29241]: #5 0xb335b7e4 in ??
Sep  3 05:56:06 odroid-dns named[29241]: #6 0xb2ffbadc in ??
Sep  3 05:56:06 odroid-dns named[29241]: exiting (due to assertion failure)

Bug#915566: libsystemd-dev: static library not provided

[Simon McVittie]

On Sat, 31 Aug 2019 at 00:31:12 +0200, Michael Biebl wrote:
> Simon, have you tried building systemd with -Dstatic-libsystemd=true
> -Dstatic-libudev=true ? Does this produce something useful?

I haven't tried it.

> Upstream doesn't seem to be too keen on supporting static builds, so if
> we divert here downstream, I'd be interested if there is actual demand
> from users of such a libsystemd.a or if this all mostly hyphothetical.

This is hypothetical, and if you want to say "no" and mark this as wontfix
or close it, that's fine; but I wanted to ask the question rather than
making an assumption about the likely answer.

The context is that I have been trying to write autopkgtests for -dev
packages, on the basis that if we have a feature, we should prove that
it works; and I've found that when a library in the dependency stack is
shared-only (for example libdbus depends on libsystemd), it is not at
all obvious how to link statically to the depending library (libdbus).
The obvious rune

cc -Wl,--no-as-needed -static -otest test.c `pkg-config --static --cflags 
--libs dbus-1`

fails, because there is no libsystemd.a to link.

(I'm using -Wl,--no-as-needed because the test.c that I'm currently
playing with doesn't actually call into libdbus, and I don't want to
invalidate the test results by having the linker decide not to link
libdbus or libsystemd after all; in real autopkgtests I try to call at
least a harmless function like dbus_get_version().)

It is still possible to link libsystemd and libc dynamically, but libdbus
statically, with something like

cc -Wl,--no-as-needed -otest test.c `pkg-config --static --cflags --libs 
dbus-1 | perl -pe 's,(^|\s)-ldbus-1(\s|$), 
/usr/lib/x86_64-linux-gnu/libdbus-1\.a ,'`

but that requires you to know the physical location of the library, and
once you have to rely on *anything* with shared linkage, you might as
well bundle *everything* with shared linkage (and -Wl,-rpath,'$ORIGIN'
or similar), at which point you've gained nothing from static libraries.

That would point towards a conclusion that if a library like libdbus
has shared-only dependencies like libsystemd, then libdbus should also
become shared-only, which would reduce the size of the binary archive
and the time taken to compile, but would harm the possibly-hypothetical
use cases that are the reason Policy tells us to build static libraries?

Another possible direction would be to disable static libraries in
general, except in cases where a bug report indicates that a real user
genuinely wants them (and has a recipe for testing that they work).

smcv

Bug#939330: firmware-brcm80211: BCM4350 rev 08 wifi card speeds decline to sluggish 50 kB/s consistently

[Kyle Nathaniel]

Package: firmware-brcm80211
Version: 20190717-2
Severity: important

Dear Maintainer,

Recently I installed Debian Buster on a Dell XPS 13 9350 laptop, which
contains a BCM4350 rev. 08 wireless card. During the installation process I had
to grab one of the unofficial CD images containing the non-free firmware to get
that downloaded.

My internet has ~10MB/s upload/download speed, and on my other computers
the speeds are near this limit and are consistently at that speed.

However, usually speeds on this wireless card are abnormally at
100-200kB/s, sometimes as low as 30-50kB/s. Furthermore, it often
unpredictably switches between such low speeds and 1MB/s speed (which is
acceptable).

I first attempted to upgrade the firmware to their absolute latest versions,
which did not improve the situation. I also noticed that in the brcmfmac
description
that there's a file for rev. 5+ card but that brcmfmac is only loading the rev.
4 and
below card. I wonder if that might be part of the problem.

Anyway, here's some diagnostic information:

$ inxi -Fx
System:Host: 4 Kernel: 4.19.0-5-amd64 x86_64 bits: 64 compiler: gcc v:
8.3.0 Desktop: Cinnamon 3.8.8
   Distro: Debian GNU/Linux 10 (buster)
Machine:   Type: Laptop System: Dell product: XPS 13 9350 v: N/A serial: 
   Mobo: Dell model: 07TYC2 v: A00 serial:  UEFI: Dell
v: 1.10.1 date: 01/22/2019
Battery:   ID-1: BAT0 charge: 48.7 Wh condition: 51.5/57.5 Wh (89%) model: SMP
DELL JHXPY53 status: Unknown
CPU:   Topology: Dual Core model: Intel Core i5-6200U bits: 64 type: MT MCP
arch: Skylake rev: 3 L2 cache: 3072 KiB
   flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips:
19200
   Speed: 500 MHz min/max: 400/2800 MHz Core speeds (MHz): 1: 500 2:
500 3: 500 4: 500
Graphics:  Device-1: Intel HD Graphics 520 vendor: Dell Skylake GT2 driver:
i915 v: kernel bus ID: 00:02.0
   Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded:
fbdev,vesa resolution: 3200x1800~60Hz
   OpenGL: renderer: Mesa DRI Intel HD Graphics 520 (Skylake GT2) v:
4.5 Mesa 18.3.6 direct render: Yes
Audio: Device-1: Intel Sunrise Point-LP HD Audio vendor: Dell driver:
snd_hda_intel v: kernel bus ID: 00:1f.3
   Sound Server: ALSA v: k4.19.0-5-amd64
Network:   Device-1: Broadcom Limited BCM4350 802.11ac Wireless Network Adapter
vendor: Dell driver: brcmfmac v: kernel
   port: f040 bus ID: 3a:00.0
   IF: wlp58s0 state: up mac: 30:52:cb:81:ef:1d
Drives:Local Storage: total: 238.47 GiB used: 15.24 GiB (6.4%)
   ID-1: /dev/nvme0n1 vendor: Samsung model: PM951 NVMe 256GB size:
238.47 GiB
Partition: ID-1: / size: 225.49 GiB used: 14.94 GiB (6.6%) fs: ext4 dev:
/dev/nvme0n1p2
   ID-2: swap-1 size: 7.87 GiB used: 294.7 MiB (3.7%) fs: swap dev:
/dev/nvme0n1p3
Sensors:   System Temperatures: cpu: 39.0 C mobo: 27.8 C
   Fan Speeds (RPM): N/A
Info:  Processes: 240 Uptime: 11h 18m Memory: 7.66 GiB used: 3.03 GiB
(39.5%) Init: systemd runlevel: 5 Compilers:
   gcc: 8.3.0 clang: 7.0.1-8 Shell: bash v: 5.0.3 inxi: 3.0.32

$ sudo dmesg | grep brcm
[4.511409] usbcore: registered new interface driver brcmfmac
[4.511475] brcmfmac :3a:00.0: enabling device ( -> 0002)
[4.636428] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4350-pcie
for chip BCM4350/8
[4.641489] brcmfmac :3a:00.0: firmware: direct-loading firmware
brcm/brcmfmac4350-pcie.bin
[4.641508] brcmfmac :3a:00.0: firmware: failed to load
brcm/brcmfmac4350-pcie.txt (-2)
[4.641576] brcmfmac :3a:00.0: Direct firmware load for
brcm/brcmfmac4350-pcie.txt failed with error -2
[4.981502] bluetooth hci0: firmware: failed to load brcm/BCM-0a5c-6412.hcd
(-2)
[4.981532] bluetooth hci0: Direct firmware load for brcm/BCM-0a5c-6412.hcd
failed with error -2
[4.981534] Bluetooth: hci0: BCM: Patch brcm/BCM-0a5c-6412.hcd not found
[5.085081] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4350-pcie
for chip BCM4350/8
[5.085100] brcmfmac :3a:00.0: firmware: failed to load
brcm/brcmfmac4350-pcie.clm_blob (-2)
[5.085148] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available
(err=-2), device may have limited channels available
[5.085405] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4350/8 wl0: Oct 22
2015 06:16:26 version 7.35.180.119 (r594535) FWID 01-e791c176
[5.109605] brcmfmac :3a:00.0 wlp58s0: renamed from wlan0
[ 4577.706990] (NULL device *): firmware: direct-loading firmware
brcm/brcmfmac4350-pcie.bin
[ 4579.525336] WARNING: CPU: 2 PID: 221 at
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c:77
brcmf_pno_remove_request+0xac/0xd0 [brcmfmac]
[ 4579.525336] Modules linked in: rfcomm fuse squashfs zstd_decompress xxhash
cmac loop bnep snd_hda_codec_hdmi joydev intel_rapl binfmt_misc btusb btrtl
btbcm btintel bluetooth nls_ascii nls_cp437 vfat fat x86_pkg_temp_thermal drbg
intel_powerclamp coretemp dell_laptop kvm_intel ansi_cprng snd_soc_s

Bug#763579: systemd.exec(5) manpage does not reflect the Debian changes to ProtectSystem

[Michael Biebl]

On Wed, 01 Oct 2014 05:30:09 +0200 intrig...@debian.org wrote:
> Package: systemd
> Version: 215-5
> Severity: normal
> 
> Hi,
> 
> ProtectSystem was adjusted (#759689) to be better suitable for Debian,
> but the corresponding manpage wasn't updated accordingly.

I wonder if it wouldn't be a better idea to document such changes (where
we divert from upstream or make explicit decisions which are not the
upstream defaults) in systemd's README.Debian.

This seems like a more maintainable approach then patching man pages.
Those patches are bound to require on-going maintenance work to keep
them updated.

-- 
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#939331: lynis: Shouldn't look in /usr/games/ for package managers / starts the game "Pacman" when looking for ArchLinux's package manager "pacman"

[Axel Beckert]

Package: lynis
Version: 2.6.2-1
Severity: normal

Dear Francisco,

   * What led up to the situation?

Calling lynis as user (where /usr/games is in $PATH by default on
Debian).

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

Calling "lynis audit system" as unprivileged user (after fixing the
permissions bug reported in https://bugs.debian.org/939325).

   * What was the outcome of this action?

A window with the game Pacman popped up when lynis started what it
believed to be ArchLinux's package manager "pacman":


>From /tmp/lynis.log:

2019-09-03 13:03:13 
===---===
2019-09-03 13:03:13 Performing test ID PKGS-7310 (Checking package list with 
pacman)
2019-09-03 13:03:13 Result: Found pacman binary (/usr/games/pacman)
 ^^^
2019-09-03 13:03:13 Test: Querying 'pacman -Q' to get package list
2019-09-03 13:03:13 Output:
2019-09-03 13:03:13 
2019-09-03 13:13:58 Result: pacman binary available, but package list seems to 
be empty
2019-09-03 13:13:58 Info: looks like the pacman binary is installed, but not 
used for package installation

   * What outcome did you expect instead?

Not looking for package managers in /usr/games/ and hence skipping of
that test, because pacman, the package manager is not installed (and not
packaged for Debian either).

This probably can be considered a debian-specific issue as well as an
upstream issue. Hence not tagging as "upstream" for now.

P.S.: Other Debian packages had the same issue in the past when looking
for ArchLinux's package manager, too. The discussion in
https://bugs.debian.org/752114 contains some discussion and arguments on
how this kind of issues can be fixed.

-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), 
(400, 'proposed-updates-debug'), (400, 'proposed-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lynis depends on:
ii  e2fsprogs  1.44.5-1+deb10u1

Versions of packages lynis recommends:
ii  menu  2.1.47+b1

Versions of packages lynis suggests:
pn  aide  
ii  apt-listbugs  0.1.28
ii  debsecan  0.4.19
ii  debsums   2.2.3
ii  dnsutils  1:9.11.5.P4+dfsg-5.1
ii  fail2ban  0.10.2-2.1
pn  samhain   
pn  tripwire  

-- no debconf information

Bug#939326: [gmsh] Could you please restore MED support?

[Nico Schlömer]

Upstream recommends against using MPI [1], so we should probably stick to that.

You can always use meshio [2] to convert between mesh formats.

Cheers,
Nico

[1] https://gitlab.onelab.info/gmsh/gmsh/issues/502#note_6582
[2] https://github.com/nschloe/meshio


On Tue, Sep 3, 2019 at 1:51 PM Christophe Trophime
 wrote:
>
> Package: gmsh
> Version: 4.4.1+ds1-2
> Severity: normal
>
> MED support has been disabled in latest build.
> This is very annoying.
>
> Could we consider restore it?
>
> I understand that it implies to rebuild with MPI support
> since MED is compiled with MPI support.
>
> Best
> C

Bug#763579: systemd.exec(5) manpage does not reflect the Debian changes to ProtectSystem

[Michael Biebl]

Am 03.09.19 um 14:05 schrieb Michael Biebl:
> On Wed, 01 Oct 2014 05:30:09 +0200 intrig...@debian.org wrote:
>> Package: systemd
>> Version: 215-5
>> Severity: normal
>>
>> Hi,
>>
>> ProtectSystem was adjusted (#759689) to be better suitable for Debian,
>> but the corresponding manpage wasn't updated accordingly.
> 
> I wonder if it wouldn't be a better idea to document such changes (where
> we divert from upstream or make explicit decisions which are not the
> upstream defaults) in systemd's README.Debian.
> 
> This seems like a more maintainable approach then patching man pages.
> Those patches are bound to require on-going maintenance work to keep
> them updated.
> 

#827159 is related in that regard.

-- 
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#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups

[Nicolas Schier]

Control: retitle -1 ITP: git-revise -- handy git tool for doing efficient 
in-memory
Control: owner -1 nico...@fjasle.eu

Hei,

I have started packaging git-revise [1], would like to take over the
package maintainance and already got an warm ack from upstream for
Debian packaging.

Right now I am just targetting on providing a usable 'git-revise'
package; for seperating the python library into a seperate package I
would wait until a corresponding bug is filed.

Antoine, could you create a repository in salsa's 'debian' namespace?
(My salsa account is 'nsc-guest').

Would you be available as a sponsor (as soon as I have got rid of all
lintian issues)?

Thanks and kind regards,
Nicolas


[1]: https://salsa.debian.org/nsc-guest/git-revise -b debian/sid

Bug#931949: transition: proj

[Emilio Pozuelo Monfort]

On 03/09/2019 05:59, Sebastiaan Couwenberg wrote:
> On 9/2/19 11:12 AM, Sebastiaan Couwenberg wrote:
>> On 9/2/19 10:43 AM, Emilio Pozuelo Monfort wrote:
>>> There's also an autopkgtest regression for r-cran-sf as you can see in the
>>> excuses at https://packages.qa.debian.org/p/proj.html. That's blocking proj 
>>> from
>>> being a migration candidate.
>>
>> That's why I filed #939002.
>>
>> There is also the autopkgtest failure of pyresample (python-pyproj rdep)
>> for which #939128 was filed. For this I'm considering moving proj 5.2.0
>> & pyproj 2.3.1 from experimental to unstable if these autopkgtest
>> failure keep blocking the testing migration for more than a week.
> 
> The pyresample autopkgtest failure is fixed with proj 6.2.0-1 &
> python-pyproj 2.3.1+ds-1 in unstable.
> 
> Do we have to wait for testing autoremoval of r-cran-sf or can one of
> you hint it out?
> 
> If you want to get this transition done to start the perl transition,
> several packages in this transition also need aging:
> 
>  * proj
>  * python-pyproj
>  * osm2pgsql
>  * mapnik
>  * openorienteering-mapper
>  * qgis
>  * vtk6

I'm removing the R modules so that proj can migrate.

Cheers,
Emilio

Bug#894663: transition: wxwidgets3.0

[Emilio Pozuelo Monfort]

On 06/08/2019 22:29, Olly Betts wrote:
> On Sun, Sep 30, 2018 at 10:09:28AM +0100, Olly Betts wrote:
>> On Sun, Sep 30, 2018 at 08:47:00AM +, Niels Thykier wrote:
>>> Are we planning to complete this transition
>>> in buster (transition deadline being 2019-01-05) or it is fine if this
>>> transition is first completed in bullseye ?
>>
>> I'd still love to complete it for buster, but I suspect we may well not
>> manage to get all the remaining rdeps moved over.
>>
>> We never actually got around to filing bugs against rdeps, but perhaps
>> we should to encourage them to move where there aren't any blockers.
> 
> Now that we're post-release, Scott Talbert has filed bugs and the
> transition is progressing well (we've gone from 17% to 41% in just
> a week).
> 
> Please can you re-enable export for this transition so that it appears
> in tracker.d.o, etc?  I've attached a patch which should be suitable.

ftr, as discussed on irc, export is disabled so that the PTS doesn't ask
maintainers to avoid uploads of these packages.

Cheers,
Emilio

Bug#939332: ftp.debian.org: RM: PKG -- removal triggered by the Python2 removal

[Dirk Eddelbuettel]

Package: ftp.debian.org
Severity: normal
 
Tags: sid bullseye   
Usertags: py2removal

Motivation: Remove r-cran-nws (version 2.0.0.3-4) so that package 'nwsserver'
can be removed

Contexct: r-cran-nws is the only other client of nwsserver, and the reason
nwsserver and nwsclient were packaged in the first place.

nwsclient has already been removed (#937173), and nwserver (#937174) can once
this goes through.

Dirk

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

Bug#939333: varnish: VSV00003 DoS attack vector

[Salvatore Bonaccorso]

Source: varnish
Version: 6.2.0-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi

See https://varnish-cache.org/security/VSV3.html . A CVE does not
seem yet to be assigned (but a request pending now).

Regards,
Salvatore

Bug#939329: named crashes when setting nsec3param

[Ondřej Surý]

Hi,

could you please take a look if you have a core around and you could install 
debug symbols to decode the coredump?

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 3 Sep 2019, at 13:51, li...@bluematt.me wrote:
> 
> Package: bind9
> Version: 1:9.11.5.P4+dfsg-5.1
> 
> Woke up this morning to the following in syslog. Looks to maybe be a
> race condition when reloading zones that have changed and setting
> nsec3params immediately after/during the reload.
> 
> Sep  3 05:56:06 odroid-dns named[29241]: zone bluematt.me/IN (unsigned):
> loaded serial 2015412479
> Sep  3 05:56:06 odroid-dns named[29241]: received control channel
> command 'signing -nsec3param 1 0 100 D1D6B923 mattcorallo.com'
> Sep  3 05:56:06 odroid-dns named[29241]: ../../../lib/dns/rbtdb.c:1494:
> REQUIRE(rbtdb->future_version == ((void *)0)) failed, back trace
> Sep  3 05:56:06 odroid-dns named[29241]: #0 0xdda1f958 in ??
> Sep  3 05:56:06 odroid-dns named[29241]: #1 0xb3437944 in ??
> Sep  3 05:56:06 odroid-dns named[29241]: #2 0xb3a1368c in ??
> Sep  3 05:56:06 odroid-dns named[29241]: #3 0xb3ad4bd4 in ??
> Sep  3 05:56:06 odroid-dns named[29241]: #4 0xb345dca0 in ??
> Sep  3 05:56:06 odroid-dns named[29241]: #5 0xb335b7e4 in ??
> Sep  3 05:56:06 odroid-dns named[29241]: #6 0xb2ffbadc in ??
> Sep  3 05:56:06 odroid-dns named[29241]: exiting (due to assertion failure)
> 

Bug#939329: named crashes when setting nsec3param

[Ondřej Surý]

Control: forwarded -1 https://gitlab.isc.org/isc-projects/bind9/issues/1205

I also forwarded this to upstream issue tracker, this doesn’t seem Debian 
package specific.

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 3 Sep 2019, at 14:27, Ondřej Surý  wrote:
> 
> Hi,
> 
> could you please take a look if you have a core around and you could install 
> debug symbols to decode the coredump?
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
> 
> 
>> On 3 Sep 2019, at 13:51, li...@bluematt.me wrote:
>> 
>> Package: bind9
>> Version: 1:9.11.5.P4+dfsg-5.1
>> 
>> Woke up this morning to the following in syslog. Looks to maybe be a
>> race condition when reloading zones that have changed and setting
>> nsec3params immediately after/during the reload.
>> 
>> Sep  3 05:56:06 odroid-dns named[29241]: zone bluematt.me/IN (unsigned):
>> loaded serial 2015412479
>> Sep  3 05:56:06 odroid-dns named[29241]: received control channel
>> command 'signing -nsec3param 1 0 100 D1D6B923 mattcorallo.com'
>> Sep  3 05:56:06 odroid-dns named[29241]: ../../../lib/dns/rbtdb.c:1494:
>> REQUIRE(rbtdb->future_version == ((void *)0)) failed, back trace
>> Sep  3 05:56:06 odroid-dns named[29241]: #0 0xdda1f958 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #1 0xb3437944 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #2 0xb3a1368c in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #3 0xb3ad4bd4 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #4 0xb345dca0 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #5 0xb335b7e4 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #6 0xb2ffbadc in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: exiting (due to assertion failure)
>> 
> 

Bug#939335: RM: python-pyrax -- NPOASR; not maintained, RC buggy, not py2 compatible, not useful

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Dear FTP masters,

It is my opinion that python-pyrax has never been maintained the correct
way, as it never stayed for long in testing. See for yourself:

https://tracker.debian.org/pkg/python-pyrax

More over, it looks like upstream now mandates a specific version of
novaclient which isn't in Debian, and we'd need to package from HEAD
if we want Python 3 support, since upstream never taged such a Py3
capable version.

The package has also been RC buggy for 2 years.

If the current maintainer wishes to do the work and reintroduce the
package, ok. But in the mean while, it's preventing perfectly valid
packages to migrate from Sid to Testing (doing our Py2 removal effort
for Bullseye).

Cheers,

Thomas Goirand (zigo)

Bug#939334: FTBFS with OCaml 4.08.0 (safe strings)

[Stéphane Glondu]

Package: src:mldonkey
Version: 3.1.6-1
Severity: important
Tags: upstream
User: debian-ocaml-ma...@lists.debian.org
Usertags: ocaml-4.08-transition

Dear Maintainer,

mldonkey FTBFS with OCaml 4.08.0 due to -safe-string being the default
now.

I've tried fixing this, but changes are pretty invasive. I've reached
a point where only a new upstream release makes sense.


Cheers,

-- 
Stéphane

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

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

Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Bjørn Mork]

Julien Cristau  writes:

> Users shouldn't have to think about it.  It's our job to make our
> install process do the right thing in the first place.

Well, it doesn't, and most users are aware of that.  DTRT is hard. It's
almost impossible when hardware is part of the equation.  Debian is
good, but will for example fail to install support for 3G/LTE modems if
you happen to select the LXDE task, because lxde recommends

 wicd | network-manager-gnome

Just one example where a user will have to look for packages supporting
their specific hardware after installation.  I'm sure there are plenty
of similar edge cases.  Users expect it and act accordingly. The
existense of an "obsolete" package like xserver-xorg-input-synaptics,
with no indication that it is obsolete, is therefore a problem.

As shown by this completely unnecessary bug and discussion.



Bjørn

Bug#939078: bro: unfulfilled (build) dependencies libbroker-dev and libbroker0

[Hilko Bengen]

* Matthias Klose:

> according to https://tracker.debian.org/pkg/bro, it references a
> nn-existing libbroker0, and doesn't build on any other architecture
> because of a missing libbroker-dev package.

libbroker0 does not exist yet; src:broker is waiting in NEW (re-uploaded
after the first REJECT).

Cheers,
-Hilko

Bug#938962: user-mode-linux needs update for new linux

[Ritesh Raj Sarraf]

Control: tag -1 help


Adding libpcap's maintainer. Maybe he has some insight.


On Fri, 2019-08-30 at 17:28 +0200, Ivo De Decker wrote:
> The version of user-mode-linux in testing and unstable build-depends
> on
> linux-source-4.19, which is no longer available in testing.

THere seems to be a problem with the newer version of libpcap at
veresion 1.9.0.


  CC  arch/um/drivers/vde_user.o
  CC  arch/um/drivers/umcast_kern.o
  CC  arch/um/drivers/umcast_user.o
  CC  arch/um/drivers/pcap_kern.o
  CC  arch/um/drivers/pcap_user.o
arch/um/drivers/pcap_user.c:35:12: error: conflicting types for ‘pcap_open’
 static int pcap_open(void *data)
^
In file included from /usr/include/pcap.h:43,
 from arch/um/drivers/pcap_user.c:7:
/usr/include/pcap/pcap.h:835:18: note: previous declaration of ‘pcap_open’ was 
here
 PCAP_API pcap_t *pcap_open(const char *source, int snaplen, int flags,
  ^
make[2]: *** [scripts/Makefile.build:309: arch/um/drivers/pcap_user.o] Error 1
make[1]: *** [Makefile:1041: arch/um/drivers] Error 2
make[1]: Leaving directory '/tmp/user-mode-linux-4.19-1um/linux-source-4.19'
make: *** [debian/rules:75: build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
root@chutzpah:/tmp/user-mode-linux-4.19-1um# 
root@chutzpah:/tmp/user-mode-linux-4.19-1um# 


With the older version from Buster, it builds fine. But not with the
one in Debian Testing.

I am inclined to reassign this bug to libpcap but I think I don't have
more details of what is causing the failure.

Can anyone help here ?

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#939316: cups-browsed: ERROR: Unable to create print queue, ignoring printer.

[Till Kamppeter]

Fixed upstream. Thanks for the bug report.

See https://github.com/OpenPrinting/cups-filters/issues/148

Will be included in the next release, 1.25.5.

   Till

Bug#933096: libsane-common: Not possible to scan from remote clients

[MAG4 Piemonte]

Dear Maintainer, we also confirm the bug upgrading to Debian 10 ...
Regards!

Guido

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

I do have a core, but don't see what package to get debug symbols from?

Matt

On 9/3/19 12:27 PM, Ondřej Surý wrote:
> Hi,
> 
> could you please take a look if you have a core around and you could install 
> debug symbols to decode the coredump?
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
> 
> 
>> On 3 Sep 2019, at 13:51, li...@bluematt.me wrote:
>>
>> Package: bind9
>> Version: 1:9.11.5.P4+dfsg-5.1
>>
>> Woke up this morning to the following in syslog. Looks to maybe be a
>> race condition when reloading zones that have changed and setting
>> nsec3params immediately after/during the reload.
>>
>> Sep  3 05:56:06 odroid-dns named[29241]: zone bluematt.me/IN (unsigned):
>> loaded serial 2015412479
>> Sep  3 05:56:06 odroid-dns named[29241]: received control channel
>> command 'signing -nsec3param 1 0 100 D1D6B923 mattcorallo.com'
>> Sep  3 05:56:06 odroid-dns named[29241]: ../../../lib/dns/rbtdb.c:1494:
>> REQUIRE(rbtdb->future_version == ((void *)0)) failed, back trace
>> Sep  3 05:56:06 odroid-dns named[29241]: #0 0xdda1f958 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #1 0xb3437944 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #2 0xb3a1368c in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #3 0xb3ad4bd4 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #4 0xb345dca0 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #5 0xb335b7e4 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #6 0xb2ffbadc in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: exiting (due to assertion failure)
>>
> 

Bug#939336: iptables: fails to delete rules when running 32-bit userspace on 64-bit kernel

[Colin Watson]

Package: iptables
Version: 1.8.3-2
Severity: normal

When running an i386 container on an amd64 host system, "iptables -D"
fails to match existing rules correctly:

  # iptables -A OUTPUT -p tcp --dport 80 -j DROP
  # iptables -D OUTPUT -p tcp --dport 80 -j DROP
  iptables: Bad rule (does a matching rule exist in that chain?).

Some gdb work revealed that this is because match_size is wrong: it's
based on alignof(struct xt_align), and when adding a new rule the
kernel's netfilter compat interfaces adjust match_size to account for
the difference between userspace and kernel alignment, but this means
that the size isn't what userspace expects when it tries to match
existing rules.

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

Kernel: Linux 5.2.0-10-generic (SMP w/1 CPU core)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 iptables depends on:
ii  libc62.28-10
ii  libip4tc21.8.3-2
ii  libip6tc21.8.3-2
ii  libiptc0 1.8.3-2
ii  libmnl0  1.0.4-2+b1
ii  libnetfilter-conntrack3  1.0.7-2
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.4-1
ii  libxtables12 1.8.3-2

Versions of packages iptables recommends:
ii  nftables  0.9.2-1

Versions of packages iptables suggests:
pn  kmod  

-- no debconf information

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

Bug#939329: named crashes when setting nsec3param

[Ondřej Surý]

I don’t know why it’s not available in the stable, but since we haven’t updated 
the package in the unstable yet, it should be identical to:

https://packages.debian.org/unstable/bind9-dbgsym

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 3 Sep 2019, at 15:19, Matt Corallo  wrote:
> 
> I do have a core, but don't see what package to get debug symbols from?
> 
> Matt
> 
> On 9/3/19 12:27 PM, Ondřej Surý wrote:
>> Hi,
>> 
>> could you please take a look if you have a core around and you could install 
>> debug symbols to decode the coredump?
>> 
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@sury.org
>> 
>> 
>> 
>>> On 3 Sep 2019, at 13:51, li...@bluematt.me wrote:
>>> 
>>> Package: bind9
>>> Version: 1:9.11.5.P4+dfsg-5.1
>>> 
>>> Woke up this morning to the following in syslog. Looks to maybe be a
>>> race condition when reloading zones that have changed and setting
>>> nsec3params immediately after/during the reload.
>>> 
>>> Sep  3 05:56:06 odroid-dns named[29241]: zone bluematt.me/IN (unsigned):
>>> loaded serial 2015412479
>>> Sep  3 05:56:06 odroid-dns named[29241]: received control channel
>>> command 'signing -nsec3param 1 0 100 D1D6B923 mattcorallo.com'
>>> Sep  3 05:56:06 odroid-dns named[29241]: ../../../lib/dns/rbtdb.c:1494:
>>> REQUIRE(rbtdb->future_version == ((void *)0)) failed, back trace
>>> Sep  3 05:56:06 odroid-dns named[29241]: #0 0xdda1f958 in ??
>>> Sep  3 05:56:06 odroid-dns named[29241]: #1 0xb3437944 in ??
>>> Sep  3 05:56:06 odroid-dns named[29241]: #2 0xb3a1368c in ??
>>> Sep  3 05:56:06 odroid-dns named[29241]: #3 0xb3ad4bd4 in ??
>>> Sep  3 05:56:06 odroid-dns named[29241]: #4 0xb345dca0 in ??
>>> Sep  3 05:56:06 odroid-dns named[29241]: #5 0xb335b7e4 in ??
>>> Sep  3 05:56:06 odroid-dns named[29241]: #6 0xb2ffbadc in ??
>>> Sep  3 05:56:06 odroid-dns named[29241]: exiting (due to assertion failure)
>>> 
>> 

Bug#939329: named crashes when setting nsec3param

[Ondřej Surý]

Nope, sorry, it’s here:

https://wiki.debian.org/AutomaticDebugPackages

…

e.g. adding:

deb http://deb.debian.org/debian-debug/ stable-debug main

should do the trick.

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 3 Sep 2019, at 15:37, Ondřej Surý  wrote:
> 
> I don’t know why it’s not available in the stable, but since we haven’t 
> updated the package in the unstable yet, it should be identical to:
> 
> https://packages.debian.org/unstable/bind9-dbgsym
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
> 
> 
>> On 3 Sep 2019, at 15:19, Matt Corallo  wrote:
>> 
>> I do have a core, but don't see what package to get debug symbols from?
>> 
>> Matt
>> 
>> On 9/3/19 12:27 PM, Ondřej Surý wrote:
>>> Hi,
>>> 
>>> could you please take a look if you have a core around and you could 
>>> install debug symbols to decode the coredump?
>>> 
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ond...@sury.org
>>> 
>>> 
>>> 
 On 3 Sep 2019, at 13:51, li...@bluematt.me wrote:
 
 Package: bind9
 Version: 1:9.11.5.P4+dfsg-5.1
 
 Woke up this morning to the following in syslog. Looks to maybe be a
 race condition when reloading zones that have changed and setting
 nsec3params immediately after/during the reload.
 
 Sep  3 05:56:06 odroid-dns named[29241]: zone bluematt.me/IN (unsigned):
 loaded serial 2015412479
 Sep  3 05:56:06 odroid-dns named[29241]: received control channel
 command 'signing -nsec3param 1 0 100 D1D6B923 mattcorallo.com'
 Sep  3 05:56:06 odroid-dns named[29241]: ../../../lib/dns/rbtdb.c:1494:
 REQUIRE(rbtdb->future_version == ((void *)0)) failed, back trace
 Sep  3 05:56:06 odroid-dns named[29241]: #0 0xdda1f958 in ??
 Sep  3 05:56:06 odroid-dns named[29241]: #1 0xb3437944 in ??
 Sep  3 05:56:06 odroid-dns named[29241]: #2 0xb3a1368c in ??
 Sep  3 05:56:06 odroid-dns named[29241]: #3 0xb3ad4bd4 in ??
 Sep  3 05:56:06 odroid-dns named[29241]: #4 0xb345dca0 in ??
 Sep  3 05:56:06 odroid-dns named[29241]: #5 0xb335b7e4 in ??
 Sep  3 05:56:06 odroid-dns named[29241]: #6 0xb2ffbadc in ??
 Sep  3 05:56:06 odroid-dns named[29241]: exiting (due to assertion failure)
 
>>> 
> 

Bug#939336: iptables: fails to delete rules when running 32-bit userspace on 64-bit kernel

[Fabio Pedretti]

I think this is fixed in iptables git:
https://git.netfilter.org/iptables/commit/?id=64e88114437072b29bed8aae9eb04ed5e773708f

BTW, iptables git has many fixes for Debian reported bugs (mostly since buster).

Il giorno mar 3 set 2019 alle ore 15:30 Colin Watson
 ha scritto:
>
> Package: iptables
> Version: 1.8.3-2
> Severity: normal
>
> When running an i386 container on an amd64 host system, "iptables -D"
> fails to match existing rules correctly:
>
>   # iptables -A OUTPUT -p tcp --dport 80 -j DROP
>   # iptables -D OUTPUT -p tcp --dport 80 -j DROP
>   iptables: Bad rule (does a matching rule exist in that chain?).
>
> Some gdb work revealed that this is because match_size is wrong: it's
> based on alignof(struct xt_align), and when adding a new rule the
> kernel's netfilter compat interfaces adjust match_size to account for
> the difference between userspace and kernel alignment, but this means
> that the size isn't what userspace expects when it tries to match
> existing rules.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
>
> Kernel: Linux 5.2.0-10-generic (SMP w/1 CPU core)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> 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 iptables depends on:
> ii  libc62.28-10
> ii  libip4tc21.8.3-2
> ii  libip6tc21.8.3-2
> ii  libiptc0 1.8.3-2
> ii  libmnl0  1.0.4-2+b1
> ii  libnetfilter-conntrack3  1.0.7-2
> ii  libnfnetlink01.0.1-3+b1
> ii  libnftnl11   1.1.4-1
> ii  libxtables12 1.8.3-2
>
> Versions of packages iptables recommends:
> ii  nftables  0.9.2-1
>
> Versions of packages iptables suggests:
> pn  kmod  
>
> -- no debconf information
>
> --
> Colin Watson   [cjwat...@debian.org]
>

Bug#939337: memcached: CVE-2019-15026

[Salvatore Bonaccorso]

Source: memcached
Version: 1.5.6-1.1
Severity: important
Tags: security upstream
Control: found -1 1.4.33-1+deb9u1
Control: found -1 1.4.33-1

Hi,

The following vulnerability was published for memcached.

CVE-2019-15026[0]:
| memcached 1.5.16, when UNIX sockets are used, has a stack-based buffer
| over-read in conn_to_str in memcached.c.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-15026
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15026

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#939336: iptables: fails to delete rules when running 32-bit userspace on 64-bit kernel

[Colin Watson]

On Tue, Sep 03, 2019 at 03:33:51PM +0200, Fabio Pedretti wrote:
> I think this is fixed in iptables git:
> https://git.netfilter.org/iptables/commit/?id=64e88114437072b29bed8aae9eb04ed5e773708f

That seems to relate to a different structure?

> BTW, iptables git has many fixes for Debian reported bugs (mostly since 
> buster).

I just tested iptables git (commit
a0f1a756419d0738c833d53b656350a520fc94c8) and reproduced the same
symptoms as in my original report.

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

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

Core dump trace follows:

[New LWP 29244]
[New LWP 29241]
[New LWP 29245]
[New LWP 29243]
[New LWP 29242]
[New LWP 29246]
[New LWP 29247]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/named -u bind'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
(gdb) thread apply all bt

Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
#0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
timeout=timeout@entry=-1, set=set@entry=0x0) at
../sysdeps/unix/sysv/linux/epoll_pwait.c:42
#1  0xb2ffbd40 in epoll_wait (epfd=,
events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
#2  0xb3471a9c in watcher (uap=0xb0db5010) at
../../../../lib/isc/unix/socket.c:4260
#3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
pthread_create.c:486
#4  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
expected=0, futex_word=0xb0db30a8)
at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  __pthread_cond_wait_common (abstime=,
mutex=, cond=) at pthread_cond_wait.c:539
#2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
at pthread_cond_wait.c:667
#3  0xb347bc54 in isc_condition_waituntil
(c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
t=t@entry=0xb0db3074)
at ../../../../lib/isc/pthreads/condition.c:59
#4  0xb3463f44 in run (uap=0xb0db3010) at
../../../lib/isc/timer.c:806
#5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
pthread_create.c:486
#6  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
#0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
#1  0xb0da6d30 in ?? ()
#2  0x94603695287e7065 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
#0  futex_wait_cancelable (private=0, expected=0,
futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
cond=0xb0db10a8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
#3  0xb345dae4 in dispatch (manager=0xb0db1010) at
../../../lib/isc/task.c:1089
#4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
#5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
pthread_create.c:486
#6  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
#0  futex_wait_cancelable (private=0, expected=0,
futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
cond=0xb0db10a8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
#3  0xb345dae4 in dispatch (manager=0xb0db1010) at
../../../lib/isc/task.c:1089
#4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
#5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
pthread_create.c:486
#6  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 2 (Thread 0xb0e12440 (LWP 29241)):
#0  0xb2f5ea9c in __GI___sigsuspend
(set=set@entry=0xd7e8b158) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
#1  0xb34671dc in isc__app_ctxrun
(ctx0=ctx0@entry=0xb34ad6f0 ) at
../../../../lib/isc/unix/app.c:725
#2  0xb346746c in isc__app_run () at
../../../../lib/isc/unix/app.c:758
#3  0xb3467e00 in isc_app_run () at
../../../../lib/isc/unix/../app_api.c:201
#4  0xdda0c0c4 in main (argc=, argv=) at ../../../bin/named/main.c:1480

Thread 1 (Thread 0xafda91a0 (LWP 29244)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xb2f4c8e8 in __GI_abort () at abort.c:79
#2  0xdda1fb58 in assertion_failed (file=,
line=, type=,
cond=0xb3b1e398 "rbtdb->future_version == ((void *)0)") at
../../../bin/named/main.c:234
#3  0xb3437944 in isc_assertion_failed
(file=file@entry=0xb3b1da10 "../../../lib/dns/rbtdb.c",
line=line@entry=1494,
type=type@entry=isc_assertiontype_require,
cond=cond@entry=0xff

Bug#939329: named crashes when setting nsec3param

[Ondřej Surý]

Thanks Matt, could you please save the core in case we (ISC) are going to need 
more information from it?

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 3 Sep 2019, at 16:05, Matt Corallo  wrote:
> 
> Core dump trace follows:
> 
> [New LWP 29244]
> [New LWP 29241]
> [New LWP 29245]
> [New LWP 29243]
> [New LWP 29242]
> [New LWP 29246]
> [New LWP 29247]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/sbin/named -u bind'.
> Program terminated with signal SIGABRT, Aborted.
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> [Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
> (gdb) thread apply all bt
> 
> Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
> #0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>timeout=timeout@entry=-1, set=set@entry=0x0) at
> ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
> #1  0xb2ffbd40 in epoll_wait (epfd=,
> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
> #2  0xb3471a9c in watcher (uap=0xb0db5010) at
> ../../../../lib/isc/unix/socket.c:4260
> #3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
> pthread_create.c:486
> #4  0xb2ffbadc in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
> #0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
> expected=0, futex_word=0xb0db30a8)
>at ../sysdeps/unix/sysv/linux/futex-internal.h:205
> #1  __pthread_cond_wait_common (abstime=,
> mutex=, cond=) at pthread_cond_wait.c:539
> #2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
> mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
>at pthread_cond_wait.c:667
> #3  0xb347bc54 in isc_condition_waituntil
> (c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
> t=t@entry=0xb0db3074)
>at ../../../../lib/isc/pthreads/condition.c:59
> #4  0xb3463f44 in run (uap=0xb0db3010) at
> ../../../lib/isc/timer.c:806
> #5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
> pthread_create.c:486
> #6  0xb2ffbadc in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
> #0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
> #1  0xb0da6d30 in ?? ()
> #2  0x94603695287e7065 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
> #0  futex_wait_cancelable (private=0, expected=0,
> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
> cond=0xb0db10a8) at pthread_cond_wait.c:502
> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
> ../../../lib/isc/task.c:1089
> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
> pthread_create.c:486
> #6  0xb2ffbadc in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
> #0  futex_wait_cancelable (private=0, expected=0,
> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
> cond=0xb0db10a8) at pthread_cond_wait.c:502
> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
> ../../../lib/isc/task.c:1089
> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
> pthread_create.c:486
> #6  0xb2ffbadc in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> Thread 2 (Thread 0xb0e12440 (LWP 29241)):
> #0  0xb2f5ea9c in __GI___sigsuspend
> (set=set@entry=0xd7e8b158) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
> #1  0xb34671dc in isc__app_ctxrun
> (ctx0=ctx0@entry=0xb34ad6f0 ) at
> ../../../../lib/isc/unix/app.c:725
> #2  0xb346746c in isc__app_run () at
> ../../../../lib/isc/unix/app.c:758
> #3  0xb3467e00 in isc_app_run () at
> ../../../../lib/isc/unix/../app_api.c:201
> #4  0xdda0c0c4 in main (argc=, argv= out>) at ../../../bin/named/main.c:1480
> 
> Thread 1 (Thread 0xafda91a0 (LWP 29244)):
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x0

Bug#936698: hfst: Python2 removal in sid/bullseye

[Tino Didriksen]

I've pushed an update that also fixes #936698 to
https://salsa.debian.org/science-team/hfst

-- Tino Didriksen

Bug#935900: RFS: z3 4.8.4-0.1 [NMU]

[Gianfranco Costamagna]

 control: owner -1 !control: tags -1 moreinfo
Hello Fabian, 

I tried many times to update it, would you mind pushing your work directly on 
the pkg-llvm repository?
In the meanwhile I'm having a look at your work
Gianfranco
Il martedì 27 agosto 2019, 19:39:28 CEST, Matthew Fernandez 
 ha scritto:  
 
 

On Aug 27, 2019, at 08:48, Fabian Wolff  wrote:
On 8/27/19 4:00 PM, Matthew Fernandez wrote:


z3 (4.8.4-0.1) unstable; urgency=medium


I am not a z3 dev, but the latest z3 release is 4.8.5. Is there a
particular motivation for uploading a 4.8.4-based release?


Thanks for pointing this out; I did not notice this, because I was
using uscan, and upstream suddenly changed the tag format on Github for
tagging new releases:

  https://github.com/Z3Prover/z3/tags


Ah, I was not aware of this either, so we both learned something :)

In the last hour or so, I have tried to import version 4.8.5, but they
apparently changed something in the build system so that building with
Mono no longer works (it fails with 'dotnet: Command not found', and I
don't know what the Mono equivalent of the dotnet command is, or if one
exists at all).


I’ve built 4.8.5 before, but not the .net bindings which I guess is what you’re 
dealing with. I can attempt this but unfortunately won’t have time in the short 
term.

So, I'd say having version 4.8.4 is still better than 4.4.1, and if
someone else wants to give 4.8.5 another try in the future, they can do
so after this upload.


Agreed. Having 4.8.4 available would be a significant improvement. Thanks!  

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Mark Hindley]

On Wed, Aug 14, 2019 at 07:22:47PM +0100, Jonathan Wiltshire wrote:
> I think your summary is fine. However, this is not my area of expertise and
> I'm rather hoping Julien or Ansgar will chime in with an update.
> 
> It certainly wouldn't be appropriate for me to remove a block put in place
> by someone else without extenuating circumstances.

Julien,

I am still waiting for some constructive engagement over this.

As Jonathan's comment above makes clear and is echoed by this exchange on
#debian-release yesterday:

 Hello. #934132 is still outstanding and is now preventing resolution
 of RC bug in bullseye #939101.  [12:13]
 Can we find a resolution to #934132? Thanks.  [12:17]
 weasel: zwiebelbot is missing here  [12:34]
 jcristau: ^ (#934132)  [13:12]
 jmw: well i still think shipping this thing is a bad idea.  but i'm
   ok with somebody else removing the block.  [13:21]
 I don't know enough about it to make a call on that
 but I think LeePen would appreciate some sort of response

it is obvious and completely understandable that other members of the Release
Team will not overrule your hint blocking elogind migration to bullseye. So,
resolution of this bug (and the resulting FTBFS in bullseye) is down to you.

I have tried to answer your concerns in detail. If you think my answers are
inadequate or still think there are issues that need to be addressed, please
specify them. If not, please remove your block of elogind's migration to
testing.

Thank you.

Mark

Bug#926731: ITS: urlscan/0.9.2 - extract and browse email URLs

[Boruch Baum]

On 2019-08-31 19:20, Marcin Kulisz wrote:
> Package: urlscan
> Version: 0.8.2-1
> Followup-For: Bug #926731
>
> Boruch are you still interested in maintaining this package?
> If not I my intent is to salvage/adopt it in the next couple of weeks, so 
> please
> let me know asap if you're planning to do it.

Answered here (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926731)
on 21 August.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

Yep, no problem. I moved it out of the way to keep it around, will try
to avoid upgrading bind and losing the original deb to run backtraces
against.


On 9/3/19 2:10 PM, Ondřej Surý wrote:
> Thanks Matt, could you please save the core in case we (ISC) are going to 
> need more information from it?
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
> 
> 
>> On 3 Sep 2019, at 16:05, Matt Corallo  wrote:
>>
>> Core dump trace follows:
>>
>> [New LWP 29244]
>> [New LWP 29241]
>> [New LWP 29245]
>> [New LWP 29243]
>> [New LWP 29242]
>> [New LWP 29246]
>> [New LWP 29247]
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/sbin/named -u bind'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>> 50   ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> [Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
>> (gdb) thread apply all bt
>>
>> Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
>> #0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>timeout=timeout@entry=-1, set=set@entry=0x0) at
>> ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
>> #1  0xb2ffbd40 in epoll_wait (epfd=,
>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
>> #2  0xb3471a9c in watcher (uap=0xb0db5010) at
>> ../../../../lib/isc/unix/socket.c:4260
>> #3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
>> pthread_create.c:486
>> #4  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
>> #0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
>> expected=0, futex_word=0xb0db30a8)
>>at ../sysdeps/unix/sysv/linux/futex-internal.h:205
>> #1  __pthread_cond_wait_common (abstime=,
>> mutex=, cond=) at pthread_cond_wait.c:539
>> #2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
>> mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
>>at pthread_cond_wait.c:667
>> #3  0xb347bc54 in isc_condition_waituntil
>> (c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
>> t=t@entry=0xb0db3074)
>>at ../../../../lib/isc/pthreads/condition.c:59
>> #4  0xb3463f44 in run (uap=0xb0db3010) at
>> ../../../lib/isc/timer.c:806
>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
>> pthread_create.c:486
>> #6  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
>> #0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
>> #1  0xb0da6d30 in ?? ()
>> #2  0x94603695287e7065 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>
>> Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
>> #0  futex_wait_cancelable (private=0, expected=0,
>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>> ../../../lib/isc/task.c:1089
>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
>> pthread_create.c:486
>> #6  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
>> #0  futex_wait_cancelable (private=0, expected=0,
>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>> ../../../lib/isc/task.c:1089
>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
>> pthread_create.c:486
>> #6  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 2 (Thread 0xb0e12440 (LWP 29241)):
>> #0  0xb2f5ea9c in __GI___sigsuspend
>> (set=set@entry=0xd7e8b158) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
>> #1  0xb34671dc in isc__app_ctxrun
>> (ctx0=ctx0@entry=0xb34ad6f0 ) at
>> ../../../../lib/isc/unix/app.c:725
>> #2  0xb346746c in isc__app_run () at
>> ../../../../lib/isc/unix/app.c:758
>> #3  0x

Bug#896891: (no subject)

[Thomas Ward]

Hello.

Can you verify that cross-building is still broken in the version 
available now in Unstable and Testing, as 1.4.1-1 has been superseded 
for some time now?  If it is still broken, please also update the patch, 
however keep in mind configure.ac has changed so it's possible the issue 
is now resolved.



Thomas

Bug#939338: /usr/include/gpsim/pic-processor.h references non-existent ../config.h

[Helmut Grohne]

Package: gpsim-dev
Version: 0.31.0-1
Severity: serious
Justification: simulide FTBFS
Tags: ftbfs
Control: affects -1 + src:simulide
File: /usr/include/gpsim/pic-processor.h

simulide fails to build from source. A build on amd64 ends with:

| g++ -c -pipe -g -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -O3 -std=gnu++11 -Wall -W -D_REENTRANT -fPIC 
-DMAINMODULE_EXPORT= -DAPP_VERSION=\"0.1.7\" -DQT_NO_DEBUG -DQT_SVG_LIB 
-DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GUI_LIB -DQT_XML_LIB 
-DQT_CONCURRENT_LIB -DQT_SERIALPORT_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. 
-I../src -I../src/gui -I../src/gui/circuitwidget 
-I../src/gui/circuitwidget/components -I../src/gui/circuitwidget/components/mcu 
-I../src/gui/oscopewidget -I../src/gui/plotterwidget 
-I../src/gui/terminalwidget -I../src/gui/QPropertyEditor 
-I../src/gui/componentselector -I../src/gui/filebrowser 
-I../src/gui/editorwidget -I../src/gui/editorwidget/findreplacedialog 
-I../src/gui/serialporwidget -I../src/simulator -I../src/simulator/elements 
-I../src/simulator/elements/processors -I../src/misc -I../src/simavr 
-I../src/simavr/sim -I../src/simavr/sim/avr -I../src/simavr/cores -isystem 
/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSvg -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSerialPort -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o itemlibrary.o 
../src/gui/circuitwidget/itemlibrary.cpp
| In file included from /usr/include/gpsim/pic-processor.h:30,
|  from ../src/simulator/elements/processors/picprocessor.h:26,
|  from 
../src/gui/circuitwidget/components/mcu/piccomponent.h:24,
|  from ../src/gui/circuitwidget/itemlibrary.cpp:62:
| /usr/include/gpsim/breakpoints.h:25:10: fatal error: ../config.h: No such 
file or directory
|25 | #include "../config.h"
|   |  ^
| compilation terminated.
| make[1]: *** [Makefile:3380: itemlibrary.o] Error 1
| make[1]: Leaving directory '/<>/build_XX'
| dh_auto_build: cd build_XX && make -j1 returned exit code 2
| make: *** [debian/rules:17: build] Error 255
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The file /usr/include/gpsim/pic-processor.h from the gpsim-dev package
references ../config.h, which does not exist. Including
 is bound to fail.

Helmut

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Michael Biebl]

Am 03.09.19 um 16:29 schrieb Mark Hindley:
> On Wed, Aug 14, 2019 at 07:22:47PM +0100, Jonathan Wiltshire wrote:
>> I think your summary is fine. However, this is not my area of expertise and
>> I'm rather hoping Julien or Ansgar will chime in with an update.
>>
>> It certainly wouldn't be appropriate for me to remove a block put in place
>> by someone else without extenuating circumstances.
> 
> Julien,
> 
> I am still waiting for some constructive engagement over this.
> 
> As Jonathan's comment above makes clear and is echoed by this exchange on
> #debian-release yesterday:
> 
>  Hello. #934132 is still outstanding and is now preventing resolution
>of RC bug in bullseye #939101.  [12:13]
>  Can we find a resolution to #934132? Thanks.  [12:17]
>  weasel: zwiebelbot is missing here  [12:34]
>  jcristau: ^ (#934132)  [13:12]
>  jmw: well i still think shipping this thing is a bad idea.  but i'm
>  ok with somebody else removing the block.  [13:21]
>  I don't know enough about it to make a call on that
>  but I think LeePen would appreciate some sort of response
> 
> it is obvious and completely understandable that other members of the Release
> Team will not overrule your hint blocking elogind migration to bullseye. So,
> resolution of this bug (and the resulting FTBFS in bullseye) is down to you.
> 
> I have tried to answer your concerns in detail. If you think my answers are
> inadequate or still think there are issues that need to be addressed, please
> specify them. If not, please remove your block of elogind's migration to
> testing.
> 
> Thank you.
> 
> Mark
> 

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

This bug report should be taken into account here. Not sure why this is
not marked as RC given that it can pretty much hose your system.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#928993: Uploading new release of sdaps onto Debian unstable

[Boyuan Yang]

Dear sdaps maintainers,

I will proceed to upload the new release of sdaps onto Debian unstable after
the previous upload onto experimental. If there's any issue, please feel free
to let me know.

Thanks,
Boyuan Yang


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

Bug#939048: transition: glibc

[Matthias Klose]

On 31.08.19 16:12, Aurelien Jarno wrote:

  - gcc-9
  - gcc-snapshot


I'll take care of these with regular uploads.

Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups

[Antoine Beaupré]

On 2019-09-03 14:12:08, Nicolas Schier wrote:
> Hei,
>
> I have started packaging git-revise [1], would like to take over the
> package maintainance and already got an warm ack from upstream for
> Debian packaging.

Thanks!

> Right now I am just targetting on providing a usable 'git-revise'
> package; for seperating the python library into a seperate package I
> would wait until a corresponding bug is filed.

Sounds good.

> Antoine, could you create a repository in salsa's 'debian' namespace?
> (My salsa account is 'nsc-guest').

Done: https://salsa.debian.org/debian/git-revise

> Would you be available as a sponsor (as soon as I have got rid of all
> lintian issues)?

Sure!

A.

-- 
Vivre tous simplement pour que tous puissent simplement vivre.
- Gandhi