Bug#941715: checkinstall: please make the build reproducible

[Chris Lamb]

Source: checkinstall
Version: 1.6.2+git20170426.d24a630-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that checkinstall could not be built reproducibly.

This is because it embedded the absolute build path in the
/usr/bin/checkinstall file. Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-10-04 07:33:48.292194331 +0100
--- b/debian/rules  2019-10-04 07:43:28.047189552 +0100
@@ -53,6 +53,9 @@
sed -i -e 's|PREFIX/lib|PREFIX/lib/checkinstall|' \
$(TMPDIR)/usr/bin/installwatch
 
+   # Remove absolute buildpath
+   sed -i -e 's|^INSTALLDIR=.*|INSTALLDIR=/usr|' 
$(TMPDIR)/usr/bin/checkinstall
+
# Remove unwanted makepak binary
rm -f $(TMPDIR)/usr/bin/makepak
 

Bug#941714: bst-external: please make the build reproducible

[Chris Lamb]

Source: bst-external
Version: 0.18.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that bst-external could not be built reproducibly.

This is because it installs a non-deterministic .coverage file
in the binary package.

Patch attached. FYI this can be flagged by Lintian [1].  :)

 [0] https://reproducible-builds.org/
 [1] https://lintian.debian.org/tags/package-contains-python-coverage-file.html


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-10-04 07:31:20.439104485 +0100
--- b/debian/rules  2019-10-04 07:39:43.152728623 +0100
@@ -6,3 +6,4 @@
 # The tests need some work to pass in Debian
 override_dh_auto_test:
-dh_auto_test
+   find -type f -name .coverage -delete

Bug#940685: buster-pu: libsixel/1.8.2-1+deb10u1

[Takatsugu Nokubi]

On Sat, 21 Sep 2019 20:47:25 +0100 "Adam D. Barratt"
 wrote:
> Control: tags -1 + moreinfo
> What environment were the amd64 packages that you uploaded built in?

Sorry, I had built on a stretch environment, so I rebuild it with
git-pbuilder environment,
tested with piuparts, and had uploaded.

Bug#941700: [Pkg-javascript-devel] Bug#941700: Update babel to version 7

[Pirate Praveen]

Control: block -1 by 929829
Control: tags -1 help

On 2019, ഒക്‌ടോബർ 4 3:22:23 AM IST, Evgeny Kapun  
wrote:
>Source: node-babel
>Version: 6.26.0+dfsg-3
>Severity: important
>
>Babel 7 was released more than a year ago, so perhaps it's time to
>package the new version.

We already started the update work, but since it needs gulp 4, we are stuck (we 
are not able to fix gulp 4 errors). Alternatively we could try to skip gulp.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#941713: buster-pu: package ntpsec/1.1.3+dfsg1-2+deb10u1

[Richard Laager]

Subject: buster-pu: package ntpsec/1.1.3+dfsg1-2+deb10u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: normal

This is my first time with the Debian proposed update process (though I
have done my own Ubuntu SRU once), so please bear with me and let me
know if I've done anything wrong.

The debdiff from the current version in Buster is attached. All of these
fixes are in the version of ntpsec in Debian unstable.


This upload is to fix several things, most importantly the first two:

* Backport fix for slow DNS retries (Closes: 924192)

The user described this pretty well, "What seems to be happening is that
if DNS is not immediately available when ntpsec starts, it waits about
10 minutes before trying again. Ten minutes is too long."

This is fixed by backporting an upstream commit which has made it into
an upstream point release.


* Fix ntpdate -s (syslog) to fix the if-up hook (Closes: 931414)

Here, the if-up hook script failed to work at all. It did not trigger
the time to be synchronized. This was ultimately due to upstream's
ntpdate wrapper, which was converting -s (for "log to syslog") to
ntpdig -p.  This is wrong, as ntpdig -p is for the number of samples and
requires a parameter.  The ntpdig man page says, "This version does not
log to syslog. Pipe standard output and standard error to logger(1) if
you want this behavior.

This was fixed by me implementing the syslog (piping to logger) behavior
in the ntpdate wrapper script. I submitted the patch upstream, it was
accepted, has made it into an upstream point release, and I have pulled
it into this backport update.



It may be controversial that I'm including fixes for bugs in man pages,
including some without Debian bug numbers. The fixes below are trivial
and only affect two (related) man pages. I likely would not have made a
buster update for them alone, but since I'm making an update anyway, it
seemed reasonable to me to include those fixes.



* ntpdate.8: Remove -p option (Closes: 926877)

The ntpdate -p option (not to be confused with the above discussion of
ntpdig -p) no longer exists. This bug is not that critical, but the fix
is trivial and low risk (as it's just to a man page).

* ntpdate.8: Remove -e option

No bug was filed for this, but this was discovered while fixing the
other issue. The -e option is gone too. I removed it from the man pages.
Again, this fix is trivial and low risk (just a man pages change).

* ntpdate.8: Remove duplicated -o option

This was also discovered while reviewing the ntpdate man page. The -o
option was listed twice. This is another trivial (single character
removal, in this case) fix to the man pages.

* ntpdate.8: Remove inaccurate BUGS section

The ntpdate man page has a BUGS section that says its "slew adjustment
is actually 50% larger than the measured offset". This is completely
wrong, which I verified with upstream. The NTPsec implementation of
ntpdate is just a wrapper script around ntpdig, which does not have this
behavior. This is fixed by removing the inaccurate information from the
man page.

* Update ntpdate-debian.8 to match ntpdate.8

The Debian packaging of NTPsec has an ntpdate-debian utility that is
itself a wrapper around ntpdate. This approach is inherited from the
Debian "ntp" package (upstream ntpsec is a fork of upstream ntp). The
man pages were inconsistent. This fixes the ntpdate-debian man page by
adding the missing -4 and -6 flags, strips some EOL whitespace, and
updates the body text to match, including mentioning the server argument(s).


-- 
Richard
diff -Nru ntpsec-1.1.3+dfsg1/debian/changelog 
ntpsec-1.1.3+dfsg1/debian/changelog
--- ntpsec-1.1.3+dfsg1/debian/changelog 2019-02-04 01:38:48.0 -0600
+++ ntpsec-1.1.3+dfsg1/debian/changelog 2019-10-04 00:21:09.0 -0500
@@ -1,3 +1,15 @@
+ntpsec (1.1.3+dfsg1-2+deb10u1) buster; urgency=medium
+
+  * Backport fix for slow DNS retries (Closes: 924192)
+  * ntpdate.8: Remove duplicated -o option
+  * ntpdate.8: Remove -p option (Closes: 926877)
+  * ntpdate.8: Remove -e option
+  * ntpdate.8: Remove inaccurate BUGS section
+  * Update ntpdate-debian.8 to match ntpdate.8
+  * Fix ntpdate -s (syslog) to fix the if-up hook (Closes: 931414)
+
+ -- Richard Laager   Fri, 04 Oct 2019 00:21:09 -0500
+
 ntpsec (1.1.3+dfsg1-2) unstable; urgency=medium
 
   * Suppress lintian warning
diff -Nru ntpsec-1.1.3+dfsg1/debian/gbp.conf ntpsec-1.1.3+dfsg1/debian/gbp.conf
--- ntpsec-1.1.3+dfsg1/debian/gbp.conf  2019-02-04 01:38:48.0 -0600
+++ ntpsec-1.1.3+dfsg1/debian/gbp.conf  2019-10-04 00:19:41.0 -0500
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = sid
+debian-branch = buster
 
 [buildpackage]
 sign-tags = True
diff -Nru ntpsec-1.1.3+dfsg1/debian/man/ntpdate.8 
ntpsec-1.1.3+dfsg1/debian/man/ntpdate.8
--- ntpsec-1.1.3+dfsg1/debian/man/ntpdate.8 2019-02-04 01:38:48.0 
-0600
+++ ntpsec-1.1.3+dfsg1/debian/man/ntpdate.8 2019-09-27 02:12:22.0 
-0

Bug#935086: insighttoolkit4 REMOVED from testing

[Andreas Tille]

Hi Steve and Gert,

since I have no idea about itk I have ignored this issue.  Is there
any chance to get this fixed soon to make sure this package and its
rdepends will migrate back to testing soon?

Kind regards

  Andreas.

On Fri, Oct 04, 2019 at 04:39:19AM +, Debian testing watch wrote:
> FYI: The status of the insighttoolkit4 source package
> in Debian's testing distribution has changed.
> 
>   Previous version: 4.12.2-dfsg1-4
>   Current version:  (not in testing)
>   Hint: 
> Bug #935086: insighttoolkit4: FTBFS with GCC-9: use of undeclared 
> identifier '__builtin_is_constant_evaluated'
> 
> The script that generates this mail tries to extract removal
> reasons from comments in the britney hint files. Those comments
> were not originally meant to be machine readable, so if the
> reason for removing your package seems to be nonsense, it is
> probably the reporting script that got confused. Please check the
> actual hints file before you complain about meaningless removals.
> 
> -- 
> This email is automatically generated once a day.  As the installation of
> new packages into testing happens multiple times a day you will receive
> later changes on the next day.
> See https://release.debian.org/testing-watch/ for more information.
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#849308: wireguard: Wireguard should not transition to stable yet

[Willem van den Akker]

Hi DKG,


> Please make sure you can build the package from the debian/master branch
> at 
https://salsa.debian.org/debian/wireguard> .
> 
> If you can do that successfully (it shouldn't be too hard), feel free to
> take a look at the debian/TODO file, which contains a handful of
> suggestions, mostly about setting up more detailed autopkgtest testing.

Building is no problem. I will dig into the autopkgtest testing. It is
rather new to me.

> 
> Another thing that might be handy is to read through the discussion
> starting here:
> 
> 
> https://lists.debian.org/deity/2019/09/msg00017.html
> 
> 
> The idea is to propose a debian package for binary wireguard kernel
> modules that matches the current kernel package, so that users
> wouldn't
> need to use dkms.  getting the dependency details right there is
> tricky,
> as is keeping it up to date, but it might be worth trying.

Interesting, needs more digging from my side.

> 
> I've pushed a very ungainly initial attempt at this binary module
> packaging to 
> https://salsa.debian.org/debian/wireguard-modules
>  -- you
> might want to take a look at that and consider fixing one of the
> things
> in debian/TODO there, and proposing a fix.  


> Alternately, testing its
> build and seeing whether the resultant binary works or not on systems
> without dkms would also be interesting.

That shouldn't be a problem.


First I will take the autopkgtest.

Greetings,
Willem

Bug#941712: hfs partitions corrupted when removing lots of files over network

[Graham Coster]

Package: hfsutils
Version: 3.2.6-14
Severity: grave
 Output from uname -a
Linux raspberrypi 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l 
GNU/Linux


 Output from apt show libc6 2>&1 | grep ^Version
Version: 2.28-10+rpi1

 Hardware;
RaspberryPi model 2b and RaspberryPi model 4b


 What led up to the situation?
I set up a new RaspberryPi to be a Samba network file server for an HFS 
partition  (see setup section at end of this email for details). I then deleted 
about 300 files from the HFS partition from a client machine.  This caused an 
"Internal error: Oops: 206 [#1] SMP ARM".  See kern.log below for Oops details.

After the error, the filesytem was corrputed and could not be repaired using 
fsck.  See fsck output below.

To reproduce the problem, I run the following from a client machine;
for i in {1..300}; do touch /Volumes/TimeMachineBackup/$i; done ; rm 
/Volumes/TimeMachineBackup/*

Every time I re-run this test on a freshly formatted drive, the same error 
occurs and the filesystem is always corrupted and cannot be repaired (i.e. 
total data loss).


 What exactly did you do (or not do) that was effective (or ineffective)?
I tried all of the following;
- Replaced Samba network sharing with Netatalk
- Re-installed Raspbian from scratch
- Different mkfs.hfs formatting options to add journal files and alter the 
b-node sizes
- Various samba configurations to change sync / async options, threading 
options, permissions, etc
- 3 different disk drives (USB flash drive, USB powered HDD, Separately powered 
HDD)
- 2 different RaspberryPi models (2b and 4b)
- Different network connections speeds (WiFi at 200Mbs, Ethernet at 100Mbs, 
Ethernet at 1000Mbs)
- Deleted 300 files locally on the RaspberryPi file server (i.e. not over 
network)
- Replaced HFS+ format with EXT4


 What was the outcome of this action?
None the the things I tried above had any impact on the problem except;
- The problem did not occur at all when deleting locally on the RaspberryPi 
file server.
- The problem did not occur at all when HFS+ was replaced with EXT4

 What outcome did you expect instead?
Given the problem did not occur locally on the file server, but did over 
Sambaa, I expected the problem to go away when I replaced Samba with Netatalk.  
It did not.

I wonder if the problem relates to how all file-networking protocols interact 
with local filesystems?


#
# LOGS AND OUTPUT   #
#
   
# kern.log;

Sep 26 16:09:25 raspberrypi kernel: [  222.906719] hfsplus: trying to free free 
bnode 0(1)
Sep 26 16:09:25 raspberrypi kernel: [  222.906844] hfsplus: trying to free free 
bnode 0(1)
Sep 26 16:09:25 raspberrypi kernel: [  222.906893] Unable to handle kernel NULL 
pointer dereference at virtual address 
Sep 26 16:09:25 raspberrypi kernel: [  222.906906] pgd = bc442823
Sep 26 16:09:25 raspberrypi kernel: [  222.906914] [] *pgd=11d05003, 
*pmd=
Sep 26 16:09:25 raspberrypi kernel: [  222.906933] Internal error: Oops: 206 
[#1] SMP ARM
Sep 26 16:09:25 raspberrypi kernel: [  222.906942] Modules linked in: nls_utf8 
hfsplus bnep hci_uart btbcm serdev bluetooth ecdh_generic 8021q garp stp llc 
vc4 v3d drm_kms_helper brcmfmac gpu_sched brcmutil drm 
drm_panel_orientation_quirks snd_bcm2835(C) snd_soc_core sha256_generic 
snd_compress snd_pcm_dmaengine snd_pcm sg snd_timer syscopyarea sysfillrect 
sysimgblt fb_sys_fops cfg80211 rfkill snd raspberrypi_hwmon hwmon 
bcm2835_codec(C) bcm2835_v4l2(C) v4l2_mem2mem v4l2_common videobuf2_vmalloc 
bcm2835_mmal_vchiq(C) videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 
videobuf2_common videodev media vc_sm_cma(C) rpivid_mem uio_pdrv_genirq uio 
fixed ip_tables x_tables ipv6
Sep 26 16:09:25 raspberrypi kernel: [  222.907150] CPU: 3 PID: 634 Comm: smbd 
Tainted: G C4.19.66-v7l+ #1253
Sep 26 16:09:25 raspberrypi kernel: [  222.907160] Hardware name: BCM2835
Sep 26 16:09:25 raspberrypi kernel: [  222.907177] PC is at kmap+0x1c/0x44
Sep 26 16:09:25 raspberrypi kernel: [  222.907188] LR is at 
_cond_resched+0x30/0x50
Sep 26 16:09:25 raspberrypi kernel: [  222.907196] pc : []lr : 
[]psr: 6013
Sep 26 16:09:25 raspberrypi kernel: [  222.907205] sp : dc0e3cc0  ip : dc0e3cb0 
 fp : dc0e3cd4
Sep 26 16:09:25 raspberrypi kernel: [  222.907214] r10: 002e  r9 : dcdf9c48 
 r8 : 
Sep 26 16:09:25 raspberrypi kernel: [  222.907222] r7 : dc0e3d02  r6 : dcdf9c7c 
 r5 : 0002  r4 : 
Sep 26 16:09:25 raspberrypi kernel: [  222.907231] r3 :   r2 : c0e953fc 
 r1 :   r0 : 
Sep 26 16:09:25 raspberrypi kernel: [  222.907241] Flags: nZCv  IRQs on  FIQs 
on  Mode SVC_32  ISA ARM  Segment user
Sep 26 16:09:25 raspberrypi kernel: [  222.907250] Control: 30c5383d  Table: 
1e71cfc0  DAC: 
Sep 26 16:09:25 raspberrypi kernel

Bug#941711: fwupdmgr: gets the wrong list of updates on OptiPlex 3046

[Akihiro Terasaki]

Package: fwupd
Version: 1.2.5-2
Severity: normal

Dear Maintainer,

When I invoke `fwupdmgr get-updates' from an ordinary shell
prompt it prints about `OptiPlex 3040 System Update',
rather than the expected `OptiPlex 3046 System Update'.

Here is a transcript:

$ fwupdmgr get-updates
OptiPlex 3046 System Firmware has firmware updates:
GUID:d63450d6-d611-48ac-8f3b-8d29bad80248
ID:  com.dell.uefid63450d6.firmware
Update Version:  0.1.11.3
Update Name: OptiPlex 3040 System Update
Update Summary:  Firmware for the Dell OptiPlex 3040
Update Remote ID:lvfs
Update Checksum: SHA1(c86096350d1dae4aa6db255412b12cf5c54601db)
Update Location: 
https://fwupd.org/downloads/2f3fedb9f816aa8bade4ec80696a75f563f6db93-firmware_OptiPlex_3040_1.11.3.Wu.cab
Update Description:  2019 Intel Q1 QSR update

ID:  com.dell.uefid63450d6.firmware
Update Version:  0.1.10.1
Update Name: OptiPlex 3040 System Update
Update Summary:  Firmware for the Dell OptiPlex 3040
Update Remote ID:lvfs
Update Checksum: SHA1(9ecfae473f2a9fa2c396bc8d3b6c5d5bbdbfe903)
Update Location: 
https://fwupd.org/downloads/90c23760d294180b9f510cd4f40ac0a9f487a518-OptiPlex_3040_1.10.1.cab
Update Description:  This stable release fixes the following issues:

 Security issues fixed:

ID:  com.dell.uefid63450d6.firmware
Update Version:  0.1.9.0
Update Name: OptiPlex 3040 System Update
Update Summary:  Firmware for the Dell OptiPlex 3040
Update Remote ID:lvfs
Update Checksum: SHA1(273611bb5d0a325101cb536637707d36eb8f3d2d)
Update Location: 
https://fwupd.org/downloads/b6efd5637b4adb7b200e1fab4d2ed9189a43748f-Signed_1152921504627896538.cab
Update Description:  This stable release fixes the following issues:

 Some new functionality has also been added:

$ 

Cheers

Akihiro

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

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

Versions of packages fwupd depends on:
ii  libarchive13   3.3.3-4
ii  libc6  2.28-10
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.2.5-2
ii  libgcab-1.0-0  1.2-3~deb10u1
ii  libglib2.0-0   2.58.3-2+deb10u1
ii  libgnutls303.6.7-4
ii  libgpg-error0  1.35-1
ii  libgpgme11 1.12.0-6
ii  libgudev-1.0-0 232-2
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-25
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.64.2-2
ii  libsqlite3-0   3.27.2-3
ii  libxmlb1   0.1.6-2
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
ii  bolt   0.7-2
ii  fwupd-amd64-signed [fwupd-signed]  1.2.5+2
ii  python33.7.3-1
ii  tpm2-abrmd 2.1.0-1
ii  tpm2-tools 3.1.3-2

fwupd suggests no packages.

-- debconf-show failed

-- 
Akihiro Terasaki

Bug#896090: Integrity:Exposing this info is a significant issue for the media to grapple with but it has to be driven through for mankind.

[rms.ferrell36]

Good day. How are you doing these days? I hope you're doing well and things are 
working out all right.


 It's my belief that these revelations were given for us to know the truth and 
choose the right path accordingly.
It would be much appreciated if you acknowledge that the truth must be known to 
all and make as much effort as possible to promote public awareness of these 
testimonies.
   uk mirror news

https://www.youtube.com/watch?v=_sRgc9NtHQI    ( unwelcome truth )
https://www.youtube.com/watch?v=dWXkBBIaiVc   a trip to Hell (  extremely 
graphic )
http://heavencometrue.com/?lang=eng  ( website of the Heaven&Hell eyewitness )





  
unsubscribe

Bug#836232: sooperlooper: upon initialization, slgui fails an assertion with SetTitle

[Olly Betts]

Control: tags -1 + unreproducible

On Thu, Oct 03, 2019 at 07:25:12PM +0200, Olivier Humbert wrote:
> Can't reproduce here on a Debian Stretch (oldstable) or a Debian Buster
> (stable).

Cc-ing the submitter since Debian's BTS rather surprisingly doesn't by
default!

chris: Can you still reproduce this on a current Debian version?

Cheers,
Olly

Bug#941366: If I run vim, but only vim.tiny is present, please don't say "command not found"

[Jason Spiro]

On Sun, Sep 29, 2019 at 10:42 PM James McCoy  wrote:
> While I understand the frustration you experienced, I don't think adding
> such a script is an appropriate solution.  I don't think there's much to
> do from the perspective of this package.  Possibly, there's an
> opportunity for enhancing the command-not-found package, but that would
> be a separate investigation/discussion.

Thank you for your reply!

I hear you.

My hunch is that enhancing command-not-found wouldn't be an ideal
solution either.  This is for two reasons:

A)  Experienced users might not pay much attention to
command-not-found's output.
B)  The command-not-found script runs kind of slowly, so users in a
hurry might even interrupt it with Ctrl+C.

Therefore:  Perhaps it would make sense for vim-tiny to provide a
/usr/bin/vim symlink which points to the vim.tiny binary?  A minimal
Vim is already installed; you might as well let users run it using the
"vim" command.  :)

If not:  Why would adding a /usr/bin/vim script, which outputs some
help text and then quits with exit code 1, be a less-than-ideal
solution?

Cheers,
--Jason

Bug#873795: calibre: Security risk and possible backdoor when fetching news

[Dev Null]

On Sat, 21 Sep 2019 14:06:28 -0400 Nicholas D Steeves 
wrote:
> Control: tags = confirmed
> Control: severity = important
>
> On Thu, Aug 31, 2017 at 10:07:25AM +0200, Jens Schmidt wrote:
> > Package: calibre
> > Version: 3.4.0+dfsg-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > I'm using cron and /usr/bin/ebook-convert to fetch RSS news daily. Some
> > generated ebooks are containing typos. The mistakes are located in a
so-called
> > "news fetching recipe" in Zip archive
/usr/share/calibre/builtin_recipes.zip. I
> > tried to edit the recipe code but the mistakes remain in ebooks. I
wrote an own
> > custom recipe, I edited built-in recipe in ZIP archive - nothing
helps. As a
> > last try I switched off network and had success. That maked me
curious, so I
> > repeated the procedures with Wireshark logging network traffic. The
result:
> >
> > Calibre completely ignores built-in recipes and loads python scripts
from a
> > server in Mumbai/India: https://code.calibre-ebook.com:443/... ( using
self-
> > signed wildcard certificate)
> >
> > It's a absolute taboo to load scripts in background from an untrusted
server
> > and execute them on a Linux computer without user permission and without
> > informing user. This is a Debian OS not Windows. What if the scripts are
> > containing malware or spyware?
> >
>
> Assuming good faith in the upstream, this is still a privacy breach,
> so I agree we ought to do something about this.  Here is everywhere
> the this website is mentioned in the source code for debian/3.48.0+dfsg-1.
>
> $ ag code.calibre-ebook.com
>   setup/linux-installer.py
>   644:'https://code.calibre-ebook.com/tarball-info/' +
('x86_64' if is64bit else 'i686'))
>   666:calibre_version =
urlopen('http://code.calibre-ebook.com/latest').read()
>
>   setup/linux-installer.sh
>   693:'https://code.calibre-ebook.com/tarball-info/' +
('x86_64' if is64bit else 'i686'))
>   715:calibre_version =
urlopen('http://code.calibre-ebook.com/latest').read()
>
>   src/calibre/ebooks/metadata/sources/update.py
>   95:'https://code.calibre-ebook.com/metadata-sources/hashes.json')
>   112:raw =
get_https_resource_securely('https://code.calibre-ebook.com/metadata-sources/'
+ name)
>
>   src/calibre/gui2/dialogs/plugin_updater.py
>   28:SERVER = 'https://code.calibre-ebook.com/plugins/'
>
>   src/calibre/gui2/store/loader.py
>   29:def download_updates(ver_map={},
server='https://code.calibre-ebook.com'):
>
>   src/calibre/gui2/update.py
>   24:URL = 'https://code.calibre-ebook.com/latest'
>
>   src/calibre/gui2/icon_theme.py
>   48:BASE_URL = 'https://code.calibre-ebook.com/icon-themes/'
>
>   src/calibre/utils/https.py
>   217:   
print(get_https_resource_securely('https://code.calibre-ebook.com/latest'))
>

Dear Maintainer,

I hope I'm not following up on this bug too soon, but I'm curious as to
the status of this bug, as I am a current user of calibre. Are there any
changes either upstream or written by yourself to stop this third-party
code execution?

I was notified of this bug during a routine 'apt-get upgrade' to the most
recent backported version of this program. (3.39.1+dfsg-3!bpo9+1)


-- 
/dev/null
4057 0DA0 0983 FFA1 8756  670F 754A 0CB9 A367 275B
https://devnull.iamdevnull.info/devnull.gpg

Bug#941710: lilv FTCBFS: Build-Depends: python not installable

[Helmut Grohne]

Source: lilv
Version: 0.24.4~dfsg0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

lilv fails to cross build from source, because its build dependency on
(the host architecture) python is not installable. Indeed, it wants
python for the build architecture to run. Beyond that, one should export
CC and PKGCONFIG to tell waf what we are compiling for. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru lilv-0.24.4~dfsg0/debian/changelog 
lilv-0.24.4~dfsg0/debian/changelog
--- lilv-0.24.4~dfsg0/debian/changelog  2019-08-22 12:00:49.0 +0200
+++ lilv-0.24.4~dfsg0/debian/changelog  2019-10-04 04:55:13.0 +0200
@@ -1,3 +1,12 @@
+lilv (0.24.4~dfsg0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate Build-Depends: python with :native.
++ Export suitable cross environment from dpkg's buildtools.mk.
+
+ -- Helmut Grohne   Fri, 04 Oct 2019 04:55:13 +0200
+
 lilv (0.24.4~dfsg0-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru lilv-0.24.4~dfsg0/debian/control 
lilv-0.24.4~dfsg0/debian/control
--- lilv-0.24.4~dfsg0/debian/control2019-08-22 12:00:49.0 +0200
+++ lilv-0.24.4~dfsg0/debian/control2019-10-04 04:55:12.0 +0200
@@ -14,7 +14,7 @@
  libsratom-dev (>= 0.4.0~),
  lv2-dev (>= 1.14.0~),
  pkg-config,
- python
+ python:native
 Standards-Version: 4.4.0
 Homepage: https://drobilla.net/software/lilv/
 Vcs-Git: https://salsa.debian.org/multimedia-team/lilv.git
diff --minimal -Nru lilv-0.24.4~dfsg0/debian/rules 
lilv-0.24.4~dfsg0/debian/rules
--- lilv-0.24.4~dfsg0/debian/rules  2019-08-22 12:00:49.0 +0200
+++ lilv-0.24.4~dfsg0/debian/rules  2019-10-04 04:55:13.0 +0200
@@ -1,9 +1,12 @@
 #!/usr/bin/make -f
 
 include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+export CC
+export PKGCONFIG = $(PKG_CONFIG)
 export LINKFLAGS += $(LDFLAGS)
 
 WAF = ./waf

Bug#941709: postfix-gld FTCBFS: uses build architecture build tools

[Helmut Grohne]

Source: postfix-gld
Version: 1.7-8
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

postfix-glx fails to cross build from source, because it uses build
architecture build tools. Please consider applying the attached patch to
use the (cross) tools detected by dpkg's buildtools.mk.

Helmut
diff --minimal -Nru postfix-gld-1.7/debian/changelog 
postfix-gld-1.7/debian/changelog
--- postfix-gld-1.7/debian/changelog2016-11-27 18:53:34.0 +0100
+++ postfix-gld-1.7/debian/changelog2019-10-04 04:12:05.0 +0200
@@ -1,3 +1,10 @@
+postfix-gld (1.7-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply cross tools. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Oct 2019 04:12:05 +0200
+
 postfix-gld (1.7-8) unstable; urgency=medium
 
   * Adapt to new metapackage policy. Closes: #845896.
diff --minimal -Nru postfix-gld-1.7/debian/rules postfix-gld-1.7/debian/rules
--- postfix-gld-1.7/debian/rules2016-11-27 17:00:00.0 +0100
+++ postfix-gld-1.7/debian/rules2019-10-04 04:12:03.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/buildtools.mk
+
 package = postfix-gld
 docdir = debian/tmp/usr/share/doc/$(package)
 
@@ -7,13 +9,14 @@
 
 DATABASE = mysql
 
+export CC
 CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall
 LDFLAGS := `dpkg-buildflags --get LDFLAGS`
 CPPFLAGS := `dpkg-buildflags --get CPPFLAGS`
-STRIP = true
+STRIP_PROGRAM = true
 
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-  STRIP = strip --remove-section=.comment --remove-section=.note
+  STRIP_PROGRAM = $(STRIP) --remove-section=.comment --remove-section=.note
 endif
 
 build:
@@ -55,7 +58,7 @@
cd $(docdir) && gzip -9n HISTORY changelog.Debian
ln -s HISTORY.gz $(docdir)/changelog.gz
gzip -r9n debian/tmp/usr/share/man
-   $(STRIP) debian/tmp/usr/sbin/*
+   $(STRIP_PROGRAM) debian/tmp/usr/sbin/*
dpkg-shlibdeps debian/tmp/usr/sbin/*
dpkg-gencontrol
chown -R 0:0 debian/tmp

Bug#941708: ITP: nextcloud-server -- Nextcloud folder synchronization tool (server)

[Antonio Russo]

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

 * Package name: nextcloud-server
   Version : 0.1.7
   Upstream Author : Antonio Russo 
 * URL : https://gitlab.com/aerusso/nextcloud-server-deb
 * License : AGPL
 * Vcs : https://gitlab.com/aerusso/nextcloud-server-deb
   Section : net
   Description : Nextcloud folder synchronization tool (server)

Nextcloud is an increasingly popular software package.  A first-class
integration of Nextcloud into Debian is desirable, but represents
a significant challenge because upstream development is unlikely to
produce long-cycled supported releases compatible with the Debian
release cycle.

This packaging sidesteps that issue by providing version-independent
tools to download, install, configure, update, and manage the server.
Although unconventional, such tools are not unheard of in Debian [1,2].

The current version is suitable for beta testing, and should eventually
reach maturity compatible with Debian stable.

Thank you,
Antonio Russo

[1] ttf-mscorefonts-installer
[2] libdvd-pkg

Bug#941611: linux-image-5.2.0-2-amd64: Kernel 5.2 has terrible performance under load

[James Bottomley]

On Wed, 2019-10-02 at 22:07 +0200, Salvatore Bonaccorso wrote:
> > Linux Kernel 5.2 is completely unusable on most of my systems.  The
> > problem seems to be something to do with memory compaction causing
> > intervals where the system becomes unresponsive.
> > 
> > This is definitely an upstream issue (my laptop running the
> > upstream kernel is displaying the problem as well) so this bug is
> > really just a warning not to deploy the 5.2 kernel until a fix is
> > found.
> 
> If so, could you point where it was reported upstream so we can set
> accorrdingly where it has been forwarded to?

Well the initial incarnation of this upstream patch set

https://marc.info/?t=15676268933

Seems to fix the problem in my testbeds.  I'm testing out the first two
patches only at the moment.

James

Bug#935669: assaultcube-data: Outdated version makes assaultcube uninstallable

[Jeremy Bicha]

To fix this bug, a Debian Developer will need to do a binary upload of
this package. Once the package makes it through the NEW queue, then
you can follow the final step in the final link of
https://lintian.debian.org/tags/source-only-upload-to-non-free-without-autobuild.html

After all that has been done, you can do a source-only upload off
assaultcube-data.

Thanks,
Jeremy

Bug#941619: ruby-odbc: ODBC dlopen regression in Debian 10

[Martin Dorey]

I've raised this bug again, in a hopefully more coherent way, as:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941707
ruby-odbc: [RubyODBC]Cannot allocate SQLHENV (ODBC::Error)

Sorry for the noise.

Bug#941707: ruby-odbc: [RubyODBC]Cannot allocate SQLHENV (ODBC::Error)

[Martin Dorey]

Package: ruby-odbc
Version: 0.8-1+b1
Severity: normal
Tags: patch

Dear Maintainer,

ruby-odbc does this, at least for me, on Buster:

martind@neutrino:~$ ruby -we 'require "odbc"; ODBC.drivers()'
Traceback (most recent call last):
1: from -e:1:in `'
-e:1:in `drivers': INTERN (0) [RubyODBC]Cannot allocate SQLHENV (ODBC::Error)
martind@neutrino:~$

The same test on the same configuration on Stretch is silent:

martind@scoot:~$ ruby -we 'require "odbc"; ODBC.drivers()'
martind@scoot:~$

I do have non-default /etc/odbc{,inst}.ini files but removing them doesn't 
affect this test.

Buoyed by a mention of Stretch here:

https://bugs.launchpad.net/raspbian/+bug/1832778

... I thought that maybe this blast from the past could have come back:

http://opensysblog.directorioc.net/2013/07/rubyodbccannot-allocate-sqlhenv.html

The change log in:

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

... included:

   * Refresh 001extconf_dlopen.patch

Reverting that fixed the problem.
These are the steps I took:

aptitude source ruby-odbc
sudo aptitude install gem2deb
tar --xz -xf ruby-odbc_0.8-1.debian.tar.xz
debian/patches/ext_enable_dlopen.patch
cd ruby-odbc-0.8/
patch -p1 -R < ../debian/patches/ext_enable_dlopen.patch
dpkg-buildpackage -b -nc -uc
sudo dpkg -i ../ruby-odbc_0.8-1_amd64.deb

I can't say I understand why Debian would have to disable dlopen here.
But the package appears unusuable without that, for me.


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

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

Versions of packages ruby-odbc depends on:
ii  libc6   2.28-10
ii  libgmp102:6.1.2+dfsg-4
ii  libiodbc2   3.52.9-2.1
ii  libruby2.5  2.5.5-3
ii  ruby1:2.5.1
ii  ruby1.8 [ruby]  1.8.7.358-7.1+deb7u6
ii  unixodbc2.3.6-0.1

ruby-odbc recommends no packages.

ruby-odbc suggests no packages.

-- debconf-show failed

Bug#941706: iputils-ping: ping run time is not correct on debian buster

[Eduardo Barros]

Package: iputils-ping
Version: 3:20190709-1
Severity: normal

Dear Maintainer,

whenever ping command is executed the run time is not correct. for example:

++
ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=37.10 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=20.6 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=23.3 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=22.5 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=22.10 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=23.9 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=20.3 ms
^C
--- 1.1.1.1 ping statistics ---

7 packets transmitted, 7 received, 0% packet loss, time 13ms <=== this value is
not ok
rtt min/avg/max/mdev = 20.302/24.508/37.981/5.643 ms
---

the ping run time should be somehere in the order of 6000 ms.

tested this on almost 20 systems running debian buster up to date.

by installing the debian testing version everything looks ok.

+
ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=20.3 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=25.2 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=25.3 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=21.0 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=20.1 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=19.9 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=28.3 ms
^C
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6008ms <=== this value
is ok
rtt min/avg/max/mdev = 19.896/22.867/28.304/3.107 ms
---

thank you.

best regards.



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

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

Versions of packages iputils-ping depends on:
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcap2-bin  1:2.25-2
ii  libgcrypt20  1.8.4-5

iputils-ping recommends no packages.

iputils-ping suggests no packages.

-- no debconf information

Bug#941705: sslh: inconsistent usage of sslh account

[Aaron M. Ucko]

Package: sslh
Version: 1.20-1
Severity: important

Hi, Don.

sslh fails to start on my system, on which I merged the new stock
"--user sslh" option into /etc/default/sslh:

  Oct  3 20:23:01 his-pc sslh-select[11576]: /var/run/sslh/sslh.pid: Permission 
denied

As the message shows, I'm using sslh-select rather than regular sslh,
as specified in the attached systemd override.conf (whose Requires
setting should apparently become a .requires symlink, but that's
another matter).

AFAICT, the error occurs because /usr/lib/tmpfiles.d/sslh.conf still
specifies that root should own /var/run/sslh, whereas sslh, or at
least sslh-select, evidently applies --user before writing its PID
file.

Could you please take a look?

Thanks!

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

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

Versions of packages sslh depends on:
ii  adduser  3.118
ii  debconf  1.5.73
ii  init-system-helpers  1.57
ii  libc62.29-2
ii  libcap2  1:2.25-2
ii  libconfig9   1.5-0.4
ii  libpcre3 2:8.39-12+b1
ii  libwrap0 7.6.q-28
ii  lsb-base 11.1.0
ii  update-inetd 4.50

Versions of packages sslh recommends:
ii  apache2 [httpd]  2.4.41-1
ii  dropbear-bin [ssh-server]2019.78-2
ii  openssh-server [ssh-server]  1:8.0p1-6
ii  yaws [httpd] 2.0.6+dfsg-1

Versions of packages sslh suggests:
ii  openbsd-inetd [inet-superserver]  0.20160825-4

-- Configuration Files:
/etc/default/sslh changed:
DAEMON=/usr/sbin/sslh
DAEMON_OPTS="--user sslh --transparent --listen 192.168.1.2:443 --ssh 
192.168.1.2:22 --ssl 192.168.1.2:443 --pidfile /var/run/sslh/sslh.pid"

/etc/logcheck/ignore.d.server/sslh [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/sslh'

-- debconf information:
* sslh/inetd_or_standalone: standalone
[Service]

# Replace the start command and make it use sslh-select 
ExecStart=
ExecStart=/usr/sbin/sslh-select --foreground $DAEMON_OPTS

# Run sslh as an user and use capabilities to bind ports
User=sslh
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_ADMIN

# Limit access
PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true

# Set routing rules automaticaly on script start
PermissionsStartOnly=true
Requires=nftables.service

# Check for mark 0x4155 (set by nftables) and forward packet to table 0x4155
ExecStartPre=-/sbin/ip rule add fwmark 0x4155 lookup 0x4155
ExecStopPost=-/sbin/ip rule del fwmark 0x4155

# Table 0x4155 to route all packets back to loopback interface
ExecStartPre=-/sbin/ip route add local 0.0.0.0/0 dev lo table 0x4155
ExecStopPost=-/sbin/ip route flush table 0x4155

Bug#941704: RFP: openrdap -- command line RDAP client

[Noah Meyerhans]

Package: wnpp
Severity: wishlist

* Package name: openrdap
  Version : 0.9.0
  Upstream Author : Tom Harwood 
* URL : https://www.openrdap.org/
* License : MIT
  Programming Lang: Go
  Description : command line RDAP client

RDAP is intended to be the successor to the RFC 3912 WHOIS protocol, used to
query information about the registration of domain names and IP addresses.
OpenRDAP is a client implementation of the RDAP protocol.

Currently supported features include:

Small & fast command line RDAP client.
Supports all RDAP query types (domain, ip, asn, help, nameserver, and 
searches).
Automatic query type detection (domain, ip, asn queries).
Full bootstrapping support (using data.iana.org, or a custom URL).
Optional on-disk bootstrap files cache.
Output formats: raw JSON, text, WHOIS format (domain queries).
Customisable query timeout.

Bug#932617: fwupd: conffile not removed: /etc/fwupd/remotes.d/fwupd.conf

[Paul Wise]

Package: fwupd
Version: 1.3.2-1
Followup-For: Bug #932617
Control: retitle -1 fwupd: conffiles not removed: 
/etc/fwupd/remotes.d/fwupd.conf /etc/dbus-1/system.d/org.freedesktop.fwupd.conf

With todays update an additional obsolete conffile was not removed:

$ pkg=fwupd ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
fwupd: obsolete-conffile /etc/fwupd/remotes.d/fwupd.conf
fwupd: obsolete-conffile /etc/dbus-1/system.d/org.freedesktop.fwupd.conf
 /etc/fwupd/remotes.d/fwupd.conf b3884b515fe5ca56eb67dc1664e04e7a obsolete
 /etc/dbus-1/system.d/org.freedesktop.fwupd.conf 
68da0ed066cc29f37b8a7531fd29a939 obsolete

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

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

Versions of packages fwupd depends on:
ii  libarchive13   3.4.0-1
ii  libc6  2.29-2
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.2-1
ii  libgcab-1.0-0  1.2-5
ii  libglib2.0-0   2.60.6-2
ii  libgnutls303.6.9-5
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.64.2-2
ii  libsqlite3-0   3.29.0-2
ii  libtss2-esys0  2.1.0-4+b1
ii  libxmlb1   0.1.8-1+b1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
pn  bolt  
pn  fwupd-signed  
ii  python3   3.7.3-1

fwupd suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Josue Ortega]

Hi,

I've included the recommended changes for the fix:

rpcbind (1.2.5-0.3+deb10u1) buster; urgency=medium

  * Add 00-rmt-calls.patch (Closes: #939877):
+ Add command line option to enable remote calls at runtime
+ Refresh debian/patches
  * debian/control: Update maintainer information
  * Add debian/README.debian explaining remote calls activation for
Debian systems
  * Add debian/NEWS

$ debdiff rpcbind_1.2.5-0.3.dsc rpcbind_1.2.5-0.3+deb10u1.dsc | diffstat

 NEWS|   12 ++
 README.debian   |   11 ++
 changelog   |   12 ++
 control |2 
 patches/00-rmt-calls.patch  |  118

 patches/02-manpages.patch   |4 
 patches/03-563971-warmstart-error-msg.patch |   14 +-
 patches/04-610718-non-linux.patch   |2 
 patches/rpcinfo-Fix-stack-buffer-overflow.patch |4 
 patches/run-migration   |2 
 patches/series  |1 
 11 files changed, 167 insertions(+), 15 deletions(-)

The debdiff is attached.

Regards

--Josue


diff -Nru rpcbind-1.2.5/debian/NEWS rpcbind-1.2.5/debian/NEWS
--- rpcbind-1.2.5/debian/NEWS	1969-12-31 18:00:00.0 -0600
+++ rpcbind-1.2.5/debian/NEWS	2019-09-09 12:19:21.0 -0600
@@ -0,0 +1,12 @@
+rpcbind (1.2.5-0.3+deb10u1) buster; urgency=medium
+
+  Since version 1.2.5 upstream has turned off the remote calls functionality
+  in order to improve security. This can be turned on at build time.
+  This functionality caused rpcbind to open up random listening ports. This
+  change broke up broadcasts requests to rpcbind making systems depending
+  on this feature unusable, e.g. NIS systems.
+  
+  This release accepts the new command line parameter 'r' to turn on the
+  remote calls functionality when needed.
+
+ -- Josue Ortega   Tue, 17 Sep 2019 19:08:34 -0600
diff -Nru rpcbind-1.2.5/debian/README.debian rpcbind-1.2.5/debian/README.debian
--- rpcbind-1.2.5/debian/README.debian	1969-12-31 18:00:00.0 -0600
+++ rpcbind-1.2.5/debian/README.debian	2019-09-09 12:19:21.0 -0600
@@ -0,0 +1,11 @@
+rpcbind for Debian
+--
+Since version 1.2.5 due to security concerns upstream has turned off
+the remote calls functionality by default and added a configuration
+flag at build time to enable it.
+This functionality caused rpcbind to open up random listening ports.
+With remote calls turned off rpcbind stops to receive any broadcast query
+causing breakage on systems depending on this feature, e.g., NIS systems.
+
+On Debian systems the remote calls can be turned on at run-time using
+the command line argument 'r'. See rpcbind(8) for more details.
diff -Nru rpcbind-1.2.5/debian/changelog rpcbind-1.2.5/debian/changelog
--- rpcbind-1.2.5/debian/changelog	2018-10-22 04:54:11.0 -0600
+++ rpcbind-1.2.5/debian/changelog	2019-09-09 12:19:21.0 -0600
@@ -1,3 +1,15 @@
+rpcbind (1.2.5-0.3+deb10u1) buster; urgency=medium
+
+  * Add 00-rmt-calls.patch (Closes: #939877):
++ Add command line option to enable remote calls at runtime
++ Refresh debian/patches
+  * debian/control: Update maintainer information
+  * Add debian/README.debian explaining remote calls activation for
+Debian systems
+  * Add debian/NEWS
+
+ -- Josue Ortega   Mon, 09 Sep 2019 12:19:21 -0600
+
 rpcbind (1.2.5-0.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rpcbind-1.2.5/debian/control rpcbind-1.2.5/debian/control
--- rpcbind-1.2.5/debian/control	2018-10-20 05:18:17.0 -0600
+++ rpcbind-1.2.5/debian/control	2019-09-09 12:19:21.0 -0600
@@ -1,7 +1,7 @@
 Source: rpcbind
 Section: net
 Priority: optional
-Maintainer: Anibal Monsalve Salazar 
+Maintainer: Josue Ortega 
 Build-Depends: debhelper (>= 11), pkg-config, libtirpc-dev (>= 1.0.2), libwrap0-dev, libsystemd-dev [linux-any]
 Standards-Version: 4.2.1
 Homepage: http://sourceforge.net/projects/rpcbind/
diff -Nru rpcbind-1.2.5/debian/patches/00-rmt-calls.patch rpcbind-1.2.5/debian/patches/00-rmt-calls.patch
--- rpcbind-1.2.5/debian/patches/00-rmt-calls.patch	1969-12-31 18:00:00.0 -0600
+++ rpcbind-1.2.5/debian/patches/00-rmt-calls.patch	2019-09-09 12:19:21.0 -0600
@@ -0,0 +1,118 @@
+Description: Add command line option to enable remote calls at runtime instead build time
+Author: Josue Ortega 
+Last-Update: 2019-09-17
+
+
+--- a/Makefile.am
 b/Makefile.am
+@@ -29,10 +29,6 @@
+ AM_CPPFLAGS +=	-DLIBWRAP
+ endif
+ 
+-if RMTCALLS
+-AM_CPPFLAGS +=	-DRMTCALLS
+-endif
+-
+ bin_PROGRAMS = rpcinfo
+ sbin_PROGRAMS = rpcbind
+ 
+--- a/src/rpcbind.c
 b/src/rpcbind.c
+@@ -88,6 +88,7 @@
+ int doabort = 0;	/* When debugging, do an abort on errors */
+ int dofork = 1;		/* fork? */
+ int createdsocket = 0;  /* Did I create the socket or systemd did it for me? */
++int rmtcalls = 0; /* 

Bug#936747: isbnlib: diff for NMU version 3.9.3-1.1

[Sandro Tosi]

Control: tags 936747 + patch
Control: tags 936747 + pending


Dear maintainer,

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

Regards.

diff -Nru isbnlib-3.9.3/debian/changelog isbnlib-3.9.3/debian/changelog
--- isbnlib-3.9.3/debian/changelog	2018-10-21 06:19:21.0 -0400
+++ isbnlib-3.9.3/debian/changelog	2019-10-03 19:46:17.0 -0400
@@ -1,3 +1,10 @@
+isbnlib (3.9.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * drop python2 support; Closes: #936747
+
+ -- Sandro Tosi   Thu, 03 Oct 2019 19:46:17 -0400
+
 isbnlib (3.9.3-1) unstable; urgency=low
 
   * New upstream package
diff -Nru isbnlib-3.9.3/debian/control isbnlib-3.9.3/debian/control
--- isbnlib-3.9.3/debian/control	2018-10-21 06:19:21.0 -0400
+++ isbnlib-3.9.3/debian/control	2019-10-03 19:42:17.0 -0400
@@ -2,21 +2,9 @@
 Maintainer: Aigars Mahinovs 
 Section: python
 Priority: optional
-Build-Depends: python-setuptools (>= 0.6b3), python3-setuptools, python-all (>= 2.6.6-3), python3-all, debhelper (>= 9), dh-python, python-nose, python3-nose
+Build-Depends: python3-setuptools, python3-all, debhelper (>= 9), dh-python, python3-nose
 Standards-Version: 4.2.1
 
-Package: python-isbnlib
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: ISBN processing library
- ISBNlib is a pure Python library for validating, cleaning and getting
- metadata from ISBN strings.
- .
- ISBN or International Standard Book Number format is somewhat fluid so
- this library provides ways to parse it to canonical form and then also to
- validate the numbers via databases as well as get metainfo for issued
- ISBNs.
-
 Package: python3-isbnlib
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru isbnlib-3.9.3/debian/rules isbnlib-3.9.3/debian/rules
--- isbnlib-3.9.3/debian/rules	2015-06-24 15:26:34.0 -0400
+++ isbnlib-3.9.3/debian/rules	2019-10-03 19:42:33.0 -0400
@@ -5,4 +5,4 @@
 export PYBUILD_NAME=isbnlib
 export PYBUILD_DISABLE=test
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#941703: libimobiledevice6: Crashes upower with stack smashing when connecting an iPhone

[Diego Escalante Urrelo]

Package: libimobiledevice6
Version: 1.2.1~git20181030.92c5462-1
Severity: important

Whenever you connect an iPhone when upower is running, a crash in upower
is triggered, apparently because libimobiledevice is doing something
leading to a stack smash crash.

The same happens if you already have the iPhone connected when upower
starts. I'm attaching a trace and log of the first case (connecting the
iPhone when upower is already running).

Note that this crash triggers upower to endlessly reload because of the
crash-restart-crash cycle it gets into.

TI:18:18:15 on_battery = no
TI:18:18:15 SYSFS add /sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2
TI:18:18:15 no changes
TI:18:18:15 failed to refresh 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2
TI:18:18:15 object path = /org/freedesktop/UPower/devices/phone_1_2x2
TI:18:18:15 added /sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2
TI:18:18:15 emitting added: /org/freedesktop/UPower/devices/phone_1_2x2
TI:18:18:15 SYSFS add 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
[New Thread 0x7532e700 (LWP 5588)]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
[Thread 0x7532e700 (LWP 5588) exited]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
TI:18:18:15 unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2
TI:18:18:15 SYSFS remove 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
TI:18:18:15 ignoring remove event on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
TI:18:18:15 SYSFS add 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
[New Thread 0x7532e700 (LWP 5594)]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
[Thread 0x7532e700 (LWP 5594) exited]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
TI:18:18:15 SYSFS add 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
[New Thread 0x7532e700 (LWP 5596)]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
[Thread 0x7532e700 (LWP 5596) exited]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
TI:18:18:15 SYSFS add 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
[New Thread 0x7532e700 (LWP 5598)]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
[Thread 0x7532e700 (LWP 5598) exited]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
TI:18:18:15 unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
TI:18:18:15 unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
TI:18:18:15 unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
TI:18:18:16 Unknown state on supply 
/org/freedesktop/UPower/devices/battery_BAT0; forcing update after 1 seconds
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 using min design voltage
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 Setup poll for 'BAT0' every 120 seconds
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 Setup poll for 'BAT0' every 120 seconds
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 Setup poll for 'BAT0' every 120 seconds
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
[Thread 0x75b2f700 (LWP 5543) exited]
*** stack smashing detected ***:  terminated

Thread 1 "upowerd" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x77a1c081 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77a07535 in __GI_abort () at abort.c:79
#2  0x77a5ddb8 in __libc_message (action=, 
fmt=fmt@entry=0x77b688a2 "*** %s ***: %s terminated\n")
at ../sysdeps/posix/libc_fatal.c:181
#3  0x77aec81d in __GI_

Bug#939551: systemd MountFlags broken

[Michael Biebl]

On Fri, 13 Sep 2019 09:06:39 +0200 Harald Dunkel
 wrote:
> Stay tuned, I had a busy week.
> 
> But I am surprised that you rely on "non-Debian" software to
> reproduce the bug. Ain't the test case mentioned in
> 
> https://github.com/systemd/systemd/commit/37ed15d7edaf59a1fc7c9e3552cd93a83f3814ef
> 
> sufficient to reproduce the problem and verify the fix, without
> dependency to a (highly complex) Rancher installation framework?
> 


I want to make sure that the problems you had with docker are actually
fixed by this upstream commit.

-- 
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#941636: udev: 73-usb-net-by-mac.rules breaks systemd.link(5) network interface renaming for usb network adapters

[Michael Biebl]

Thanks for the additional information.

Your proposed change looks ok to me but I'd like an ACK from Martin on this.

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#941702: RM: python-osd -- RoQA; python2-only; dead upstream; maintainer emails bounces; low popcon; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#941701: RM: python-iso8583 -- RoQA; python2-only; dead upstream; last upload May 2013; maintainer emails bounces; low popcon; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#408162: fookb-plainx: Menu item does not work by default.

[Jeremy Sowden]

I've submitted a patch upstream to fall back to default parameter values
if there is no config-file in $HOME.  The specific values used upstream
will not be appropriate for Debian, so I will add a separate patch to
the package.

J.


signature.asc
Description: PGP signature

Bug#936730: [Python-modules-team] Bug#936730: impacket: Python2 removal in sid/bullseye

[Raphael Hertzog]

Hello,

On Tue, 01 Oct 2019, Emmanuel Arias wrote:
> I've just push to salsa and mentors
> (https://mentors.debian.net/package/python-ldapdomaindump)
> ldapdomaindump, maybe you can sponsor it :) thanks

I can sponsor it but first I'd like you to make some changes:

1/ fix the Vcs-Git and Vcs-Browser URL to match the correct location
   on salsa.debian.org

2/ point 1 prove that you based your work on the kali package so please
   credit Kali in the changelog and keep the Kali copyright notice for the
   debian/* files in debian/copyright.

3/ please reuse the same .orig.tar.gz (bit for bit!) for Debian as what we
   used in Kali, otherwise Kali will not be able to import the Debian
   package due to different conflicting files with the same name
   (you have to redo "pristine-tar commit " manually with
   the correct file).

$ wget 
http://http.kali.org/pool/main/p/python-ldapdomaindump/python-ldapdomaindump_0.9.1.orig.tar.gz
$ sha1sum python-ldapdomaindump_0.9.1.orig.tar.gz 
7df22d1fb6207e71c93abad6fa5e92179aa8b548  
python-ldapdomaindump_0.9.1.orig.tar.gz

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#941636: udev: 73-usb-net-by-mac.rules breaks systemd.link(5) network interface renaming for usb network adapters

[Benjamin Poirier]

On 2019/10/03 13:34, Michael Biebl wrote:
> Hi
> 
> Am 03.10.19 um 10:17 schrieb Benjamin Poirier:
> > Package: udev
> > Version: 243-2
> > Severity: normal
> > 
> > /lib/udev/rules.d/73-usb-net-by-mac.rules prevents the renaming of network
> > interfaces from usb adapters using the systemd.link(5) mechanism.
> > 
> > The latter is implemented using /lib/udev/rules.d/80-net-setup-link.rules
> > which is ineffective because 73-usb-net-by-mac.rules has previously
> > unconditionally set a name (based on the mac address).
> 
> Not quite unconditionally. The conditions are

That's right, thanks for correcting me.

> - user has not disabled persistent interface naming via the kernel
> command line (net.ifnames=0)

systemd.link also checks this kernel option:
"NamePolicy= may be disabled by specifying net.ifnames=0 on the kernel
command line."

> - the interface name has not been provided by user space
> ATTR{name_assign_type}=="3"

We can change the 73-usb-net-by-mac.link I gave as an example to add
"keep":
[Link]
NamePolicy=keep mac

> - NAME= is unset

This is also checked by 80-net-setup-link.rules

> - it has a universally administered (stable) MAC address (second bit
>   is 0).

net_setup_link implements the same condition:

"ID_NET_NAME_MAC=prefixxAABBCCDDEEFF

[...] It is available if the device has a fixed MAC address. [...]
"

The check is based on addr_assign_type provided by the kernel. See
src/udev/udev-builtin-net_id.c names_mac().

> - the user has no custom /etc/udev/rules.d/80-net-setup-link.rules or
^^ incorrect
> /etc/systemd/network/99-default.link

This is an incomplete way of reimplementing udev functionality. In
particular, the user will get a different behavior if they do
$ cp /lib/systemd/network/99-default.link /etc/systemd/network/
even though the naming rules are effectively the same.

> 
> You are correct though, we do not handle the case where a user has a
> arbitrarily named .link file which is used to rename a USB device.
> 
> Fwiw, I've run into this issue myself some time ago, where I created a
> .link file which supposedly was not applied. After some head scratching
> it was then clear that the udev rule file had already renamed the interface.
> 
> My solution back then was a
> touch /etc/udev/rules.d/73-usb-net-by-mac.rules (basically what you
> figured out as well)
> 
> 
> > For example
> > ben@f3:~$ cat /etc/systemd/network/10-dock.link
> > [Match]
> > MACAddress=3c:e1:a1:01:02:03
> > 
> > [Link]
> > Name=dock
> > does not work (with the related interface being a usb adapter).
> > 
> > I believe that /lib/udev/rules.d/73-usb-net-by-mac.rules should be removed. 
> > In
> > fact, the same functionality can be provided by the systemd.link mechanism
> > while also allowing users to override the default rule. I tested this by
> > setting up
> > /etc/udev/rules.d/73-usb-net-by-mac.rules -> /dev/null
> > and adding
> > ben@f3:~$ cat /etc/systemd/network/73-usb-net-by-mac.link
> > [Match]
> > Path=*-usb-*
> > 
> > [Link]
> > NamePolicy=mac
> > 
> > (Ideally the match would be done using something like Type= but DEVTYPE is 
> > not
> > an attribute of the network device. Matching on the ID_BUS udev attribute
> > would work but is not supported by net_setup_link I think.)

I just noticed that 73-usb-net-by-mac.rules matches on
'SUBSYSTEMS=="usb"' which "[searches] the devpath upwards for a matching
device subsystem name." [udev(7)]. I think this is equivalent to the
'Path=*-usb-*' expression in the .link file I suggested.

I still think that match is not ideal, but at least its equivalent in
behavior to 73-usb-net-by-mac.rules.

> > 
> > This still used a name based on the mac address by default (instead of based
> > on the slot) and also allowed me to change the name by adding a file like 
> > the
> > 10-dock.link example above.
> 
> 
> Using a .link file is an interesting idea but afaics we can't express
> all the conditions I mentioned above.
> So we would trade one set of corner cases where it doesn't behave as
> expected with another set of corner cases.
> Not sure if we can make everyone happy.
> 
> Martin, as main author of 73-usb-net-by-mac.rules, what's your take on this?
> 
> Michael
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 





signature.asc
Description: Digital signature

Bug#894663: Raising severity of wxwidgets3.0-gtk transition blockers

[Olly Betts]

severity 933407 serious
severity 933408 serious
severity 933411 serious
severity 933412 serious
severity 933415 serious
severity 933416 serious
severity 933419 serious
severity 933424 serious
severity 933425 serious
severity 933426 serious
severity 933427 serious
severity 933431 serious
severity 933433 serious
severity 933434 serious
severity 933435 serious
severity 933438 serious
severity 933440 serious
severity 933441 serious
severity 933442 serious
severity 933445 serious
severity 933451 serious
severity 933457 serious
severity 933459 serious
severity 933462 serious
severity 933463 serious
severity 933465 serious
severity 933466 serious
severity 933469 serious
severity 933473 serious
severity 933474 serious
severity 933475 serious
severity 933476 serious
severity 933478 serious
severity 933479 serious
severity 934096 serious
severity 934097 serious
severity 934098 serious
severity 933439 serious
severity 933458 serious
thanks

> We plan to remove the wxwidgets3.0 GTK2 packages before bullseye.  Please
> test *now* if you haven't already and report any problems you find.  If
> you don't find any problems, please upload your package.
>
> The severity of remaining bugs will be raised to "serious" once known
> blockers have been addressed.

All known blockers in wxwidgets3.0 have now been addressed, so I'm
raising the severity of remaining bugs.

Cheers,
Olly

Bug#937976: python-osd: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:43:18 + Matthias Klose  wrote:
> Package: src:python-osd
> Version: 0.2.14-6.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Mauro,
what do you what to do here (i'm uncertain what to do):

* there is a possible py3k port, https://github.com/dzen/pyosd but i'm
unsure about its quality and/or if it works at all
* the popcon of this package is rather low, no reverse dependencies,
so we can just remove it as obsolete.

if i dont hear back in a week, i'll just probably go ahead and ask for
its removal from Debian.

Regards,
Sandro

Bug#941242: pymc: intention to remove this package from Debian

[Sandro Tosi]

thanks! retitle+reassing'ing now

On Thu, Sep 26, 2019 at 7:46 PM Yaroslav Halchenko  wrote:
>
> I guess it could indeed be removed, even if only to raise later from ashes as 
> pymc3
>
> Cheers
>
> On September 26, 2019 7:18:08 PM EDT, Sandro Tosi  wrote:
> >Source: pymc
> >Severity: serious
> >
> >Hello,
> >pymc is abandoned upstream and replaced by pymc3 (python3 only module),
> >https://github.com/pymc-devs/pymc3 .
> >
> >Currently pymc has a single (initial) maintainer upload, the only other
> >one
> >being a NMU, it's not in the last 2 stable releases, have 2 RCs bugs
> >unaddressed, so it's my belief we should remove this package.
> >
> >if I dont get back a good reason to keep this package in Debian withing
> >a week,
> >i will file for its removal (it has no reverse dependencies).
> >
> >Regards,
> >Sandro
> >
> >-- System Information:
> >Debian Release: 10.0
> >  APT prefers unstable-debug
> >APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> >'experimental-debug'), (1, 'experimental')
> >Architecture: amd64 (x86_64)
> >Foreign Architectures: i386
> >
> >Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
> >Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> >TAINT_UNSIGNED_MODULE
> >Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> >LANGUAGE= (charmap=UTF-8)
> >Shell: /bin/sh linked to /bin/dash
> >Init: systemd (via /run/systemd/system)
> >LSM: AppArmor: enabled
>
> --
> Yaroslav O. Halchenko (mobile version)
> Center for Open Neuroscience   http://centerforopenneuroscience.org
> Dartmouth College, NH, USA



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

Bug#941700: Update babel to version 7

[Evgeny Kapun]

Source: node-babel
Version: 6.26.0+dfsg-3
Severity: important

Babel 7 was released more than a year ago, so perhaps it's time to package the 
new version.

Bug#941699: Implement installing packages from deb files

[KOLANICH]

Package: python3-apt
Version: any

Currently it is impossible (or at least so poorly documented that I haven't 
found that) to install a package from a deb file without creating a repo.

Bug#939781: Please include Navi10 firmware files

[at46]

Since we have mesa, libdrm and kernel with Navi 10 support in Debian 
now, it would be nice to also have the firmware files available direct. 
They were added to the kernel archive at october 23rd 
(https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=417a9c6e197a8d3eec792494efc87a2b42f76324).


Axel

Bug#941698: tcpdump: CVE-2018-10103 CVE-2018-10105 CVE-2018-14461 CVE-2018-14462 CVE-2018-14463 CVE-2018-14464 CVE-2018-14465 CVE-2018-14466 CVE-2018-14467 CVE-2018-14468 CVE-2018-14469 CVE-2018-14470

[Salvatore Bonaccorso]

Source: tcpdump
Version: 4.9.3~git20190901-2
Severity: important
Tags: security upstream
Control: found -1 4.9.2-3
Control: found -1 4.9.2-1~deb9u1
Control: found -1 4.9.2-1

Hi,

The following vulnerabilities were published for tcpdump.

CVE-2018-10103[0]:
| tcpdump before 4.9.3 mishandles the printing of SMB data (issue 1 of
| 2).


CVE-2018-10105[1]:
| tcpdump before 4.9.3 mishandles the printing of SMB data (issue 2 of
| 2).


CVE-2018-14461[2]:
| The LDP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-ldp.c:ldp_tlv_print().


CVE-2018-14462[3]:
| The ICMP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-icmp.c:icmp_print().


CVE-2018-14463[4]:
| The VRRP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-vrrp.c:vrrp_print().


CVE-2018-14464[5]:
| The LMP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-lmp.c:lmp_print_data_link_subobjs().


CVE-2018-14465[6]:
| The RSVP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-rsvp.c:rsvp_obj_print().


CVE-2018-14466[7]:
| The Rx parser in tcpdump before 4.9.3 has a buffer over-read in print-
| rx.c:rx_cache_find() and rx_cache_insert().


CVE-2018-14467[8]:
| The BGP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-bgp.c:bgp_capabilities_print() (BGP_CAPCODE_MP).


CVE-2018-14468[9]:
| The FRF.16 parser in tcpdump before 4.9.3 has a buffer over-read in
| print-fr.c:mfr_print().


CVE-2018-14469[10]:
| The IKEv1 parser in tcpdump before 4.9.3 has a buffer over-read in
| print-isakmp.c:ikev1_n_print().


CVE-2018-14470[11]:
| The Babel parser in tcpdump before 4.9.3 has a buffer over-read in
| print-babel.c:babel_print_v2().


CVE-2018-14879[12]:
| The command-line argument parser in tcpdump before 4.9.3 has a buffer
| overflow in tcpdump.c:get_next_file().


CVE-2018-14880[13]:
| The OSPFv3 parser in tcpdump before 4.9.3 has a buffer over-read in
| print-ospf6.c:ospf6_print_lshdr().


CVE-2018-14881[14]:
| The BGP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-bgp.c:bgp_capabilities_print() (BGP_CAPCODE_RESTART).


CVE-2018-14882[15]:
| The ICMPv6 parser in tcpdump before 4.9.3 has a buffer over-read in
| print-icmp6.c.


CVE-2018-16227[16]:
| The IEEE 802.11 parser in tcpdump before 4.9.3 has a buffer over-read
| in print-802_11.c for the Mesh Flags subfield.


CVE-2018-16228[17]:
| The HNCP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-hncp.c:print_prefix().


CVE-2018-16229[18]:
| The DCCP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-dccp.c:dccp_print_option().


CVE-2018-16230[19]:
| The BGP parser in tcpdump before 4.9.3 has a buffer over-read in
| print-bgp.c:bgp_attr_print() (MP_REACH_NLRI).


CVE-2018-16300[20]:
| The BGP parser in tcpdump before 4.9.3 allows stack consumption in
| print-bgp.c:bgp_attr_print() because of unlimited recursion.


CVE-2018-16451[21]:
| The SMB parser in tcpdump before 4.9.3 has buffer over-reads in print-
| smb.c:print_trans() for \MAILSLOT\BROWSE and \PIPE\LANMAN.


CVE-2018-16452[22]:
| The SMB parser in tcpdump before 4.9.3 has stack exhaustion in
| smbutil.c:smb_fdata() via recursion.


CVE-2019-15166[23]:
| lmp_print_data_link_subobjs() in print-lmp.c in tcpdump before 4.9.3
| lacks certain bounds checks.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10103
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10103
[1] https://security-tracker.debian.org/tracker/CVE-2018-10105
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10105
[2] https://security-tracker.debian.org/tracker/CVE-2018-14461
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14461
[3] https://security-tracker.debian.org/tracker/CVE-2018-14462
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14462
[4] https://security-tracker.debian.org/tracker/CVE-2018-14463
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14463
[5] https://security-tracker.debian.org/tracker/CVE-2018-14464
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14464
[6] https://security-tracker.debian.org/tracker/CVE-2018-14465
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14465
[7] https://security-tracker.debian.org/tracker/CVE-2018-14466
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14466
[8] https://security-tracker.debian.org/tracker/CVE-2018-14467
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14467
[9] https://security-tracker.debian.org/tracker/CVE-2018-14468
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14468
[10] https://security-tracker.debian.org/tracker/CVE-2018-14469
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14469
[11] https://security-tracker.debian.org/tracker/CVE-2018-14470
https://cve.mitre.org/cgi-bin/cven

Bug#941697: libpcap: CVE-2018-16301 CVE-2019-15165

[Salvatore Bonaccorso]

Source: libpcap
Version: 1.9.0-2
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for libpcap.

CVE-2018-16301[0]:
| libpcap before 1.9.1, as used in tcpdump before 4.9.3, has a buffer
| overflow and/or over-read because of errors in pcapng reading.


CVE-2019-15165[1]:
| sf-pcapng.c in libpcap before 1.9.1 does not properly validate the PHB
| header length before allocating memory.


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#941696: linux-image-4.19.0-6-amd64: samsung nvme ssd enters read only mode periodically

[Lucas Zanella]

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

Dear Maintainer,

Simply using debian for a few minutes will lead to my Samsung 960 EVO 256gb
NVME M2 to enter read only mode. I also tested with a Samsung 512gb PM961 SSD
NVME M2 and I get the exact same problem, so the problem is not on the SSD.
Also, Windows will run without any problems on this computer and these 2 SSDs.
It enters read only mode mostly when there' s lots of writes going on the SSD
but can also happen out of nowhere without huge loads on the SSD. I had no
opportunity to test other SSD brands as it' s too expensive.

When the SSD enters read only mode I have to reboot and run fsck /dev/nvme0n1p2
and then reboot and the system continues to work. However this problem happens
at least 2 times a day so it' s really bad and I can' t use the system. It can
happen 10 times a day easily.

Problem is not exclusive to this exact kernel version, it also happens on other
ones.



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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
root=UUID=555feea3-608e-431b-88fb-215e25cb84dc ro quiet

** Not tainted

** Kernel log:
[4.531023] uvcvideo: Found UVC 1.00 device USB Camera (0bda:579f)
[4.545307] uvcvideo 1-7:1.0: Entity type for entity Extension 4 was not 
initialized!
[4.545309] uvcvideo 1-7:1.0: Entity type for entity Processing 2 was not 
initialized!
[4.545310] uvcvideo 1-7:1.0: Entity type for entity Camera 1 was not 
initialized!
[4.545367] input: USB Camera: USB Camera as 
/devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/input/input21
[4.565177] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
[4.565347] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[4.567538] idma64 idma64.1: Found Intel integrated DMA 64-bit
[4.579065] Bluetooth: Core ver 2.22
[4.579076] NET: Registered protocol family 31
[4.579077] Bluetooth: HCI device and connection manager initialized
[4.579080] Bluetooth: HCI socket layer initialized
[4.579081] Bluetooth: L2CAP socket layer initialized
[4.579086] Bluetooth: SCO socket layer initialized
[4.596852] usbcore: registered new interface driver uvcvideo
[4.596853] USB Video Class driver (1.1.1)
[4.601170] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb1/1-9/1-9:1.0/0003:04F3:2356.0006/input/input22
[4.601313] hid-multitouch 0003:04F3:2356.0006: input,hiddev0,hidraw5: USB 
HID v1.10 Device [ELAN Touchscreen] on usb-:00:14.0-9/input0
[4.644141] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC298: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[4.644142] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[4.644144] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[4.644144] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[4.644145] snd_hda_codec_realtek hdaudioC0D0:inputs:
[4.644146] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x18
[4.644147] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[4.657470] usbcore: registered new interface driver btusb
[4.669783] bluetooth hci0: firmware: direct-loading firmware 
qca/rampatch_usb_0302.bin
[4.669786] Bluetooth: hci0: using rampatch file: 
qca/rampatch_usb_0302.bin
[4.669788] Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware 
rome 0x302 build 0x111
[4.675569] idma64 idma64.2: Found Intel integrated DMA 64-bit
[4.704892] ath10k_pci :01:00.0: enabling device ( -> 0002)
[4.719271] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 
reset_mode 0
[4.725454] bluetooth hci0: firmware: direct-loading firmware 
qca/nvm_usb_0302.bin
[4.725457] Bluetooth: hci0: using NVM file: qca/nvm_usb_0302.bin
[4.749629] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input26
[4.750645] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input27
[4.750685] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input28
[4.750723] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input29
[4.750759] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input30
[4.750796] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input31
[4.750838] input: HDA Intel PCH HDMI/DP,pcm=9 as 
/devices/pci:00/:00:1f.3/sound/card0/input32
[4.750874] input: HDA Intel PCH HDMI/DP,pcm=10 as 
/devices/pci:00/:00:1f.3/sound/card0/input33
[4.768911] audit: type=1400 audit(1570137356.811:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/mysqld-akonadi" 
pid=495 comm="a

Bug#941695: cardpeek: Broken link in manual page

[Ben Hutchings]

Package: cardpeek
Version: 0.8.4-1+b5
Severity: minor

cardpeek(1) refers to:

   PDF documentation cardpeek_ref.en.pdf available online here:

   http://cardpeek.googlecode.com/files/cardpeek_ref.en.pdf

but that (along with the rest of googlecode.com) is no longer
available.

Ben.

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

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

Versions of packages cardpeek depends on:
ii  cardpeek-data0.8.4-1
ii  libatk1.0-0  2.33.3+really2.32.0-4
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcurl4 7.65.3-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgtk-3-0   3.24.10-1
ii  liblua5.2-0  5.2.4-1.1+b3
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpcsclite1 1.8.25-2
ii  libreadline8 8.0-3
ii  libssl1.11.1.1c-1

cardpeek recommends no packages.

Versions of packages cardpeek suggests:
ii  pcscd  1.8.25-2

-- no debconf information

Bug#941694: ocsinventory-agent: Can the OCSInventory Cron be brought inline with upstream?

[Pat Riehecky]

Package: ocsinventory-agent
Version: 2:2.4.2-3
Severity: wishlist

Dear Maintainer,
The official OCSInventory RPMs (http://rpm.ocsinventory-ng.org/) include a 
cronjob to run the agent in a defined manner.

As part of my maintenance of the Fedora OCS Inventory Agent, I opened a PR 
against the official sources 
(https://github.com/OCSInventory-NG/UnixAgent/pull/223)

Could Ubuntu's OCS Inventory Package include this updated script and timers? 
This would simplify my management of OCS when bouncing between 
Fedora/CentOS/Ubuntu.

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

Kernel: Linux 3.10.0-1062.1.1.el7.x86_64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages ocsinventory-agent depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  fdisk  2.33.1-0.1
ii  libc6  2.28-10
ii  libcrypt-ssleay-perl   0.73.06-1+b1
ii  libnet-ip-perl 1.26-2
ii  libproc-daemon-perl0.23-1
ii  libwww-perl6.36-2
ii  libxml-simple-perl 2.25-1
ii  perl   5.28.1-6
ii  ucf3.0038+nmu1
ii  util-linux 2.33.1-0.1

Versions of packages ocsinventory-agent recommends:
ii  dmidecode   3.2-1
ii  e2fsprogs   1.44.5-1+deb10u1
ii  hdparm  9.58+ds-1
ii  libio-socket-ssl-perl   2.060-3
ii  liblwp-protocol-https-perl  6.07-2
ii  libnet-cups-perl0.64-1+b1
ii  libnet-netmask-perl 1.9104-1
ii  libnet-snmp-perl6.0.1-5
ii  libparse-edid-perl  1.0.7-1
ii  pciutils1:3.5.2-1

Versions of packages ocsinventory-agent suggests:
pn  libnmap-parser-perl  
pn  nmap 
pn  read-edid
pn  smartmontools

-- debconf information excluded

Bug#941637: linux-image-4.19.0-6-amd64: noht flag on command line has no effect for 6 core/12 Thread Ryzens

[Anton Ivanov]

On 03/10/2019 16:06, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

Hi

On Thu, Oct 03, 2019 at 09:24:26AM +0100, Anton Ivanov wrote:

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

Dear Maintainer,

noht has no effect.

I have been trying to chase down a weird hang which occurs only on 6
core/12 thread Ryzens (I cannot reproduce it on 4/8 or older CPUs).

As a part of that I tried to disable ht. Well, it cannot be disabled
- the noht command line arg has no effect whatosever.

As ht can be a security hole this may have security implications as
well.

Do you mean 'nosmt'? (See kernel-parameters.txt).

You can find further information as well in
Documentation/admin-guide/hw-vuln/l1tf.rst.


I picked up noht from an older document somewhere and I cannot remember 
the actual source. It was definitely in the older version of RHEL 
guides, etc.


I can see that the parameter is nosmt now.

You can close the bug.



Regards,
Salvatore



--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#941665: [Pkg-openssl-devel] Bug#941688: openssl 1.1.1d security update breaks openssh login on old kernels

[Kurt Roeckx]

On Thu, Oct 03, 2019 at 07:56:54PM +, Sylvain Rochet wrote:
> 
> Dear Maintainer,
> 
> Upgrading from openssl 1.1.1c-1 to openssl 1.1.1d-0+deb10u1 on Debian 
> Buster breaks openssh login on systems running old kernels (3.16.x at 
> least).
> 
> This is due to the missing getrandom syscall on those kernels and 
> seccomp filter triggering on fallback implementation of the missing 
> syscall, reverting to 1.1.1c-1 fixes the issue.
> 
> This is currently being discussed upstream at:
>   https://github.com/openssl/openssl/issues/9984
> 
> It only affects old kernels so it's no big deal anyway.

The getrandom() system call is available from version 3.19. You
will only run into this if you're running an older kernel that
doesn't provide getrandom().

I think this is really an openssh problem, not openssl problem.
It's one of the downsides of using seccomp that one of the
libraries you're using might start to do new calls.


Kurt

Bug#941693: sagenb: No Python3 version of python-sagenb

[Rann Bar-On]

Source: sagenb
Version: 1.1..2+ds1-1
Severity: important

Dear Maintainer,

Since Debian's sage is now Python 3 based, we need a python3-sagenb for the 
notebook to work.

Right now, since there is no such package, sage -notebook or notebook() in Sage 
itself fails with 'No module named 'sagenb'.

Thank you!

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (800, 'testing'), (750, 'unstable'), (500, 'unstable-debug'), 
(500, 'testing-debug'), (500, 'stable-updates'), (500, 'proposed-updates'), 
(500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#935753: FATAL:memory_linux.cc Out of memory

[Mikhail Morfikov]

Package: chromium
Version: 76.0.3809.100-1
Followup-For: Bug #935753

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It looks like the problem is in the libgl1-mesa-dri package as described here:
https://bugs.archlinux.org/task/63945

Currently, the 19.2.0-1 version is in SID, which causes the OOM issue.
Downgrading it to 19.1.6-1
fixes the problem.



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

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

Versions of packages chromium depends on:
ii  chromium-common  76.0.3809.100-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.34.0-3
ii  libatk1.0-0  2.34.0-1
ii  libatomic1   9.2.1-8
ii  libatspi2.0-02.34.0-3
ii  libavcodec58 7:4.1.4-1+b2
ii  libavformat587:4.1.4-1+b2
ii  libavutil56  7:4.1.4-1+b2
ii  libc62.29-2
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.3.0-5
ii  libdbus-1-3  1.12.16-2
ii  libdrm2  2.4.99-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.9-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-8
ii  libgdk-pixbuf2.0-0   2.38.2+dfsg-1
ii  libglib2.0-0 2.62.0-3
ii  libgtk-3-0   3.24.11-1
ii  libharfbuzz0b2.6.2-1
ii  libicu63 63.2-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3+b1
ii  liblcms2-2   2.9-4
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.21-2
ii  libnss3  2:3.45-1
ii  libopenjp2-7 2.3.0-3
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpci3  1:3.6.2-2
ii  libpng16-16  1.6.37-1
ii  libpulse013.0-1
ii  libre2-5 20190901+dfsg-1
ii  libsnappy1v5 1.1.7-1+b1
ii  libstdc++6   9.2.1-8
ii  libvpx6  1.8.1-2
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.8-1
ii  libx11-xcb1  2:1.6.8-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages chromium recommends:
ii  chromium-sandbox  76.0.3809.100-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox76.0.3809.100-1
ii  fonts-liberation1:1.07.4-10
ii  libgl1-mesa-dri 19.1.6-1
pn  libu2f-udev 
ii  plasma-workspace [notification-daemon]  4:5.14.5.1-2
pn  system-config-printer   
ii  upower  0.99.11-1
ii  xfce4-notifyd [notification-daemon] 0.4.4-1+b1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  9.2.1-8
ii  libc6   2.29-2
ii  libgcc1 1:9.2.1-8
ii  libstdc++6  9.2.1-8




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAl2WXAIACgkQzQRoEHcb
ZSC6YxAAvYUZPPEKAFZ6iaIU+Yz2pU9QOhNPApy6inM1oU/KGkZRuF1LOJ0wlbbW
kJSERKuXZOvbAETYzhUHETEUVzW5rxjvdbJNzbkjwxXKdaHwP7TNjC1xS9BjBBgn
Pf3/yo5L9PQNNH5ahokk4AE386fB4RXk9mJCz3x9yERO3W/ilSFDIHOefz0BWoxa
osGkbpG5yS4QxvyiE73ExgKp2moIweChc8XNWGPHC/hByeQ71o3ev07Q+vHlWeAT
35ijik6YOZg82UpDDL7ezs62jmYOCXpzZQ4LMvujT8AcONNqz6s42aDKyKAvc9QI
fsvQbCUY3Cn2Oth2NK+Er04ZGLQv4dzf9Kh11V+ZSfZjTW9poBQTNMgObAedWuGj
eYnEFmawDpq3fClDKWUMRjk8Qq1/m5CJzdm7xfNWxPoMZZzU835/21nOJLCYGskU
KZGJaFP00bFVmclYBAR7rVacBbQHZXVxefbRUeD0PQhDxNgjDH9/F82jEvUjtrBW
kC/KW6TRfvNCk+KAM3QzjRE6GvbK79pwu7IghLaKV9mTKr7Yn6bD2GIE5G0GIipW
llrOp2c5i/a3dV44oyIH6QJHBwue03vhqtJMaOmyJTJjiYAPzPNQgjc6HXZI1qTf
SA5UmzOei2VXIdfbE8elDHRYt2AUtura/2vwcaaU/hjcbndfLIA=
=8PIL
-END PGP SIGNATURE-

Bug#941692: unbound: CVE-2019-16866

[Salvatore Bonaccorso]

Source: unbound
Version: 1.9.3-1
Severity: important
Tags: security upstream
Control: found -1 1.9.0-2

Hi,

The following vulnerability was published for unbound.

CVE-2019-16866[0]:
| Unbound before 1.9.4 accesses uninitialized memory, which allows
| remote attackers to trigger a crash via a crafted NOTIFY query. The
| source IP address of the query must match an access-control rule.


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-16866
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16866
[1] https://nlnetlabs.nl/downloads/unbound/CVE-2019-16866.txt

Please adjust the affected versions in the BTS as needed. If I checked
correctly, then this issue was really only introduced upstream in
1.7.1, thus not affecting stretch. Please double-check.

Regards,
Salvatore

Bug#941654: [Pkg-samba-maint] Bug#941654: samba: Upgrading to 4.11.0 pulls in glib, dconf and systemd packages by enabling spotlight feature

[Mathieu Parent]

Le jeu. 3 oct. 2019 à 13:21, Elimar Riesebieter  a écrit :
>
> Package: samba
> Version: 2:4.11.0+dfsg-8
> Severity: normal

Hi,

> Upgrading to 4.11.0+dfsg-8 pulls in by enabling spotlight feature::
>
> The following packages will be REMOVED:
>   libldb1 sysvinit-core
> The following NEW packages will be installed:
>   dbus-user-session dconf-gsettings-backend dconf-service glib-networking 
> glib-networking-common glib-networking-services gsettings-desktop-schemas 
> libargon2-1 libcryptsetup12 libdconf1 libjson-glib-1.0-0
>   libjson-glib-1.0-common libldb2 libpam-systemd libproxy1v5 libsoup2.4-1 
> libtracker-sparql-2.0-0 systemd systemd-sysv
> The following packages will be upgraded:
>   ldb-tools libwbclient0 python3-ldb python3-samba samba samba-common 
> samba-common-bin samba-dsdb-modules samba-libs samba-vfs-modules winbind
> 11 upgraded, 19 newly installed, 2 to remove and 0 not upgraded.

Yes:
# aptitude why libglib2.0-0
i   samba  Depends samba-libs (= 2:4.11.0+dfsg-8)
i A samba-libs Depends libglib2.0-0 (>= 2.16.0)

# ldd /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0 | grep glib
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7f35b0ad8000)
libjson-glib-1.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 (0x7f35aff06000)

$ git grep ifdef.HAVE_GLIB
source3/lib/tevent_glib_glue.c:#ifdef HAVE_GLIB

$ cat source3/wscript
# ...
if conf.CONFIG_SET('HAVE_GLIB'):
conf.DEFINE('WITH_TEVENT_GLIB_GLUE', '1')
# ...

> Neither the dconf nor the glib packages are needed to run a headless
> server. Hence systemd isn't wanted from me on a headless server.

Agree.

> It should be possible to package the spotlight feature in a separate
> package, though.

This is in samba-libs, and harder to fix probably.

Will take a look...

> Thanks
> --
> Elimar
>
> ___
> Pkg-samba-maint mailing list
> pkg-samba-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-samba-maint



-- 
Mathieu

Bug#941691: live-build: apt-get fails for added repositories if local packages present

[John Estabrook]

Package: live-build
Version: 1:20190311
Severity: important
Tags: patch

Dear Maintainer,

The reported bug occurs in the following setting: when building a Debian Buster
release with additional packages from added (non-debian) repositories _and_
packages residing locally. When those two conditions hold, chroot_archives will
add repo lists, and then configure local packages, calling 'Apt chroot update',
before adding the public keys for those repos. This error is obscured by the
sequence of cache/restore until the binary stage, when chroot is restored from
cache/bootstrap.

This same issue occurred with Jessie and Stretch releases, however, it only
resulted in a warning; the warning was changed to failing in apt 1.5.

Patch provided by following merge request:

https://salsa.debian.org/live-team/live-build/merge_requests/30

-- Package-specific info:

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

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

Versions of packages live-build depends on:
ii  debootstrap  1.0.114

Versions of packages live-build recommends:
ii  apt-utils   1.8.2
ii  bzip2   1.0.6-9.2~deb10u1
ii  cpio2.12+dfsg-9
ii  file1:5.35-4
ii  live-boot-doc   1:20190614
ii  live-config-doc 5.20190519
ii  live-manual-html [live-manual]  2:20151217.1
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages live-build suggests:
ii  e2fsprogs  1.44.5-1+deb10u2
pn  mtd-utils  
ii  parted 3.2-25

-- no debconf information

Bug#941690: RFS: clipf/0.6-1 -- command line minimalistic personal finance manager

[Adam Bilbrough]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: clipf
   Version : 0.6-1
   Upstream Author : Adam Bilbrough 
 * URL : https://github.com/atsb/clipf
 * License : GPL-2+
 * Vcs : None
   Section : misc

It builds those binary packages:

  clipf - command line minimalistic personal finance manager

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/c/clipf/clipf_0.6-1.dsc

Changes since the last upload:

   * New upstream release.
   * debian/control:
   - Updated to Standards-version 4.4.1.

Regards,

--
  Adam Bilbrough

Bug#941689: RFS: git-quick-stats/2.0.9-1 ITP

[Birger Schacht]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "git-quick-stats"

* Package name : git-quick-stats
  Version  : 2.0.9-1
  Upstream Author  : Lukáš Mešťan
* Url  : https://github.com/arzzen/git-quick-stats
* Licenses : Expat
  Programming Lang : Bash
  Section  : utils

 Git quick statistics is a simple and efficient way to access various
 statistics in git repository.

It builds those binary packages:

  * git-quick-stats

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

https://mentors.debian.net/package/git-quick-stats

Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/g/git-quick-stats/git-quick-stats_2.0.9-1.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://salsa.debian.org/bisco-guest/git-quick-stats.git

More information about git-quick-stats can be obtained from
https://github.com/arzzen/git-quick-stats


Regards,
  Birger Schacht

Bug#941688: openssl 1.1.1d security update breaks openssh login on old kernels

[Sylvain Rochet]

Package: openssl
Version: 1.1.1d-0+deb10u1
Severity: minor
Tags: upstream

Dear Maintainer,

Upgrading from openssl 1.1.1c-1 to openssl 1.1.1d-0+deb10u1 on Debian 
Buster breaks openssh login on systems running old kernels (3.16.x at 
least).

This is due to the missing getrandom syscall on those kernels and 
seccomp filter triggering on fallback implementation of the missing 
syscall, reverting to 1.1.1c-1 fixes the issue.

This is currently being discussed upstream at:
  https://github.com/openssl/openssl/issues/9984

It only affects old kernels so it's no big deal anyway.

Regards,
Sylvain

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

Kernel: Linux 3.16.74 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages openssl depends on:
ii  libc6  2.28-10
ii  libssl1.1  1.1.1d-0+deb10u1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20190110

-- no debconf information

Bug#935737: transition: perl

[Dominic Hargreaves]

On Thu, Oct 03, 2019 at 01:05:02PM +0200, Paul Gevers wrote:
> Hi Niko, Dom,
> 
> On 25-08-2019 20:39, Niko Tyni wrote:
> > Please let us know when we might get a transition slot.  Both of us
> > are currently rather taken by real life stuff, so would appreciate an
> > advance warning if possible.
> 
> As discussed on IRC, if you are ready to go in a couple of days (let
> say, 5), we can start, otherwise please let us know and we can continue
> with other transitions first.

Hello

Yes, I am able to cut a release and upload on Saturday (morning Europe
time).

Cheers
Dominic.

Bug#939807: sbcl build-depends on package that is cruft in unstable and gone in testing.

[Sébastien Villemot]

Hi Steve,

Le mardi 01 octobre 2019 à 14:58 -0700, Steve Langasek a écrit :
> Package: sbcl
> Followup-For: Bug #939807
> User: ubuntu-de...@lists.ubuntu.com
> 
> Usertags: origin-ubuntu eoan ubuntu-patch
> 
> Dear maintainers,
> 
> Attached is a straightforward patch for this issue.

Note that this issue had already been fixed in Debian. It looks like
sbcl in Ubuntu is out-of-sync.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org



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

Bug#941686: backintime-qt: Version 1.2.1-1 has wrong dependency on qt4 python3-dbus.mainloop

[Michael Weghorn]

Package: backintime-qt
Version: 1.2.1-1
Severity: normal
Tags: patch

Dear Maintainer,

backintime 1.2.1-1, which is currently in the NEW queue, switched from
Qt 4 to Qt 5.

However, the package still declares a (wrong) dependency on the qt4-based 
package
'python3-dbus.mainloop.qt', which should be replaced by the qt5 version,
'python3-dbus.mainloop.pyqt5' that is now being used.

Best regards,
Michael

PS: Thanks for packaging the new version!


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 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)

Versions of packages backintime-qt depends on:
ii  backintime-common1.2.1-1
ii  libnotify-bin0.7.8-1
ii  policykit-1  0.105-26
ii  python3  3.7.3-1
ii  python3-dbus.mainloop.pyqt5  5.12.3+dfsg-2
ii  python3-pyqt55.12.3+dfsg-2
ii  x11-utils7.7+4

Versions of packages backintime-qt recommends:
ii  python3-secretstorage  2.3.1-2

Versions of packages backintime-qt suggests:
ii  meld  3.20.0-2

-- no debconf information
>From 4d9751c7d215ebdd56f14239d6edfd0e1db78b19 Mon Sep 17 00:00:00 2001
From: Michael Weghorn 
Date: Thu, 3 Oct 2019 21:26:56 +0200
Subject: [PATCH] d/control: Update python3-dbus.mainloop dep for qt5

Package 'python3-dbus.mainloop.qt' is the qt4 version,
while backintime now uses qt5.

To demonstrate the issue:

$ python3 /usr/share/backintime/qt/serviceHelper.py
Traceback (most recent call last):
  File "/usr/share/backintime/qt/serviceHelper.py", line 74, in 
import dbus.mainloop.pyqt5
ModuleNotFoundError: No module named 'dbus.mainloop.pyqt5'
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 9a19da2..6ea3eee 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,7 @@ Architecture: all
 Breaks: backintime-kde (<< 1.1.6-1~), backintime-gnome (<< 1.1.6-1~), 
backintime-qt4 (<< 1.2.1-0.1~)
 Replaces: backintime-kde (<< 1.1.6-1~), backintime-gnome (<< 1.1.6-1~), 
backintime-kde4, backintime-qt4 (<< 1.2.1-0.1~)
 Conflicts: backintime-kde4
-Depends: x11-utils, libnotify-bin, python3-pyqt5, python3-dbus.mainloop.qt, 
policykit-1,
+Depends: x11-utils, libnotify-bin, python3-pyqt5, python3-dbus.mainloop.pyqt5, 
policykit-1,
  backintime-common (= ${source:Version}), ${python3:Depends}, ${misc:Depends}
 Recommends: python3-secretstorage
 Suggests: meld | kompare
-- 
2.23.0

Bug#940136: aqbanking-tools: Transaction fails with 9075::Starke Kundenauthentifizierung notwendig.

[Martin Steigerwald]

Dear Micha.

Micha Lenk - 03.10.19, 20:27:48 CEST:
> I started to look into updating AqBanking in Debian again. It all
> starts with uploading Gwenhywfar, which I did a few days ago. As
> usual when binary package names change (in this case required due to
> the soname bump), the package is currently stalled in the NEW queue.
> https://ftp-master.debian.org/new/libgwenhywfar_4.99.19rc3-1.html
> 
> So we will need some patience now.

Thank you very much. Looking forward to it.

Best,
-- 
Martin

Bug#926809: closed by "Dmitry V. Levin" (Re: strace: Allow dumping full detail of fstat and getdents/getdents64 syscalls)

[Witold Baryluk]

Hi Dmitry.

Yes, `strace -v`, and `strace -e abbrev=none`, which are basically the
same thing, works.

Thank you,
and sorry for wasting your time on this.

I have no idea how I missed it in the manual.

Cheers,
Witold


czw., 3 paź 2019 o 02:03 Debian Bug Tracking System
 napisał(a):
>
> This is an automatic notification regarding your Bug report
> which was filed against the strace package:
>
> #926809: strace: Allow dumping full detail of fstat and getdents/getdents64 
> syscalls
>
> It has been closed by "Dmitry V. Levin" .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact "Dmitry V. Levin" 
>  by
> replying to this email.
>
>
> --
> 926809: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926809
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Dmitry V. Levin" 
> To: 926809-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 3 Oct 2019 04:56:08 +0300
> Subject: Re: strace: Allow dumping full detail of fstat and 
> getdents/getdents64 syscalls
>
> tags 926809 notabug
> thanks
>
> On Wed, Apr 10, 2019 at 05:43:03PM +, Witold Baryluk wrote:
> > Package: strace
> > Version: 4.26-0.2
> > Severity: normal
> >
> > ...
> > fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> > getdents64(3, /* 35 entries */, 32768)  = 1104
> > fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x7), ...}) = 0
> > ...
> >
> >
> > I tried fidling with -X verbose, -e verbose=%desc, and others, and it
> > still hides some details behind ... and in /* 35 entries */.
> >
> >
> > AFAIK, for things like select/poll/epoll_wait, that also return complex
> > variable length structures, strace shows them fully and reasonably nicely
> > (not sure if they do work with -y option, maybe...).
> >
> > I want to be able to see detail of all getdents64 entries, including
> > entry order as they are returned by kernel, d_type, and the exact filename 
> > string
> > positions in memory, and the d_reclen, d_off values.
>
> Consider using -v or -e abbrev=set for more fine-grained control.
>
>
> --
> ldv
>
>
> -- Forwarded message --
> From: Witold Baryluk 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 10 Apr 2019 17:43:03 +
> Subject: strace: Allow dumping full detail of fstat and getdents/getdents64 
> syscalls
> Package: strace
> Version: 4.26-0.2
> Severity: normal
>
> ...
> fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> getdents64(3, /* 35 entries */, 32768)  = 1104
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x7), ...}) = 0
> ...
>
>
> I tried fidling with -X verbose, -e verbose=%desc, and others, and it
> still hides some details behind ... and in /* 35 entries */.
>
>
> AFAIK, for things like select/poll/epoll_wait, that also return complex
> variable length structures, strace shows them fully and reasonably nicely
> (not sure if they do work with -y option, maybe...).
>
> I want to be able to see detail of all getdents64 entries, including
> entry order as they are returned by kernel, d_type, and the exact filename 
> string
> positions in memory, and the d_reclen, d_off values.
>
>
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages strace depends on:
> ii  libc6   2.28-8
> ii  libunwind8  1.2.1-8
>
> strace recommends no packages.
>
> strace suggests no packages.
>
> -- no debconf information



-- 
Witold Baryluk
My PGP keys for 2017-02-17 - 2019-02-17:
5B8C 48CB 8B2F CF53 CA55  0995 16D9 6FA2 20A8 F130
https://functor.xyz/pgp/witold.baryluk-gmail.gpg.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=0x16D96FA220A8F130

Bug#934630: transition: octave

[Sébastien Villemot]

Le jeudi 03 octobre 2019 à 09:14 +0200, Paul Gevers a écrit :

> Octave has now been built everywhere. Will you take care of all the
> failures in the reverse build depends? There are 16 packages that need
> your attention before octave can migrate. I filed one FTBFS bug already,
> but waiting for autoremoval isn't the way forward.

I intend to work on the failures, beginning with the packages are not
maintained by the Debian Octave Group (since their maintainers are not
responsible for the situation). Clearly there are more failures than I
had anticipated, but that should still be manageable.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org



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

Bug#941684: multimon FTCBFS: compiles code generator with host architecture compiler

[Helmut Grohne]

Source: multimon
Version: 1.0-7.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

multimon fails to cross build from source, because it fails running the
code generator mkcostab as it is built with the host architecture
compiler. Please consider applying the attached patch to use the build
architecture compiler for that step.

Helmut
diff --minimal -Nru multimon-1.0/debian/changelog multimon-1.0/debian/changelog
--- multimon-1.0/debian/changelog   2015-07-20 19:58:21.0 +0200
+++ multimon-1.0/debian/changelog   2019-10-03 21:06:30.0 +0200
@@ -1,3 +1,10 @@
+multimon (1.0-7.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Compile mkcostab.c with the build architecture compiler. 
(Closes: #-1)
+
+ -- Helmut Grohne   Thu, 03 Oct 2019 21:06:30 +0200
+
 multimon (1.0-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru multimon-1.0/debian/patches/cross.patch 
multimon-1.0/debian/patches/cross.patch
--- multimon-1.0/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ multimon-1.0/debian/patches/cross.patch 2019-10-03 21:05:40.0 
+0200
@@ -0,0 +1,23 @@
+--- multimon-1.0.orig/Makefile
 multimon-1.0/Makefile
+@@ -32,8 +32,8 @@
+ AS=as
+ LD=ld
+ LDFLAGS   +=-lm
+-HOSTCC=gcc
+ CC=gcc
++CC_FOR_BUILD?= $(CC)
+ MAKE  =make
+ CPP   =$(CC) -E
+ AR=ar
+@@ -75,8 +75,8 @@
+ $(BINDIR)/gen:$(OBJ_GEN)
+   $(CC) $^ $(LDFLAGS) -o $@
+ 
+-$(BINDIR)/mkcostab:   $(BINDIR)/mkcostab.o
+-  $(CC) $^ $(LDFLAGS) -o $@
++$(BINDIR)/mkcostab:   mkcostab.c
++  $(CC_FOR_BUILD) $^ -lm -o $@
+ 
+ costabi.c costabf.c:  $(BINDIR)/mkcostab
+   $(BINDIR)/mkcostab
diff --minimal -Nru multimon-1.0/debian/patches/series 
multimon-1.0/debian/patches/series
--- multimon-1.0/debian/patches/series  2013-11-17 22:01:53.0 +0100
+++ multimon-1.0/debian/patches/series  2019-10-03 21:03:43.0 +0200
@@ -7,3 +7,4 @@
 quiet-output.patch
 fix-stereo.patch
 ccir-added.patch
+cross.patch
diff --minimal -Nru multimon-1.0/debian/rules multimon-1.0/debian/rules
--- multimon-1.0/debian/rules   2015-07-20 19:57:51.0 +0200
+++ multimon-1.0/debian/rules   2019-10-03 21:06:28.0 +0200
@@ -1,6 +1,10 @@
 #!/usr/bin/make -f
 
 export DEB_CFLAGS_MAINT_APPEND=-fgnu89-inline
+include /usr/share/dpkg/buildtools.mk
 
 %:
dh $@
+
+override_dh_auto_build:
+   dh_auto_build -- 'CC_FOR_BUILD=$(CC_FOR_BUILD)'

Bug#940631: ITP: primus-vk -- Vulkan layer for GPU offloading

[Luca Boccassi]

On Wed, 18 Sep 2019 08:09:43 +0200 =?utf-8?q?Felix_D=C3=B6rre?= <
deb...@felixdoerre.de
> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Felix Dörre <
deb...@felixdoerre.de
>
> 
> * Package name: primus-vk
>   Version : 1.2.z
>   Upstream Author : Felix Dörre <
deb...@felixdoerre.de
>
> * URL : 
https://github.com/felixdoerre/primus_vk

> * License : BSD-2-clause
>   Programming Lang: C++
>   Description : Vulkan layer for GPU offloading
> 
> Typically you want to display an image rendered on a more powerful
> GPU on a display managed by an internal GPU. The layer in this
package will
> direct rendering commands to a dedicated, more powerful GPU an when
such an
> image is displayed it will be copied to the integrated CPU for
displaying.
> 
> This software seems already fit for several people's needs and
handles most
> games/applications perfectly.

Hello Andreas,

This can be useful for older cards that will not get native support for
optimus in the 435 series and up, so I intend to sponsor it.

Is it OK for you if I put this in the nvidia-team section on Salsa and
so on?

-- 
Kind regards,
Luca Boccassi


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

Bug#941683: buster-pu: package node-yarnpkg/1.13.0-1+deb10u1

[Xavier Guimard]

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

Hi,

node-yarnpkg is vulnerable: it exports auth data in http requests
(#941354, CVE-2019-5448). This patch imports upstream fix.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index 01fe7d70d..6c4b5fef1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-yarnpkg (1.13.0-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Add patch to force using https for the regular registries
+(Closes: #941354, CVE-2019-5448)
+
+ -- Xavier Guimard   Thu, 03 Oct 2019 18:23:54 +0200
+
 node-yarnpkg (1.13.0-1) unstable; urgency=low
 
   * Initial release (Closes: #843021)
diff --git a/debian/patches/CVE-2019-5448.diff 
b/debian/patches/CVE-2019-5448.diff
new file mode 100644
index 0..8bb7442c8
--- /dev/null
+++ b/debian/patches/CVE-2019-5448.diff
@@ -0,0 +1,75 @@
+Description: Forces using https for the regular registries
+Author: Maël Nison 
+Origin: upstream, https://github.com/yarnpkg/yarn/commit/2f08a740
+Bug: https://hackerone.com/reports/640904
+Bug-Debian: https://bugs.debian.org/941354
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-10-03
+
+--- a/__tests__/registries/npm-registry.js
 b/__tests__/registries/npm-registry.js
+@@ -750,6 +750,30 @@
+ 
+ expect(npmRegistry.getRequestUrl(registry, 
pathname)).toEqual('https://my.registry.co/registry/foo/bar/baz');
+   });
++
++  for (const host of [`registry.yarnpkg.com`, `registry.npmjs.org`, 
`registry.npmjs.com`]) {
++test(`enforces loading packages through https when they come from 
${host}`, () => {
++  const testCwd = '.';
++  const {mockRequestManager, mockRegistries, mockReporter} = 
createMocks();
++  const npmRegistry = new NpmRegistry(testCwd, mockRegistries, 
mockRequestManager, mockReporter, true, []);
++  const registry = `http://${host}/registry`;
++  const pathname = 'foo/bar/baz';
++
++  expect(npmRegistry.getRequestUrl(registry, 
pathname)).toEqual(`https://${host}/registry/foo/bar/baz`);
++});
++  }
++
++  test("doesn't change the protocol for packages from other registries", () 
=> {
++const testCwd = '.';
++const {mockRequestManager, mockRegistries, mockReporter} = createMocks();
++const npmRegistry = new NpmRegistry(testCwd, mockRegistries, 
mockRequestManager, mockReporter, true, []);
++const registry = 'http://registry.mylittlepony.org/registry';
++const pathname = 'foo/bar/baz';
++
++expect(npmRegistry.getRequestUrl(registry, pathname)).toEqual(
++  'http://registry.mylittlepony.org/registry/foo/bar/baz',
++);
++  });
+ });
+ 
+ describe('getScope functional test', () => {
+--- a/src/registries/npm-registry.js
 b/src/registries/npm-registry.js
+@@ -22,6 +22,7 @@
+ import ini from 'ini';
+ 
+ const DEFAULT_REGISTRY = 'https://registry.npmjs.org/';
++const REGEX_REGISTRY_ENFORCED_HTTPS = 
/^https?:\/\/([^\/]+\.)?(yarnpkg\.com|npmjs\.(org|com))(\/|$)/;
+ const REGEX_REGISTRY_HTTP_PROTOCOL = /^https?:/i;
+ const REGEX_REGISTRY_PREFIX = /^(https?:)?\/\//i;
+ const REGEX_REGISTRY_SUFFIX = /registry\/?$/;
+@@ -112,13 +113,17 @@
+   }
+ 
+   getRequestUrl(registry: string, pathname: string): string {
+-const isUrl = REGEX_REGISTRY_PREFIX.test(pathname);
++let resolved = pathname;
+ 
+-if (isUrl) {
+-  return pathname;
+-} else {
+-  return url.resolve(addSuffix(registry, '/'), pathname);
++if (!REGEX_REGISTRY_PREFIX.test(pathname)) {
++  resolved = url.resolve(addSuffix(registry, '/'), pathname);
+ }
++
++if (REGEX_REGISTRY_ENFORCED_HTTPS.test(resolved)) {
++  resolved = resolved.replace(/^http:\/\//, 'https://');
++}
++
++return resolved;
+   }
+ 
+   isRequestToRegistry(requestUrl: string, registryUrl: string): boolean {
diff --git a/debian/patches/series b/debian/patches/series
index f3c856f99..7c03222a8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@
 08-cli-table3.diff
 09-buffer_from.diff
 10-babel-plugin-inline-import.diff
+CVE-2019-5448.diff

Bug#941354: node-yarnpkg: CVE-2019-5448

[Salvatore Bonaccorso]

Hi Xavier,

On Thu, Oct 03, 2019 at 06:27:40PM +0200, Xavier wrote:
> Hi,
> 
> I don't know if you want to DSA this bug. Anyway here is the patch.

I think we can have this schedule via next point releases as well.

Regards,
Salvatore

Bug#940136: aqbanking-tools: Transaction fails with 9075::Starke Kundenauthentifizierung notwendig.

[Micha Lenk]

Hi all,

I started to look into updating AqBanking in Debian again. It all starts 
with uploading Gwenhywfar, which I did a few days ago. As usual when 
binary package names change (in this case required due to the soname 
bump), the package is currently stalled in the NEW queue.

https://ftp-master.debian.org/new/libgwenhywfar_4.99.19rc3-1.html

So we will need some patience now.

Regards,
Micha

Bug#941618: torus-trooper: fails to start with "undefined symbol" error

[Peter De Wachter]

This isn't just torus-trooper, many other libgphobos reverse
dependencies are affected:

dustmite
gunroar
mu-cade
parsec47
projectl
titanion
torus-trooper
tumiki-fighters
val-and-rick

On Thu, Oct 3, 2019 at 6:36 PM Stephen Kitt  wrote:
>
> Hi Matthias,
>
> Le 02/10/2019 23:37, Cédric Boutillier a écrit :
> > I've just installed the game and tried to launch it from the terminal:
> > I got the following error message:
> >
> > torus-trooper: symbol lookup error: torus-trooper: undefined symbol:
> > _D4core4stdc5errno5errnoFNbNdNiNeZ
>
> This is a symbol in libgdruntime.so.76.0.2 which is no longer present in
> libgdruntime.so.76.0.3. It does look like an internal symbol, but
> binaries apparently end up with references to it, so binaries built with
> the GCC 8 version can break with the GCC 9 version...
>
> Should this be fixed in GCC, or by binNMUing?
>
> Regards,
>
> Stephen
>

Bug#941093: transition: qtbase-opensource-src

[Dmitry Shachnev]

Version: 5.0.1-1

Hi Boyan,

On Thu, Oct 03, 2019 at 02:10:49PM -0400, Boyuan Yang wrote:
> Just FYI: I've updated deepin-qt5dxcb-plugin to make it compatible with Qt
> 5.12.5 so It won't be a blocker for this transition. Let me know if there's
> any other issues.

Thank you! I think we can close bug #935105 now.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#941681: wine: Run msiexec /i, automatically when calling wine xyz.msi

[Witold Baryluk]

Package: wine
Version: 4.0.2-1
Severity: normal

I find needing to know about existence of msiexec /i, somehow painful, 
especially
to wine newcomers.

I expect calling wine xyz.msi, to be equivalent to double clicking a msi file on
Windows, aka launching installer automatically. Should be easy to support.
At the moment wine just says: "wine: Bad EXE format for Z:\\xyz.msi",
which isn't helpful.


-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

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

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

Versions of packages wine depends on:
ii  wine32  4.0.2-1
ii  wine64  4.0.2-1

wine recommends no packages.

Versions of packages wine suggests:
ii  dosbox   0.74-3-1
ii  exe-thumbnailer  0.10.0-3
pn  playonlinux  
pn  q4wine   
ii  winbind  2:4.10.8+dfsg-1
pn  wine-binfmt  
ii  winetricks   0.0+20190912-1

Versions of packages wine is related to:
ii  fonts-wine  4.0.2-1
ii  wine4.0.2-1
ii  wine32  4.0.2-1
ii  wine64  4.0.2-1

-- no debconf information

Bug#915495: Intend to Adopt: goto-chg-el

[David Krauser]

Control: retitle -1 ITA: goto-chg-el -- navigate the point to the most recent 
edit in the buffer
Control: owner -1 da...@krauser.org

Bug#941679: snarf FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: snarf
Version: 7.0-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

snarf fails to cross build from source, because it configures for the
build architecture. Usually, this is solved by passing a --host switch
(and this is what dh_auto_configure does automatically). Unfortunately,
snarf's configure is too old to understand that. Instead, one is
supposed to export a cross compiler in CC. Please consider applying the
attached patch.

Helmut
diff -u snarf-7.0/debian/changelog snarf-7.0/debian/changelog
--- snarf-7.0/debian/changelog
+++ snarf-7.0/debian/changelog
@@ -1,3 +1,9 @@
+snarf (7.0-7) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Export CC for ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 03 Oct 2019 20:19:28 +0200
+
 snarf (7.0-6) unstable; urgency=medium
 
   * QA upload.
diff -u snarf-7.0/debian/rules snarf-7.0/debian/rules
--- snarf-7.0/debian/rules
+++ snarf-7.0/debian/rules
@@ -2,6 +2,8 @@
 
 export CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
 export LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
+-include /usr/share/dpkg/buildtools.mk
+export CC
 
 clean:
dh_testdir

Bug#941677: lsmount FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: lsmount
Version: 0.2.3-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lsmount fails to cross build from source, because it uses the build
architecture pkg-config. Please consider applying the attached patch to
make pkg-config substitutable.

Helmut
--- lsmount-0.2.3.orig/Makefile
+++ lsmount-0.2.3/Makefile
@@ -1,9 +1,10 @@
 .PHONY: all clean install uninstall manpage
 
 CC  = /usr/bin/gcc
+PKG_CONFIG ?= pkg-config
 CFLAGS += -std=gnu99 -lconfig -D_GNU_SOURCE
-CFLAGS += `pkg-config --cflags libconfig`
-LDLIBS += `pkg-config --libs libconfig`
+CFLAGS += `$(PKG_CONFIG) --cflags libconfig`
+LDLIBS += `$(PKG_CONFIG) --libs libconfig`
 LDFLAGS = -ltermcap -z now
 BIN = lsmount
 OBJ = lsmount.o lsmgrid.o options.o lsmcolors.o helper.o

Bug#941680: wmf FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: wmf
Version: 1.0.5-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wmf fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so is using dh_auto_build.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru wmf-1.0.5/debian/changelog wmf-1.0.5/debian/changelog
--- wmf-1.0.5/debian/changelog  2016-03-06 15:14:57.0 +0100
+++ wmf-1.0.5/debian/changelog  2019-10-03 20:11:33.0 +0200
@@ -1,3 +1,10 @@
+wmf (1.0.5-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 03 Oct 2019 20:11:33 +0200
+
 wmf (1.0.5-7) unstable; urgency=medium
 
   * Package revamped with modern debhelper. Previous patches are now properly
diff --minimal -Nru wmf-1.0.5/debian/rules wmf-1.0.5/debian/rules
--- wmf-1.0.5/debian/rules  2016-03-06 14:46:45.0 +0100
+++ wmf-1.0.5/debian/rules  2019-10-03 20:11:33.0 +0200
@@ -23,7 +23,7 @@
 override_dh_auto_test:
 
 override_dh_auto_build:
-   $(MAKE) -C src -f $(CURDIR)/debian/Makefile.debian wmf
+   dh_auto_build --buildsystem=makefile --sourcedirectory=src -- -f 
$(CURDIR)/debian/Makefile.debian wmf
 
 override_dh_auto_install:
$(MAKE) -C src -f $(CURDIR)/debian/Makefile.debian install 
DESTDIR=$(CURDIR)/debian/wmf

Bug#941678: pimd FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: pimd
Version: 2.3.2-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pimd fails to cross build from source, because it uses the build
architecture compiler. Given that it has a ./configure script, debhelper
assumes that ./configure will set up the compiler. However, pimd expects
the compiler to be set for the make invocation. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru pimd-2.3.2/debian/changelog pimd-2.3.2/debian/changelog
--- pimd-2.3.2/debian/changelog 2017-01-23 11:33:14.0 +0100
+++ pimd-2.3.2/debian/changelog 2019-10-03 20:10:03.0 +0200
@@ -1,3 +1,10 @@
+pimd (2.3.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass CC to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 03 Oct 2019 20:10:03 +0200
+
 pimd (2.3.2-2) unstable; urgency=medium
 
   * Bump Standards to 3.9.8; no changes needed
diff --minimal -Nru pimd-2.3.2/debian/rules pimd-2.3.2/debian/rules
--- pimd-2.3.2/debian/rules 2017-01-23 11:31:49.0 +0100
+++ pimd-2.3.2/debian/rules 2019-10-03 20:10:01.0 +0200
@@ -5,6 +5,8 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@ --with systemd
 
@@ -12,6 +14,9 @@
 override_dh_auto_configure:
./configure --prefix=/usr --sysconfdir=/etc
 
+override_dh_auto_build:
+   dh_auto_build -- 'CC=$(CC)'
+
 override_dh_auto_clean:
touch config.mk
dh_auto_clean

Bug#934927: Status update request

[Pirate Praveen]

On Sun, Sep 29, 2019 at 21:53, Paul Gevers  wrote:

Could you please next time provide more context than only the bug
number. It's annoying to need to look it up if all you need to do is 
add

"libgit2 transition" somewhere.



ok.


That said, are you aware of any progress on the julia front?



I have pinged on the bug again.


Paul

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Witold Baryluk]

Package: libreoffice
Version: 1:6.3.2-1+b1
Followup-For: Bug #940914

Same issue here:

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
cppu::_copyConstructAnyFromData (mapping=0x0, acquire=0x7f42d3ba1eb0 
, pTypeDescr=, 
pType=, pSource=0x7ffe7c59db60, pDestAny=0x562e0b85a478) at 
./cppu/source/uno/copy.hxx:192
192 ./cppu/source/uno/copy.hxx: No such file or directory.
#0  0x7f42d088a5e7 in cppu::_copyConstructAnyFromData(_uno_Any*, void*, 
_typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), 
_uno_Mapping*) (mapping=0x0, acquire=0x7f42d3ba1eb0 
, pTypeDescr=, 
pType=, pSource=0x7ffe7c59db60, pDestAny=0x562e0b85a478) at 
./cppu/source/uno/copy.hxx:192
#1  0x7f42d088a5e7 in cppu::_copyConstructAny(_uno_Any*, void*, 
_typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), 
_uno_Mapping*) (pDestAny=0x562e0b85a478, pSource=0x7ffe7c59db60, 
pType=, pTypeDescr=, acquire=0x7f42d3ba1eb0 
, mapping=0x0) at 
./cppu/source/uno/copy.hxx:268
#2  0x7f42d0889a4b in uno_type_any_assign(uno_Any*, void*, 
typelib_TypeDescriptionReference*, uno_AcquireFunc, uno_ReleaseFunc) 
(pDest=0x562e0b85a478, pSource=pSource@entry=0x7ffe7c59db60, 
pType=0x562e0b859be0, acquire=acquire@entry=0x7f42d3ba1eb0 
, release=release@entry=0x7f42d3ba1ec0 
) at ./cppu/source/uno/any.cxx:39
#3  0x7f42d51aaee9 in 
com::sun::star::uno::operator<<=(com::sun::star::uno::Any&,
 com::sun::star::beans::NamedValue const&) (value=..., rAny=...) at 
./include/com/sun/star/uno/Type.h:155
#4  0x7f42d51aaee9 in utl::ConfigManager::acquireTree(utl::ConfigItem 
const&) (item=...) at ./unotools/source/config/configmgr.cxx:123
#5  0x7f42d51ab416 in utl::ConfigManager::addConfigItem(utl::ConfigItem&) 
(this=0x7f42d684ea00 ::get()::instance>, item=...) at 
./unotools/source/config/configmgr.cxx:146
#6  0x7f42d51a550c in utl::ConfigItem::ConfigItem(rtl::OUString const&, 
ConfigItemMode) (this=0x562e0b859e20, rSubTree="Setup/L10N", 
nSetMode=) at ./unotools/source/config/configitem.cxx:161
#7  0x7f42d51e43f2 in SvtSysLocaleOptions_Impl::SvtSysLocaleOptions_Impl() 
(this=0x562e0b859e20) at ./include/rtl/stringutils.hxx:170
#8  0x7f42d51e5851 in 
__gnu_cxx::new_allocator::construct(SvtSysLocaleOptions_Impl*)
 (this=, __p=0x562e0b859e20) at /usr/include/c++/9/new:174
#9  0x7f42d51e5851 in 
std::allocator_traits 
>::construct(std::allocator&,
 SvtSysLocaleOptions_Impl*) (__a=..., __p=0x562e0b859e20) at 
/usr/include/c++/9/bits/alloc_traits.h:484
#10 0x7f42d51e5851 in 
std::_Sp_counted_ptr_inplace, 
(__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<>(std::allocator)
 (__a=..., this=0x562e0b859e10) at /usr/include/c++/9/bits/shared_ptr_base.h:548
#11 0x7f42d51e5851 in 
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count>(SvtSysLocaleOptions_Impl*&, 
std::_Sp_alloc_shared_tag >) (__a=..., 
__p=, this=) at 
/usr/include/c++/9/bits/shared_ptr_base.h:679
#12 0x7f42d51e5851 in std::__shared_ptr::__shared_ptr>(std::_Sp_alloc_shared_tag
 >) (__tag=..., this=) at 
/usr/include/c++/9/bits/shared_ptr_base.h:1344
#13 0x7f42d51e5851 in 
std::shared_ptr::shared_ptr>(std::_Sp_alloc_shared_tag
 >) (__tag=..., this=) at 
/usr/include/c++/9/bits/shared_ptr.h:359
#14 0x7f42d51e5851 in std::allocate_shared>(std::allocator
 const&) (__a=...) at /usr/include/c++/9/bits/shared_ptr.h:702
#15 0x7f42d51e5851 in std::make_shared() () at 
/usr/include/c++/9/bits/shared_ptr.h:718
#16 0x7f42d51e5851 in SvtSysLocaleOptions::SvtSysLocaleOptions() 
(this=0x7ffe7c59dd20) at ./unotools/source/config/syslocaleoptions.cxx:544
#17 0x7f42d558c1f0 in InitVCL() () at ./vcl/source/app/svmain.cxx:339
#18 0x7f42d558d785 in ImplSVMain() () at ./vcl/source/app/svmain.cxx:228
#19 0x7f42d4720e93 in soffice_main() () at 
./desktop/source/app/sofficemain.cxx:170
#20 0x562e0a36807c in sal_main () at ./desktop/source/app/main.c:48
#21 0x562e0a36807c in main (argc=, argv=) at 
./desktop/source/app/main.c:47


I also noticed these entries in dmesg:

[1584366.195829] audit: type=1400 audit(1570126695.579:12453): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" name="rw/usr/share/drirc.d" 
pid=116628 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
[1584366.196340] audit: type=1400 audit(1570126695.579:12454): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" name="rw/usr/share/drirc.d" 
pid=116628 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
[1584366.197593] audit: type=1400 audit(1570126695.579:12455): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" 
name="rw/usr/lib/libreoffice/program/services" pid=116627 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[158

Bug#931693: julia: libgit2 0.28 transition

[Pirate Praveen]

On Tue, 09 Jul 2019 19:37:27 +0900 Jongmin Kim  wrote:
> Source: julia
> Severity: important
> 
> Dear Maintainer,
> 
> libgit2 0.28 is now available in experimental. Please make sure your
> package is ready for this version by the time we upload this package to
> unstable in one to two weeks. The severity of this report will be
> raised to serious once libgit2 0.28 is uploaded to unstable.

Hi,

Any plans to get this done soon? We'd really like to get libgit2 0.28 in
unstable.

Thanks
Praveen

Bug#941340: sooperlooper: Should sooperlooper be removed from Debian?

[Olivier Humbert]

Hi here.

Adding a +1 here for keeping SooperLooper in Debian archive. It's a 
great tools without much competitor at the same level out there.


I've had a look to the outstanding bugs.
1. one is just a user using the wrong binary to launch sooperlooper 
(#920813)
2. one is probably something coming from the time stretch was in dev 
(#836232) and I can't reproduce it now on Stretch or Buster.
3. one is from a very old version of sooperlooper : 1.6.14 dating back 
from 2009 (see http://essej.net/sooperlooper/), so should probably be 
closed if unreproducible nowadays (#596392)
4. the last one is about building against gtk3 wx instead of gtk wx and 
it is the case nowadays if I'm not wrong reading at 
https://salsa.debian.org/multimedia-team/sooperlooper/blob/master/debian/control 
so should probably be closed as well (#933425)


I've been talking with upstream those last few days and he might be 
willing to release a new version including a bunch of different fixes. 
See https://github.com/essej/sooperlooper/pull/13


It could then be wise to keep it in Debian regarding all of that.
Hope that helps.
Olivier

--
Site web : https://librazik.tuxfamily.org/
Donation : https://liberapay.com/LibraZiK/
Diaspora : 
https://framasphere.org/people/8c184af0c9450134f6682a053625

Mastodon : https://mastodon.xyz/@LibraZiK

Bug#941676: RFS: kanshi/1.0.0-1 ITP

[Birger Schacht]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : kanshi
  Version  : 1.0.0-1
  Upstream Author  : Simon Ser
* Url  : https://github.com/emersion/kanshi
* Licenses : Expat
  Programming Lang : C
  Section  : x11

 kanshi allows you to define output profiles that are automatically
enabled and
 disabled on hotplug. For instance, this can be used to turn a laptop's
internal
 screen off when docked.
 .
 This is a Wayland equivalent for tools like autorandr. kanshi can be
used on
 Wayland compositors supporting the wlr-output-management protocol.

It builds those binary packages:

  * kanshi

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

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

Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/k/kanshi/kanshi_1.0.0-1.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://salsa.debian.org/bisco-guest/kanshi.git

More information about kanshi can be obtained from
https://github.com/emersion/kanshi


Regards,
  Birger Schacht

Bug#915491: Intend to Adopt: elpa-undo-tree

[David Krauser]

Control: retitle -1 ITA: elpa-undo-tree -- Emacs minor mode for handling undo 
history as tree
Control: owner -1 da...@krauser.org

Bug#941093: transition: qtbase-opensource-src

[Boyuan Yang]

X-Debbugs-CC: mity...@debian.org



On Tue, 24 Sep 2019 19:32:28 +0300 Dmitry Shachnev  wrote:
> 
> Dear Release team,
> 
> Debian is currently shipping with Qt 5.11.3 which is quite outdated.
> 
> We would like to update to 5.12.5 release from the 5.12 LTS branch.
> [...]
> 
> The 5.12 release fixes build failure in qtwebengine (#939038) which blocks
the
> libvpx transition.
> 
> The only known package failing to build with Qt 5.12 is deepin-qt5dxcb-
plugin
> (#935105) which I can NMU if needed.

Just FYI: I've updated deepin-qt5dxcb-plugin to make it compatible with Qt
5.12.5 so It won't be a blocker for this transition. Let me know if there's
any other issues.

Best,
Boyuan Yang


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

Bug#920813: sooperlooper does not show GUI

[Olivier Humbert]

This is expected.
The "sooperlooper" binary is the engine one.
If you want to use the GUI, the binary is "slgui".

Hope that helps.
Olivier

--
Site web : https://librazik.tuxfamily.org/
Donation : https://liberapay.com/LibraZiK/
Diaspora : 
https://framasphere.org/people/8c184af0c9450134f6682a053625

Mastodon : https://mastodon.xyz/@LibraZiK

Bug#836232: sooperlooper: upon initialization, slgui fails an assertion with SetTitle

[Olivier Humbert]

Can't reproduce here on a Debian Stretch (oldstable) or a Debian Buster 
(stable).


Olivier

--
Site web : https://librazik.tuxfamily.org/
Donation : https://liberapay.com/LibraZiK/
Diaspora : 
https://framasphere.org/people/8c184af0c9450134f6682a053625

Mastodon : https://mastodon.xyz/@LibraZiK

Bug#941675: gkr-pam: unable to locate daemon control file

[Felix Zielcke]

Package: libpam-gnome-keyring
Version: 3.34.0-1
Severity: normal

I use MATE and lightdm. With the new version in sid it needs more time
until the desktop appears.

auth.log says:
lightdm: gkr-pam: unable to locate daemon control file

downgrading to the version in testing or commenting out the
libpam_gnome_keyring.so PAM lines in /etc/pam.d/lightdm makes it fast again.

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

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

Versions of packages libpam-gnome-keyring depends on:
ii  libc6   2.29-2
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5
ii  libselinux1 2.9-2+b2

Versions of packages libpam-gnome-keyring recommends:
ii  gnome-keyring  3.34.0-1

libpam-gnome-keyring suggests no packages.

-- no debconf information

Bug#941674: gnome-shell-extension-dashtodock: Not working

[Domenico Cufalo]

Package: gnome-shell-extension-dashtodock
Version: 66-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Latest upgrade to Gnome 3.34

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

//

   * What was the outcome of this action?

Dashtodock is not working and https://extensions.gnome.org/local/ report an
error.

Maybe due to this error, at every error all extensions are disabled and I am
forced to activate them by hand by Gnome Tweak Tool.

I don't know how to debug this issue, but, if necessary, tell me how to do it
and I will do, if possible.

   * What outcome did you expect instead?

Dashtodock working. ;-)

Thank you very much in advance,
Domenico



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

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

Versions of packages gnome-shell-extension-dashtodock depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  gir1.2-clutter-1.0   1.26.2+dfsg-12
ii  gnome-shell  3.34.0-2

gnome-shell-extension-dashtodock recommends no packages.

gnome-shell-extension-dashtodock suggests no packages.

-- no debconf information

Bug#941673: jessie-pu: package publicsuffix/20190925.1705-0+deb8u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian jessie.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in jessie is attached.

This proposed release is also available at the
"publicsuffix_debian/20190925.1705-0+deb8u1" tag on the "debian/jessie" branch 
at the
git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to jessie.



../publicsuffix_20171028.2055-0+deb8u1_20190925.1705-0+deb8u1.debdiff.gz
Description: Binary data

Bug#941672: [INTL:nl] Renewed Dutch translation for unattended-upgrades

[Maarten]

Package: unattended-upgrades
Version: 1.14
Severity: wishlist
Tags: l10n, patch



Dear Maintainer


The Dutch translation for unattended-upgrades has been renewed to
meet the needs of version 1.14.


With kind regards

Maarten
member of the Dutch translation team of Debian

nl.po.gz
Description: application/gzip

Bug#941618: torus-trooper: fails to start with "undefined symbol" error

[Stephen Kitt]

Hi Matthias,

Le 02/10/2019 23:37, Cédric Boutillier a écrit :

I've just installed the game and tried to launch it from the terminal:
I got the following error message:

torus-trooper: symbol lookup error: torus-trooper: undefined symbol:
_D4core4stdc5errno5errnoFNbNdNiNeZ


This is a symbol in libgdruntime.so.76.0.2 which is no longer present in 
libgdruntime.so.76.0.3. It does look like an internal symbol, but 
binaries apparently end up with references to it, so binaries built with 
the GCC 8 version can break with the GCC 9 version...


Should this be fixed in GCC, or by binNMUing?

Regards,

Stephen

Bug#941354: node-yarnpkg: CVE-2019-5448

[Xavier]

Hi,

I don't know if you want to DSA this bug. Anyway here is the patch.

Cheers,
Xavier

https://bugs.debian.org/941354
https://security-tracker.debian.org/tracker/CVE-2019-5448
diff --git a/debian/changelog b/debian/changelog
index 01fe7d70d..464a7c745 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-yarnpkg (1.13.0-1+deb10u1) buster-security; urgency=medium
+
+  * Team upload
+  * Add patch to force using https for the regular registries (Closes: 
#941354, CVE-2019-5448)
+
+ -- Xavier Guimard   Thu, 03 Oct 2019 18:23:54 +0200
+
 node-yarnpkg (1.13.0-1) unstable; urgency=low
 
   * Initial release (Closes: #843021)
diff --git a/debian/patches/CVE-2019-5448.diff 
b/debian/patches/CVE-2019-5448.diff
new file mode 100644
index 0..8bb7442c8
--- /dev/null
+++ b/debian/patches/CVE-2019-5448.diff
@@ -0,0 +1,75 @@
+Description: Forces using https for the regular registries
+Author: Maël Nison 
+Origin: upstream, https://github.com/yarnpkg/yarn/commit/2f08a740
+Bug: https://hackerone.com/reports/640904
+Bug-Debian: https://bugs.debian.org/941354
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-10-03
+
+--- a/__tests__/registries/npm-registry.js
 b/__tests__/registries/npm-registry.js
+@@ -750,6 +750,30 @@
+ 
+ expect(npmRegistry.getRequestUrl(registry, 
pathname)).toEqual('https://my.registry.co/registry/foo/bar/baz');
+   });
++
++  for (const host of [`registry.yarnpkg.com`, `registry.npmjs.org`, 
`registry.npmjs.com`]) {
++test(`enforces loading packages through https when they come from 
${host}`, () => {
++  const testCwd = '.';
++  const {mockRequestManager, mockRegistries, mockReporter} = 
createMocks();
++  const npmRegistry = new NpmRegistry(testCwd, mockRegistries, 
mockRequestManager, mockReporter, true, []);
++  const registry = `http://${host}/registry`;
++  const pathname = 'foo/bar/baz';
++
++  expect(npmRegistry.getRequestUrl(registry, 
pathname)).toEqual(`https://${host}/registry/foo/bar/baz`);
++});
++  }
++
++  test("doesn't change the protocol for packages from other registries", () 
=> {
++const testCwd = '.';
++const {mockRequestManager, mockRegistries, mockReporter} = createMocks();
++const npmRegistry = new NpmRegistry(testCwd, mockRegistries, 
mockRequestManager, mockReporter, true, []);
++const registry = 'http://registry.mylittlepony.org/registry';
++const pathname = 'foo/bar/baz';
++
++expect(npmRegistry.getRequestUrl(registry, pathname)).toEqual(
++  'http://registry.mylittlepony.org/registry/foo/bar/baz',
++);
++  });
+ });
+ 
+ describe('getScope functional test', () => {
+--- a/src/registries/npm-registry.js
 b/src/registries/npm-registry.js
+@@ -22,6 +22,7 @@
+ import ini from 'ini';
+ 
+ const DEFAULT_REGISTRY = 'https://registry.npmjs.org/';
++const REGEX_REGISTRY_ENFORCED_HTTPS = 
/^https?:\/\/([^\/]+\.)?(yarnpkg\.com|npmjs\.(org|com))(\/|$)/;
+ const REGEX_REGISTRY_HTTP_PROTOCOL = /^https?:/i;
+ const REGEX_REGISTRY_PREFIX = /^(https?:)?\/\//i;
+ const REGEX_REGISTRY_SUFFIX = /registry\/?$/;
+@@ -112,13 +113,17 @@
+   }
+ 
+   getRequestUrl(registry: string, pathname: string): string {
+-const isUrl = REGEX_REGISTRY_PREFIX.test(pathname);
++let resolved = pathname;
+ 
+-if (isUrl) {
+-  return pathname;
+-} else {
+-  return url.resolve(addSuffix(registry, '/'), pathname);
++if (!REGEX_REGISTRY_PREFIX.test(pathname)) {
++  resolved = url.resolve(addSuffix(registry, '/'), pathname);
+ }
++
++if (REGEX_REGISTRY_ENFORCED_HTTPS.test(resolved)) {
++  resolved = resolved.replace(/^http:\/\//, 'https://');
++}
++
++return resolved;
+   }
+ 
+   isRequestToRegistry(requestUrl: string, registryUrl: string): boolean {
diff --git a/debian/patches/series b/debian/patches/series
index f3c856f99..7c03222a8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@
 08-cli-table3.diff
 09-buffer_from.diff
 10-babel-plugin-inline-import.diff
+CVE-2019-5448.diff

Bug#941665: [Pkg-openssl-devel] Bug#941665: libssl1.1: Breaks ssh privsep_preauth in some circumstances

[Kurt Roeckx]

On Thu, Oct 03, 2019 at 04:11:57PM +0200, fab...@maintenancia.com wrote:
> It might be related to the fact that my system is a VPS running on an
> old kernel (3.16.0-4).

openssl does a new call to shm* related calls on such old kernels, and
openssh has a seccomp fileter that doesn't allow those calls.


Kurt

Bug#941609: [Pkg-utopia-maintainers] Bug#941609: network-manager: generates world-{read, execut}able secret_key file (in buster)

[Michael Biebl]

Am 02.10.19 um 20:07 schrieb Thorsten Glaser:
> Package: network-manager
> Version: 1.14.6-2
> 
> src/nm-core-utils.c has:
>2896 } else if (!nm_utils_file_set_contents 
> (SECRET_KEY_FILE,
>2897 (const char 
> *) new_content,
>2898 len,
>2899 0077,
>2900 &error)) {
> 
> Fixed in 1.20.4-1 (sid):
>2698 } else if (!nm_utils_file_set_contents 
> (SECRET_KEY_FILE,
>2699 (const char 
> *) new_content,
>2700 len,
>2701 0600,
>2702 &error)) {
> 

Relevant upstream bug report

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/175

Contrary to the comments in
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/613af1de95182c69bd30e09a4139b172bf2e1a70

/var/lib/NetworkManager is 755 on Debian (as it is created via
network-manager.dirs). So bringing the security team into the loop here.

At a first glance, this does not look too critical. The secret key is
used as follows:

> * Support and use a new kind of secret-key in 
> "/var/lib/NetworkManager/secret_key".
>   The secret-key represents the identity of the machine that is used for 
> various
>   purposes like generating IPv6 stable privacy addresses. It is now combined
>   with "/etc/machine-id" so that changing only the machine-id results in new 
> identifiers.
>   That matters for example when cloning a virtual machine. Previously, the 
> user
>   hard to prune NetworkManager's secret-key to get a new identity, now 
> regenerating
>   machine-id suffices. Secret-keys generated by earlier versions of 
> NetworkManager are
>   not affected and keep their previous behavior.

Aside from cherry-picking the upstream commit, I guess we should fix up
the permissions of /var/lib/NetworkManager/secret_key on upgrades and
also make sure we use 700 for /var/lib/NetworkManager/ as upstream intended.

@security team: Do you think this is sufficient? Should we re-generate
the key? Should this be fixed via a stable upload or a security upload?

I'm leaning towards keeping the existing secret-key file and fixing this
via stable, but I'd welcome your feedback here.

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#941671: imagemagick: CVE-2019-15140

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.10.23+dfsg-2.1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/1554

Hi,

The following vulnerability was published for imagemagick.

CVE-2019-15140[0]:
| coders/mat.c in ImageMagick 7.0.8-43 Q16 allows remote attackers to
| cause a denial of service (use-after-free and application crash) or
| possibly have unspecified other impact by crafting a Matlab image file
| that is mishandled in ReadImage in MagickCore/constitute.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-15140
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15140
[1] https://github.com/ImageMagick/ImageMagick/issues/1554

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#941670: imagemagick: CVE-2019-15139

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.10.23+dfsg-2.1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/1553

Hi,

The following vulnerability was published for imagemagick.

CVE-2019-15139[0]:
| The XWD image (X Window System window dumping file) parsing component
| in ImageMagick 7.0.8-41 Q16 allows attackers to cause a denial-of-
| service (application crash resulting from an out-of-bounds Read) in
| ReadXWDImage in coders/xwd.c by crafting a corrupted XWD image file, a
| different vulnerability than CVE-2019-11472.


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-15139
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15139
[1] https://github.com/ImageMagick/ImageMagick/issues/1553

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#941669: python3-rpi.gpio fails to work on aarch64 (upgrade needed)

[André Draszik]

Package: python3-rpi.gpio
Version: 0.6.5-1
Severity: grave
Tags: upstream
Justification: renders package unusable


Hi,

python3-rpi.gpio 0.6.5 as is current in sid, doesn't support
aarch64:

Traceback (most recent call last):
  File "./server.py", line 8, in 
import RPi.GPIO as GPIO
  File "/usr/lib/python3/dist-packages/RPi/GPIO/__init__.py", line 23, in 

from RPi._GPIO import *
RuntimeError: This module can only be run on a Raspberry Pi!


Upstream has fixed this in the 0.7.0 release, see here
https://sourceforge.net/p/raspberry-gpio-python/tickets/161/

I am kindly asking to please update the Debian package.

Andre'

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages python3-rpi.gpio depends on:
ii  libc62.28-10
ii  python3  3.7.3-1
ii  rpi.gpio-common  0.6.5-1

python3-rpi.gpio recommends no packages.

python3-rpi.gpio suggests no packages.

-- no debconf information

Bug#780302: Any plan to apply provided patch ?

[Frédéric Bonnard]

Dear maintainers,

do you have any plan to take that patch for ppc64el build ?
It would also fix the current FTBFS on ppc64.

Regards,

F.


pgpOJSrud57_3.pgp
Description: PGP signature

Bug#941637: linux-image-4.19.0-6-amd64: noht flag on command line has no effect for 6 core/12 Thread Ryzens

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi

On Thu, Oct 03, 2019 at 09:24:26AM +0100, Anton Ivanov wrote:
> Package: src:linux
> Version: 4.19.67-2+deb10u1
> Severity: important
> 
> Dear Maintainer,
> 
> noht has no effect.
> 
> I have been trying to chase down a weird hang which occurs only on 6
> core/12 thread Ryzens (I cannot reproduce it on 4/8 or older CPUs).
> 
> As a part of that I tried to disable ht. Well, it cannot be disabled
> - the noht command line arg has no effect whatosever.
> 
> As ht can be a security hole this may have security implications as
> well.

Do you mean 'nosmt'? (See kernel-parameters.txt).

You can find further information as well in
Documentation/admin-guide/hw-vuln/l1tf.rst.

Regards,
Salvatore

Bug#941668: ruby-build: New version (2019)

[Nicholas J Humfrey]

Package: ruby-build
Version: 20170726-1
Severity: wishlist

Dear Maintainer,

Please can you update to a new snapshot of ruby-build.
Github currently contains definitions for ruby 2.6.5 (released 1st October 
2019):
https://github.com/rbenv/ruby-build/tree/master/share/ruby-build

The current version of the ruby-build package was snapshotted over 2 years ago
and contains up to ruby 2.4.1 (released 22nd March 2017):
https://packages.debian.org/buster/all/ruby-build/filelist



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

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

Versions of packages ruby-build depends on:
ii  build-essential   12.6
ii  curl  7.64.0-4
ii  libreadline6-dev  6.3-8+b3
ii  zlib1g-dev1:1.2.11.dfsg-1

Versions of packages ruby-build recommends:
ii  libsqlite3-dev  3.27.2-3
ii  libssl-dev  1.1.1d-0+deb10u1
ii  libxml2-dev 2.9.4+dfsg1-7+b3
ii  libxslt1-dev [libxslt-dev]  1.1.32-2.1~deb10u1
ii  rbenv   1.1.1-1

Versions of packages ruby-build suggests:
ii  autoconf2.69-11
ii  automake1:1.16.1-4
ii  bison   2:3.3.2.dfsg-1
ii  git [git-core]  1:2.20.1-2
ii  libtool 2.4.6-9

-- no debconf information

Bug#941530: jackson-databind: CVE-2019-16942 CVE-2019-16943

[Sébastien Delafond]

On 02/10 09:43, Salvatore Bonaccorso wrote:
> Whilst I'm not yet sure if we should really release a futher DSA for
> jackson-databind (we will come back to you on that), a possible idea
> for bullseye (might be better cloned/filled as new bug, but want to
> mention it here already):

Let's do a DSA for this one. For future issues, we can choose to decide
on DSA vs. point release on a case-by-case basis, depending on severity.

Cheers,

-- 
Seb

Bug#941667: CVE-2019-3685

[Sylvain Beucler]

Package: osc
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for osc.

CVE-2019-3685[0]:
Fails to adequately verify TLS certificates allowing for a man in the middle 
attack

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

Sadly, little information is known at the moment:

[0] https://security-tracker.debian.org/tracker/CVE-2019-3685
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3685
https://bugzilla.redhat.com/show_bug.cgi?id=1737797

To the least, it would help to know which versions are affected.
Please adjust the affected versions in the BTS as needed.

Cheers!
Sylvain Beucler
Debian LTS Team

Bug#941666: ITP: vega-datasets -- Collection of datasets used in Vega and Vega-Lite examples

[Santiago Ruano Rincón]

Package: wnpp
Severity: wishlist
Owner: "Santiago Ruano Rincón" 

* Package name: vega-datasets
  Version : 0.7
  Upstream Author : Jake Vanderplas
* URL : https://github.com/altair-viz/vega_datasets
* License : MIT and others.
  Programming Lang: Python
  Description : Python package for offline access to vega datasets

This is a collection of datasets used in vega examples.

This is required to build altair (See ITP bug https://bugs.debian.org/941599),
especially to run the test suite.

Similar to altair, it would be great to maintain it within the Python
Modules Team.


signature.asc
Description: PGP signature