Bug#905324: please provide badges for upsteam documentation

[Picca Frédéric-Emmanuel]

Source: autodeb
Severity: wishlist

Hello,

I do not know if this is the right place to report this but I will do it :). 
First a big thanks for this project to all the team involved.


It seesm to me that it would be a great addition for autodeb (and Debian) to 
propose a badge which could be added to the documentation of the website of the 
upstreams (Opt-In). this way upsteam would 
have a direct feedback that something is ok or not in their last release. They 
could try to fix it by themself when possible. (like they do with another well 
known multi system distribution).

thanks for considering

Frederic

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

Kernel: Linux 4.17.0-1-686 (SMP w/1 CPU core)
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)
LSM: AppArmor: enabled

Bug#905323: dgit-maint-debrebase(7): suggests that mixed commits are bad

[Sean Whitton]

Package: dgit
Version: 6.4
Severity: minor

The manpage encourages separating into different commits changes to the
upstream source and changes to the debian/ directory.  In fact, a
git-debrebase splits these up, so the manpage need not imply that the
user has to think so carefully about what goes into their commits.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#905322: git-debrebase: want convert-from-dgit-view subcommand

[Sean Whitton]

Package: git-debrebase
Version: 6.4
X-debbugs-cc: jcowg...@debian.org

Hello,

As discussed just now, git-debrebase should have a
'convert-from-dgit-view' subcommand.  By this I mean a subcommand that
converts from a non-git-debrebase patches-applied view, to a
git-debrebase view.

Uses:

1) Starting to use git-debrebase on an existing package that has no
   existing git history, or whose git history you want to throw away, or
   where you just want to do some work in a stable release suite for a
   stable update, while ignoring the maintainer git history.

   dgit-maint-debrebase(7) says you can just `dgit clone`, but in fact
   that is not enough.

2) Switching from dgit-maint-merge(7) to dgit-maint-debrebase(7) (the
   other direction is easy).

   A package might start off suitable for the dgit-maint-merge(7)
   workflow but then the number of patches not upstreamable might grow
   to the point that git-debrebase would be more useful.

   You'd run convert-from-dgit-view and this would give you a single
   entry in the delta queue, which you'd then split up using a
   debrebase.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#905314: snapper-gui: Please clarify why you disable the testsuite

[Ritesh Raj Sarraf]

On Fri, 2018-08-03 at 04:26 +0100, Chris Lamb wrote:
> I just ACCEPTed snapper-gui from NEW but was wondering if you could
> clarify (in the package itself) why you disable the testsuite.

Thank you for the quick response on the ftp queue.

I don't have the exact logs right now, but IIRC it was depending on the
dbus service.

When I'm back to my build machines, I'll dig it up. I also need to
teach myself to write more descriptive commit messages.

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

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

Bug#905321: linux-image-4.17.0-1-amd64: Screen flicker

[Sten Heinze]

Package: src:linux
Version: 4.17.8-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

apt upgrade installed linux 4.17 and booting the new kernel.

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

Neither previous kernel versions (mostly 4.15 and before; I have not used 4.16 
as much because it causes the X start to be delayed) nor Windows has this 
problem.

I was trying to see if anything is in the logs and some flickers seems to
coincide with the following kernel log message:

Aug 03 01:27:46 box kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] 
*ERROR* CPU pipe A FIFO underrun

However, most of the flickers do not (not with this or any other message that 
I can see in journalctl.)

   * What was the outcome of this action?

Screen flickering in X. Every few seconds (seems to depend how active I use 
the system) for a fraction of a second.

   * What outcome did you expect instead?

No flickering as before.

Please let me know if I can provide any other information, logs, video 
recording, etc.

-- Package-specific info:
** Version:
Linux version 4.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-26)) #1 SMP Debian 4.17.8-1 (2018-07-20)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.17.0-1-amd64 
root=UUID=822f5786-fcce-4563-ada9-f9c9d684742e ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: HP
product_name: HP EliteBook Folio G1
product_version: 
chassis_vendor: HP
chassis_version: 
bios_vendor: HP
bios_version: N91 Ver. 01.24
board_vendor: HP
board_name: 8170
board_version: KBC Version 29.70

** Loaded modules:
ctr
ccm
cmac
rfcomm
bnep
nls_ascii
nls_cp437
vfat
fat
arc4
btusb
btrtl
btbcm
btintel
snd_hda_codec_hdmi
intel_rapl
snd_hda_codec_conexant
bluetooth
x86_pkg_temp_thermal
intel_powerclamp
coretemp
snd_hda_codec_generic
kvm_intel
hp_wmi
wmi_bmof
jitterentropy_rng
snd_soc_skl
snd_soc_skl_ipc
efi_pstore
snd_hda_ext_core
snd_soc_sst_dsp
kvm
snd_soc_sst_ipc
snd_soc_acpi
irqbypass
snd_soc_core
snd_compress
crct10dif_pclmul
crc32_pclmul
iwlmvm
ghash_clmulni_intel
intel_cstate
snd_hda_intel
intel_uncore
snd_hda_codec
intel_rapl_perf
mac80211
serio_raw
snd_hda_core
pcspkr
efivars
snd_hwdep
drbg
iwlwifi
i915
snd_pcm
ansi_cprng
snd_timer
uvcvideo
videobuf2_vmalloc
videobuf2_memops
iTCO_wdt
iTCO_vendor_support
videobuf2_v4l2
drm_kms_helper
snd
soundcore
videobuf2_common
cfg80211
videodev
evdev
media
ecdh_generic
joydev
rfkill
mei_me
crc16
mei
idma64
shpchp
intel_pch_thermal
drm
i2c_algo_bit
processor_thermal_device
battery
wmi
intel_soc_dts_iosf
tpm_crb
int3403_thermal
int340x_thermal_zone
soc_button_array
tpm_tis
video
tpm_tis_core
tpm
int3400_thermal
rng_core
acpi_thermal_rel
intel_hid
sparse_keymap
button
acpi_pad
hp_wireless
ac
efivarfs
ip_tables
x_tables
autofs4
btrfs
xor
zstd_decompress
zstd_compress
xxhash
raid6_pq
libcrc32c
crc32c_generic
crc32c_intel
hid_alps
hid_generic
aesni_intel
aes_x86_64
crypto_simd
cryptd
glue_helper
psmouse
xhci_pci
nvme
xhci_hcd
i2c_i801
nvme_core
intel_lpss_pci
usbcore
intel_lpss
usb_common
i2c_hid
thermal
hid

** Network interface configuration:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# shz, added 01.01.2018, commented 02.01.2018
#iface wlp109s0 inet dhcp
#   wpa-ssid WooAlum
#   wpa-psk 2743acc9675072f716d232a3721c0e8d5fdaf71de11b3a85767dac1601a42210
#

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: wlp109s0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether a0:c5:89:21:5e:b2 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.103/24 brd 192.168.0.255 scope global dynamic noprefixroute 
wlp109s0
   valid_lft 85937sec preferred_lft 85937sec
inet6 fe80::ec5c:f6ba:937a:f66b/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:   15416 196000 0  0 015416 
196000 0   0  0
wlp109s0: 12250992529000 0  0 0   339285
1443000 0   0  0


** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Skylake 

Bug#905279: git-debrebase: 'dgit clone ' followed by "cd ; git debrebase" fails

[Sean Whitton]

control: tag -1 +moreinfo

Hello,

On Thu 02 Aug 2018 at 03:47PM +0200, Ruben Undheim wrote:

> Hi,
>
> Try to run:
>
>   dgit clone 
>
> then followed by
>
>   cd 
>   git debrebase
>
> for a  which has not been used together with dgit earlier.

This is not expected to work.  Could you explain what you were trying to
achieve, please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#905167: debmake-doc: Handling Upstream Autotools Packaging on Debian

[Paul Hardy]

On Thu, Aug 2, 2018 at 9:14 AM, Osamu Aoki  wrote:
> Hi,
>
> Thank you for your very detailed review.

I realized when I wrote it that it was probably _too much_ detail (I
tried to keep everything on one screen but went a little past that).
I figured I would get all my thoughts down for others to pick and
choose what they wanted to use.

> On Tue, Jul 31, 2018 at 11:12:12PM -0700, Paul Hardy wrote:
>> Package: debmake-doc
>> Version: 1.9-1
>> Tags: patch
>>
>> Section 5.16.1 recommends running autoreconf when building a package
> ...
> Let's add:
> | For compat level 10 or newer, the simple “dh $@” command without
> | "--with autoreconf" option can take care all steps 1 to 4, too.
>
>> That
>> brings with it considerations about automake.  The default
>> "strictness" level of an automake setup is the "gnu" level, which
>> requires files AUTHORS, ChangeLog, INSTALL, NEWS, and README along
>> with the Makefile.am and configure.ac files that autoreconf will
>> expect.  That then brings other implications for using such a package
>> on Debian.
>
> Hmmm I had a different thought and intentionally chose "foreign".
>
>> Elsewhere, the document refers to the GNU Coding Standards, which is
>> further reason to make mention of the above files, and which get
>> installed and which do not get installed (COPYING and INSTALL) on
>> Debian.
>
> This tutorial is about packaging an upstream source ... not about
> creating an upstream source to be uploaded to the GNU project.

Yes.  I brought up the "gnu" strictness level for automake because the
_Guide for Debian Maintainers_ already refers the reader to consult
the GNU Coding Standards.  It was not with a goal of packaging for the
GNU Project.  Maybe that is going too far though.

> I also find many packages on Debian uses "foreign".  Upstream source on
> git may not have NEWS and ChangeLog.  So making simpler example is good
> for entry level document.  Another POV I checked is:
>
>   https://autotools.io/automake/options.html#automake.options.flavors
>
>> I propose that wording like what follows be considered for the end of
>> Section 8.9 or 8.11.  Both of those examples set the automake
>
> I think adding a short pointer to remind automake defaults to gnu flavor
> may be a good idea around Section 8.9.  But I don't think I should
> elaborate too much in detail.  If we do so, this tutorial get bloated
> and reader will lose important things to learn about the Debian
> packaging.
>
> After "configure.ac (v=1.6): " example, add:
> 
> TIP: Without "foreign" strictness level specified in AM_INIT_AUTOMAKE()
> as above, automake defaults to "gnu" strictness level requiring several
> files in the top-level directory.  See "3.2 Strictness" in the automake
> document.
> 
>
>> The other files besides Makefile.am and configure.ac that Autotools
>> expects in the top-level directory (AUTHORS, NEWS, README, and
>> ChangeLog) can be installed in /usr/share/doc/.
>
> This is fair point to be reminded.  Place to do is at:
>   5.12. Customization of the Debian packaging
>
> Now:
> 
> * The Debian package build system can be customized through the
>   debian/rules file (see Section 5.4.3, “Customized debian/rules”).
>
> * The Debian package installation path etc. can be customized through
>   the addition of configuration files in the debian/ directory for the
>   dh_* commands from the debhelper package (see Section 5.11, “Other
>   debian/*”).
> 
>
> Proposed:
> 
> * The Debian package build system can be customized through the
>   debian/rules file (see Section 5.4.3, “Customized debian/rules”).
>
> * The Debian package installation path etc. can be customized through
>   the addition of configuration files such as "package.doc" and
>   "package.install" in the debian/ directory for the dh_* commands from
>   the debhelper package (see Section 5.11, “Other debian/*”).
> 

Sounds good.

>> Running "autoreconf -ivf"  as described in Section 5.16.1 will create
>> a new INSTALL file even if one existed.i
>
> As written there, this is run by the upstream.

Well, building in debian/rules with autoreconf will run that too.
Actually, I don't know if running automake with "foreign" strictness
re-creates INSTALL.  I have only tried automake with "gnu" strictness.

>>  That file will have a copyright,
>> as will the GPL or LGPL in the COPYING or COPYING.LESSER file.  Therefore,
>> list those files in the Files-Exclude field in the first paragraph of
>> debian/copyright.
>
> ??? What ???
>
> Files-Exclude field is for different purpose and effect.  Please check
> the uscan manpage and mk-origtargz manpage.

I realize that.  I should have said use Files-Exclude to handle the
case where uscan is downloading upstream files automatically.

>> One of the standard "make" targets that automake creates is "distcheck".
>
> Yes.  But I am not writing full tutorial on autotools.  Nor this test build
> target also exist on other upstream build system.
>
>> That builds a copy of 

Bug#905094: Grub2 boot card dead

[binnan hao]

Ok, thanks for the update.

Steve McIntyre  于2018年8月3日周五 下午12:17写道：

> On Fri, Aug 03, 2018 at 11:54:27AM +0800, binnan hao wrote:
> >How to cooperate with debugging?
>
> For now, disable secure boot. We'll be announcing shortly once we have
> everything ready.
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> Dance like no one's watching. Encrypt like everyone is.
>  - @torproject
>
>

-- 
*Hao Binnan*
*Isoo (Qinhuangdao) software development Co., Ltd. (China)*
http://www.eassos.com

PGP Public Key: 4096R/9EF21740 / 9678 1E8C B21E 1E60 3997  811D F83B B359
9EF2 1740
haobinnan 

Bug#904988: /bin/su does not set $PATH

[ian_bruce]

 wrote:

> I thought I (or something) had hosed my system, but it turns out this
> change is by design.

That was exactly my reaction. I don't think that it's acceptable to have
a major (unannounced) change in behaviour for an essential system
utility like "/bin/su".

some discussion here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833256#90

quote:

Debian would have to add "ALWAYS_SET_PATH yes" to "/etc/login.defs"
to preserve its current behavior.

current source code reference:

https://sources.debian.org/src/util-linux/2.32-0.3/login-utils/su-common.c/#L980

It seems that the previous behaviour can be restored, without source
code modifications, simply by changing a config file. That would seem to
be by far the best option.


-- Ian Bruce

Bug#904988: use "su -" (RTFM) Re: Bug#904988: (util-linux /bin/su $path is missing crucial dirs)

[Andreas Henriksson]

Hi Gijs Hillenius,

Thanks for your bug report. (Reply inline below.)

On Tue, Jul 31, 2018 at 09:18:06AM +0200, Gijs Hillenius wrote:
> 
> I thought I (or something) had hosed my system, but it turns out this
> change is by design. After reading more closely the changelog I read
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=90483
> 
> and
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833256
> 
> > To me this mostly seems like a(nother) case of "always use 'su -',
> > never su".

Yes, the difference between 'su' and 'su -' (aka 'su -l') is to
preserve environment or not. Generally preserving the environment of
a different user when switching is a really bad idea, so basically
you always want to do 'su -'.

You are correct though that the old (src:shadow) su would, even when
preserving environment, still alter it slightly. The PATH and IFS
environment variables where apparently always alterened even
when you specified 'preserve environment'.

Since I guess the difference between using 'su' and 'su -' is something
we'll keep repeating and teaching people for all eternity the difference
in behaviour is quite user visible and unfortunate. I'll make sure to
document it in the NEWS file atleast.

(FYI 
https://salsa.debian.org/debian/util-linux/commit/ce2bd4bd05f11af1b85ce8f5c4e52807671122ed
 )

If you notice any other differences, please report back so they can
be written down as well. (Merge requests even more welcome!)

> 
> 
> Feel free to close this bug, sorry for the noise.

As a bug submitter you're fully entitled to do so yourself and as
you already seems to be aware of just sending a mail to -done is
enough.

Regards,
Andreas Henriksson

Bug#905094: Grub2 boot card dead

[Steve McIntyre]

On Fri, Aug 03, 2018 at 11:54:27AM +0800, binnan hao wrote:
>How to cooperate with debugging?

For now, disable secure boot. We'll be announcing shortly once we have
everything ready.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Dance like no one's watching. Encrypt like everyone is.
 - @torproject

Bug#877711: Latest upstream firmware resolves this issue

[Tomasz Buchert]

On 24/10/17 14:41, Andrew McMillan wrote:
> Hi,
>
> I can confirm that Brian Tarricone's solution also works for me, and
> the latest firmware resolves the issue:
>
>
> I.e. this commit from the 9th October:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware
> .git/commit/ath10k/QCA6174/hw3.0?id=96a7402d4172f4786ee93dd9f7cb3f76e1a
> 8025e
>
> "Update from a new firmware branch. This also fixes a regression with
> ath10k frequently disconnecting."
>
>
> Thanks,
> Andrew McMillan.

If you don't want to do manual changes to your firmware files,
consider installing firmware-atheros from buster [1].

Tomasz

[1] https://packages.debian.org/buster/firmware-atheros


signature.asc
Description: PGP signature

Bug#905318: monitoring-plugins-common: $PATH_TO_SUDO is not set (required by check_mailq -s)

[Adam Bolte]

Package: monitoring-plugins-common
Version: 2.2-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I have a postfix installation where main.cf is configured like so:

-rw-r- 1 root root 2013 Aug  3 11:41 /etc/postfix/main.cf

This breaks mailq if executed without sudo, so I have icinga2 call
check_mail (from the monitoring-plugins-standard package) with
-s. This doesn't work since the check_mail script is actually unable
to call the sudo command.


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

This fixes the issue:

$ diff /usr/lib/nagios/plugins/utils.pm{.orig,}
20c20
< $PATH_TO_SUDO= "";
---
> $PATH_TO_SUDO= "/usr/bin/sudo";

Apparently the build system is supposed to take care of this
automatically.


   * What was the outcome of this action?

$ /usr/lib/nagios/plugins/check_mailq -s -w 4 -c 8 -M postfix -v
mailq: fatal: open /etc/postfix/main.cf: Permission denied
CRITICAL: Error code 75 returned from /usr/bin/mailq


   * What outcome did you expect instead?

$ /usr/lib/nagios/plugins/check_mailq -s -w 4 -c 8 -M postfix -v
OK: postfix mailq reports queue is empty|unsent=0;4;8;0

Hopefully it's a simple fix. Thanks for taking a look.

Regards,
Adam


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


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

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

Versions of packages monitoring-plugins-common depends on:
ii  libc6  2.24-11+deb9u3
ii  ucf3.0036

monitoring-plugins-common recommends no packages.

Versions of packages monitoring-plugins-common suggests:
pn  icinga | icinga2  

Bug#905316: maxima: printf hangs with format string, works in lisp mode

[Anders Andersson]

Package: maxima
Version: 5.41.0-3
Severity: normal

Dear Maintainer,

I wanted to format a list of integers in base 16, but the default output was
returned in mixed case for the letters A-F. When I added case-conversion to the
format string, maxima suddenly ends up in an infinite memory-consuming loop.
The exact same format string works in lisp within maxima.


Example:


This works as expected and prints the list as a comma-separated list of
hexadecimal integers in upper case:

> (%i1) :lisp (format t "~{0x~:@(~x~)~^, ~}~%" '(1000 2000 3000 4000) )
> 0x3E8, 0x7D0, 0xBB8, 0xFA0
> NIL
> (%i1)

while this hangs indefinitely (notice exact same string and values)

> (%i1) printf(true, "~{0x~:@(~x~)~^, ~}~%", [1000,2000,3000,4000] );


This started happening when I added the case conversion. If I remove it, the
output is as expected:

> (%i4) printf(true, "~{0x~x~^, ~}~%", [1000,2000,3000,4000] );
> 0x3E8, 0x7D0, 0xBB8, 0xFA0
> (%o4)false






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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
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)
LSM: AppArmor: enabled

Versions of packages maxima depends on:
ii  libc6 2.27-5
ii  libgmp10  2:6.1.2+dfsg-3
ii  libreadline7  7.0-5
ii  libx11-6  2:1.6.5-1

Versions of packages maxima recommends:
ii  gnuplot-x11   5.2.2+dfsg1-2
ii  maxima-share  5.41.0-3

Versions of packages maxima suggests:
ii  maxima-doc5.41.0-3
pn  maxima-emacs  
pn  texmacs   
ii  tk [wish] 8.6.0+9
pn  xmaxima   

-- no debconf information

Bug#905315: renderdoc: Incomplete debian/copyright?

[Chris Lamb]

Source: renderdoc
Version: 1.0+dfsg-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Jordan Justen , 
ftpmas...@debian.org

Hi,

I just ACCEPTed renderdoc from NEW but noticed it was missing 
attribution in debian/copyright for at least a PCRE code copy.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#797340: choose-mirror: use httpredir.debian.org by default

[Chris Lamb]

retitle 797340 choose-mirror: use deb.debian.org by default
thanks

> choose-mirror: use httpredir.debian.org by default

s/httpredir/deb/   \o/


Best wishes,

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

Bug#905314: snapper-gui: Please clarify why you disable the testsuite

[Chris Lamb]

Source: snapper-gui
Version: 0git.960a94834f-1
Severity: wishlist
X-Debbugs-CC: Ritesh Raj Sarraf , ftpmas...@debian.org

Hi,

I just ACCEPTed snapper-gui from NEW but was wondering if you could
clarify (in the package itself) why you disable the testsuite.


Regards,

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

Bug#905313: ITP: libodpi-c: Oracle Database Programming Interface for Drivers and Applications

[Hugo Lefeuvre]

Package: wnpp
Severity: wishlist

* Package name: libodpi-c
  Version : 2.4.2
  Upstream Author : Oracle
* URL : https://github.com/oracle/odpi/
* License : UPL + Apache
  Programming Lang: C

Dependency of python-cx-oracle.


signature.asc
Description: PGP signature

Bug#905312: ITP: xlunzip -- test tool for the kernel lzip decompression

[Daniel Baumann]

Package: wnpp

  * Package name : xlunzip
  * Upstream Author : Antonio Diaz Diaz 
  * License : GPL-2+
  * Homepage : http://www.nongnu.org/lzip/xlunzip.html

(quoting from the website:)

Xlunzip is a test tool for the lzip decompression code of my lzip patch
for linux. Xlunzip is similar to lunzip, but it uses the lzip_decompress
linux module as a backend. Xlunzip tests the module for stream,
buffer-to-buffer and mixed decompression modes, including in-place
decompression (using the same buffer for input and output). You can use
xlunzip to verify that the module produces correct results when
decompressing single member files, multimember files, or the
concatenation of two or more compressed files. Xlunzip can be used with
unzcrash to test the robustness of the module to the decompression of
corrupted data.

Regards,
Daniel

Bug#834335: ngspice isn't providing libngspice.so

[Carsten Schoenert]

Hello Michael,

On Thu, Aug 02, 2018 at 08:42:48PM +0200, Michael Büsch wrote:
> I would like to second the proposal to add libngspice.so support to the
> ngspice package.
> PySpice ( https://pyspice.fabrice-salvaire.fr/ ) needs libngspice.so.
> So I'm currently stuck with compiling ngspice from source by myself.
> 
> Also new versions of ngspice are available. Please consider an upgrade.

all these things should be solved once ngspice 28 has passed the NEW
queue. Then ngspice would also be available within the main section.

https://ftp-master.debian.org/new/ngspice_28-1.html

Hopefully it will processed in the near future.

You can build ngspice-28 in between times by your own.

https://salsa.debian.org/electronics-team/ngspice

Regards
Carsten

Bug#905311: autopktest: skip tests with unsatisfiable dependencies

[Ralf Treinen]

Package: autopkgtest
Version: 5.4.1
Severity: wishlist

Hi,

please provide a means to specify that a test is to be skipped when its
dependencies are not satisfiable. This is needed since what is a dependency
for a particluar test case might be just one of many *alternative* 
dependencies of the package, of just a Recommends/Suggests.

My particular use case is the package why3 which Recommends [1]

alt-ergo | cvc3 | cvc4 | why3-coq | spass | z3

These are all backends with which why3 can talk. I have tests [2] for 
each of these backends, the control entry for these tests look like
this:

  Tests: why3+alt-ergo
  Depends: why3, alt-ergo

As you can see, alt-ergo is strict dependency for this test, but it is
only one of many alternative recommends for the package. 

Now, some of these backends are not available on all architectures [3]. I
was told to use the "flaky" restriction in this case but this is not
the right solution since if the backend package is available and the
test fails when it is executed then I still want the red lights to go on.

An alternative solution in my use case would be to use the "skippable"
restriction, apt-get install the backend in the test and exit 77 when
this fails, but this would mean using root access without a good reason.

In fact, I think skipping a test in case the test dependencies cannot be
satisfied should even be the default behaviour since checking package
dependencies is not the job of autopkgtest (we have testing migration
and qa.debian.net/dose for that) but I could live with it if you do
not agree with that ;-)

-Ralf.

[1] https://sources.debian.org/src/why3/1.0.0-1/debian/control/
[2] https://sources.debian.org/src/why3/1.0.0-1/debian/tests/control/
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895104


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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.6.3
ii  libdpkg-perl1.19.0.5
ii  procps  2:3.3.15-2
ii  python3 3.6.5-3
ii  python3-debian  0.1.32

Versions of packages autopkgtest recommends:
ii  autodep8  0.13

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd-client
pn  ovmf  
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
pn  qemu-utils
pn  schroot   

-- no debconf information

Bug#883950: Next steps on "[GPL-3+]" proposal

[Russ Allbery]

Markus Koschany  writes:

> I have a hard time to imagine what kind of breakage might occur with
> those non-Lintian parsers.

It's pretty straightforward: currently, a License field must either
contain an extended paragraph or references one elsewhere in the document.
Therefore, whenever a parser sees a License field without an extended
paragraph, it currently knows (and expects) there to be a stand-alone
license paragraph later in the document.  But with this change that
paragraph wouldn't exist.

> I personally dislike the trend in Debian to create more and more
> complexity in our source packages.

Well, I think avoiding changing the version of the standard and adding
this special case (and special-casing a specific set of licenses) adds
*more* complexity to the format than my proposal, as did the brackets.  It
requires encoding options and branches and multiple interpretations of the
same field.  Simplicity is exactly why I want to just change the version
number, introduce a new field with a clear meaning and syntax, and have
clean and simple semantics in the new version.

> I find the Standards-Version field unnecessary, VCS fields should not be
> part of a debian/control file, all DFSG licenses approved by our
> ftp-team should be listed in /usr/share/common-licenses and maintainers
> allowed to reference them, simple clarifications for copyright format
> 1.0 elements should not require a separate document 1.1 and so on.

That's an interesting assortment of things that seem very, very unlike
each other to me.  Including a few I agree with (such as VCS fields not
being in the debian/control file; I'd love to find a good migration
strategy to move such metadata about the package maintenance process, as
opposed to a single instance of a source package, out of debian/control
for a cleaner separation of concerns).

Personally, I'd be happy to have all approved licenses listed in
common-licenses (there are a few complexities to actually doing that, but
it would be nice if we worked those out) since it would make my life a lot
easier, but you'll have to take that one up with the embedded systems
folks (and minimal container folks, for that matter), who have indicated
they'd be quite *unhappy* about that.  (I suspect the base-files
maintainer wouldn't be thrilled either.)

One of the jobs of being a Policy Editor is to try to keep in mind the
widely varying uses to which Debian is put and to try to chart a course
between those concerns.  The common-licenses compromise is awkward and not
particularly graceful, and it would be nice to have a better approach, but
I don't think shipping several megabytes of text in base-files is the one
that's going to make everyone happy.

> I have noticed that you are always in the opposite camp and a proponent
> for more complexity.  I believe this kind of perfectionism makes it more
> and more difficult to change even smaller details in Debian.

This amuses me a lot, since part of what I've tried to do in Policy in the
past year or two has been to argue against perfectionism and to push
things forward despite some objections and desire to get all the details
more correct, to the considerable annoyance of some folks.

It is certainly true that Policy is probably too bureaucratic, and I'd
like it to be more streamlined and faster as well.  But formulating
standards through consensus is hard, and every standards process ends up
having this problem to some extent if it's successful.  If you think this
is bad, you should try the IETF or, heaven forbid, POSIX.  :)

Debian is really large, and there are a lot of edge cases, and
standardization becomes the place where we find all those edge cases and
talk about them and try to write them down.  If anyone has figured out how
to do that without being bureaucratic, I haven't heard about it.

I think what you're seeing is a large and mature project with a stronger
committment to quality and consistency than you find in most communities.
(And, to be fair, quite a lot of momentum and adherence to "the way things
have always been done," probably more than we should have.)  That
inherently comes with a certain lack of agility.  I wish we could have
both at the same time, but I think it might be a constraint of human
nature.

> For me #883950 and this proposal is a no-brainer and should have been
> handled much more gracefully.

Yup, that's a common theme -- just about everyone who comes to Policy for
a specific proposal thinks their proposal is a no-brainer (but usually has
some objections to some other proposal someone else had, like putting VCS
fields into debian/control).

> I'm not surprised that I can't convince you but for the sake of other
> Policy bug reporters, I suggest that you make your decision making
> process more transparent in the future. For instance I was asked by one
> Policy editor to contact the ftp-team, which are the authoritative body
> in Debian when it comes to licenses, I got the OK for my proposal but
> now it 

Bug#904729: Policy 12.5: Must the license grant be included in debian/copyright?

[Jonathan Nieder]

Hi,

Simon McVittie wrote:
> On Wed, 01 Aug 2018 at 19:23:09 -0700, Jonathan Nieder wrote:
>> Simon McVittie wrote:

>>>   ( ) the full text of the license, *and* the license grant
>>>   (unless the license *is* the license grant, like BSD-style licenses)
>>
>> This wording confuses me.  All licenses are license grants.
>
> In the past, it has been asserted that maintainers are required to
> paste the text written by upstream that tells the consumer that they
> may redistribute the package under a specified license, verbatim,
> into the copyright file. That's what I meant whenever I said "license
> grant" on this bug. (Not to be confused with the text you can find in
> /usr/share/common-licenses, which tells you what the terms of the GPL
> are, but does not tell you that you can distribute any particular piece
> of software under those terms.)

Right: this involves a strange intersection of two requirements.

One is policy's "verbatim" requirement:

Every package must be accompanied by a verbatim copy of its
copyright information and distribution license

Another is a "common sense" requirement, which I'll put in my own
words:

A statement about where you can find a copy of the GPL does not
say anything about whether this package is under the GPL.  So
we need more than that.

One way to handle them both is to include a verbatim copy of some text
from upstream indicating that the package is under the GPL.  This is
what Joerg used to encourage packagers to include, for example in the
reject FAQ.

But since then, he has (fortunately!) relaxed a bit, and his more
current statements suggest that he views these two requirements as
independent.  We need a verbatim copy of the license, for example as
included "by reference" from common-licenses.  And we need a clear
indication that that license applies to this package, as provided for
example by the text

Files: *
License: GPL-2+

in a DEP-5 format copyright file.

Cc-ing him to allow him to correct me.

Thanks and hoping that clarifies,
Jonathan

Bug#905306: bts

[Daniel Baumann]

retitle 905306 special handling needed to upgrade from 1.7-2
tag 905306 + pending
thanks

Bug#883950: Next steps on "[GPL-3+]" proposal

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> I personally dislike the trend in Debian to create more and more
> complexity in our source packages. I find the Standards-Version field
> unnecessary, VCS fields should not be part of a debian/control file, all
> DFSG licenses approved by our ftp-team should be listed in
> /usr/share/common-licenses and maintainers allowed to reference them,
> simple clarifications for copyright format 1.0 elements should not
> require a separate document 1.1 and so on.

Is this a trend?  Most of the complexity you are describing has been
there since day one, and efforts like the copyright format have tended
toward simplification.

> I have noticed that you are always in the opposite camp and a proponent
> for more complexity.

This is uncalled for, when Russ was just providing some context.

Please, let's discuss the proposals, not the people.

Sincerely,
Jonathan

Bug#905257: want automatic push to salsa or whereever

[Sean Whitton]

Hello,

On Thu 02 Aug 2018 at 08:35AM +0100, Ian Jackson wrote:

> I should be able to configure dgit to push my branch to salsa or
> chiark or whatever, after each push.
>
> Failures of that push should not be fatal.

I feel like this is something of a layering violation.  dgit is for
interaction with the Debian archive.

Users will probably want to configure a custom push command (I have a
complicated perl script, as I've mentioned) and so a shell alias that
runs `dgit push-source` followed by that push command seems like the
right way to implement this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#905310: Please document hint-testsuite-triggers convention

[Ian Jackson]

Package: autopkgtest
Version: 5.4.2
Tags: patch

>From ee5188ba223d31cbdca70f0601c7683090cddfa9 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Fri, 3 Aug 2018 03:32:50 +0100
Subject: [PATCH] doc/README.package-tests.rst: document
 hint-testsuite-triggers

There is currently no official way to influence which packages trigger
a retest on ci.d.n.  However, there is a trick, involving an
unrunnable test which exists only to get its Depends into
Testsuite-Triggers.  This is used by the dgit packagae.

In lieu of a better mechanism, this trick ought to be documented.
Documenting it also means that future ci machinery can know what this
strange test actually means.

Signed-off-by: Ian Jackson 
---
 doc/README.package-tests.rst | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/doc/README.package-tests.rst b/doc/README.package-tests.rst
index 384eacd..44a9197 100644
--- a/doc/README.package-tests.rst
+++ b/doc/README.package-tests.rst
@@ -269,6 +269,28 @@ skippable
 that ``skippable`` tests never exit with status 77 for reasons that
 should be treated as a failure.
 
+hint-testsuite-triggers
+This test exists purely as a hint to suggest when rerunning the
+tests is likely to be useful.  Specifically, it exists to
+influence the way dpkg-source generates the Testsuite-Triggers
+.dsc header from test metadata: the Depends for this test are
+to be added to Testsuite-Triggers.  (Just as they are for any other
+test.)
+
+The test with the hint-testsuite-triggers restriction should not
+actually be run.  Future systems which understand per-test update
+triggering should treat the Depends of the test with this
+restriction, as triggering packages for all tests in this
+debian/tests/control.
+
+The packages listed as Depends for this test are usually indirect
+dependencies, updates to which are considered to pose a risk of
+regressions in other tests defined in this package.
+
+There is currently no way to specify this hint on a per-test
+basis; but in any case the debian.org machinery is not able to
+think about triggering individual tests.
+
 Defined features
 
 
-- 
2.11.0



-- 
Ian JacksonThese opinions are my own.

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

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder]

Sean Whitton wrote:
> On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote:

>> "as verbose as reasonably possible" seems incompatible with "maximally 
>> verbose
>> output", at least in some cases (golang packages come to mind).
>>
>> Would it be possible to clarify this ?
>
> Yes.  Let's improve this.
>
> Would s/maximally// be sufficient?  Or s/maximally/more/ ?

I don't know a better way to say this, so I'll just say it: I am not
feeling listened to.  I am feeling talked past.  No, that wouldn't be
sufficient at all.

I think some of that is inevitable in the rush to resolve policy bugs,
but there are other ways to get this done that are less dismissive (for
example, requesting a patch).

If you'd like more detail from me, is there some appropriate place to
discuss this in real time?  I am jrnieder on freenode.

Jonathan

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Wed 01 Aug 2018 at 10:47PM -0700, Jonathan Nieder wrote:

>> Thanks for reporting.  My understanding from
>> https://bugs.debian.org/628515 is that the intention is
>>
>> - print out compiler driver command lines, so that compiler errors are
>>   closely preceded with the command that produced them
>>
>> - no need to print out command lines for tools like ld that are
>>   themselves invoked by the compiler driver, but do print out those
>>   command lines if you invoke them directly
>>
>> I don't think verbosity for the sake of verbosity was ever a goal
>> here, so ideas for better wording would be very welcome.
>>
>> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628515;msg=30
>> I proposed wording along the lines of
[... wording snipped ...]
> IIRC my hope was to generalise the recommendation to apply to as many
> different build systems as possible.  For example, packages whose builds
> do not involve any compilers and linkers.
>
> We could restore your text in a footnote or a "For example ..."
> paragraph?

Thanks.  Unfortunately, that wouldn't address Clément's concern about
maximal verbosity (1) not being consistent with reasonableness and (2)
not being concrete enough to easily act on as a packager.

Can we make it about not abbreviating build command lines, instead of
maximal verbosity?  For example, enabling more warnings might make a
compiler produce more verbose output, but it isn't the goal of this
requirement.  Similarly, enabling compiler tracing might make a
compiler produce more verbose output, and some people might even like
that, but I don't believe that was the goal of this policy
requirement.

Hope that helps,
Jonathan

Bug#905258: lintian: ruby-script-but-no-ruby-dep does not accept :any dependency

[Chris Lamb]

tags 905258 + pending
thanks

Fixed in Git, pending upload...

  
https://salsa.debian.org/lintian/lintian/commit/e3361853210bbf48561a9f598952b6a6ee6d33a5

  data/scripts/interpreters | 2 +-
  debian/changelog  | 4 
  2 files changed, 5 insertions(+), 1 deletion(-)


Regards,

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

Bug#883950: Next steps on "[GPL-3+]" proposal

[Markus Koschany]

Am 03.08.2018 um 00:59 schrieb Russ Allbery:
> Markus Koschany  writes:
> 
>> You appear more concerned about one parser, Lintian, than about the
>> human maintainers who have to update d/copyright again.  You argue that
>> the maintainers have to update d/copyright anyway, I say fixing the tool
>> is far more efficient because it affects far less human beings.
> 
> You seem to be assuming that Lintian is the only validating parser.  One,
> this is definitely not true, and two, the entire point of having a
> standard for machine-readable copyright files is so that anyone can write
> a parser without consulting with us first.  Part of the guarantee in
> creating a standard is that the interface is the standard.  We should
> assume there are an unknown number of implementations of that standard in
> the wild and do the right thing when updating the standard so that they
> can track future changes.

I have a hard time to imagine what kind of breakage might occur with
those non-Lintian parsers. We just have to check whether a short license
identifier is also a common-license, if true, do not write a standalone
paragraph and do not add boilerplate statements like "On Debian systems
you can find..." to the license field anymore. I believe you overstate
the impact of this change on tools and a pragmatical solution would be
absolutely fine in this case.

> Also, again, no human maintainers have to update anything if they don't
> want to.  The 1.0 format isn't going anywhere.  We would continue to
> publish it; that was the agreement we reached when we versioned it in the
> first place.  So I don't understand your insistance that this creates work
> for people.

I personally dislike the trend in Debian to create more and more
complexity in our source packages. I find the Standards-Version field
unnecessary, VCS fields should not be part of a debian/control file, all
DFSG licenses approved by our ftp-team should be listed in
/usr/share/common-licenses and maintainers allowed to reference them,
simple clarifications for copyright format 1.0 elements should not
require a separate document 1.1 and so on.

I have noticed that you are always in the opposite camp and a proponent
for more complexity. I believe this kind of perfectionism makes it more
and more difficult to change even smaller details in Debian. For me
#883950 and this proposal is a no-brainer and should have been handled
much more gracefully. It's not about changing a number that creates
work, it is all that bureaucratic stuff that I have mentioned which adds
up to my frustration about our current workflows.
 [...]
> Okay.  I think I understand your argument and viewpoint.  I'm not at all
> persuaded by it, I'm afraid.  We definitely need a version change for
> this.
> 
>> Well, to me it looks like he didn't recognize it because there isn't any
>> but let's just ask him again to be sure. (that's probably the discussion
>> in #904729)
> 
> Even if he agrees with you, that doesn't change my position, just for the
> record.  So I'm not sure this is going to achieve what you want it to
> achieve.  :)

I'm not surprised that I can't convince you but for the sake of other
Policy bug reporters, I suggest that you make your decision making
process more transparent in the future. For instance I was asked by one
Policy editor to contact the ftp-team, which are the authoritative body
in Debian when it comes to licenses, I got the OK for my proposal but
now it is blocked by another Policy editor who subtly implies that the
resolution of this bug depends solely on him. It would have saved us
time and effort if we got that straight right from the start.

Regards,

Markus






signature.asc
Description: OpenPGP digital signature

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Sean Whitton]

Hello Jonathan,

On Wed 01 Aug 2018 at 10:47PM -0700, Jonathan Nieder wrote:

> Thanks for reporting.  My understanding from
> https://bugs.debian.org/628515 is that the intention is
>
> - print out compiler driver command lines, so that compiler errors are
>   closely preceded with the command that produced them
>
> - no need to print out command lines for tools like ld that are
>   themselves invoked by the compiler driver, but do print out those
>   command lines if you invoke them directly
>
> I don't think verbosity for the sake of verbosity was ever a goal
> here, so ideas for better wording would be very welcome.
>
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628515;msg=30
> I proposed wording along the lines of
>
>   terse
>   
>   Compiler and linker commands used to build the package
>   should not be abbreviated in the log unless this
>   tag is supplied.
>
>   Packages built with cmake, autotools, or
>   the Linux kernel build system can implement this by
>   passing the parameters V=1 and
>   VERBOSE=1 by default as arguments to
>   make and omitting them when the terse tag is
>   supplied.
>   
>
> I am not sure why this suggestion got generalized to "as verbose as
> reasonably possible" in the patch that replaced it.

IIRC my hope was to generalise the recommendation to apply to as many
different build systems as possible.  For example, packages whose builds
do not involve any compilers and linkers.

We could restore your text in a footnote or a "For example ..."
paragraph?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Sean Whitton]

Hello,

On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote:

> "as verbose as reasonably possible" seems incompatible with "maximally verbose
> output", at least in some cases (golang packages come to mind).
>
> Would it be possible to clarify this ?

Yes.  Let's improve this.

Would s/maximally// be sufficient?  Or s/maximally/more/ ?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#905266: gfortran: Write and read arrays in unformatted files do not work properly

[Matthias Klose]

Control: tags -1 + moreinfo

On 02.08.2018 12:24, Marco wrote:
> Package: gfortran
> Version: 4:8.1.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> I'm running a fortran hydrodynamic model. Here we have a routine writing
> an unformatted file with an header and a real array with the following
> code:
> 
>  write(30,iostat=ierr) time,ivar,m,lmax
>  +  ,(((vals(l,j,i)
>  +  ,l=1,ll(j))
>  +  ,j=1,jj)
>  +  ,i=1,m)
> 
> and a second routine this file with:
> 
>  read(20,iostat=ierr) time,ivar,m,lmax
>  +  ,(((vals(l,j,i)
>  +  ,l=1,ll(j))
>  +  ,j=1,jj)
>  +  ,i=1,m)
> 
> where vals is a real array. 
> The problem is that if I write the file and then I read it and I print "vals" 
> it contains 0.00 values. 
> If I set ll(j) = 1 and I write in both the routines: 
>   + ,l=1,1)
> the code works.
> 
> With old gfortran versions the code worked, as well as with other compilers.

please could you provide a self-contained example?

Bug#905309: nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing

[Allan Wind]

Package: nvidia-driver
Version: 384.130-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I noticed the fan on my laptop was spinning at full speed which 
signifies heavy load.  Screens suspended, and they don't 
unsuspend when I pressed the keyboard.  I ssh into the machine 
remotely, and see that nvidia-modeset is using 100% cpu.  The 
only thing unusual in syslog is:


2018-08-02T22:49:34.702+00:00 vent kernel: nvidia-modeset: 
WARNING: GPU:0: Lost display notification (0:0x); 
continuing.


sysstat suggest load went up shortly before 21:25 UTC (100% on 1 
cpu of 8 is 12.50%)


12:00:01 AM CPU %user %nice   %system   %iowait
%steal %idle

...
08:45:01 PM all  4.21  0.00  0.38  0.02  
0.00 95.39
08:55:01 PM all  0.42  0.00  0.06  0.00  
0.00 99.52
09:05:01 PM all  0.09  0.00  0.05  0.01  
0.00 99.85
09:15:01 PM all  0.07  0.00  3.35  0.01  
0.00 96.57
09:25:01 PM all  0.06  0.82 12.58  0.01  
0.00 86.53
09:35:01 PM all  0.06  0.00 12.63  0.00  
0.00 87.30
09:45:01 PM all  0.07  0.00 12.68  0.01  
0.00 87.24


I initiated a reboot via ssh, but my system was still hanging 
after a few minutes.  Hard power cycled laptop to restore 
service.


I have had similar issues in the past but never narrowed it down 
to the process.  At best this is intermittent, maybe, months 
apart.  Happy to provide additional data next time this happens.  
What would be helpful?


-- Package-specific info:
uname -a:
Linux vent 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 
GNU/Linux

/proc/version:
Linux version 4.9.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  384.130  Wed Mar 21 03:37:26 
PDT 2018
GCC version:  gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 


lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1436] 
(rev a1) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:2251]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video 226,   0 Aug  2 19:49 /dev/dri/card0
crw-rw+ 1 root video 226, 128 Aug  2 19:49 /dev/dri/renderD128
crw-rw-rw-  1 root root  195, 254 Aug  2 19:49 /dev/nvidia-modeset
crw-rw-rw-  1 root root  195,   0 Aug  2 19:49 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Aug  2 19:49 /dev/nvidiactl
video:x:44:allan,mona

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jul  6  2017 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Jul  6  2017 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Jul  6  2017 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jul  6  2017 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   50 Jul  6  2017 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Jul  6  2017 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   47 Jul  6  2017 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Jul  6  2017 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   51 Jul  6  2017 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jul  6  2017 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jul  6  2017 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jul  6  2017 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Jul  6  2017 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Jul  6  2017 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Jul  6  2017 

Bug#905308: elpa-debian-el: deb-view.el shell of bad filename

[Kevin Ryde]

Package: elpa-debian-el
Version: 37.5
File: /usr/share/emacs/site-lisp/elpa-src/debian-el-37/deb-view.el

In deb-view-process, the filename is not quoted when passed to the shell
in a few places, so it executes shell code on visiting a bad filename.

cd /tmp
touch ';echo hello >xyz;.deb'
emacs -q
M-: (add-to-list 'auto-mode-alist '("\.deb\\'" . deb-view-mode))
C-x C-f ;echo hello >xyz;.deb
=>
creates file /tmp/xyz

A bad filename should be unlikely, but in the interests of avoiding
accidents or malice it'd be good to be safe.  It looks like all
remaining "(call-process shell-file-name ...)" can be call-process
alone, no shell.


-- System Information:
Debian Release: buster/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages elpa-debian-el depends on:
ii  bzip2   1.0.6-8.1
ii  dpkg1.19.0.5+b1
ii  emacsen-common  2.0.8
ii  reportbug   7.5.0
ii  xz-utils5.2.2-1.3

Bug#868724: debian/watch file for the ledgersmb package

[Robert James Clay]

 On Thu, Aug 2, 2018 at 1:58 PM Shengjing Zhu  wrote:  

> Not about repack, current watch file will download tarball that github  

> generated, not the one upstream uploading to github release. Look at  

> https://github.com/ledgersmb/LedgerSMB/releases, please be careful  

> that there're two kinds of tarball. Don't look at  

> https://github.com/ledgersmb/LedgerSMB/tags, which doesn't have asc   

  If that were entirely true then where does the, in this case,
downloaded file ledgersmb-1.5.21.tar.gz.asc from? I'd always thought that
resulted from the GitHub pgpsigurlmangle entry[1], which does point to the
'releases'. And if the final URL is pointed to the 'releases' also, it fails
because it can't find the *.asc file as it's looking for the wrong file name
and ends up not downloading anything.  That's why it confused me; the form
of watch I ended up using at least downloaded files but still failed due to
the apparently bad downloaded archive.

  

   

 

  > And I think using upstream http release page is much simpler for you.

   

    I'm inclined to agree and will look at using that site instead.  

    

    Thanks!

   

   

  Robert James Clay

  j...@rocasa.us 

  [1] https://wiki.debian.org/debian/watch

   

Bug#904796: chromium for arm64 lacks security updates

[Riku Voipio]

tags 904796 + patch upstream
thanks

On Mon, Jul 30, 2018 at 01:37:57AM +, Riku Voipio wrote:
> On Sat, Jul 28, 2018 at 05:23:14PM -0400, Michael Gilbert wrote:
> > > Chromium on arm64 in Debian Stretch stopped receiving security updates.
> > > Chromium for i386, amd64 and armhf received updates for versions 67 and
> > > 68, however chromium for arm64 is stuck on version 66.
>  
> > There was a build error in crashpad on arm64 introduced by upstream
> > chromium 67.  A patch fixing that has been included with the last two
> > security uploads, so I'm not sure why those builds would have failed.
> 
> Security build logs are not available, so I missed that. I'll try to 
> reproduce.

The issue seems to be binutils in stable not supporting LR = x30 alias. I've
built a fixed version. I'm travelling now, but once I get back, I'll test the
fix and submit patch upstream. Similar issue for armhf, but we don't have
chromium/armhf on stable, so it's not as important.

Riku
description: Stretch binutils doesn't recognize LR on arm64
author: Riku Voipio

Index: chromium-browser-68.0.3440.75/third_party/crashpad/crashpad/util/misc/capture_context_linux.S
===
--- chromium-browser-68.0.3440.75.orig/third_party/crashpad/crashpad/util/misc/capture_context_linux.S
+++ chromium-browser-68.0.3440.75/third_party/crashpad/crashpad/util/misc/capture_context_linux.S
@@ -312,14 +312,14 @@ CAPTURECONTEXT_SYMBOL2:
   stp x28, x29, [x0, #0x198]
 
   // The original LR can't be recovered.
-  str LR, [x0, #0x1a8]
+  str x30, [x0, #0x1a8]
 
   // Use x1 as a scratch register.
   mov x1, SP
   str x1, [x0, #0x1b0] // context->uc_mcontext.sp
 
   // The link register holds the return address for this function.
-  str LR, [x0, #0x1b8]  // context->uc_mcontext.pc
+  str x30, [x0, #0x1b8]  // context->uc_mcontext.pc
 
   // NZCV, pstate, and CPSR are synonyms.
   mrs x1, NZCV

Bug#897877: Confirm fix upstream

[Andreas Tille]

Hi,

I confirm this bug is fixed upstream.  However, this version requires
salmon 0.9 which is not yet uploaded due to unrelated build problems.
So I'm closing the bug in changelog in Git but the actual upload will
be delayed.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#903533: yapf FTBFS with Python 3.7 as supported version

[Nicholas D Steeves]

I hope this bug is fixed before 21 Aug, because yapf is marked for
autoremoval on the 23rd, and this will result in elpy's autoremoval
that same day.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#898961: dscverify: accept .buildinfo from a build with unsigned .dsc which later was signed

[Thorsten Glaser]

Hi Mattia,

> wait, but why is the checksum of the .dsc in the .buildinfo wrong?
> `debsign` takes care of updating the checksums in the .buildinfo when
> you sign a .changes (or a .buildinfo).  And of course if you sign

oh, that must be new then.

I have a specific setup that copies the .dsc and .changes from the
remote (Debian) system to the local (BSD) system that contains my
PGP secret key, signs them with a only slightly patched version of
debsign (to work on BSD, not GNU coreutils and such), and copies
them back.

It is semantically interesting, because the build was not actually
done with the signed .dsc, but I guess that’s irrelevant.

Meh, so I guess I have to port the newer debsign to BSD and then
change the wrapper copying script to handle the added complexity…

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Wouter Verhelst]

On Thu, Aug 02, 2018 at 09:46:28AM +0100, Simon McVittie wrote:
> mate-terminal and tilix, both terminals, have been adapted to Ubuntu
> having patched vte to stay with pcre instead of moving to pcre2.
> mate-terminal could easily use cpp; tilix is written in D, and I don't
> know whether that has a preprocessor.

It does not, but it does have a mechanism to have a somewhat limited
subset of D code be evaluated at compile time (which is actually far
more powerful than a preprocessor)

It also has an explicit mechanism for conditional compilation, which
would apply here; https://dlang.org/spec/version.html has the details on
how that works.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#905307: pbuilder: create consistent hosts(5) file for USENETWORK=no builds

[Thorsten Glaser]

Package: pbuilder
Version: 0.229.3
Severity: wishlist
Tags: patch

Hi Mattia & Co,

the announcement of the latest Policy had me review the way we
set up the network for disconnected-network builds in the chroot,
and found it was doing quite well already.

I’m attaching a patch that makes sure /etc/hosts is also cleaned up.
You might wish to apply it with the next upload. Otherwise, I think
we’re good.

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  debootstrap1.0.106
ii  dpkg-dev   1.19.0.5

Versions of packages pbuilder recommends:
ii  devscripts  2.18.3
ii  eatmydata   105-6
ii  fakeroot1.23-1
ii  iproute24.17.0-2
ii  net-tools   1.60+git20161116.90da8a0-3
ii  sudo1.8.23-2

Versions of packages pbuilder suggests:
ii  cowdancer   0.87+b1
pn  gdebi-core  

-- debconf information excluded
From 2e734501b8da2c2072efce3963e452cae91183f9 Mon Sep 17 00:00:00 2001
From: mirabilos 
Date: Fri, 3 Aug 2018 00:27:47 +0200
Subject: [PATCH] Create consistent /etc/hosts in build chroots with
 USENETWORK=no
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Policy 4.2.0.0 §4.9 explicitly allows loopback access.
We already set up the build chroot in a way that ifconfig shows:

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

We already also clean resolv.conf; add a clean hosts file to that
which ships 127.0.0.1 as localhost and ::1 as localhost6 to avoid
trouble. (It also ships a couple other standard IPv6-related en‐
tries; these are optional, but don’t hurt.)

This patch also adds rm statements to make sure hardlinks on the
replaced files are broken up.

Signed-off-by: mirabilos 
---
 pbuilder-buildpackage | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/pbuilder-buildpackage b/pbuilder-buildpackage
index 8c4e8027..c9addaf8 100755
--- a/pbuilder-buildpackage
+++ b/pbuilder-buildpackage
@@ -184,7 +184,20 @@ unset DISPLAY
 if [ "$USENETWORK" = "no" ]; then
 # empty /etc/resolv.conf, so software trying to resolv addresses even when
 # no network is possible doesn't choke.
-echo > "$BUILDPLACE/etc/resolv.conf"
+rm -f "$BUILDPLACE/etc/resolv.conf" # break hardlinks
+: > "$BUILDPLACE/etc/resolv.conf"
+# loopback access only
+rm -f "$BUILDPLACE/etc/hosts" # break hardlinks
+cat > "$BUILDPLACE/etc/hosts" <<'EOF'
+   127.0.0.1   localhost localhost.localdomain
+
+   ::1 ip6-localhost ip6-loopback localhost6 localhost6.localdomain6
+   fe00::0 ip6-localnet
+   ff00::0 ip6-mcastprefix
+   ff02::1 ip6-allnodes
+   ff02::2 ip6-allrouters
+   ff02::3 ip6-allhosts
+EOF
 fi
 
 (
-- 
2.18.0

Bug#900442: linux-image-4.16.0-2-amd64: LVM2 COW snapshots fail as of 4.16

[WGH]

This problem is being discussed in kernel mailing list right now:
https://www.spinics.net/lists/linux-block/msg29103.html (its cause is
more or less known now)

Bug#905306: zutils: trying to overwrite '/bin/zcat', which is also in package gzip 1.9-1

[Axel Beckert]

Package: zutils
Version: 1.7-3
Severity: serious

When trying to upgrade zutils from 1.7-2 to 1.7-3, it fails for me as
follows:

Preparing to unpack .../zutils_1.7-3_amd64.deb ...
Unpacking zutils (1.7-3) over (1.7-2) ...
dpkg: error processing archive /var/cache/apt/archives/zutils_1.7-3_amd64.deb 
(--unpack):
 trying to overwrite '/bin/zcat', which is also in package gzip 1.9-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/zutils_1.7-3_amd64.deb

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages zutils depends on:
ii  libc6   2.27-5
ii  libgcc1 1:8.2.0-1
ii  libstdc++6  8.2.0-1

Versions of packages zutils recommends:
ii  bzip2 1.0.6-8.1
ii  lzip  1.20-1
ii  xz-utils  5.2.2-1.3

zutils suggests no packages.

-- no debconf information

Bug#905305: emacs-common: terrible mess

[Cristian Ionescu-Idbohrn]

Package: emacs-common
Version: 1:25.2+1-8
Severity: important

Recent updates/transitions give me a hard time.
I had to remove older versions 23 amd 24 because of package upgrade failures.
The only installed version now is emacs25.

Been using debian and emacs for some 20 years.  This is a system that
runs sid "from the beginning of times", constantly upgraded, moved
from one HW to another.  Can't recall seeing anything (emacs related)
like this, over the years.  This is really annoying.  Executing:

# emacs -nw --debug-init -q

shows the following in the *Message* buffer:

...
Loading /etc/emacs/site-start.d/50devscripts-el.el (source)...
Package devscripts-el removed but not purged.  Skipping setup.
...
Loading /etc/emacs/site-start.d/50emacs-jabber.el (source)...
Package emacs-jabber removed but not purged.  Skipping setup.
...
Loading /etc/emacs/site-start.d/50git-core.el (source)...
git removed but not purged, skipping setup
...
Loading /etc/emacs/site-start.d/50lua-mode.el (source)...
Package lua-mode removed but not purged.  Skipping setup.
...
Loading /etc/emacs/site-start.d/50python-mode.el (source)...
Package python-mode not fully installed.  Skipping setup.
...
and finaly:

run-hooks: Cannot open load file: No such file or directory, initz

Impossible to open any file (for edit) from the command line.  Have to
open it again after startup: C-x C-f.

Common denominator seems to be /etc/emacs/site-start.d/.  Packages
dropping files in there are:

# dpkg -S /etc/emacs/site-start.d/
a2ps,
apel,
autoconf,
boxes,
cmake-data,
crypt++el,
css-mode,
develock-el,
dictionaries-common,
docutils-common,
elib,
elpa-jabber,
elserv,
emacs-goodies-el,
emacs-intl-fonts,
festival,
figlet,
flim,
gettext-el,
git-el,
global,
gnuplot-mode,
gnuserv,
gtk-doc-tools,
gtypist,
html-helper-mode,
initz,
lookup-el,
mew,
mgp,
planner-el,
pylint,
pymacs,
python-mode,
remember-el,
sawfish,
subversion-tools,
systemtap-common,
tcsh,
tpp,
tuareg-mode,
w3m-el,
whizzytex,
windows-el,
x-face-el,
x-pgp-sig-el,
xcscope-el,
emacs-common: /etc/emacs/site-start.d

I can see that some of those packages are no longer available from the
archive:

css-mode elib elserv html-helper-mode remember-el x-pgp-sig-el

Still, they don't seem to be the ones failing 'init', AFAICT.

I guess emacs-common is not the root of the problem here, but I have
a hard time figuring out what is.  Please feel free reassigning.

Still wondering.  Is there anything _I_ can do to clean up the mess?

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

Kernel: Linux 4.15.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=en_US:en 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages emacs-common depends on:
ii  emacsen-common  3.0.2
ii  install-info6.5.0.dfsg.1-4

Versions of packages emacs-common recommends:
pn  emacs-el  

Versions of packages emacs-common suggests:
pn  emacs-common-non-dfsg  
ii  ncurses-term   6.1+20180714-1

-- no debconf information


Cheers,

-- 
Cristian

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Горбешко Богдан]

I upgraded the kernel to 4.17.8 and experienced the issue again. Not 
sure if the bug is the same technically, but the sympthomes are: I tried 
to upload a 30 MB file, and in the midst got a noisy screen. I will try 
to catch it with kdump to get the backtrace again later.


On 6/29/18 11:17 AM, Bjørn Mork wrote:

This issue should be fixed by commit

  49c2c3f246e2 ("cdc_ncm: avoid padding beyond end of skb")

which has been backported to v4.17.3, v4.16.18 and v4.14.52.  Please
check again with one of those kernel versions (or newer).

I see now that the fix doesn't apply cleanly to v4.9 stable due to
unrelated context changes.  I'll go fix that and resubmit a backport for
v4.9, so we get the fix into "stretch" too.  Thanks for reminding me.



Bjørn

Bug#905230: elfutils: FTBFS on x32 due to bugs in testsuite

[Thorsten Glaser]

Hi Helmut,

> I don't think this is correct. The above configure invocation will only
> run when performing a cross build. confenv will only contain your
> variable when the host arch is x32

you’re completely right. Sorry.

Given #847096 it might be wise to just *always* disable the biarch stuff
since Debian does not normally use biarch *anyway*, and since we test it
on all architectures during their native build anyway.

So drop the “ifneq (,$(filter x32,$(DEB_HOST_ARCH)))” and the correspon‐
ding endif line from the patch.

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

*

**Besuchen Sie uns auf der dmexco 2018!**

12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031**

Digital Business, Marketing und Innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

**Visit us at dmexco 2018!**

12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031**

Digital business, marketing and innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

Bug#886633: Acknowledgement (sbuild: Please, unapply quilt patches after the build.)

[Pierre-Elliott Bécue]

Dear Josch,

Do you intend to include this patch in a next release of sbuild? :)

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#905304: security-tracker: DSA-4259-1 vs. tracker

[Salvatore Bonaccorso]

HI Francesco,

On Thu, Aug 02, 2018 at 10:00:31PM +0200, Francesco Poli (wintermute) wrote:
> Package: security-tracker
> Severity: normal
> 
> Hello!
> 
> According to [DSA-4259-1], ruby2.3/2.3.3-1+deb9u3 fixes a number of
> vulnerabilities, among which CVE-2017-17405, CVE-2017-17742,
> CVE-2017-17790, and CVE-2018-6914.
> 
> However, the tracker pages for [CVE-2017-17405], [CVE-2017-17742],
> [CVE-2017-17790], and [CVE-2018-6914] seem to disagree.
> 
> Is the tracker wrong?
> Please update the tracker data, then.

The tracker was wrong due to the human-error in
https://salsa.debian.org/security-tracker-team/security-tracker/commit/a5e9c1099e5f5a29832b60c97f3d9d0f61a538cf
, which needed to be added manually due to a unrelated problem while
updating tracker and relasing the DSA.

Thanks for spotting! All the information should be uptodate in at most
an hour.

Regards,
Salvatore

Bug#888338: libavg: FTBFS with FFmpeg 4.0

[peter green]

I applied the patch that jcowgill submitted upstream plus another upstream 
commit and disabled vdpau support (which has been removed upstream) and was 
able to get the debian package to build, so I uploaded it to raspbian.

A debdiff should appear soon at https://debdiffs.raspbian.org/main/liba/libavg/ 
No intent to nmu in debian.

Bug#905304: security-tracker: DSA-4259-1 vs. tracker

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hello!

According to [DSA-4259-1], ruby2.3/2.3.3-1+deb9u3 fixes a number of
vulnerabilities, among which CVE-2017-17405, CVE-2017-17742,
CVE-2017-17790, and CVE-2018-6914.

However, the tracker pages for [CVE-2017-17405], [CVE-2017-17742],
[CVE-2017-17790], and [CVE-2018-6914] seem to disagree.

Is the tracker wrong?
Please update the tracker data, then.

Is the DSA wrong?
Please clarify (I searched in the tracker commit history on Salsa,
but I failed to find any explicit explanation about this
discrepancy...).

Thanks for your time!

[DSA-4259-1]: 

[CVE-2017-17405]: 
[CVE-2017-17742]: 
[CVE-2017-17790]: 
[CVE-2018-6914]:  

Bug#897877: trinityrnaseq: ftbfs with GCC-8

[Adrian Bunk]

Control: tags -1 ftbfs fixed-upstream

On Fri, May 04, 2018 at 12:23:56PM +, Matthias Klose wrote:
>...
> mv slclust ../bin/
> make[3]: Leaving directory 
> '/<>/trinityrnaseq-2.5.1+dfsg/trinity-plugins/slclust/src'
> make[1]: Leaving directory '/<>/trinityrnaseq-2.5.1+dfsg'
>debian/rules override_dh_install-arch
> make[1]: Entering directory '/<>/trinityrnaseq-2.5.1+dfsg'
> dh_install -a
> dh_install: Cannot find (any matches for) "Chrysalis/TranscriptomeFromVaryK" 
> (tried in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/TranscriptomeFromVaryK
> dh_install: Cannot find (any matches for) "Chrysalis/RunButterfly" (tried in 
> ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/RunButterfly
> dh_install: Cannot find (any matches for) 
> "Chrysalis/ReadsToTranscripts_MPI_chang" (tried in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: 
> Chrysalis/ReadsToTranscripts_MPI_chang
> dh_install: Cannot find (any matches for) "Chrysalis/ReadsToTranscripts_MPI" 
> (tried in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/ReadsToTranscripts_MPI
> dh_install: Cannot find (any matches for) "Chrysalis/ReadsToTranscripts" 
> (tried in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/ReadsToTranscripts
> dh_install: Cannot find (any matches for) "Chrysalis/QuantifyGraph" (tried in 
> ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/QuantifyGraph
> dh_install: Cannot find (any matches for) "Chrysalis/JoinTransByPairs" (tried 
> in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/JoinTransByPairs
> dh_install: Cannot find (any matches for) "Chrysalis/IsoformAugment" (tried 
> in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/IsoformAugment
> dh_install: Cannot find (any matches for) "Chrysalis/GraphFromFasta_MPI" 
> (tried in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/GraphFromFasta_MPI
> dh_install: Cannot find (any matches for) "Chrysalis/GraphFromFasta" (tried 
> in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/GraphFromFasta
> dh_install: Cannot find (any matches for) "Chrysalis/CreateIwormFastaBundle" 
> (tried in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/CreateIwormFastaBundle
> dh_install: Cannot find (any matches for) "Chrysalis/Chrysalis" (tried in ., 
> debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/Chrysalis
> dh_install: Cannot find (any matches for) "Chrysalis/BreakTransByPairs" 
> (tried in ., debian/tmp)
> 
> dh_install: trinityrnaseq missing files: Chrysalis/BreakTransByPairs
> dh_install: missing files, aborting
> make[1]: *** [debian/rules:46: override_dh_install-arch] Error 25
> make[1]: Leaving directory '/<>/trinityrnaseq-2.5.1+dfsg'
> make: *** [debian/rules:19: binary-arch] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
> returned exit status 2

Upstream fix:
https://github.com/trinityrnaseq/trinityrnaseq/commit/a3d279c17f868fd51d56f8e1a6f9a3c223480fbf

There is now a second FTBFS afterwards:
   dh_installdocs
dh_installdocs: Cannot find (any matches for) "hpc_conf" (tried in .)

This second FTBFS is unrelated, it is due to the #902355 fix.

cu
Adrian

-- 

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

Bug#830876: A new love version has been released

[Reiner Herrmann]

Hi,

> In short: The debian/copyright file should be up-to-date and ideally the
> enet and box2d libraries should not be embedded and system libraries be
> used instead.
> 
> Love must be buildable from source of course (see #873329) and its only
> reverse-dependency mrrescue should be tested whether it still works with
> newer versions or if any adjustments are needed.
> 
> After that packaging 11.0.0 would be nice or you could skip 0.10
> completely and fix all the things I mentioned above in 11.0.0. Most
> importantly love needs a maintainer who cares about it.

I updated the copyright file (which seems to be the biggest blocker) in
my [merge request] on salsa. It is based on the current 11.1 release and
is building for me with pbuilder, but I haven't tested building reverse
dependencies.

Also I have temporarily disabled the -doc package, as I couldn't figure
out where to get the -doc and -demos tarballs and use them during build.

Kind regards,
  Reiner

[merge request]: https://salsa.debian.org/games-team/love/merge_requests/1


signature.asc
Description: PGP signature

Bug#834335: ngspice isn't providing libngspice.so

[Michael Büsch]

I would like to second the proposal to add libngspice.so support to the
ngspice package.
PySpice ( https://pyspice.fabrice-salvaire.fr/ ) needs libngspice.so.
So I'm currently stuck with compiling ngspice from source by myself.

Also new versions of ngspice are available. Please consider an upgrade.

Thanks.

-- 
Michael


pgpMXc7WcMS6j.pgp
Description: OpenPGP digital signature

Bug#897845: repsnapper: ftbfs with GCC-8

[Adrian Bunk]

Control: reassign -1 libvmmlib-dev 1.0-2
Control: affects -1 src:repsnapper

On Fri, May 04, 2018 at 12:23:20PM +, Matthias Klose wrote:
>...
> In file included from /usr/include/vmmlib/vmmlib.hpp:26,
>  from src/stdafx.h:59,
>  from src/transform3d.h:22,
>  from src/transform3d.cpp:21:
> /usr/include/vmmlib/quaternion.hpp: In member function 'void 
> vmml::quaternion::operator-=(const vmml::vector<3, T>&)':
> /usr/include/vmmlib/quaternion.hpp:760:10: error: return-statement with a 
> value, in function returning 'void' [-fpermissive]
>   return *this;
>   ^~~~
>...

This bug is actually in libvmmlib-dev, reassigning.

cu
Adrian

-- 

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

Bug#905299: includes homophobic comments and insults the user

[Jonathan Dowland]

On Thu, Aug 02, 2018 at 05:29:54PM +0100, Jonathan Dowland wrote:

Source: weboob
Version: 0.c-4.1
Severity: normal

Fixed upstream here:

https://git.weboob.org/weboob/devel/merge_requests/228


Checked and present in all of

  o-o-stable: 0.c-4.1
  oldstable: 1.0-3
  stable: 1.2-1
  testing: 1.3-1


I've prepared initial branches in my Salsa fork for stable

   https://salsa.debian.org/jmtd/weboob/tree/905299-stretch

and oldstable

   https://salsa.debian.org/jmtd/weboob/tree/905299-jessie

(But not o-o-stable yet, seems it's not archived so we could)

These probably need to go via stable-proposed-updates, so the Closes
lines will need updating to reflect the release.debian.org bug numbers
once they exist.

I don't know whether you would like to maintain git branches for stable
and oldstable in Salsa? If so I could raise PRs.

Bug#905303: `/usr/share/bash-completion/completions/su` is owned by both util-linux and bash-completion

[Víctor Cuadrado Juan]

Package: util-linux
Version: 2.32-0.3
Severity: critical

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello util-linux maintainer,

Looping in the bash-completion maintainer too.

On a Stretch system with:
  util-linux_2.32-0.3
  bash-completion_1:2.1-4.3

I get an error performing a full-upgrade to Testing, as both packages
own `/usr/share/bash-completion/completions/su`:

```
Preparing to unpack .../util-linux_2.32-0.3_amd64.deb ...
Unpacking util-linux (2.32-0.3) over (2.29.2-1+deb9u1) ...
Replacing files in old package login (1:4.4-4.1) ...
dpkg: error processing archive 
/var/cache/apt/archives/util-linux_2.32-0.3_amd64.deb (--unpack):
 trying to overwrite '/usr/share/bash-completion/completions/su', which is 
also in package bash-completion 1:2.1-4.3   
 
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
dpkg: considering deconfiguration of util-linux, which would be broken by 
installation of login ...
dpkg: no, util-linux is essential, will not deconfigure
 it in order to enable installation of login
dpkg: error processing archive 
/var/cache/apt/archives/login_1%3a4.5-1.1_amd64.deb (--unpack):
 installing login would break existing software
Errors were encountered while processing:
 /var/cache/apt/archives/util-linux_2.32-0.3_amd64.deb
 /var/cache/apt/archives/login_1%3a4.5-1.1_amd64.deb
```



After a brief look at both source packages, I can see that meanwhile the last
util-linux doesn't ship that file, bash-completion does. Also, util-linux
declares a Break and Conflicts with specific versions of bash-completion, so I
have assumed that the bug report goes indeed against util-linux.

Please don't hesitate to reassign or reduce severity if needed.


Kind regards,
Víctor Cuadrado



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

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

Versions of packages util-linux depends on:
ii  fdisk  2.32-0.3
ii  libaudit1  1:2.8.3-1+b1
ii  libblkid1  2.32-0.3
ii  libc6  2.27-5
ii  libmount1  2.32-0.3
ii  libpam0g   1.1.8-3.7
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.32-0.3
ii  libsystemd0239-7
ii  libtinfo6  6.1+20180714-1
ii  libudev1   239-7
ii  libuuid1   2.32-0.3
ii  login  1:4.5-1.1
ii  zlib1g 1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-3
ii  util-linux-locales  2.32-0.3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAltjVJEACgkQIj8Vylqv
Dnge/Af7BhE6AP0QyxzqiBHCu9atZkAzIIYp5QImB7A0T6Jdtp75xmFiNaEafbbI
HkHHvp7T373VeEFN+WoGCcv1atsPNrnuixa5WnEVBg5lbgzQWVOQ/HWtBDlHxybg
MdgzDhZJGM/LMR+UZiIfJdy2YpOsVq4i40ezTgZwRqTn6JjZyPtQtBEjQwxTF6rQ
KeK8rZqxVnkSVX19l710AAeLWPiDjglYE+msxUAqPn5/AJbdt52+AV1+NyQm0z7y
lPbcVxv7SP5cxHNJU5co5nHaJbNli21ebEVABoh+fC3kqWtbOunlI0wlYHL+NX7b
nzioou4jaj91PP3gk/DfH33bN7fJug==
=NKh+
-END PGP SIGNATURE-

Bug#897880: upx-ucl: diff for NMU version 3.94-4.1

[Adrian Bunk]

Control: tags 897880 + patch
Control: tags 897880 + pending
Control: tags 897880 + ftbfs

Dear maintainer,

I've prepared an NMU for upx-ucl (versioned as 3.94-4.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru upx-ucl-3.94/debian/changelog upx-ucl-3.94/debian/changelog
--- upx-ucl-3.94/debian/changelog	2017-12-23 00:25:38.0 +0200
+++ upx-ucl-3.94/debian/changelog	2018-08-02 21:59:33.0 +0300
@@ -1,3 +1,11 @@
+upx-ucl (3.94-4.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Empty CXXFLAGS_WERROR to workaround FTBFS with gcc 8.
+(Closes: #897880)
+
+ -- Adrian Bunk   Thu, 02 Aug 2018 21:59:33 +0300
+
 upx-ucl (3.94-4) unstable; urgency=medium
 
   * Apply Mach-o-defend-against-bad-crafted-input.patch from upstream
diff -Nru upx-ucl-3.94/debian/rules upx-ucl-3.94/debian/rules
--- upx-ucl-3.94/debian/rules	2017-12-23 00:25:38.0 +0200
+++ upx-ucl-3.94/debian/rules	2018-08-02 21:59:33.0 +0300
@@ -27,6 +27,7 @@
 	@echo "Starting build process ($(DEB_HOST_ARCH))"
 	dh_auto_build $(DH_AUTO_OPTIONS) -- \
 		  CXXFLAGS_OPTIMIZE=\
+		  CXXFLAGS_WERROR=  \
 		  CHECK_WHITESPACE= \
 		  UPX_VERSION_GITREV=   \
 	  exeext=   \

Bug#902936: fixed in zutils 1.7-2

[Antonio Diaz Diaz]

Ben Hutchings wrote:

"A buffer overrun has been fixed in zcat which happened sometimes when
the '-v, --show-nonprinting' option was used (or indirectly enabled)."


Thanks, Antonio.  Will you request a CVE ID for this?


No, but I'm fine if somebody else requests it. The kind of vulnerability 
is "Heap-based Buffer Overflow"[1].


[1] http://cwe.mitre.org/data/definitions/122.html


Best regards,
Antonio.

Bug#905162: qt5-qmake-bin: qmake -install qinstall -exe {DIRECTORY} makes a reguler file,not copying directory.

[Dmitry Shachnev]

On Thu, Aug 02, 2018 at 01:48:02PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Please point me to the source package, I want to try this myself.

I found the source here:

https://www.deb-multimedia.org/pool/main/m/mythtv-dmo/mythtv-dmo_29.1-dmo1~bpo9+1.dsc

But I cannot reproduce this (in a fresh sid chroot, after lowering libcec-dev
and libx264-dev required versions).

The generated themes/Makefile correctly has:

install_themes: first FORCE
@test -d $(INSTALL_ROOT)/usr/share/mythtv/themes/ || mkdir -p 
$(INSTALL_ROOT)/usr/share/mythtv/themes/
-$(QINSTALL) /build/mythtv-dmo-29.1/themes/default 
$(INSTALL_ROOT)/usr/share/mythtv/themes/default
-$(QINSTALL) /build/mythtv-dmo-29.1/themes/default-wide 
$(INSTALL_ROOT)/usr/share/mythtv/themes/default-wide
-$(QINSTALL) /build/mythtv-dmo-29.1/themes/classic 
$(INSTALL_ROOT)/usr/share/mythtv/themes/classic
...

Note the usage of $(QINSTALL) instead of $(QINSTALL_PROGRAM) like in your
case.

QINSTALL_PROGRAM will not install directories, it is only for executable
files.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#887809: RFP: borgmatic -- A wrapper script for Borg backup software that creates and prunes backups

[Felix Geyer]

Hi,

On Tue, 31 Jul 2018 11:17:46 +0200 Andrej Shadura  wrote:
> Hi Olivier,
> 
> On Mon, 30 Jul 2018, 13:03 Olivier Berger,
>  wrote:
> > Out of curiosity, have you made any progress towards packaging borgmatic ?>
> 
> Unfortunately, I have not. I figured I don’t really need it myself,
> since I’m just running a one-liner from a systemd timer. I may package
> it one day though, but feel free to take it over.

FWIW the borgmatic dependency pykwalify is considered non-free by Debian because
its license contains the "The Software shall be used for Good, not Evil." 
clause.

https://github.com/Grokzen/pykwalify/blob/master/LICENSE
https://wiki.debian.org/qa.debian.org/jsonevil

Felix

Bug#897889: x42-plugins: ftbfs with GCC-8

[Robin Gareus]

This was fixed upstream early 2018.

check uscan, debian/watch: The latest release is
https://gareus.org/misc/x42-plugins/x42-plugins-20180320.tar.xz
and includes the fix.

Bug#902459: faumachine: FTBFS in buster/sid (error: 'faum_dsdt' undeclared)

[Stefan Potyra]

Hi Santiago,

thanks for reporting the bug!

I cannot reproduce your problem, but I can reproduce the problem of the linked
build log:

gcc -Wchar-subscripts -Wcomment -Wformat -Wnonnull -Wimplicit-int 
-Wimplicit-function-declaration -Wimplicit -Wmain -Wmissing-braces 
-Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs 
-Wunused-function -Wunused-label -Wunused-variable -Wunused-value 
-Wuninitialized -Wunknown-pragmas -Wundef -Wendif-labels -Wshadow 
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return 
-Wstrict-prototypes -Wmissing-noreturn -Wnested-externs -Wunused-local-typedefs 
-Wredundant-decls -Wno-pointer-sign -I. -g -O2 -fno-dse -fno-pie -no-pie  
-L/usr/lib -L/usr/local/lib -o dyngen dyngen-dyngen.o
./dyngen -p chip_intel_80286_op_ -o cpu_286_jit_op_gen.h 
libqemu_gen_286_a-cpu_286_jit_op.o
dyngen: unsupported X86_64 relocation (4)

Reminds me a little bit of 
,
but that may be a false hint.

@Volkmar, can you take a look? Newest git also shows doesn't build on unstable.

Thanks,
  Stefan.


signature.asc
Description: PGP signature

Bug#905302: New upstream version 1.2.1

[Bill Allombert]

Package: cypari2
Version: 1.1.4-3
Severity: wishlist

Hello Debian Science Team,

there is a new upstream version of cypari2 (1.2.1) available.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#897889: x42-plugins: diff for NMU version 20170428-1.2

[Adrian Bunk]

Control: tags 897889 + patch
Control: tags 897889 + pending
Control: tags 897889 + ftbfs

Dear maintainer,

I've prepared an NMU for x42-plugins (versioned as 20170428-1.2) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

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

diff -Nru x42-plugins-20170428/debian/changelog x42-plugins-20170428/debian/changelog
--- x42-plugins-20170428/debian/changelog	2018-03-20 20:30:37.0 +0200
+++ x42-plugins-20170428/debian/changelog	2018-08-02 21:10:13.0 +0300
@@ -1,3 +1,11 @@
+x42-plugins (20170428-1.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add upstream patch for FTBFS with gcc 8,
+thanks to Juhani Numminen. (Closes: #897889)
+
+ -- Adrian Bunk   Thu, 02 Aug 2018 21:10:13 +0300
+
 x42-plugins (20170428-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru x42-plugins-20170428/debian/patches/0001-Fix-FTBS-with-gcc-8.patch x42-plugins-20170428/debian/patches/0001-Fix-FTBS-with-gcc-8.patch
--- x42-plugins-20170428/debian/patches/0001-Fix-FTBS-with-gcc-8.patch	1970-01-01 02:00:00.0 +0200
+++ x42-plugins-20170428/debian/patches/0001-Fix-FTBS-with-gcc-8.patch	2018-08-02 21:10:13.0 +0300
@@ -0,0 +1,30 @@
+From 06d32a0a9bd670925c4dd3e8097c3ae120d6e3e4 Mon Sep 17 00:00:00 2001
+From: Guido Aulisi 
+Date: Thu, 15 Feb 2018 13:47:53 +0100
+Subject: Fix FTBS with gcc 8
+
+complex operator""i are declared in the namespace std::literals::complex_literals
+http://en.cppreference.com/w/cpp/numeric/complex/operator%22%22i
+
+Somehow gcc 8 is less permissive than gcc 7
+---
+ src/spectr.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/spectr.c b/src/spectr.c
+index 665ad4f..e9e06cc 100644
+--- a/tuna.lv2/src/spectr.c
 b/tuna.lv2/src/spectr.c
+@@ -31,6 +31,9 @@
+ # define creal(XX) std::real(XX)
+ # define cimag(XX) std::imag(XX)
+ # define _I ((complex_t)(1i))
++  #ifdef __cpp_lib_complex_udls
++using namespace std::literals::complex_literals;
++  #endif
+   typedef std::complex complex_t;
+ #else
+ # include 
+-- 
+2.11.0
+
diff -Nru x42-plugins-20170428/debian/patches/series x42-plugins-20170428/debian/patches/series
--- x42-plugins-20170428/debian/patches/series	2018-03-20 20:30:34.0 +0200
+++ x42-plugins-20170428/debian/patches/series	2018-08-02 21:10:13.0 +0300
@@ -1 +1,2 @@
 pow10f.patch
+0001-Fix-FTBS-with-gcc-8.patch

Bug#868724: debian/watch file for the ledgersmb package

[Shengjing Zhu]

On Fri, Aug 3, 2018 at 1:25 AM Robert James Clay  wrote:
> Running, for instance, the command "uscan --force-download --verbose --rename 
> --destdir .." results in the error "BAD signature".  And indeed, checking the 
> resulting files from that command  finds that the archive does look to have 
> been repacked (it's smaller) and so the verify fails.

Not about repack, current watch file will download tarball that github
generated, not the one upstream uploading to github release. Look at
https://github.com/ledgersmb/LedgerSMB/releases, please be careful
that there're two kinds of tarball. Don't look at
https://github.com/ledgersmb/LedgerSMB/tags, which doesn't have asc
signatures.

And I think using upstream http release page is much simpler for you.

-- 
Best regards,
Shengjing Zhu

Bug#905301: eject: When I want to open the CD-ROM drive, either it does nothing or the CD-ROM drive starts to open but it goes back and closes.

[Gilles CHARABOT]

Package: eject
Version: 2.1.5+deb1+cvs20081104-13.2
Severity: normal

Dear Maintainer, when I want to open the CD-ROM drive, in most cases, either it 
does nothing or the CD-ROM drive starts to open but it goes back and closes. 
I have to start over many times before this succeeds. Either with the nautilus 
graphical interface by clicking on the "Eject" icon associated
 with the CD-ROM or by using the command line interface as :

$ eject -v /dev/sr0

or

# eject -v /dev/sr0




An exemple when I use gdb and the eject command says it was successful when it 
failed.

++
# gdb eject
GNU gdb (Debian 8.1-4) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from eject...(no debugging symbols found)...done.
(gdb) run -v /dev/sr0
Starting program: /usr/bin/eject -v /dev/sr0
/usr/bin/eject: le nom du périphérique est `/dev/sr0'
/usr/bin/eject: le nom étendu est `/dev/sr0'
/usr/bin/eject: `/dev/sr0' n'est pas monté
/usr/bin/eject: `/dev/sr0' n'est pas un point de montage
/usr/bin/eject: `/dev/sr0' n'est pas un périphérique partitionné
/usr/bin/eject: tentative d'éjection `/dev/sr0' avec la commande d'éjection du 
CD-ROM
/usr/bin/eject: la commande d'éjection du CD-ROM n'a pas réussi
/usr/bin/eject: tentative d'éjection `/dev/sr0' avec la commande SCSI
/usr/bin/eject: la commande d'éjection SCSI a réussi
[Inferior 1 (process 12277) exited normally]
(gdb) quit



I am lucky ! An exemple when CD-ROM drive succeds to open viewed with strace :

+
$ strace  eject -v /dev/sr0
execve("/usr/bin/eject", ["eject", "-v", "/dev/sr0"], 0x7ffc57abe9c0 /* 51 vars 
*/) = 0
brk(NULL)   = 0x562cf5184000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=124976, ...}) = 0
mmap(NULL, 124976, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f89d19aa000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\,\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1808440, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f89d19a8000
mmap(NULL, 1821408, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f89d17eb000
mmap(0x7f89d180d000, 1335296, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f89d180d000
mmap(0x7f89d1953000, 307200, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x168000) = 0x7f89d1953000
mmap(0x7f89d199e000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b2000) = 0x7f89d199e000
mmap(0x7f89d19a4000, 15072, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f89d19a4000
close(3)= 0
arch_prctl(ARCH_SET_FS, 0x7f89d19a9540) = 0
mprotect(0x7f89d199e000, 16384, PROT_READ) = 0
mprotect(0x562cf3655000, 4096, PROT_READ) = 0
mprotect(0x7f89d19f, 4096, PROT_READ) = 0
munmap(0x7f89d19aa000, 124976)  = 0
brk(NULL)   = 0x562cf5184000
brk(0x562cf51a5000) = 0x562cf51a5000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1683120, ...}) = 0
mmap(NULL, 1683120, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f89d165
close(3)= 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2995
read(3, "", 4096)   = 0
close(3)= 0
openat(AT_FDCWD, "/usr/share/locale/fr_FR.UTF-8/LC_MESSAGES/eject.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/fr_FR.utf8/LC_MESSAGES/eject.mo", O_RDONLY) 
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 

Bug#905300: gfan: FTBFS on 32bit architectures: test 0602ResultantFanProjection hangs

[Andreas Beckmann]

Source: gfan
Version: 0.6.2-1~exp1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

gfan/experimental FTBFS on all 32bit architectures since a test hangs:

https://buildd.debian.org/status/package.php?p=gfan=experimental

[...]
Running command:"cat testsuite/0602ResultantFanProjection/outputNew"
E: Build killed with signal TERM after 150 minutes of inactivity


Andreas

Bug#902631: devscripts: CI fails in unstable due to Python 3.7

[Bastian Blank]

Hi

I miss any description of the real problem.  You only describe
solutions, but you forget to mention why the easiest solution, just
upgrade both sources, does not work.  Sure, some of the points can be
found in the bug report.

On Thu, Aug 02, 2018 at 12:39:18PM -0400, Sandro Tosi wrote:
> astroid: on the 1.x branch, builds python-astroid and python3-astroid
> pylint: on the 1.x branch, builds pylint (depends on python-astroid),
> pylint3 (depends on python3-astroid), pylint-doc
> 
> the only way forward to keep compat with python2 while supporting 3.7 i see 
> is:
> 
> astroid: uses the 2.x branch, builds only python3-astroid

Why can't this build python-astroid?

> pylint: uses the 2.x branch, builds only pylint3, pylint-doc

Why can't this build pylint?

> NEW astroid2: remains on the 1.x branch, builds only python-astroid
> NEW pylint2: remains on the 1.x branch, builds only pylint (depending
> on python-astroid)

Given that pylint is a program and no library, why do we need both
pylint and pylint3?

Regards,
Bastian

-- 
We'll pivot at warp 2 and bring all tubes to bear, Mr. Sulu!

Bug#905253: Processed: python-txtorcon: fails to install with Python 3.7

[meejah]

Matthias Klose  writes:

> this is wrong.  Please note that the error is in the Python 2.7 package ...
> There are probably files which should not be included in the Python2 package.

The current strategy for "python3-only" code in txtorcon is the naming
scheme (*_py3.py) and that could won't be imported in python2 so it
should be fine to delete it / not ship it in a python2 package.

(That's currently the ONLY python3 code). If there's a better way to
accomplish this, I'm happy to change txtorcon.

-- 
meejah

Bug#902631: devscripts: CI fails in unstable due to Python 3.7

[Pierre-Elliott Bécue]

Le jeudi 02 août 2018 à 19:32:15+0200, Bastian Blank a écrit :
> [why should one package two source packages?]

See [1] and following posts. astroid 2.0 dropped the support for Python2.

Regards,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902631#77

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#903135: intel-microcode: Kabby Lake microcode rev 0x84 instead of rev 0x8e

[E. B.]

Just today my machine pulled this update

amd64-microcode (3.20180524.1~ubuntu0.18.04.2)

Should this message go away on the next reboot?

Bug#868724: debian/watch file for the ledgersmb package

[Robert James Clay]

All,  

The upstream for the ledgersmb package [1] moved from Sourceforge to GitHub
including for where new releases of the application are made available; so
the debian/watch file in the package needed to be`updated for the new
locations of the distribution archive and its detached`gpg file that is used
for verification.  Updating the watch file [2] so that uscan can see new
releases was successful but  the *.asc file associated with the new releases
and used for the gpg verification does not seem to get referenced properly so
the verification step fails. (Or the verify is happening after the repack for
some reason but before renaming the archive?  It's not clear...) Since the
verify step is failing, the step for doing the repack of the archive does not
happen. Manually downloading then verifying the archive can be done
successfully although then repacking the upstream archive also has to done
manually.  The download, verify, and repacking was successful at the time
when the watch file was pointing to the old SourceForge site.  

Running, for instance, the command "uscan --force-download --verbose --rename
--destdir .." results in the error "BAD signature".  And indeed, checking
the resulting files from that command  finds that the archive does look to
have been repacked (it's smaller) and so the verify fails.  

The current upstream version in Debian is 1.5.21 but 1.6.3 has been
released;  I'll be working on upgrading the packaging for the new series.  

I'd appreciate if the current version of the debain/watch file be reviewed
and advice given about how it could be updated to work properly.  Besides the
new releases being available at github (via their tags), they are also
available at a separate upstream site [3];  I wonder if it would be better
to try using that?

  

   

Robert James Clay, j...@rocasa.us, rjc...@gmail.com  

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

[2] https://sources.debian.org/src/ledgersmb/1.5.21+ds-1/debian/watch/  

[3] https://download.ledgersmb.org/f/Releases/  

 

Bug#905235: emacs-goodies-el failed to install due to old broken symlinks

[Nicholas D Steeves]

stretch2buster: installed emacs-nox (uses emacs24-nox)
installed emacs-goodies-el
modified /etc/apt/sources.list and ran dist-upgrade
  - to buster
dist-upgrade succeeded
emacs-goodies-el 36.3+nmu1 to 40.0 succeeded
  - installed 40.0 with dpkg on top of buster's 39.9

Automated piuparts are also good:
  https://piuparts.debian.org/sid/source/e/emacs-goodies-el.html

I'll keep an eye on the piuparts page.

Were you using aptitude when this bug was triggered?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#905239: adding usertag

[Nicholas D Steeves]

user debian-emac...@lists.debian.org
usertags 905239 elpafy
thanks


signature.asc
Description: PGP signature

Bug#813855: rubber: doesn't generate PDF figures when elsarticle.cls is in the local directory

[Nicolas Boulenguez]

Package: rubber
Version: 1.4-3
Followup-For: Bug #813855
Control: retitle -1 graphicx module confused if required by a local class

Here is a small reproducer.

The graphicx module is registered once inside c.cls.
It thinks that the main document is c.cls,
and does not manage to guess if foo.eps or foo.pdf is wanted.

foo.fig: (any fig file)
c.cls:
  \LoadClass{article}
  \RequirePackage{graphicx}
doc.tex:
  \documentclass{c}
  \usepackage{graphicx}
  \begin{document}
  \includegraphics{foo}
  \end{document}

Bug#900813: vm: fails to byte-compile with unversioned emacs

[Ian Jackson]

I'm just a user of VM but I need it to stay in Debian.  Accordingly I
intend to NMU this time very soon.  I may well make mistakes.  Hints
and tips welcome.

Manoj, if you don't want me to NMU this please upload a fix
immediately.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#905299: includes homophobic comments and insults the user

[Jonathan Dowland]

Source: weboob
Version: 0.c-4.1
Severity: normal

Fixed upstream here:

https://git.weboob.org/weboob/devel/merge_requests/228


Checked and present in all of

   o-o-stable: 0.c-4.1
   oldstable: 1.0-3
   stable: 1.2-1
   testing: 1.3-1

I will next test cherry-picking that patch for the Debian package.

-- System Information:
Debian Release: 9.4
 APT prefers stable
 APT policy: (990, 'stable'), (600, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.12-x86_64-linode105 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#883950: Next steps on "[GPL-3+]" proposal

[Russ Allbery]

Markus Koschany  writes:

> You appear more concerned about one parser, Lintian, than about the
> human maintainers who have to update d/copyright again.  You argue that
> the maintainers have to update d/copyright anyway, I say fixing the tool
> is far more efficient because it affects far less human beings.

You seem to be assuming that Lintian is the only validating parser.  One,
this is definitely not true, and two, the entire point of having a
standard for machine-readable copyright files is so that anyone can write
a parser without consulting with us first.  Part of the guarantee in
creating a standard is that the interface is the standard.  We should
assume there are an unknown number of implementations of that standard in
the wild and do the right thing when updating the standard so that they
can track future changes.

Also, again, no human maintainers have to update anything if they don't
want to.  The 1.0 format isn't going anywhere.  We would continue to
publish it; that was the agreement we reached when we versioned it in the
first place.  So I don't understand your insistance that this creates work
for people.

It's possible that Lintian might ask people to switch to the new version
as some sort of lower-priority tag, but that's no more work than bumping
the Standards-Version of a package and is the sort of thing that one can
do via automated tooling or when one feels like it or even ignore without
harm for an extended period of time.

> I also recommend to avoid a discussion about new fields and considering
> the inclusion of SPDX identifiers to "solve" this issue. While I'm
> absolutely not against the latter, I believe it should be discussed in a
> separate bug report.

Yup, that's fine -- I agree that should be in a separate bug report.

> As I previously tried to explain I don't feel that there is a compelling
> reason for such a new version number because there is no severe
> backwards-incompatible change. I can see where are you coming from but
> the "consumer" is a tool called Lintian, not really impossible to solve.

Okay.  I think I understand your argument and viewpoint.  I'm not at all
persuaded by it, I'm afraid.  We definitely need a version change for
this.

> Well, to me it looks like he didn't recognize it because there isn't any
> but let's just ask him again to be sure. (that's probably the discussion
> in #904729)

Even if he agrees with you, that doesn't change my position, just for the
record.  So I'm not sure this is going to achieve what you want it to
achieve.  :)

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

Bug#902631: devscripts: CI fails in unstable due to Python 3.7

[Pierre-Elliott Bécue]

Le jeudi 02 août 2018 à 12:39:18-0400, Sandro Tosi a écrit :
> there are currently 2 source packages:
> 
> astroid: on the 1.x branch, builds python-astroid and python3-astroid
> pylint: on the 1.x branch, builds pylint (depends on python-astroid),
> pylint3 (depends on python3-astroid), pylint-doc
> 
> the only way forward to keep compat with python2 while supporting 3.7 i see 
> is:
> 
> astroid: uses the 2.x branch, builds only python3-astroid
> pylint: uses the 2.x branch, builds only pylint3, pylint-doc
> NEW astroid2: remains on the 1.x branch, builds only python-astroid
> NEW pylint2: remains on the 1.x branch, builds only pylint (depending
> on python-astroid)
> 
> astroid2 and pylint2 will be dropped after buster is released, keeping
> only astroid and pylint in bullseye
> 
> adding ftpmasters in the loop as a headsup since this plan would
> require a bit of coordination to reduce users disruption during the
> migration of the bin pkgs from one src pkg to the new ones.
> 
> what people feel about it? just to make it clear: i'm not really
> excited about the package duplication, although it's the only viable
> solution i can see for now. comments/suggestions welcome

That seems, for me, the best solution, provided it's temporary (which we all
agree on). I had a look on porting the changes to 1.x from 2.x that would
allow python3-astroid to work properly, and it seems quite a lot of work
with a mixed outcome.

If you wish, I'm eager to contribute into implementing this solution, but
keep in mind that, as a DM, I'll eventually require your help to upload
these packages.

If you prefer to handle this on your own, it's fine with me, too.

Thanks for considering, and cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#905298: ITP: virtualpg -- Loadable dynamic extension to both SQLite and SpatiaLite

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: virtualpg
  Version : 1.0.2
  Upstream Author : Alessandro Furieri 
* URL : https://www.gaia-gis.it/fossil/virtualpg
* License : MPL-1.1 or GPL-2+ or LGPL-2.1+
  Programming Lang: C
  Description : Loadable dynamic extension to both SQLite and SpatiaLite

VirtualPG is a loadable dynamic extension to both SQLite and SpatiaLite.

Its intended scope is supporting direct SQL access to PostgreSQL and
PostGIS tables, to make any possible kind of data exchange between
these two popular open source Spatial DBMSes as straightforward and
simple as possible.


virtualpg is required for spatialite-gui 2.1.0, and will be maintained
alongside spatialite, spatialite-gui & postgis in the Debian GIS team.

Bug#868409: verbiste: Please drop the (build-)dependency against gnome-vfs

[Tomasz Buchert]

On 27/07/18 13:04, Nicholas D Steeves wrote:
> [...]

Hey all,
sorry for extremely long lag in fixing this...

Anyway, I went with Nicholas' suggestion and added verbiste-gtk,
whereas verbiste-gnome is now transitional. Feel free to review it:
https://salsa.debian.org/debian/verbiste

As for verbiste-el, I've created https://bugs.debian.org/905290. I'd
actually ask for help with this, I'm pretty bad at emacs
packaging. Pull requests are welcome! :D

Tomasz


signature.asc
Description: PGP signature

Bug#905162: qt5-qmake-bin: qmake -install qinstall -exe {DIRECTORY} makes a reguler file,not copying directory.

[Lisandro Damián Nicanor Pérez Meyer]

tag 905162 moreinfo
thanks

Hi!

El martes, 31 de julio de 2018 23:51:03 -03 Kyuma Ohta escribió:
> Package: qt5-qmake-bin
> Version: 5.11.1+dfsg-6
> Severity: normal
> 
> Dear Maintainer,
> 
>  Building some projects using qmake build system,
> installing contents under directory fails.
> 
>  For example, building MythTV-dmo (probided by deb-multimedia.org)
> with debuild, installing contents under themes/ to debian/tmp/
> fails.

Please point me to the source package, I want to try this myself.



-- 
Si vives cada día de tu vida como si fuera el último,
algún día realmente tendrás razón.
  Steve Jobs

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#902631: devscripts: CI fails in unstable due to Python 3.7

[Sandro Tosi]

there are currently 2 source packages:

astroid: on the 1.x branch, builds python-astroid and python3-astroid
pylint: on the 1.x branch, builds pylint (depends on python-astroid),
pylint3 (depends on python3-astroid), pylint-doc

the only way forward to keep compat with python2 while supporting 3.7 i see is:

astroid: uses the 2.x branch, builds only python3-astroid
pylint: uses the 2.x branch, builds only pylint3, pylint-doc
NEW astroid2: remains on the 1.x branch, builds only python-astroid
NEW pylint2: remains on the 1.x branch, builds only pylint (depending
on python-astroid)

astroid2 and pylint2 will be dropped after buster is released, keeping
only astroid and pylint in bullseye

adding ftpmasters in the loop as a headsup since this plan would
require a bit of coordination to reduce users disruption during the
migration of the bin pkgs from one src pkg to the new ones.

what people feel about it? just to make it clear: i'm not really
excited about the package duplication, although it's the only viable
solution i can see for now. comments/suggestions welcome

-- 
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#905297: ITP: saaj-ri -- SOAP with Attachments API for Java - Reference Implementation

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 
User: debian-j...@lists.debian.org
Usertags: default-java11

* Package name: saaj-ri
  Version : 1.4.1
  Upstream Author : Oracle Corporation
* URL : https://javaee.github.io/metro-saaj/
* License : CDDL-1.1 or GPL-2 with Classpath exception
  Programming Lang: Java
  Description : SOAP with Attachments API for Java - Reference 
Implementation

The SOAP with Attachments API for Java (SAAJ) provides the API for creating
and sending SOAP messages by means of the javax.xml.soap package. It is used
for the SOAP messaging that goes on behind the scenes in JAX-WS, JAX-RPC,
and JAXR implementations. SOAP Handlers in JAX-WS use SAAJ APIs to access
the SOAP Message. Developers can also use it to write SOAP messaging
applications directly instead of using JAX-WS/JAX-RPC.

The package will be maintained by the Java Team. It's required to build
the JAX-WS reference implementation. JAX-WS was previously embedded
in the JDK but will be removed in Java 11.

Bug#905296: pyvo: autopkgtest regression: 'module' object has no attribute 'tools'

[Paul Gevers]

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

Dear maintainer(s),

Since the upload of version 0.8.1-1 the autopkgtest of your package
started to fail. I have copied the output below.

Could you please investigate? Currently this failure is contributing to
delaying migration to testing with 13 days.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyvo/754662/log.gz

autopkgtest [09:38:10]: test python-pyvo: [---
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.hgq2qi_p/downtmp/build.r4H/src/debian/tests/python-pyvo",
line 4, in 
assert pyvo.tools.plainxml.xml._MINIMUM_XMLPLUS_VERSION
AttributeError: 'module' object has no attribute 'tools'
autopkgtest [09:38:11]: test python-pyvo: ---]



signature.asc
Description: OpenPGP digital signature

Bug#905295: mc: Only pretends to edit files on sh:// mounts

[Axel]

Package: mc
Version: 3:4.8.18-1
Severity: normal

Dear Maintainer,

if Vim is called as the external editor on a file in a directory mounted via 
MC's sh://
capability, it appears to be writable and reflects all changes — until MC is 
ended. No
changes are written to the actual file on the remote machine. All changes are 
silently
lost as there are no error messages or warnings.

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

Kernel: Linux 4.14.0-0.bpo.2-686 (SMP w/1 CPU core)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mc depends on:
ii  e2fslibs  1.43.4-2
ii  libc6 2.24-11+deb9u3
ii  libglib2.0-0  2.50.3-2
ii  libgpm2   1.20.4-6.2+b1
ii  libslang2 2.3.1-5
ii  libssh2-1 1.7.0-1
ii  mc-data   3:4.8.18-1

Versions of packages mc recommends:
ii  mime-support  3.60
ii  perl  5.24.1-3+deb9u4
ii  unzip 6.0-21

Versions of packages mc suggests:
pn  arj  
ii  atril [pdf-viewer]   1.16.1-2+deb9u1
ii  bzip21.0.6-8.1
pn  dbview   
pn  djvulibre-bin
ii  evince [pdf-viewer]  3.22.1-3+deb9u1
ii  file 1:5.30-1+deb9u1
ii  genisoimage  9:1.1.11-3+b2
ii  gv [pdf-viewer]  1:3.7.4-1+b1
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u4
pn  libaspell-dev
pn  links | w3m | lynx   
pn  odt2txt  
ii  poppler-utils0.48.0-2+deb9u2
ii  python   2.7.13-2
pn  python-boto  
pn  python-tz
ii  texlive-binaries 2016.20160513.41080.dfsg-2
ii  zip  3.0-11+b1

-- no debconf information

Bug#905285: tlp activates suspend even when on AC

[Raphaël Halimi]

Le 02/08/2018 à 16:30, alberto a écrit :
> I just substituted my stolen thinkpad x250 with a x270.

Sorry for your loss. I experienced that myself in late 2012, this is a
terrible experience. Fortunately, mine was fully encrypted, and I had a
recent (less than one week) full backup. I hope you took the same
precautions.

> Despite that tlp-stat reports correctly that the power source is AC, tlp
> always starts the suspend process after some inactivity even if I configured
> PM (through xfce GUI) not to suspend on AC.
> 
> This is the log:
> 
> Aug  2 11:20:26  systemd[1]: Starting TLP suspend/resume...
> Aug  2 11:20:26  systemd[1]: Started TLP suspend/resume.
> Aug  2 11:20:26  systemd[1]: Reached target Sleep.
> Aug  2 11:20:26  systemd[1]: Starting Restart Syncthing after resume...
> Aug  2 11:20:26  systemd[1]: Starting Suspend...
> Aug  2 11:20:26  systemd[1]: Started Restart Syncthing after resume.
> Aug  2 11:20:26  systemd-sleep[11509]: Suspending system...
> Aug  2 11:20:26  kernel: [ 1685.988411] PM: suspend entry (deep)
> 
> Note that this never happened with the x250.
> 
> BTW, I tried to perform some diagnostics but I could not find anything.
> I do not even find a proper setting to avoid this (tried searching into
> /etc/default/tlp).

Are you positively sure that it's not something triggered by XFCE ?
AFAIK, TLP doesn't activate suspend at all (hence the lack of such a
setting in the configuration file). You may have been mislead by the log
messages showing "TLP suspend/resume", which merely indicate that TLP's
pre/post suspend hooks are being run.

I don't know XFCE very well, so I'll ask you to double-check every
setting even remotely related to power management. Also, if you want to
be absolutely sure, try to purge TLP, and see if your computer still
exhibits the same behavior.

> I don't know if this is relevant but I found other stuffs related to
> thinkpad in syslog:
> 
> Aug  2 15:57:13  kernel: [ 7848.767292] thinkpad_ec: 
> thinkpad_ec_request_row: arg0 rejected: (0x01:0x00)->0x00
> Aug  2 15:57:13  kernel: [ 7848.767298] thinkpad_ec: 
> thinkpad_ec_read_row: failed requesting row: (0x01:0x00)->0xfffb
> Aug  2 15:57:13  kernel: [ 7848.767305] thinkpad_ec: initial ec test 
> failed
> 
> In addition, tlp-stat says:
> +++ ThinkPad Battery Features
> tp-smapi   = inactive (unsupported hardware)
> tpacpi-bat = active
> 
> and, actually, I can use tlp BAT settings even without smapi.

That's perfectly normal. Lenovo discarded the SMAPI interface starting
with the X230 (read [1]). Newer models must use tpacpi-bat (which uses
acpi-call) to set the battery (dis)charge thresholds.

This also explains your error messages emanating from thinkpad_ec : it
can't find the interface it's looking for.

Normally, on your X270, you shouldn't install tp-smapi-dkms, but
acpi-call-dkms instead.

I'm not sure about the improved hdaps driver, though, but I guess you
got an SSD with your new X270, so you shouldn't need it anyway.

[1] http://www.thinkwiki.org/wiki/Tp_smapi

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#905167: debmake-doc: Handling Upstream Autotools Packaging on Debian

[Osamu Aoki]

Hi,

Thank you for your very detailed review.

On Tue, Jul 31, 2018 at 11:12:12PM -0700, Paul Hardy wrote:
> Package: debmake-doc
> Version: 1.9-1
> Tags: patch
> 
> Section 5.16.1 recommends running autoreconf when building a package
> on Debian GNU/Linux, to improve portability to new systems.

Actually, this part needs some updates since recent debhelper depends on
the dh-autoreconf package and runs it as the default behavior since
debhelper 9.20160402/02 Apr 2016.

After:
| The package maintainer may wish to take care all steps 1 to 4. This is
| realized by the “dh $@ --with autoreconf” command used in the
| debian/rules file. This rebuilds all auto-generated files to the latest
| version ones and provides better supports for the porting to the newer
| architectures.

Let's add:
| For compat level 10 or newer, the simple “dh $@” command without
| "--with autoreconf" option can take care all steps 1 to 4, too.

> That
> brings with it considerations about automake.  The default
> "strictness" level of an automake setup is the "gnu" level, which
> requires files AUTHORS, ChangeLog, INSTALL, NEWS, and README along
> with the Makefile.am and configure.ac files that autoreconf will
> expect.  That then brings other implications for using such a package
> on Debian.

Hmmm I had a different thought and intentionally chose "foreign".

> Elsewhere, the document refers to the GNU Coding Standards, which is
> further reason to make mention of the above files, and which get
> installed and which do not get installed (COPYING and INSTALL) on
> Debian.

This tutorial is about packaging an upstream source ... not about
creating an upstream source to be uploaded to the GNU project.

I also find many packages on Debian uses "foreign".  Upstream source on
git may not have NEWS and ChangeLog.  So making simpler example is good
for entry level document.  Another POV I checked is:

  https://autotools.io/automake/options.html#automake.options.flavors

> I propose that wording like what follows be considered for the end of
> Section 8.9 or 8.11.  Both of those examples set the automake

I think adding a short pointer to remind automake defaults to gnu flavor
may be a good idea around Section 8.9.  But I don't think I should
elaborate too much in detail.  If we do so, this tutorial get bloated
and reader will lose important things to learn about the Debian
packaging.

After "configure.ac (v=1.6): " example, add:

TIP: Without "foreign" strictness level specified in AM_INIT_AUTOMAKE()
as above, automake defaults to "gnu" strictness level requiring several
files in the top-level directory.  See "3.2 Strictness" in the automake
document.


> The other files besides Makefile.am and configure.ac that Autotools
> expects in the top-level directory (AUTHORS, NEWS, README, and
> ChangeLog) can be installed in /usr/share/doc/.

This is fair point to be reminded.  Place to do is at:
  5.12. Customization of the Debian packaging

Now:

* The Debian package build system can be customized through the
  debian/rules file (see Section 5.4.3, “Customized debian/rules”).

* The Debian package installation path etc. can be customized through
  the addition of configuration files in the debian/ directory for the
  dh_* commands from the debhelper package (see Section 5.11, “Other
  debian/*”).


Proposed:

* The Debian package build system can be customized through the
  debian/rules file (see Section 5.4.3, “Customized debian/rules”).

* The Debian package installation path etc. can be customized through
  the addition of configuration files such as "package.doc" and
  "package.install" in the debian/ directory for the dh_* commands from
  the debhelper package (see Section 5.11, “Other debian/*”).


> This
> can be done by listing those files in debian/doc.  If you keep any
> Autotools-generated files in the Debian package, make sure that
> those files have their copyright and license information captured
> in the debian/copyright file.  Their copyright notices and license
> terms differ slightly, so you will have to check every one.  The
> GNU Project standard practice is to leave all such files in place
> if a "make distclean" leaves them, so asking upstream to remove
> them is probably not the correct solution.

Should we have to dwell on these?  It's good practice but ...
 
> Running "autoreconf -ivf"  as described in Section 5.16.1 will create
> a new INSTALL file even if one existed.i

As written there, this is run by the upstream.

>  That file will have a copyright,
> as will the GPL or LGPL in the COPYING or COPYING.LESSER file.  Therefore,
> list those files in the Files-Exclude field in the first paragraph of
> debian/copyright.

??? What ???

Files-Exclude field is for different purpose and effect.  Please check
the uscan manpage and mk-origtargz manpage.

Files-Excluded or Files-Excluded-component stanzas are set in
debian/copyright to make mk-origtargz invoked from uscan remove
files 

Bug#905176: ganeti: fails to upgrade from 'stretch': removal of ganeti-{haskell,htools}-2.15 fails

[Apollon Oikonomopoulos]

Control: tag -1 - moreinfo

Hi,

On 13:50 Thu 02 Aug , Andreas Beckmann wrote:
> Control: tag -1 moreinfo
> Control: severity -1 important
> 
> On 2018-08-02 09:00, Apollon Oikonomopoulos wrote:
> > Finally, I want to stress again that the root cause of all this is the 
> > flawed libcurl3 → libcurl4 transition: if the OpenSSL API changes the 
> 
> Let's wait for libcurl3 to leave testing, that might clean up the
> upgrade path automatically. The pure existence of libcurl3 in testing
> causes trouble on a few other upgrade paths as well, since it is not
> always considered as a candidate for removal.
> 
> If that doesn't work, ganeti might need to add Breaks or Conflicts
> against ganeti-{haskell,htools}-2.15 to ensure they are removed before
> the new ganeti is unpacked. This should hopefully be resolvable without
> updating the version in stable.

Unfortunately this won't help: ganeti-*-2.15 and ganeti-*-2.16 are 
designed to be co-installable (hence the different package names)
and in fact they must both be installed and configured for the cluster 
upgrade to take place. IOW, the intended behavior when dist-upgrading is 
to end up with *both* sets of packages installed and configured, and 
Breaks/Replaces defeats this purpose.

As libcurl4 and libcurl3 conflict, a set of packages that collectively 
depends on both will not be installable. So we'll either need a version 
of ganeti-*-2.15 that depends on libcurl4 in buster (because we can't 
have it in stretch, as stretch doesn't have libcurl4), or a version that 
uses a different libcurl variant in stretch (and buster presumably).

I tend to think the former is more robust.

Apollon

Bug#905294: git-cola: missing Depends: python3-distutils

[Andreas Beckmann]

Package: git-cola
Version: 3.1-1
Severity: serious

$ git-cola
Traceback (most recent call last):
  File "/usr/bin/git-cola", line 55, in 
from cola.main import main
  File "/usr/share/git-cola/lib/cola/main.py", line 7, in 
from . import app
  File "/usr/share/git-cola/lib/cola/app.py", line 13, in 
from . import core
  File "/usr/share/git-cola/lib/cola/core.py", line 9, in 
import distutils.spawn as spawn
ModuleNotFoundError: No module named 'distutils.spawn'


Andreas

Bug#905293: python3-datalad: missing Depends: python3-distutils

[Andreas Beckmann]

Package: python3-datalad
Version: 0.10.2-1
Severity: serious

$ datalad
Traceback (most recent call last):
  File "/usr/bin/datalad", line 7, in 
from datalad.cmdline.main import main
  File "/usr/lib/python3/dist-packages/datalad/__init__.py", line 24, in 

GitRunner._check_git_path()
  File "/usr/lib/python3/dist-packages/datalad/cmd.py", line 620, in 
_check_git_path
from distutils.spawn import find_executable
ModuleNotFoundError: No module named 'distutils.spawn'


Andreas

Bug#888374: gmerlin-avdecoder: FTBFS with FFmpeg 4.0

[peter green]

tags 888374 +patch
thanks

Since this package has rdeps and there seemed to be no maintainer response I 
decided to take a look.

The good news is I got it building, the bad news is that in order to do so I 
had to disable vdpau support. It seems that struct vdpau_render_state has 
disappeared and I have no idea what if anything it can be replaced with.

Anyway the debdiff is attatched, no intent to NMU in Debian.


diff -Nru gmerlin-avdecoder-1.2.0~dfsg/debian/changelog 
gmerlin-avdecoder-1.2.0~dfsg/debian/changelog
--- gmerlin-avdecoder-1.2.0~dfsg/debian/changelog   2017-01-31 
07:37:57.0 +
+++ gmerlin-avdecoder-1.2.0~dfsg/debian/changelog   2018-08-02 
14:55:06.0 +
@@ -1,3 +1,13 @@
+gmerlin-avdecoder (1.2.0~dfsg-9+rpi1) buster-staging; urgency=medium
+
+  * Fix FTBFS with ffmpeg 4.0
++ Fixup renamed constants
++ Disable vdpau, struct vdpau_render_state has disappeard and I hae no 
idea what if anything
+  it can be replaced with.
+  * Remove po/de.gmo in clean target, it seems that the build process changes 
it.
+
+ -- Peter Michael Green   Thu, 02 Aug 2018 14:55:06 
+
+
 gmerlin-avdecoder (1.2.0~dfsg-9) unstable; urgency=medium
 
   * Team upload
diff -Nru gmerlin-avdecoder-1.2.0~dfsg/debian/patches/ffmpeg_4.0.patch 
gmerlin-avdecoder-1.2.0~dfsg/debian/patches/ffmpeg_4.0.patch
--- gmerlin-avdecoder-1.2.0~dfsg/debian/patches/ffmpeg_4.0.patch
1970-01-01 00:00:00.0 +
+++ gmerlin-avdecoder-1.2.0~dfsg/debian/patches/ffmpeg_4.0.patch
2018-08-02 14:55:06.0 +
@@ -0,0 +1,101 @@
+Description:  Fix FTBFS with ffmpeg 4.0
+ Update constant names for ffmpeg 4.0
+Author: Peter Michael Green 
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: , 
+Bug: 
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Reviewed-By: 
+Last-Update: 2018-08-02
+
+Index: gmerlin-avdecoder-1.2.0~dfsg/lib/audio_ffmpeg.c
+===
+--- gmerlin-avdecoder-1.2.0~dfsg.orig/lib/audio_ffmpeg.c
 gmerlin-avdecoder-1.2.0~dfsg/lib/audio_ffmpeg.c
+@@ -189,7 +189,7 @@ static int fill_buffer(bgav_stream_t * s
+ bgav_dprintf("Got packet\n");
+ bgav_packet_dump(p);
+ #endif
+-bgav_bytebuffer_append(>buf, p, FF_INPUT_BUFFER_PADDING_SIZE);
++bgav_bytebuffer_append(>buf, p, AV_INPUT_BUFFER_PADDING_SIZE);
+ bgav_stream_done_packet_read(s, p);
+ }
+   return 1;
+@@ -334,7 +334,7 @@ static int decode_frame_ffmpeg(bgav_stre
+ {
+ if(!fill_buffer(s))
+   {
+-  if(!(priv->ctx->codec->capabilities & CODEC_CAP_DELAY))
++  if(!(priv->ctx->codec->capabilities & AV_CODEC_CAP_DELAY))
+ return 0;
+   }
+   
+@@ -373,7 +373,7 @@ static int decode_frame_ffmpeg(bgav_stre
+ 
+ /* Only codecs with delay are allowed to eat
+packets without outputting audio */
+-if(!(priv->ctx->codec->capabilities & CODEC_CAP_DELAY))
++if(!(priv->ctx->codec->capabilities & AV_CODEC_CAP_DELAY))
+   return 0;
+ }
+   
+@@ -451,7 +451,7 @@ static int init_ffmpeg_audio(bgav_stream
+   if(s->ext_size)
+ {
+ priv->ext_data = calloc(1, s->ext_size +
+-FF_INPUT_BUFFER_PADDING_SIZE);
++AV_INPUT_BUFFER_PADDING_SIZE);
+ memcpy(priv->ext_data, s->ext_data, s->ext_size);
+ 
+ priv->ctx->extradata = priv->ext_data;
+Index: gmerlin-avdecoder-1.2.0~dfsg/lib/video_ffmpeg.c
+===
+--- gmerlin-avdecoder-1.2.0~dfsg.orig/lib/video_ffmpeg.c
 gmerlin-avdecoder-1.2.0~dfsg/lib/video_ffmpeg.c
+@@ -121,7 +121,7 @@ typedef struct
+ 
+   /* Real video ugliness */
+ 
+-  uint32_t rv_extradata[2+FF_INPUT_BUFFER_PADDING_SIZE/4];
++  uint32_t rv_extradata[2+AV_INPUT_BUFFER_PADDING_SIZE/4];
+ 
+ #if LIBAVCODEC_VERSION_MAJOR < 54
+   AVPaletteControl palette;
+@@ -859,18 +859,18 @@ static int init_ffmpeg(bgav_stream_t * s
+*  For streams, where the packets are not aligned with frames,
+*  we need an AVParser
+*/
+-  priv->ctx->flags &= ~CODEC_FLAG_TRUNCATED;
++  priv->ctx->flags &= ~AV_CODEC_FLAG_TRUNCATED;
+   //  priv->ctx->flags |=  CODEC_FLAG_BITEXACT;
+ 
+   /* Check if there might be B-frames */
+-  if(codec->capabilities & CODEC_CAP_DELAY)
++  if(codec->capabilities & AV_CODEC_CAP_DELAY)
+ priv->flags |= HAS_DELAY;
+   
+   priv->ctx->opaque = s;
+   
+   if(s->ext_data)
+ {
+-priv->extradata = calloc(s->ext_size + FF_INPUT_BUFFER_PADDING_SIZE, 1);
++priv->extradata = calloc(s->ext_size + AV_INPUT_BUFFER_PADDING_SIZE, 1);
+ memcpy(priv->extradata, s->ext_data, s->ext_size);
+ priv->extradata_size = s->ext_size;
+ 
+@@ -1782,7 +1782,7 @@ void bgav_init_video_decoders_ffmpeg(bga
+   

Bug#905292: cysignals-tools: missing Depends: python3-distutils

[Andreas Beckmann]

Package: cysignals-tools
Version: 1.6.7+ds-2
Severity: serious

$ /usr/bin/cysignals-CSI
Traceback (most recent call last):
  File "/usr/bin/cysignals-CSI", line 44, in 
from distutils.spawn import find_executable
ModuleNotFoundError: No module named 'distutils.spawn'


Andreas

Bug#592548: rubber-info gives "IndexError: list index out of range"

[Nicolas Boulenguez]

Package: rubber
Followup-For: Bug #592548
Control: tags -1 + unreproducible

Hello.
Both files compile correctly with rubber/1.4-3.
The bug has probably been fixed since, I suggest to close it.

Bug#905291: anki: missing Depends: python3-distutils

[Andreas Beckmann]

Package: anki
Version: 2.1.0+dfsg~rc2-1
Severity: serious

$ anki
Traceback (most recent call last):
  File "/usr/bin/anki", line 6, in 
import aqt
  File "/usr/share/anki/aqt/__init__.py", line 4, in 
from anki import version as _version
  File "/usr/share/anki/anki/__init__.py", line 14, in 
from anki.storage import Collection
  File "/usr/share/anki/anki/storage.py", line 11, in 
from anki.collection import _Collection
  File "/usr/share/anki/anki/collection.py", line 25, in 
from anki.sound import stripSounds
  File "/usr/share/anki/anki/sound.py", line 87, in 
from anki.mpv import MPV, MPVBase
  File "/usr/share/anki/anki/mpv.py", line 39, in 
from distutils.spawn import find_executable
ModuleNotFoundError: No module named 'distutils.spawn'


Andreas

Bug#905290: verbiste-el: fix emacsen-common-without-dh-elpa

[Tomasz Buchert]

Package: verbiste-el
Severity: normal

Dear Maintainer,
lintian reports emacsen-common-without-dh-elpa on the verbiste-el package.
Please fix it.



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

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

Versions of packages verbiste-el depends on:
ii  emacsen-common  2.0.8
ii  verbiste0.1.45-2

Versions of packages verbiste-el recommends:
ii  emacs24 [emacsen]  24.5+1-11
ii  emacs25 [emacsen]  25.2+1-6+b3

verbiste-el suggests no packages.

Bug#905188: cryptsetup-initramfs: fails to install, remove, distupgrade, and install again

[Guilhem Moulin]

Control: tag   -1 pending
Control: found -1 2:2.0.3-1

On Wed, 01 Aug 2018 at 20:29:50 +0200, Andreas Beckmann wrote:
> On 2018-08-01 19:01, Guilhem Moulin wrote:
>> On Wed, 01 Aug 2018 at 13:20:37 +0200, Andreas Beckmann wrote:
>>> Configuration file '/etc/cryptsetup-initramfs/conf-hook'
>>> ==> Deleted (by you or by a script) since installation.
>>> ==> Package distributor has shipped an updated version.
>>> What would you like to do about it ?  Your options are:
>>> Y or I  : install the package maintainer's version
>>> N or O  : keep your currently-installed version
>>>  D : show the differences between the versions
>>>  Z : start a shell to examine the situation
>>> The default action is to keep your current version.
>>> *** conf-hook (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
>>> cryptsetup-initramfs (--configure):
>>> end of file on stdin at conffile prompt
>>> dpkg: dependency problems prevent configuration of cryptsetup:
>>> cryptsetup depends on cryptsetup-initramfs (>= 2:2.0.3-1); however:
>>> Package cryptsetup-initramfs is not configured yet.
>> 
>> I wonder if it's a false positive?  Following the same upgrade path in a
>
> No, already asking the question about the conffile that was *not*
> modified by the user is a policy violation.

I see, thanks for the pointers.  Fixed at
https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/b7abb5d06e46f3704c4edeb55d033b6283ae8777
 .

(Interesting, I seem to recall we threw piuparts at 2:2.0.3-1, but
possibly didn't test that same upgrade path.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903256: ITA: mktorrent

[Paride Legovini]

Control: owner 903256 !

Peter Pentchev wrote on 02/08/2018:
> On Thu, Aug 02, 2018 at 03:59:17PM +0200, Paride Legovini wrote:
>> On Sun, 22 Jul 2018 Peter Pentchev  wrote:
>>> package wnpp
>>> retitle 903256 ITA: mktorrent -- simple command line utility to create 
>>> BitTorrent metainfo files
>>> owner 903256 !
>>> thanks
>>
>> Hello Peter,
>>
>> Having followed up to #852159, I was in the process of adopting
>> mktorrent. I didn't know there was a RFA an I guess Nico wasn't aware of
>> your ITA. Thing is, I already did some work:
>>
>> https://salsa.debian.org/paride-guest/mktorrent/
>>
>> The packaging follows DEP14 with a "pure git" workflow (git tags are
>> used instead of upstream tarballs).
>>
>> Now, if you already made some packaging work just go on, I'm looking
>> forward to see mktorrent 1.1 uploaded. If you didn't, feel free to take
>> whatever you want from my repository, should you find anything useful.
>> As a third alternative, still in the hypothesis that no work of yours is
>> getting wasted, we could co-maintain the package in salsa.org/debian. I
>> would be glad to. Truly: as you prefer!
> 
> Hi Paride,
> 
> Actually I hadn't got 'round to doing anything about mktorrent yet;
> I did notice that the upstream repository changed and that there was
> a new release, but other things got in the way...
> 
> So it would be completely fine with me to pass ownership of this bug
> and, consequently, maintainership of mktorrent, over to you!
> Feel free to reassign the bug, or, if you prefer it done explicitly,
> I could do that in a follow-up message.

Very well then: no work got wasted. This email with reassign the bug.
I expect to have mktorrent 1.1-1 uploaded in a few days.

Cheers,

Paride