Bug#942252: lintian: No vendor given at /<>/lib/Lintian/Maintainer.pm line 33

[Sebastian Ramacher]

On 2019-10-13 14:32:01, Felix Lechner wrote:
> Hi Sebastian,
> 
> On Sun, Oct 13, 2019 at 12:15 PM Chris Lamb  wrote:
> >
> > Thanks. Unfortunately, I don't quite know why this is happening. (The
> > tests on Salsa appear to pass right now.)
> 
> Some test scripts appear to load old profiles. They are presumably
> located in the installed location /usr/share/lintian. The errors
> depend on the version difference between what is installed and what is
> under test. That is probably why the reported bug does not show up in
> Gitlab (anymore).
> 
> Could you please cherry-pick this commit?
> https://salsa.debian.org/lintian/lintian/commit/33508343d8fde77a3d5db22863ff358dbf7a915f
> 
> This commit does two things: (1) It unambiguously uses only one
> include path when finding profiles, and (2) makes sure a profile is
> loaded in the test pod-synopsis.t that fails in your bug report.
> 
> I cannot test the proposed fix locally (the error does not appear
> here). Which version Lintian do you have installed?

Please check the build log. I don't have any other info. I was only
reporting the build failure from the buildds.

Cheers

> 
> Kind regards,
> Felix Lechner

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#927155: synaptic: Idiotic dependencies after the upgrade to 0.84.6

[jim_p]

Package: synaptic
Followup-For: Bug #927155

Now that synaptic was updated to 0.84.7 and it no longer pulls zenity as a
dependency, its dependencies have dropped to the minimal ones, so this issue
can be closed.

I will open a new one on zenity, because its dependencies remain stupid.



-- 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-3-amd64 (SMP w/2 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: systemd (via /run/systemd/system)

Versions of packages synaptic depends on:
ii  hicolor-icon-theme  0.17-2
ii  libapt-inst2.0  1.8.4
ii  libapt-pkg5.0   1.8.4
ii  libc6   2.29-2
ii  libept1.5.0 1.1+nmu3+b1
ii  libgcc1 1:9.2.1-8
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-1
ii  libglib2.0-02.62.1-1
ii  libgtk-3-0  3.24.12-1
ii  libpango-1.0-0  1.42.4-7
ii  libstdc++6  9.2.1-8
ii  libvte-2.91-0   0.58.0-1
ii  libxapian30 1.4.12-1
ii  policykit-1 0.105-26

Versions of packages synaptic recommends:
pn  libgtk2-perl  
ii  xdg-utils 1.1.3-1

Versions of packages synaptic suggests:
pn  apt-xapian-index 
ii  deborphan1.7.31
pn  dwww 
pn  menu 
pn  software-properties-gtk  
ii  tasksel  3.55

-- no debconf information

Bug#935931: Re: Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

[Nicholas D Steeves]

Hi Daniel and everyone reading this,

Daniel  writes:

> I am addressing another case, the one you have not separated partitions 
> for /, /home and swap.
>

Len and Daniel, WRT swap, hibernation is useful when you need to
preserve the state of applications that aren't aware of a desktop
session manager, eg: half-finished work in a terminal.  As I see it the
primary advantage to a swap file is the ability to expand it after a RAM
upgrade. eg: that a reboot using a livecd to resize partitions is not
required.  Granted, expanding a swap file is only necessary if one cares
about hibernation...

> As a matter of fact if the installer is able to recognize the home 
> folder having  /home separated in another partition is not necessary 
> anymore. The advantage respect having the /home separated, specifically 
> for a desktop use are noteworthy.
>

The key point is "is able to recognize [safely and reliably]", and that
requires someone who values the feature to work on debian-installer
(not fun), and also maintain it (not fun).

> If the installer, instead of creating /, /home and swap, creates just / 
> and a swap file and if is able to reinstall itself without overwriting 
> the home folder I think is a huge improvement. As a matter of fact if 
> you reinstall Debian, even with /home in another partition, there is not 
> any assisted aid that explain you how to properly setup the /home 
> partition. Having the system partitioned is already a setup for advanced 
> user.
>

As Len mentioned, Debian users tend to believe that it's a better use of
time to learn how to fix things if one is going to track
testing/sid/experimental than hitting the panic button and losing state.
My mother (who lives 3500km away, runs Debian stable, and installed it
herself eight years ago) doesn't need this feature.  She's not an
intermediate or advanced user and is currently running buster.  She also
has root on her laptop, so has the power to render it unusable.

Daniel, would you please take a look at Bug #941627 (ITP: grub-btrfs --
provides grub entries for btrfs snapshots (boot environments/restore
points)?  I think that this is a feature that would solve the situation
where one ran a testing/sid/experimental upgrade at a time when one
didn't have time to do the work required to fix the brokenness.

Here's how it will work:

1. Install to btrfs (after my MR is merged this will automatically
create @rootfs subvolume, eg: special directory kind of like a pseudo
logical volume).  Reboot.
2. Run a one-line command and add one line to fstab to create a @home
subvolume--this is necessary to exclude /home from the snapshots.  I can
write a beginner friendly helper script if necessary.
3. Take a snapshot before running a dangerous upgrade (easy one-line
command).  Eventually this may be automatic (eg: something like
apt-btrfs-snapshot)
4. If the upgrade produces a broken state the user doesn't have time to
fix, simply boot into a known-good copy of / using the grub menu to
select the correct entry.  If the top-most one isn't good, reboot and
try with the second top-most one until a good one is found.  After
confirming all is well, rename the @rootfs subvolume and create a new
read-write snapshot named @rootfs based on the current boot environment.
This step is only necessary if you want to reboot into the old copy of
the rootfs automatically.  You also get to keep the
@rootfs-does-not-work copy.
5. The logical progression of this feature is to create a snapshot,
dist-upgrade the snapshot, test it (without rebooting), and if
everything looks good then mark it as the default boot environment.

Eventually there will be a GUI!

While wiping and reinstalling may be the best other OSs can aspire to,
Debian can, and will, do better.  I hope you'll agree the project I'm
working on will solve the root issue you're reporting, and that you'll
agree it's a more elegant and time-efficient solution :-)

In the meantime, to remove everything but /home and reinstall without
reformatting you can reboot into a Debian rescue system or using the
Debian Live image, mount your volume, use the solution I provided in my
initial reply (p.s. I consider that a risky approach), then follow:

  https://www.debian.org/releases/buster/amd64/apds03.en.html
  https://wiki.debian.org/Debootstrap


Sorry for the belated reply, I've been swamped with work.
Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#942294: scide can not display example codes in Help browser

[Takeshi Soejima]

Symlink ~/.local/share/SuperCollider/Help/prettify.js is also broken.

Bug#941658: Build openafs on other ppc64el

[Benjamin Kaduk]

On Thu, Oct 03, 2019 at 03:03:55PM +0200, Frédéric Bonnard wrote:
> Package: src:openafs
> Version: 1.8.4~pre1-1
> 
> --
> 
> Dear maintainer,
> is there any reason that openafs isn't built on ppc64el(maybe linux-any) ?
> I tested on ppc64el and with minor modifications (arch verifications in
> debian/sysname and debian/module/sysname), it built well.

I think the only reason is that I forgot to add it to debian/control after
upstream merged the necessary bits :(

Thanks for the reminder; I should be able to include that in the next
upload.

-Ben

Bug#942268: spamassassin: FROM_EXCESS_BASE64 always gives false positive

[Noah Meyerhans]

Control: tags -1 + upstream fixed-upstream
Control: forwarded -1 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7730

> file /usr/share/spamassassin/20_head_tests.cf contains:
> 
> --
> header __FROM_NEEDS_MIMEFrom:name:raw =~ 
> /[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\xff]/
> header __FROM_ENCODED_QPFrom:raw =~ /=\?\S+\?Q\?/i
> header __FROM_ENCODED_B64   From:raw =~ /=\?\S+\?B\?/i
> 
> 
> meta FROM_EXCESS_BASE64 __FROM_ENCODED_B64 && !__FROM_NEEDS_MIME
> describe FROM_EXCESS_BASE64 From: base64 encoded unnecessarily
> --
> 
> It results in false positive for every properly encoded From header.
> All the incoming mails in my box are marked with FROM_EXCESS_BASE64.

It looks like this has been fixed upstream already. Please see
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7730

While you wait for updated packages to be available, you may wish to
enable spamassassin's periodic rules update feature.  This will retrieve
updated rules published by the upstream project. I documented this
process for Debian in /usr/share/doc/spamassassin/README.Debian.gz and
at https://noah.meyerhans.us/blog/2015/01/15/spamassassin-updates/

If you don't wish to run the update process regularly, you can run it
once with the following, as root:

start-stop-daemon --chuid debian-spamd:debian-spamd --start \
--exec /usr/bin/sa-update -- \
--gpghomedir /var/lib/spamassassin/sa-update-keys

noah

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

Control: owner -1 !

Hi,

On Sun, Oct 30, 2016 at 02:21:39PM +0100, Philipp Kern wrote:
> On 10/11/2016 11:40 PM, Nicholas D Steeves wrote:
> > So far, the plan is to default to simple @rootfs and @home subvolumes,
> > because I've read that backing up OpenSUSE systems is cumbersome with
> > all of those subvolumes, and also because of the KISS principle; [...]
> 
> FWIW, given that I just encountered this myself: rescue(-mode) will need
> a fix in this case because by default it mounts the top-level, which
> means that the actual chroot is one level down. Although I guess setting
> the default subvolume id to the one of whatever you call @rootfs should
> also fix this.
> 

I've submitted a tested MR at:
  https://salsa.debian.org/installer-team/partman-btrfs/merge_requests/1

I decided to leave configuring @home up to the user, because the user
may wish to mount /home using another block device, possibly on a
non-btrfs volume.

Also, adding full-fledged btrfs subvolume configuration (eg: forking
partman-lvm) to DI will require a comaintainer.  The bus-factor is too
high for me to do it alone.

Would you like to take care of rescue-mode or shall I?


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#942294: scide can not display example codes in Help browser

[Takeshi Soejima]

Package: supercollider
Version: 1:3.10.0+repack-1

Dear Maintainer,

On startup scide shows errors and can not display example codes in Help
browser.

$ scide &
*** ERROR in JavaScript: "Uncaught ReferenceError: $ is not defined"
* line: 215
* source ID: "file:///home/sohet/.local/share/SuperCollider/Help/scdoc.js"
*** ERROR in JavaScript: "Uncaught ReferenceError: CodeMirror is not defined"
* line: 3
* source ID: "file:///home/sohet/.local/share/SuperCollider/Help/editor.js"
*** ERROR in JavaScript: "Uncaught ReferenceError: $ is not defined"
* line: 157
* source ID: "file:///home/sohet/.local/share/SuperCollider/Help/scdoc.js"


Symlinks in ~/.local/share/SuperCollider/Help/lib are broken.

$ ls -l ~/.local/share/SuperCollider/Help/lib
total 0
lrwxrwxrwx 1 sohet sohet 46 Oct 14 09:53 codemirror-5.39.2.min.js -> 
../../../javascript/codemirror/codemirror.js
lrwxrwxrwx 1 sohet sohet 54 Oct 14 09:54 codemirror-addon-simple-5.39.2.min.js 
-> ../../../javascript/codemirror/addon/mode/simple.js
lrwxrwxrwx 1 sohet sohet 42 Oct 14 09:54 jquery.min.js -> 
../../../javascript/jquery/jquery.min.js


When I install libjs-jquery and libjs-codemirror, and link to them, then
scide displays example codes well in Help browser.

$ ls -l ~/.local/share/SuperCollider/Help/lib
total 0
lrwxrwxrwx 1 sohet sohet 46 Oct 14 09:53 codemirror-5.39.2.min.js -> 
/usr/share/javascript/codemirror/codemirror.js
lrwxrwxrwx 1 sohet sohet 54 Oct 14 09:54 codemirror-addon-simple-5.39.2.min.js 
-> /usr/share/javascript/codemirror/addon/mode/simple.js
lrwxrwxrwx 1 sohet sohet 42 Oct 14 09:54 jquery.min.js -> 
/usr/share/javascript/jquery/jquery.min.js


The bug has also been reported elsewhere.

  
  

Bug#942260: pulseaudio: The pulseaudio use id for normal user.

[Felipe Sateler]

Control: tags -1 moreinfo unreproducible

On Sun, Oct 13, 2019 at 7:21 AM Corcodel Marian 
wrote:

> Package: pulseaudio
> Version: 10.0-1+deb9u1
> Severity: normal
>
> Inspect /etc/passwd and see on user pulse uid and guid number upper 1000 ,
> this
> is bad wich in not normal user, i replaced with 999 on both places ,
> solved on
> kdm manager to hide user pulse on login.
>

Mine has id 114. The postinst script does use the --system flag. Did you
create that user yourself? I can't reproduce the problem.

-- 

Saludos,
Felipe Sateler

Bug#942293: needrestart: Nagios plugin mode fails when running sysvinit-core on Debian 10

[wirelessduck]

Package: needrestart
Version: 3.4-5
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Upgrading from Debian 9 to Debian 10

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

Running `needrestart -p`

   * What was the outcome of this action?

Running `needrestart -p` on Debian 10 with sysvinit gives UNKN output

[main] eval /etc/needrestart/needrestart.conf
[main] needrestart v3.4
[main] running in root mode
[main] #388 uses deleted /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
[main] #388 is not a child
[main] #489 uses deleted /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
[main] #489 is not a child
[Core] #5394 is a NeedRestart::Interp::Python
[Python] #5394: source=/usr/bin/reportbug
[main] #388 exe => /usr/lib/systemd/systemd-udevd
[main] #388 running /etc/needrestart/hook.d/10-dpkg
dpkg-query: no path found matching pattern /usr/lib/systemd/systemd-udevd
[main] #388 running /etc/needrestart/hook.d/20-rpm
[main] #388 running /etc/needrestart/hook.d/90-none
[main] #489 exe => /usr/sbin/dhclient
[main] #489 running /etc/needrestart/hook.d/10-dpkg
dpkg-query: no path found matching pattern /usr/sbin/dhclient
[main] #489 running /etc/needrestart/hook.d/20-rpm
[main] #489 running /etc/needrestart/hook.d/90-none
Failed to load NeedRestart::uCode::Intel: [uCode/Intel] iucode-tool not 
available!
[ucode] no supported processor microcode detection
[Kernel] Linux: kernel release 4.19.0-6-amd64, kernel version #1 SMP Debian 
4.19.67-2+deb10u1 (2019-09-20)
Failed to load NeedRestart::Kernel::kFreeBSD: [Kernel/kFreeBSD] Not running on 
GNU/kFreeBSD!
[Kernel/Linux] /boot/vmlinuz-4.19.0-6-amd64 => 4.19.0-6-amd64 
(debian-ker...@lists.debian.org) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) 
[4.19.0-6-amd64]*
[Kernel/Linux] Expected linux version: 4.19.0-6-amd64
UNKN - Kernel: 4.19.0-6-amd64, Microcode: unknown, Services: none, Containers: 
none, Sessions: none|Kernel=0;0;;0;2 Microcode=U;0;;0;1 Services=0;;0;0 
Containers=0;;0;0 Sessions=0;0;;0
root@debian:~# echo $?
3

   * What outcome did you expect instead?

Running `needrestart -p` on Debian 9 with sysvinit gives expected OK output

root@debian:~# needrestart -p -v
[main] eval /etc/needrestart/needrestart.conf
[main] needrestart v2.11
[main] running in root mode
[Kernel] Linux: kernel release 4.9.0-11-amd64, kernel version #1 SMP Debian 
4.9.189-3+deb9u1 (2019-09-20)
Failed to load NeedRestart::Kernel::kFreeBSD: [Kernel/kFreeBSD] Not running on 
GNU/kFreeBSD!
[Kernel/Linux] /boot/vmlinuz-4.9.0-11-amd64 => 4.9.0-11-amd64 
(debian-ker...@lists.debian.org) #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20) 
[4.9.0-11-amd64]*
[Kernel/Linux] Expected linux version: 4.9.0-11-amd64
OK - Kernel: 4.9.0-11-amd64, Services: none, Containers: none, Sessions: 
none|Kernel=0;0;;0;2 Services=0;;0;0 Containers=0;;0;0 Sessions=0;0;;0
root@debian:~# echo $?
0

Running `needrestart -p` on Debian 10 with sysvinit should also give OK output


-- Package-specific info:
needrestart output:

checkrestart output:


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages needrestart depends on:
ii  binutils   2.31.1-16
ii  dpkg   1.19.7
ii  gettext-base   0.19.8.1-9
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.27-1
ii  libproc-processtable-perl  0.56-1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.38-1
ii  perl   5.28.1-6
ii  xz-utils   5.2.4-1

Versions of packages needrestart recommends:
ii  sysvinit-core  2.93-8

Versions of packages needrestart suggests:
pn  iucode-tool  
pn  needrestart-session | libnotify-bin  

-- no debconf information

Bug#942289: avrdude: Commit 7e245a25 breaks ft245r bitbang devices using DEFAULT_USB interface

[Stanley Pinchak]

Package: avrdude
Version: 6.3-20171130+svn1429-2+b1
Followup-For: Bug #942289

The patch provided in the previous message makes some changes to how ft245r
devices parse the port command line parameter.

1) for a default port (no -P provided) or "-P usb" it will select the first
   ftdi devnum (0).  This reverts to the operation prior to upstream patch
   8580.

2) for a -P usb: it will check if a valid serial number is provided and
   select the correct ftdi devnum.  In this regard it is identical to the
   functionality of upstream patch 8580.

3) for a -P usb:ftX it will fail.  In this regard it is a reversion of the
   functionality of upstream patch 8580.  I think the logic could be altered to
   allow this type of port selection. I would not be averse to this change and
   it would accommodate users who have changed to post 8580 port selection
   semantics.  I believe that the helpful message at line 590 of 7e245a25
   should be more clear about how to pass "-P usb:ftX" if this variant is kept. 

4) for a -P ftX it will select the ftdi devnum provided by X. In this regard it
   is a reversion to the previous operation prior to upstream patch 8580.

I don't know if upstream want to allow the "-P ftX" anymore, or if they want to
transition to the "-P usb:ftX" manner of port selection for usb attached
devices.

The patch does not address the possibility of parsing the usbsn or usbdev
parameters from .avrdudrc file.  These parameters are available in the pgm
structure, but I think an even better way to avoid having to create a custom
programmer type would be to parse the default_serial or default_parallel
parameters from .avrduderc.  I am not familiar enough with avrdude to provide a
patch which would look at these parameters and try to use them in the "port"
parameter of the ft245r_open function. 

Bug#942292: exim4.template.conf for clean buster install av_scanner incorrect

[Serge Rijkers]

Package: exim4
Version: 4.92-8+deb10u3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

A clean install of buster as an smtp mail server

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
exim4.template.conf contains:

av_scanner = clamd: /var/run/clamav/clamd.ctl

clean buster clamav-daemon uses /run/clamav/clamd.ctl

For a on tech-savvy user this is difficult to diagnose
possibly exim4.template.conf should contain:

av_scanner = clamd:/run/clamav/clamd.ctl

instead.

   * What was the outcome of this action?

Changing this to the above made clamd scanning from exim4 operational is
was not before.

   * What outcome did you expect instead?


-- Package-specific info:
Exim version 4.92 #3 built 27-Sep-2019 16:09:35
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event OCSP PRDR PROXY 
SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='tregare.net'
dc_local_interfaces='192.168.0.110 ; 127.0.0.1 ; ::1'
dc_readhost='tregare.net'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets='192.168.0.0/24'
dc_smarthost='smtp.ziggo.nl'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
mailname:tregare.net
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on
# port 25 only. To listen on more ports, it is recommended to use
# -oX 25:587:10025 -oP /run/exim4/exim.pid
SMTPLISTENEROPTIONS='-oX 25:465:587 -oP /run/exim4/exim.pid'

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_ALL 
to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_ALL to default locale: 
No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  exim4-base 4.92-8+deb10u3
ii  exim4-daemon-heavy 4.92-8+deb10u3

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_MONETARY = 

Bug#942291: afl++: add transitional packages for afl/afl-doc?

[Paul Wise]

Package: afl++
Severity: wishlist
Usertags: transition

I think it would be useful to add transitional packages for afl/afl-doc 
so that folks upgrading from previous releases get upgraded to afl++

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#942290: libbpfcc: libbcc_bpf.so: needs to link with -lelf

[Paul Wise]

Package: libbpfcc
Version: 0.11.0-1
Severity: minor
File: /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0
User: debian...@lists.debian.org
Usertags: undefined-symbol adequate

libbcc_bpf.so needs to link with -lelf, see the output of
adequate, symtree and objdump below.

I detected this on amd64 but dpkg-buildpackage complains about it on
the other architectures, see the getbuildlog output below.

I filed this bug at severity minor since I'm not sure if there are any
programs using the libbcc_bpf.so lib and if they already use the
libelf-0.176.so symbols and link with the -lelf flag or not.

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ lib=/usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0
$ link=/usr/lib/x86_64-linux-gnu/libelf-0.176.so
$ pkg="$(dpkg-query --search "$lib" | sed s/:.*//)"
$ src="$(grep-aptavail --no-field-names --show-field Source:Package --field 
Package --exact-match --pattern "$pkg" | sed 's/ .*//')"
$ first="$(printf '%s' "$src" | head --bytes 1)"

$ adequate "$pkg"
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
gelf_getshdr
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_rawdata
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_getscn
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_begin
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
gelf_getrel
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_memory
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_end
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_strptr
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_nextscn
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
gelf_getehdr
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_version
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
elf_getdata
libbpfcc: undefined-symbol /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 => 
gelf_getsym

$ man adequate | grep -A4 undefined-symbol
   undefined-symbol
   The symbol has not been found in the libraries linked with the 
binary.
   Either the binary either needs to be linked with an additional 
shared library,
   or the dependency on the shared library package that provides this 
symbol is too weak.

   References: Debian Policy §3.5, §8.6, §10.2.

$ lddtree "$lib"
libbcc_bpf.so.0.11.0 => /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0 
(interpreter => none)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

$ symtree "$lib"
/usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.11.0
libc.so.6 => 
socket,__xpg_basename,fopen,strncmp,perror,__isoc99_sscanf,epoll_wait,strncpy,time,__stack_chk_fail,unlink,mkdir,realloc,getpid,strdup,strtol,mmap,fgets,calloc,strlen,send,memset,dirname,strstr,rmdir,__errno_location,bind,read,getpagesize,getsockopt,dup3,poll,__fprintf_chk,recv,__isoc99_fscanf,memcpy,memcpy,fclose,setsockopt,malloc,stderr,ioctl,munmap,__snprintf_chk,__memset_chk,setrlimit,if_nametoindex,__fxstat,__getdelim,if_indextoname,fwrite,fread,epoll_ctl,statfs,__memcpy_chk,close,open,strchr,getsockname,epoll_create1,__vfprintf_chk,qsort,accept,__strcpy_chk,__cxa_finalize,syscall,__xpg_strerror_r,__xstat,getrlimit,memmove,uname,access,strcmp,strerror,write,snprintf,reallocarray,free
WEAK => _ITM_deregisterTMCloneTable,__gmon_start__,_ITM_registerTMCloneTable
UNRESOLVED => 
gelf_getshdr,elf_rawdata,elf_getscn,elf_begin,gelf_getrel,elf_memory,elf_end,elf_strptr,elf_nextscn,gelf_getehdr,elf_version,elf_getdata,gelf_getsym

$ objdump -T "$link" | grep -E "($(symtree "$lib" | sed -n 's/UNRESOLVED => 
//p' | tr , '|'))$"
3420 gDF .text  0045  ELFUTILS_1.0 elf_version
ad50 gDF .text  006e  ELFUTILS_1.0 elf_rawdata
a840 gDF .text  00e4  ELFUTILS_1.0 gelf_getshdr
99b0 gDF .text  0098  ELFUTILS_1.0 elf_nextscn
7510 gDF .text  0013  ELFUTILS_1.0 gelf_getehdr
b680 gDF .text  0013  ELFUTILS_1.0 elf_getdata
5070 gDF .text  01f0  ELFUTILS_1.0 elf_begin
00010a90 gDF .text  017c  ELFUTILS_1.0 gelf_getrel
00010600 gDF .text  00e3  ELFUTILS_1.0 gelf_getsym
be90 gDF .text  0035  ELFUTILS_1.0 elf_memory
aa70 gDF .text  02d3  ELFUTILS_1.0 elf_strptr
9880 gDF .text  0121  ELFUTILS_1.0 elf_getscn
5360 gDF .text  02ec  ELFUTILS_1.0 elf_end

$ chronic getbuildlog "$src" last

$ 

Bug#942289: avrdude: Commit 7e245a25 breaks ft245r bitbang devices using DEFAULT_USB interface

[Stanley Pinchak]

Package: avrdude
Version: 6.3-20171130+svn1429-2+b1
Severity: important
Tags: patch upstream

Dear Maintainer,

I recently upgraded avrdude from debian version 6.3-5.  After upgrading I was
unable to use my default programmer, arduino-ft232r without setting a -P port
parameter on the command line.  Upstream patch 8580 modified ft245r.c to allow
selection of a particular ftdi device based on the serial number of the device.
Unfortunately this patch has broken the ability for avrdude to automatically
select the first ftdi port for ft245r devices, which include arduino-ft232r.

Furthermore, there is no way to specify the serial number in the .avrduderc
file which has effect with these ft245r devices.  All attempts to set
"default_serial" or "default_parallel" with the correct "usb:SERIAL_NUM" which
work with the -P parameter failed to get past the conditional at line 554 of
ft245r.c.  Attempts to create a custom programmer with a parent of
arduino-ft232r or ft245r which attempted different combinations of setting
"usbdev" and "usbsn" to the appropriate serial number failed to satisfy the
aforementioned conditional.

I consider the upstream patch 8580 as ill formed in that it breaks existing
configurations without providing a way to specify a device serial number in
.avrduderc via either the default_serial or through a custom programmer with
usbdev or usbsn specified.  I am not sure how to incorporate the previous
behavior which selected the first ftdi device and "just worked" in version
6.3-5 with the added functionality for allowing users with multiple ftdi
devices to select a particular one via serial number.

The upstream patch 8580 is also logically incorrect in that the "else if"
conditional on line 573 is unreachable.  Any port which does not satisfy the
sscanf conditional at line 554 will immediately shortcut to the error return at
line 558.  A correct patch must strncmp "port" with DEFAULT_USB for
strlen(DEFAULT_USB) and then check if "port" is longer than strlen(DEFAULT_USB) 
 and then it can perform the sscanf conditional at line 554.

The upstream patch is also broken for the parsing of ftX style ports in the
conditional at 573.  Comparing "device" with "ft" is not correct.  The correct
comparison is between "port" and "ft".

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, arm64

Kernel: Linux 4.12.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages avrdude depends on:
ii  libc6  2.28-8
ii  libelf10.176-1
ii  libftdi1   0.20-4+b1
ii  libhidapi-libusb0  0.9.0+dfsg-1
ii  libncurses66.1+20181013-2
ii  libreadline8   8.0-3
ii  libtinfo6  6.1+20181013-2
ii  libusb-0.1-4   2:0.1.12-32

avrdude recommends no packages.

Versions of packages avrdude suggests:
pn  avrdude-doc 
pn  dfu-programmer  

-- no debconf information
--- ft245r.c.old2019-01-01 15:31:09.0 -0500
+++ ft245r.c2019-10-13 20:07:20.097474440 -0400
@@ -550,13 +550,18 @@
 
 strcpy(pgm->port, port);
 
+if ((strcmp(port, DEFAULT_USB) == 0)) {
+  devnum = 0;
+  avrdude_message(MSG_INFO,
+  "%s: ft245r_open(): default device identifier '%s'\n",
+  progname, port);
 // read device string cut after 8 chars (max. length of serial number)
-if ((sscanf(port, "usb:%8s", device) != 1)) {
+} else if ((strncmp(port, DEFAULT_USB, strlen(DEFAULT_USB)) == 0) &&
+(strcmp(port, DEFAULT_USB) > 0) &&
+(sscanf(port, "usb:%8s", device) != 1)) {
   avrdude_message(MSG_INFO,
   "%s: ft245r_open(): invalid device identifier '%8s'\n",
-  progname, device);
-  return -1;
-} else {
+  progname, device); return -1; } else {
   if (strlen(device) == 8 ){ // serial number
 if (verbose >= 2) {
   avrdude_message(MSG_INFO,
@@ -570,8 +575,8 @@
 // and use first device with matching serial (should be unique)
 devnum = 0;
   }
-  else if (strncmp("ft", device, 2) || strlen(device) <= 8)  { // classic 
device number
-char *startptr = device + 2;
+  else if ((strncmp("ft", port, 2) == 0))  { // classic device number
+char *startptr = port + 2;
 char *endptr = NULL;
 devnum = strtol(startptr,,10);
 if ((startptr==endptr) || (*endptr != '\0')) {
@@ -584,10 +589,9 @@
 devnum);
   }
 }
-
 // if something went wrong before abort with helpful message
 if (devnum < 0) {
-  avrdude_message(MSG_INFO, "%s: ft245r_open(): invalid portname '%s': 
use^ 'ft[0-9]+' or serial number\n",
+  avrdude_message(MSG_INFO, "%s: ft245r_open(): invalid portname '%s': 
use^ default 'usb', 

Bug#942150: Calibre 4.1 has been released

[Norbert Preining]

block 942150 941093
thanks

On Fri, 11 Oct 2019, John Zaitseff wrote:
> I see that Calibre 4.1 has been released 
> (https://calibre-ebook.com/whats-new).

Now we have python(2)-pyqt5.qtwebengine back in Debian (thanks to the
maintainers!), calibre 4 is (hopefully) only blocked by the outdated
libQt (Debian still contains the preumbrial 5.11 ;-). But light is at
the end of the tunnel, there is a transition registered to 5.12,
https://release.debian.org/transitions/html/qtbase-abi-5-12-5.html
so we might see Calibre 4 in Debian at some point ...

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#942288: Wish for tar2squashfs

[Trent W. Buck]

Package: squashfs-tools
Version: 1:4.4-1
Severity: wishlist

Is it possible to write something that reads a tarball from stdin, and
writes a squashfs to stdout?

The context is https://bugs.debian.org/942098
where tar is used in a pipeline, so replacing it with mksquashfs is
fiddly.  One suggestion is a hypothetical "tar2squashfs" program.
Is such a program even possible?
If so, how hard is it to implement?


[I initially tried to send this to
nntp://news.gmane.org/gmane.comp.file-systems.squashfs.devel, but that
particular mailing list is read-only in gmane.
So I'm dumping it here because otherwise I'll forget about it entirely.
Sorry!]


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages squashfs-tools depends on:
ii  libc6  2.28-10
ii  liblz4-1   1.8.3-1
ii  liblzma5   5.2.4-1
ii  liblzo2-2  2.10-0.1
ii  libzstd1   1.3.8+dfsg-3
ii  zlib1g 1:1.2.11.dfsg-1

squashfs-tools recommends no packages.

squashfs-tools suggests no packages.

-- no debconf information

Bug#942227: fish: "unreachable" state reached when redirecting to/from an unopenable file with `exec'

[Asher Gordon]

Hi David,

David Adam  writes:

> I am pleased to report that this problem is fixed in the upcoming 3.1.0
> release:
>
> https://github.com/fish-shell/fish-shell/pull/5643

Great! I can confirm that the bug is no longer present in the latest
upstream git (currently commit g82eca4bc).

Thanks,
Asher

-- 
The marvels of today's modern technology include the development of a
soda can, when discarded will last forever ... and a $7,000 car which
when properly cared for will rust out in two or three years.


signature.asc
Description: PGP signature

Bug#942287: python3-exif: package name should be python3-exifread

[Sandro Tosi]

Package: python3-exif
Version: 2.2.0-3
Severity: serious

Hello,
since this package installs a module called `exifread` the binary package name
should be python3-exifread not python3-exif.

Since it violates the policy, severity is set to serious.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-exif depends on:
ii  python3  3.7.3-1

python3-exif recommends no packages.

python3-exif suggests no packages.

-- no debconf information

Bug#942284: [Pkg-net-snmp-devel] Bug#942284: libsnmp-perl: perl module SNMP broken

[Craig Small]

On Mon, 14 Oct 2019 at 09:30, gregor herrmann  wrote:

> libsnmp-perl is broken.
>
Ouch, I don't use the module (or Perl much for that matter) but that's very
broken. No idea what's going on but it worries me that
netsnmp_ds_get_boolean is the first function in that module which means a
coincidence or all functions are not available.

 - Craig

Bug#942286: fontypython: Crash at start with UnicodeDecodeError

[Pierre Thierry]

Package: fontypython
Version: 0.5-1
Severity: normal

After using it several times without issue, now fontypython crashes at start
time with the following output in the terminal:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_misc.py", line 1367,
in Notify
self.notify()
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py", line 16868,
in Notify
self.result = self.callable(*self.args, **self.kwargs)
  File "/usr/lib/python2.7/dist-packages/fontypythonmodules/wxgui.py", line
910, in showMain
frame = MainFrame(None, _("Fonty Python: bring out your fonts!"))
  File "/usr/lib/python2.7/dist-packages/fontypythonmodules/wxgui.py", line
337, in __init__
self.choose_zipdir_panel = ChooseZipDirPanel( self, wfunc )
  File "/usr/lib/python2.7/dist-
packages/fontypythonmodules/gui_dismissable_panels.py", line 599, in __init__
wfunc = wfunc)
  File "/usr/lib/python2.7/dist-
packages/fontypythonmodules/gui_dismissable_panels.py", line 91, in __init__
whatever = self.__post_init__()
  File "/usr/lib/python2.7/dist-
packages/fontypythonmodules/gui_dismissable_panels.py", line 626, in
__post_init__
self._make_label(),
  File "/usr/lib/python2.7/dist-
packages/fontypythonmodules/gui_dismissable_panels.py", line 672, in
_make_label
return _("The zip file(s) will be put into:\n{}").format(p)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 14:
ordinal not in range(128)



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

Kernel: Linux 4.19.0-4-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fontypython depends on:
ii  python   2.7.14-3
ii  python-pil   4.0.0-4
ii  python-wxgtk3.0  3.0.2.0+dfsg-5

fontypython recommends no packages.

fontypython suggests no packages.

-- no debconf information

Bug#942285: smokeping: stretch to buster upgrade adds dyndir to /etc/smokeping/config.d/pathnames, breaking existing installation

[Kenyon Ralph]

Package: smokeping
Version: 2.7.3-2
Severity: normal

Dear Maintainer,

When upgrading from stretch to buster, dyndir =
/var/lib/smokeping/__cgi was added to my
/etc/smokeping/config.d/pathnames. This causes smokeping.cgi to look
for files and directories under that __cgi directory, but since my
installation predates dyndir, all of those files and directories are
under datadir. This results in a bunch of errors like this in the web
server error log:

[Sat Oct 12 02:54:46.775961 2019] [cgi:error] [pid 1626:tid 140274202294016] 
[client 2606:6000:cd04:400:222:4dff:fe83:cd4a:42894] AH01215: [Sat Oct 12 
02:54:46 2019] smokeping.cgi [client 2606:6000:cd04:400:222:4dff:fe83:cd4a]: 
Could not lock /var/lib/smokeping/__cgi//Others/ISPRouter.einstein.slave_cache 
(No such file or directory). Trying again 2 more times.: 
/usr/lib/cgi-bin/smokeping.cgi
[Sat Oct 12 02:54:46.778780 2019] [cgi:error] [pid 1626:tid 140274202294016] 
[client 2606:6000:cd04:400:222:4dff:fe83:cd4a:42894] AH01215: [Sat Oct 12 
02:54:46 2019] smokeping.cgi [client 2606:6000:cd04:400:222:4dff:fe83:cd4a]: 
Could not lock /var/lib/smokeping/__cgi//Others/ISPRouter.einstein.slave_cache 
(No such file or directory). Trying again 1 more times.: 
/usr/lib/cgi-bin/smokeping.cgi
[Sat Oct 12 02:54:46.779933 2019] [cgi:error] [pid 1626:tid 140274202294016] 
[client 2606:6000:cd04:400:222:4dff:fe83:cd4a:42894] AH01215: [Sat Oct 12 
02:54:46 2019] smokeping.cgi [client 2606:6000:cd04:400:222:4dff:fe83:cd4a]: 
Could not update 
/var/lib/smokeping/__cgi//Others/ISPRouter.einstein.slave_cache, giving up for 
now. at /usr/share/perl5/Smokeping/Master.pm line 156.: 
/usr/lib/cgi-bin/smokeping.cgi

The easy fix is to remove the dyndir line from
/etc/smokeping/config.d/pathnames. I suppose you could also move the
files to dyndir. I'm not sure why this wasn't a problem when upgrading
to wheezy, jessie, or stretch, since the split_config script seems to
have been introduced for wheezy, and I installed smokeping on squeeze.

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

Kernel: Linux 5.1.17-x86_64-linode128 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages smokeping depends on:
ii  adduser 3.118
ii  debianutils 4.8.6.1
ii  fping   4.2-1
ii  libcgi-fast-perl1:2.13-1
ii  libconfig-grammar-perl  1.12-2
ii  libdigest-hmac-perl 1.03+dfsg-2
ii  libjs-cropper   1.2.2-1
ii  libjs-prototype 1.7.1-3
ii  libjs-scriptaculous 1.9.0-2
ii  librrds-perl1.7.1-2
ii  libsnmp-session-perl1.14~git20130523.186a005-4
ii  liburi-perl 1.76-1
ii  libwww-perl 6.36-2
ii  lsb-base10.2019051400
ii  perl5.28.1-6
ii  postfix [mail-transport-agent]  3.4.5-1
ii  ucf 3.0038+nmu1

Versions of packages smokeping recommends:
ii  apache2 [httpd-cgi]  2.4.38-3+deb10u1
ii  dnsutils 1:9.11.5.P4+dfsg-5.1
ii  echoping 6.0.2-10
ii  libsocket6-perl  0.29-1+b1

Versions of packages smokeping suggests:
ii  curl   7.64.0-4
pn  libauthen-radius-perl  
ii  libio-socket-ssl-perl  2.060-3
ii  libnet-dns-perl1.19-1
pn  libnet-ldap-perl   
pn  libnet-telnet-perl 
ii  openssh-client 1:7.9p1-10+deb10u1

-- no debconf information

Bug#934338: xtel: Please migrate off xmkmf/imake

[Samuel Thibault]

FI, upstream thinks it's not worth the effort since official minitel
servers are down since around 2012.

Samuel

Bug#941562: python-mox: diff for NMU version 0.7.8-1.1

[Sandro Tosi]

> > all of this so that i will be able to upgrade nsscache from python2 to 
> > python3:
> > it requires pymox for tests.
>
> Honestly last I looked at mox, the mock library shipped with python was
> as good, so maybe a better thing would be to port the unittests. But,
> that's a separate thing.

i agree upstream projects should move to mock but not all of them are there yet.

> > It would also be great if you'd consider migrating your python packages to
> > the DPMT team :)
>
> I'd have to learn what needs to be done first, but given this is already
> under debian with righs for all DDs, what would DPMT bring on top?

i think the most important reason is mentioned in the policy:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

```
by packaging available modules that may be useful and
providing a central location for packages maintained by a team, hence
improving responsiveness, integration, and standardization.
```

in the case of the py2 removal process, it would be extremely helpful
to have as many packages as possible in the team, so that we could
have a more standardize approach to upload packages to remove their
py2 packages. of course, it's your choice where you want to maintain
your packages, i just think for a python module, that place is DPMT

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#942284: libsnmp-perl: perl module SNMP broken

[gregor herrmann]

Package: libsnmp-perl
Version: 5.8+dfsg-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As noticed by some autopkgtest and build failures, e.g.
https://buildd.debian.org/status/package.php?p=libsnmp-info-perl
libsnmp-perl is broken.

Minimal test case:

% perl -MSNMP -e1
Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/NetSNMP/default_store/default_store.so'
 for module NetSNMP::default_store: 
/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/NetSNMP/default_store/default_store.so:
 undefined symbol: netsnmp_ds_get_boolean at 
/usr/lib/x86_64-linux-gnu/perl/5.30/DynaLoader.pm line 193.
 at /usr/lib/x86_64-linux-gnu/perl5/5.30/SNMP.pm line 19.
Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.30/SNMP.pm 
line 19.
BEGIN failed--compilation aborted at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/SNMP.pm line 19.
Compilation failed in require.
BEGIN failed--compilation aborted.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl2jpM5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaq7BAAtaqI2DGml2AO2vgRqnQKlygINGZg9bhbN23LAT1WfSI1VESQjfzeWAPe
ImJN99DUeySKDmEm0jlykz5k/XZZFipxA1pLPNVbRKOPis+lZSZyCODR8s/TdoIS
VYtyxXHBPe+D8JkjHB5tBzHJ9NAfj55vtYLm4WyH5Ztt5RUtXXO6ctvXJkhNrZz8
XMFaA6R7+8nhFOxoGULhmxHFhU3v7EaeE9gsj0HD6e4urQdpjob8c779jDGT6N4y
cstfong8ohEe+Ew/otVsFmPGm3HviwPo2qrCVvdXIYQZr4+uTdZtttoQ17N5AyNn
CLdxxERT6c4TJyqnQyeeUA6tL4MjLwqgAJGGLcNF3iOaftI04qFpzb+uPUGMZ+CB
YI9Lv7ev3eMuRh1vKkN16B+q9kUnNo7J/jS+1rm3QLNMTGbGuilIFgy5BiSURl7s
uKLVC8YJOOlW2J+24FPe42p+WURsMZLr74laUav9IbLHldy9iinC/teAFf7PXzrK
3lo/eD/nELgagLX4YQovjol28yDwnfyTgvvVrWfEmZF9bdcIsdrsF9ZekQI4Hvmu
x4TFr+bjPKa/kaGrTtMiGXDErvkJPALnYY/hDFY19HWHKTXkgVwUt2g2sk2B3oKh
VM1bk+8QnxKHaBmnz2epqXZGORZtVQ1TDl6WQw/ptdq7IRSA/w0=
=G+aH
-END PGP SIGNATURE-

Bug#925941: nvenc not in ffmpeg

[Tony Mantler]

Silly question: is there a quick how-to for rebuilding the ffmpeg packages 
locally with nvenc turned on? I tried grabbing the source and build-deps with 
apt and twiddling with the configure file but I must have missed something as 
the newly built packages didn't show any signs of having nvenc support.

--
Tony 'Nicoya' Mantler - Master of Code-fu
-- nic...@ubb.ca -- http://www.ubb.ca/ --

Bug#938169: python-setuptools-git: diff for NMU version 1.2-2.1

[Sandro Tosi]

> > thanks! I think you have several other py2 bin packages without any
> > reverse deps that could be uploaded, maybe you want to go thru them?
>  Yup, that's the plan. I'm in preparation for an abroad business
> travel. Thus it may take more than a week. But I'm on it.

I'll try to remember not to NMU your packages, but it's possible i may
forget soon and still do that :) I always upload to delayed/7 so
there's still time to do a MU

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#942172: clamav-daemon: After upgrade, clamd cannon create /var/run/clamav/clamd.ctl and stop.

[Filipe Fonseca]

Hello,

I could only test from 0.100.0+dfsg-0+deb8u1 as I couldn't find 
0.100.3+dfsg-0+deb8u1 anywhere in the archives and I'm out of servers 
running clamav-daemon 0.100.3+dfsg-0+deb8u1; but as /run/clamav/ is root 
owned in 0.100.0+dfsg-0+deb8u1 and clamav-daemon 0.101.4+dfsg-0+deb8u2 
got started without a problem after the upgrade I'd say it's OK.


Many thanks!!!

Regards,
Filipe

On 13/10/19 10:32, Filipe Fonseca wrote:

Hello,

I can test it but probably only in half a day time or so. I'll get back 
to you then. Many thanks.


Regards,
Filipe

On October 13, 2019 09:33:17 Hugo Lefeuvre  wrote:


Hi Filipe,

I did strike this in three boxes. Straight upgrade but opted not to 
touch

config when asked. Don't know if it matters. However I did not find any
reference to /etc/systemd/system/clamav-daemon.service.d/extend.conf 
in the

package scripts as in stretch.

The chown did make the difference. And the extend.conf prior to the 
upgrade

on further two boxes got the upgrade working, AFAICT.


thanks for your answer.

After further investigations, I have found a probable cause for this 
issue:

debian/patches/clamd_dont_depend_on_clamav_demon_socket.patch was
mistakenly backported from the stretch upload.

This should not have been backported, because the jessie package is still
providing the systemd socket, which was removed from the stretch 
package in

0.99.2+dfsg-3 because of #824042[0].

I did not backport this removal because I considered it too intrusive 
for a

security upload. Looking back, this was maybe a mistake because it
increased the complexity of the backport.

I have prepared a regression update addressing this issue. It would be a
true benefit for the quality of this upload if somebody could give it 
a try

before I go on with uploading. You can find (UNRELEASED) amd64 builds,
signed by myself on my Debian webpage:

https://people.debian.org/~hle/lts/clamav/

regards,
Hugo

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824042

--
   Hugo Lefeuvre (hle)    |    www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


--
filipe.fons...@farmingbits.com
+351.914593743






--
filipe.fons...@farmingbits.com
+351.914593743

Bug#938169: python-setuptools-git: diff for NMU version 1.2-2.1

[GCS]

On Sun, Oct 13, 2019 at 11:20 PM Sandro Tosi  wrote:
> On Sun, Oct 13, 2019 at 3:50 AM László Böszörményi (GCS)  
> wrote:
> >  Expect the non-removal of "X-Python-Version" this is fine.
>
> they are not strictly required from the removal of py2, they are just
> obsolete fields, good to remove in a MU
 More or less right. Proper package maintenance means to remove those fields.

> > With other
> > changes I'm going to upload it soon.
>
> thanks! I think you have several other py2 bin packages without any
> reverse deps that could be uploaded, maybe you want to go thru them?
 Yup, that's the plan. I'm in preparation for an abroad business
travel. Thus it may take more than a week. But I'm on it.

Regards,
Laszlo/GCS

Bug#942019: Assembling an .apk fails with: Invalid file name: must contain only [a-z0-9_.]

[Markus Koschany]

Control: reassign -1 aapt
Control: affects -1 apktool

On Wed, 09 Oct 2019 06:23:00 + Georg Koppen  wrote:
> Package: apktool
> Version: 2.4.0-1
> 
> When using apktool to assemble a .apk after decompiling it I get the
> following error:

Hello,

thanks for the detailed bug report. I believe the Invalid file name
warnings cause the exception in apktool. The bug is in aapt which is a
separate package in Debian. We don't use the prebuilt binaries and
probably a new release of aapt will fix the issue.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#862908: #862908 smartd fails to start when no disks are present

[Thorsten Glaser]

On Fri, 11 Oct 2019, Dmitry Smirnov wrote:

> Thorsten, upstream suggested to pass "-q never" to smartd.
> 
> I verified that the daemon starts on system without disks
> with 
> 
> smartd_opts="-q never"
> 
> in "/etc/default/smartmontools".

I can try that, but the system has discs:

root@ci-busyapps:~ # cat /proc/partitions
major minor  #blocks  name

 2540   67108864 vda
 2541   67106816 vda1
 2530   65105920 dm-0
 25311998848 dm-1


Yes, adding that option fixes it. Please make it the default;
it’s not acceptable for a newly installed package to break
during maintainer script operation (we learnt that the hard
way in fusionforge, where the postinst needs the database but
can’t error out if it is not running).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#942283: mtkbabel: Timestamps in GPX files are in the past by 7168 days due Weeks Rollover Bug

[Niccolo Rigacci]

Package: mtkbabel
Version: 0.8.3.1-1.1
Severity: normal
Tags: patch

Dear Maintainer,

When I download GPS data from an i-Blue 747 device, Model ID 
001B, all the timestamps are now in the past by 7168 days. As an 
example, a track recorded in data 2019-10-10, have all timestamps 
with date 2000-02-24. The time is indeed correct. The device has 
worked perfectly until some months ago.

Searching for "GPS Weeks Rollover Bug" on the net, I discovered that many
GPS devices are affected by an overflow on weeks count, this means that
timestamps will overflow after 1024 weeks (10 bits), starting back from
device hard-coded EPOCH (begin of the time).

The upstream mantainer (i.e. me) has made a patch in mtkbabel: if 
you use the -W -1 option, the program will try to guess if a 
rollover is happening, and it will add 1024 weeks to the 
timestamp. You can also pass the exact count of rollover weeks, 
e.g. with -W 1024.

New upstream version is downloadable here:
https://sourceforge.net/projects/mtkbabel/files/mtkbabel/0.8.4/



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

Kernel: Linux 4.9.0-9-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mtkbabel depends on:
ii  libdevice-serialport-perl  1.04-3+b3
ii  libtimedate-perl   2.3000-2
ii  perl   5.24.1-3+deb9u5

mtkbabel recommends no packages.

mtkbabel suggests no packages.

-- no debconf information

Bug#880380: Orphaning php-horde*

[Mathieu Parent]

Hello,

FYI, I'm orphaning php-horde-* packages. See:

https://bugs.debian.org/942282

Regards
-- 
Mathieu Parent

Bug#942252: lintian: No vendor given at /<>/lib/Lintian/Maintainer.pm line 33

[Felix Lechner]

Hi Sebastian,

On Sun, Oct 13, 2019 at 12:15 PM Chris Lamb  wrote:
>
> Thanks. Unfortunately, I don't quite know why this is happening. (The
> tests on Salsa appear to pass right now.)

Some test scripts appear to load old profiles. They are presumably
located in the installed location /usr/share/lintian. The errors
depend on the version difference between what is installed and what is
under test. That is probably why the reported bug does not show up in
Gitlab (anymore).

Could you please cherry-pick this commit?
https://salsa.debian.org/lintian/lintian/commit/33508343d8fde77a3d5db22863ff358dbf7a915f

This commit does two things: (1) It unambiguously uses only one
include path when finding profiles, and (2) makes sure a profile is
loaded in the test pod-synopsis.t that fails in your bug report.

I cannot test the proposed fix locally (the error does not appear
here). Which version Lintian do you have installed?

Kind regards,
Felix Lechner

Bug#938169: python-setuptools-git: diff for NMU version 1.2-2.1

[Sandro Tosi]

On Sun, Oct 13, 2019 at 3:50 AM László Böszörményi (GCS)  
wrote:
>
> Hi Sandro,
>
> On Sun, Oct 13, 2019 at 5:03 AM Sandro Tosi  wrote:
> > I've prepared an NMU for python-setuptools-git (versioned as 1.2-2.1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
>  Expect the non-removal of "X-Python-Version" this is fine.

they are not strictly required from the removal of py2, they are just
obsolete fields, good to remove in a MU

> With other
> changes I'm going to upload it soon.

thanks! I think you have several other py2 bin packages without any
reverse deps that could be uploaded, maybe you want to go thru them?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#935042: Program phones home by default

[Robie Basak]

On Sun, Oct 13, 2019 at 11:02:45PM +0200, Birger Schacht wrote:
> The problem is that the package will be removed from unstable in a
> couple of days because of this bug report. 3 month is sometimes not that
> much time to fix a bug or even comment on a bug report. And the release
> of bullseye is not even in sight. I or someone else could do an NMU, but
> the package will be removed from the archive before that can happen.

It sounds like you would like to change Debian's process for handling
serious bugs then, rather than having any particular issue with this bug
specifically? That might be a discussion better had on the debian-devel@
list.


signature.asc
Description: PGP signature

Bug#942282: O: php-horde-core -- Core Horde Framework library (AND all php-horde*!)

[Mathieu Parent]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-de...@lists.debian.org

Hello,

I intend to orphan the php-horde-core package and ALL the php-horde*
packages. I'm not using them anymore.

There are a few stability fixes to backport to stable (#839129,
#931255 #880380, #935816).

There is some tooling to ease package update and upload.

I won't create a bug for each of those 123 packages [1], but I will
ask for the removal of those packages if no-one comes within the next
months.

[1]: 
https://qa.debian.org/developer.php?email=team%2Bdebian-horde-team%40tracker.debian.org

The php-horde-core package description is:
 These classes provide the core functionality of the Horde Application
 Framework.
 .
 This package is part of Horde, a web application Framework written in PHP with
 modules like IMP (webmail), Turba (contacts), Kronolith (calendar), Nag (task
 list), Gollem (file manager), etc.

Bug#942281: libapache2-mod-ruid2 package missing

[Ali Laraaj]

Package: libapache2-mod-ruid2
Version: 0.9.8-3
Severity: grave

The package libapache2-mod-ruid2 is completely missing from Debian 10

(Buster) repositories, what's the problem why is it missing ?

It's available in previous releases and the the unstable release (SID)

but not Buster

jessie (httpd): 0.9.8-3
Binary packages: libapache2-mod-ruid2
stretch (httpd): 0.9.8-3
Binary packages: libapache2-mod-ruid2
sid (httpd): 0.9.8-3
Binary packages: libapache2-mod-ruid2

Bug#935042: Program phones home by default

[Birger Schacht]

Hi,

On 10/13/19 10:02 PM, Robie Basak wrote:
> On Sun, Oct 13, 2019 at 05:23:40PM +0200, Birger Schacht wrote:
>> Robie, could you please point out the part of the Debian policy that
>> this package is violating?
> 
> I cannot. I believe that this issue is such a clear violation of
> Debian's philosophy that it has never been necessary to document it
> formally as policy.

Thanks for the clarification!

> 
> However you seem to have missed out the latter part of the definition of
> "serious" in your quote. Here's the full definition:
> 
> serious is a severe violation of Debian policy (roughly, it
> violates a "must" or "required" directive), or, in the package
> maintainer's or release manager's opinion, makes the package
> unsuitable for release.

I haven't missed out the part about the "package maintainers or the
release manager's opinion", but I didn't consider it relevant to this
bug report because its neither nor is setting this level of seriousness.

> I think it's quite clear that this issue makes the package unsuitable
> for release. If the package maintainer disagrees and thinks that it's OK
> to release Debian with this bug outstanding, they may change it.
> 
> Are you suggesting that "serious" is not justified? Nobody seems to have
> doubted that so far. If the package maintainer wants to reduce the
> severity of this bug by relying on policy not mentioning this type of
> matter, then I'm fairly confident that this will result in policy being
> amended in the end anyway.

The problem is that the package will be removed from unstable in a
couple of days because of this bug report. 3 month is sometimes not that
much time to fix a bug or even comment on a bug report. And the release
of bullseye is not even in sight. I or someone else could do an NMU, but
the package will be removed from the archive before that can happen.

cheers,
Birger
PS: please don't mistake me asking for clarification as a sign that I
don't consider this being a privacy leak, on the contrary.

Bug#556893: #556893,say which 'defaults' are which better

[Michael Biebl]

Control: tags -1 - patch

Am 13.10.19 um 21:41 schrieb Jesse Smith:
> On 10/13/19 4:33 PM, Michael Biebl wrote:
>> Control: tags -1 + moreinfo

>> Will insserv fail if the version is too old, i.e. do we need a versioned
>> dependency (or rather versioned Breaks)?
> 
> Yes, older versions of insserv will fail if --silent is specified as it
> will not be a recognized option. There should probably be a version
> check. Or a check in the calling script to try with insserv --silent and
> if it fails, try again without the flag.

Ok, thanks.

Removing the patch tag then.

>> What exactly is suppressed by -q/--silent?
>> Only this specific error about "defaults" or other error messages as
>> well? Do we want to suppress all error messages?
> 
> The --silent flag suppresses warnings (non-fatal errors). Basically
> anything that is a "heads up" warning is suppressed. Fatal errors and
> issues which require user attention are still printed.

Ok, good.


-- 
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#935042: Privacy Breach is not in policy

[Marcos Fouces]

Hello

Similar issues were discussed in: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726998

You could also find that Lintian folks uses several levels of error
tags to describe this problem, for instance:

* 
https://lintian.debian.org/tags/privacy-breach-statistics-website.html.
It is considered as "serious"

* https://lintian.debian.org/tags/privacy-breach-generic.html. It is
considered as "important"

Both tags are related to the present issue.

AFAIK, there is nothing in Debian Policy about this but it is plain
common sense to avoid this kind of privacy breaches.

Greetings, 

Marcos

Bug#935042: Program phones home by default

[Robie Basak]

On Sun, Oct 13, 2019 at 05:23:40PM +0200, Birger Schacht wrote:
> Robie, could you please point out the part of the Debian policy that
> this package is violating?

I cannot. I believe that this issue is such a clear violation of
Debian's philosophy that it has never been necessary to document it
formally as policy.

However you seem to have missed out the latter part of the definition of
"serious" in your quote. Here's the full definition:

serious is a severe violation of Debian policy (roughly, it
violates a "must" or "required" directive), or, in the package
maintainer's or release manager's opinion, makes the package
unsuitable for release.

I think it's quite clear that this issue makes the package unsuitable
for release. If the package maintainer disagrees and thinks that it's OK
to release Debian with this bug outstanding, they may change it.

Are you suggesting that "serious" is not justified? Nobody seems to have
doubted that so far. If the package maintainer wants to reduce the
severity of this bug by relying on policy not mentioning this type of
matter, then I'm fairly confident that this will result in policy being
amended in the end anyway.


signature.asc
Description: PGP signature

Bug#938962: Bug#941720: linux-headers-4.19.0-0.bpo.6-amd64 depends on linux-headers-4.19.0-0.bpo.6-common=4.19.67-2+deb10u1~bpo9+1 but only linux-headers-4.19.0-0.bpo.6-amd64=4.19.67-2~bpo9+1 is avail

[Bastian Blank]

On Sun, Oct 13, 2019 at 07:20:35PM +0530, Ritesh Raj Sarraf wrote:
> It is maintained. It is just that the latest upload is blocked by DBug:
> #938962

No, it is not maintained.  It depends on packages not longer in the
archive.

Regards,
Bastian

-- 
Bones: "The man's DEAD, Jim!"

Bug#597897: FOR YOUR INFORMATION

[Richard Cracknell]

From: Richard Cracknell
Sent: Sunday, October 13, 2019 11:32 AM
Subject: FOR YOUR INFORMATION


Hi, you have been selected to receive a financial-donation. Contact  
maviswan...@gmail.com  for more info and claim.

Bug#942280: linux-image-4.19.0-6-amd64: Mouse wheel does not work

[Rafał Rutkowski]

Package: src:linux
Version: 4.19.67-2+deb10u1
Severity: important

Dear Maintainer,
The mouse wheel does not work, if the machine is booted with this kernel.
By not working, I mean the windows do not scroll (I use GNOME on X11); no
mouse
wheel events are registered in xev.

The above problem does not exist, if the machine is booted with 4.19.0-5.

Below is the mouse info from lsusb:

Bus 003 Device 005: ID 09da:000a A4Tech Co., Ltd. Optical Mouse Opto 510D /
OP-620D
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x09da A4Tech Co., Ltd.
  idProduct  0x000a Optical Mouse Opto 510D / OP-620D
  bcdDevice0.17
  iManufacturer   1 A4Tech
  iProduct2 USB Mouse
  iSerial 0
  bNumConfigurations  1



-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64
root=UUID=0a662727-41e2-4786-8765-c0b222edc576 ro quiet iommu=pt
ignore_msrs=1

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[4.586935] CR2: 56192c487268 CR3: 00042b772000 CR4:
003406e0
[4.586936] Call Trace:
[4.586993]  dce110_apply_ctx_to_hw+0x62d/0x690 [amdgpu]
[4.587051]  ? hubbub1_verify_allow_pstate_change_high+0xdd/0x180
[amdgpu]
[4.587106]  dc_commit_state+0x2c6/0x550 [amdgpu]
[4.587161]  ? set_freesync_on_streams.part.6+0x4d/0x230 [amdgpu]
[4.587215]  ? mod_freesync_set_user_enable+0x11f/0x150 [amdgpu]
[4.587273]  amdgpu_dm_atomic_commit_tail+0x384/0xe00 [amdgpu]
[4.587323]  ? amdgpu_bo_pin_restricted+0x60/0x280 [amdgpu]
[4.587380]  ? amdgpu_dm_atomic_commit_tail+0xe00/0xe00 [amdgpu]
[4.587436]  ? dm_plane_helper_prepare_fb+0x1ee/0x300 [amdgpu]
[4.587443]  commit_tail+0x3d/0x70 [drm_kms_helper]
[4.587449]  drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper]
[4.587454]  restore_fbdev_mode_atomic+0x170/0x1d0 [drm_kms_helper]
[4.587460]  drm_fb_helper_restore_fbdev_mode_unlocked+0x45/0x90
[drm_kms_helper]
[4.587466]  drm_fb_helper_set_par+0x29/0x50 [drm_kms_helper]
[4.587467]  fbcon_init+0x488/0x600
[4.587469]  visual_init+0xd5/0x130
[4.587470]  do_bind_con_driver+0x1db/0x2d0
[4.587471]  do_take_over_console+0x113/0x190
[4.587473]  do_fbcon_takeover+0x58/0xb0
[4.587474]  notifier_call_chain+0x47/0x70
[4.587475]  blocking_notifier_call_chain+0x3e/0x60
[4.587476]  register_framebuffer+0x257/0x340
[4.587482]  __drm_fb_helper_initial_config_and_unlock+0x216/0x440
[drm_kms_helper]
[4.587533]  amdgpu_fbdev_init+0xc4/0xf0 [amdgpu]
[4.587588]  amdgpu_device_init.cold.28+0x1142/0x129e [amdgpu]
[4.587637]  amdgpu_driver_load_kms+0x86/0x2d0 [amdgpu]
[4.587648]  drm_dev_register+0x109/0x140 [drm]
[4.587697]  amdgpu_pci_probe+0x1aa/0x230 [amdgpu]
[4.587699]  local_pci_probe+0x41/0x90
[4.587700]  pci_device_probe+0xf5/0x1b0
[4.587702]  really_probe+0x23e/0x390
[4.587703]  driver_probe_device+0xb3/0xf0
[4.587704]  __driver_attach+0xea/0x110
[4.587705]  ? driver_probe_device+0xf0/0xf0
[4.587706]  bus_for_each_dev+0x77/0xc0
[4.587708]  ? klist_add_tail+0x3b/0x70
[4.587709]  bus_add_driver+0x152/0x230
[4.587710]  ? 0xc0f42000
[4.587711]  driver_register+0x6b/0xb0
[4.587712]  ? 0xc0f42000
[4.587713]  do_one_initcall+0x46/0x1c3
[4.587714]  ? _cond_resched+0x15/0x30
[4.587715]  ? kmem_cache_alloc_trace+0x155/0x1d0
[4.587717]  do_init_module+0x5a/0x210
[4.587718]  load_module+0x2118/0x2390
[4.587720]  ? __do_sys_finit_module+0xad/0x110
[4.587721]  __do_sys_finit_module+0xad/0x110
[4.587723]  do_syscall_64+0x53/0x110
[4.587724]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[4.587725] RIP: 0033:0x7f351b7b1f59
[4.587726] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48
89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05
<48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00 f7 d8 64 89 01 48
[4.587726] RSP: 002b:7fffc0ba4468 EFLAGS: 0246 ORIG_RAX:
0139
[4.587727] RAX: ffda RBX: 5635e0c7c080 RCX:
7f351b7b1f59
[4.587728] RDX:  RSI: 7f351b6b6cad RDI:
0014
[4.587728] RBP: 7f351b6b6cad R08:  R09:

[4.587729] R10: 0014 R11: 0246 R12:

[4.587729] R13: 5635e0c64be0 R14: 0002 R15:
5635e0c7c080
[4.587730] ---[ end trace 365537b8fab10f42 ]---
[4.595392] Console: switching to colour frame buffer device 240x75
[4.597130] EDAC amd64: Node 0: DRAM ECC disabled.
[4.597132] EDAC amd64: ECC 

Bug#942266: Try to exclude root

[Corcodel Marian]

On atach is 1 patch wich prevent to run pulseaudio on root user.


---
Last-Update: 2019-10-13

--- pulseaudio-10.0.orig/src/daemon/main.c
+++ pulseaudio-10.0/src/daemon/main.c
@@ -646,6 +646,12 @@ int main(int argc, char *argv[]) {
 goto finish;
 }
 
+#if defined (HAVE_GETUID) && defined (HAVE_SYSTEMD_DAEMON)
+if (getuid() == 0 && !conf->system_instance) {
+	pa_log(_("THIS program is not intended to be as root (unless --system is specified), exitting."));
+	goto finish;
+}
+#endif
 #ifdef HAVE_GETUID
 if (getuid() == 0 && !conf->system_instance)
 pa_log_warn(_("This program is not intended to be run as root (unless --system is specified)."));

Bug#942279: golang-github-hashicorp-go-retryablehttp breaks golang-github-circonus-labs-circonus-gometrics autopkgtest

[Paul Gevers]

Source: golang-github-hashicorp-go-retryablehttp, 
golang-github-circonus-labs-circonus-gometrics
Control: found -1 golang-github-hashicorp-go-retryablehttp/0.6.2-1
Control: found -1 golang-github-circonus-labs-circonus-gometrics/2.0.0-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of golang-github-hashicorp-go-retryablehttp the
autopkgtest of golang-github-circonus-labs-circonus-gometrics fails in
testing when that autopkgtest is run with the binary packages of
golang-github-hashicorp-go-retryablehttp from unstable. It passes when
run with only packages from testing. In tabular form:
pass fail
golang-github-hashicorp-go-retryablehttpfrom testing 0.6.2-1
golang-github-circonus-labs-circonus-gometrics  from testing 2.0.0-1
all others  from testing from testing

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

Currently this regression is blocking the migration of
golang-github-hashicorp-go-retryablehttp to testing [1]. Due to the
nature of this issue, I filed this bug report against both packages. Can
you please investigate the situation and reassign the bug to the right
package?

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

Paul

[1]
https://qa.debian.org/excuses.php?package=golang-github-hashicorp-go-retryablehttp

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-circonus-labs-circonus-gometrics/3160364/log.gz

# github.com/circonus-labs/circonus-gometrics
src/github.com/circonus-labs/circonus-gometrics/submit.go:133:24: cannot
use func literal (type func(*log.Logger, *http.Request, int)) as type
retryablehttp.RequestLogHook in assignment
dh_auto_build: cd obj-x86_64-linux-gnu && go install
-gcflags=all=\"-trimpath=/tmp/autopkgtest-lxc.ikh1z671/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\"
-asmflags=all=\"-trimpath=/tmp/autopkgtest-lxc.ikh1z671/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\"
-v -p 2 github.com/circonus-labs/circonus-gometrics
github.com/circonus-labs/circonus-gometrics/api
github.com/circonus-labs/circonus-gometrics/api/config
github.com/circonus-labs/circonus-gometrics/checkmgr returned exit code 2
make: *** [debian/rules:4: build] Error 255



signature.asc
Description: OpenPGP digital signature

Bug#556893: #556893,say which 'defaults' are which better

[Jesse Smith]

On 10/13/19 4:33 PM, Michael Biebl wrote:
> Control: tags -1 + moreinfo
>
> On Sat, 28 Sep 2019 15:21:17 -0300 Jesse Smith
>  wrote:
>> This has been addressed upstream in insserv by allowing the program to
>> accept changes like this silently. All we need now is for update-rc.d to
>> be updated to use the new behaviour (enabled with the -q flag) and this
>> issue can be closed.
> Is it -q or --silent? Or are they the same?

-q and --silent do the same thing. These are now documented in the
manual page for insserv.

>
> Will insserv fail if the version is too old, i.e. do we need a versioned
> dependency (or rather versioned Breaks)?

Yes, older versions of insserv will fail if --silent is specified as it
will not be a recognized option. There should probably be a version
check. Or a check in the calling script to try with insserv --silent and
if it fails, try again without the flag.

> What exactly is suppressed by -q/--silent?
> Only this specific error about "defaults" or other error messages as
> well? Do we want to suppress all error messages?

The --silent flag suppresses warnings (non-fatal errors). Basically
anything that is a "heads up" warning is suppressed. Fatal errors and
issues which require user attention are still printed.

Bug#941452: python-cryptography 1.7.1-3+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941452 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: python-cryptography
Version: 1.7.1-3+deb9u2

Explanation: fix test suite failures when built against newer OpenSSL versions

Bug#942193: dwz: dh_dwz freecad build regression: write_die: Assertion `value && refdcu->cu_kind != CU_ALT' failed.

[Kurt Kremitzki]

Hi Matthias,

On Saturday, October 12, 2019 12:34:30 PM CDT Matthias Klose wrote:
> Control: tags -1 + moreinfo
> Control: severity -1 grave
> 
> please could you attach the binary, or put it somewhere on the web?
> 

Sorry, which binary are you referring to?

Here are a few links in the meantime that might help, buildd logs for the 
i386/s390x/mipsel failures:

https://buildd.debian.org/status/fetch.php?
pkg=freecad=i386=0.18.3%2Bdfsg1-3=1568751036=0

https://buildd.debian.org/status/fetch.php?
pkg=freecad=mipsel=0.18.3%2Bdfsg1-3=1568784049=0

https://buildd.debian.org/status/fetch.php?
pkg=freecad=s390x=0.18.3%2Bdfsg1-3=1569764936=0

Bug#941169: postfix 3.1.14-0+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941169 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: postfix
Version: 3.1.14-0+deb9u1

Explanation: new upstream stable release; work around poor TCP loopback 
performance

Bug#941350: fence-agents 4.0.25-1+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941350 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: fence-agents
Version: 4.0.25-1+deb9u2

Explanation: fix incomplete removal of fence_amt_ws

Bug#942278: dpkg-www: Missing dependancy on perl module CGI.pm. At least when using lighttpd.

[Michael Gindonis]

Package: dpkg-www
Severity: normal

Dear Maintainer,

I installed dpkg-www on a raspberry pi running raspian (based on Debian 10.1).
For the web server I chose lighttpd and enabled the cgi module.

When accessing the dpkg-www cgi via a web browser, anything clickable did not 
work.
It would just print the main page. Looking a bit further and setting the debug 
option
I noticed that the script did not receive the query string.

Looking at /usr/lib/cgi-bin/dpkg it tries to load a perl module that is not in 
the dependancies.

1261:perl -e "use CGI; my \$q = new CGI(\$_); print scalar 
\$q->param('$key')" "$1"

I installed libcgi-pm-perl to satisfy the dependancy and then the CGI worked as 
it should.

The system information below is not the same system where I encountered the 
problem.
I doubt that it makes much difference. 

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

Kernel: Linux 4.9.0-3-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg-www depends on:
ii  apt   1.4.9
pn  dwww  
pn  info2www  
ii  perl  5.24.1-3+deb9u5

Versions of packages dpkg-www recommends:
pn  apache2 | httpd  

Versions of packages dpkg-www suggests:
ii  chromium [www-browser] 73.0.3683.75-1~deb9u1
ii  dctrl-tools [grep-dctrl]   2.24-2+b1
ii  dlocate1.07+nmu1
ii  firefox-esr [www-browser]  60.9.0esr-1~deb9u1
pn  man2html   
ii  tasksel3.39

Bug#942110: gnustep-base 1.24.9-3.1+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 942110 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: gnustep-base
Version: 1.24.9-3.1+deb9u1

Explanation: fix UDP amplification vulnerability

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Harlan Lieberman-Berg]

On Sun, Oct 13, 2019 at 06:53 Adam D. Barratt 
wrote:

> Apologies for the delay. Please go ahead.


Uploaded!

> --
Harlan Lieberman-Berg
~hlieberman

Bug#556893: #556893,say which 'defaults' are which better

[Michael Biebl]

Control: tags -1 + moreinfo

On Sat, 28 Sep 2019 15:21:17 -0300 Jesse Smith
 wrote:
> This has been addressed upstream in insserv by allowing the program to
> accept changes like this silently. All we need now is for update-rc.d to
> be updated to use the new behaviour (enabled with the -q flag) and this
> issue can be closed.

Is it -q or --silent? Or are they the same?

Will insserv fail if the version is too old, i.e. do we need a versioned
dependency (or rather versioned Breaks)?

What exactly is suppressed by -q/--silent?
Only this specific error about "defaults" or other error messages as
well? Do we want to suppress all error messages?

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#942265: systemd: Missing subdir. sockets.target.wants

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 13.10.19 um 15:12 schrieb Corcodel Marian:
> Package: systemd
> Version: 232-25+deb9u12
> Severity: normal
> 
> Hi, when try to enable global pulseaudio.socket missing subdir
> etc/systemd/user/socket.target.wants and need create manual.
> $systemctl --global enable pulseaudio.socket fail.
> 

Please provide the exact error message you are getting from systemctl
and the exact command line you used.
Output of
ls -la /etc/systemd/user/
before and after you run the systemctl command.

Fwiw, I can't reproduce the failure on stretch.



-- 
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#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

[Michael Biebl]

Control: tags -1 + moreinfo

Am 12.10.19 um 15:56 schrieb Rado Q:
> Package: systemd
> Version: 241-7~deb10u1
> 
> Dear Maintainer,
>* What led up to the situation?
> Installation of debian10.
> 
>* What exactly did you do (or not do) that was effective (or ineffective)?
> Boot.
> 
>* What was the outcome of this action?
> Failed systemd-backlight@backlight:dell_backlight.service .
> 
>* What outcome did you expect instead?
> Startup without failure.
> 
> 
> This happens with dell d600, d620, d820.
> It works OK for dell vostro 1520.
> 
> How to get more info?

Please attach the output of (run as root)
systemctl status systemd-backlight@backlight:dell_backlight.service
journalctl -alb

-- 
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#885265: Bug#936299: chirp: Python2 removal in sid/bullseye

[Chris Knadle]

There has been some discussion about #936299 on the upstream mailing list, and
there have been a few upstream commits starting to port the code to Python3.

http://intrepid.danplanet.com/pipermail/chirp_devel/2019-August/005580.html

  -- Chris, KB2IQN

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#942252: lintian: No vendor given at /<>/lib/Lintian/Maintainer.pm line 33

[Chris Lamb]

retitle 942252 lintian: No vendor given at 
/<>/lib/Lintian/Maintainer.pm line 33
thanks

Sebastian Ramacher wrote:

> https://buildd.debian.org/status/fetch.php?pkg=lintian=all=2.26.0=1570670200=0

Thanks. Unfortunately, I don't quite know why this is happening. (The
tests on Salsa appear to pass right now.)

t/scripts/pod-coverage.t ... ok
#   Failed test '/<>/lib/Lintian/Maintainer.pm'
#   at t/scripts/pod-synopsis.t line 18.
# No vendor given at /<>/lib/Lintian/Maintainer.pm line 33.
# Compilation failed in require at 
/<>/lib/Lintian/Maintainer.pm line 43.
# BEGIN failed--compilation aborted at 
/<>/lib/Lintian/Maintainer.pm line 43.
t/scripts/pod.t  ok
# Looks like you failed 1 test of 66.


Best wishes,

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

Bug#940476: tmpreaper 1.6.14+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 940476 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: tmpreaper
Version: 1.6.14+deb10u1

Explanation: add `--protect '/tmp/systemd-private*/*'` to cron job to prevent 
breaking systemd services that have PrivateTmp=true

Bug#939313: swi-prolog 8.0.2+dfsg-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939313 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: swi-prolog
Version: 8.0.2+dfsg-3+deb10u1

Explanation: use HTTPS when contacting upstream pack servers

Bug#939890: rpcbind 1.2.5-0.3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939890 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: rpcbind
Version: 1.2.5-0.3+deb10u1

Explanation: allow remote calls to be enabled at run-time

Bug#942075: cyrus-imapd 3.0.8-6+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 942075 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cyrus-imapd
Version: 3.0.8-6+deb10u1

Explanation: fix data loss on upgrade from version 3.0.0 or earlier

Bug#939526: inn2 2.6.3-1+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939526 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: inn2
Version: 2.6.3-1+deb10u2

Explanation: fix negotiation of DHE ciphersuites

Bug#941227: node-set-value 0.4.0-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941227 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-set-value
Version: 0.4.0-1+deb10u1

Explanation: fix prototype pollution [CVE-2019-10747]

Bug#941168: postfix 3.4.7-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941168 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: postfix
Version: 3.4.7-0+deb10u1

Explanation: new upstream stable release; work around poor TCP loopback 
performance

Bug#941451: python-cryptography 2.6.1-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941451 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: python-cryptography
Version: 2.6.1-3+deb10u1

Explanation: fix test suite failures when built against newer OpenSSL versions

Bug#942044: open-vm-tools 10.3.10-1+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 942044 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: open-vm-tools
Version: 10.3.10-1+deb10u2

Explanation: fix memory leaks and error handling

Bug#941348: fence-agents 4.3.3-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941348 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: fence-agents
Version: 4.3.3-2+deb10u1

Explanation: fix incomplete removal of fence_amt_ws

Bug#942253: picard 2.1.2-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 942253 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: picard
Version: 2.1.2-1+deb10u1

Explanation: update translations to fix crash with Spanish locale

Bug#939526: inn2 2.6.3-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939526 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: inn2
Version: 2.6.3-1+deb10u1

Explanation: fix negotiation of DHE ciphersuites

Bug#941468: plasma-applet-redshift-control 1.0.18-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941468 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: plasma-applet-redshift-control
Version: 1.0.18-2+deb10u1

Explanation: fix manual mode when used with redshift versions above 1.12

Bug#940943: gnustep-base 1.26.0-4+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 940943 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnustep-base
Version: 1.26.0-4+deb10u1

Explanation: disable gdomap daemon that was accidentally enabled on upgrades 
from stretch

Bug#939738: aegisub 3.2.2+dfsg-4+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939738 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: aegisub
Version: 3.2.2+dfsg-4+deb10u1

Explanation: fix crash when selecting a language from the bottom of the "Spell 
checker language" list; fix crash when right-clicking in the subtitles text box

Bug#940112: quota 4.04-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 940112 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: quota
Version: 4.04-2+deb10u1

Explanation: fix rpc.rquotad spinning at 100% CPU

Bug#906578: [makehuman] Future Qt4 removal

[Boyuan Yang]

Looks like makehuman upstream is working on the Qt5 version but it hasn't
finished yet. There's only alpha versions at 
https://github.com/makehumancommunity/makehuman . I guess we should move on
and have it removed if upstream is acting that slowly.

Muammar: if you have any other thoughts, please let us know now. Otherwise a
removal before 2020 should be reasonable.

Regards,
Boyuan Yang

在 2019-10-11五的 23:14 +0200，Moritz Mühlenhoff写道：
> Hi,
> there hasn't been any followup on this bug since over a year and we're now
> moving
> forward with the Qt4 removal, are there immediate plans to port makehuman to
> Qt5 or
> should we remove it from the archive?
> 
> Cheers,
> Moritz


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

Bug#937303: Please port to Python3 (#48)

[Olly Betts]

On Tue, Sep 17, 2019 at 02:29:45PM +, Alex Mestiashvili wrote:
> plip is actually python3 compatible, however it depends on
> python3-openbabel which is not yet in the archive, but some work is
> already done on the salsa repository. Once python3-openbabel is
> accepted into unstable I'll update plip packaging.

python3-openbabel is now in unstable:

$ rmadison python3-openbabel
python3-openbabel | 2.4.1+dfsg-4  | buildd-unstable | amd64, arm64, armel, 
armhf, i386, mips64el, mipsel, ppc64el, s390x
python3-openbabel | 2.4.1+dfsg-4  | unstable| amd64, arm64, armel, 
armhf, i386, mips64el, mipsel, ppc64el, s390x

Cheers,
Olly

Bug#941338: spek: Should spek be removed from Debian?

[Olly Betts]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: spek -- RoQA; dead upstream; unmaintained; low popcon; 
RC-buggy

On Sun, Sep 29, 2019 at 05:28:49PM +1300, Olly Betts wrote:
> I think it's time to remove the spek package:
> 
> * last upstream release was 6.5 years ago 
> * last package update was 3.5 years ago
> * has low popcon - inst:331 vote:57
> * has no reverse dependencies (according to dak rm)
> * 2 open bugs, neither with any maintainer response
> * I had to NMU for the last wxWidgets transition 5 years ago, and
>   it's now a blocker for the current wxwidgets3.0-gtk3 transition.
> 
> If there are no objections within two weeks, I'll turn this into an RM
> bug.

I've had no response, so doing so now.

Cheers,
Olly

Bug#941078: transition: postgresql-12

[Christoph Berg]

Re: Paul Gevers 2019-10-13 
> The migration is currently blocked on the regression of repmgr. I just
> triggered a reference run as I think the postgresql-11 migration in the
> perl transition will have caused the current state in testing to be bad
> already. If that's not the case, and it's really postgresql-12 related,
> how do you propose we treat the situation?

Fwiw, I believe the situation is as follows: libpq5 didn't break ABI,
so the existing postgresql-11-repmgr packages are fine, both in
testing and in unstable.

What did change however is that some API juggling happened, which
means repmgr needs to be updated to cope with mixed PostgreSQL
versions in postgresql-server-dev-11 and libpq-dev 12.

Unfortunately repmgr's autopkgtest is marked "build-needed" so we get
to see the API problem, while there's no actual problem with the
binaries. I've pushed a change to git to fix that.

Christoph

Bug#941078: transition: postgresql-12

[Christoph Berg]

Re: Paul Gevers 2019-10-13 
> The migration is currently blocked on the regression of repmgr. I just
> triggered a reference run as I think the postgresql-11 migration in the
> perl transition will have caused the current state in testing to be bad
> already. If that's not the case, and it's really postgresql-12 related,
> how do you propose we treat the situation?

Marco said there would be a new repmgr release tomorrow. That can
transition to testing independently first, and then PG12 will be good
to go.

Christoph

Bug#941078: transition: postgresql-12

[Paul Gevers]

Hi Christoph,

On 13-10-2019 12:04, Christoph Berg wrote:
> Re: Emilio Pozuelo Monfort 2019-10-12 
> <09c44ee4-1bee-bc9a-43fd-64fbbdf5c...@debian.org>
>> Go ahead.
> 
> Thanks. We'll start as soon as postgresql-12 is in testing to minimize
> any possible entanglement with other transitions.

The migration is currently blocked on the regression of repmgr. I just
triggered a reference run as I think the postgresql-11 migration in the
perl transition will have caused the current state in testing to be bad
already. If that's not the case, and it's really postgresql-12 related,
how do you propose we treat the situation?

Paul
PS: I am aware of the discussion on IRC, but the outcome for
postgresql-12 isn't clear to me and I like it to be logged in this bug.



signature.asc
Description: OpenPGP digital signature

Bug#912495: pydxcluster: Please migrate to python3-pygame

[Christoph Berg]

Re: Reiner Herrmann 2019-08-03 <20190803154842.l3yldt4xzh5vf...@reiner-h.de>
> I attached a patch that ports pydxcluster to Python 3.
> Though I did some testing with the UI, I'm not very familiar
> with the program. It would be good if someone could verify
> the functionality before applying+uploading the patch (especially
> the network functionality which I could not test at all).

Thanks for the patch!

I applied it in git, but noticed that the telnetlib part needs a lot
more attention because it expects to work with bytes instead of str.
I poked around a bit with it, but it's not properly working yet.
Notably, the telnet window scrolls past at around 3 lines per second,
even with no actual traffic.

I pushed the changes to a "python3" branch, but someone with more
python3 fu needs to finish that.

Christoph

Bug#942200: [Pkg-javascript-devel] Bug#942200: Bug#942200: rollup 1.0 transition: node-d3 built with rollup 1.0 gives error in test

[Xavier]

Thanks a lot for your work !

Le 13 octobre 2019 17:02:20 GMT+02:00, Pirate Praveen 
 a écrit :
>
>
>On Sun, Oct 13, 2019 at 20:15, Pirate Praveen 
> wrote:
>> This seems like a bug in rollup 1.0.2. Using with rollup 1.0.2 in 
>> package.json, npm i; npm run test also fails. Works fine with rollup 
>> 1.8.
>
>Now trying to update to 1.10.1 (which also works).
>
>Found debian/nodejs/./build
>   cd ./. && sh -e debian/nodejs/./build
>src/Module.ts:5:34 - error TS2307: Cannot find module 
>'rollup-pluginutils/src/extractAssignedNames'.
>
>5 import extractAssignedNames from 
>'rollup-pluginutils/src/extractAssignedNames';
>   
>~
>
>src/watch/index.ts:4:26 - error TS2307: Cannot find module 
>'rollup-pluginutils/src/createFilter'.
>
>4 import createFilter from 'rollup-pluginutils/src/createFilter';
>   ~
>
>
>Found 4 errors.
>
>We'll need to update node-rollup-pluginutils to 2.6 and drop src_babel 
>generation as tsc can consume ES module directly. I'm going to try this
>
>tomorrow.

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#942277: vim: Please consider replacing dh_install --list-missing with dh_missing --list-missing

[Boyuan Yang]

Source: vim
Version: 2:8.1.2136-1
Severity: minor

Dear vim maintainer,

For debian/rules file, the "--list-missing" option in dh_install(1) has been
deprecated in debhelper compat v11 and will be removed in debhelper compat
v12. Please consider using "dh_missing --list-missing" instead.

Best,
Boyuan Yang


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

Bug#942276: libmessage-passing-perl: test failure

[gregor herrmann]

Source: libmessage-passing-perl
Version: 0.116-4
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As seen on 
https://ci.debian.net/data/autopkgtest/unstable/amd64/libm/libmessage-passing-perl/3150247/log.gz
we have a test failure which also happens at build time and makes the
package FTBFS:

t/configfile.t .. 
ok 1 - use Message::Passing;
Can't locate object method "_options_prog_name" via package "Message::Passing" 
at /usr/share/perl5/MooX/Options/Role.pm line 348.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 25 just after 1.
Dubious, test returned 25 (wstat 6400, 0x1900)
All 1 subtests passed 


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl2jWdFfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgapGA//UnAloNglGDbKd6YCFqojZkoe690l2Nxkiv9g2Y1vnGxVD+X8kU3jaWb8
btnYiy2j5IUG6hfZkrK8beDaB9zozu3/UOg/QgARYI+n2WXnqhufNqS7XRBrmg6e
RupIB5Yi/c3lmPzzW2rNG7QyjudvjeoncNX05uxGK98tS7Rv9cGyVOLB3AHBnxPD
/WkQPtJu0myhOF0SrQMZ2mzbw5+JQlXAUNs3bi20mDP6YG5ISJB108cOnFe6lfRt
OX8Gwl0ZeHLeoVrbqo9wOVtDxU4qtFJH4v6hItM7271NpFv76PDEpdhIGi1xsTx3
51uH/lLvfSuKV5xKCb2RevgG8q5JCqzXoqtov0JOtu7eO8kGCCOOLAUvlDtjyW7i
zZlxj/Z2IhPUwvG1xitMGMu2/t37jXfRxoSTW532RlHrMf2UqOxlv9wgY/ygexwT
arzWOvGX5fFfiHuyULYiP7Fxis/5KttCd2wnICe+I8u9dVURlFWRSUDnoQ1PC9my
fw8KNF7/J9a+LkrHsb3rFwEVzDy8sizAimYnJyuz63SeEzBnnavEuFLLsmf6Bqdw
akeXO28zlwN3PC8RlkrOmPzZPH+F1wuC+L6SzTH2A97fG8eKlogkczs8UXSA5PsI
IEynKsJPZSbEUz/tRNJUPuE5v63vLK2scganIuXGwMoj+KDOeGE=
=Yfoi
-END PGP SIGNATURE-

Bug#932456: (no subject)

[Robert Niederreiter]

Hi,

I encountered the same problem.

It looks like libvirt denies write access to guest base image by 
modifying the guest related apparmor profile once the guest runs on a 
snapshot referring to this base image.


Here's what i tried:

Guest runs on base image:

root@host/storage/vm# virsh domblklist test
 Target   Source

 vda  /storage/vm/test.img

Generated aa profile not contains deny rule for base image:

root@host/storage/vm# cat /etc/apparmor.d/libvirt/libvirt-.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
  "/var/log/libvirt/**/test.log" w,
  "/var/lib/libvirt/qemu/domain-test/monitor.sock" rw,
  "/var/lib/libvirt/qemu/domain-8-test/*" rw,
  "/var/run/libvirt/**/test.pid" rwk,
  "/run/libvirt/**/test.pid" rwk,
  "/var/run/libvirt/**/*.tunnelmigrate.dest.test" rw,
  "/run/libvirt/**/*.tunnelmigrate.dest.test" rw,
  "/storage/vm/test.img" rwk,  <---
  "/dev/vhost-net" rw,
  "/var/lib/libvirt/qemu/domain-8-test/{,**}" rwk,
  "/var/lib/libvirt/qemu/channel/target/domain-8-test/{,**}" rwk,
  "/var/lib/libvirt/qemu/domain-8-test/master-key.aes" rwk,
  "/dev/net/tun" rwk,

After generating the snapshot, there's still no deny rule (but we also not 
tried to merge back to base image yet):

root@host/storage/vm# virsh snapshot-create-as --domain test --name 
backup_overlay --no-metadata --atomic --disk-only --diskspec 
vda,snapshot=external
Domain snapshot backup_overlay created

root@host/storage/vm# cat /etc/apparmor.d/libvirt/libvirt-.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
  "/var/log/libvirt/**/test.log" w,
  "/var/lib/libvirt/qemu/domain-test/monitor.sock" rw,
  "/var/lib/libvirt/qemu/domain-8-test/*" rw,
  "/var/run/libvirt/**/test.pid" rwk,
  "/run/libvirt/**/test.pid" rwk,
  "/var/run/libvirt/**/*.tunnelmigrate.dest.test" rw,
  "/run/libvirt/**/*.tunnelmigrate.dest.test" rw,
  "/storage/vm/test.img" rwk,  <---
  "/dev/pts/2" rw,
  "/dev/pts/2" rw,
  
"/var/lib/libvirt/qemu/channel/target/domain-8-test/org.qemu.guest_agent.0" rw,
  "/dev/vhost-net" rw,
  "/storage/vm/test.backup_overlay" rwk,

When shutting down and starting guest again, host specific aa profile gets 
regenerated.
Now the deny rule is present. Note that guest runs on snapshot:

root@host/storage/vm# virsh domblklist test
 Target   Source
---
 vda  /storage/vm/test.backup_overlay

root@host/storage/vm# virsh shutdown test
Domain test is being shutdown

root@host/storage/vm# virsh start test
Domain test started

root@host/storage/vm# cat /etc/apparmor.d/libvirt/libvirt-.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
  ...
  "/storage/vm/test.img" rk,   <---
  # don't audit writes to readonly files
  deny "/storage/vm/test.img" w,  <
  "/dev/vhost-net" rw,
  ...

And it seems like this rule prevents us from merging snapshot back to base 
image:

root@host/storage/vm# virsh blockcommit test vda --active --pivoterror: 
internal error: unable to execute QEMU command 'block-commit': Could not reopen 
file: Permission denied

As soon as the guest aa profile gets disabled, blockcommit works as expected:

root@host/storage/vm# aa-disable /etc/apparmor.d/libvirt/libvirt-
Disabling /etc/apparmor.d/libvirt/libvirt-.

root@host/storage/vm# virsh blockcommit test vda --active --pivot
Successfully pivoted

After merge, stop and start guest, the deny rule is gone again:

root@host/storage/vm# virsh shutdown test
Domain test is being shutdown

root@host/storage/vm# virsh start test
Domain test started

root@host/storage/vm# cat /etc/apparmor.d/libvirt/libvirt-.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
  ...
  "/storage/vm/test.img" rwk,
  "/dev/vhost-net" rw,
  ...

root@host/storage/vm# virsh domblklist test
 Target   Source

 vda  /storage/vm/test.img

As stated above, the deny rule is not created immediately when creating the 
snapshot
if guest not gets stopped/started. But it gets added as soon as we try to merge 
back
to the base image:

root@host/storage/vm# virsh snapshot-create-as --domain test --name 
backup_overlay --no-metadata --atomic --disk-only --diskspec 
vda,snapshot=external
Domain snapshot backup_overlay created

root@host/storage/vm# cat /etc/apparmor.d/libvirt/libvirt-.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
  ...
  "/storage/vm/test.img" rwk,
  ...

root@host/storage/vm# virsh blockcommit test vda --active --pivoterror: 
internal error: 

Bug#942275: libmoox-options-perl: test failure

[gregor herrmann]

On Sun, 13 Oct 2019 19:01:19 +0200, gregor herrmann wrote:

> Currently this only happens in unstable, and I haven't yet seen why.

Maybe yesterday's upload of libnamespace-autoclean-perl?


Cheers,
gregor
-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Peter Ratzenbeck: Bonnie Bessie Logan


signature.asc
Description: Digital Signature

Bug#942275: libmoox-options-perl: test failure

[gregor herrmann]

Source: libmoox-options-perl
Version: 4.103-1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As first seen on ci.debian.net, libmoox-options-perl has a test
failure which also makes the package FTBFS:

https://ci.debian.net/data/autopkgtest/unstable/amd64/libm/libmoox-options-perl/3150674/log.gz

t/16-namespace_clean.t .. 
ok 1 - TestNamespaceClean is a package
Can't locate object method "__" via package "TestNamespaceClean" at 
/usr/share/perl5/MooX/Options/Role.pm line 352.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 1.
Dubious, test returned 255 (wstat 65280, 0xff00)
All 1 subtests passed 


Currently this only happens in unstable, and I haven't yet seen why.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl2jWF9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYIqw//XGnU4dpmTGHf/zNwzGrxbtXxwtCws0FycziVOMyibaHrsSnfWo1z4q9x
S2l9SRolRx6QdzS0iXdege9Ay0tqAvE+ae6lGkHsb6zg8fe1oGGkh8B35TMx6U0j
jhjjtJU0iruB0mMr783TKH/4kWlAOfTprq6C0MPbiJ5WBm3v+sCe2JArfKIJhcW6
GheUF+lH2zsXR9u6AcZK5uOlxo/Bjawak6akbxbNfPxxcpOWKmUz9V1h8iaElim6
qqgiAJRXMDty0+tNP3tYYK4ta4cwUzj2cGevfBIBlNYhUMsK7sRlLjO2Rb6e22mU
wwr5HGcEjkr1o//h7wZ1bYU/yK5GDtrw0lnbluG9qHu1cO0kIYF0Cut8wTWisw9q
aPYau5b6xE+70swsRiArrA3UPrmWKgUK2lRhZC1MVzpakFT01uaINwaMyCL606bG
jB4/g7+BbKmLCyTSOx0uWaRIG5KgtFQTm8Dm7agjQdsLVMTmOXzRQi7saP0slHCT
ak80F2h4LY3PtlNWK9+T1RBHkC0FaZxOqWVEVUVXC+U4kSQzF8F5ir8NwiDPKr1E
+kYXOdecvcKw1nC+SKQIJLrAt2ibTjogd33v5QXIjRNd+/lHtZeHANV5m5TeNqWK
uNEo2qrVys+d2RAWBjvboxJgtW7K24cMnUTYIw6C9kc2UJc7/K4=
=vx9q
-END PGP SIGNATURE-

Bug#942262: transition: x265

[Sebastian Ramacher]

On 2019-10-13 14:28:32, Emilio Pozuelo Monfort wrote:
> On 13/10/2019 13:47, Sebastian Ramacher wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/auto-x265.html
> > 
> > x265 bumped its SONAME to 179 and the new upstream release is staged in
> > experimental. All reverse dependencies build fine against the new
> > version.
> 
> If the package builds fine in the remaining release architectures (I have just
> bumped the build prio) you can go ahead.

It built everywhere, so I've uploaded it to unstable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#942274: uscan: handling several levels of http links

[Samuel Thibault]

Package: devscripts
Version: 2.19.6
Severity: wishlist

Hello,

For the hwloc package, there is on single webpage that references all
releases.

For instance,
https://www.open-mpi.org/projects/hwloc/

points at both
https://www-lb.open-mpi.org/software/hwloc/v2.1/
https://www-lb.open-mpi.org/software/hwloc/v2.0/

And those do provide links to the files. I had hardcoded the
https://www-lb.open-mpi.org/software/hwloc/v2.0/ in debian/watch, but
that doesn't catch the 2.1 release of course.

I tried something  like

https://www.open-mpi.org/software/hwloc/ \
https://www-lb.open-mpi.org/software/hwloc/(v[\d\.]+)/ \
https://download.open-mpi.org/release/hwloc/(v[\d\.]+)/hwloc(?:[_\-]v?|)@ANY_VERSION@@ARCHIVE_EXT@

But this doesn't seem supported. Am I missing something or is handling
several levels of http links not supported?

Samuel

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID="0xDB550E89F0FA54F3!"
DEBCHANGE_AUTO_NMU=no
DEBSIGN_PROGRAM="gpg --use-agent"

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

Kernel: Linux 5.3.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev   1.19.7
ii  fakeroot   1.24-1
ii  file   1:5.37-5
ii  gnupg  2.2.17-3
ii  gnupg2 2.2.17-3
ii  gpgv   2.2.17-3
ii  libc6  2.29-2
ii  libfile-homedir-perl   1.004-1
ii  libfile-which-perl 1.23-1
ii  libipc-run-perl20180523.0-1
ii  libmoo-perl2.003004-2
ii  libstring-shellquote-perl  1.04-1
ii  libwww-perl6.39-1
ii  patchutils 0.3.4-2+b1
ii  perl   5.28.1-6
ii  python33.7.5-1
ii  sensible-utils 0.0.12
ii  wdiff  1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.4
ii  at  3.1.23-1+b1
ii  curl7.66.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2019.09.24
ii  dput-ng [dput]  1.28
ii  dupload 2.9.4
ii  equivs  2.2.0
ii  libdistro-info-perl 0.22
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.22-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.25.0
ii  man-db  2.8.7-3
ii  patch   2.7.6-6
ii  python3-apt 1.8.4
ii  python3-debian  0.1.36
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-25
ii  wget1.20.3-1+b1
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
ii  autopkgtest  5.11
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1+b1
ii  build-essential  12.8
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.6.1
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
ii  duck 0.13
ii  faketime 0.9.7-3
ii  gnuplot  5.2.7+dfsg1-5
ii  gnuplot-x11 [gnuplot]5.2.7+dfsg1-5
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
ii  libdbd-pg-perl   3.10.0-1
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
ii  libyaml-syck-perl1.31-1+b1
ii  mailutils [mailx]

Bug#934134: seabios: Unable to install FreeDOS

[Harald Welte]

I can confirm this problem.  It also happens here, when trying to install
FreeDOS 1.2 from CDROM on debian unstable (seabios 1.12.0-1)
-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#942273: drkonqi: I keep getting "drkonqi Closed Unexpectedly" messages every 30 seconds or so

[Gary Dale]

Package: drkonqi
Version: 5.14.5-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
this has been happening for last few days. I full-updgrade every day so that 
probably 
triggered it.

   * What exactly did you do (or not do) that was effective (or ineffective)?
I don't know what drkonqi does but it doesn't seem to impact my system other 
than 
continually throwing up annoying messages

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages drkonqi depends on:
ii  kio   5.62.1-1
ii  libc6 2.29-2
ii  libkf5completion5 5.62.0-1
ii  libkf5configcore5 5.62.0-1
ii  libkf5configgui5  5.62.0-1
ii  libkf5configwidgets5  5.62.0-1
ii  libkf5coreaddons5 5.62.0-1
ii  libkf5crash5  5.62.0-1
ii  libkf5i18n5   5.62.0-1
ii  libkf5idletime5   5.62.0-1
ii  libkf5jobwidgets5 5.62.0-1
ii  libkf5kiocore55.62.1-1
ii  libkf5notifications5  5.62.0-1
ii  libkf5service-bin 5.62.0-1
ii  libkf5service55.62.0-1
ii  libkf5wallet-bin  5.62.0-1
ii  libkf5wallet5 5.62.0-1
ii  libkf5widgetsaddons5  5.62.0-1
ii  libkf5xmlrpcclient5   5.62.0-1
ii  libqt5core5a  5.11.3+dfsg1-4
ii  libqt5dbus5   5.11.3+dfsg1-4
ii  libqt5gui55.11.3+dfsg1-4
ii  libqt5widgets55.11.3+dfsg1-4
ii  libqt5x11extras5  5.11.3-2
ii  libqt5xml55.11.3+dfsg1-4
ii  libstdc++69.2.1-8

drkonqi recommends no packages.

drkonqi suggests no packages.

-- no debconf information

Bug#942272: gnome-shell: numlock state is reversed

[EdiD]

Package: gnome-shell
Version: 3.34.0-2
Severity: normal

Numlock state is reversed after system boot

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  evolution-data-server3.34.1-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.34.0-3
ii  gir1.2-freedesktop   1.62.0-2
ii  gir1.2-gcr-3 3.33.4-2
ii  gir1.2-gdesktopenums-3.0 3.34.0-2
ii  gir1.2-gdm-1.0   3.34.1-1
ii  gir1.2-geoclue-2.0   2.5.5-1
ii  gir1.2-glib-2.0  1.62.0-2
ii  gir1.2-gnomebluetooth-1.03.34.0-1
ii  gir1.2-gnomedesktop-3.0  3.34.0-2
ii  gir1.2-gtk-3.0   3.24.12-1
ii  gir1.2-gweather-3.0  3.28.3-2
ii  gir1.2-ibus-1.0  1.5.19-4+b1
ii  gir1.2-mutter-5  3.34.0-4
ii  gir1.2-nm-1.01.20.4-2
ii  gir1.2-nma-1.0   1.8.22-2
ii  gir1.2-pango-1.0 1.42.4-7
ii  gir1.2-polkit-1.00.105-26
ii  gir1.2-rsvg-2.0  2.44.14-1
ii  gir1.2-soup-2.4  2.68.1-2
ii  gir1.2-upowerglib-1.00.99.11-1
ii  gjs  1.58.1-1
ii  gnome-backgrounds3.34.0-1
ii  gnome-settings-daemon3.34.0-3
ii  gnome-shell-common   3.34.0-2
ii  gsettings-desktop-schemas3.34.0-2
ii  libatk-bridge2.0-0   2.34.1-1
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libcroco30.6.13-1
ii  libecal-2.0-13.34.1-1
ii  libedataserver-1.2-243.34.1-1
ii  libgcr-base-3-1  3.33.4-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libgirepository-1.0-11.62.0-2
ii  libgjs0g 1.58.1-1
ii  libgles2 1.1.0-1+b1
ii  libglib2.0-0 2.62.1-1
ii  libglib2.0-bin   2.62.1-1
ii  libgnome-autoar-0-0  0.2.3-2
ii  libgstreamer1.0-01.16.1-1
ii  libgtk-3-0   3.24.12-1
ii  libical3 3.0.5-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-5-03.34.0-4
ii  libnm0   1.20.4-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpolkit-agent-1-0  0.105-26
ii  libpolkit-gobject-1-00.105-26
ii  libpulse-mainloop-glib0  13.0-2
ii  libpulse013.0-2
ii  libsecret-1-00.19.1-1
ii  libsystemd0  242-7
ii  libwayland-server0   1.17.0-1
ii  libx11-6 2:1.6.8-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.34.0-4
ii  python3  3.7.5-1

Versions of packages gnome-shell recommends:
ii  bolt  0.8-4
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.34.1-1
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.34.1-1
ii  gnome-user-docs   3.34.0-2
ii  ibus  1.5.19-4+b1
ii  iio-sensor-proxy  2.4-2+b1
ii  switcheroo-control1.3.1-2
ii  unzip 6.0-25

Versions of packages gnome-shell suggests:
pn  gir1.2-telepathyglib-0.12   
pn  gir1.2-telepathylogger-0.2  

Versions of packages gnome-session depends on:
ii  gnome-session-bin  3.34.1-1
ii  gnome-session-common   3.34.1-1
ii  gnome-settings-daemon  3.34.0-3

Versions of packages gnome-session suggests:
ii  desktop-base   10.0.3
ii  gnome-keyring  3.34.0-1

Bug#942053: dh-runit: generates dangling symlinks

[Dmitry Bogatov]

[2019-10-09 18:01] Sven Joachim 
> Package: dh-runit
> Version: 2.8.14
>
> The fix for bug #934500 has the side effect of introducing broken
> symlinks[1] into packages using it, causing complaints by tools that
> report such oddities, e.g. adequate(1) or symlinks(1):

As I recall, dangling symlink is not violation of Policy (correct me if
I am wrong), so the best route is to teach these tools about this
special case, like we teach lintian.

So, I think adequate(1) need to be patched. Something else?

> I find that quite annoying.

Sorry, this is not enough. Debian strives to be universal operating
system, and pays the price for it: on every system there is something
that is not needed for how this system is used.

You can use dpkg-exclude to alleviate this particular issue somewhat.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#941924: runit-helper: Remove log directory on purge

[Dmitry Bogatov]

control: tags -1 +pending

[2019-10-07 17:50] Lorenzo Puliti 
> Hi,

Hi,

> I think runit-helper should remove log directories when
> called with purge. See Debian Policy 10.8.
> Patch attached.

Yes, this is true. Thank you. Applied in git, not uploading yet due perl
transition.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#556893: #556893,say which 'defaults' are which better

[Dmitry Bogatov]

control: reassign -1 init-system-helpers
control: tags -1 +patch

[2019-09-28 15:21] Jesse Smith 
> This has been addressed upstream in insserv by allowing the program to
> accept changes like this silently. All we need now is for update-rc.d to
> be updated to use the new behaviour (enabled with the -q flag) and this
> issue can be closed.

Thank you for bug triaging, Jesse. Reassigning back to
init-system-helpers.

Dear init-system-helpers maintainer, please consider applying following
patch:

From 638717158f50fa24a119b69ee0888158d306f492 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sat, 12 Oct 2019 13:55:45 +
Subject: [PATCH] Prevent insserv(8) from printing too much debug

Closes: #556893
---
 script/update-rc.d | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/script/update-rc.d b/script/update-rc.d
index 71fb1a6..03d21cf 100755
--- a/script/update-rc.d
+++ b/script/update-rc.d
@@ -181,7 +181,7 @@ sub create_sequence {
 $insserv = "/sbin/insserv" if ( -x "/sbin/insserv");
 # If insserv is not configured it is not fully installed
 my $insserv_installed = -x $insserv && -e "/etc/insserv.conf";
-my @opts;
+my @opts = ('--silent');
 push(@opts, '-f') if $force;
 # Add force flag if initscripts is not installed
 # This enables inistcripts-less systems to not fail when a facility is 
missing


-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#935042: Program phones home by default

[Birger Schacht]

Hi,

On 8/18/19 3:21 PM, Robie Basak wrote:
> Package: lynis
> Version: 2.6.2-1
> Severity: serious

https://www.debian.org/Bugs/Developer#severities says:
> serious is a severe violation of Debian policy (roughly, it violates a
> "must" or "required" directive)"

Robie, could you please point out the part of the Debian policy that
this package is violating?

thanks,
Birger

Bug#942271: RM: darcsweb -- RoQA; depends on Python 2, unmaintained, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove darcsweb. It's dead upstream, unmaintained (last maintainer upload
in 2010) and depends on Python 2.

Cheers,
Moritz

Bug#942270: task-spanish depends on removed manpages-es

[Moritz Muehlenhoff]

Source: tasksel
Severity: grave

task-spanish depends on manpages-es, which has been removed from the archive.

Cheers,
Moritz