Bug#929825: Version 7 available upstream

[積丹尼 Dan Jacobson]

Package: imagemagick-6.q16
Version: 8:6.9.10.23+dfsg-2.1
Severity: wishlist

https://imagemagick.org/script/download.php has a new version.

Bug#920546: dolfin: flaky autopkgtest as it times out sometimes

[Drew Parsons]

Source: dolfin
Followup-For: Bug #920546

The flaky test has been nasty the last couple of days. Always the C++
MPI demos timing out, each time on a different demo.  The MPI python
demos (usually) run fine.  Presumeably some unresolved race condition.  

2019.1 is now released (currently in experimental), so over time we'll
see if the problem is resolved in the new version or not.

The dolfin tests (even when successful) are shame-listed as "slow
running" by debci, taking about 1:15 hr to complete. The tests are
comprehensive, we could of course run a subset of them if it were
important to run the tests more quickly.  Is there an autopkgtest
option to distingush between "normal" and "slow" tests, so the test
daemon can make its own decision whether to run all of them or not?

I've added C++ unit tests now. They only add a minute or less.  I
don't think the "slow" timing of the tests is related to the C++ MPI
timeouts (the python tests are the slow ones).

So an audit of the tests (when successful):

C++ unit tests (serial):2 sec
C++ demos (serial): 135 sec = 2.3 min
C++ demos (MPI):415 sec = 6.9 min  (flaky timeouts)
python unit tests (serial): 1395 sec = 23.3 min
python unit tests (MPI):622 sec = 10.4 min
python demos (serial):  665 sec = 11 min
python demos (MPI): 634 sec = 10.6 min

total run time = 3868 sec = 65 min = 1 hr 5 min



Audit of flaky timeouts (C++ MPI demos back to March 1 2019):

demo_poisson-disc_mpi
  demo_bcs_mpi
  demo_submesh_mpi
  demo_nonmatching-interpolation_mpi
  demo_auto-adaptive-navier-stokes_mpi
  demo_eigenvalue_mpi
  demo_elasticity_mpi
  demo_elastodynamics_mpi
  demo_singular-poisson_mpi
  demo_sym-dirichlet-bc_mpi
  demo_mixed-poisson_mpi
  demo_spatial-coordinates_mpi
  demo_advection-diffusion_mpi

No obvious pattern.  Not one single repetition in the same demo, each
time the timeout was in a different demo.




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

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

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Tareeq Ali]

Package: light-locker
Version: 1.8.0-3
Followup-For: Bug #870641

Dear Maintainer,

Another user here with the same issue, using Jeremiah Mahler's workaround
fixed the problem for me as well.  I can confirm I see the same thing in the 
xorg logs, which is fbdev is being loaded.  Afer the work around the display
wakes up as normal.

When the screen refused to wake up I could CTRL+ALT+F1 to tty1, and kill
light-locker and then CTRL+ALT+F7 to get back into my xfce session.  

$ lspci -v 
[...]
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated 
Graphics Controller (rev 0b) (prog-if 00 [VGA controller])
Subsystem: Lenovo Haswell-ULT Integrated Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at f000 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at 3000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915
[...]

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

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

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.12-1
ii  libdbus-glib-1-2 0.110-4
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libsystemd0  241-3
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxss1  1:1.2.3-1
ii  lightdm  1.26.0-4

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

Bug#928429: dpkg: trigger cycle postgresql-common -> sgml-base while upgrading from stretch to buster

[Guillem Jover]

Hi!

On Fri, 2019-05-17 at 21:12:28 +0200, Andreas Beckmann wrote:
> On 2019-05-14 02:35, Guillem Jover wrote:
> > setup some chroot somewhere to do that.
> > 
> > I'm attaching the patch. Otherwise already built (and signed) binary
> > packages can be temporarily found at:
> > 
> >   
> 
> It would have been even easier if you had added a Packages file to the
> directory :-) (then I could have used it directly as an argument to the
> --testdebs-repo option)

I'll have that in mind for the next time. :)

> I've ran two piuparts tests upgrading from stretch to sid:
> * with your new packages: success
> * with what's in sid: failure
> 
> So your patch seems to fix this issue.

Perfect thanks.

I have queued most of the changes for the next release, which I'm
planning on cutting tomorrow night, but I've yet to decide on the
s-s-d issue. Sorry for the delays!

Thanks,
Guillem

Bug#926615: [bug #56094] ..2'nd roll over bug: gpsd "clock is 56 years wrong", like "1963-07-18T08:57:40.584Z"

[Arnt Karlsen]

On Thu, 30 May 2019 22:17:51 -0400 (EDT), Eric wrote in message 
<20190530-221751.sv56628.73...@savannah.nongnu.org>:

> Update of bug #56094 (project gpsd):
> 
>  Open/Closed:Open =>
> Closed 
> 
> ___
> 
> Follow-up Comment #4:
> 
> I see that a timebase.h patch for the new era has been applied.


..er, no: On Tue, 9 Apr 2019 09:23:28 +0200, Arnt wrote in message 
<20190409092328.7fbdfb77@sda3>:

> Hi,
> 
> ..I filed https://bugs.devuan.org//cgi/bugreport.cgi?bug=314
> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926615
> (we @ Devuan use Debian's gpsd package as it is) and 
> https://savannah.nongnu.org/bugs/index.php?56094 titled 
> gpsd: ..22'nd roll over bug: gpsd "clock is 56 years wrong", 
> like "1963-07-18T08:57:40.584Z", is my fix suggestion wrong?


..key question: Is my fix suggestion wrong?


...and then I got too damned busy with post-Groklaw supression 
fire litigation to test etc my fix idea.
On Thu, 30 May 2019 22:17:51 -0400 (EDT), Eric wrote in message 
<20190530-221751.sv56628.73...@savannah.nongnu.org>:

> Accordingly I am closing this bug.

..closing https://savannah.nongnu.org/bugs/index.php?56094 
to move this bug to https://gitlab.com/gpsd/gpsd/issues/3 ?

> I have added  Arnt Karlsen
>  and jamesb.f...@gmail.com on the Cc list so they'll
> be notified.

..cc'ed to 3...@bugs.devuan.org and 926...@bugs.debian.org so we 
and they can act on it too.

> If there is still a live issue here, please open it on the new
> tracker at https://gitlab.com/gpsd/gpsd/issues
> 
> ___
> 
> Reply to this item at:
> 
>   
> 
> ___
>   Message sent via Savannah
>   https://savannah.nongnu.org/
> 


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Bug#929816: RFS: simhash/0.0.20161225-1 [ITA] -- generate similarity hashes to find nearly duplicate files

[laokz]

Hello Adam,

Thanks for the quick reply and kind help.

在 2019-05-31五的 20:16 +0200，Adam Borowski写道：
> It's nice to see you taking up this package -- however, this is an upload
> to
> unstable during the freeze.  It's generally a bad idea; it would be better
> to either use experimental or to wait until Buster is released.
> 
Ah yes. I forgot that. Surely I'll keep this bug open and wait Buster
released.

> >  * d/{watch,source/lintian-overrides}: New version adds a watch file. It
> > is not very well but can do work.
> 
> It finds some old version for me:
> 
> uscan info: Newest version of simhash on remote site is 0.0.20110213,
> local version is 0.0.20161225
> uscan info:=> Only older package available from
>   https://github.com/BartMassey/simhash master
> 
Upstream repo has no release nor tags but 2 branches, one is 'master',
another is 'properly-unsigned-incompatible' which is more fresh. In order to
watch them all, I added two lines in watch file:

opts="mode=git, pretty=0.0.%cd" https://github.com/BartMassey/simhash
heads/properly-unsigned-incompatible
opts="mode=git, pretty=0.0.%cd" https://github.com/BartMassey/simhash
heads/master

>From uscan manpage and IRC help, it seems that above method not well
supported. By testing though, that could be useful: when 'properly-unsigned-
incompatible' update it gives me a new right tarball, when 'master' update
it can tell me there is an update. But uscan output looks a bit confused. I
prefer this than just watch a specific branch. (I don't know if this is
useful to CI/QA robot)

Best regards,
laokz

Bug#929588: usat: source tarballs are missing the source of the configure script

[Carsten Schoenert]

Hi,

please use 'Reply All' next time so your answer will also get into the
bug tracking system. Thanks!

Am 31.05.19 um 17:50 schrieb badd...@gmail.com:
> Ah I see.
> 
> Well, I am about to put out a new release with a lot of updates. In
> fact, the current release has some debian issues that I am working
> on. I will ensure that it is fixed in that release.

Thanks!
Once it's released the package maintainers can keep it up then.

> If I have some time, I will go back to the current release and add
> the configure.in. I am not sure where it got lost to...
I guess it's mostly about hand crafted (Make)files, otherwise at least
one part -f the -local targets should get a bit of a reworking.

Please do a reply again about some ready to use updates to this email so
the information about a new or updated archive will be announced into
the Debian issue tracker.

-- 
Regards
Carsten Schoenert

Bug#929740: RFS: elpy/1.28.0-2

[Nicholas D Steeves]

On Thu, May 30, 2019 at 04:54:28AM +0100, Chris Lamb wrote:
> 
> Nicholas D Steeves wrote:
> 
> > Alternatively, one can download the package with dget using this command:
> > 
> > dget -x 
> > https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.28.0-2.dsc
> 
> Uploaded; thanks. :)
> 

Thank you Chris :-)


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#928913: unblock: elpy/1.28.0-2

[Nicholas D Steeves]

Control: tag -1 -moreinfo

On Mon, May 27, 2019 at 09:33:05PM +0200, Paul Gevers wrote:
> Control: tags -1 confirmed moreinfo
> 
> On Sun, 12 May 2019 19:33:57 -0400 Nicholas D Steeves
>  wrote:
> > Please unblock package elpy
> > 
> > I'm filing this unblock request before uploading to unstable.
> 
> Please go ahead and remove the moreinfo tag when there is something to
> unblock.

Done!  Updated debdiff is attached.

Thank you,
Nicholas
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/concepts.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/editing.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/extending.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/ide.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/index.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/introduction.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_sources/quickstart.rst.txt
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/ajax-loader.gif
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/basic.css
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/classic.css
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/comment-bright.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/comment-close.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/comment.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/default.css
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/documentation_options.js
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/down-pressed.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/down.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/file.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/language_data.js
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/minus.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/plus.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/pygments.css
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/up-pressed.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/_static/up.png
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/concepts.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/editing.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/extending.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/genindex.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/ide.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/index.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/introduction.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/objects.inv
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/quickstart.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/search.html
-rw-r--r--  root/root   /usr/share/doc/elpa-elpy/html/searchindex.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/doctools.js -> ../../../../javascript/sphinxdoc/1.0/doctools.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/jquery.js -> ../../../../javascript/sphinxdoc/1.0/jquery.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/searchtools.js -> ../../../../javascript/sphinxdoc/1.0/searchtools.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/sidebar.js -> ../../../../javascript/sphinxdoc/1.0/sidebar.js
lrwxrwxrwx  root/root   /usr/share/doc/elpa-elpy/html/_static/underscore.js -> ../../../../javascript/sphinxdoc/1.0/underscore.js

Control files: lines which differ (wdiff format)

Installed-Size: [-567-] {+817+}
Recommends: emacs (>= 46.0), [-python3-jedi-] {+python3-jedi, libjs-sphinxdoc+}
Version: [-1.28.0-1-] {+1.28.0-2+}
diff -Nru elpy-1.28.0/debian/changelog elpy-1.28.0/debian/changelog
--- elpy-1.28.0/debian/changelog	2019-01-05 17:13:12.0 -0500
+++ elpy-1.28.0/debian/changelog	2019-05-29 18:05:30.0 -0400
@@ -1,3 +1,25 @@
+elpy (1.28.0-2) unstable; urgency=medium
+
+  * debian/rules: Disable DH_VERBOSE.
+  * Use sphinx to generate documentation in html format, and use
+debian/docs to install it.
+(Closes: #928633)
+  * Add libjs-sphinxdoc to Recommends.  This package's html doc search page
+fails gracefully with "Please activate JavaScript to enable the search
+functionality" if a user chooses not to install libjs-sphinxdoc.
+  * debian/README.Debian: Make explicit how Debian's Elpy package does
+not ship with support for Python 2. (Closes: #927084)
+  * debian/control: Clarify comment explaining why the Python 2 package
+python-autopep8 is a build dependency.
+  

Bug#929824: linux-image-4.19.0-5-amd64: Backport VMCI PPN64 patch

[Adit Ranadive]

Package: src:linux
Version: 4.19.37-3
Severity: wishlist

Dear Maintainer,

Can this kernel patch [1] for VMCI be backported to Debian 10?
Here is the commit log:

commit f2db7361cb19bf3a6f7fd367f21d8eb325397946
Author: Vishnu DASA 
Commit: Greg Kroah-Hartman 

VMCI: Support upto 64-bit PPNs

Add support in the VMCI driver to handle upto 64-bit PPNs when the VMCI
device exposes the capability for 64-bit PPNs.

Thanks,
Adit

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f2db7361cb19bf3a6f7fd367f21d8eb325397946

-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=9b0eb070-17d5-4e5d-98ef-fe640c663c5f ro quiet

** Not tainted

** Kernel log:
[1.862333] sd 0:0:0:0: [sda] Mode Sense: 61 00 00 00
[1.862454] sd 0:0:0:0: [sda] Cache data unavailable
[1.862455] sd 0:0:0:0: [sda] Assuming drive cache: write through
[1.865538]  sda: sda1 sda2 < sda5 >
[1.866314] sd 0:0:0:0: [sda] Attached SCSI disk
[1.896204] sr 3:0:0:0: [sr0] scsi3-mmc drive: 1x/1x writer dvd-ram cd/rw 
xa/form2 cdda tray
[1.896206] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.896616] sr 3:0:0:0: Attached scsi CD-ROM sr0
[2.016689] usb 2-1: New USB device found, idVendor=0e0f, idProduct=0003, 
bcdDevice= 1.03
[2.016691] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[2.016692] usb 2-1: Product: VMware Virtual USB Mouse
[2.016693] usb 2-1: Manufacturer: VMware
[2.038438] hidraw: raw HID events driver (C) Jiri Kosina
[2.046691] usbcore: registered new interface driver usbhid
[2.046692] usbhid: USB HID core driver
[2.048214] input: VMware VMware Virtual USB Mouse as 
/devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-1:1.0/0003:0E0F:0003.0001/input/input5
[2.048360] hid-generic 0003:0E0F:0003.0001: input,hidraw0: USB HID v1.10 
Mouse [VMware VMware Virtual USB Mouse] on usb-:02:00.0-1/input0
[2.099584] tsc: Refined TSC clocksource calibration: 2194.839 MHz
[2.099627] clocksource: tsc: mask: 0x max_cycles: 
0x1fa32779500, max_idle_ns: 440795235982 ns
[2.099680] clocksource: Switched to clocksource tsc
[2.163481] usb 2-2: new full-speed USB device number 3 using uhci_hcd
[2.281146] PM: Image not found (code -22)
[2.346450] usb 2-2: New USB device found, idVendor=0e0f, idProduct=0002, 
bcdDevice= 1.00
[2.346451] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[2.346452] usb 2-2: Product: VMware Virtual USB Hub
[2.363522] hub 2-2:1.0: USB hub found
[2.370440] hub 2-2:1.0: 7 ports detected
[2.478608] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[4.384855] systemd[1]: Inserted module 'autofs4'
[4.580579] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[4.580608] systemd[1]: Detected virtualization vmware.
[4.580612] systemd[1]: Detected architecture x86-64.
[4.592363] systemd[1]: Set hostname to .
[5.360189] systemd[1]: Listening on initctl Compatibility Named Pipe.
[5.360323] systemd[1]: Listening on Journal Audit Socket.
[5.365038] systemd[1]: Created slice User and Session Slice.
[5.365261] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[5.365536] systemd[1]: Created slice system-getty.slice.
[5.365607] systemd[1]: Listening on fsck to fsckd communication Socket.
[5.550458] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[5.714465] systemd-journald[397]: Received request to flush runtime journal 
from PID 1
[6.430087] audit: type=1400 audit(1559010294.601:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=433 comm="apparmor_parser"
[6.437211] audit: type=1400 audit(1559010294.609:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=436 
comm="apparmor_parser"
[6.437525] audit: type=1400 audit(1559010294.609:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=436 comm="apparmor_parser"
[6.46] audit: type=1400 audit(1559010294.633:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=463 comm="apparmor_parser"
[6.490391] audit: type=1400 audit(1559010294.661:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=464 comm="apparmor_parser"
[6.521883] ACPI: AC Adapter [ACAD] (on-line)
[6.699438] audit: type=1400 audit(1559010294.869:7): apparmor="STATUS" 

Bug#850644: #850644: RFP: Guix in Debian

[Ludovic Courtès]

Hello!

Vagrant Cascadian  skribis:

>> After all that, I did get to the point where I could at least try to
>> compile guix:
>>
>>   https://salsa.debian.org/vagrant/guix
>
> With local builds of the above packages, I've got a working guix
> package!

Woohoo, awesome!

> It still needs a way to get the bootstrap binaries (bash, mkdir, tar and
> xz) from Guix; right now they're binaries shipped in the source!
> Ludovic Courtès worked on a patch that would in theory download those at
> run-time, but that is not yet working...

Yes, I figured this couldn’t be done on ‘master’ without entailing a
full rebuild, but I’ll see what can be done in ‘core-updates’.  To be
continued…

Congrats on all the Guile packaging work, that’s quite an achievement!

Ludo’.

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

On Fri, May 31, 2019 at 5:03 PM Chris Wilson  wrote:

> Hi Reinhard,
>
> Presumably the many other affected packages have had similar difficulty in
> developing a comprehensive solution? I also wasn't aware of a time
> constraint. Not that it would have helped me much, as I was moving house,
> but it would have been good to know that there was a risk of not making
> Debian 10.
>

I'm sorry, I should have communicated that point earlier. I've been bitten
by this with other packages as well.
The release schedule is documented here:
https://wiki.debian.org/DebianBuster
The most recent update from the release team is
https://lists.debian.org/debian-devel-announce/2019/04/msg3.html - and
newer updates will be linked from https://release.debian.org/.

In short: The team is minimizing changes as much as possible, and getting
updates in becomes more and more a similar big deal as updating something
in stable.

I could create a special branch with a cut-down version of the solution,
> e.g. forcing the SecurityLevel to -1 (compatibility and warn) for the time
> being, in order to get the fix out in time for Debian 10, and then put the
> full version into backports?
>

That would be amazing, if the patch is easy to review, I'd be happy to
upload it as a distro patch based on the current package and try to get
this approved by the release team. It might even be accepted as a stable
update, depending on how invasive it is.


Thanks,
-rt

Bug#929804: gnome-maps: crash when exporting map as the image

[Bernhard Übelacker]

Hello Saša Janiška,
thanks for your fast response.

Maybe you could also install following debug symbol packages:

libpixman-1-0-dbgsym libcairo2-dbgsym libchamplain-0.12-0-dbgsym 
libffi6-dbg libgjs0g-dbgsym libglib2.0-0-dbgsym libgtk-3-0-dbgsym gjs-dbgsym
(and if size does not matter: libmozjs-60-0-dbgsym)

And send another output of journalctl, that way the function
names for each frame will be visible.

These debug symbol packages are in a separate repository,
details described here: 
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Did you receive this crash always calculating the same route?
Does it also crash if you calculate a route between some
other random locations?

Kind regards,
Bernhard

Bug#929823: xfce4: Keyboard Loses Focus When Screensaver Ends

[Michael Cordingley]

Package: xfce4
Version: 4.12.5
Severity: normal

Dear Maintainer,

When coming out of the screensaver or out of the screen having locked, whatever 
the currently active window is does not receive keyboard input. I have to make 
the window lose focus and then given it back for keyboard input to work again.

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

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

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-4
ii  libxfce4ui-utils 4.12.1-3
ii  thunar   1.8.4-1
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.2-1
ii  xfce4-pulseaudio-plugin  0.4.1-1
ii  xfce4-session4.12.1-6
ii  xfce4-settings   4.12.4-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.4-2
ii  xfwm44.12.5-1

Versions of packages xfce4 recommends:
ii  desktop-base  10.0.2
ii  tango-icon-theme  0.8.90-7
ii  thunar-volman 0.9.1-1
ii  xfce4-notifyd 0.4.3-1
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
pn  xfce4-goodies
ii  xfce4-power-manager  1.6.1-1

-- no debconf information

Bug#929822: xserver-xorg-video-amdgpu: display stops updating after VT switch

[Ross Vandegrift]

Package: xserver-xorg-video-amdgpu
Version: 19.0.1-1
Severity: normal

After starting Xorg with the AMDGPU driver, I switch to a different VT.
When I switch back to X, the display has frozen.  Only the mouse cursor
moves.  To reproduce:

1) From a linux console with no display manager or X session running:
$ startx /usr/bin/xterm
2) Switch to a different VT and back.
3) Nothing appears in the xterm when typing.
4) Switch to a different VT and back, the old typing appears.

The screen isn't updating correctly but the client & server are
functioning.  I can run commands in the terminal, but can't see any
output without a VT switch.  Exiting the xterm immediately ends the X
session cleanly.

The same issue is triggered by a suspend/resume cycle, as a well as
loggin into an X session with gdm.  In both cases, I suspect VT change
is the underlying trigger.

Ross

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] [1002:98e4] (rev eb)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 343 May 30 19:48 libinput.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

Xorg X server log files on system:
--
-rw-r--r-- 1 ross ross 46097 May 31 13:18 
/home/ross/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 ross ross 35981 May 31 14:03 
/home/ross/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/ross/.local/share/xorg/Xorg.0.log):
-
[  1483.270] 
X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
[  1483.274] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[  1483.276] Current Operating System: Linux momomoto 4.19.0-5-amd64 #1 SMP 
Debian 4.19.37-3 (2019-05-15) x86_64
[  1483.276] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=/dev/mapper/momomoto--vg-root ro quiet splash
[  1483.279] Build Date: 25 October 2018  06:15:23PM
[  1483.280] xorg-server 2:1.20.3-1 (https://www.debian.org/support) 
[  1483.281] Current version of pixman: 0.36.0
[  1483.284]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1483.284] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1483.290] (==) Log file: "/home/ross/.local/share/xorg/Xorg.0.log", Time: 
Fri May 31 14:02:35 2019
[  1483.292] (==) Using config directory: "/etc/X11/xorg.conf.d"
[  1483.293] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1483.293] (==) No Layout section.  Using the first Screen section.
[  1483.293] (==) No screen section available. Using defaults.
[  1483.293] (**) |-->Screen "Default Screen Section" (0)
[  1483.293] (**) |   |-->Monitor ""
[  1483.294] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1483.294] (==) Automatically adding devices
[  1483.294] (==) Automatically enabling devices
[  1483.294] (==) Automatically adding GPU devices
[  1483.294] (==) Max clients allowed: 256, resource mask: 0x1f
[  1483.294] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  1483.294]Entry deleted from font path.
[  1483.294] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  1483.294] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1483.294] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  1483.294] (II) Loader magic: 0x5590f93c8e20
[  1483.294] (II) Module ABI versions:
[  1483.294]X.Org ANSI C Emulation: 0.4
[  1483.294]X.Org Video Driver: 24.0
[  1483.294]X.Org XInput driver : 24.1
[  1483.294]X.Org Server Extension : 10.0
[  1483.295] (++) using VT number 2

[  1483.298] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_35
[  1483.299] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1483.300] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0
[  1483.305] (--) PCI:*(0@0:1:0) 1002:98e4:1028:087e rev 235, Mem @ 

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Chris Wilson]

Hi Reinhard,

Presumably the many other affected packages have had similar difficulty in
developing a comprehensive solution? I also wasn't aware of a time
constraint. Not that it would have helped me much, as I was moving house,
but it would have been good to know that there was a risk of not making
Debian 10.

I could create a special branch with a cut-down version of the solution,
e.g. forcing the SecurityLevel to -1 (compatibility and warn) for the time
being, in order to get the fix out in time for Debian 10, and then put the
full version into backports?

Thanks, Chris.

On Fri, 31 May 2019 at 12:16, Reinhard Tartler  wrote:

> Hi Chris,
>
> On Sun, May 19, 2019 at 12:21 PM Chris Wilson 
> wrote:
>
>> Hi Reinhard and all,
>>
>> Good news, I have just finished fixing this problem, and merged it into
>> master with https://github.com/boxbackup/boxbackup/pull/36. Please could
>> you cut a new Debian package release and see if the tests pass for you? Or
>> if not, point me to the failure logs?
>>
>> If anyone wants to know more, the issue is quite complex, and there are
>> no easy answers, which is why it took so long to fix. I've done my best to
>> describe it at
>> https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates. Please
>> feel free to correct any mistakes that I've made.
>>
>
> Thanks a lot for your assistance!
>
> I've now (finally) uploaded the package to debian/experimental, the build
> logs will be available at
> https://buildd.debian.org/status/package.php?p=boxbackup=experimental
>  soon.
>
> Unfortunately, the changes are quite invasive and do not qualify for
> inclusion into "Debian testing" this late in the Debian release cycle (cf.
> https://salsa.debian.org/debian/boxbackup/commit/6017757bc079f4446aa77bc5c0855c52741280f4?w=1
> - all of which would need to be reviewed and approved by the Release Team).
> That's very unfortunate, because it very likely means that boxbackup will
> not be part of Debian 10 (buster).
>
> I am also sympathetic -- the nature of the issue seems to require such
> invasive changes and coming up with a simple, focused and reviewable fix is
> super hard.
>
> The best that we can do at this point is to get it included into
> "buster-backports" as soon as that suite opens, probably shortly after
> buster is released, which should be within (hopefully) a small number of
> weeks.
>
>
> Best,
> -rt
>
> --
> regards,
> Reinhard
>

Bug#929738: [Debian GNUstep maintainers] Bug#929738: gnumail.app: gnumail freezes when i click 'info > preferences'

[Svetlana Tkachenko]

GNUMail starts with

2019-06-01 06:59:33.831 GNUMail[21423:21423] styleoffsets ... guessing offsets
2019-06-01 06:59:33.834 GNUMail[21423:21423] styleoffsets ... guessing offsets
2019-06-01 06:59:34.014 GNUMail[21423:21423] Bad application class '(null)' 
specified
2019-06-01 06:59:34.531 GNUMail[21423:21423] Problem posting notification: 
 NAME:NSInvalidArgumentException REASON:[NSURL 
initFileURLWithPath:] nil string parameter INFO:(null)

But after this, when I click preferences, there is no additional console output.

Bug#907240: Status of this ITP?

[Jakob Haufe]

Hi Ruben,

some time ago, you expressed interest to package nextpnr for Debian.
Have you found time to work on this yet? Do you need help and/or
testers?

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpsxsrevsZmU.pgp
Description: OpenPGP digital signature

Bug#929738: [Debian GNUstep maintainers] Bug#929738: gnumail.app: gnumail freezes when i click 'info > preferences'

[Ivan Vučica]

I suspect there might be some relevant console output. Do you see any
output after clicking Preferences if you start gnumail through the terminal?

Bug#929172: Same issue as already reported, and partially fixed

[Diederik de Haas]

On vrijdag 31 mei 2019 21:52:38 CEST Paul Gevers wrote:
> On 31-05-2019 21:16, Diederik de Haas wrote:
> > Control: severity -1 serious
> 
> Please don't use this if you CC multiple bugs that aren't all of the
> same severity.

Sorry about that, didn't realize that it would affect CC-ed bugs too. Later on 
I send another mail to revert the inadvertent changes.

> > The fix has actually been made. But the problem is that it needs an
> > unblock ack from the d-i team (https://bugs.debian.org/928908), but after
> > 2 weeks there is still no reply.
> 
> Please have patience. D-I is busy.

Ok. I already felt that I was being annoying. I guess I got too frustrated not 
seeing any response for > 2 weeks and not knowing why.

> > When that is done, (afaik) a rebuild of the package to pick up the change
> > in libdebian-installer is needed (at least for cdebootstrap-static? which
> > I'm using).
> 
> Please file a binNMU bug already than (I didn't check if that is the
> correct course of action, but better discuss that there).

I had never done that before, but I tried here: #929820


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

Bug#929821: libgd2: CVE-2019-11038: Uninitialized read in gdImageCreateFromXbm

[Salvatore Bonaccorso]

Source: libgd2
Version: 2.2.5-5.1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libgd/libgd/issues/501
Control: found -1 2.2.4-2+deb9u4
Control: found -1 2.2.4-1

Hi,

The following vulnerability was published for libgd2.

CVE-2019-11038[0]:
Uninitialized read in gdImageCreateFromXbm

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11038
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11038
[1] https://github.com/libgd/libgd/issues/501
[2] https://bugs.php.net/bug.php?id=77973

Regards,
Salvatore

Bug#929820: nmu: cdebootstrap_0.7.7+b11

[Diederik de Haas]

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

nmu cdebootstrap_0.7.7+b11 . ANY . buster . -m "Rebuild for change in 
libdebian-installer (v0.119)"

I don't know if this is the correct way, but cdebootstrap-static needs a
rebuild to pick up the change in libdebian-installer (version 0.119,
fixing #55) and this is my attempt to request it.

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

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

Bug#929819: [firefox] package v67

[jnqnfe]

Package: firefox
Version: 66.0.5-1
Severity: critical

Firefox v67 was released 10 days ago and includes critical security
fixes (as I'm sure I don't need to point out, they always do). Please
update the package on the unstable channel.

I am aware that we are currently in a freeze period for the next stable
release, but many Debian users, like myself and my family, actually run
'unstable/'Sid', and the long delays in getting critical security fixes
like this onto the unstable channel impacts our security.

I understand that perhaps using unstable may not be officially
considered a correct use of Debian, but with the exception of server
use, people don't want to wait 2 years for new major versions of
significant userland packages. I have been using this channel for some
years now and rarely experience noticeable bugs introduced on it. The
only real problem stems from freezes that delay security updates.

Regards, :)

Bug#929818: sddm crashes after VT switch (but switching works fine without sddm)

[J. Pfennig]

Package: sddm
Version: 0.18.0-1
Severity: important

Concurrent X-Sessions can be started on other VTs (without sddm, just
xinit) and you can switch between these without any problem.

When switching back to the sddm VT (number 7) sddm crashes and so the
session is lost.

This behaviour is 100% reproducible on various notbooks.

(1) pam modification: the pam groups module now works fine with
sddm (pam was fixed since stretch, sddm was not usable with
stretch anyhow).

(2) here the trivial xinitrc used with startx to do testing:

#!/bin/sh
. /etc/X11/Xsession
if [ -x /usr/bin/startkde ] ; then
startkde
elif [ -x /usr/bin/twm ] ; then
twm &
xclock -g 130x130+900+10 &
xterm -g 120x35+10+10 -sb
fi

(3) Kernal taint: is virtual box, but the mentioned tests were
run on a real machine.

---

Thanks for your attention and your Debian engagement
Jürgen

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

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

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.71
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libpam0g1.3.1-5
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5dbus5 5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5network5  5.11.3+dfsg1-1
ii  libqt5qml5  5.11.3-4
ii  libqt5quick55.11.3-4
ii  libstdc++6  8.3.0-6
ii  libsystemd0 241-3
ii  libxcb-xkb1 1.13.1-2
ii  libxcb1 1.13.1-2
ii  qml-module-qtquick2 5.11.3-4
ii  x11-common  1:7.7+19
ii  xnest [xserver] 2:1.20.3-1
ii  xserver-xorg [xserver]  1:7.7+19

Versions of packages sddm recommends:
ii  haveged1.9.1-7
ii  libpam-systemd 241-3
ii  sddm-theme-breeze [sddm-theme] 4:5.14.5.1-1
ii  sddm-theme-debian-breeze [sddm-theme]  4:5.14.5.1-1
ii  sddm-theme-debian-elarun [sddm-theme]  0.18.0-1
ii  sddm-theme-debian-maui [sddm-theme]0.18.0-1

Versions of packages sddm suggests:
pn  libpam-kwallet5   
pn  qtvirtualkeyboard-plugin  

-- Configuration Files:
/etc/pam.d/sddm changed:
authrequisite   pam_nologin.so
authrequiredpam_succeed_if.so user != root quiet_success
@include common-auth
auth   optional   pam_group.so
-auth   optionalpam_gnome_keyring.so
-auth   optionalpam_kwallet5.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so close
session optionalpam_keyinit.so force revoke
session requiredpam_limits.so
session requiredpam_loginuid.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so open
-session optional   pam_gnome_keyring.so auto_start
-session optional   pam_kwallet5.so auto_start
@include common-password
session requiredpam_env.so
session requiredpam_env.so envfile=/etc/default/locale user_readenv=1


-- no debconf information

Bug#928421: php7.3: CVE-2019-11036

[Salvatore Bonaccorso]

Source: php7.3
Source-Version: 7.3.6-1

On Sat, May 04, 2019 at 10:46:24AM +0200, Salvatore Bonaccorso wrote:
> Source: php7.3
> Version: 7.3.4-2
> Severity: important
> Tags: security upstream
> Forwarded: https://bugs.php.net/bug.php?id=77950
> 
> Hi,
> 
> The following vulnerability was published for php7.3.
> 
> CVE-2019-11036[0]:
> | When processing certain files, PHP EXIF extension in versions 7.1.x
> | below 7.1.29, 7.2.x below 7.2.18 and 7.3.x below 7.3.5 can be caused
> | to read past allocated buffer in exif_process_IFD_TAG function. This
> | may lead to information disclosure or crash.

This issue was fixed upstream in 7.3.5 and thus included in the
7.3.6-1 upload to unstable, but it was not closed with the upload.

Regards,
Salvatore

Bug#928634: nvidia-legacy-390xx-kernel-source: Fails to build with kernel 5.1

[Harald Dunkel]

I tried it (using sid and upstream's kernel 5.1.6): Builds fine,
X appears to work.


Regards
Harri

Bug#929804: gnome-maps: crash when exporting map as the image

[Saša Janiška]

Bernhard Übelacker  writes:

> Your desktop is running a xorg or wayland session?

xorg

> Was this just crashing once or can you reproduce it again?

Reproducable.

> Maybe you could install a package systemd-coredump,
> then the last entries returned by 'journalctl --no-pager'
> should contain a "Stack trace" that could lead to the
> location causing the crash.

Here it is:

svi 31 21:46:43 atmarama org.gnome.Maps[12055]: Some code called 
array.toString() on a Uint8Array instance. Previously this would have 
interpreted the bytes of the array as a string, but that is nonstandard. In the 
future this will return the bytes as comma-separated digits. For the time 
being, the old behavior has been preserved, but please fix your code anyway to 
explicitly call ByteArray.toString(array).
(Note that array.toString() may 
have been called implicitly.)
0 load() 
["resource:///org/gnome/Maps/js/placeStore.js":168]
1 _initPlaceStore() 
["resource:///org/gnome/Maps/js/application.js":186]
2 vfunc_startup() 
["resource:///org/gnome/Maps/js/application.js":233]
3 main() 
["resource:///org/gnome/Maps/js/main.js":57]
4 run() 
["resource:///org/gnome/gjs/modules/package.js":225]
5 start() 
["resource:///org/gnome/gjs/modules/package.js":209]
6  
["/usr/share/gnome-maps/org.gnome.Maps":2]
svi 31 21:46:51 atmarama dbus-daemon[671]: [system] Activating via systemd: 
service name='org.freedesktop.hostname1' 
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.983' (uid=1000 
pid=12055 comm="/usr/bin/gjs /usr/share/gnome-maps/org.gnome.Maps ")
svi 31 21:46:51 atmarama systemd[1]: Starting Hostname Service...
svi 31 21:46:52 atmarama dbus-daemon[671]: [system] Successfully activated 
service 'org.freedesktop.hostname1'
svi 31 21:46:52 atmarama systemd[1]: Started Hostname Service.
svi 31 21:47:18 atmarama kernel: org.gnome.Maps[12055]: segfault at 
7fb251353000 ip 7fb30a039c04 sp 7ffeaf6565a8 error 4 in 
libpixman-1.so.0.36.0[7fb309fd2000+83000]
svi 31 21:47:18 atmarama kernel: Code: c4 66 0f dd cc 66 44 0f e4 c3 66 0f e4 
cb 66 45 0f dc c1 66 0f dc c1 66 44 0f 67 c0 44 0f 29 04 02 48 83 c0 10 49 39 
c4 74 44  0f 6f 04 01 66 0f 6f c8 66 0f 74 ca 66 0f d7 f1 81 fe ff ff 00
svi 31 21:47:18 atmarama systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
svi 31 21:47:18 atmarama systemd[1]: Started Process Core Dump (PID 12162/UID 
0).
svi 31 21:47:20 atmarama systemd-coredump[12163]: Process 12055 
(org.gnome.Maps) of user 1000 dumped core.
  
  Stack trace of thread 12055:
  #0  0x7fb30a039c04 n/a 
(libpixman-1.so.0)
  #1  0x7fb309fd38a1 
pixman_image_composite32 (libpixman-1.so.0)
  #2  0x7fb30d0f9691 n/a 
(libcairo.so.2)
  #3  0x7fb30d131f3d n/a 
(libcairo.so.2)
  #4  0x7fb30d13267e n/a 
(libcairo.so.2)
  #5  0x7fb30d1326fc n/a 
(libcairo.so.2)
  #6  0x7fb30d0ed921 n/a 
(libcairo.so.2)
  #7  0x7fb30d13e278 n/a 
(libcairo.so.2)
  #8  0x7fb30d0f56d6 n/a 
(libcairo.so.2)
  #9  0x7fb30d0f04f9 n/a 
(libcairo.so.2)
  #10 0x7fb30d14b085 
cairo_paint_with_alpha (libcairo.so.2)
  #11 0x7fb301187b17 n/a 
(libchamplain-0.12.so.0)
  #12 0x7fb30118af69 
champlain_view_to_surface (libchamplain-0.12.so.0)
  #13 0x7fb30e6e58ee 
ffi_call_unix64 (libffi.so.6)
  #14 0x7fb30e6e52bf 
ffi_call (libffi.so.6)
  #15 0x7fb30ef5b819 n/a 
(libgjs.so.0)
  #16 0x7fb30ef5cf96 n/a 
(libgjs.so.0)
  #17 0x7fb30d33b474 n/a 
(libmozjs-60.so.0)
  #18 0x7fb30d32e6e1 n/a 
(libmozjs-60.so.0)
  #19 0x7fb30d33acf6 n/a 
(libmozjs-60.so.0)
  

Bug#554444: Same issue as already reported, and partially fixed

[Paul Gevers]

severity 55 grave
merge 929172 904699
thanks

Hi Diederik,

On 31-05-2019 21:16, Diederik de Haas wrote:
> Control: severity -1 serious

Please don't use this if you CC multiple bugs that aren't all of the
same severity.

> The fix has actually been made. But the problem is that it needs an unblock 
> ack 
> from the d-i team (https://bugs.debian.org/928908), but after 2 weeks there 
> is 
> still no reply.

Please have patience. D-I is busy.

> When that is done, (afaik) a rebuild of the package to pick up the change in 
> libdebian-installer is needed (at least for cdebootstrap-static? which I'm 
> using).

Please file a binNMU bug already than (I didn't check if that is the
correct course of action, but better discuss that there).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929817: RFP: node-evacuated-aok -- Extensible JavaScript test suite

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-evacuated-aok
  Version : 1.9.0
  Upstream Author : Ryan Van Etten
* URL : 
http://n6ikmdnlc2lvfeycj4e3tk2wpmpth6ta5mpfemvlfiiowty2dxlbfkqd.onion/
* License : MIT
  Programming Lang: javascript
  Description : Extensible JavaScript test suite

aok includes, among other things, a simple grunt task for running tests via 
grunt.
aok uses the Console API if available ( 
https://developers.google.com/web/tools/chrome-devtools/console/api )

aok is a prerequisite of node-ecstatic ( #910614 ).

Bug#929764: usbmuxd segfaults on startup

[James Henried]

Bernhard Übelacker  wrote:

> I guess this issue could be related to following shared library.

> > 0x77b6a0e0 0x77b7af47 Yes (*) 
> > /usr/local/lib/libimobiledevice.so.6

> It looks like this file is a manual installed version,
> while the debian version of that library should be loaded
> from here: /usr/lib/x86_64-linux-gnu/libimobiledevice.so.6

> Can you check if you really need that local file?
> And if it is renamed, does the problems disappear?

Bernhard, that's it!

I checked:

# dpkg -S /usr/local/lib/libimobiledevice.so.6
libimobiledevice: /usr/local/lib/libimobiledevice.so.6
# dpkg -S /usr/lib/x86_64-linux-gnu/libimobiledevice.so.6
libimobiledevice6:amd64: /usr/lib/x86_64-linux-gnu/libimobiledevice.so.6
#

But I noticed the libimobiledevice package isn't in sid anymore. I
wonder if it's been deprecated. I removed it, and now only have
libimobiledevice6 installed.

And now:


# usbmuxd 
#

No segfault!


As a user:

$ ifuse /media/iphone/
$ ls /media/iphone/
BooksDCIM   iTunes_Control  PhotoStreamsData  Radio
CloudAssets  Downloads  PhotoData   Purchases Recordings
$ ideviceinfo 
ActivationState: Activated
ActivationStateAcknowledged: true
BasebandActivationTicketVersion: V2
[... etc ...]
$ fusermount -u /media/iphone/
$

It turns out this old libimobiledevice package was interfering.

Thank you, Bernhard and Yves-Alexis for your help!

I'm so glad to be able to mount this phone and get the photos off
after so many months...

Please close this bug as fixed.

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Romain Perier]

On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote:
> On 3/26/19 9:03 PM, Romain Perier wrote:
> > On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote:
> >> On 3/18/19 7:46 PM, Romain Perier wrote:
> >>> On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:
>  On 3/18/19 12:20 PM, Romain Perier wrote:
> > Hello,
> >
> > On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
> >> Source: linux
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
> >> (testing).
> >>    After the upgrade, the touchpad and the trackpoint was not usable
> >> anymore.
> >>
> >>
> >>    This already has some bug report here,
> >>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> >>
> >>    As a workaround, one can run the command,
> >>    sudo sh -c 'echo -n "elantech">
> >> /sys/bus/serio/devices/serio1/protocol'
> >>    in order to use the touchpad. However, on a GUI Interface and 
> >> without
> >>    an external mouse, it's impossible to apply this workaround
> >>   (switching to the terminal -F1, login, and run the command
> >> above might work)
> >>
> >>    I expect to be able to use the touchpad just out of the box, not 
> >> needing
> >>    to run the above workaround
> >>
> > Could you :
> >
> > - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and 
> > confirm or
> >   not is the problem still exists ?
>  Dear Romain
> 
> 
>  I upgraded the kernel and rebooted:
> 
>  schloegl@debian10:~$ uname -a
>  Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
>  x86_64 GNU/Linux
> 
> 
>  With this kernel the trackpoint is working, the trackpad is still not
>  usable.
> 
>  (This improves the situation because now at least one pointer device is
>  available).
> 
> 
> >>> Good, we did some progress :)
> >>>
> > - According to the bug on launchpad and to the fix pushed upstream, the
> >   fix seems to be an hardware quirks, could you give me the output of 
> > the
> >   following command :
> >   $ /sys/bus/serio/devices/serio1/firmware_id
>  root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
>  PNP: LEN2036 PNP0f13
> 
> >>> Could you test the patch attached to this reply ?
> >>> (if you don't know how to do this, I can provide support)
> >>>
> >>> Regards,
> >>> Romain
> >>
> >>
> >> I tried to followed these instructions:
> >>
> >> https://kernel-team.pages.debian.net/kernel-handbook/ch-comm
> >>
> >> 4.5. Building a custom kernel from Debian kernel source
> >>
> >> Specifically using the patched the sources,
> >>
> >> *scripts/config --disable MODULE_SIG*
> >> **scripts/config --disable DEBUG_INFO**
> >> ||*|make clean|* ||*|make deb-pkg
> >>
> >> |*
> >>
> >> and ended up with a kernel that does not boot (missing HD audio firmware),
> >>
> >>
> >> Which procedure do you recommend to build and install a modified kernel ?
> >>
> >>
> > Hi,
> >
> > Section 4.2 from
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
> > , until test-patches should work. For the test-patches script, use the 
> > flavour and a
> > featureset as argument, when you invoke it, like this :
> >
> > # debian/bin/test-patches -f amd64 -s none 
> > /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch
> >
> > This will apply the patch on the fly, configure the kernel for amd64
> > and build a version with a special changelog entry and a special suffix
> > version dedicated to the test version you generate.
> >
> >
> > In case of troubles, I can provide another way, from git with few
> > commands.
> >
> >
> > Hope this helps,
> > Regards,
> > Romain
> 
> 
> Dear Romain,
> 
> 
> your instructions to build the kernel worked fine, when trying to
> install the kernel,
> 
>    sudo dpkg -i linux-headers-4.19.0-5-amd64_4.19.37-3a~test_amd64.deb 
> linux-image-4.19.0-5-amd64-unsigned_4.19.37-3a~test_amd64.deb
> 
> I run into problem, getting this warning. 
> 
> 
>  │ You are running a kernel (version 4.19.0-5-amd64) and attempting to
> remove the same
> version.  
>  
> │
>  │
>   
>   
> │
>  │ This can make the system unbootable as it will remove
> /boot/vmlinuz-4.19.0-5-amd64 and all modules under the directory
> /lib/modules/4.19.0-5-amd64. This can only be fixed with a copy  │
>  │ of the kernel image and the corresponding
> modules.  
>   

Bug#554444: Same issue as already reported, and partially fixed

[Diederik de Haas]

Control: severity -1 serious

Hi,

This is the same issue as https://bugs.debian.org/904699, which is actually an 
issue in libdebian-installer (https://bugs.debian.org/55).

The fix has actually been made. But the problem is that it needs an unblock ack 
from the d-i team (https://bugs.debian.org/928908), but after 2 weeks there is 
still no reply.
When that is done, (afaik) a rebuild of the package to pick up the change in 
libdebian-installer is needed (at least for cdebootstrap-static? which I'm 
using).

Raised the issue to be RC as cdebootstrap(-static) is pretty much useless as 
it is now if you want to install buster (or sid).
My previous attempts to push this towards a solution have been unsuccessful so 
far and I don't know what else I could do...

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

Bug#898425: ERROR: ld.so: object '/usr/lib/libtcmalloc_minimal.so.4' from LD_PRELOAD cannot be preloaded

[Bernhard Übelacker]

Hello Andy Dorman,
the new location seems to be in the following directory:

root@debian:~# dpkg -L libtcmalloc-minimal4 | sort
...
/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal_debug.so.4
/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal_debug.so.4.5.3
/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4
/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4.5.3

So I guess you should change your configuration that
LD_PRELOAD points to the new file, if this is still an issue.

This report might then just be closed, I guess.

Kind regards,
Bernhard

Bug#929764: [Pkg-gtkpod-devel] Bug#929764: usbmuxd segfaults on startup

[Bernhard Übelacker]

Hello James Henried,
I guess this issue could be related to following shared library.

> 0x77b6a0e0  0x77b7af47  Yes (*) 
> /usr/local/lib/libimobiledevice.so.6

It looks like this file is a manual installed version,
while the debian version of that library should be loaded
from here: /usr/lib/x86_64-linux-gnu/libimobiledevice.so.6

Can you check if you really need that local file?
And if it is renamed, does the problems disappear?

Kind regards,
Bernhard

Bug#888733: hyantesite: test failures on most architectures

[Paul Gevers]

Control: retitle -1 should hyantesite be part of buster?

Hi,

On Tue, 21 May 2019 07:24:17 +0200 Andreas Tille 
wrote:
> On Mon, May 20, 2019 at 08:05:09PM +0100, Rebecca N. Palmer wrote:
> > On 19/05/2019 18:15, Andreas Tille wrote:
> > > So what is the plan to fix this bug?  Create new references to craft
> > > a valid test or ignore these tests?
> > 
> > ...or decide that something that's abandoned and doesn't follow its
> > documentation (even after the above fixes) doesn't belong in Debian stable
> > and let it be removed?  I have no strong opinion.
> > 
> > The above fix was written as part of an attempt to find fixes for all RC
> > bugs in debian-science testing; I hadn't heard of the package before seeing
> > this bug.
> 
> Same for me.  If nobody else might rise an opinion we probably let it go
> and the package will be removed now from testing.  The real usage of
> this package[1] is below 20 users (but anyway there are 20) and I'm
> intentionally CCing Debian Science user list to possibly reach some of
> these users.

If by now, you think the package should be removed, can we have an RM
bug please, such that others don't have to spend the time reading the
bug report?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929814: ITP: ruby-rubocop-performance -- Automatic performance checking tool for Ruby code

[Jongmin Kim]

On Fri, May 31, 2019 at 10:34:21PM +0500, Pirate Praveen wrote:
> Hi jmkim,

Hiya!

> Which rails 6 gem needs this package? We usually don't run style checks
> during build.

No, rails 6 does not need this for building or testing. I miss-estimated
the dependencies.

This package does not serve standalone app and there is no other package
need this package (rubocop-performance), so this package is not-needed.
I'll close this bug.

Thanks!

-- 
Jongmin Kim

OpenPGP key located at https://jongmin.dev/pgp
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#929321: Update for SQLAlchemy to address CVE-2019-7164 CVE-2019-7548

[Paul Gevers]

Control: tags -1 - moreinfo

Hi Thomas,

On 31-05-2019 01:34, Thomas Goirand wrote:
> Dear package maintainer,
> 
> We're about to upgrade SQLAlchemy in Buster to address an SQL injection
> issue. The fixed package is in unstable, under the version 1.2.18+ds1-2.
> 
> In some rare cases, this update may break reverse depenencies, leading
> to non-working SQL queries.
> 
> This is why I'm writing this email to you today: to ask you to please
> test your application with SQLAlchemy 1.2.18+ds1-2 ASAP, to address any
> potential unforecast issue before the Buster release.
> 
> Details about the discussion can be seen here in the Debian bug #929321.
> 
> Best regards,
> 
> Thomas Goirand (zigo)

Thanks for sending this. I'll give this a day or two and then I intend
unblock SQLAlchemy.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929793: liblopsub: please make the build reproducible

[Andre Noll]

On Fri, May 31, 17:05, Chris Lamb wrote

> > Also DATE_FMT should be a singly expanded make variable.
> 
> (Singly, as in ":=" vs "=" ?)

Yes.

> > Care to provide a commit message which explains why we try to
> > pass $(SOURCE_DATE_EPOCH) as an argument to both -d and -r, who
> > sets SOURCE_DATE_EPOCH, and what type its value is supposed to be
> > (filename or number of seconds)?
> 
> In terms of a its value, probably best to canonically link to:
> 
>   https://reproducible-builds.org/specs/source-date-epoch/
> 
> … although as a spoiler, it is a UNIX timestamp. :) Thanks for 
> your review.

Then I don't grok the purpose of the

LC_ALL=C date -u -r '$(SOURCE_DATE_EPOCH)' '$(DATE_FMT)'

command. After all, at least GNU date(1) expects a filename as the
argument to -r.

So how about the simpler patch below?

Best
Andre
---
commit 439a6e427979dbe146319d15411c31f6ebe1f962
Author: Chris Lamb 
Date:   Fri May 31 19:54:04 2019 +0200

Don't embed compile-time timestamps into generated files.

Currently the build is not reproducible because make(1) runs
date(1) to provide the month and the year for the man page. Fix
this by honouring SOURCE_DATE_EPOCH as described in

https://reproducible-builds.org/specs/source-date-epoch/

diff --git a/Makefile b/Makefile
index 408e3a5..3c7bde2 100644
--- a/Makefile
+++ b/Makefile
@@ -21,7 +21,15 @@ INSTALL := install
 GZIP := gzip -f9
 ZCAT := zcat
 
-DATE := $(shell date '+%B %Y')
+DATE_FMT := +%B %Y
+# To get a reproducible build, we use $(SOURCE_DATE_EPOCH) instead of the
+# current time if this variable is set.
+ifdef SOURCE_DATE_EPOCH
+   DATE := $(shell LC_ALL=C date -u -d '@$(SOURCE_DATE_EPOCH)' \
+   '$(DATE_FMT)' 2>/dev/null || LC_ALL=C date -u '$(DATE_FMT)')
+else
+   DATE := $(shell date '+$(DATE_FMT)')
+endif
 GIT_VERSION := $(shell ./version-gen.sh)
 PLAIN_VERSION := $(firstword $(subst -, , $(GIT_VERSION)))
 MAJOR_VERSION := $(firstword $(subst ., , $(PLAIN_VERSION)))
-- 
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#929816: RFS: simhash/0.0.20161225-1 [ITA] -- generate similarity hashes to find nearly duplicate files

[Adam Borowski]

On Sat, Jun 01, 2019 at 01:27:53AM +0800, laokz wrote:
> I am looking for a sponsor for my first package "simhash".
> 
> * Package name: simhash
>   Version : 0.0.20161225-1

> Changes since the last upload:
> 
>  * New maintainer. Closes: #652727
>  * Upgraded d/* according to Debian Policy 4.3.0.3.
>Priority -> optional, Standards-Version -> 4.3.0, debhelper >= 12,
>update Vcs-* fields, add simple testsuite and watch file,
>remove redundant d/{clean,dirs,lintian-overrides}.
>  * Upstream cleaned up buffer signedness warned by gcc. (Git commit fa34436)

Hi!
It's nice to see you taking up this package -- however, this is an upload to
unstable during the freeze.  It's generally a bad idea; it would be better
to either use experimental or to wait until Buster is released.

> After packaging, I checked lintian, debdiff .dsc|.deb results, tried
> install/remove/run, and https://tracker.debian.org/pkg/simhash. More
> explanations:
> 
>  * d/dirs removed: Its content is 'usr/bin' which belongs to FHS.
>  * d/simhash.linlian-overrides removed: It contained "no-upstream-
> changelog", which is nonexisted in current lintian version.
>  * d/{clean,rules,test/*}: Based on source 'test.sh', the testsuite can
> confirm the build procedure. d/clean is no needed also.
>  * d/{watch,source/lintian-overrides}: New version adds a watch file. It is
> not very well but can do work.

It finds some old version for me:

uscan info: Newest version of simhash on remote site is 0.0.20110213, local 
version is 0.0.20161225
uscan info:=> Only older package available from
  https://github.com/BartMassey/simhash master

> Another request. I updated Vcs-* fields, but need you help to upload to
> salsa.debian.org/debian/.

(didn't do this yet)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Bug#929694: cme update dpkg-copyright removes manually added copyright entries

[Pirate Praveen]

On Fri, May 31, 2019 at 11:18 PM, Dominique Dumont  
wrote:
On Wed, 29 May 2019 10:36:27 +0500 Pirate Praveen 


wrote:

 justification: it should not remove any existing copyright noticed
 added by maintainer.


Then what's the point of running "cme update dpkg-copyright" ?



To find out if we missed any copyright notices.


Let's see what's going on:

node-gulp$ licensecheck -r make-iterator --copyright -m
make-iterator/LICENSE   MIT/X11 (BSD like)  2014-2018 Jon 
Schlinkert.

make-iterator/README.md UNKNOWN 2012-2013 moutjs team and contributors
(http:moutjs.com)
make-iterator/index.js  UNKNOWN 2014-2018 Jon Schlinkert.
make-iterator/package.json  UNKNOWN *No copyright*

First problem: LICENSE and README.md do not contain the same copyright
owners. By reading the README.md file, I saw that make-iterator is
derived from moutjs. Hence debian/copyright entry is accurate.

But how can cme decide if the discrepancy is due to upstream change or
upstream inconsistencies ? It cannot.

Don't remove anything if cme is not sure. When more than one notice is 
there, add both, I think that is safer. In this case both notices are 
still present.



license-reconcile choose to throw an error in this case. cme trusts
upstream files.


README.md is also upstream file.


To avoid update debian/copyright with wrong entries, you should
override wrong copyright information in
debian/fill.copyright.blanks.yml as described in
Dpkg::Copyright::Scanner man page.

Note that fill.copyright.blanks can be edited with "cme edit dpkg"


That said, tests done with node-gulp has shown that the way cme
extracts information from LICENSE and README file is not ideal. I'm
going to improve its behaviour.



Thanks.


All the best.

Bug#929694: cme update dpkg-copyright removes manually added copyright entries

[Dominique Dumont]

On Wed, 29 May 2019 10:36:27 +0500 Pirate Praveen  
wrote:
> justification: it should not remove any existing copyright noticed 
> added by maintainer.

Then what's the point of running "cme update dpkg-copyright" ?

Let's see what's going on:

node-gulp$ licensecheck -r make-iterator --copyright -m
make-iterator/LICENSE   MIT/X11 (BSD like)  2014-2018 Jon Schlinkert.
make-iterator/README.md UNKNOWN 2012-2013 moutjs team and contributors 
(http:moutjs.com)
make-iterator/index.js  UNKNOWN 2014-2018 Jon Schlinkert.
make-iterator/package.json  UNKNOWN *No copyright*

First problem: LICENSE and README.md do not contain the same copyright
owners. By reading the README.md file, I saw that make-iterator is
derived from moutjs. Hence debian/copyright entry is accurate.

But how can cme decide if the discrepancy is due to upstream change or
upstream inconsistencies ? It cannot.

license-reconcile choose to throw an error in this case. cme trusts
upstream files.

To avoid update debian/copyright with wrong entries, you should
override wrong copyright information in
debian/fill.copyright.blanks.yml as described in
Dpkg::Copyright::Scanner man page.

Note that fill.copyright.blanks can be edited with "cme edit dpkg"


That said, tests done with node-gulp has shown that the way cme
extracts information from LICENSE and README file is not ideal. I'm
going to improve its behaviour.

All the best.

Bug#929804: gnome-maps: crash when exporting map as the image

[Bernhard Übelacker]

Control: tags -1 + moreinfo


Hello Saša Janiška,
I just tried to reproduce the issue but for me it did not show up.
Therefore a few more information may be required.

Your desktop is running a xorg or wayland session?
Was this just crashing once or can you reproduce it again?

Maybe you could install a package systemd-coredump,
then the last entries returned by 'journalctl --no-pager'
should contain a "Stack trace" that could lead to the
location causing the crash.

Kind regards,
Bernhard

Bug#929814: ITP: ruby-rubocop-performance -- Automatic performance checking tool for Ruby code

[Pirate Praveen]

Hi jmkim,

Which rails 6 gem needs this package? We usually don't run style checks 
during build.


Praveen

Bug#803119: [Debian-rtc-admin] RFA: rtc.debian.org

[gustavo panizzo]

Hi

On Thu, May 30, 2019 at 06:45:13PM +0200, Victor Seva wrote:

Hi,




>[0] https://salsa.debian.org/vseva/dsa-puppet/commits/vseva/xmpp




I'm testing the module using puppet masterless on a personal prosody


--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#927014: qtcreator: Menu disapear

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi bruno!

On Sat, 13 Apr 2019 at 12:39, bruno volpi  wrote:
>
> Package: qtcreator
> Version: 4.8.2-1
> Severity: normal
>
> Dear Maintainer,
>
> with KDE :
> application menu on global menu dashboard :
> disapear in change to another application and doesn't commes back
> application menu on title bar :
> disapear as soon i use Edition of ui
> application menu on menubar under title bar:
> sub menu transparency at 100% -> can't see it
> with Gnome :
> It works well

Sorry, I can't make sense of this. Can you try being more verbose?
Maybe using a translation service if necessary.


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

Bug#929816: RFS: simhash/0.0.20161225-1 [ITA] -- generate similarity hashes to find nearly duplicate files

[laokz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my first package "simhash".

* Package name: simhash
  Version : 0.0.20161225-1
  Upstream Author : Bart Massey 
* URL : http://wiki.cs.pdx.edu/forge/simhash.html
* License : BSD-3-clause
  Section : utils

It builds those binary packages:

  simhash - generate similarity hashes to find nearly duplicate files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/simhash/simhash_0.0.20161225-1.dsc

More information about simhash can be obtained from 
http://wiki.cs.pdx.edu/forge/simhash.html.

Changes since the last upload:

 * New maintainer. Closes: #652727
 * Upgraded d/* according to Debian Policy 4.3.0.3.
   Priority -> optional, Standards-Version -> 4.3.0, debhelper >= 12,
   update Vcs-* fields, add simple testsuite and watch file,
   remove redundant d/{clean,dirs,lintian-overrides}.
 * Upstream cleaned up buffer signedness warned by gcc. (Git commit fa34436)

After packaging, I checked lintian, debdiff .dsc|.deb results, tried
install/remove/run, and https://tracker.debian.org/pkg/simhash. More
explanations:

 * d/dirs removed: Its content is 'usr/bin' which belongs to FHS.
 * d/simhash.linlian-overrides removed: It contained "no-upstream-
changelog", which is nonexisted in current lintian version.
 * d/{clean,rules,test/*}: Based on source 'test.sh', the testsuite can
confirm the build procedure. d/clean is no needed also.
 * d/{watch,source/lintian-overrides}: New version adds a watch file. It is
not very well but can do work.
 
Another request. I updated Vcs-* fields, but need you help to upload to
salsa.debian.org/debian/.

Regards,
laokz

Bug#929814: ITP: ruby-rubocop-performance -- Automatic performance checking tool for Ruby code

[Jongmin Kim]

Package: wnpp
Severity: wishlist
Owner: Jongmin Kim 

* Package name: ruby-rubocop-performance
  Version : 1.3.0
  Upstream Author : Bozhidar Batsov 
* URL : https://github.com/rubocop-hq/rubocop-performance
* License : Expat
  Programming Lang: Ruby
  Description : Automatic performance checking tool for Ruby code

 This package provides a collection of RuboCop cops to check for
 performance optimizations in Ruby code.

This package is a dependency of latest rubycop and rails 6.

Bug#929815: uglifyjs.terser does not work for any file

[Pirate Praveen]

package: uglifyjs.terser
version: 3.14.1-1
severity: grave
justification: it does not work at all

Sample repo https://salsa.debian.org/gi-boi-guest/node-d3-fetch

Also tried in https://salsa.debian.org/js-team/node-d3-scale-chromatic 
with same error when trying to minimize dist/d3-scale-chromatic.js


$ uglifyjs.terser dist/d3-fetch.js -o dist/d3-fetch.min.js
module.js:549
   throw err;
   ^

Error: Cannot find module '../tools/exit.js'
   at Function.Module._resolveFilename (module.js:547:15)
   at Function.Module._load (module.js:474:25)
   at Module.require (module.js:596:17)
   at require (internal/module.js:11:18)
   at Object. (/usr/lib/nodejs/terser/bin/uglifyjs:6:1)
   at Module._compile (module.js:652:30)
   at Object.Module._extensions..js (module.js:663:10)
   at Module.load (module.js:565:32)
   at tryModuleLoad (module.js:505:12)
   at Function.Module._load (module.js:497:3)

Bug#929813: unblock: pugixml/1.9-3

[Gianfranco Costamagna]

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

Hello, looks like pugixml has been installing the cmake files into a 
non-standard path:
usr/share/pugixml-dev/cmake
instead of:
/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/pugixml

I fixed that and uploaded in unstable, after a cmake developer pointed this out 
to us.

I also checked, and now the cmake file is correctly parsed.

thanks for caring,

Gianfranco

debdiff:
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pugixml (1.9-3) unstable; urgency=medium
+
+  * Team upload
+  * Fixup dev package creation, cmake was put in wrong place
+(Closes: #929792)
+
+ -- Gianfranco Costamagna   Fri, 31 May 2019 
13:00:23 +0200
+
 pugixml (1.9-2) unstable; urgency=medium
 
   * Upload to unstable
diff --git a/debian/rules b/debian/rules
index a910c39..0ca135d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -80,7 +80,7 @@ debian/stamp-local-shlibs-$(lib): \
--override s/$(lib)$(major)-dev/$(lib)-dev/ \
--movedev "debian/tmp/usr/include/*" usr/include/ \
--movedev "debian/tmp/usr/lib/*/cmake/pugixml/*" \
-   usr/share/$(lib)-dev/cmake \
+   /usr/lib/$(DEB_HOST_MULTIARCH)/cmake/pugixml \
--movedev "debian/tmp/usr/lib/pkgconfig/*" \
usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig \
debian/tmp/usr/lib/*/$(lib).so

Bug#929764: [Pkg-gtkpod-devel] Bug#929764: usbmuxd segfaults on startup

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2019-05-31 at 10:35 -0400, James Henried wrote:
> Please let me know if this is useful/ok or if I need to do anything
> else.

It looks OpenSSL related, but besides that I don't have much clue yet. It
might help to install dbgsym packages for usbmuxd, libssl and libusbmuxd
though.

See https://wiki.debian.org/SourcesList#Debug_Symbol_Packages for example.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlzxXTQACgkQ3rYcyPpX
RFu+wggAp15qEZo4qe43XiNU3dKM3lmGzeSui+1QIgzMRHJJL54LywGPrTsFZpmx
AtvUj6bUKLbkGXRgaQ3zBmFzoRt0OWPayTqCcMDrgYRtHYjEz6s5RJ2mChSl/FbE
kMdlpL8AZ1QeuYIKAcOX4838yISIkzFUSn+EhISS2m9OrVRlW9UGlFS1rt8TU0k/
aQb6qQNzqQ036tqFGvu4uCNrJAUbU8h4sCRiZvdoY108lJTZc8KoRHl+COlmiByr
J+r17HEB5//34NoaXy/ffU/OUbR0dT7JDVJuBWQdmmZbrI33i4TcIalVhRF4nZMi
FJ2+cwglEVteBKwpqDPaCrj1M9kFeQ==
=1FAP
-END PGP SIGNATURE-

Bug#929098: linux-image-4.19.0-5-amd64: No graphics with Radeon Vega 1.0

[skodde]

Hi,

I can confirm this bug. The systems boots with 'nomodeset'.

0c:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] (rev c1)

It works fine with

linux-image-4.19.0-4-amd64 (4.19.28-2)

and

linux-image-5.0.0-trunk-amd64 (5.0.2-1~exp1)


Thanks

Bug#929798: exim4-base: /etc/cron.daily/exim4-base will not rotate paniclog if it is 100% noise.

[Andreas Metzler]

On 2019-05-31 Kyrian  wrote:
> Quoting Andreas Metzler :
[...]
> > So if paniclog is non-empty, but only contains ignored lines then the
> > log is not-rotated but warning mails are not sent out. So "warning
> > emails keep coming" will not happen.

> Yes, I agree that is the logic that the script follows.

> Anyway, having worked through it all again in my head and worked out the
> bits that are deliberate on the developer's part, and the red herrings, I
> think this is the issue I meant...

> If you have a paniclog full of rubbish you want to ignore (say 4138/4143
> lines are junk in the log, and the error is not in the last
> $E4BCD_PANICLOG_LINES lines), the step that does 'tail -n' on the paniclog
> and sends it out without filtering in the same way with
> $E4BCD_PANICLOG_NOISE, then all the email gives you are the lines of noise
> (which looks remarkably similar day-to-day if it's all exactly the same
> error with just different timestamps, and perhaps that lead me to think
> 'once' was being ignored), not the actual non-ignored lines that triggered
> the email.

Hello,

that part (sending out the unfiltered lines) does not make a lot of
sense. Thanks for explaining the issue in detail.

> I think that's what got me thinking that the log rotation should happen if
> the paniclog has *something* in it even if it's junk that you ignore,
> because you can get a lt of junk in those logs. That might end up being
> counter-intuitive for some use cases though I guess. Another thing to do
> might be to change the "tail -n" line to:

> grep -v "$E4BCD_PANICLOG_NOISE" /var/log/exim4/paniclog | tail -n
> "${E4BCD_PANICLOG_LINES}"

Sounds like a good idea.

[...]
> This is sounding more like a feature request than a bug I suppose.

I can see reasons both for rotating paniclog consisting entirely of
noise (space) and for not rotating it (an important one being "we have
always done that").

I will definitely change the mail, but tend to keep the rotation logic
unchanged.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#929793: liblopsub: please make the build reproducible

[Chris Lamb]

Hi Andr,

> This does not work if SOURCE_DATE_EPOCH is set because the unnamed
> argument has with two '+' characters (one from DATE_FMT and one
> from the command line).

Mea culpa; I must have copy-pasted too hastily from my terminal to my
email editor (also causing the quotes and LC_ALL confusion) from a
previous iteration of my patch.

> Also DATE_FMT should be a singly expanded make variable.

(Singly, as in ":=" vs "=" ?)

> Care to provide a commit message which explains why we try to
> pass $(SOURCE_DATE_EPOCH) as an argument to both -d and -r, who
> sets SOURCE_DATE_EPOCH, and what type its value is supposed to be
> (filename or number of seconds)?

In terms of a its value, probably best to canonically link to:

  https://reproducible-builds.org/specs/source-date-epoch/

… although as a spoiler, it is a UNIX timestamp. :) Thanks for 
your review.


Regards,

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

Bug#765448: libvirt-daemon-system is not installable on non-systemd system

[sergio]

libvirt-daemon-system is still not installable on non-systemd system due
to policykit-1 dependency

1. on gentoo libvirt works without policykit or systemd
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897936

-- 
sergio.

Bug#929812: debian-security-support: [INTL:it] Updated Italian translation

[Holger Levsen]

On Fri, May 31, 2019 at 05:38:14PM +0200, Beatrice Torracca wrote:
> here is te updated translation of the po file for debian-security support. 
> Please include it in the next upload.

thank you & will do! :)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Some people say that the climate crisis  is something that we all have created,
but  that is not true,  because if everyone is guilty  then no one is to blame.
And someone is to blame.  Some people, some companies,  some decision-makers in
particular, have known exactly what priceless values they have been sacrificing
to continue making unimaginable amounts of money.


signature.asc
Description: PGP signature

Bug#800345: bug still present in 2.2-6~bpo9+1 (stretch-backports)

[Klaus Thorn]

There is 95% left:

# df
Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/sda2   51475044   2169988  49317068   5% /

But 0 is reported:


# /usr/lib/nagios/plugins/check_disk -w 10% -c 5% [...]
DISK CRITICAL - free space: CRITICAL [ / 0 MB (0% inode=-)];[...]

type is btrfs:

# mount|grep "/ "
/dev/sda2 on / type btrfs 
(rw,noatime,compress=zlib,space_cache,subvolid=257,subvol=/@)



I looked into the source and did not find the patch there:

source:
http://deb.debian.org/debian/pool/main/m/monitoring-plugins/monitoring-plugins_2.2.orig.tar.gz
http://deb.debian.org/debian/pool/main/m/monitoring-plugins/monitoring-plugins_2.2-6~bpo9+1.debian.tar.xz

patch:
https://github.com/monitoring-plugins/monitoring-plugins/pull/1388/commits/23436a18516e66469aeb4d81329d62ee4bfa7a51


--
Freundliche Grüße / Best Regards

Klaus Thorn

Bug#929812: debian-security-support: [INTL:it] Updated Italian translation

[Beatrice Torracca]

Package: debian-security-support
Severity: wishlist
Tags: l10n patch

Hi,

here is te updated translation of the po file for debian-security support. 
Please include it in the next upload.

Thanks,

beatrice
# Italian translation of debian-security-support debconf messages.
# Copyright (C) 2014, debian-security-support package's copyright holder
# This file is distributed under the same license as the 
debian-security-support package.
# Beatrice Torracca , 2014, 2016, 2019.
msgid ""
msgstr ""
"Project-Id-Version: debian-security-support\n"
"Report-Msgid-Bugs-To: debian-security-supp...@packages.debian.org\n"
"POT-Creation-Date: 2016-06-07 12:13+0200\n"
"PO-Revision-Date: 2019-05-31 17:34+0200\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#: ../check-support-status.in:24
#, sh-format
msgid ""
"Unknown DEBIAN_VERSION $DEBIAN_VERSION. Valid values from "
"$DEB_LOWEST_VER_ID and $DEB_NEXT_VER_ID"
msgstr ""
"DEBIAN_VERSION $DEBIAN_VERSION sconosciuta. Valori validi da $"
"DEB_LOWEST_VER_ID e $DEB_NEXT_VER_ID"

#: ../check-support-status.in:63
msgid "Failed to parse the command line parameters"
msgstr "Analisi dei parametri della riga di comando fallita"

#: ../check-support-status.in:72
#, sh-format
msgid "$name version $VERSION"
msgstr "$name versione $VERSION"

#: ../check-support-status.in:101
msgid "E: Internal error"
msgstr "E: errore interno"

#: ../check-support-status.in:117
msgid "E: Need a --type if --list is given"
msgstr "E: Necessario --type se è specificato --list"

#: ../check-support-status.in:130
#, sh-format
msgid "E: Unknown --type '$TYPE'"
msgstr "E: --type '$TYPE' sconosciuto"

#: ../check-support-status.in:152
msgid "E: Cannot detect dpkg version, assuming wheezy or newer"
msgstr ""
"E: impossibile rilevare la versione di dpkg, viene supposto sia "
"wheezy o successiva"

#: ../check-support-status.in:282
msgid "Future end of support for one or more packages"
msgstr ""
"Termine previsto del supporto di sicurezza per uno o più pacchetti"

#: ../check-support-status.in:285
msgid ""
"Unfortunately, it will be necessary to end security support for some "
"packages before the end of the regular security maintenance life "
"cycle."
msgstr ""
"Sfortunatamente sarà necessario terminare il supporto di sicurezza "
"per alcuni pacchetti prima della fine del regolare ciclo di vita di "
"manutenzione di sicurezza."

#: ../check-support-status.in:288 ../check-support-status.in:298
#: ../check-support-status.in:308
msgid ""
"The following packages found on this system are affected by this:"
msgstr "Ciò ha effetto sui seguenti pacchetti presenti nel sistema:"

#: ../check-support-status.in:292
msgid "Ended security support for one or more packages"
msgstr "Supporto di sicurezza terminato per uno o più pacchetti"

#: ../check-support-status.in:295
msgid ""
"Unfortunately, it has been necessary to end security support for some "
"packages before the end of the regular security maintenance life "
"cycle."
msgstr ""
"Sfortunatamente è stato necessario terminare il supporto di sicurezza "
"per alcuni pacchetti prima della fine del regolare ciclo di vita di "
"manutenzione di sicurezza."

#: ../check-support-status.in:302
msgid "Limited security support for one or more packages"
msgstr "Supporto di sicurezza limitato per uno o più pacchetti"

#: ../check-support-status.in:305
msgid ""
"Unfortunately, it has been necessary to limit security support for "
"some packages."
msgstr ""
"Sfortunatamente è stato necessario limitare il supporto di sicurezza "
"per alcuni pacchetti."

#: ../check-support-status.in:320
#, sh-format
msgid "* Source:$SRC_NAME, will end on $ALERT_WHEN"
msgstr "* Sorgente:$SRC_NAME, terminerà il $ALERT_WHEN"

#: ../check-support-status.in:323
#, sh-format
msgid ""
"* Source:$SRC_NAME, ended on $ALERT_WHEN at version $ALERT_VERSION"
msgstr ""
"* Sorgente:$SRC_NAME, terminato il $ALERT_WHEN alla versione "
"$ALERT_VERSION"

#: ../check-support-status.in:326
#, sh-format
msgid "* Source:$SRC_NAME"
msgstr "* Sorgente:$SRC_NAME"

#: ../check-support-status.in:330
#, sh-format
msgid "  Details: $ALERT_WHY"
msgstr "  Dettagli: $ALERT_WHY"

#: ../check-support-status.in:333
msgid "  Affected binary package:"
msgstr "  Pacchetto binario affetto:"

#: ../check-support-status.in:335
msgid "  Affected binary packages:"
msgstr "  Pacchetti binari affetti:"

#: ../check-support-status.in:338
#, sh-format
msgid "  - $BIN_NAME (installed version: $BIN_VERSION)"
msgstr "  - $BIN_NAME (versione installata: $BIN_VERSION)"

Bug#929811: Port build to gulp 4 (transition coming)

[Pirate Praveen]

package: node-postcss
version: 6.0.23-1
severity: important

gulp 4.0 is now available in experimental. We'd like to upload it to 
unstable (after freeze) when all reverse build dependencies are ported.


pravi@nishumbha:~/forge/debian/git/js-team/node-postcss$ 
dpkg-buildpackage

dpkg-buildpackage: info: source package node-postcss
dpkg-buildpackage: info: source version 6.0.23-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Pirate Praveen 


dpkg-buildpackage: info: host architecture amd64
dpkg-source --before-build .
fakeroot debian/rules clean
dh clean
  debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/home/pravi/forge/debian/git/js-team/node-postcss'

gulp clean || true
[20:58:52] Local gulp not found in 
~/forge/debian/git/js-team/node-postcss

[20:58:52] Try running: npm install gulp
[20:58:52] Using globally installed gulp
assert.js:42
 throw new errors.AssertionError({
 ^

AssertionError [ERR_ASSERTION]: Task function must be specified
   at Gulp.set [as _setTask] 
(/usr/lib/nodejs/gulp/node_modules/undertaker/lib/set-task.js:10:3)
   at Gulp.task 
(/usr/lib/nodejs/gulp/node_modules/undertaker/lib/task.js:13:8)
   at Object. 
(/home/pravi/forge/debian/git/js-team/node-postcss/gulpfile.js:38:6)

   at Module._compile (module.js:652:30)
   at Object.Module._extensions..js (module.js:663:10)
   at Module.load (module.js:565:32)
   at tryModuleLoad (module.js:505:12)
   at Function.Module._load (module.js:497:3)
   at Module.require (module.js:596:17)
   at require (internal/module.js:11:18)
dh_auto_clean
make[1]: Leaving directory 
'/home/pravi/forge/debian/git/js-team/node-postcss'

  dh_clean
dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building node-postcss using existing 
./node-postcss_6.0.23.orig.tar.gz

dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building node-postcss in 
node-postcss_6.0.23-1.debian.tar.xz

dpkg-source: info: building node-postcss in node-postcss_6.0.23-1.dsc
debian/rules build
make: 'build' is up to date.
fakeroot debian/rules binary
dh binary
  dh_update_autotools_config
  dh_autoreconf
  debian/rules override_dh_auto_build
make[1]: Entering directory 
'/home/pravi/forge/debian/git/js-team/node-postcss'

gulp build
[20:58:54] Local gulp not found in 
~/forge/debian/git/js-team/node-postcss

[20:58:54] Try running: npm install gulp
[20:58:54] Using globally installed gulp
assert.js:42
 throw new errors.AssertionError({
 ^

AssertionError [ERR_ASSERTION]: Task function must be specified
   at Gulp.set [as _setTask] 
(/usr/lib/nodejs/gulp/node_modules/undertaker/lib/set-task.js:10:3)
   at Gulp.task 
(/usr/lib/nodejs/gulp/node_modules/undertaker/lib/task.js:13:8)
   at Object. 
(/home/pravi/forge/debian/git/js-team/node-postcss/gulpfile.js:38:6)

   at Module._compile (module.js:652:30)
   at Object.Module._extensions..js (module.js:663:10)
   at Module.load (module.js:565:32)
   at tryModuleLoad (module.js:505:12)
   at Function.Module._load (module.js:497:3)
   at Module.require (module.js:596:17)
   at require (internal/module.js:11:18)
debian/rules:12: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1
make[1]: Leaving directory 
'/home/pravi/forge/debian/git/js-team/node-postcss'

debian/rules:9: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess 
returned exit status 2

Bug#929467: RFS: tfortune-1.0.0 [ITP]

[Adam Borowski]

On Fri, May 24, 2019 at 08:57:49AM +0200, Andre Noll wrote:
>  * Package name: tfortune
>Version : 1.0.0

>   git clone git://git.tuebingen.mpg.de/tfortune/

Hi!
I'm afraid your packaging unnecessarily reinvents a good part of usual
tools, and does this wrong.  For example:
* directories have non-standard permissions, and this affects common dirs as
  well
* gzip is invoked without -n, which renders the package non-reproducible
* standard build flags don't get passed to the compiler
* no md5sum files are generated

I'd recommend using dh instead.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Bug#929809: debian-security-support: [INTL:nl] Dutch po file for the debian-security-support package

[Holger Levsen]

Hi Frans,

On Fri, May 31, 2019 at 05:12:10PM +0200, Frans Spiesschaert wrote:
> Please find attached the Dutch po file for the debian-security-
> support package. 

nice, thanks, commited & will be included in the upload tomorrow.

(& btw, also thanks for merging from weblatte for d-edu-doc today! :)

> It has been submitted for review to the debian-l10n-dutch mailing
> list. 

cool, also! 


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


signature.asc
Description: PGP signature

Bug#929810: grml-debootstrap: Unreliable configuration of predictable network interface names

[Michael Prokop]

Package: grml-debootstrap
Version: 0.88
Severity: important

We noticed that the network configuration generated by
grml-debootstrap is unreliable for the predictable network naming
schema (when net.ifname=0 isn't set).

The underlying code in grml-debootstrap currently iterates over all
network devices via:

  for interface in $(udevadm info -e | sed -n -e 's/E: 
ID_NET_NAME_PATH=\([^$*]\)/\1/p'); do
  [...]

This means that we get something like the following for a (Proxmox)
VM with a virtio network device:

  # udevadm info -e | grep 'ID_NET_NAME_PATH'
  E: ID_NET_NAME_PATH=enp0s18

While on actual boot the device is named ens18 then. This results in
the VM having a broking network configuration.

I managed to track this down already. In systemd's link_config_apply
function (defined in src/udev/net/link-config.c) we have:

| switch (policy) {
| case NAMEPOLICY_KERNEL:
| if (name_type != NET_NAME_PREDICTABLE)
| continue;
|
| /* The kernel claims to have given a predictable name, keep 
it. */
| log_device_debug(device, "Policy *%s*: keeping predictable 
kernel name",
|  name_policy_to_string(policy));
| goto no_rename;
| case NAMEPOLICY_KEEP:
| if (!IN_SET(name_type, NET_NAME_USER, NET_NAME_RENAMED))
| continue;
|
| log_device_debug(device, "Policy *%s*: keeping existing 
userspace name",
|  name_policy_to_string(policy));
| goto no_rename;
| case NAMEPOLICY_DATABASE:
| (void) sd_device_get_property_value(device, 
"ID_NET_NAME_FROM_DATABASE", _name);
| break;
| case NAMEPOLICY_ONBOARD:
| (void) sd_device_get_property_value(device, 
"ID_NET_NAME_ONBOARD", _name);
| break;
| case NAMEPOLICY_SLOT:
| (void) sd_device_get_property_value(device, 
"ID_NET_NAME_SLOT", _name);
| break;
| case NAMEPOLICY_PATH:
| (void) sd_device_get_property_value(device, 
"ID_NET_NAME_PATH", _name);
| break;
| case NAMEPOLICY_MAC:
| (void) sd_device_get_property_value(device, 
"ID_NET_NAME_MAC", _name);
| break;
| default:
| assert_not_reached("invalid policy");
| }

So if a device has the propery ID_NET_NAME_PATH set (e.g. enp0s18),
but also ID_NET_NAME_SLOT (ens18), we can't just use the value from
ID_NET_NAME_PATH but have to follow the precedence.

I tend to call this a RC bug, so we should get this fixed for
Debian/buster.

regards
-mika-


signature.asc
Description: Digital signature

Bug#929674: --pristine-tar option to gbp import-dsc does not add multiple tarballs to pristine-tar branch

[Pirate Praveen]

On Fri, May 31, 2019 at 7:55 PM, Guido =?iso-8859-1?q?G=FCnther?= 
 wrote:

Hi,
On Tue, May 28, 2019 at 06:56:51PM +0500, Pirate Praveen wrote:



 On Tue, May 28, 2019 at 5:54 PM, Guido =?iso-8859-1?q?G=FCnther?=
  wrote:
 > control: -1 tags +moreinfo
 > control: -1 severity normal
 >
 >
 > Hi,
 > On Tue, May 28, 2019 at 04:26:03PM +0500, Pirate Praveen wrote:
 > >  package: git-buildpackage
 > >  version: 0.9.14
 > >  severity: important
 > >
 > >  When using multiple tarballs and components in 
debian/gbp.conf, gbp
 > >  import-dsc imports the tarballs to master branch but does not 
add

 > > them to
 > >  pristine-tar branch
 >
 > I don't think this is an issue with additional tarballs per se 
since

 > we're testing this
 >
 > 
https://github.com/agx/git-buildpackage/blob/master/tests/component/deb/test_import_dsc.py#L178

 >
 > and the code is basicall the same as in import_orig. Something 
else must
 > be different in your setup. When reporting such things please 
make sure

 > it's 1:1 reproducible by publishing the needed tarballs, repo and
 > command issued. Also please follow

 Sorry, I thought I added the repo, but missed it.

 The repo is here https://salsa.debian.org/js-team/node-gulp


At what revision is that repo when you import the dsc?
Every time a new module is added I import the dsc. You can take the 
master HEAD.





 uscan -dd will download all the tarballs.


But I'd need a dsc not orig tarballs (I read the bug report to affect
import-dsc)


I use dpkg-source -b . to create dsc after uscan -dd.


 > /usr/share/bug/git-buildpackage/presubj and use `--verbose` when 
pasting
 > command output since the output without `--verbose` is not 
sufficient

 > for debugging such things.
 > Cheers,

 Here is the verbose log,

 $ gbp import-dsc --pristine-tar --verbose ../node-gulp_4.0.2-1.dsc


...where does this dsc come from? The archive only has 3.9.1-7. Can 
you

dump it somehwhere?

As said above, I use dpkg-source -b . after uscan -dd to create dsc. I 
have just uploaded 4.0.2-1 to the archive.



Cheers,
 -- Guido


 gbp:debug: ['git', 'rev-parse', '--show-cdup']
 gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
 gbp:debug: ['git', 'rev-parse', '--git-dir']
 gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)',
 'refs/heads/']
 gbp:debug: ['git', 'status', '--porcelain']
 gbp:debug: Upstream version: 4.0.2
 gbp:debug: Debian version: 1
 gbp:debug: Upstream tarball:
 /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig.tar.gz
 gbp:debug: Additional tarballs:
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-ansi-colors.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-ansi-wrap.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-arr-filter.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-arr-map.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-each.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-initial.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-last.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-slice.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-sort.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-async-done.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-async-settle.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-bach.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-collection-map.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-color-support.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-copy-props.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-default-compare.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-default-resolution.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-each-props.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-gulp-cli.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-homedir-polyfill.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-is-absolute.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-is-relative.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-last-run.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-make-iterator.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-matchdep.tar.gz,
 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-mute-stdout.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-now-and-later.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-object-defaults.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-object-reduce.tar.gz, 
/home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-replace-homedir.tar.gz, 

Bug#929809: debian-security-support: [INTL:nl] Dutch po file for the debian-security-support package

[Frans Spiesschaert]

 
 
Package: debian-security-support 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch po file for the debian-security-
support package. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip

Bug#929782: cryptsetup-initramfs: Detects rootfs incorrectly

[Guilhem Moulin]

On Fri, 31 May 2019 at 14:55:04 +0200, Guilhem Moulin wrote:
> And your proposed logic won't work well with detached headers, which
> might be long gone by the time the initramfs image is created.

My bad, on second read your proposal doesn't affect detached headers at
all, as you only propose to change the way how mountpoints are mapped to
dm-crypt target(s), not further discovery (further device stack traversal).

However I believe my other points remain.  Perhaps we could look
mountpoints up in /etc/fstab first, and fallback to /proc/mounts for the
missing ones; thought at this point it's not clear to me whether that
would be regression-free.

By the way, with your use-case if the source device from /etc/fstab were
specified by UUID (like the debian installer does by default) not as
/dev/mapper/$NAME, then mapping it to a crypttab(5) entry is bound to
fail: the mapped device with that UUID has the new/transient name.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#929793: liblopsub: please make the build reproducible

[Andre Noll]

On Fri, May 31, 09:44, Chris Lamb wrote
> Whilst working on the Reproducible Builds effort [0], we noticed
> that liblopsub could not be built reproducibly.

No general objection from my side.  However,

> -DATE := $(shell date '+%B %Y')
> +DATE_FMT = '+%B %Y'
> +ifdef SOURCE_DATE_EPOCH
> + DATE := $(shell LC_ALL=C date -u -d "@$(SOURCE_DATE_EPOCH)" 
> "+$(DATE_FMT)" 2>/dev/null || LC_ALL=C date -u -r "$(SOURCE_DATE_EPOCH)" 
> "+$(DATE_FMT)" 2>/dev/null || date LC_ALL=C -u "+$(DATE_FMT)")
> +else
> + DATE := $(shell date "+$(DATE_FMT)")
> +endif

This does not work if SOURCE_DATE_EPOCH is set because the unnamed
argument has with two '+' characters (one from DATE_FMT and one
from the command line). Also DATE_FMT should be a singly expanded
make variable. Next, the quotes in DATE_FMT will be copied into the
command line, resulting in a syntax error. Finally, "date" and "LC_ALL=C"
in the third command of the first alternative are in the wrong order.

Also, it would be nice to get rid of the overlong line.  The patch
below fixes the syntax errors and is easier to read IMO.

Care to provide a commit message which explains why we try to
pass $(SOURCE_DATE_EPOCH) as an argument to both -d and -r, who
sets SOURCE_DATE_EPOCH, and what type its value is supposed to be
(filename or number of seconds)?

Thanks
Andre
---
diff --git a/Makefile b/Makefile
index 408e3a5..b72db24 100644
--- a/Makefile
+++ b/Makefile
@@ -21,7 +21,18 @@ INSTALL := install
 GZIP := gzip -f9
 ZCAT := zcat
 
-DATE := $(shell date '+%B %Y')
+DATE_FMT := +%B %Y
+ifdef SOURCE_DATE_EPOCH
+   DATE := $(shell \
+   LC_ALL=C date -u -d '@$(SOURCE_DATE_EPOCH)' '$(DATE_FMT)' \
+   2>/dev/null || \
+   LC_ALL=C date -u -r '$(SOURCE_DATE_EPOCH)' '$(DATE_FMT)' \
+   2>/dev/null || \
+   LC_ALL=C date -u '$(DATE_FMT)' \
+   )
+else
+   DATE := $(shell date "+$(DATE_FMT)")
+endif
 GIT_VERSION := $(shell ./version-gen.sh)
 PLAIN_VERSION := $(firstword $(subst -, , $(GIT_VERSION)))
 MAJOR_VERSION := $(firstword $(subst ., , $(PLAIN_VERSION)))

-- 
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#929798: exim4-base: /etc/cron.daily/exim4-base will not rotate paniclog if it is 100% noise.

[Kyrian]

Quoting Andreas Metzler :


On 2019-05-31 Kev Green  wrote:

Package: exim4-base
Version: 4.84.2-2+deb*
Severity: normal

[...]

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



Doing $E4BCD_PANICLOG_NOISE to begin with was one mitigation, but it
does not respect the 'once' mode of $E4BCD_WATCH_PANICLOG so warning
emails keep coming until manual intervention is done.



I do not get this part of the bug-report. Afaict from looking at the
script the following happens (in pseudocode):

1. Check for nonempty paniclog.
2. If E4BCD_PANICLOG_NOISE is not set or if paniclog contains lines NOT
ignored by E4BCD_PANICLOG_NOISE then
  a) send out a warning mail
  b) rotate log if "$E4BCD_WATCH_PANICLOG"="once"

So if paniclog is non-empty, but only contains ignored lines then the
log is not-rotated but warning mails are not sent out. So "warning
emails keep coming" will not happen.

cu Andreas


Yes, I agree that is the logic that the script follows.

Anyway, having worked through it all again in my head and worked out  
the bits that are deliberate on the developer's part, and the red  
herrings, I think this is the issue I meant...


If you have a paniclog full of rubbish you want to ignore (say  
4138/4143 lines are junk in the log, and the error is not in the last  
$E4BCD_PANICLOG_LINES lines), the step that does 'tail -n' on the  
paniclog and sends it out without filtering in the same way with  
$E4BCD_PANICLOG_NOISE, then all the email gives you are the lines of  
noise (which looks remarkably similar day-to-day if it's all exactly  
the same error with just different timestamps, and perhaps that lead  
me to think 'once' was being ignored), not the actual non-ignored  
lines that triggered the email.


I think that's what got me thinking that the log rotation should  
happen if the paniclog has *something* in it even if it's junk that  
you ignore, because you can get a lt of junk in those logs. That  
might end up being counter-intuitive for some use cases though I  
guess. Another thing to do might be to change the "tail -n" line to:


grep -v "$E4BCD_PANICLOG_NOISE" /var/log/exim4/paniclog | tail -n  
"${E4BCD_PANICLOG_LINES}"


It struck me as a bug initially because I thought when grep finds no  
matches it returns 1 rather than 0 might be tripping up the script  
logic, but what you say above suggests that was intentional.


As best I can tell, the "tail -n" line is unchanged up to the most  
recent package version.


This is sounding more like a feature request than a bug I suppose.

K.

Bug#929764: usbmuxd segfaults on startup

[James Henried]

Yves-Alexis Perez  wrote:

> Hi, can you also provide the information asked in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919630#10 ?

Yes, I'm happy to:

> When does this behavior started? Is it recently or
> more ancient?

It's not recent. I've used ifuse on this system for years, but have
been having trouble for at least 6 months, possibly longer.


> I can't reproduce this (it works fine whether I plug an iPhone and let
> udev/systemd runs usbmuxd or wether I run usbmuxd manually). What is the iOS
> version? 

This is an iPhone 5 with IOD 10.3.3 (14G60).


> Is the iPhone correctly seen by lsusb?

Yes:

$ lsusb
Bus 006 Device 002: ID 8087:8002 Intel Corp. 
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 8087:800a Intel Corp. 
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 05ac:12a8 Apple, Inc. iPhone5/5C/5S/6
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ 



> What does ideviceinfo reports?

$ ideviceinfo 
No device found, is it plugged in?
double free or corruption (fasttop)
Aborted
$


> Can you install the various debugging packages and take a backtrace?

Yes. I will do this now and send in response to Bernhard Übelacker's
post.


Thank you, all, for your continued help.

Bug#929764: usbmuxd segfaults on startup

[James Henried]

Bernhard Übelacker  wrote:


> Maybe you could install the package systemd-coredump.
> That way in the journal would appear a backtrace that
> could give some hints where the segmentation fault happens.
> Visible in the output of:

> journalctl --no-pager

Here it is:


May 31 10:29:05 debian systemd[1]: /lib/systemd/system/usbmuxd.service:6: 
PIDFile= references path below legacy directory /var/run/, updating 
/var/run/usbmuxd.pid → /run/usbmuxd.pid; please update the unit file 
accordingly.
May 31 10:29:05 debian systemd[1]: getty@tty1.service: Current command vanished 
from the unit file, execution of the command list won't be resumed.
May 31 10:29:05 debian systemd[1]: Listening on Process Core Dump Socket.
May 31 10:29:19 debian su[28045]: pam_unix(su:session): session closed for user 
root
May 31 10:29:34 debian su[29407]: (to root) jh on pts/0
May 31 10:29:34 debian su[29407]: pam_unix(su:session): session opened for user 
root by (uid=1000)
May 31 10:29:38 debian usbmuxd[29410]: [1] Another instance is already running 
(pid 26593). exiting.
May 31 10:29:38 debian kernel: do_general_protection: 496 callbacks suppressed
May 31 10:29:38 debian kernel: traps: usbmuxd[29410] general protection 
ip:7f9e393d49bd sp:7ffd67ab0b60 error:0 in libc-2.28.so[7f9e39372000+148000]
May 31 10:29:38 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
May 31 10:29:38 debian systemd[1]: Started Process Core Dump (PID 29411/UID 0).
May 31 10:29:38 debian systemd-coredump[29412]: Process 29410 (usbmuxd) of user 
0 dumped core.
 
 Stack trace of thread 29410:
 #0  0x7f9e393d49bd 
__GI___libc_free (libc.so.6)
 #1  0x7f9e391a09f0 
OPENSSL_sk_pop_free (libcrypto.so.1.1)
 #2  0x7f9e392ccc29 n/a 
(libssl.so.1.1)
 #3  0x7f9e3913af1a 
OPENSSL_cleanup (libcrypto.so.1.1)
 #4  0x7f9e3938a2b7 
__cxa_finalize (libc.so.6)
 #5  0x7f9e3903c093 n/a 
(libcrypto.so.1.1)
 #6  0x7f9e399bf6f6 
_dl_fini (ld-linux-x86-64.so.2)
 #7  0x7f9e39389d8c 
__run_exit_handlers (libc.so.6)
 #8  0x7f9e39389eba 
__GI_exit (libc.so.6)
 #9  0x7f9e393740a2 
__libc_start_main (libc.so.6)
 #10 0x55821d8f0b0a n/a 
(usbmuxd)


> Additional you could install the package gdb and start
> usbmuxd with the following command:

Done:

Script started on 2019-05-31 10:32:30-04:00 [TERM="xterm-256color" 
TTY="/dev/pts/0" COLUMNS="69" LINES="41"]
Reading symbols from usbmuxd...(no debugging symbols found)...done.
Starting program: /usr/sbin/usbmuxd 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x101040104070701) at malloc.c:3093
3093malloc.c: No such file or directory.
rax0x0 0
rbx0x0 0
rcx0x1 1
rdx0x79e   1950
rsi0x77923f08  140737346944776
rdi0x101040104070701   72343471423686401
rbp0x55589d20  0x55589d20
rsp0x7fffdf10  0x7fffdf10
r8 0xf 15
r9 0x5556da50  93824992336464
r100x0 0
r110x246   582
r120x778e92b0  140737346704048
r130x77b2cd90  140737349078416
r140x2 2
r150x77b2cd80  140737349078400
rip0x779f49bd  0x779f49bd <__GI___libc_free+29>
eflags 0x10202 [ IF RF ]
cs 0x3351
ss 0x2b43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
1: x/i $pc
=> 0x779f49bd <__GI___libc_free+29>:mov-0x8(%rdi),%rax
#0  __GI___libc_free (mem=0x101040104070701) at malloc.c:3093
#1  0x777c09f0 in OPENSSL_sk_pop_free () from 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#2  0x778ecc29 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#3  0x7775af1a in OPENSSL_cleanup () from 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#4  0x779aa2b7 in __cxa_finalize (d=0x778b2000) at cxa_finalize.c:83
#5  0x7765c093 in ?? () from 

Bug#929808: RM: blogofile -- ROM; dead upstream

[Jakob Haufe]

Package: ftp.debian.org
Severity: normal

Please remove blogofile - it has not seen any upstream commits for 4 years
and the project website is gone. It might furthermore be affected by
#929321.

Cheers,
sur5r

Bug#929674: --pristine-tar option to gbp import-dsc does not add multiple tarballs to pristine-tar branch

[Guido Günther]

Hi,
On Tue, May 28, 2019 at 06:56:51PM +0500, Pirate Praveen wrote:
> 
> 
> On Tue, May 28, 2019 at 5:54 PM, Guido =?iso-8859-1?q?G=FCnther?=
>  wrote:
> > control: -1 tags +moreinfo
> > control: -1 severity normal
> > 
> > 
> > Hi,
> > On Tue, May 28, 2019 at 04:26:03PM +0500, Pirate Praveen wrote:
> > >  package: git-buildpackage
> > >  version: 0.9.14
> > >  severity: important
> > > 
> > >  When using multiple tarballs and components in debian/gbp.conf, gbp
> > >  import-dsc imports the tarballs to master branch but does not add
> > > them to
> > >  pristine-tar branch
> > 
> > I don't think this is an issue with additional tarballs per se since
> > we're testing this
> > 
> > https://github.com/agx/git-buildpackage/blob/master/tests/component/deb/test_import_dsc.py#L178
> > 
> > and the code is basicall the same as in import_orig. Something else must
> > be different in your setup. When reporting such things please make sure
> > it's 1:1 reproducible by publishing the needed tarballs, repo and
> > command issued. Also please follow
> 
> Sorry, I thought I added the repo, but missed it.
> 
> The repo is here https://salsa.debian.org/js-team/node-gulp

At what revision is that repo when you import the dsc?

> uscan -dd will download all the tarballs.

But I'd need a dsc not orig tarballs (I read the bug report to affect
import-dsc)

> > /usr/share/bug/git-buildpackage/presubj and use `--verbose` when pasting
> > command output since the output without `--verbose` is not sufficient
> > for debugging such things.
> > Cheers,
> 
> Here is the verbose log,
> 
> $ gbp import-dsc --pristine-tar --verbose ../node-gulp_4.0.2-1.dsc

...where does this dsc come from? The archive only has 3.9.1-7. Can you
dump it somehwhere?

Cheers,
 -- Guido

> gbp:debug: ['git', 'rev-parse', '--show-cdup']
> gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> gbp:debug: ['git', 'rev-parse', '--git-dir']
> gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)',
> 'refs/heads/']
> gbp:debug: ['git', 'status', '--porcelain']
> gbp:debug: Upstream version: 4.0.2
> gbp:debug: Debian version: 1
> gbp:debug: Upstream tarball:
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig.tar.gz
> gbp:debug: Additional tarballs:
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-ansi-colors.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-ansi-wrap.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-arr-filter.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-arr-map.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-each.tar.gz, 
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-initial.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-last.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-slice.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-array-sort.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-async-done.tar.gz, 
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-async-settle.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-bach.tar.gz, 
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-collection-map.tar.gz,
>  
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-color-support.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-copy-props.tar.gz, 
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-default-compare.tar.gz,
>  
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-default-resolution.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-each-props.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-gulp-cli.tar.gz, 
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-homedir-polyfill.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-is-absolute.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-is-relative.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-last-run.tar.gz, 
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-make-iterator.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-matchdep.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-mute-stdout.tar.gz, 
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-now-and-later.tar.gz,
>  
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-object-defaults.tar.gz,
>  
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-object-reduce.tar.gz,
>  
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-replace-homedir.tar.gz,
>  
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-semver-greatest-satisfied-range.tar.gz,
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-stack-trace.tar.gz, 
> /home/pravi/forge/debian/git/js-team/node-gulp_4.0.2.orig-stream-exhaust.tar.gz,
> 

Bug#928746: unblock: zfs-linux/0.7.13-1

[Christian Marillat]

On 30 mai 2019 21:51, Paul Gevers  wrote:

> Control: tags -1 moreinfo
>
> Hi Mo,
>
> On Thu, 09 May 2019 22:09:18 -0700 Mo Zhou  wrote:
>> zfs-linux (= 0.7.13-1) is 66 days in unstable and there is no new bug
>> for it.
>> Compared to (0.7.12-2), the (0.7.13-1) version in unstable only
>> introduces
>> bug fixes. Aron has already applied for an unblock but it was rejected.
>> Here I'm requesting for unblock again.
>
> I checked bug #923770 again (it was filed by you by the way). As I said
> in that bug, I didn't spot anything that was at the level of important
> or more severe in Debian BTS terms. I may have been wrong, but then
> please point me to the changes so important that you want them in
> buster. Please also be prepared to undo the new upstream release and
> just fix the bugs that are so important to you.

I see a problem with longterm kernel is Buster (4.19).
4.19.38 doesn't build with zfs 0.7.12

OK, 4.19.37 will be the Buster kernel, but has we upgrade recent kernel
from longterm branch for stable release the next stable release will
probably break zfs.

So zfs 0.7.13 is probably a good choice for Buster.

This is because kernel 5.0 "drops export of __kernel_fpu_begin/end" has
been back-ported to 4.19.38 (and also 4.14.120) kernel and fixed in zfs 0.7.13

https://github.com/NixOS/nixpkgs/issues/60907
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.38
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.120

Christian

Bug#897936: libvirt-daemon-system should not depend on policykit-1

[sergio]

Any update?

For example libvirt in gentoo doesn't depend on  policykit or systemd.

-- 
sergio.

Bug#929807: libguestfs: supermin/liguestfs fails to configure network

[Ioanna Alifieraki]

Package: libguestfs
Version: 1:1.40.2-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

When /etc/dhcp/dhclient-enter-hooks.d/resolved hook is present in the
supermin appliance the network fails to be configured because this hook
tries to restart a systemd serive and systemd is not used inside the
appliance.

For more information :
https://launchpad.net/bugs/1824236

In Ubuntu, the attached patch was applied to achieve the following:

remove the hook so the network can be configured successfully.

  * d/p/appliance-Remove-etc-dhcp-dhclient-enter-hooks.d-res.patch : remove
/etc/dhcp/dhclient-enter-hooks.d/resolved (LP: #1824236)


Thanks for considering the patch.


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

Kernel: Linux 5.0.0-13-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
libguestfs-1.40.2/debian/patches/appliance-Remove-etc-dhcp-dhclient-enter-hooks.d-res.patch
 
libguestfs-1.40.2/debian/patches/appliance-Remove-etc-dhcp-dhclient-enter-hooks.d-res.patch
--- 
libguestfs-1.40.2/debian/patches/appliance-Remove-etc-dhcp-dhclient-enter-hooks.d-res.patch
 1970-01-01 01:00:00.0 +0100
+++ 
libguestfs-1.40.2/debian/patches/appliance-Remove-etc-dhcp-dhclient-enter-hooks.d-res.patch
 2019-05-30 12:29:10.0 +0100
@@ -0,0 +1,32 @@
+From: "Richard W.M. Jones" 
+Origin: Upstream, 
https://github.com/libguestfs/libguestfs/commit/2bb6be333e6347d3f18856627d8ad8e50b8e5427
+Bug-Ubuntu: https://launchpad.net/bugs/1824236
+Date: Thu, 18 Apr 2019 10:53:39 +0100
+Subject: [PATCH] appliance: Remove /etc/dhcp/dhclient-enter-hooks.d/resolved.
+
+Workaround for Ubuntu which uses this script to try to start a systemd
+service.  That won't work because systemd is not used inside the
+appliance.  See:
+
+https://bugs.launchpad.net/ubuntu/+source/supermin/+bug/1824236
+
+Thanks: Ioanna Alifieraki
+---
+ appliance/init | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+Index: libguestfs-1.40.2/appliance/init
+===
+--- libguestfs-1.40.2.orig/appliance/init
 libguestfs-1.40.2/appliance/init
+@@ -122,7 +122,9 @@ ip link set dev lo up
+ 
+ if test "$guestfs_network" = 1; then
+ iface=$(ls -I all -I default -I lo /proc/sys/net/ipv4/conf)
+-touch /etc/fstab   # Workaround for Ubuntu.
++# Two workarounds for Ubuntu:
++touch /etc/fstab
++rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved
+ if dhclient --version >/dev/null 2>&1; then
+ dhclient $iface
+ else
diff -Nru libguestfs-1.40.2/debian/patches/series 
libguestfs-1.40.2/debian/patches/series
--- libguestfs-1.40.2/debian/patches/series 2019-04-22 04:45:56.0 
+0100
+++ libguestfs-1.40.2/debian/patches/series 2019-05-30 12:12:51.0 
+0100
@@ -13,3 +13,4 @@
 0013-Fix-up-perl-path-in-installed-scripts.patch
 0014-Fix-.depend-generation-for-out-of-tree-build.patch
 0015-Change-cryptsetop-cryptsetup-bin-in-appliance.patch
+0016-appliance-Remove-etc-dhcp-dhclient-enter-hooks.d-res.patch

Bug#929806: ITP: ruby-devise-i18n--Translations for the devise gem

[Samyak Jain]

Package: wnpp
Severity: wishlist
Owner: Samyak Jain 

* Package name: ruby-devise-i18n
  Version : 1.8.0
  Upstream Author : Christopher Dell 
mcasimir 
* URL : https://github.com/tigrish/devise-i18n
* License : Expat
  Programming Lang: Ruby
  Description : Translations for the devise gem

 Devise is a flexible authentication solution for Rails based on Warden.
 Internationalization (aka i18n) is a "means of adapting computer software to
 different languages, regional differences and technical requirements of a
 target market".
 Devise supports i18n in controllers, models, and in other areas, but it does
 not have support for internationalized views. devise-i18n adds this support.
 Devise also does not include the actual translations. devise-i18n does this
 too.


It is a dependency for loomio and hence needs to be packaged.

Thanks,
Samyak Jain

Bug#928381: unblock: stunnel4/3:5.54~b3-1

[Sam Hartman]

> "Peter" == Peter Pentchev  writes:

Peter> On Thu, May 30, 2019 at 09:00:18PM +0200, Paul Gevers wrote:
>> Hi Peter,
>> 
>> On 30-05-2019 11:24, Peter Pentchev wrote:
>> > Just for my information, is there a chance that this upgrade
>> could be > allowed later on during the buster lifecycle as a
>> stable update?
>> 
>> If it would be suitable for a stable release point update, it
>> would be suitable now. We're close to releasing, but not that
>> close yet.

Peter> So what you're saying is that stunnel4 will have a bug that
Peter> leads to random crashes all through the buster lifetime?
Peter> That's...  a bit unfortunate, I guess...

Well, if you can produce a small targeted fix, and argue that the bug is
at least important priority,
then you can ask for that small fix to be reviewed now or later.

Bug#174424: COFFEE REQUEST FOR A MEETING

[Arthur Jones]

From: Arthur Jones 
Sent: Friday, May 31, 2019 8:43 AM
To: Arthur Jones
Subject: Re: COFFEE REQUEST FOR A MEETING

Hello,


How are you doing today? Could you please send us quote of 400 cups of Black 
Coffee ? We want you to supply our upcoming conference and barista will be 
picking up from you to the event.
Hope to read from you soon.
Thanks
Arthur

Bug#929805: gbp import-dsc is not filtering components (multiple tarballs)

[Pirate Praveen]

package: git-buildpackage
version: 0.9.14
severity: important

Repo to reproduce https://salsa.debian.org/js-team/node-vinyl-fs

I want to remove dist/browser.js from object-assign component.

I have this in gbp.conf

[import-dsc]
filter-pristine-tar = True
filter = ['object-assign/dist/browser.js']

(tried with [import-orig] as well)

But the file does not get filtered.

Bug#910124: network-manager-gnome: option to import/export WiFi config as a QR code

[Salvatore Bonaccorso]

Hi Michael,

Thanks for the heads-up.

On Fri, May 31, 2019 at 12:26:58PM +0200, Michael Biebl wrote:
> Am 30.05.19 um 04:36 schrieb Paul Wise:
> > On Wed, 2019-05-29 at 12:57 +0200, Michael Biebl wrote:
> > 
> >>> This has been implemented in 1.8.22.
> >> This is apparently implemented as well.
> > 
> > Thanks for the notice.
> > 
> >> https://gitlab.gnome.org/GNOME/network-manager-applet/merge_requests/45
> > 
> > This appears to introduce an embedded code copy, you might want to let
> > the security team know about that once it reaches Debian.
> 
> Sure.
> 
> Dear security team,
> network-manager-applet 1.8.22 has been uploaded to experimental. It uses
> an internal copy of
> https://www.nayuki.io/page/qr-code-generator-library
> which afaics is not (yet) packaged for Debian.
> See
> https://salsa.debian.org/utopia-team/network-manager-applet/blob/experimental/src/libnma/qrcodegen.c

Is that the same as src:qr-code-generator as present in unstable, cf.
https://tracker.debian.org/pkg/qr-code-generator . 

Is the network-manager-applet embedded copy unmodified? If so it would
be preferable if network-manager-applet could switch to the system
one.

Regards,
Salvatore

Bug#929804: gnome-maps: crash when exporting map as the image

[Saša Janiška]

Package: gnome-maps
Version: 3.30.3-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I created a route and wanted to save it by exporting to the image, but
application regularly crash.

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

right-click --> Export as Image

   * What was the outcome of this action?

Application does crash.
   * What outcome did you expect instead?

Here is the small snippet from the console:

[20782.988916] org.gnome.Maps[6226]: segfault at 7f5f06efd010 ip
7f5f26bac5d0 sp 7fffd8380258 error 4 in
libpixman-1.so.0.36.0[7f5f26b2a000+83000]
[20782.988923] Code: 00 00 00 f6 c1 0f 75 e2 83 fb 3f 7e b9 83 eb 40 48 89 ca
41 89 dd 41 c1 ed 06 45 89 ec 49 83 c4 01 49 c1 e4 06 4a 8d 2c 20 90  0f 6f
50 10 f3 0f 6f 18 48 83 c0 40 48 83 c2 40 f3 0f 6f 48 e0


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

-- 
As a blazing fire turns firewood to ashes, O Arjuna, so does the
fire of knowledge burn to ashes all reactions to material activities.

Bug#929725: ddd: Window does not close when killed with ctrl-z

[Bernhard Übelacker]

Control: tags -1 - moreinfo


Hello Shawn Landden,

> Good point. I started ddd from a terminal. Ctrl-c is ignored.

I just saw that Ctrl-c is not terminating ddd, but
in the debugger console following is shown:

(gdb) Quit
(gdb) Quit

So it looks like it just get forwarded to the gdb process.
This happens for at least ppc64el and amd64 architectures.

This might then be desired behaviour.

Kind regards,
Bernhard

Bug#929473: sssd-kcm: talloc_abort call via schedule_fd_processing

[Bernhard Übelacker]

Dear Maintainer,
I just tried to reproduce this crash and may have
found some more information.

It looks like this memory got freed already at
this location [1].

Then on the second free attempt the talloc
recognises this and aborts [2].

Could not find a related upstream bug report in [3].

It does not always crash so it looks timing related.

Attached file shows some details on my attempt to
reproduce this issue.

Kind regards,
Bernhard


[1]
(rr) bt
#0  _talloc_free (ptr=0x5622b5453df0, location=0x7f8594c8e15d 
"../tevent_timed.c:391") at ../talloc.c:1743
#1  0x7f8594c8ace1 in tevent_common_invoke_timer_handler 
(te=te@entry=0x5622b5453df0, current_time=..., removed=removed@entry=0x0) at 
../tevent_timed.c:391
#2  0x7f8594c8adea in tevent_common_loop_timer_delay 
(ev=ev@entry=0x5622b5431920) at ../tevent_timed.c:441
#3  0x7f8594c8be67 in epoll_event_loop_once (ev=0x5622b5431920, 
location=) at ../tevent_epoll.c:922
#4  0x7f8594c8a2d7 in std_event_loop_once (ev=0x5622b5431920, 
location=0x7f85948c9178 "../src/util/server.c:725") at ../tevent_standard.c:110
#5  0x7f8594c857e4 in _tevent_loop_once (ev=ev@entry=0x5622b5431920, 
location=location@entry=0x7f85948c9178 "../src/util/server.c:725") at 
../tevent.c:772
#6  0x7f8594c85a2b in tevent_common_loop_wait (ev=0x5622b5431920, 
location=0x7f85948c9178 "../src/util/server.c:725") at ../tevent.c:895
#7  0x7f8594c8a277 in std_event_loop_wait (ev=0x5622b5431920, 
location=0x7f85948c9178 "../src/util/server.c:725") at ../tevent_standard.c:141
#8  0x7f85948a48e3 in server_loop (main_ctx=0x5622b5432df0) at 
../src/util/server.c:725
#9  0x5622b38e4c70 in main (argc=, argv=) at 
../src/responder/kcm/kcm.c:318
(rr) when
Current event: 12824


[2]
(rr) bt
#0  _talloc_free (ptr=0x5622b5453df0, location=0x5622b391d27a 
"../src/util/tev_curl.c:449") at ../talloc.c:1743
#1  0x5622b38f98fb in schedule_fd_processing (multi=, 
timeout_ms=0, userp=) at ../src/util/tev_curl.c:449
#2  0x7f8594cd88cc in update_timer (multi=multi@entry=0x5622b5440a50) at 
multi.c:2941
#3  0x7f8594cd9f76 in curl_multi_add_handle (data=0x5622b6871250, 
multi=0x5622b5440a50) at multi.c:500
#4  curl_multi_add_handle (multi=0x5622b5440a50, data=0x5622b6871250) at 
multi.c:376
#5  0x5622b38f9fa9 in tcurl_request_send 
(mem_ctx=mem_ctx@entry=0x5622b544e740, ev=ev@entry=0x5622b5431920, 
tcurl_ctx=tcurl_ctx@entry=0x5622b543c0f0, 
tcurl_req=tcurl_req@entry=0x5622b686b890, timeout=timeout@entry=5) at 
../src/util/tev_curl.c:700
#6  0x5622b38faa98 in tcurl_http_send (mem_ctx=0x5622b544e740, 
ev=ev@entry=0x5622b5431920, tcurl_ctx=0x5622b543c0f0, 
method=method@entry=TCURL_HTTP_GET, 
socket_path=socket_path@entry=0x5622b39154a3 "/var/run/secrets.socket", 
url=, headers=0x5622b39379b0 , body=0x0, timeout=5) 
at ../src/util/tev_curl.c:1017
#7  0x5622b38ef659 in sec_list_send (mem_ctx=, 
ev=ev@entry=0x5622b5431920, client=client@entry=0x5622b686a4e0, 
secdb=) at ../src/responder/kcm/kcmsrv_ccache_secrets.c:163
#8  0x5622b38efc4e in sec_get_ccache_send (mem_ctx=, 
ev=ev@entry=0x5622b5431920, secdb=secdb@entry=0x5622b54409d0, 
client=client@entry=0x5622b686a4e0, name=name@entry=0x5622b543cea0 "0", 
uuid=uuid@entry=0x7ffdbedbd470 "") at 
../src/responder/kcm/kcmsrv_ccache_secrets.c:482
#9  0x5622b38f016d in ccdb_sec_getbyname_send (mem_ctx=, 
ev=0x5622b5431920, db=, client=0x5622b686a4e0, 
name=0x5622b543cea0 "0") at ../src/responder/kcm/kcmsrv_ccache_secrets.c:1275
#10 0x5622b38e7e39 in kcm_ccdb_getbyname_send (mem_ctx=, 
ev=ev@entry=0x5622b5431920, db=0x5622b543d630, client=0x5622b686a4e0, 
name=0x5622b543cea0 "0") at ../src/responder/kcm/kcmsrv_ccache.c:692
#11 0x5622b38f18d7 in kcm_op_get_kdc_offset_send (mem_ctx=, 
ev=0x5622b5431920, op_ctx=0x5622b544de60) at 
../src/responder/kcm/kcmsrv_ops.c:1731
#12 0x5622b38f09f3 in kcm_cmd_queue_done (subreq=0x0) at 
../src/responder/kcm/kcmsrv_ops.c:196
#13 0x7f8594c86479 in tevent_common_invoke_immediate_handler 
(im=0x5622b5430520, removed=removed@entry=0x0) at ../tevent_immediate.c:165
#14 0x7f8594c864a3 in tevent_common_loop_immediate 
(ev=ev@entry=0x5622b5431920) at ../tevent_immediate.c:202
#15 0x7f8594c8be5b in epoll_event_loop_once (ev=0x5622b5431920, 
location=) at ../tevent_epoll.c:917
#16 0x7f8594c8a2d7 in std_event_loop_once (ev=0x5622b5431920, 
location=0x7f85948c9178 "../src/util/server.c:725") at ../tevent_standard.c:110
#17 0x7f8594c857e4 in _tevent_loop_once (ev=ev@entry=0x5622b5431920, 
location=location@entry=0x7f85948c9178 "../src/util/server.c:725") at 
../tevent.c:772
#18 0x7f8594c85a2b in tevent_common_loop_wait (ev=0x5622b5431920, 
location=0x7f85948c9178 "../src/util/server.c:725") at ../tevent.c:895
#19 0x7f8594c8a277 in std_event_loop_wait (ev=0x5622b5431920, 
location=0x7f85948c9178 "../src/util/server.c:725") at ../tevent_standard.c:141
#20 0x7f85948a48e3 in server_loop (main_ctx=0x5622b5432df0) at 
../src/util/server.c:725
#21 

Bug#929798: exim4-base: /etc/cron.daily/exim4-base will not rotate paniclog if it is 100% noise.

[Andreas Metzler]

On 2019-05-31 Kev Green  wrote:
> Package: exim4-base
> Version: 4.84.2-2+deb*
> Severity: normal
[...]
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?

> Doing $E4BCD_PANICLOG_NOISE to begin with was one mitigation, but it
> does not respect the 'once' mode of $E4BCD_WATCH_PANICLOG so warning
> emails keep coming until manual intervention is done.


I do not get this part of the bug-report. Afaict from looking at the
script the following happens (in pseudocode):

1. Check for nonempty paniclog.
2. If E4BCD_PANICLOG_NOISE is not set or if paniclog contains lines NOT
ignored by E4BCD_PANICLOG_NOISE then
  a) send out a warning mail
  b) rotate log if "$E4BCD_WATCH_PANICLOG"="once"

So if paniclog is non-empty, but only contains ignored lines then the
log is not-rotated but warning mails are not sent out. So "warning
emails keep coming" will not happen.

cu Andreas

Bug#929803: Package:kamailio-java-modules request for buster (Package:kamailio-java-modules with openjdk deps)

[Renato Gallo]

Package:kamailio-java-modules

Hello,
I need a kamailio_java package for kamailio 5 's buster without the gcj 
dependancy.
I would love it to depend on

java --version
openjdk 11.0.3 2019-04-16
OpenJDK Runtime Environment (build 11.0.3+1-Debian-1)
OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1, mixed mode, sharing)


I use buster

Renato Gallo--- Begin Message ---
Hello, 
I need a kamailio_java package for kamailio 5 's buster without the gcj 
dependancy. 
I would love it to depend on 

java --version 
openjdk 11.0.3 2019-04-16 
OpenJDK Runtime Environment (build 11.0.3+1-Debian-1) 
OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1, mixed mode, sharing) 


I use buster 

Renato Gallo 


--- End Message ---

Bug#929802: checkrestart: wrongly report processes using deleted files from sssd cache

[Baptiste BEAUPLAT]

Package: debian-goodies
Tags: patch

Dear maintainers,

The tool checkrestart wrongly report processes using deleted files from
/var/lib/sss/mc/ as in need of a restart.

Files present in that directories are caches from sssd and are expected
to change (removed and re-created) from now and then. glibc
automatically reopen the cache files on the next request (which can take
a while, creating the problem with checkrestart).

I propose to add this directory to the list of ignored path in checkrestart.

Please find attached a patch.

Best regards,

-- 
Baptiste BEAUPLAT - lyknode
--- checkrestart  2018-07-20 17:27:39.0 +
+++ checkrestart2019-05-31 12:07:56.136939223 +
@@ -566,6 +566,9 @@
 # Skip memfd files
 if f.startswith('/memfd:'):
 return 0
+# Skip sssd cache
+if f.startswith('/var/lib/sss/mc/'):
+return 0
 # Skip, if asked to, files that do not belong to any package
 if onlyPackageFiles:
 # Remove some lsof information from the file to ensure that it is


signature.asc
Description: OpenPGP digital signature

Bug#927470: zsh: Segfault on completion menu in large git repo's

[wesleys]

Hello maintainers,

Hope you are doing well.

This bug seems to be resolved upstream by 
4b85edface379a3575273a2b712d80bd9420d4c9

Cheers,
Wesley

Bug#862887: 14 tests fail gulp

[Pirate Praveen]

On Wed, 13 Feb 2019 20:52:54 +0100 Xavier  wrote:
> This outdated version of gulp depends on (at least) outdated
> node-vinyl-fs and node-first-chunk-stream and unpackaged
> node-glob-watcher. That's why tests fail, this reveals that
> "auto-rebuild" feature is unusable. I hope nothing else is broken.
> 
> To avoid uploading a major change during Buster freeze, I packaged gulp
> with tests related to Gulp.watch() disabled and with a patch to throw an
> error that points here if vinyl-fs.watch() is called.

I'm updating gulp to 4.x and planning to upload it to experimental soon.

I have updated node-vinyl-fs in experimental and glob-watcher is
embedded. The tests are still failing.

Bug#929725: ddd: Window does not close when killed with ctrl-z

[Shawn Landden]

El vie., 31 may. 2019 4:33, Bernhard Übelacker 
escribió:

> Control: tags -1 + moreinfo
>
>
> Hello Shawn Landden,
> where exactly do you enter this ctrl-z?
>
Good point. I started ddd from a terminal. Ctrl-c is ignored.

>
>
> In the graphical user interface of ddd ctrl-z is the shortcut for the
> Edit - Undo action. So that is not supposed to end ddd, I guess.
>
>
> Or do you enter it in a terminal from which you started ddd?
> From man bash:
> ... Typing the suspend character (typically ^Z, Control-Z) while
> a process is running causes that process to be stopped and returns
> control to bash. ...
> So that whould just send ddd to the background and stop its execution.
> If you wanted to kill it in a terminal, where ddd was started from,
> you could use ctrl-c?
>
> Kind regards,
> Bernhard
>

Bug#929588: usat: source tarballs are missing the source of the configure script

[Carsten Schoenert]

Hi,

thanks for your quick answer!

Am 31.05.19 um 12:26 schrieb badd...@gmail.com:
> I am sending this from my other account, as your email service is blocking
> my main email telling me I have been blacklisted.
> 
> Those packages are astronomically out of date. I had problems with
> Sourceforge when they changed hands, and still have password issues.
> Use the official site:>
> http://dimlight.org/lsat/
> 
> 0.9.8.5 is the latest version.
> 
> Thanks.

O.k. that's an important information for the package maintainers.

I've looked quickly into the zipped file for the version you have
mentioned, the issue is still here also existing. I can't find a
configure.in script nor some similar autogen.sh file.

The configure script has some content that it was created from a
configure.in file.

> #! /bin/sh
> 
> # Guess values for system-dependent variables and create Makefiles.
> # Generated automatically using autoconf version 2.13 
> # Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.
> #
> # This configure script is free software; the Free Software Foundation
> # gives unlimited permission to copy, distribute and modify it.
> 
> # Defaults:
> ac_help=
> ac_default_prefix=/usr/local
> # Any additions from configure.in:

Please add the configure.in file to the next release or even better
update the existing archives.

> On 2019-05-30 10:58, Carsten Schoenert wrote:
> 
> Hi,
> 
> previous and the most recent release of the usat tarballs is missing the
> source for the configure script.
> 
> http://usat.sourceforge.net/code/lsat-0.9.8.2.zip
> 
> For Debian this makes the package [1 ]
> non-free due the regulation of the
> Debian Free Software Guidelines [2
> ].
> It also makes it impossible to build the package on platforms that are
> not supported by the provided configure script.
> 
> Could you please include the source for the generated configure script?
> 
> [1] https://tracker.debian.org/pkg/lsat
> [2] https://www.debian.org/social_contract.en.html#guidelines
> 

-- 
Regards
Carsten Schoenert

Bug#921618: Could this be released and included in Buster?

[Dagfinn Ilmari Mannsåker]

Dear maintainer,

This looks like it will unnecessarily pulling in python2 on many Buster
systems.  Since this is such a trivial change, and the only commit since
1:2.0.0-3, could you please make a release and ask the release team to
unblock it for Buster?

Thanks,

- ilmari
-- 
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen

Bug#929801: debian-policy: Broken link in section 3.6 Virtual packages

[Alexandros Prekates]

Package: debian-policy
Version: 4.3.0.3
Severity: normal

Dear Maintainer,

In the webpage of the debian policy manual in
section 3.6 Virtual Packages the link
https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml.
is broken.



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

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

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

Bug#929786: origtargz does not download multiple tarballs

[Pirate Praveen]

On Fri, May 31, 2019 at 3:12 PM, Mattia Rizzolo  
wrote:

user devscri...@packages.debian.org
usertags 929786 origtargz
tags 929786 moreinfo
quit

On Thu, May 30, 2019 at 08:26:27PM +0500, Pirate Praveen wrote:

 pravi@nishumbha:~/forge/debian/git/js-team/node-vinyl-fs$ origtargz
 pristine-tar: successfully generated 
../node-vinyl-fs_3.0.3.orig.tar.gz


 But it failed to download multiple tarballs from archive. You can 
use
 https://salsa.debian.org/js-team/node-vinyl-fs to reproduce this 
issue.


Honestly, I don't think there is any sane way for `origtargz` to 
fiugre
that it needs to download/produce/build more than one orig tarball, 
from

inside the unpacked source.

That's an information that is available *only* from the .dsc, which is
not something `origtargz` has access to.  Anything else would truly be
guesswork.


Suggestions?

If #577113 gets implemented, that will give a uniform way to get list 
of components. But even now this information is available in 
debian/gbp.conf for packages that use git-buildpackage. I think 
origtargz should look in gbp.conf for components if the file is present.


When pristine-tar branch is missing it does apt source, I think the 
same could be tried here also.

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

Hi Chris,

On Sun, May 19, 2019 at 12:21 PM Chris Wilson 
wrote:

> Hi Reinhard and all,
>
> Good news, I have just finished fixing this problem, and merged it into
> master with https://github.com/boxbackup/boxbackup/pull/36. Please could
> you cut a new Debian package release and see if the tests pass for you? Or
> if not, point me to the failure logs?
>
> If anyone wants to know more, the issue is quite complex, and there are no
> easy answers, which is why it took so long to fix. I've done my best to
> describe it at
> https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates. Please
> feel free to correct any mistakes that I've made.
>

Thanks a lot for your assistance!

I've now (finally) uploaded the package to debian/experimental, the build
logs will be available at
https://buildd.debian.org/status/package.php?p=boxbackup=experimental
 soon.

Unfortunately, the changes are quite invasive and do not qualify for
inclusion into "Debian testing" this late in the Debian release cycle (cf.
https://salsa.debian.org/debian/boxbackup/commit/6017757bc079f4446aa77bc5c0855c52741280f4?w=1
- all of which would need to be reviewed and approved by the Release Team).
That's very unfortunate, because it very likely means that boxbackup will
not be part of Debian 10 (buster).

I am also sympathetic -- the nature of the issue seems to require such
invasive changes and coming up with a simple, focused and reviewable fix is
super hard.

The best that we can do at this point is to get it included into
"buster-backports" as soon as that suite opens, probably shortly after
buster is released, which should be within (hopefully) a small number of
weeks.


Best,
-rt

-- 
regards,
Reinhard

Bug#929800: ITP: ruby-jaro-winkler -- Jaro-Winkler distance algorithm implementation

[Jongmin Kim]

Package: wnpp
Severity: wishlist
Owner: Jongmin Kim 

* Package name: ruby-jaro-winkler
  Version : 1.5.2
  Upstream Author : Jian Weihang 
* URL : https://github.com/tonytonyjan/jaro_winkler
* License : Expat
  Programming Lang: Ruby, C
  Description : Jaro-Winkler distance algorithm implementation

 This package provides an implementation of Jaro-Winkler distance
 algorithm which is written in C extension and will fallback to pure
 Ruby.

This package is a dependency of latest rubycop.

Bug#929776: unblock: rrdtool/1.7.1-2

[Jean-Michel Vourgère]

Control: tags -1 -moreinfo

Version 1.7.1-2 is now installed on all major architectures.

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

Bug#929799: --download-current-version and --download-version does not work with uscan when using multiple tarballs

[Pirate Praveen]

Package: devscripts
version: 2.19.5
severity: important

Repo to reproduce is https://salsa.debian.org/js-team/node-chokidar

$ cat debian/watch
version=4
opts=\
dversionmangle=s/\+(debian|dfsg|ds|deb)(\.\d+)?$//,\
filenamemangle=s/.*\/v?([\d\.-]+)\.tar\.gz/chokidar-$1.tar.gz/ \
https://github.com/paulmillr/chokidar/tags 
.*/archive/v?([\d\.]+).tar.gz debian


opts="searchmode=plain,pgpmode=none,component=upath" \
https://registry.npmjs.org/upath \
https://registry.npmjs.org/upath/-/upath-(1.[\d\.]*)@ARCHIVE_EXT@ ignore


$ uscan --force-download --download-version 2.1.6
uscan: Newest version of node-chokidar on remote site is 2.1.6, 
specified download version is 2.1.6

Leaving ../node-chokidar_2.1.6.orig.tar.gz where it is.
uscan warn: In debian/watch no matching hrefs for version 2.1.6 in 
watch line
 https://registry.npmjs.org/upath 
https://registry.npmjs.org/upath/-/upath-(1.[\d\.]*)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz|tbz|txz)) 
ignore



$ uscan --force-download --download-current-version
uscan: Newest version of node-chokidar on remote site is 2.1.6, 
specified download version is 2.1.6

Leaving ../node-chokidar_2.1.6.orig.tar.gz where it is.
uscan warn: In debian/watch no matching hrefs for version in watch line
 https://registry.npmjs.org/upath 
https://registry.npmjs.org/upath/-/upath-(1.[\d\.]*)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz|tbz|txz)) 
ignore

Bug#929794: further investigation

[Michael Jarosch]

Okay, tried to copy a few songs less and it works. My problem seems to
be that too many audio files are processed, simultaneously. But there's
another problem: Why are the files processed at all?
My Phone can handle several codecs (as shown in the "Advanced" tab in
"Properties"): MPEG layer 3 Audio, Ogg Vorbis, MPEG 4 audio and FLAC.
Most of my collection is mp3, I have several vorbis and flac tracks and
very few ogg opus tracks - that's it. Unfortunately, it looks like
rhythmbox is processing more tracks than it needs to.
But even that wouldn't be a problem, if rhythmbox would set a limit of
tracks beeing processed…

Greets!
Mitsch


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

Bug#929798: exim4-base: /etc/cron.daily/exim4-base will not rotate paniclog if it is 100% noise.

[Kev Green]

Package: exim4-base
Version: 4.84.2-2+deb*
Severity: normal

Dear Maintainer,

Reporting this bug on a personal system because I observed it at work, but my
current employer requires some confidentiality. Bug seems to apply in multiple
package versions.

There appears to be a logical error in /etc/cron.daily/exim4-base such that it
will not rotate /var/log/exim4/paniclog if it is full of *only* lines that
are ignored by virtue of $E4BCD_PANICLOG_NOISE. I think the block that
performs log rotation should be contingent only on the log having something in
it, not on there being any non-noise lines in it, that would be alerted about,
to make this bug go away.

So I think those 3 lines ought to be moved down below the 'fi' immediately
beneath them.

*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

Stupid emails causing paniclog to be full of stuff ignored by setting 
$E4BCD_PANICLOG_NOISE. Which results in the 'grep -vq' call returning a
failure exit code.

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

Doing $E4BCD_PANICLOG_NOISE to begin with was one mitigation, but it does not
respect the 'once' mode of $E4BCD_WATCH_PANICLOG so warning emails keep coming
until manual intervention is done.

   * What was the outcome of this action?

Not quite enough.

   * What outcome did you expect instead?

Paniclog to rotate and thus to only receive one email about the same errors.

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

-- Package-specific info:
Exim version 4.80 #3 built 10-Feb-2018 15:37:27
Copyright (c) University of Cambridge, 1995 - 2012
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2012
Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages exim4-base depends on:
ii  adduser3.113+nmu3
ii  cron   3.0pl1-124
ii  debconf [debconf-2.0]  1.5.49
ii  exim4-config [exim4-config-2]  4.80-7+deb7u6
ii  libc6  2.13-38+deb7u12
ii  libdb5.1   5.1.29-5+deb7u1
ii  lsb-base   4.1+Debian8+deb7u1
ii  netbase5.0

Versions of packages exim4-base recommends:
ii  bsd-mailx [mailx]  8.1.2-0.2006cvs-1+deb7u1
ii  perl-modules   5.14.2-21+deb7u5
ii  psmisc 22.19-1+deb7u1

Versions of packages exim4-base suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.2006cvs-1+deb7u1
pn  exim4-doc-html | exim4-doc-info  
pn  eximon4  
ii  file 5.11-2+deb7u9
ii  mutt [mail-reader]   1.5.21-6.2+deb7u3
ii  openssl  1.0.1t-1+deb7u4
pn  spf-tools-perl   
pn  swaks

-- debconf information:
  exim4/purge_spool: false
  exim4-base/drec:

Bug#929774: iproute2: please compile with NETNS_RUN_DIR=/run/netns

[Luca Boccassi]

On Thu, 2019-05-30 at 13:07 -0700, Andrew Ayer wrote:
> Package: iproute2
> Version: 4.20.0-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Currently, iproute2 is built with the default NETNS_RUN_DIR of
> /var/run/netns[1].  Consequentially, if /var is a separate
> filesystem,
> it is not possible to use ip netns to manage network namespaces early
> in boot before /var is mounted[2], because the symlink from /var/run
> to
> /run does not exist.
> 
> This can be fixed by adding the following line to debian/rules under
> the definition of KERNEL_INCLUDE[3]:
> 
> export NETNS_RUN_DIR=/run/netns
> 
> Thanks,
> 
> Andrew
> 
> [1] 
> https://sources.debian.org/src/iproute2/4.20.0-2/Makefile/#L19
> 
> 
> [2] for example, in a udev rule to move interfaces to a different
> namespace
> 
> [3] 
> https://sources.debian.org/src/iproute2/4.20.0-2/debian/rules/#L23

Thanks for the suggestion, pushed to git so it will be part of the next
upload to experimental and then bullseye after buster ships.

-- 
Kind regards,
Luca Boccassi


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

Bug#910124: network-manager-gnome: option to import/export WiFi config as a QR code

[Michael Biebl]

Am 30.05.19 um 04:36 schrieb Paul Wise:
> On Wed, 2019-05-29 at 12:57 +0200, Michael Biebl wrote:
> 
>>> This has been implemented in 1.8.22.
>> This is apparently implemented as well.
> 
> Thanks for the notice.
> 
>> https://gitlab.gnome.org/GNOME/network-manager-applet/merge_requests/45
> 
> This appears to introduce an embedded code copy, you might want to let
> the security team know about that once it reaches Debian.

Sure.

Dear security team,
network-manager-applet 1.8.22 has been uploaded to experimental. It uses
an internal copy of
https://www.nayuki.io/page/qr-code-generator-library
which afaics is not (yet) packaged for Debian.
See
https://salsa.debian.org/utopia-team/network-manager-applet/blob/experimental/src/libnma/qrcodegen.c

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



signature.asc
Description: OpenPGP digital signature

Bug#929797: Vagrant image debian/wheezy64 no longer works right away

[Manuel Molina Cuberos]

Package: cloud.debian.org


Since Debian Wheezy repositories had been archived, when I try to use
the Vagrant image "debian/wheezy64", I get this:

$ vagrant up

Bringing machine 'default' up with 'virtualbox' provider...

*==> default: Importing base box 'debian/wheezy64'...*

*==> default: Matching MAC address for NAT networking...*

*==> default: Checking if box 'debian/wheezy64' version '7.11.2' is up
to date...*

*==> default: Setting the name of the VM: debian7_default_1559296753043_62638*

*==> default: Fixed port collision for 22 => . Now on port 2200.*

*==> default: Clearing any previously set network interfaces...*

*==> default: Preparing network interfaces based on configuration...*

default: Adapter 1: nat

*==> default: Forwarding ports...*

default: 22 (guest) => 2200 (host) (adapter 1)

*==> default: Booting VM...*

*==> default: Waiting for machine to boot. This may take a few minutes...*

default: SSH address: 127.0.0.1:2200

default: SSH username: vagrant

default: SSH auth method: private key

default:

default: Vagrant insecure key detected. Vagrant will automatically replace

default: this with a newly generated keypair for better security.

default:

default: Inserting generated public key within guest...

default: Removing insecure key from the guest if it's present...

default: Key inserted! Disconnecting and reconnecting using new SSH key...

*==> default: Machine booted and ready!*

*==> default: Checking for guest additions in VM...*

default: No guest additions were detected on the base box for this VM! Guest

default: additions are required for forwarded ports, shared
folders, host only

default: networking, and more. If SSH fails on this machine, please install

default: the guest additions and repackage the box to continue.

default:

default: This is not an error message; everything may continue to
work properly,

default: in which case you may ignore this message.

*==> default: Installing rsync to the VM...*

The following SSH command responded with a non-zero exit status.

Vagrant assumes that this means the command failed!


apt-get -yqq update

apt-get -yqq install rsync



Stdout from the command:


WARNING: The following packages cannot be authenticated!

  rsync



Stderr from the command:


W: Failed to fetch
http://security.debian.org/dists/wheezy/updates/main/source/Sources
404  Not Found [IP: 151.101.132.204 80]


W: Failed to fetch
http://security.debian.org/dists/wheezy/updates/main/binary-amd64/Packages
 404  Not Found [IP: 151.101.132.204 80]


W: Failed to fetch
http://httpredir.debian.org/debian/dists/wheezy/main/source/Sources
404  Not Found [IP: 151.101.132.204 80]


W: Failed to fetch
http://httpredir.debian.org/debian/dists/wheezy/main/binary-amd64/Packages
 404  Not Found [IP: 151.101.132.204 80]


E: Some index files failed to download. They have been ignored, or old
ones used instead.

E: There are problems and -y was used without --force-yes

I think this could easily be addressed by replacing the current
/etc/apt/sources.list file from the image:

#

# deb cdrom:[Debian GNU/Linux 7.11.0 _Wheezy_ - Official amd64 NETINST
Binary-1 20160605-17:36]/ wheezy main

#deb cdrom:[Debian GNU/Linux 7.11.0 _Wheezy_ - Official amd64 NETINST
Binary-1 20160605-17:36]/ wheezy main

deb http://httpredir.debian.org/debian wheezy main

deb-src http://httpredir.debian.org/debian wheezy main


deb http://security.debian.org/ wheezy/updates main

deb-src http://security.debian.org/ wheezy/updates main


With this content:

#
# deb cdrom:[Debian GNU/Linux 7.11.0 _Wheezy_ - Official amd64 NETINST
Binary-1 20160605-17:36]/ wheezy main

#deb cdrom:[Debian GNU/Linux 7.11.0 _Wheezy_ - Official amd64 NETINST
Binary-1 20160605-17:36]/ wheezy main

deb http://archive.debian.org/debian wheezy main
deb-src http://archive.debian.org/debian wheezy main

#deb http://security.debian.org/ wheezy/updates main
#deb-src http://security.debian.org/ wheezy/updates main


-- 
Regards,

 Manuel Molina Cuberos (deluxe_)