Bug#925351: stretch-pu: package dns-root-data/2019031302~deb9u1

[Daniel Kahn Gillmor]

On Sun 2019-03-31 20:07:06 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Sat, 2019-03-23 at 16:04 +0100, Daniel Kahn Gillmor wrote:
>> Please consider an update to dns-root-data in debian stretch.
>
> +dns-root-data (2019031302~deb9u1) stretch; urgency=medium
> +
> +  * Rebuild for stretch-backports.
>
> *cough* :-)

d'oh!  that's embarrassing.

> With that fixed, please go ahead.

uploaded, thanks for the review!

--dkg

Bug#924976: python3-celery: Incompatible with python3-redis/python3-kombu versions

[Scott Kitterman]

On Tue, 19 Mar 2019 11:03:37 + wmwmw  wrote:
> Package: python3-celery
> Version: 4.2.1-3
> Severity: grave
> Justification: renders package unusable
> 
> Should be fixed in the upstream, but current versions in repository are 
incompatible.
> 
> https://github.com/celery/celery/issues/5175

Fixing this requires updating kombu and celery to the current versions (celery 
4.3.0 was just released today and should be compatible).

Scott K

Bug#924554: SUCCESS messages: significant behaviour change

[Alex]

I agree, this behavior is not needed and causes too many emails to be sent to 
my root account.

I don't believe messages should be sent out if nothing actually occurred.

Bug#618863: related openssh bug

[sergio]

https://bugzilla.mindrot.org/show_bug.cgi?id=2119

--
sergio.

--
sergio.

Bug#885200: guile-2.2's guile.m4 needs fix

[أحمد المحمودي]

reassign 885200 guile-2.2 2.2.4+1-1
affects 885200 gwave
retitle 885200 guile.m4 needs to be fixed
quit

On Sat, Mar 30, 2019 at 03:07:22AM +0100, أحمد المحمودي wrote:
> > I tried to build gwave 20190116, but I got this error on during 
> > configure phase:
> > 
> > configure: checking for guile 2.2
> > configure: found guile 2.2
> > checking for guile-2.2... /usr/bin/guile-2.2
> > checking for Guile version >= 2.2... 2.2.4
> > checking for guild-2.2... no
> > checking for guile-config-2.2... no
> > checking for guile-tools-2.2... no
> > checking build system type... x86_64-pc-linux-gnu
> > checking host system type... x86_64-pc-linux-gnu
> > checking for ld used by gcc... /usr/bin/ld
> > checking if the linker (/usr/bin/ld) is GNU ld... yes
> > checking for shared library run path origin... done
> > checking for GUILE... yes
> > configure: error: 'guild' binary not found; please check your guile-2.x 
> > installation.
> ---end quoted text---
> 
> I found that this problem happens if I run dh_autoreconf. The problem is 
> because after autoreconf, the configure script searches for guild with 
> the -2.2 suffix, yet the guile-2.2-dev package installs guild without 
> that suffix, although guile binary has the -2.2 suffix in guile-2.2 
> package. Yet in /usr/share/aclocal/guile.m4 it says:
> 
> # @code{guile} is still not found, signal an error. The suffix, if any,
> # that was required to find @code{guile} will be used for @code{guild}
> # as well.
> 
> So I beleive that that there is an issue with guile-2.2 package
---end quoted text---

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#926146: the diskstat_ plugin fails with 4.19 kernels

[Marco d'Itri]

Package: munin-plugins-core
Version: 2.0.47-1
Severity: important
Tags: upstream newcomer patch

The diskstat_ plugin does not work with the 4.19 kernel in testing:

'/sys/block/sda/stat' doesn't contain exactly 11 values. Aborting at 
/etc/munin/plugins/diskstat_iops_sda line 505,  line 1.
main::read_sysfs("sda") called at /etc/munin/plugins/diskstat_iops_sda 
line 530
main::parse_diskstats("sda") called at 
/etc/munin/plugins/diskstat_iops_sda line 561
main::fetch_device_counters("sda") called at 
/etc/munin/plugins/diskstat_iops_sda line 331

Changing 11 to 15 will fix it, so I think that this could be fixed with:

-croak "'$stats_file' doesn't contain exactly 11 values. Aborting"
-if ( @elems != 11 );
+croak "'$stats_file' doesn't contain at least 11 values. Aborting"
+if ( @elems < 11 );

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#925957: Proper fix is now available upstream

[Alexander E. Patrakov]

Control: reopen -1

Hello,

you have closed the bug without fixing it properly (an extra warning
is not a fix for an algorithmic bug). A proper fix is available
upstream now, please backport it to the Debian package, including the
stable and LTS releases.

The fix is 
https://github.com/cosmos72/fstransform/commit/1a935732abdd2ef998b8a3f172dc6d9548b49fab

Thanks!

-- 
Alexander E. Patrakov

Bug#924123: shishi: FTBFS with pam >= 1.3 (was: with gcc 8.3)

[Steve Langasek]

Hi Bernhard,

On Sun, Mar 31, 2019 at 11:27:47PM +0200, Bernhard R. Link wrote:
> Control: retitle -1 shishi: FTBFS with pam >= 1.3
> 
> Just some litte fly-by comment looking over RC bugs affecting testing:
> 
> I can also reproduce the FTBFS in an unstable chroot (so nothing testing
> specific with that build failure).
> 
> The log is not really helpful here, as libtool only prints stderr of the
> -DPIC compilation, but hides stderr of the non-PIC compilation, while
> only the non-PIC compilation fails (the PIC case only produces harmless
> warnings).
> 
> Unhiding the output of that gcc run gives the following result:
> 
> | pam_shishi.c: In function 'pam_sm_authenticate':
> | pam_shishi.c:185:48: warning: cast to pointer from integer of different 
> size [-Wint-to-pointer-cast]
> |pam_set_data (pamh, "shishi_setcred_return", (void *) retval, NULL);
> | ^
> | pam_shishi.c: At top level:
> | pam_shishi.c:292:8: error: variable '_pam_shishi_modstruct' has initializer 
> but incomplete type
> |  struct pam_module _pam_shishi_modstruct = {
> | ^~
> | pam_shishi.c:293:3: warning: excess elements in struct initializer
> |"pam_shishi",
> |^~~~
> | pam_shishi.c:293:3: note: (near initialization for '_pam_shishi_modstruct')
> | pam_shishi.c:294:3: warning: excess elements in struct initializer
> |pam_sm_authenticate,
> |^~~
> | pam_shishi.c:294:3: note: (near initialization for '_pam_shishi_modstruct')
> | pam_shishi.c:295:3: warning: excess elements in struct initializer
> |pam_sm_setcred,
> |^~
> | pam_shishi.c:295:3: note: (near initialization for '_pam_shishi_modstruct')
> | pam_shishi.c:296:3: warning: excess elements in struct initializer
> |pam_sm_acct_mgmt,
> |^~~~
> | pam_shishi.c:296:3: note: (near initialization for '_pam_shishi_modstruct')
> | pam_shishi.c:297:3: warning: excess elements in struct initializer
> |pam_sm_open_session,
> |^~~
> | pam_shishi.c:297:3: note: (near initialization for '_pam_shishi_modstruct')
> | pam_shishi.c:298:3: warning: excess elements in struct initializer
> |pam_sm_close_session,
> |^~~~
> | pam_shishi.c:298:3: note: (near initialization for '_pam_shishi_modstruct')
> | pam_shishi.c:299:3: warning: excess elements in struct initializer
> |pam_sm_chauthtok
> |^~~~
> | pam_shishi.c:299:3: note: (near initialization for '_pam_shishi_modstruct')
> | pam_shishi.c:292:19: error: storage size of '_pam_shishi_modstruct' isn't 
> known
> |  struct pam_module _pam_shishi_modstruct = {
> |^
> | /usr/include/security/pam_modules.h: In function 'pam_sm_authenticate':
> | pam_shishi.c:127:7: warning: ignoring return value of 'asprintf', declared 
> with attribute warn_unused_result [-Wunused-result]
> |asprintf ((char **) [0].msg, "Password for `%s@%s': ",
> |^~
> |shishi_principal_default (h), shishi_realm_default (h));
> |~~~

> Looking at the sourcecode of the pam sourcepackage, it seems like suppor
> for PAM_STATIC was removed with pam upstream 1.3.0, which hit Debian
> with 1.3.1-3 uploaded 2019-02-12.

> Taking a look at other pam_modules, they do not define PAM_STATIC
> themself under any circumstances but only check it,
> while extra/pam_shishi/pam_shishi.c contains:

> | #ifndef PIC
> | #define PAM_STATIC
> | #endif

> Looking around at some old pam documentation, my guess is that
> PAM_STATIC is only to be used if modules are to be linked into libpam
> directly. So I think those three lines above are in error and without
> them this build failure might also be fixed.

> @vorlon: could you take a look if my understanding of PAM_STATIC is
> correct and it is nothing that should be defined if compiled as
> an pam module outside of the pam source tree?

That's correct. PAM_STATIC was non-standard, broken through most of the life
of Linux-PAM, and is now obsolete; and there is no reason for anything
outside of the Linux-PAM tree to ever be building non-PIC PAM modules.  This
package should stop trying to build a PAM module as a static library.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#926145: please package version 1.10 or newer

[W. Martin Borgert]

Source: kivy
Version: 1.9.1-1
Severity: wishlist

Please consider packaging version >= 1.10.
It is needed for Cagou (#897232).
Thanks!

Bug#926144: josm: JOSM said I encountered a bug when closing a toolbox

[Paul Johnson]

Package: josm
Version: 0.0.svn14760+dfsg-1
Severity: normal

{{{
Revision:14760
Is-Local-Build:false
Build-Date:2019-02-05 06:06:28
Debian-Release:0.0.svn14760+dfsg-1
Build-Name:Debian

Identification: JOSM/1.5 (14760 Debian en) Linux Debian GNU/Linux buster/sid
Memory Usage: 475 MB / 3876 MB (82 MB allocated, but free)
Java version: 11.0.3+1-Debian-1, Oracle Corporation, OpenJDK 64-Bit Server VM
Screen: :0.0 1366x768, :0.1 1280x1024
Maximum Screen Size: 1366x1024
Java package: openjdk-11-jre:amd64-11.0.3+1-1
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-21
VM arguments: [-Djosm.restart=true, -Djava.net.useSystemProxies=true,
-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel]

Plugins:
+ CustomizePublicTransportStop (34867)
+ DirectDownload (34867)
+ DirectUpload (34867)
+ FixAddresses (34867)
+ ImproveWay (24)
+ InfoMode (34755)
+ OpenStreetCam (184)
+ OpeningHoursEditor (34867)
+ apache-commons (34506)
+ apache-http (34632)
+ auto_tools (67)
+ buildings_tools (34867)
+ continuosDownload (82)
+ download_along (34869)
+ ejml (34389)
+ geochat (34867)
+ geojson (116)
+ geotools (34513)
+ gson (34389)
+ imagery_offset_db (34867)
+ jaxb (34678)
+ jna (34867)
+ jts (34524)
+ lakewalker (34867)
+ log4j (34527)
+ mbtiles (v2.5.0)
+ measurement (34867)
+ opendata (34867)
+ photo_geotagging (34867)
+ photoadjust (34867)
+ pt_assistant (2.1.10)
+ reltoolbox (34867)
+ routing (34678)
+ tageditor (34867)
+ terracer (34867)
+ todo (30306)
+ turnlanes-tagging (280)
+ turnrestrictions (34867)
+ undelete (34877)
+ utilsplugin2 (34867)
+ waydownloader (34867)

Tagging presets:
+ https://josm.openstreetmap.de/josmfile?page=Presets/Animal_facilities=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/BuildingPreset=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/Bus_lanes=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/LaneAttributes=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/Maxspeed-zones=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/NewParkingFeatures=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/NewTags=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/ParkingLanes=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/Quick-highways=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/Quick-stops=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/Light_sources=1
+
https://josm.openstreetmap.de/josmfile?page=Presets/MobilePhoneBaseStations=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/public_bookcase=1
+
https://raw.githubusercontent.com/jacobbraeutigam/JOSM_Preset_street_cabinet/master/street_cabinet.xml
+ https://josm.openstreetmap.de/josmfile?page=Presets/Towers=1
+
https://raw.githubusercontent.com/yopaseopor/traffic_signs_preset_JOSM/master/US.zip
+ https://josm.openstreetmap.de/josmfile?page=Presets/BicycleJunction=1
+
https://raw.githubusercontent.com/OpenNauticalChart/josm/master/INT-1-preset.xml
+ https://josm.openstreetmap.de/josmfile?page=Presets/OpenSeaMap-
PresetForSeamarks=1

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/NewParkingFeatures=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/MaxspeedIcons=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/Traffic_signs=1
+
https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Ph_Typhoon=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Fixme=1
- https://raw.github.com/molysgaard/OAM-JOSM/master/oam-style.mapcss
+ https://josm.openstreetmap.de/josmfile?page=Styles/PowerMapping=1
- https://josm.openstreetmap.de/josmfile?page=Styles/PublicTransport=1
- https://josm.openstreetmap.de/josmfile?page=Styles/MTB=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways=1

Last errors/warnings:
- W: javax.imageio.IIOException: Caught exception during read:. Cause:
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1
- E: Failed to locate image 'traffic_signs_presets/tunnel.png'
- W:  Tunnel: Could not get presets icon traffic_signs_presets/tunnel.png
- W: java.io.IOException: The requested URL
https://josm.openstreetmap.de/josmfile?page=Styles/Traffic_signs=1 was not
found
- W: Failed to load Mappaint styles from
'https://josm.openstreetmap.de/josmfile?page=Styles/Traffic_signs=1'.
Exception was: java.io.IOException: The requested URL
https://josm.openstreetmap.de/josmfile?page=Styles/Traffic_signs=1 was not
found
- E: java.io.IOException: The requested URL
https://josm.openstreetmap.de/josmfile?page=Styles/Traffic_signs=1 was not
found
- W: Initializing map style
https://josm.openstreetmap.de/josmfile?page=Styles/Traffic_signs=1
completed in 170 ms (1 errors, 0 warnings)
- E: Handled by bug report queue: java.lang.NullPointerException
- E: Handled by bug report queue: 

Bug#926009: openjdk-11 breaks libreoffice autopkgtests

[Matthias Klose]

Control: reassign -1 src:libreoffice

> IMHO correctly so, some of the changes are so far away from the
> freeze policy..

pointy comments won't help, because you will see these changes at least in the
first buster security update, so maybe some backports for libreoffice are
needed? is that fixed in 6.2.x?

Bug#925911: RFS: lopsub-1.0.2 [ITP]

[Andre Noll]

On Sat, Mar 30, 23:58, Adam Borowski wrote
> On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
> >  * Package name: lopsub
> >Version : 1.0.2
> 
> Such a version means a native package; only software written specifically
> for Debian which makes no sense outside it should use the native format.
> Even if you're both upstream and the packager, a non-native format is
> helpful in case someone other than you would upload a fix.
> 
> This library is certainly not something for Debian only, thus please append
> "-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
> despite the name, doesn't require actually using quilt).

Sure, I just wasn't aware of this convention, and that "3.0 (quilt)"
is the right choice for a package like lopsub. One question: With this
change applied, dpkg-buildpackage wants the upstream tarball in the
parent directory. I guess I'm supposed to run git archive here to
create it as part of the before-build hook, but I couldn't figure
out where this hook is defined.

> >Upstream Author : Andre Noll 
> >  * URL : http://people.tuebingen.mpg.de/maan/lopsub/
> >  * License : (L)GPLv3
> 
> It would be nice to mention more prominently what parts are GPLv3-ed and
> which are LGPLv3-ed.

The library is LGPLv3 while the lopsubgen executable is GPLv3. The
source code generated by lopsubgen is licensed with a simple
all-permissive license. See lopsub.7 for more information. I've
changed debian/copyright to make this distinction stand out a bit more.

> I'd recommend running "lintian -i" which gives a long descriptive message
> for every warning, including hints how to fix.

Point. This was a very helpful hint indeed. With the long descriptions,
it was easy to squash the remaining few warnings.

> I see a static library installed by the package.  Those shouldn't generally
> be used unless you're doing something special -- static linking makes
> security and bugfix updates extremely tedious.  Libraries should also be
> split into separate binary packages, with lib${name}dev providing
> development files while lib${name}${so} the runtime lib.

Yes, I had this concern as well. I'll change the build system to
create a shared library instead and split the binary package as you
suggest. I'll follow up with another reply when it's ready.

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


signature.asc
Description: PGP signature

Bug#926143: network-manager: The wired network stop suddenly, needs replug cable or reboot.

[Vinicius Couto]

Package: network-manager
Version: 1.14.6-2
Severity: important

Dear Maintainer,

Using the computer, the wired network stops suddenly.
Reactivating the network via gnome config not works.
I need to replug the cable or reboot the router or computer.

Part of /var/log/user.log

Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.0848] dhcp4 
(enp2s0): request timed out
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.0848] dhcp4 
(enp2s0): state changed unknown -> timeout
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1540] dhcp4 
(enp2s0): canceled DHCP transaction, DHCP client pid 20528
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1541] dhcp4 
(enp2s0): state changed timeout -> done
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1544] device 
(enp2s0): state change: ip-config -> failed (reason 'ip-config-unavailable'
, sys-iface-state: 'managed')
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1555] device 
(enp2s0): Activation: failed for connection 'Wired connection 1'
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1559] device 
(enp2s0): state change: failed -> disconnected (reason 'none', sys-iface-st
ate: 'managed')
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1585] policy: 
auto-activating connection 'Wired connection 1' (8cc50a6b-b16d-4543-bf92-b
d03a6b2d9b3)
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1597] device 
(enp2s0): Activation: starting connection 'Wired connection 1' (8cc50a6b-b1
6d-4543-bf92-bd03a6b2d9b3)
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1781] device 
(enp2s0): state change: disconnected -> prepare (reason 'none', sys-iface-s
tate: 'managed')
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1794] device 
(enp2s0): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1828] device 
(enp2s0): state change: config -> ip-config (reason 'none', sys-iface-state
: 'managed')
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.1835] dhcp4 
(enp2s0): activation: beginning transaction (timeout in 45 seconds)
Mar 31 19:35:05 vimc NetworkManager[545]:   [1554071705.2473] dhcp4 
(enp2s0): dhclient started with pid 20589

[...]

Mar 31 19:35:50 vimc NetworkManager[545]:   [1554071750.0867] dhcp4 
(enp2s0): request timed out
Mar 31 19:35:50 vimc NetworkManager[545]:   [1554071750.0867] dhcp4 
(enp2s0): state changed unknown -> timeout
Mar 31 19:35:50 vimc NetworkManager[545]:   [1554071750.1191] dhcp4 
(enp2s0): canceled DHCP transaction, DHCP client pid 20589
Mar 31 19:35:50 vimc NetworkManager[545]:   [1554071750.1191] dhcp4 
(enp2s0): state changed timeout -> done
Mar 31 19:35:50 vimc NetworkManager[545]:   [1554071750.1196] device 
(enp2s0): state change: ip-config -> failed (reason 'ip-config-unavailable'
, sys-iface-state: 'managed')
Mar 31 19:35:50 vimc NetworkManager[545]:   [1554071750.1209] device 
(enp2s0): Activation: failed for connection 'Wired connection 1'
Mar 31 19:35:50 vimc NetworkManager[545]:   [1554071750.1214] device 
(enp2s0): state change: failed -> disconnected (reason 'none', sys-iface-st
ate: 'managed')


Reggards


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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.12-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-2
ii  libbluetooth3  5.50-1
ii  libc6  2.28-8
ii  libcurl3-gnutls7.64.0-2
ii  libglib2.0-0   2.58.3-1
ii  libgnutls303.6.7-2
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.6-2
ii  libpam-systemd 241-2
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0241-2
ii  libteamdctl0   1.28-1
ii  libudev1   241-2
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2019031300
ii  policykit-10.105-25
ii  udev   241-2
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-3

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-4
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.10.0-1
ii  ppp  

Bug#925327: gpsd: CVE-2018-17937

[Bernd Zeimetz]

Hi,

On 3/30/19 8:32 AM, Salvatore Bonaccorso wrote:
> Hi Bernd,
> 
> On Fri, Mar 29, 2019 at 10:54:50PM +0100, Bernd Zeimetz wrote:
>> Hi Salvatore,
>>
>>> The following vulnerability was published for gpsd, not competely sure
>>> on severity and on if the referenced upstream commit is enough.
>>> Ideally though the fix seems ideal to go to buster.
>>
>> I've tried to get more information out of Upstream, but did not get a
>> reply yet. So I'll prepare an upload with the mentioned commit. Looking
>> trough the commit logs from gpsd it seems to be the only relevant one.
> 
> Ack thank you for investigating, I was neither more successfull to
> determine if that's enough.
> 
> Cc;ing the security team alias, if anyone has more ideas.

So I'd go with
https://github.com/bzed/pkg-gpsd/blob/buster/debian/patches/json-cve-fix

which contains all changes to json.c/.h up to
a399e85c1201400e281f2c1dc29dde21c29b0088

from the upstream repository.

Later changes are not relevant here.

Any objections?


Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#924835: adacontrol: FTBFS: test tfw_gpr.txt failed

[Nicolas Boulenguez]

Package: src:adacontrol
Followup-For: Bug #924835

Hello.

I fail to reproduce the attached log with adacontrol/1.20r7-1 in a
local amd64 buster chroot.

In my chroot and during reproducible builds, the failure of the
tfw_gpr test is reported but not critical thanks to the
fix_tfw_gpr.diff Debian patch.
However, it breaks the build on several non-released architectures
with 1.20r7-1 in unstable.
A proper fix is introduced by 1.20r9-1 in experimental.

The t_style test succeeds in my chroot and during reproducible builds.
It fails on several non-released architectures in both unstable and
experimental.

Unless someone manages to reproduce both issues (probably in a
porterbox) and upload a targeted fix within 5 days, the package will
be removed from buster without possible return.

This seems hazardous, so for now I suggest to simply disable all tests
during the build.

Any better idea is welcome.

Bug#923319: #923319: dynalogin: FTBFS with pam >= 1.3

[Bernhard R. Link]

Control: retitle -1 dynalogin: FTBFS with pam >= 1.3

I think this problem is caused by three factors playing together:

- pam dropped support for PAM_STATIC with version 1.3.0
- libtool always compiles everything both as shared and as static
  object, even if it is a pam_module that only makes sense as shared
  object.
- dynalog is incorrectly defining PAM_STATIC compiled non-PIC.

AFAUI it PAM_STATIC was to be used to include a pam module into libpam
directly. As such it makes no sense for dynalogin to define it.
(Also searching for PAM_STATIC with codesearch.debian.net, usually
pam modules only check for it but do not define it (with very few
exceptions, and those I checked yet shishi and dynalogin have FTBFS
because of it)).

As libtool compiles everything both as static and as shared object
(as you might have some mechanism to also use them statically, and
libtool even have some mechanism where you can simulate loadable
plugins on architectures that only support static linking)
this needless build triggers that code.

But as pam 1.3.0 removed that possibility, it now fails.

I think the proper fix is to simple remove the following three lines:
#ifndef PIC
#define PAM_STATIC
#endif
from pam_dynalogin/pam_dynalogin.c

(Additionally it might be worth checking if setting
pam_dynalogin_la_LIBTOOLFLAGS = -shared
im Makefile.am is possible (not sure, as -shared is a compiler (so
LDFLAGS is too late) and a linker option, but not a generic option).
For a targeted fix, just not defining PAM_STATIC should be enough
and safer.)

(The same problem can also be seen in #924123 with shishi).

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Bug#926142: RFP: node-evacuated-pathwatcher -- path watcher nodejs module

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-evacuated-pathwatcher
  Version : 8.0.1
  Upstream Author : Github, inc.
* URL : 
https://salsa.debian.org/themusicgod1-guest/evacuated-pathwatcher
* License : MIT
  Programming Lang: javascript
  Description : path watcher nodejs module

Watch for changes on filename, where filename is either a file or a directory. 

node-evacuated-pathwatcher is a fork of node-pathwatcher.
It is a prerequisite of meteor ( #842425 ).

Bug#912467: Partial triaging

[Giovanni Mascellani]

Hi,

Il 30/03/19 15:06, Giovanni Mascellani ha scritto:
> I can try to devise a patch, but I do not know this API, so if there
> is someone more expert at that I would leave it to them. If not, I
> can give a try.

Using [1] and a partial previous patch by Andrej Shadura as a base, I
managed to create a patch that fixes FTBFS on jasperreports, which I
pushed to Salsa[2]. I did not test it because I do not know how to do
it. It would be nice if other members of the Java team reviewed my work
before uploading it, because I am not completely confident with the
changes that I made on the POM.

 [1]
https://github.com/TIBCOSoftware/jasperreports/commit/b7bd874137d357e0c27e04d1595086826c38995b
 [2]
https://salsa.debian.org/java-team/jasperreports/commit/90fdfb5a6f1e413ba81f9be56513a92605634350

HTH, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#926141: Please package version >= 0.5.3

[Thomas Goirand]

Package: python3-pyroute2
Version: 0.5.2-1
Severity: wishlist

Hi,

The last version of OpenStack needs pyroute2 >= 0.5.3. Could you please upload
a new upstream release to Experimental? Upstream has released 0.5.5, and
OpenStack Stein declares using 0.5.4.

If you have no time for this at least during this week, would you accept an NMU?

Also, why not pushing your package into Salsa, rather than Github, and doing
team maintenance? I would very much like to be listed as an Uploaders for this
package, as getting new upstream release in is a reoccuring issue.

Thanks for maintaining Pyroute2 in Debian,
Cheers,

Thomas Goirand (zigo)

Bug#849509: d-i modularity

[Geert Stappers]

On Mon, Apr 01, 2019 at 04:50:51AM +0800, ? Dan Jacobson wrote:
> I suppose in the logs, of
> 
> Mar 27 23:38:24 in-target: Preparing to unpack 
> .../popularity-contest_1.64_all.deb ...
> Mar 27 23:38:24 in-target: Unpacking popularity-contest (1.64) ...
> Mar 27 23:38:24 in-target: Setting up popularity-contest (1.64) ...
> Mar 27 23:38:24 in-target: Removing popularity-contest (1.64) ...
> Mar 27 23:38:24 in-target: Purging configuration files for popularity-contest 
> (1.64) ...
 
> In fact it is putting the money back into your account, from a temporary
> holding area, instead of forwarding it elsewhere. All very odd.
 
I do understand the "All very odd." After reading
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849509#22
which says "Yes, that's how the d-i modularity is handled here.". Was it
less odd to me. Right now I can give you
https://salsa.debian.org/installer-team/user-setup/blob/master/debian/control#L15
as clue.  Popcon will have also a XB-Installer-Menu-Item: entry in
debian/control.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#924123: shishi: FTBFS with pam >= 1.3 (was: with gcc 8.3)

[Bernhard R. Link]

Control: retitle -1 shishi: FTBFS with pam >= 1.3

Just some litte fly-by comment looking over RC bugs affecting testing:

I can also reproduce the FTBFS in an unstable chroot (so nothing testing
specific with that build failure).

The log is not really helpful here, as libtool only prints stderr of the
-DPIC compilation, but hides stderr of the non-PIC compilation, while
only the non-PIC compilation fails (the PIC case only produces harmless
warnings).

Unhiding the output of that gcc run gives the following result:

| pam_shishi.c: In function 'pam_sm_authenticate':
| pam_shishi.c:185:48: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
|pam_set_data (pamh, "shishi_setcred_return", (void *) retval, NULL);
| ^
| pam_shishi.c: At top level:
| pam_shishi.c:292:8: error: variable '_pam_shishi_modstruct' has initializer 
but incomplete type
|  struct pam_module _pam_shishi_modstruct = {
| ^~
| pam_shishi.c:293:3: warning: excess elements in struct initializer
|"pam_shishi",
|^~~~
| pam_shishi.c:293:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:294:3: warning: excess elements in struct initializer
|pam_sm_authenticate,
|^~~
| pam_shishi.c:294:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:295:3: warning: excess elements in struct initializer
|pam_sm_setcred,
|^~
| pam_shishi.c:295:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:296:3: warning: excess elements in struct initializer
|pam_sm_acct_mgmt,
|^~~~
| pam_shishi.c:296:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:297:3: warning: excess elements in struct initializer
|pam_sm_open_session,
|^~~
| pam_shishi.c:297:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:298:3: warning: excess elements in struct initializer
|pam_sm_close_session,
|^~~~
| pam_shishi.c:298:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:299:3: warning: excess elements in struct initializer
|pam_sm_chauthtok
|^~~~
| pam_shishi.c:299:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:292:19: error: storage size of '_pam_shishi_modstruct' isn't 
known
|  struct pam_module _pam_shishi_modstruct = {
|^
| /usr/include/security/pam_modules.h: In function 'pam_sm_authenticate':
| pam_shishi.c:127:7: warning: ignoring return value of 'asprintf', declared 
with attribute warn_unused_result [-Wunused-result]
|asprintf ((char **) [0].msg, "Password for `%s@%s': ",
|^~
|shishi_principal_default (h), shishi_realm_default (h));
|~~~

Looking at the sourcecode of the pam sourcepackage, it seems like suppor
for PAM_STATIC was removed with pam upstream 1.3.0, which hit Debian
with 1.3.1-3 uploaded 2019-02-12.

Taking a look at other pam_modules, they do not define PAM_STATIC
themself under any circumstances but only check it,
while extra/pam_shishi/pam_shishi.c contains:

| #ifndef PIC
| #define PAM_STATIC
| #endif

Looking around at some old pam documentation, my guess is that
PAM_STATIC is only to be used if modules are to be linked into libpam
directly. So I think those three lines above are in error and without
them this build failure might also be fixed.

@vorlon: could you take a look if my understanding of PAM_STATIC is
correct and it is nothing that should be defined if compiled as
an pam module outside of the pam source tree?

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Bug#924122: Users' eyes are drawn to "USB stick"

[Brian Potkin]

On Sat 09 Mar 2019 at 19:13:16 +0100, Holger Wansing wrote:

> Hi,
> 
> 積丹尼 Dan Jacobson  wrote:
> > Package: www.debian.org
> > 
> > On https://www.debian.org/devel/debian-installer/
> > users see:
> > "other images (netboot, USB stick, etc.)"
> > 
> > But in fact many of the other places above and below that can also be
> > used for USB sticks. In fact they are the more primary places...
> 
> Under https://www.debian.org/releases/stable/debian-installer/ for example,
> there is a note "all i386 and amd64 CD/DVD images can be used on USB sticks 
> too"
> to deal with this.
> 
> Maybe we should add such hint to 
> https://www.debian.org/devel/debian-installer/ too?

"Usb stick" isn't an image. "other images (netboot, hd-media, mini.iso)"
would be a more accurate and useful heading.

-- 
Brian.

Bug#889283: geany: Cannot install 1.32-2, because of geany plugins at version 1.32-1

[Simon John]

We have the same problem now - geany has been upgraded to 1.34.1-1 and 
all of the plugins are stuck on 1.33+dfsg-1 which means on dist-upgrade 
all of the plugins are removed unless you pin them.


Seems the binaries were upgraded just before (actually looks like 
after?!) the freeze and now I guess we have to wait until Buster is out 
the door before the plugins get updated to match?

Bug#925979: busybox-udeb: breaks user-params, rescue mode, etc.

[Ben Hutchings]

On Sat, 2019-03-30 at 13:33 +0100, Cyril Brulebois wrote:
> Heya,
> 
> Chris Boot  (2019-03-30):
[...]
> > I've also had a thought, and I can't remember if we've considered it
> > already: do the environment variables get preserved in
> > /proc/1/environ, even if busybox ash can't grok them? Could d-i be
> > modified to pull them from there?
> 
> Indeed, /proc/1/environ seems to have everyone!

Please note that /proc/$pid/environ is a live view of the region of a
process's virtual memory where the kernel originally wrote its
environment strings.  The process is free to overwrite or even unmap
this memory at any time.  (Even if it doesn't do that, any additions to
its environment will necessarily be outside that region.)

So I don't recommend using /proc/1/environ if you can avoid it.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.




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

Bug#926138: e2scrub_reap.service fails in LXC

[Theodore Ts'o]

On Sun, Mar 31, 2019 at 10:41:15PM +0200, Martin Pitt wrote:
> Package: e2fsprogs
> Version: 1.45.0-1
> 
> In a standard sid LXC container, this unit fails:
> 
> This is due to `AmbientCapabilities=CAP_SYS_ADMIN CAP_SYS_RAWIO`,
> and containers usually don't (and really should't) have RAWIO. Also,
> this unit seems fairly useless in containers anyway, as these only
> run on already mounted file systems.

Thanks for the bug report!

> Can you please consider adding
> 
>[Unit]
>ConditionVirtualization=!container

Hmm, I'm thinking instead of adding:

[Unit]
ConditionCapability=CAP_SYS_ADMIN
ConditionCapability=CAP_SYS_RAWIO

Could you test this and confirm whether or not this would correctly
cause the unit to be skipped for your lxc containers which don't have
CAP_SYS_RAWIO?

Thanks!

- Ted

Bug#926121: acl2: excessive build time on 32-bit architectures

[Camm Maguire]

Greetings!  Do you have a suggestion as to how to determine on 32bit
machines the total amount of heap (across all jobs) I might be able to
use for this build?

Take care,

Aurelien Jarno  writes:

> Source: acl2
> Version: 8.1dfsg-2
> Severity: important
>
> acl2 version 8.1dfsg-2 contains the following change:
>
> | * Limit number of jobs on memory restricted machines
>
> This change looks wrong and causes the build time to increase quite a
> lot on 32-bit architectures, even if they have a lot of RAM. For example
> on a fast i386 build daemon the build time went from ~5h to ~19h, which
> is not acceptable.
>
> The code computing the max number of jobs wrongly assume that the RAM
> corresponds to what a process can allocate on the heap. This is not true
> for 32-bit architectures, which can allocate only 2, 3 or 4GB per
> process depending on the architecture.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#924135: more cvs releated files

[Thomas Lange]

In the cron repository I found these files which may be obsolete after
moving to git:

log_accum.pl
commit_prep2
.cvsignore

-- 
regards Thomas

Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)

[Alexis Murzeau]

Le 31/03/2019 à 22:53, Alexis Murzeau a écrit :
> Le 31/03/2019 à 15:19, Aurelien Jarno a écrit :
>> This bug is very likely a bug present in old glibc versions. It has been
>> brought to light when enabling TLS support in openblas and not by a new
>> glibc version.
>>
>> Right now the bug has been workarounded by disabling TLS support in
>> openblas. The way to handle this bug is to write a small testcase that
>> can be forwarded upstream. It's not an easy task though.
>>
> 
> Hi,
> 
> I've made a test case here [0].
> I've not tested it against latest glibc commit.
> But it does reproduce the deadlock with glibc 2.28 on Linux.
> 
> To run the test case, do this:
> ```
> gcc test_compiler_tls.c -o test_compiler_tls -ldl -g -pthread
> gcc test_compiler_tls_lib.c -shared -o test_compiler_tls_lib.so \
>  -g -pthread -fPIC
> ./test_compiler_tls ./test_compiler_tls_lib &
> gdb --pid $! -ex 'thr a a bt'
> ```
> 
> This reproduce the deadlock that I've found in openblas:
> 1- The test_thread open the library which call its constructor
> 2- The library's constructor create a thread
>`thread_that_use_tls_after_sleep`
> 3- The thread `thread_that_use_tls_after_sleep` sleep for 100ms (this
>needs to be enough so dl_close is called before the sleep ends)
> 3- The test_thread close the library with dl_close
> 4- dl_close lock `dl_load_lock` and call the library's destructor
> 5- The library's destructor wait `thread_that_use_tls_after_sleep` to
>finish
> 6- The `thread_that_use_tls_after_sleep` thread try to read the TLS
>variable which cause a call to `__tls_get_addr`
> 7- `__tls_get_addr` cause a deadlock in `tls_get_addr_tail` trying to
>lock the same `dl_load_lock` as dl_close does
> 8- Nothing happen because dl_close thread is waiting for the
>`thread_that_use_tls_after_sleep` thread to finish which having the
>lock and the latter thread try to lock the same lock as dl_close and
>so never exit.
> 
> See [1] for the stacktrace.
> 
> Thread 3 is the library's thread created in its constructor and joined
> in its destructor.
> Thread 2 is the thread that does dl_open and dl_close.
> Thread 1 is a "monitoring" thread to implement a timeout of 10s (useful
> if this tests need to run on a CI system)
> 
> Where dl_close lock the `dl_load_lock`: [2]
> Where tls_get_addr_tail lock the `dl_load_lock`: [3]
> 
> [0]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7
> [1]:
> https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7#file-gdb_stacktrace-txt
> [2]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-close.c#L812
> [3]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-tls.c#L761
> 

Related links:
https://bugzilla.redhat.com/show_bug.cgi?id=1409899
https://sourceware.org/bugzilla/show_bug.cgi?id=2377


Actually, the hang is caused by a C++ here, but that's the same deadlock
(the C++ exception require the `dl_load_lock´ lock).

It seems from the first link that using thread stuff in constructor and
destructor is risky and not well supported and that applications should
just avoid doing this.

I didn't find a really related bug in sourceware bugzilla, maybe we
should forward our bug to them ?

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#926130: e2fsck returns 1 which makes e2scrub fails

[Theodore Ts'o]

On Sun, Mar 31, 2019 at 09:37:56PM +0200, Laurent Bigonville wrote:
> Package: e2fsprogs
> Version: 1.45.0-1
> Severity: important
> 
> Hi,
> 
> For one of my LV, e2scrub consistantly fails.
> 
> Debugging this it seems that e2fsck returns 1 but it's not showing any
> messages about reparing something.
> 
> According to the manpage, 1 means:
> 1- File system errors corrected

Can you send me (or attach to the bug) the output of running "e2scrub
"?

Thanks,

- Ted

Bug#926140: Subject: installation-reports: stuck on loading kernel cubieboard2

[Balthasar Szczepański]

Subject: installation-reports: stuck on loading kernel cubieboard2
Package: installation-reports
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

It was impossible t oinstall Debian on a Cuybieboard2, installer got
stuck, see below for details


-- Package-specific info:

Boot method: Tried both methods listed here:
 [200~https://wiki.debian.org/InstallingDebianOn/Allwinner [201~: from
SD card and from USB
Image version:
[200~https://get.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/firmware.Cubieboard2.img.gz
[201~,
 
[200~https://get.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz
[201~
for SD,  
[200~http://ftp.debian.org/debian/dists/stable/main/installer-armhf/current/images/hd-media/hd-media.tar.gz
[201~,
 
[200~https://cdimage.debian.org/debian-cd/current/armhf/bt-cd/debian-9.8.0-armhf-netinst.iso.torrent
[201~
for USB
Date: 2019-03-31 22:39

Machine: Cubieboard2
Partitions: SD card with the installer, SATA disk unpartitioned


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

The computer is a Cubieboard2 with the following things connected:
230VAC to 5VDC power supply,
1TB SATA hard disk.
serial port through a SP3232 chip.
Additionally during installation I also connected:
USB keyboard
HDMI screen
16GB SD card with installer on it
8GB USB drive with installer on it


In both cases, booting from SD and from USB the result is the same:
It reaches the step "Starting kernel..." and stays there forever.

I tried the obvious things like disconnecting SATA disk, HDMI screen,
USB keyboard and restarting. Didn't help.

Here is the log from serial console when using USB:

U-Boot SPL 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51 +) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Cubietech Cubieboard2
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

HDMI connected: Setting up a 1024x600 dvi console (overscan 0x0)
In:serial
Out:   vga
Err:   vga
SCSI:  Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   eth0: ethernet@01c5
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 2 USB Device(s) found
Hit any key to stop autoboot:  0
=> run bootcmd_usb0

USB device 0:
Device 0: Vendor: Generic  Rev: 8.07 Prod: Flash Disk
Type: Removable Hard Disk
Capacity: 7680.0 MB = 7.5 GB (15728640 x 512)
... is now current device
Scanning usb 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
1575 bytes read in 27 ms (56.6 KiB/s)
## Executing script at 4310
Mainline u-boot / new-style environment detected.
reading vmlinuz
3716200 bytes read in 338 ms (10.5 MiB/s)
reading dtbs/sun7i-a20-cubieboard2.dtb
34277 bytes read in 52 ms (643.6 KiB/s)
reading initrd.gz
13192685 bytes read in 1125 ms (11.2 MiB/s)
Booting the Debian installer...

## Flattened Device Tree blob at 4300
   Booting using the fdt blob at 0x4300
   Loading Ramdisk to 4936b000, end 49fffded ... OK
   Loading Device Tree to 4935f000, end 4936a5e4 ... OK

Starting kernel ...


and here when using SD card:

U-Boot SPL 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51 +) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Cubietech Cubieboard2
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

HDMI connected: Setting up a 1024x600 dvi console (overscan 0x0)
In:serial
Out:   vga
Err:   vga
SCSI:  Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   eth0: ethernet@01c5
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 

Bug#926139: gitlab: Missing or incorrect version of ruby-carrierwave

[Philippe Clérié]

Package: gitlab
Version: 11.4.9+dfsg-2~bpo9+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

gitlab could not be installed.

carrierwave 1.3.1 is installed but it's looking for 1.2.3. And there is
no 1.2.3 version in Debian.


Could not find gem 'carrierwave (= 1.2.3)' in any of the gem sources
listed in your Gemfile or available on this machine.  

dpkg: error processing package gitlab (--configure): 
 subprocess installed post-installation script returned error exit status 1
 Processing triggers for systemd (232-25+deb9u9) ...
 Errors were encountered while processing:
  gitlab
  E: Sub-process /usr/bin/dpkg returned an error code (1)


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

Kernel: Linux 4.15.0-46-generic (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitlab depends on:
...
ii  ruby-carrierwave   1.3.1-1~bpo9+1
...
...

Versions of packages gitlab recommends:
ii  certbot  0.28.0-1~bpo9+1
ii  gitaly   0.125.1+debian-3~bpo9+1

gitlab suggests no packages.

-- debconf information excluded

Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)

[Alexis Murzeau]

Le 31/03/2019 à 15:19, Aurelien Jarno a écrit :
> This bug is very likely a bug present in old glibc versions. It has been
> brought to light when enabling TLS support in openblas and not by a new
> glibc version.
> 
> Right now the bug has been workarounded by disabling TLS support in
> openblas. The way to handle this bug is to write a small testcase that
> can be forwarded upstream. It's not an easy task though.
> 

Hi,

I've made a test case here [0].
I've not tested it against latest glibc commit.
But it does reproduce the deadlock with glibc 2.28 on Linux.

To run the test case, do this:
```
gcc test_compiler_tls.c -o test_compiler_tls -ldl -g -pthread
gcc test_compiler_tls_lib.c -shared -o test_compiler_tls_lib.so \
 -g -pthread -fPIC
./test_compiler_tls ./test_compiler_tls_lib &
gdb --pid $! -ex 'thr a a bt'
```

This reproduce the deadlock that I've found in openblas:
1- The test_thread open the library which call its constructor
2- The library's constructor create a thread
   `thread_that_use_tls_after_sleep`
3- The thread `thread_that_use_tls_after_sleep` sleep for 100ms (this
   needs to be enough so dl_close is called before the sleep ends)
3- The test_thread close the library with dl_close
4- dl_close lock `dl_load_lock` and call the library's destructor
5- The library's destructor wait `thread_that_use_tls_after_sleep` to
   finish
6- The `thread_that_use_tls_after_sleep` thread try to read the TLS
   variable which cause a call to `__tls_get_addr`
7- `__tls_get_addr` cause a deadlock in `tls_get_addr_tail` trying to
   lock the same `dl_load_lock` as dl_close does
8- Nothing happen because dl_close thread is waiting for the
   `thread_that_use_tls_after_sleep` thread to finish which having the
   lock and the latter thread try to lock the same lock as dl_close and
   so never exit.

See [1] for the stacktrace.

Thread 3 is the library's thread created in its constructor and joined
in its destructor.
Thread 2 is the thread that does dl_open and dl_close.
Thread 1 is a "monitoring" thread to implement a timeout of 10s (useful
if this tests need to run on a CI system)

Where dl_close lock the `dl_load_lock`: [2]
Where tls_get_addr_tail lock the `dl_load_lock`: [3]

[0]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7
[1]:
https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7#file-gdb_stacktrace-txt
[2]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-close.c#L812
[3]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-tls.c#L761

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#849509: Can't blame the user for trying to read the messages

[積丹尼 Dan Jacobson]

I suppose in the logs, of

Mar 27 23:38:24 in-target: Preparing to unpack 
.../popularity-contest_1.64_all.deb ...
Mar 27 23:38:24 in-target: Unpacking popularity-contest (1.64) ...
Mar 27 23:38:24 in-target: Setting up popularity-contest (1.64) ...
Mar 27 23:38:24 in-target: Removing popularity-contest (1.64) ...
Mar 27 23:38:24 in-target: Purging configuration files for popularity-contest 
(1.64) ...

what one is seeing go by so fast in the little window is the latter part.

So the only thing the user has time to notice is the package name.

So he thinks you must be installing it, along with the other names he
sees fly by.

But in fact you are removing it.

Anyway if it said "transfer 5 euros?" and you hit "no",
would you still be happy if what you saw was
something about 5 go by below,
looking like the same message the last time when you said "yes".
In fact it is putting the money back into your account, from a temporary
holding area, instead of forwarding it elsewhere. All very odd.

Bug#926138: e2scrub_reap.service fails in LXC

[Martin Pitt]

Package: e2fsprogs
Version: 1.45.0-1

In a standard sid LXC container, this unit fails:

| ● e2scrub_reap.service - Remove Stale Online ext4 Metadata Check Snapshots
|Loaded: loaded (/lib/systemd/system/e2scrub_reap.service; enabled; vendor 
preset: enabled)
|Active: failed (Result: exit-code) since Sun 2019-03-31 20:31:21 UTC; 5min 
ago
|  Docs: man:e2scrub_all(8)
|  Main PID: 61 (code=exited, status=218/CAPABILITIES)
| 
| Mar 31 20:31:21 sid-amd64 systemd[1]: Starting Remove Stale Online ext4 
Metadata Check Snapshots...
| Mar 31 20:31:21 sid-amd64 systemd[61]: e2scrub_reap.service: Failed to apply 
ambient capabilities (before UID change): Operation not permitted
| Mar 31 20:31:21 sid-amd64 systemd[61]: e2scrub_reap.service: Failed at step 
CAPABILITIES spawning /sbin/e2scrub_all: Operation not permitted
| Mar 31 20:31:21 sid-amd64 systemd[1]: e2scrub_reap.service: Main process 
exited, code=exited, status=218/CAPABILITIES
| Mar 31 20:31:21 sid-amd64 systemd[1]: e2scrub_reap.service: Failed with 
result 'exit-code'.
| Mar 31 20:31:21 sid-amd64 systemd[1]: Failed to start Remove Stale Online 
ext4 Metadata Check Snapshots.

This is due to `AmbientCapabilities=CAP_SYS_ADMIN CAP_SYS_RAWIO`, and
containers usually don't (and really should't) have RAWIO. Also, this unit
seems fairly useless in containers anyway, as these only run on already mounted
file systems.

Can you please consider adding

   [Unit]
   ConditionVirtualization=!container

to the unit, to avoid this failure and noise?

Thank you!

Martin

Bug#905697: kdepimlibs: don't depend on libical

[Giovanni Mascellani]

user debian-rele...@lists.debian.org

usertags 905697 + bsp-2019-03-fr-paris
thank you

Hi,

On Thu, 14 Feb 2019 10:07:42 +0100 Emilio Pozuelo Monfort
 wrote:
> kde-runtime has dozens of rdeps, so unless its dep on kdepimlibs can be broken
> somehow, this would be much harder to solve for buster.

Hoping it might be helpful, I ported kdepimlibs to libical3. This should
finally make us able to remove libical2, I believe. With the attached
patch kdepimlibs compiles, but I did not try to use it (I am not a KDE
user, and much less a KDE PIM user). Could KDE maintainers test it?

My patch was mostly adapted from [1]. I am also attaching another patch
that explicitly sets QT_SELECT to version 4, so that build does not fail
even if Qt 5 is available.

 [1]
https://github.com/KDE/kcalcore/commit/27eaa211b23a6bb0bcba5a91cf7cadfc1e888e21?diff=unified

HTH, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
From 7ef777b77083500d06f9117096239c2e929858c1 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani 
Date: Sun, 31 Mar 2019 17:48:14 +0200
Subject: [PATCH 1/2] Select QT version 4.

---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 57ddfa6..7230a24 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,8 @@ libpkgs_addsubst_allLibraries = kdepimlibs5-dev
 libpkgs_gen_strict_local_shlibs = $(libpkgs_all_packages)
 include /usr/share/pkg-kde-tools/qt-kde-team/2/library-packages.mk
 
+export QT_SELECT=4
+
 override_dh_auto_configure:
 	$(overridden_command) -- -DKDE4_BUILD_TESTS=false
 
-- 
2.20.1

From 909fa74d0c745f9beda474d3affecaa7f2d2e2ca Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani 
Date: Sun, 31 Mar 2019 17:07:13 +0200
Subject: [PATCH 2/2] Port to libical3.

---
 debian/changelog  |   7 ++
 debian/control|   2 +-
 debian/patches/libical3.patch | 196 ++
 debian/patches/series |   1 +
 4 files changed, 205 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/libical3.patch

diff --git a/debian/changelog b/debian/changelog
index edd8c2b..ccfa2d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+kdepimlibs (4:4.14.10-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Port to libical3.
+
+ -- Giovanni Mascellani   Sun, 31 Mar 2019 17:06:59 +0200
+
 kdepimlibs (4:4.14.10-10) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 5809d2a..5f67151 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Build-Depends: cmake,
libboost-dev (>= 1.34),
libboost-graph-dev (>= 1.34.0~),
libgpgme11-dev,
-   libical2-dev (>= 0.42),
+   libical-dev,
libldap2-dev,
libqjson-dev,
libqt4-dev (>= 4:4.8),
diff --git a/debian/patches/libical3.patch b/debian/patches/libical3.patch
new file mode 100644
index 000..6b12024
--- /dev/null
+++ b/debian/patches/libical3.patch
@@ -0,0 +1,196 @@
+Description: Compile with libical3
+From: Giovanni Mascellani 
+Bug-Debian: https://bugs.debian.org/905697
+
+Index: kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp
+===
+--- kdepimlibs-4.14.10.orig/kcalcore/icalformat_p.cpp
 kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp
+@@ -2301,7 +2301,6 @@ icaltimetype ICalFormatImpl::writeICalDa
+ t.second = 0;
+ 
+ t.is_date = 1;
+-t.is_utc = 0;
+ t.zone = 0;
+ 
+ return t;
+@@ -2323,7 +2322,9 @@ icaltimetype ICalFormatImpl::writeICalDa
+ t.second = datetime.time().second();
+ }
+ t.zone = 0;   // zone is NOT set
+-t.is_utc = datetime.isUtc() ? 1 : 0;
++if (datetime.isUtc()) {
++t = icaltime_convert_to_zone(t, icaltimezone_get_utc_timezone());
++}
+ 
+ // _dumpIcaltime( t );
+ 
+@@ -2398,7 +2399,7 @@ icalproperty *ICalFormatImpl::writeICalD
+ }
+ 
+ KTimeZone ktz;
+-if (!t.is_utc) {
++if (!icaltime_is_utc(t)) {
+ ktz = dt.timeZone();
+ }
+ 
+@@ -2431,7 +2432,7 @@ KDateTime ICalFormatImpl::readICalDateTi
+ //  _dumpIcaltime( t );
+ 
+ KDateTime::Spec timeSpec;
+-if (t.is_utc  ||  t.zone == icaltimezone_get_utc_timezone()) {
++if (icaltime_is_utc(t)  ||  t.zone == icaltimezone_get_utc_timezone()) {
+ timeSpec = KDateTime::UTC;   // the time zone is UTC
+ utc = false;// no need to convert to UTC
+ } else {
+Index: kdepimlibs-4.14.10/kcalcore/icaltimezones.cpp
+===
+--- kdepimlibs-4.14.10.orig/kcalcore/icaltimezones.cpp
 kdepimlibs-4.14.10/kcalcore/icaltimezones.cpp
+@@ -54,7 +54,7 @@ static QDateTime toQDateTime(const icalt
+ {
+ return QDateTime(QDate(t.year, t.month, t.day),
+  QTime(t.hour, t.minute, t.second),
+- (t.is_utc ? Qt::UTC : 

Bug#926137: RM: coq-doc/8.6-1

[Benjamin Barenblat]

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

buster currently carries coq/8.9.0-1, but coq-doc still documents
Coq 8.6. Building the reference manual for 8.9.0 requires the ANTLR 4
runtime for Python 3, which is not in buster
(https://bugs.debian.org/926134). With the freeze in effect, it’s
looking pretty unlikely that coq-doc for Coq 8.9.0 is going to make it
into buster/non-free before the buster release gets finalized. Please
remove coq-doc and its binary packages (coq-doc, coq-doc-html, and
coq-doc-pdf) from buster/non-free.

Bug#842893: libxml-twig-perl: expand_external_ents fails to work as documented

[gregor herrmann]

On Sun, 31 Mar 2019 19:55:29 +0200, Moritz Mühlenhoff wrote:

> > +B: setting expand_external_ents to 0 or -1 currently doesn't work
> > +as expected; cf. L.
> > +To completelty turn off expanding external entities use C.
> > +
> > +=item no_xxe
> > +
> > +If this argument is set to a true value, expanding of external entities is
> > +turned off.
> > +
> 
> Looks great, that's exactly what i had in mind!

Great, thanks for the feedback!
 
> > In general, if we go ahead with something like this, I'm not sure if
> > we should really close this bug; the issue is mitigated by using and
> > documenting no_xxe but the expand_external_ents option is still buggy.
> > [0]. 
> I assume it was an oversight for expand_external_ents, but then they didn't
> want to break existing behaviour and only added no_xxe as a new option.
> Which (if properly documented) is fine, it's not uncommon that impacting
> changes are only hidden behind newly introduced flags for a lot of libraries.

Ok, makes sense.
 
> I think there's both arguments for closing and keeping the bug.

And the bug title is "… doesn't work as documented" which is no
longer true after the update of the documentation.

I've uploaded the packaged to DELAYED/2 right now and left the bug
closer in.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#926116: cross build failing - update-binfmts: warning: qemu-i386 not in database of installed binary formats.

[Johannes Schauer]

Hi Patrick,

Quoting Patrick Schleizer (2019-03-31 18:57:00)
> Dear maintainer,
> 
> # How to reproduce:
> 
> sudo /home/user/whonix_dot/Whonix/help-steps/mmdebstrap --verbose
> --architectures=i386 stretch /var/cache/pbuilder/base.cow_i386
> /home/user/whonix_dot/Whonix/build_sources/debian_stable_current_clearnet.list
> 
> (Could probably simplified but I hope you can reproduce this easily /
> hope you also have usr/bin/mkdir.)
> 
> # Expected result:
> 
> No error.
> 
> # Actual result:
> 
> > I: automatically chosen mode: root
> > I: i386 cannot be executed, falling back to qemu-user
> > update-binfmts: warning: qemu-i386 not in database of installed binary 
> > formats.
> > update-binfmts: exiting due to previous errors
> > qemu-i386 is not a supported binfmt name at 
> > /home/user/whonix_dot/Whonix/help-steps/mmdebstrap line 1838.
> 
> # Misc:
> 
> /usr/sbin/update-binfmts --display qemu-i386
> 
> > update-binfmts: warning: qemu-i386 not in database of installed binary 
> > formats.
> > update-binfmts: exiting due to previous errors
> 
> I guess the issue is somewhere here:
> 
> open my $fh, '-|', '/usr/sbin/update-binfmts', 
> '--display',
> "qemu-$options->{qemu}" // die "failed to fork(): $!";
> chomp (my $binfmts = do { local $/; <$fh> });
> close $fh;
> if ($binfmts eq '') {
> die "qemu-$options->{qemu} is not a supported binfmt 
> name";
> }
> 
> Removing
> die "qemu-$options->{qemu} is not a supported binfmt name";
> helps as a workaround. I can now build i386 on amd64.

qemu is only chosen because of the earlier message "i386 cannot be executed,
falling back to qemu-user" which occurs because the arch-test program
determined that i386 cannot be executed on amd64. This is not true and maybe
there is a bug in the arch-test package in stretch?

> 
> Building armhf or arm64 fails.
> 
> I: installing packages...
> /usr/sbin/chroot: failed to run command \u2018dpkg\u2019: Permission denied
> env --unset=APT_CONFIG /usr/sbin/chroot
> /var/cache/pbuilder/base.cow_arm64 dpkg --install --force-depends
> /var/cache/apt/archives//sysvinit-utils_2.88dsf-59.9_arm64.deb ...
> /home/user/whonix_dot/Whonix/help-steps/mmdebstrap line 551.
> 
> This might be more a user support question than actual bug. I hope you
> don't mind me asking here. Please kindly let me know if I should take
> this elsewhere please.
> 
> > dpkg -l | grep qemu
> > ii  ipxe-qemu 
> > 1.0.0+git-20161027.b991c67-1   all  PXE boot firmware - 
> > ROM images for qemu
> > ii  qemu  1:2.8+dfsg-6+deb9u5   
> >  amd64fast processor emulator
> > ii  qemu-slof 20161019+dfsg-1   
> >  all  Slimline Open Firmware -- QEMU PowerPC version
> > ii  qemu-system   1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU full system emulation binaries
> > ii  qemu-system-arm   1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU full system emulation binaries (arm)
> > ii  qemu-system-common1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU full system emulation binaries (common 
> > files)
> > ii  qemu-system-mips  1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU full system emulation binaries (mips)
> > ii  qemu-system-misc  1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU full system emulation binaries 
> > (miscellaneous)
> > ii  qemu-system-ppc   1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU full system emulation binaries (ppc)
> > ii  qemu-system-sparc 1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU full system emulation binaries (sparc)
> > ii  qemu-system-x86   1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU full system emulation binaries (x86)
> > ii  qemu-user 1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU user mode emulation binaries
> > ii  qemu-user-static  1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU user mode emulation binaries (static 
> > version)
> > ii  qemu-utils1:2.8+dfsg-6+deb9u5   
> >  amd64QEMU utilitie
> 
> I am using mmdebstrap (git version) and I am still on Debian stretch.
> Perhaps stretch is unsupported and all of this works in buster?

I have never tested this on stretch and would be surprised if it works there.
mmdebstrap makes use of very recent apt and dpkg options and I would not be
surprised if 

Bug#842893: libxml-twig-perl: diff for NMU version 1:3.50-1.1

[gregor herrmann]

Control: tags 842893 + pending


Dear maintainer,

I've prepared an NMU for libxml-twig-perl (versioned as 1:3.50-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru libxml-twig-perl-3.50/debian/changelog libxml-twig-perl-3.50/debian/changelog
--- libxml-twig-perl-3.50/debian/changelog	2016-08-04 18:52:02.0 +0200
+++ libxml-twig-perl-3.50/debian/changelog	2019-03-31 22:18:27.0 +0200
@@ -1,3 +1,15 @@
+libxml-twig-perl (1:3.50-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "CVE-2016-9180: expand_external_ents fails to work as
+documented": add patch CVE-2016-9180.patch:
+- update documentation about expand_external_ents and no_xxe
+- add test for expand_external_ents and no_xxe
+Additionally add build dependency on libtest-exception-perl.
+(Closes: #842893)
+
+ -- gregor herrmann   Sun, 31 Mar 2019 22:18:27 +0200
+
 libxml-twig-perl (1:3.50-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libxml-twig-perl-3.50/debian/control libxml-twig-perl-3.50/debian/control
--- libxml-twig-perl-3.50/debian/control	2016-08-04 18:52:02.0 +0200
+++ libxml-twig-perl-3.50/debian/control	2019-03-30 19:36:50.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Bart Martens 
 Standards-Version: 3.9.8
-Build-Depends-Indep: perl (>= 5.6.0-16), libxml-parser-perl, libunicode-map8-perl, libunicode-string-perl, libtie-ixhash-perl, libxml-xpathengine-perl | libxml-xpath-perl, libtest-pod-perl, libtest-pod-coverage-perl (>= 1.00), libxml-handler-yawriter-perl, libxml-sax-machines-perl, libxml-simple-perl, libyaml-perl
+Build-Depends-Indep: perl (>= 5.6.0-16), libxml-parser-perl, libunicode-map8-perl, libunicode-string-perl, libtie-ixhash-perl, libxml-xpathengine-perl | libxml-xpath-perl, libtest-pod-perl, libtest-pod-coverage-perl (>= 1.00), libxml-handler-yawriter-perl, libxml-sax-machines-perl, libxml-simple-perl, libyaml-perl, libtest-exception-perl
 Build-Depends: debhelper (>= 8.0.0), expat
 Homepage: http://www.xmltwig.org/
 
diff -Nru libxml-twig-perl-3.50/debian/patches/CVE-2016-9180.patch libxml-twig-perl-3.50/debian/patches/CVE-2016-9180.patch
--- libxml-twig-perl-3.50/debian/patches/CVE-2016-9180.patch	1970-01-01 01:00:00.0 +0100
+++ libxml-twig-perl-3.50/debian/patches/CVE-2016-9180.patch	2019-03-31 01:06:09.0 +0100
@@ -0,0 +1,85 @@
+Description: Update documentation for XML::Twig.
+ Mention problems with expand_external_ents and add
+ information about new no_xxe argument.
+ .
+ Additionally add tests for both expand_external_ents and no_xxe.
+Origin: vendor
+Bug: https://rt.cpan.org/Public/Bug/Display.html?id=118097
+Bug-Debian: https://bugs.debian.org/842893
+Author: gregor herrmann 
+Last-Update: 2019-03-30
+
+--- a/Twig_pm.slow
 b/Twig_pm.slow
+@@ -10454,6 +10454,15 @@
+ pubid =>  }). Yes, this is a bit of a hack, but it's useful in some
+ cases.  
+ 
++B: setting expand_external_ents to 0 or -1 currently doesn't work
++as expected; cf. L.
++To completelty turn off expanding external entities use C.
++
++=item no_xxe
++
++If this argument is set to a true value, expanding of external entities is
++turned off.
++
+ =item load_DTD
+ 
+ If this argument is set to a true value, C or C on the twig
+--- /dev/null
 b/t/CVE-2016-9180.t
+@@ -0,0 +1,41 @@
++#!/usr/bin/perl
++
++use strict;
++use warnings;
++use Test::More;
++use Test::Exception;
++
++BEGIN { use_ok('XML::Twig'); }
++
++my $twig = XML::Twig->new( expand_external_ents => 1 );
++$twig->parsefile('t/CVE-2016-9180.xml');
++my $result = $twig->sprint;
++like( $result, qr/Boom/, 'external entity expanded (expand_external_ents 1)' );
++
++TODO: {
++local $TODO = 'This test currently fails: https://rt.cpan.org/Public/Bug/Display.html?id=118097';
++
++$twig = XML::Twig->new( expand_external_ents => 0 );
++$twig->parsefile('t/CVE-2016-9180.xml');
++$result = $twig->sprint;
++unlike( $result, qr/Boom/,
++'external entity not expanded (expand_external_ents 0)' );
++
++$twig = XML::Twig->new( expand_external_ents => -1 );
++$twig->parsefile('t/CVE-2016-9180.xml');
++$result = $twig->sprint;
++unlike( $result, qr/Boom/,
++'external entity not expanded and no fail (expand_external_ents -1)' );
++
++}
++
++$twig = XML::Twig->new( no_xxe => 1 );
++throws_ok { $twig->parsefile('t/CVE-2016-9180.xml') } qr/cannot expand /,
++'external entity not expanded (no_xxe 1)';
++
++$twig = XML::Twig->new( no_xxe => 0 );
++$twig->parsefile('t/CVE-2016-9180.xml');
++$result = $twig->sprint;
++like( $result, qr/Boom/, 'external entity expanded (no_xxe 0)' );
++
++done_testing();
+--- /dev/null
 

Bug#925899: lxc: Unprivileged containers fail to start after recent updates

[Regis Smith]

On Sun, 31 Mar 2019 14:55:52 +0200 intrigeri 
wrote:
> Hi,
> 
> Regis Smith:
> >> > lxc-start: test: lsm/apparmor.c: apparmor_prepare: 974 Cannot
use
> > generated profile: apparmor_parser not available
> 
> I've reproduced this problem and I could fix it with:
> 
>   lxc.apparmor.profile = unconfined
> 
> Regis, can you please confirm this fix works for you as well?
> 

Yes, this works.  Thanks!  This was the old solution required in Jessie
or early Stretch (w/o backports), so people may still complain after
Buster is released :)  But I'm happpy if I can reliably start
unprivileged containers again, which "unconfined" does.

Regis

Bug#926136: stretch-pu: package zziplib/0.13.62-3.2~deb9u1

[Salvatore Bonaccorso]

On Sun, Mar 31, 2019 at 10:14:30PM +0200, Salvatore Bonaccorso wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi Stable release managers,
> 
> Several CVEs were adressed with the 0.13.62-3.2 to unstable (and
> buster) which are CVE-2018-6381, CVE-2018-6484, CVE-2018-6541,
> CVE-2018-6869, CVE-2018-6540, CVE-2018-7725, CVE-2018-7726 and
> CVE-2018-16548.
> 
> Given 0.13.62-3.1 beeing in stable and 0.13.62-3.2 consisted only on
> those CVE fixes, I would like to propose a rebuild of 0.13.62-3.2 to
> be included in stretch in the upcoming point release and adress those
> CVEs.
> 
> > zziplib (0.13.62-3.2~deb9u1) stretch; urgency=medium
> > 
> >   * Rebuild for stretch-backports.

Whoops, sorry. The local prepared package has already correctly
Rebuild for stretch. Not stretch-backports.

Regards,
Salvatore

Bug#926134: antlr4: Please package Python 3 runtime

[Benjamin Barenblat]

On Sunday, March 31, 2019, at  3:52 PM EDT, Benjamin Barenblat wrote:
> Coq now needs the ANTLR 4 runtime for Python 3 to generate its HTML
> documentation.

Er, correction: Some HTML documentation can be built without the
runtime. However, you need the runtime to build the reference manual,
and that actually holds true whether you’re building PDF or HTML.

Bug#925567: gcc-8-cross: FTBFS: conftest.c:72: undefined reference to `getexecname'

[Bernhard R. Link]

Control: retitle 925567 gcc-8-cross: FTBFS: out of memory allocating 4064 bytes 
after a total of 155293664 bytes
Control: notfound 925567 gcc-8-cross/26
Control: fixed 925567 gcc-8-cross/26

The error message the build failed with according to the linked log is actually:

| out of memory allocating 4064 bytes after a total of 155293664 bytes
| cc1plus: out of memory allocating 65536 bytes after a total of 3620864 bytes

(The "undefined reference to `getexecname'" if part of a check an no
error but part of the full config.log)

This bugs still appears on
https://bugs.debian.org/release-critical/other/testing.html, I guess
because bugs.debian.org says:

   Found in version gcc-8-cross/26
   Fixed in version 26

and thus thinks testing is still affected.
I'm trying to send some notfound and fixed commands to clear that.


Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Bug#923759: Update

[Andreas Tille]

Merged and adapted d/changelog.  Will be uploaded after buster release.
Thanks a lot for your enhancements, Andreas.

On Sun, Mar 31, 2019 at 09:10:40PM +0200, Markus Koschany wrote:
> Hi,
> 
> Am 31.03.19 um 20:59 schrieb Dominik Stadler:
> > I think the current changes do not properly fix this, I created
> > https://salsa.debian.org/java-team/netlib-java/merge_requests/2 with the
> > set of changes based on previous patches that I think would make the
> > classes be built again and also improve error handling slightly to make
> > it easier to spot the actual error during building.
> 
> The latest revision of netlib-java does fix the class file generation
> bug. It was already accepted by the release team. Your other changes can
> be included in a future update of the package. I'm sure Andreas (CCed)
> is interested in patches and will merge them.
> 
> Regards,
> 
> Markus
> 




-- 
http://fam-tille.de

Bug#924145: stretch-pu: package vips/8.4.5-1+deb9u1

[GCS]

On Sun, Mar 31, 2019 at 8:52 PM Adam D. Barratt
 wrote:
> Control: tags -1 + confirmed
>
> On Sat, 2019-03-09 at 22:14 +0100, László Böszörményi wrote:
> > There are two security issues in VIPS, which don't warrant a DSA.
> > I would like to update it via PU. Debdiff is attached.
>
> Please go ahead.
 Thanks, uploaded.

Cheers,
Laszlo/GCS

Bug#926136: stretch-pu: package zziplib/0.13.62-3.2~deb9u1

[Salvatore Bonaccorso]

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

Hi Stable release managers,

Several CVEs were adressed with the 0.13.62-3.2 to unstable (and
buster) which are CVE-2018-6381, CVE-2018-6484, CVE-2018-6541,
CVE-2018-6869, CVE-2018-6540, CVE-2018-7725, CVE-2018-7726 and
CVE-2018-16548.

Given 0.13.62-3.1 beeing in stable and 0.13.62-3.2 consisted only on
those CVE fixes, I would like to propose a rebuild of 0.13.62-3.2 to
be included in stretch in the upcoming point release and adress those
CVEs.

> zziplib (0.13.62-3.2~deb9u1) stretch; urgency=medium
> 
>   * Rebuild for stretch-backports.
> 
>  -- Salvatore Bonaccorso   Sun, 31 Mar 2019 22:02:00 +0200
> 
> zziplib (0.13.62-3.2) unstable; urgency=medium
> 
>   * Non-maintainer upload.
>   * Invalid memory access in zzip_disk_fread (CVE-2018-6381) (Closes: #889096)
>   * Reject the ZIP file and report it as corrupt if the size of the central
> directory and/or the offset of start of central directory point beyond the
> end of the ZIP file (CVE-2018-6484, CVE-2018-6541, CVE-2018-6869)
> (Closes: #889089)
>   * bus error in zzip_disk_findfirst function in zzip/mmapped.c
> (CVE-2018-6540) (Closes: #923659)
>   * out of bound read in mmapped.c:zzip_disk_fread() causes crash
> (CVE-2018-7725) (Closes: #913165)
>   * Bus error in zip.c:__zzip_parse_root_directory() cause crash via crafted
> zip file (CVE-2018-7726) (Closes: #913165)
>   * Memory leak triggered in the function __zzip_parse_root_directory in zip.c
> (CVE-2018-16548) (Closes: #910335)
> 
>  -- Salvatore Bonaccorso   Mon, 04 Mar 2019 22:43:14 +0100

Attaching the debdiff against 0.13.62-3.1.

AFAICS no regression were reported for 0.13.62-3.2.

Regards,
Salvatore
diff -Nru zziplib-0.13.62/debian/changelog zziplib-0.13.62/debian/changelog
--- zziplib-0.13.62/debian/changelog2017-06-04 09:03:20.0 +0200
+++ zziplib-0.13.62/debian/changelog2019-03-31 22:02:00.0 +0200
@@ -1,3 +1,28 @@
+zziplib (0.13.62-3.2~deb9u1) stretch; urgency=medium
+
+  * Rebuild for stretch-backports.
+
+ -- Salvatore Bonaccorso   Sun, 31 Mar 2019 22:02:00 +0200
+
+zziplib (0.13.62-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Invalid memory access in zzip_disk_fread (CVE-2018-6381) (Closes: #889096)
+  * Reject the ZIP file and report it as corrupt if the size of the central
+directory and/or the offset of start of central directory point beyond the
+end of the ZIP file (CVE-2018-6484, CVE-2018-6541, CVE-2018-6869)
+(Closes: #889089)
+  * bus error in zzip_disk_findfirst function in zzip/mmapped.c
+(CVE-2018-6540) (Closes: #923659)
+  * out of bound read in mmapped.c:zzip_disk_fread() causes crash
+(CVE-2018-7725) (Closes: #913165)
+  * Bus error in zip.c:__zzip_parse_root_directory() cause crash via crafted
+zip file (CVE-2018-7726) (Closes: #913165)
+  * Memory leak triggered in the function __zzip_parse_root_directory in zip.c
+(CVE-2018-16548) (Closes: #910335)
+
+ -- Salvatore Bonaccorso   Mon, 04 Mar 2019 22:43:14 +0100
+
 zziplib (0.13.62-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
zziplib-0.13.62/debian/patches/Avoid-memory-leak-from-__zzip_parse_root_directory-1.patch
 
zziplib-0.13.62/debian/patches/Avoid-memory-leak-from-__zzip_parse_root_directory-1.patch
--- 
zziplib-0.13.62/debian/patches/Avoid-memory-leak-from-__zzip_parse_root_directory-1.patch
   1970-01-01 01:00:00.0 +0100
+++ 
zziplib-0.13.62/debian/patches/Avoid-memory-leak-from-__zzip_parse_root_directory-1.patch
   2019-03-31 22:02:00.0 +0200
@@ -0,0 +1,74 @@
+From: jmoellers 
+Date: Fri, 7 Sep 2018 11:32:04 +0200
+Subject: Avoid memory leak from __zzip_parse_root_directory().
+Origin: 
https://github.com/gdraheim/zziplib/commit/9411bde3e4a70a81ff3ffd256b71927b2d90dcbb
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-16548
+Bug-Debian: https://bugs.debian.org/910335
+Bug: https://github.com/gdraheim/zziplib/issues/58
+
+---
+
+diff --git a/zzip/zip.c b/zzip/zip.c
+index 88b833b2533d..a6852802f87e 100644
+--- a/zzip/zip.c
 b/zzip/zip.c
+@@ -475,9 +475,15 @@ __zzip_parse_root_directory(int fd,
+ } else
+ {
+ if (io->fd.seeks(fd, zz_rootseek + zz_offset, SEEK_SET) < 0)
++  {
++  free(hdr0);
+ return ZZIP_DIR_SEEK;
++  }
+ if (io->fd.read(fd, , sizeof(dirent)) < __sizeof(dirent))
++  {
++  free(hdr0);
+ return ZZIP_DIR_READ;
++  }
+ d = 
+ }
+ 
+@@ -577,12 +583,38 @@ __zzip_parse_root_directory(int fd,
+ 
+ if (hdr_return)
+ *hdr_return = hdr0;
++  else
++  {
++  /* If it is not assigned to *hdr_return, it will never be free()'d 
*/
++  free(hdr0);
++  /* Make sure we don't free it again in case of error */
++  hdr0 = 

Bug#926021: unblock: lam/7.1.4-6

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Sat, Mar 30, 2019 at 09:53:55AM -0400, Camm Maguire wrote:
> This package represents a minimal change to restore alternative
> compatibility with the other mpi implementations in Debian (see #924452,
> #922633).  It will also remove FTBFS issues for existing netpipe and
> xmpi packages in testing.  In all, three AUTORM issues will be resolved.
> 
> Take care,
> 
> =
> source debdiff
> =
> diff -Nru lam-7.1.4/debian/changelog lam-7.1.4/debian/changelog
> --- lam-7.1.4/debian/changelog2014-03-15 02:47:33.0 +
> +++ lam-7.1.4/debian/changelog2019-03-29 17:36:04.0 +
> @@ -1,4 +1,39 @@
> -lam (7.1.4-3.1) unstable; urgency=medium
> +lam (7.1.4-6) unstable; urgency=medium
> +
> +  * Minimal RC fix for testing migration
> +
> + -- Camm Maguire   Fri, 29 Mar 2019 17:36:04 +
> +
> +lam (7.1.4-5) unstable; urgency=medium
> +
> +  * fix /usr/lib/lam/lib/* links in lam4-dev
> +
> + -- Camm Maguire   Mon, 25 Mar 2019 02:24:32 +
> +
> +lam (7.1.4-4) unstable; urgency=high
> +
> +  * Accept non-maintaner upload.  Thanks Eric Dorland 
> +  * priority optional, thanks Andreas Beckmann 
> +  * debhelper compat level 9
> +  * remove obsolete conflicts/replace, thanks Andreas Beckmann 
> 
> +  * remove mpi virtual package, thanks Andreas Beckmann 
> +  * add breaks against old style alternatives, thanks Andreas Beckmann
> +  
> +  * multiarch for liblam4, thanks Andreas Beckmann 
> +  * multiarch support in lam4-dev.{prerm,postinst}.in and rules, thanks 
> Andreas
> +  Beckmann , (Closes: #924452, #922633)
> +  * remove old mpi alternative when appropriate in lam4-dev.preinst, thanks
> +  Andreas Beckmann 
> +  * remove obsolete ldconfig call in liblam4.postinst, thanks Andreas 
> Beckmann
> +  
> +  * thanks to Aron Xu.  (Closes: #721437)
> +  * standard debian build flags
> +  * lintian cleanups
> +  * latest standards
> +
> + -- Camm Maguire   Thu, 21 Mar 2019 21:53:46 +

I'm afraid this is not "minimal changes". In particular the multi-arch and
debhelper compat level changes are not appropriate at this stage.

I also have concerns about this package being abandoned upstream since
2015, as described in #922633.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#926065: unblock: diffoscope/113

[Holger Levsen]

On Sun, Mar 31, 2019 at 09:10:00PM +0100, Jonathan Wiltshire wrote:
> Unblocked; thanks.

\o/ & thank you too!


-- 
tschau,
Holger

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


signature.asc
Description: PGP signature

Bug#926135: RM: mariadb-connector-c -- ROM; obsoleted by mariadb-10.3

[Otto Kekäläinen]

Package: ftp.debian.org
Severity: normal

Please remove src:mariadb-connector-c from unstable.

MariaDB Connector C is nowadays built from sources of by MariaDB 10.3.
The source package mariadb-10.3 produces produces all the binary
packages mariadb-connector-c used to produce.

Current mariadb-connector-c in unstable is already in state "has no
binaries on any arch". See:
https://tracker.debian.org/pkg/mariadb-connector-c

It has however not been autoremoved so I decided to file this issue to
bring it to the attention of ftp-masters.


Thank you ftp-masters!

Bug#926134: antlr4: Please package Python 3 runtime

[Benjamin Barenblat]

Source: antlr4
Version: 4.7.2-1

Coq now needs the ANTLR 4 runtime for Python 3 to generate its HTML
documentation. Would you be willing to add it to the antlr4 package?

This may be a duplicate of https://bugs.debian.org/897129, but lacking
familiarity with ANTLR, it’s not clear to me whether that bug is asking
for the runtime or for bindings to script against ANTLR.

Bug#926123: unblock: cabextract/1.9-2

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Sun, Mar 31, 2019 at 08:20:52PM +0200, Jens Reyer wrote:
> I'm not the maintainer of cabextract, but of winetricks which is affected by
> #914263 (cabextract: -F option doesn't work correctly.)
> 
> #914263 is a duplicate of #912687 (libmspack0: Regression when extracting
> cabinets using -F
> option fixed upstream, needs to be patched), see my previous unblock request
> #926118.  It was fixed by:
> 
> cabextract (1.9-2) unstable; urgency=medium
> 
>   * Force libmspack0 version >= 0.9.1-1 to avoid bugs in that
> package: Closes: #914263
> 
>  -- Eric Sharkey   Sun, 09 Dec 2018 08:06:55 -0500
> 
> Other changes I found in the debdiff:
> - Bump debhelper version from 7 to 11
> - Bump Standards-Version from 3.9.6 to 4.2.1
> - d/rules target install: build
>   drop dh_clean -k, add dh_prep

The debhelper compat change is a problem. Would you or the maintainer be
interested in an upload reverting it?


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#926133: poppler: CVE-2019-10018

[Salvatore Bonaccorso]

Source: poppler
Version: 0.71.0-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for poppler.

CVE-2019-10018[0]:
| An issue was discovered in Xpdf 4.01.01. There is an FPE in the
| function PostScriptFunction::exec at Function.cc for the psOpIdiv
| case.

The above issue originally reported for Xpdf seems to actually affect
poppler. Cf. [1]. Might you check with upstream to double check? I
explicitly this time have not set any affected version as its not
fully clear.

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-10018
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10018
[1] https://forum.xpdfreader.com/viewtopic.php?f=3=41276

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#926131: footer: replace identi.ca with micronews

[Ana Guerrero Lopez]

Package: www.debian.org

Hi,

I'd say it's about time we drop identi.ca/debian from the footer 
and add instead a link to micronews.debian.org

Thoughts?

Cheers,
Ana

Bug#926132: unblock: curl/7.64.0-2

[Alessandro Ghedini]

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

Please unblock package curl

The version in sid fixes #922554, which affects several users of NetworkManager.
and is marked as important (the patch is backported from upstream).

Debdiff is attached.

At the time I uploaded it I expected it to migrate to testing before the freeze,
but apparently I did the math wrong. Anyway an unrelated change adding a couple
of entries to the previous upload'ss changelog was also included (as you can see
from the debdiff), hope that's not too much of a problem.

unblock curl/7.64.0-2

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 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)
diff -Nru curl-7.64.0/debian/changelog curl-7.64.0/debian/changelog
--- curl-7.64.0/debian/changelog	2019-02-06 22:33:05.0 +
+++ curl-7.64.0/debian/changelog	2019-03-07 20:02:35.0 +
@@ -1,3 +1,9 @@
+curl (7.64.0-2) unstable; urgency=medium
+
+  * Fix infinite loop when fetching URLs with unreachable IPv6 (Closes: #922554)
+
+ -- Alessandro Ghedini   Thu, 07 Mar 2019 20:02:35 +
+
 curl (7.64.0-1) unstable; urgency=medium
 
   * New upstream release
@@ -8,6 +14,8 @@
 + Fix SMTP end-of-response out-of-bounds read as per CVE-2019-3823
   https://curl.haxx.se/docs/CVE-2019-3823.html
 + Fix HTTP negotiation with POST requests (Closes: #920267)
+  * Refresh patches
+  * Import fixes for zsh completion script generator (Closes: #92145)
 
  -- Alessandro Ghedini   Wed, 06 Feb 2019 22:33:05 +
 
diff -Nru curl-7.64.0/debian/patches/13_singlesocket-fix-the-sincebefore-placement.patch curl-7.64.0/debian/patches/13_singlesocket-fix-the-sincebefore-placement.patch
--- curl-7.64.0/debian/patches/13_singlesocket-fix-the-sincebefore-placement.patch	1970-01-01 01:00:00.0 +0100
+++ curl-7.64.0/debian/patches/13_singlesocket-fix-the-sincebefore-placement.patch	2019-03-07 20:02:35.0 +
@@ -0,0 +1,38 @@
+From afc00e047c773faeaa60a5f86a246cbbeeba5819 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Tue, 19 Feb 2019 15:56:54 +0100
+Subject: [PATCH] singlesocket: fix the 'sincebefore' placement
+
+The variable wasn't properly reset within the loop and thus could remain
+set for sockets that hadn't been set before and miss notifying the app.
+
+This is a follow-up to 4c35574 (shipped in curl 7.64.0)
+
+Reported-by: buzo-ffm on github
+Detected-by: Jan Alexander Steffens
+Fixes #3585
+Closes #3589
+---
+ lib/multi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/lib/multi.c
 b/lib/multi.c
+@@ -2360,8 +2360,6 @@
+   int num;
+   unsigned int curraction;
+   int actions[MAX_SOCKSPEREASYHANDLE];
+-  unsigned int comboaction;
+-  bool sincebefore = FALSE;
+ 
+   for(i = 0; i< MAX_SOCKSPEREASYHANDLE; i++)
+ socks[i] = CURL_SOCKET_BAD;
+@@ -2380,6 +2378,8 @@
+   i++) {
+ unsigned int action = CURL_POLL_NONE;
+ unsigned int prevaction = 0;
++unsigned int comboaction;
++bool sincebefore = FALSE;
+ 
+ s = socks[i];
+ 
diff -Nru curl-7.64.0/debian/patches/series curl-7.64.0/debian/patches/series
--- curl-7.64.0/debian/patches/series	2019-02-06 22:33:05.0 +
+++ curl-7.64.0/debian/patches/series	2019-03-07 20:02:35.0 +
@@ -4,6 +4,7 @@
 08_enable-zsh.patch
 11_omit-directories-from-config.patch
 12_zsh.patch
+13_singlesocket-fix-the-sincebefore-placement.patch
 
 # do not add patches below
 90_gnutls.patch


signature.asc
Description: PGP signature

Bug#926076: goxkcdpwgen -- xkcd style password generator library and cli tool

[Phil Morrell]

On Sun, Mar 31, 2019 at 05:27:03PM +0530, Dhanya Thailappan wrote:
> * Package name: goxkcdpwgen
>   Version : 0.0~git20181107.de898c7-1
>   Upstream Author : Martin Hoefling
> * URL : https://github.com/martinhoefling/goxkcdpwgen
> * License : MIT
>   Programming Lang: Go
>   Description : xkcd style password generator library and cli tool

Hello,

How does this compare to the diceware package? Even the available
parameters are very similar. Perhaps you could consider submitting the
de_wordlist.txt to the diceware project?

https://tracker.debian.org/pkg/diceware
https://github.com/ulif/diceware#usage
--
Phil Morrell


signature.asc
Description: PGP signature

Bug#924800: [PATCH] resolve race in test cleanup by making second attempt more forceful

[Sean Whitton]

Errors are like this:

.t/gpgtest/9/S.gpg-agent.extra: 
removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:r
 emovePathRecursive:getSymbolicLinkStatus: does not exist (No such file or 
directory)

i.e. the problem seems to be files vanishing while
removeDirectoryRecursive is running.  removePathForcibly ignores such
errors.

Reported-by: Lucas Nussbaum 
Signed-off-by: Sean Whitton 
---
 Test/Framework.hs | 2 +-
 git-annex.cabal   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Test/Framework.hs b/Test/Framework.hs
index 410eb6713..45bdf9374 100644
--- a/Test/Framework.hs
+++ b/Test/Framework.hs
@@ -271,7 +271,7 @@ finalCleanup = whenM (doesDirectoryExist tmpdir) $ do
Utility.ThreadScheduler.Seconds 10
whenM (doesDirectoryExist tmpdir) $ do
Annex.Action.reapZombies
-   removeDirectoryRecursive tmpdir
+   removePathForcibly tmpdir

 checklink :: FilePath -> Assertion
 checklink f =
diff --git a/git-annex.cabal b/git-annex.cabal
index 9b7eb9516..653621580 100644
--- a/git-annex.cabal
+++ b/git-annex.cabal
@@ -313,7 +313,7 @@ Executable git-annex
unix-compat,
SafeSemaphore,
async,
-   directory (>= 1.2),
+   directory (>= 1.2.7.0),
disk-free-space,
filepath,
IfElse,
-- 
2.20.1

Bug#924634:

[Dominik Stadler]

Not sure if I read the package-pages correctly, but
https://packages.debian.org/search?keywords=libspring-jms-java=names=all=all
looks to me like libspring-jms-java is still (or again) available both in
buster and sid, so this bug is not a problem any more, right?

Bug#924888: (no subject)

[Thomas Lange]

the link to mirroring Debian is also available on the /devel page
-- 
regards Thomas

Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2

[Roberto C . Sánchez]

On Sun, Mar 31, 2019 at 08:09:27PM +0100, Adam D. Barratt wrote:
> On Thu, 2018-11-01 at 21:07 -0400, Roberto C.Sánchez wrote:
> > On Thu, Nov 01, 2018 at 06:50:53PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + moreinfo
> > > 
> > > On Wed, 2018-10-31 at 23:25 -0400, Roberto C. Sanchez wrote:
> > > > I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2)
> > > > related to CVE-2018-16336 and also including a minor fix to the
> > > > previous patch for CVE-2018-10958 and CVE-2018-10999.
> > > 
> > > The Security Tracker indicates that CVE-2018-16336 is as-yet
> > > unfixed in
> > > unstable; is that correct?
> > > 
> > 
> > Hi Adam,
> > 
> > That is correct.  I completely overlooked it.  I will check with the
> > maintainers about their plans for unstable.
> 
> Was there any progress there? The issue is still marked as affecting
> unstable in the tracker.
> 
No real progress.  I sent a message [0] to the packaging team's mailing
list that same day (1st November).  Salvatore responded a few days
later, but there was no response after that.

Regards,

-Roberto

[0] 
https://alioth-lists.debian.net/pipermail/pkg-kde-extras/2018-November/029728.html

-- 
Roberto C. Sánchez

Bug#924888: why bsd.license?

[Thomas Lange]

I wonder why bsd.license is needed in /misc, because it's not
referenced except in the makefile
-- 
regards Thomas

Bug#926130: e2fsck returns 1 which makes e2scrub fails

[Laurent Bigonville]

Package: e2fsprogs
Version: 1.45.0-1
Severity: important

Hi,

For one of my LV, e2scrub consistantly fails.

Debugging this it seems that e2fsck returns 1 but it's not showing any
messages about reparing something.

According to the manpage, 1 means:
1- File system errors corrected

If I'm umounting the FS and then run e2scrub, it returns 0

Any idea how to debug this further?

Regards,
Laurent Bigonville

-- System Information:
Debian Release: buster/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 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages e2fsprogs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-8
ii  libcom-err2  1.45.0-1
ii  libext2fs2   1.45.0-1
ii  libss2   1.45.0-1
ii  libuuid1 2.33.1-0.1

Versions of packages e2fsprogs recommends:
ii  e2fsprogs-l10n  1.45.0-1
ii  lvm22.03.02-2

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
ii  fuse2fs1.45.0-1
pn  gpart  
ii  parted 3.2-24

-- no debconf information

Bug#926129: unblock: git-annex/7.20190129-3

[Sean Whitton]

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

Please unblock package git-annex

Fixes an race condition in the test suite that causes FTBFS.

unblock git-annex/7.20190129-3

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

-- 
Sean Whitton
diff -Nru git-annex-7.20190129/debian/changelog 
git-annex-7.20190129/debian/changelog
--- git-annex-7.20190129/debian/changelog   2019-02-03 15:54:29.0 
-0700
+++ git-annex-7.20190129/debian/changelog   2019-03-31 12:34:02.0 
-0700
@@ -1,3 +1,10 @@
+git-annex (7.20190129-3) unstable; urgency=medium
+
+  * Resolve a race in test cleanup by making second attempt more forceful
+(Closes: #924800).
+
+ -- Sean Whitton   Sun, 31 Mar 2019 12:34:02 -0700
+
 git-annex (7.20190129-2) unstable; urgency=medium
 
   * Cherry pick upstream commit a64fca92f6dfea086b7b9e65a2b83fb50fee1ecf.
diff -Nru git-annex-7.20190129/debian/patches/debian-changes 
git-annex-7.20190129/debian/patches/debian-changes
--- git-annex-7.20190129/debian/patches/debian-changes  2019-02-03 
15:54:29.0 -0700
+++ git-annex-7.20190129/debian/patches/debian-changes  2019-03-31 
12:34:02.0 -0700
@@ -65,3 +65,25 @@
, unlesscrippled ("v7 locked", testMode opts (RepoVersion 7))
, Just ("v5 direct", (testMode opts (RepoVersion 5)) { 
forceDirect = True })
]
+--- git-annex-7.20190129.orig/Test/Framework.hs
 git-annex-7.20190129/Test/Framework.hs
+@@ -271,7 +271,7 @@ finalCleanup = whenM (doesDirectoryExist
+   Utility.ThreadScheduler.Seconds 10
+   whenM (doesDirectoryExist tmpdir) $ do
+   Annex.Action.reapZombies
+-  removeDirectoryRecursive tmpdir
++  removePathForcibly tmpdir
+   
+ checklink :: FilePath -> Assertion
+ checklink f =
+--- git-annex-7.20190129.orig/git-annex.cabal
 git-annex-7.20190129/git-annex.cabal
+@@ -313,7 +313,7 @@ Executable git-annex
+unix-compat,
+SafeSemaphore,
+async,
+-   directory (>= 1.2),
++   directory (>= 1.2.7.0),
+disk-free-space,
+filepath,
+IfElse,


signature.asc
Description: PGP signature

Bug#868454: u-boot-menu: wrong path for fdtdir in extlinux.conf

[Jonas Smedegaard]

control: clone 868454 -1 -2 -3
control: retitle 868454 u-boot-menu: unusable with separate /boot partition
control: forcemerge 868454 908590
control: retitle -1 u-boot-menu: should try flash-kernel path with separate 
/boot partition
control: retitle -2 u-boot-menu: /etc/default/u-boot not installed
control: retitle -3 u-boot-menu: should stop with error if failing

This bugreport contain multiple issues, better tracked separately.

Also, sorry for not understanding at the time that (main part of) this 
bugreport was the same as I later reported as bug#908590.


Thanks,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#926037: systemd: localectl console keymap configuration delayed

[Iiro Laiho]

On 31.3.2019 21.23, Michael Biebl wrote:

Can you post the exact commands you used and what you did next.
I'm not quite sure what you mean with "application of the new layout to
the virtual consoles is delayed".
Did you logout/login again in the mean time and still got the same layout?


Let's say we want to use the "fi" keyboard layout with variant "das". It 
is one of those "exotic" variants that are in the xkb's 
"base.extras.xml". I am not quite sure whether or not it matters. Then 
we run:


$ localectl set-x11-keymap fi das

The layout is not applied immediately. I am not sure when it is applied, 
but apparently it eventually will be. Sometimes running 
"dpkg-reconfigure keyboard-configuration" and telling it to keep the 
current /etc/default/keyboard settings helps, but for some reason my 
system does not show that option anymore. Anyway, no further steps 
should be necessary after running that localectl command. This issue is 
not limited to the CLI configuration: gnome-control-center also uses 
localed to choose the system-wide keyboard mapping.


Btw, "fi das" is a non-QWERTY layout so it is recommendable to do these 
tests on a machine that has a SSH server or something other that can be 
used to switch the layout back.



TTBOMK, localectl just writes to /etc/default/keyboard and /etc/default
/console-setup and leaves it up to console-setup to apply those changes,
which is usually done during bootup.
There is also a /lib/udev/rules.d/90-console-setup.rules, i.e is
triggered via udev. So it might be possible, that console-setup applies
the changes when the hardware configuration changes.


Yeah, just noticed that myself. On Debian localed apparently just edits 
the while when console-setup applies it.


Cheers,
Iiro

Bug#926125: libmysofa: CVE-2019-10672

[Salvatore Bonaccorso]

Source: libmysofa
Version: 0.6~dfsg0-2
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for libmysofa.

CVE-2019-10672[0]:
| treeRead in hdf/btree.c in libmysofa before 0.7 does not properly
| validate multiplications and additions.


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-10672
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10672
[1] 
https://github.com/hoene/libmysofa/commit/d39a171e9c6a1c44dbdf43f9db6c3fbd887e38c1

Regards,
Salvatore

Bug#923759: Bug update

[Dominik Stadler]

Yes, sorry, I found how it was fixed by a followup upload, -5 did not as
far as I see, only -6 will fix it I think. I am also a bit new to the
Debian Bug-via-mail interface, I'll try to fix the bug-state. Sorry for the
spam.

Bug#923759: Update

[Markus Koschany]

Hi,

Am 31.03.19 um 20:59 schrieb Dominik Stadler:
> I think the current changes do not properly fix this, I created
> https://salsa.debian.org/java-team/netlib-java/merge_requests/2 with the
> set of changes based on previous patches that I think would make the
> classes be built again and also improve error handling slightly to make
> it easier to spot the actual error during building.

The latest revision of netlib-java does fix the class file generation
bug. It was already accepted by the release team. Your other changes can
be included in a future update of the package. I'm sure Andreas (CCed)
is interested in patches and will merge them.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#923184: unblock: qgis/3.4.6+dfsg-1

[Sebastiaan Couwenberg]

On 3/31/19 9:02 PM, Dmitry Shachnev wrote:
> On Sun, Mar 31, 2019 at 08:24:17PM +0200, Sebastiaan Couwenberg wrote:
>> On 3/31/19 4:54 PM, Dmitry Shachnev wrote:
>>> First of all, sorry for breaking qgis. Sip 4.19.14 was a minor release
>>> and I did not expect it to break anything. And I learned about this
>>> breakage only now.
>>
>> My experience with SIP is that every new upstream release, even minor
>> ones, introduce breakage in qgis.
>>
>> It would be good to upload to experimental first and do a test rebuild
>> of reverse dependencies with the new SIP before uploading to unstable.
> 
> I do not have resources to rebuild everything, but I will add qgis to
> my list of packages to rebuild next time.

The debomatic service may be an option:

 http://debomatic-amd64.debian.net/

sip4 doesn't seem to have many reverse dependencies, though.

> Also if something like this happens that is a good reason to complain
> to upstream sip, I think they do not want to minor sip releases to break
> anything.

Yes, they may be in need of some better CI too.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2

[Adam D. Barratt]

On Thu, 2018-11-01 at 21:07 -0400, Roberto C.Sánchez wrote:
> On Thu, Nov 01, 2018 at 06:50:53PM +, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Wed, 2018-10-31 at 23:25 -0400, Roberto C. Sanchez wrote:
> > > I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2)
> > > related to CVE-2018-16336 and also including a minor fix to the
> > > previous patch for CVE-2018-10958 and CVE-2018-10999.
> > 
> > The Security Tracker indicates that CVE-2018-16336 is as-yet
> > unfixed in
> > unstable; is that correct?
> > 
> 
> Hi Adam,
> 
> That is correct.  I completely overlooked it.  I will check with the
> maintainers about their plans for unstable.

Was there any progress there? The issue is still marked as affecting
unstable in the tracker.

Regards,

Adam

Bug#910805: stretch-pu: package dnsruby/1.54-2

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Thu, 2018-10-11 at 19:36 +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Thu, 2018-10-11 at 15:51 +0200, Santiago Ruano Rincón wrote:
> > I'd like to propose the attached dnsruby NMU to fix two bugs:
> > 
> > #908887: include latest DNS trust anchor (KSK-2017)
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908887
> 
> The metadata for that bug suggests that it also affects the package
> in unstable - is that correct?
> 
> > #910754: dnsruby: warning: constant ::TimeoutError is deprecated
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910754
> 
> That bug has no version information at all. :-( Does it also affect
> the package in unstable?

It looks like we never got a reply to the above questions, but they
seem to have been resolved in the meantime, so please go ahead.

Regards,

Adam

Bug#925351: stretch-pu: package dns-root-data/2019031302~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2019-03-23 at 16:04 +0100, Daniel Kahn Gillmor wrote:
> Please consider an update to dns-root-data in debian stretch.

+dns-root-data (2019031302~deb9u1) stretch; urgency=medium
+
+  * Rebuild for stretch-backports.

*cough* :-)

With that fixed, please go ahead.

Regards,

Adam

Bug#923184: unblock: qgis/3.4.6+dfsg-1

[Dmitry Shachnev]

On Sun, Mar 31, 2019 at 08:24:17PM +0200, Sebastiaan Couwenberg wrote:
> On 3/31/19 4:54 PM, Dmitry Shachnev wrote:
> > First of all, sorry for breaking qgis. Sip 4.19.14 was a minor release
> > and I did not expect it to break anything. And I learned about this
> > breakage only now.
>
> My experience with SIP is that every new upstream release, even minor
> ones, introduce breakage in qgis.
>
> It would be good to upload to experimental first and do a test rebuild
> of reverse dependencies with the new SIP before uploading to unstable.

I do not have resources to rebuild everything, but I will add qgis to
my list of packages to rebuild next time.

Also if something like this happens that is a good reason to complain
to upstream sip, I think they do not want to minor sip releases to break
anything.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#924945: stretch-pu: package edk2/0~20161202.7bbe0b3e-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2019-03-18 at 14:17 -0600, dann frazier wrote:
> Fixes 3 CVEs.
> 

Please go ahead.

Regards,

Adam

Bug#924642: stretch-pu: package rsync/3.1.2-1+deb9u1

[Adam D. Barratt]

On Sun, 2019-03-31 at 19:57 +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Fri, 2019-03-15 at 11:23 +0100, Paul Slootman wrote:
> > There are a couple of CVEs that have been fixed by 3.1.2-1+deb9u2.
> > After discussing this with a member of the security team it was not
> > considered important enough to warrant a DSA, but it would be good
> > if
> > it
> > could be included in a point release for stretch.
> > 
> > The changelog is:
> > 
> >   * Apply CVEs from 2016 to the zlib code.
> > closes:#924509
> > 
> > The only change was the addition of 4 patches to the zlib code.
> > 
> > The uploaded version was compiled on a stretch system.
> > 
> 
> There doesn't appear to be an uploaded version anywhere that I can
> see.

Because:

Mar 15 10:54:14 /rsync_3.1.2-1+deb9u2_amd64.changes has bad PGP/GnuPG
signature!

> Please attach a source debdiff to this report.

Regards,

Adam

Bug#923759: Update

[Dominik Stadler]

I think the current changes do not properly fix this, I created
https://salsa.debian.org/java-team/netlib-java/merge_requests/2 with the
set of changes based on previous patches that I think would make the
classes be built again and also improve error handling slightly to make it
easier to spot the actual error during building.

Bug#924642: stretch-pu: package rsync/3.1.2-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Fri, 2019-03-15 at 11:23 +0100, Paul Slootman wrote:
> There are a couple of CVEs that have been fixed by 3.1.2-1+deb9u2.
> After discussing this with a member of the security team it was not
> considered important enough to warrant a DSA, but it would be good if
> it
> could be included in a point release for stretch.
> 
> The changelog is:
> 
>   * Apply CVEs from 2016 to the zlib code.
> closes:#924509
> 
> The only change was the addition of 4 patches to the zlib code.
> 
> The uploaded version was compiled on a stretch system.
> 

There doesn't appear to be an uploaded version anywhere that I can see.

Please attach a source debdiff to this report.

Regards,

Adam

Bug#926124: unblock: weston/5.0.0-3

[Héctor Orón Martínez]

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

Please unblock package weston

Fixed a couple bugs related to:
  - make build reproducible
  - fix startup with systemd-login

Find debdiff attached:

diff --git a/debian/changelog b/debian/changelog
index d6a391bc..ba9cb592 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+weston (5.0.0-3) unstable; urgency=medium
+
+  * debian/control: add libdbus-1-dev to Build-Depends
+- Fixes "won't start despite having an active logind session"
+(Closes: #799325)
+Thanks Paul Menzel for analysis.
+  * debian/patches/reproducible-build-899358.patch: new patch
+- Make the build reproducible
+(Closes: #899358)
+
+ -- Héctor Orón Martínez   Thu, 28 Mar 2019 14:11:26 +0100
+
 weston (5.0.0-2) unstable; urgency=medium
 
   [ Emilio Pozuelo Monfort ]
diff --git a/debian/control b/debian/control
index c2c11c28..4eea61de 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
  debhelper (>= 10),
  quilt,
  pkg-config,
+ libdbus-1-dev,
  libpixman-1-dev (>= 0.25.2),
  libpng-dev,
  libjpeg-dev,
diff --git a/debian/patches/reproducible-build-899358.patch 
b/debian/patches/reproducible-build-899358.patch
new file mode 100644
index ..642c9dfb
--- /dev/null
+++ b/debian/patches/reproducible-build-899358.patch
@@ -0,0 +1,14 @@
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899358
+Index: weston/weston.ini.in
+===
+--- weston.orig/weston.ini.in  2019-03-28 12:55:11.730324981 +0100
 weston/weston.ini.in   2019-03-28 12:58:53.029372855 +0100
+@@ -38,7 +38,7 @@
+ 
+ [launcher]
+ icon=/usr/share/icons/gnome/24x24/apps/arts.png
+-path=@abs_top_builddir@/weston-flower
++path=@libexecdir@/weston-flower
+ 
+ [input-method]
+ path=@libexecdir@/weston-keyboard
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index ..4a8185bf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+reproducible-build-899358.patch

unblock weston/5.0.0-3

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

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

Bug#924804: Duplicate

[Dominik Stadler]

This is the same as bug #923759 as far as I see

Bug#922918: stretch-pu: package twitter-bootstrap3/3.3.7+dfsg-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-02-21 at 21:50 +0100, Xavier Guimard wrote:
> A little fix for CVE-2019-8331.
> 

Please go ahead.

Regards,

Adam

Bug#924145: stretch-pu: package vips/8.4.5-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2019-03-09 at 22:14 +0100, László Böszörményi wrote:
> There are two security issues in VIPS, which don't warrant a DSA.
> I would like to update it via PU. Debdiff is attached.
> 

Please go ahead.

Regards,

Adam

Bug#924255: stretch-pu: package systemd/232-25+deb9u10

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-03-10 at 17:18 +0100, Michael Biebl wrote:
> Am 10.03.19 um 16:55 schrieb Michael Biebl:
> > I'd like to make a stable upload for systemd, fixing 5 separate
> > issues.
> > Two of them have a CVE.
> 
> ...
> 
> > The fix for CVE-2018-15686/#912005 is the most invasive one. I
> > based it
> > partially on what was uploaded to old-stable by the debian-lts
> > team.
> > With this patch applied, the demo exploit from [1] no longer causes
> > systemctl stop to hang.
> > That said, I would appreciate a second pair of eyes to look over
> > the
> > patch.
> 
> Sorry, forgot to attach the debdiff.
> Doing that now...

Please go ahead.

Regards,

Adam

Bug#926118: unblock: libmspack/0.10.1-1

[Jens Reyer]

I sent the full debdiff as xz (70kb), but erroneously to #926123.
Not resending, sorry and thanks.

Bug#926123: unblock: cabextract/1.9-2

[Jens Reyer]

Attached the debdiff as xz.

I also explicitly forwarded my mail to the maintainer, because I don't
know if x-debbugs-cc worked.


libmspack_0.8-1_0.10.1-1.diff.xz
Description: application/xz

Bug#924657: Buggy gettext() after switching locale (#924657)

[Niko Tyni]

On Sun, Mar 31, 2019 at 01:56:15PM +0200, intrigeri wrote:
 
> >From Iain's report I understand that since Perl 5.28, gettext() calls
> are cached, so after switching the locale, in order to get correct
> results, one needs to invalidate the cache somehow, e.g. by calling
> bindtextdomain() and then textdomain().

FWIW I looked into this a bit, and indeed glibc has a cache of
already loaded translations that gets invalidated (by incrementing
_nl_msg_cat_cntr) in setlocale(3), bindtextdomain(3) and textdomain(3)
but not uselocale(3).

Starting with Perl 5.28, Perl uses POSIX 2008 thread-safe locales, so
it calls uselocale(3) underneath when the Perl side POSIX::setlocale()
function is invoked.

The proposed fix/workaround seems fine to me, though I wonder if glibc
should invalidate the cache in uselocale(3) as well. Copying the
glibc maintainers. Any opinion on this?
-- 
Niko Tyni   nt...@debian.org

Bug#924888: (no subject)

[Thomas Lange]

The links to the logos, banners and mirrors are not needed because we
have them also on the devel page.
-- 
regards Thomas

Bug#923184: unblock: qgis/3.4.6+dfsg-1

[Sebastiaan Couwenberg]

On 3/31/19 4:54 PM, Dmitry Shachnev wrote:
> First of all, sorry for breaking qgis. Sip 4.19.14 was a minor release
> and I did not expect it to break anything. And I learned about this
> breakage only now.

My experience with SIP is that every new upstream release, even minor
ones, introduce breakage in qgis.

It would be good to upload to experimental first and do a test rebuild
of reverse dependencies with the new SIP before uploading to unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Bug#926037: systemd: localectl console keymap configuration delayed

[Michael Biebl]

Am 30.03.19 um 18:11 schrieb Iiro Laiho:
> Package: systemd
> Version: 232-25+deb9u9
> Severity: important
> Tags: l10n
> 
> Dear Maintainer,
> 
> When I set the system keymap using the "localectl" command, the 
> application of the new layout to the virtual consoles is delayed. The 
> delay seems to be unpredictable. I have currently no idea what does 
> finally trigger the change or when it happens. Sometimes reboot seems to 
> do it, sometimes not.

Can you post the exact commands you used and what you did next.
I'm not quite sure what you mean with "application of the new layout to
the virtual consoles is delayed".
Did you logout/login again in the mean time and still got the same layout?

TTBOMK, localectl just writes to /etc/default/keyboard and /etc/default
/console-setup and leaves it up to console-setup to apply those changes,
which is usually done during bootup.
There is also a /lib/udev/rules.d/90-console-setup.rules, i.e is
triggered via udev. So it might be possible, that console-setup applies
the changes when the hardware configuration changes.



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#926123: unblock: cabextract/1.9-2

[Jens Reyer]

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

block -1 by 926118


Hi

Please unblock package cabextract

I'm not the maintainer of cabextract, but of winetricks which is affected by
#914263 (cabextract: -F option doesn't work correctly.)

#914263 is a duplicate of #912687 (libmspack0: Regression when extracting
cabinets using -F
option fixed upstream, needs to be patched), see my previous unblock request
#926118.  It was fixed by:

cabextract (1.9-2) unstable; urgency=medium

  * Force libmspack0 version >= 0.9.1-1 to avoid bugs in that
package: Closes: #914263

 -- Eric Sharkey   Sun, 09 Dec 2018 08:06:55 -0500

Other changes I found in the debdiff:
- Bump debhelper version from 7 to 11
- Bump Standards-Version from 3.9.6 to 4.2.1
- d/rules target install: build
  drop dh_clean -k, add dh_prep


This unblock of cabextract is not strictly necessary for a pure Debian stable,
but might help e.g. derivatives.  If I'm wasting your time here, please just
NACK and close this report.


unblock cabextract/1.9-2


Thanks and greets
jre



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/12 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
diffstat for cabextract-1.9 cabextract-1.9

 changelog |7 +++
 compat|2 +-
 control   |6 +++---
 rules |2 +-
 4 files changed, 12 insertions(+), 5 deletions(-)

diff -Nru cabextract-1.9/debian/changelog cabextract-1.9/debian/changelog
--- cabextract-1.9/debian/changelog 2018-11-11 17:46:01.0 +0100
+++ cabextract-1.9/debian/changelog 2018-12-09 14:06:55.0 +0100
@@ -1,3 +1,10 @@
+cabextract (1.9-2) unstable; urgency=medium
+
+  * Force libmspack0 version >= 0.9.1-1 to avoid bugs in that
+package: Closes: #914263
+
+ -- Eric Sharkey   Sun, 09 Dec 2018 08:06:55 -0500
+
 cabextract (1.9-1) unstable; urgency=medium
 
   * New upstream release: Closes: #913007
diff -Nru cabextract-1.9/debian/compat cabextract-1.9/debian/compat
--- cabextract-1.9/debian/compat2018-11-11 17:20:41.0 +0100
+++ cabextract-1.9/debian/compat2018-12-09 14:06:55.0 +0100
@@ -1 +1 @@
-7
+11
diff -Nru cabextract-1.9/debian/control cabextract-1.9/debian/control
--- cabextract-1.9/debian/control   2018-11-11 17:46:01.0 +0100
+++ cabextract-1.9/debian/control   2018-12-09 14:06:55.0 +0100
@@ -2,12 +2,12 @@
 Section: utils
 Priority: optional
 Maintainer: Eric Sharkey 
-Build-Depends: debhelper (>= 7), sharutils, libmspack-dev, pkg-config, 
automake-1.15
-Standards-Version: 3.9.6
+Build-Depends: debhelper (>= 11), sharutils, libmspack-dev, pkg-config, 
automake-1.15
+Standards-Version: 4.2.1
 
 Package: cabextract
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: libmspack0 (>= 0.9.1-1), ${shlibs:Depends}, ${misc:Depends}
 Multi-Arch: foreign
 Enhances: konqueror
 Description: Microsoft Cabinet file unpacker
diff -Nru cabextract-1.9/debian/rules cabextract-1.9/debian/rules
--- cabextract-1.9/debian/rules 2018-11-11 17:46:01.0 +0100
+++ cabextract-1.9/debian/rules 2018-12-09 14:06:55.0 +0100
@@ -44,7 +44,7 @@
 install: build
dh_testdir
dh_testroot
-   dh_clean -k
+   dh_prep
dh_installdirs
 
# Add here commands to install the package into debian/cabextract.

Bug#798097: Restarting logind kills Xserver

[Michael Biebl]

Hi Julien

Am 31.03.19 um 11:23 schrieb Julien Cristau:
> On Thu, Mar 21, 2019 at 17:59:26 +0100, Michael Biebl wrote:
> 
>> Julien, in case you are busy, I could offer to NMU.
>> WDYT?
>>
> No objection.  (Just git cherry-pick -x the upstream change and add a
> changelog entry with the explanation.)

I just rebuilt the xserver package with this patch applied and tested it
again. Seems like something has regressed in the mean time.
Now restarting logind still kill the (X) session, this time it looks
like gnome-shell is crashing directly. Back then with stretch, this
worked fine.
So this needs further investigation and possibly additional changes in
Xorg and/or gnome-shell.

As it's not ready for buster, there is no point in applying this patch
either, so I guess it's best to postpone this.

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

Bug#926122: nuget: CVE-2019-0757 tampering vulnerability

[Markus Koschany]

Package: nuget
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for nuget.

CVE-2019-0757[0]:
A tampering vulnerability exists in NuGet software when executed in a
Linux or Mac environment. An attacker who successfully exploited the
vulnerability could run arbitrary code in the context of the current user.

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-0757
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0757

Please adjust the affected versions in the BTS as needed.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#926121: acl2: excessive build time on 32-bit architectures

[Aurelien Jarno]

Source: acl2
Version: 8.1dfsg-2
Severity: important

acl2 version 8.1dfsg-2 contains the following change:

| * Limit number of jobs on memory restricted machines

This change looks wrong and causes the build time to increase quite a
lot on 32-bit architectures, even if they have a lot of RAM. For example
on a fast i386 build daemon the build time went from ~5h to ~19h, which
is not acceptable.

The code computing the max number of jobs wrongly assume that the RAM
corresponds to what a process can allocate on the heap. This is not true
for 32-bit architectures, which can allocate only 2, 3 or 4GB per
process depending on the architecture.

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

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

Bug#926120: mirror submission for openmirror.fi

[Gunter Grodotzki]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: openmirror.fi
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Gunter Grodotzki 
Country: FI Finland
Location: Helsinki
Comment: Hi,
 
 I would like to "officially" add my mirror: http://openmirror.fi/ to your 
list. The setup of the server is completely open source: 
https://github.com/openmirror/openmirror and also completely automated via 
travis-ci. This is to keep the whole setup transparent and will also give a 
sense of "activity" towards the user.
 
 My main reasons to run this mirror:
 
 - I wanted to have a "zero compromise" mirror when it comes to offering (e.g. 
I offer cd-images, archive and main - would even like to go further and mirror 
testing cd-images and bpo, but have not found any proper documentation on that 
yet)
 - I would like to give back to the community - being a happy Debian user 
(desktop and server) for more than 10 years
 - I would like to use this as a test project for an automated mirror server 
and gain experience on running a (hopefully) high traffic website
 
 It is currently funded from my personal projects, but the costs are kept at a 
minimum. so I am not seeing any issues funding this for a longterm. The "cost 
of my personal time" would deplete rather quicker than the actual server costs 
- which is why I am hoping by hosting it on github might attract other 
volunteers.
 
 Looking forward to some feedback :)
 
 Cheers,
 Gunter




Trace Url: http://openmirror.fi/debian/project/trace/
Trace Url: http://openmirror.fi/debian/project/trace/ftp-master.debian.org
Trace Url: http://openmirror.fi/debian/project/trace/openmirror.fi

Bug#922340: unblock: open-build-service/2.9.4-1

[Héctor Orón Martínez]

Hello,

Missatge de Jonathan Wiltshire  del dia dg., 17 de
març 2019 a les 19:04:
>
> Control: tag -1 moreinfo
>
> Hi,
>
> On Wed, Mar 06, 2019 at 11:51:45PM +0100, Hector Oron wrote:
> > OK, I tried, and to be honest, stable isn't perfect either, since
> > distro lifecycle is longer than application support, so not allowing
> > newer upstream versions in stable is problematic security wise in the
> > long term. open-build-service is not the only one in this category,
> > there are many packages in the same situation and it'd be nice to find
> > a common solution for all those.
>
> What is upstream's approach to stable security updates like? How long is a
> stable series maintained? Is it realistic to cherry-pick fixes from new
> upstream releases for buster's lifetime?
>
> New upstreams in stable aren't a problem in themselves, but when not all
> new upstream releases are suitable (e.g. mixing bug fixes and features) the
> effect can be to block further releases, and make fixing high severity bugs
> harder.

I have been discussing with my colleagues about current state of the
package and it needs a bit more polishing, hence we are fine with
closing this unblock as Paul did. We'll look into alternative ways to
distribute the package for the next stable distribution.

Thanks,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#926119: vice: Add /usr/local to search path for ROM images

[Ben Wong]

Package: vice
Version: 3.0.0.dfsg-2
Severity: normal
Tags: patch

Dear Maintainer,

When a local administrator wishes to install the VICE ROMs for all
users on the local machine, the usual and recommended practice would
be to put them under /usr/local/. 

VICE does not look there by default, however, which forces local
admins to put the files in /usr/lib/, a directory normally reserved
for the OS. Only Debian's version of VICE should be writing files
there, not local admins.

The solution is to modify VICE to add /usr/local to the search path. I
have included a patch below.

--- src/arch/unix/archdep.c.orig2016-10-20 10:07:43.0 -0700
+++ src/arch/unix/archdep.c 2019-03-31 10:51:21.530798424 -0700
@@ -169,8 +169,8 @@
 boot_path = archdep_boot_path();
 home_path = archdep_home_path();
 
-/* First search in the `LIBDIR' then the $HOME/.vice/ dir (home_path)
-   and then in the `boot_path'.  */
+/* First search in the `LIBDIR', then /usr/local/vice, then the home 
dir
+  ($HOME/.vice/), and finally in the `boot_path'.  */
 
 #if defined(MINIXVMD) || defined(MINIX_SUPPORT)
 default_path_temp = util_concat(LIBDIR, "/", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
@@ -207,12 +207,18 @@
home_path, "/", VICEUSERDIR, "/PRINTER", 
NULL);
 #else
 default_path = util_concat(LIBDIR, "/", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
+  "/usr/local/vice/", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
+  "/usr/local/lib/vice/", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
home_path, "/", VICEUSERDIR, "/", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
boot_path, "/", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
LIBDIR, "/DRIVES", 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
+  "/usr/local/vice/DRIVES", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
+  "/usr/local/lib/vice/DRIVES", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
home_path, "/", VICEUSERDIR, "/DRIVES", 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
boot_path, "/DRIVES", 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
LIBDIR, "/PRINTER", 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
+  "/usr/local/vice/PRINTER", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
+  "/usr/local/lib/vice/PRINTER", emu_id, 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
home_path, "/", VICEUSERDIR, "/PRINTER", 
ARCHDEP_FINDPATH_SEPARATOR_STRING,
boot_path, "/PRINTER", NULL);
 #endif




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

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

Versions of packages vice depends on:
ii  dpkg 1.18.25
ii  install-info 6.3.0.dfsg.1-1+b2
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u4
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u4
ii  libgtk-3-0   3.22.11-1
ii  libieee1284-30.2.11-13
ii  libjpeg62-turbo  1:1.5.1-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpcre2-8-0 10.32-4
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1+deb9u1
ii  libreadline7 7.0-3
ii  libstdc++6   6.3.0-18+deb9u1
ii  libvte-2.91-00.46.1-1
ii  libx11-6 2:1.6.4-3+deb9u1
ii  libxrandr2   2:1.5.1-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  zlib1g   1:1.2.8.dfsg-5

vice recommends no packages.

vice suggests no packages.

-- no debconf information

Bug#922339: unblock: python-cassandra-driver/3.16.0-1

[Héctor Orón Martínez]

Hello,

Missatge de Paul Gevers  del dia ds., 30 de març
2019 a les 19:12:
>
> tags 922339 wontfix
> thanks
>
> On Sun, 17 Mar 2019 17:38:21 + Jonathan Wiltshire 
> wrote:
> > On Thu, Feb 14, 2019 at 08:11:55PM +0100, Héctor Orón Martínez wrote:
> > > Please unblock package python-cassandra-driver
> > >
> > > I have been working with Emmanuel Arias on getting his package sponsored
> > > into Debian, however it did not make it into Buster on time. It is a
> > > `salt` build dependency (however `salt` package maintainer has disabled
> > > it until it makes it in Buster).
> >
> > Is the intention that salt will enable support once this package migrates?
> > Will that require an unblock too?
> >
> > #921658 seems to suggest that salt is only a test-time build dependency.
> > Does this mean that not all of salt's tests are being run at the moment?
> > What is the impact of this?
> >
> > 2018-12-05 when the upload was prepared to 2019-02-08 when it was uploaded
> > is quite a long delay. Is long-term maintenance assured? Are sufficient
> > sponsors available for the next 5-6 years?
>
> I am closing this bug as wontfix as it is getting too late in the cycle
> for new packages and the above questions were not answered.

I am fine with that if it is not bloking saltstack from being in
buster. We can get it back in for Bullseye.

Thanks,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#842893: libxml-twig-perl: expand_external_ents fails to work as documented

[Moritz Mühlenhoff]

Hi Gregor,

> Moritz, I'm not completely sure I understand which changes to the
> docs you imagined, but I've added the following now:
> 
> +B: setting expand_external_ents to 0 or -1 currently doesn't work
> +as expected; cf. L.
> +To completelty turn off expanding external entities use C.
> +
> +=item no_xxe
> +
> +If this argument is set to a true value, expanding of external entities is
> +turned off.
> +

Looks great, that's exactly what i had in mind!

> In general, if we go ahead with something like this, I'm not sure if
> we should really close this bug; the issue is mitigated by using and
> documenting no_xxe but the expand_external_ents option is still buggy.
> [0]. 

I assume it was an oversight for expand_external_ents, but then they didn't
want to break existing behaviour and only added no_xxe as a new option.
Which (if properly documented) is fine, it's not uncommon that impacting
changes are only hidden behind newly introduced flags for a lot of libraries.

I think there's both arguments for closing and keeping the bug.

Cheers,
Moritz

Bug#926118: unblock: libmspack/0.10.1-1

[Jens Reyer]

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

Hi

Please unblock package libmspack

I'm not the maintainer of libmspack (in CC), but of winetricks which is
affected by #912687 (libmspack0: Regression when extracting cabinets using -F
option fixed upstream, needs to be patched).

The mentioned upstream fix is
https://github.com/kyz/libmspack/commit/2d86d4e70026cd03730ce0b00b12579c2e21620a
and was released some time ago in:

libmspack (0.9.1-1) unstable; urgency=medium

  * New upstream release:
+ fix regression when extracting cabinets using -F option
  (Closes: #912687)
  * Bump Standards-Version to 4.2.1.
  * Adapt to documentation now generated in 'doc/html'.

 -- Marc Dequènes (Duck)   Tue, 06 Nov 2018 22:38:49 +0900



Unfortunately the version fixing this failed to build on big-endian systems.
The upload fixing that was just a few days short for migration before the hard
freeze:

libmspack (0.10.1-1) unstable; urgency=medium

  * New upstream release:
+ fix build on big-endian systems (Closes: #914794)
  * Add missing JS files for documentation menu and search functions.

 -- Marc Dequènes (Duck)   Tue, 05 Mar 2019 19:03:29 +0900



I propose to accept libmspack/0.10.1-1 for buster, because especially 0.9.1-1
was much more tested since last December, then a 0.8 plus some cherry-picked
fixes would ever be.  However there seem to be a lot of unrelated changes,
mainly for the documentation system.  The debdiff is quite large (full debdiff
is over 400bk), so here's just the diffstat for libmspack-0.8 libmspack-0.10.1:

 ChangeLog  |  107 +
 Makefile.am|  178 +-
 Makefile.in|  787 +++---
 README |   17
 acinclude.m4   |   12
 config.h.in|   27
 configure  |  402 +++--
 configure.ac   |   20
 debian/changelog   |   18
 debian/control |2
 debian/copyright   |2
 debian/libmspack-doc.docs  |   12
 debian/rules   |2
 doc/.gitignore |1
 doc/Doxyfile   |   17
 doc/Doxyfile.in|   22
 doc/Makefile   |   16
 doc/Makefile.in|   14
 examples/cabd_memory.c |   30
 examples/cabrip.c  |   85 +
 examples/chmextract.c  |  121 +
 examples/msexpand.c|   48
 examples/multifh.c |   12
 examples/oabextract.c  |   41
 libmscabd.la   |   41
 libmschmd.la   |   41
 libmspack.la   |   41
 mspack/cab.h   |6
 mspack/cabd.c  |  351 ++--
 mspack/chmd.c  |  578 +++
 mspack/crc32.c |  104 -
 mspack/crc32.h |2
 mspack/kwajd.c |  354 ++--
 mspack/lzss.h  |8
 mspack/lzssd.c |   84 -
 mspack/lzx.h   |   22
 mspack/lzxd.c  |  714 -
 mspack/mspack.h|  173 +-
 mspack/mszip.h |   12
 mspack/mszipd.c|  270 +--
 mspack/oab.h   |1
 mspack/oabd.c  |  117 -
 mspack/qtm.h   |8
 mspack/qtmd.c  |  232 +-
 mspack/readbits.h  |  124 -
 mspack/readhuff.h  |  124 -
 mspack/system.c|9
 mspack/system.h|   56
 mspack/szddd.c |   74
 src/cabrip.c   |   85 -
 src/chmextract.c   |  122 -
 src/error.h|   22
 src/msexpand.c |   48
 src/oabextract.c   |   41
 test-driver|  148 +
 test/cabd_md5.c|  154 -
 test/cabd_test.c   |  643 
 test/chmd_find.c   |  110 -
 test/chmd_md5.c|   34
 test/chmd_order.c  |  190 +-
 test/chmd_test.c   |   70
 test/chminfo.c |  207 +-
 test/kwajd_test.c  |  144 -
 test/md5.c |  163 --
 test/md5.h |   25
 test/md5_fh.h  |   58
 test/test_files/cabd/mszip_lzx_qtm.cab  |binary
 test/test_files/cabd/normal_2files_2folders.cab |binary
 test/test_files/chmd/cve-2015-4467-reset-interval-zero.chm.LZXC-is-lzxc
|binary
 test/test_files/chmd/cve-2015-4467-reset-interval-zero.chm.xor |binary
 test/test_files/chmd/short-system-filenames.chm |binary
 test/test_files/kwajd/make.pl  |   16
 72 files changed, 4294 insertions(+), 3525 deletions(-)



unblock libmspack/0.10.1-1


Sorry for being so late.

Greets
jre


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-
debug'), (500, 'unstable'), (100, 'experimental'), (1, 

Bug#926117: debian-i18n: The NumLock function of the keyboard does not work after first login to Debian

[Gustavo Gutierrez]

Package: debian-i18n
Severity: normal
Tags: l10n

Dear Maintainer,

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

   * What led up to the situation?
Changing configuration (combination of some) in Language, Formats and Input
Sources.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Changing standard values of above settings to:
Language=English
Formats=Meixco
Input Sources=Portuguese
   * What was the outcome of this action?
In the first login to Debian (every time I start the computer) NumLock behavior
works well, I type my password which is a number of 6 characters and I can log
in to Debian but after this initial windows where Debian asks for my password,
the NumLock function cease to work, everytime the computer goes to a locked
screen where a I need to put again my password I can only use the number keys
that are above the starndard letter keys, if I want to use the NumPad keys I
need to press the Shift key and hold it while I type my password using this
pad, otherwise, it does not work.
   * What outcome did you expect instead?
Normal behaviour, NumLock function of the keyboard should always be the same
regardless the value selected in Language, Formats or Input Sources.

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



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

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

Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default

[Samuel Thibault]

Hello,

Mika Hanhijärvi, le dim. 31 mars 2019 19:59:19 +0300, a ecrit:
> This bug seems to still exist in Debian 9.8 "Stretch".

As explained earlier in the thread, the behavior mentioned in the topic
"grabs tty from CP2102/CP2109" is expected, because that's the only way
for blind people to get their their device working without having to
configure things blindly.

What is not expected is the package to be installed on a system which
does not have a Braille device. As mentioned earlier again, AFAIK that
*only* happens if these devices are plugged during installation of
Debian.

Samuel

Bug#925966: autopkgtest-buildvm-ubuntu-cloud: restore support for precise, trusty

[Martin Pitt]

Control: tag -1 pending

Hello Dan,

Dan Streetman [2019-03-29 10:48 -0400]:
>   * autopkgtest-buildvm-ubuntu-cloud: work with precise and trusty;
> they aren't dead yet!
> (LP: #1822331)

Thanks! Committed.

Martin