Bug#914964: diceware-doc: Package short description probably truncated

[Beatrice Torracca]

Package: diceware-doc
Severity: minor

Hi!

the package short description now reads «Create memorizable
passphrases from wordlists and various sources of ran» .

Probably the last word should be "randomness" like in the diceware package.

Thanks

beatrice

Bug#914914: debhelper: Consider setting common full-path variables to prevent reproducible build issues wrt usrmerge

[Niels Thykier]

Andreas Henriksson:
> Package: debhelper
> Version: 11.5.3
> Severity: wishlist
> 
> Dear Maintainer,
> 

Hi Andreas,

Thanks for filing the bug.

> While looking into some of the spotted reproducible build issues
> related to building on merged-usr vs non-merged systems[1]
> and fixed a couple of them[2][3] I was thinking that the
> "whack-a-mole" strategy might not be the best here.
> 

This seems to still be a "whack-a-mole" strategy; we are just
centralizing it to debhelper (which does have some merit).

> [...]
> 
> Apart from looking at the specific tools used in the already
> spotted reproducible build issues[1], doing a codesearch for
> AC_PATH_PROG and also investigating AC_PROG_* from autoconf docs[4]
> could be used as an inspiration to come up with with variables to
> set, which could be eg.
> 
> MKTEMP=/bin/mktemp
> GREP=/bin/grep
> ...
> 
> What do you think? Are setting these during configure unconditionally
> too scary? If it needs to happen in a new compat level, it likely
> won't have as big as an impact while also not helping in enough
> cases to be useful (but maybe not).
> 
> [1]: 
> https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
> [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914907
> [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914911
> [4]: 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Programs.html
> 
> 
> 
> Regards,
> Andreas Henriksson
> 

Honestly, I am conflicted on this.  On one hand, I do not want to
maintain such a list forever - which I would have if usrmerge will
remain optional forever.  On the other hand, I can see how this would be
useful in deflating the current (and future) d-d mail threads about
usrmerge.

I will be considering it for now.

Thanks,
~Niels

Bug#914963: python3-neovim: Package renamed upstream to pynvim

[Stefan Tatschner]

Package: python3-neovim
Version: 0.2.6-3
Severity: important

Dear Maintainer,

the package has been renamed upstream to pynvim. Please consider
changing the debian package name as well.

https://github.com/neovim/neovim/wiki/Following-HEAD#20181118
https://github.com/neovim/pynvim

Stefan

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

Kernel: Linux 4.18.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-neovim depends on:
ii  python3   3.6.7-1
ii  python3-greenlet  0.4.15-1
ii  python3-msgpack   0.5.6-1+b1

Versions of packages python3-neovim recommends:
ii  neovim  0.3.1-2

python3-neovim suggests no packages.

-- no debconf information

Bug#914953: [3dprinter-general] Bug#914953: FTBFS with Python 3.7 on many architectures

[Gregor Riepl]

Ok, it looks like I misunderstood how binNMUs work, so I'll simply prepare a
release then. [1]

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

Bug#914953: [3dprinter-general] Bug#914953: FTBFS with Python 3.7 on many architectures

[Gregor Riepl]

> for the Python 3.7 default transition, libarcus was binNMUed against
> Python 3.7, but FTBFS on at least amd64, arm64, i386, mips, ppc64el
> and s390x:
>
> https://buildd.debian.org/status/package.php?p=libarcus=unstable
>
> So far it only build fine only on these release architectures" armel,
> armhf, mipsel64.

Thanks for reporting.

I'd like to fix this ASAP, but I just noticed that the NMU was never imported
back into the repository.

I'll add those imported library symbols and prepare a release as soon as I've
tracked the changes down.

Bug#914325: mirror.cc.columbia.edu down for maintenance

[Peter Palfrader]

On Thu, 22 Nov 2018, Columbia Mirror Admin wrote:

> Our mirror server, mirror.cc.columbia.edu, is under maintenance.  I will
> send an update when it is back in service.

Thanks for the information.  I have removed it from our list of mirrors
for now;  feel free to re-submit it once it's back using
https://www.debian.org/mirror/submit or just let us know.

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#914539: mirrors.tecnoera.com removed

[Peter Palfrader]

On Wed, 28 Nov 2018, Peter Palfrader wrote:
> On Sat, 24 Nov 2018, Peter Palfrader wrote:

> > It seems http://mirrors.tecnoera.com/debian/
> > is out of date
> > https://mirror-master.debian.org/status/mirror-info/mirrors.tecnoera.com.html
> > 
> > Please investigate.

Your mirror has not updated successfully in over a week.
Accordingly, I have removed it from our list of mirrors for now;  feel
free to re-submit it once it's back using
https://www.debian.org/mirror/submit
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#914962: perl: t/porting/manifest.t fails in a git checkout

[Niko Tyni]

Source: perl
Version: 5.28.0-4

When building in a checkout of our Debian git repo
(currently https://salsa.debian.org/perl-team/interpreter/perl ),
t/porting/manifest.t fails because the files in debian/ and
regen-configure/ are not in MANIFEST.

This broke in 5.26.1-1 when debian/skip-upstream-git-tests.diff was
replaced with the upstreamed fixes/packaging_test_skips.diff patch
(included upstream in 5.28), relying on the PERL_BUILD_PACKAGING
environment variable to skip tests specific to the upstream git
repository.

The problem is that find_git_or_skip() in t/test.pl looks at
PERL_BUILD_PACKAGING too late, so it doesn't change the logic of skipping,
only the explanation of why tests get skipped if they do.

Presumably this hasn't been spotted earlier because we almost never
build in git checkouts. I know I mostly just pass a .dsc to sbuild when
building. Still, I think this is worth fixing, preferably upstream as
I don't think the current test.pl change is useful to anybody.
-- 
Niko Tyni   nt...@debian.org

Bug#914906: [20181128] ftp.uni-bayreuth.de: unavailable intermittently

[Tom Rüger]

Am 28.11.18 um 14:56 schrieb Peter Palfrader:

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi!

it seems
http://ftp.uni-bayreuth.de/debian/
is not answering requests properly sometimes:
https://mirror-master.debian.org/status/mirror-info/ftp.uni-bayreuth.de.html

Please investigate.

Cheers,


Hi,

Thanks for your mail, investigated.

Our mirror ran out of client-connections due to a high number of users 
trying to download files from the deleted Debian 6 "squeeze"-tree with a 
high rate.


Hopefully solved by temporary limiting the number of concurrent 
connections per IP to 5. SInce 2018-11-28 14:25 'till now no further 
errors seem to have occurred.


Cheers,

Tom Rueger

Bug#742888:

[shirish शिरीष]

at bottom :-

On 23/11/2018, Alberts Muktupāvels  wrote:
> Is this still problem or can be closed?
>
> --
> Alberts Muktupāvels
>

Please close it as I have stopped using gnome-flashback a while back
and have shifted to a debian-mate and lxqt desktop with lightdm.

Thank you for taking the time to go through the bug and using your
valuable time and effort.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#914961: stretch-pu: libgpod/0.8.3-8.2+deb9u1

[Boyuan Yang]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: b...@debian.org

Dear Release Team,

I would like to push the fix for RC bug #896230 (
https://bugs.debian.org/896230) into Debian Stable. Currently package python-
gpod won't work (import error) when installed on a clean Debian Stable system
due to missing dependency on python-gobject-2 packakge.

The fix is exactly the same as libgpod/0.8.3-12 QA upload provided by Adrian
Bunk by adding missing dependency on python-gobject-2 for package python-gpod.

Full debdiff pasted here as well as provided as diff file in the attachment.

Thanks,
Boyuan Yang




diff -Nru libgpod-0.8.3/debian/changelog libgpod-0.8.3/debian/changelog
--- libgpod-0.8.3/debian/changelog  2017-04-07 04:33:15.0 -0400
+++ libgpod-0.8.3/debian/changelog  2018-11-29 00:27:09.0 -0500
@@ -1,3 +1,11 @@
+libgpod (0.8.3-8.2+deb9u1) stretch; urgency=high
+
+  * debian/control: Replace defunct Vcs-* fields with correct ones.
+  * python-gpod: Add missing dependency on python-gobject-2.
+(Closes: #896230)
+
+ -- Boyuan Yang   Thu, 29 Nov 2018 00:27:09 -0500
+
 libgpod (0.8.3-8.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libgpod-0.8.3/debian/control libgpod-0.8.3/debian/control
--- libgpod-0.8.3/debian/control2017-04-07 04:33:15.0 -0400
+++ libgpod-0.8.3/debian/control2018-11-29 00:26:16.0 -0500
@@ -32,8 +32,8 @@
libglib2.0-cil-dev (>= 2.12) [amd64 armel armhf arm64 i386
mipsel kfreebsd-amd64 kfreebsd-i386 ppc64 ppc64el s390x]
 Homepage: http://www.gtkpod.org/wiki/Libgpod
 Standards-Version: 3.9.6
-Vcs-Git: git://git.debian.org/git/pkg-gtkpod/packages/libgpod.git
-Vcs-Browser: http://git.debian.org/?p=pkg-gtkpod/packages/libgpod.git
+Vcs-Git: https://salsa.debian.org/debian/libgpod.git
+Vcs-Browser: https://salsa.debian.org/debian/libgpod
 
 Package: libgpod-nogtk-dev
 Section: oldlibs
@@ -121,7 +121,7 @@
 Section: python
 Architecture: any
 Depends: libgpod4 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends},
- ${python:Depends}
+ ${python:Depends}, python-gobject-2
 Replaces: python2.3-gpod (<< 0.3.2-1.1)
 Conflicts: python2.3-gpod (<< 0.3.2-1.1)
 Provides: ${python:Provides}
diff -Nru libgpod-0.8.3/debian/rules libgpod-0.8.3/debian/rules
--- libgpod-0.8.3/debian/rules  2017-04-07 04:33:15.0 -0400
+++ libgpod-0.8.3/debian/rules  2018-11-29 00:26:25.0 -0500
@@ -128,7 +128,7 @@
-V 'libgpod$(SONAME) (>= $(VERSION))'
 
 override_dh_python2:
-   dh_python2 --depends=mutagen --depends=gobject
+   dh_python2 --depends=mutagen
 
 %:
$(call DH, $@)
diff -Nru libgpod-0.8.3/debian/changelog libgpod-0.8.3/debian/changelog
--- libgpod-0.8.3/debian/changelog	2017-04-07 04:33:15.0 -0400
+++ libgpod-0.8.3/debian/changelog	2018-11-29 00:27:09.0 -0500
@@ -1,3 +1,11 @@
+libgpod (0.8.3-8.2+deb9u1) stretch; urgency=high
+
+  * debian/control: Replace defunct Vcs-* fields with correct ones.
+  * python-gpod: Add missing dependency on python-gobject-2.
+(Closes: #896230)
+
+ -- Boyuan Yang   Thu, 29 Nov 2018 00:27:09 -0500
+
 libgpod (0.8.3-8.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libgpod-0.8.3/debian/control libgpod-0.8.3/debian/control
--- libgpod-0.8.3/debian/control	2017-04-07 04:33:15.0 -0400
+++ libgpod-0.8.3/debian/control	2018-11-29 00:26:16.0 -0500
@@ -32,8 +32,8 @@
libglib2.0-cil-dev (>= 2.12) [amd64 armel armhf arm64 i386 mipsel kfreebsd-amd64 kfreebsd-i386 ppc64 ppc64el s390x]
 Homepage: http://www.gtkpod.org/wiki/Libgpod
 Standards-Version: 3.9.6
-Vcs-Git: git://git.debian.org/git/pkg-gtkpod/packages/libgpod.git
-Vcs-Browser: http://git.debian.org/?p=pkg-gtkpod/packages/libgpod.git
+Vcs-Git: https://salsa.debian.org/debian/libgpod.git
+Vcs-Browser: https://salsa.debian.org/debian/libgpod
 
 Package: libgpod-nogtk-dev
 Section: oldlibs
@@ -121,7 +121,7 @@
 Section: python
 Architecture: any
 Depends: libgpod4 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends},
- ${python:Depends}
+ ${python:Depends}, python-gobject-2
 Replaces: python2.3-gpod (<< 0.3.2-1.1)
 Conflicts: python2.3-gpod (<< 0.3.2-1.1)
 Provides: ${python:Provides}
diff -Nru libgpod-0.8.3/debian/rules libgpod-0.8.3/debian/rules
--- libgpod-0.8.3/debian/rules	2017-04-07 04:33:15.0 -0400
+++ libgpod-0.8.3/debian/rules	2018-11-29 00:26:25.0 -0500
@@ -128,7 +128,7 @@
 		-V 'libgpod$(SONAME) (>= $(VERSION))'
 
 override_dh_python2:
-	dh_python2 --depends=mutagen --depends=gobject
+	dh_python2 --depends=mutagen
 
 %:
 	$(call DH, $@)


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

Bug#914048: closed by Peter Palfrader (Re: Bug#914048: mirror submission for debian.petarmaric.com)

[Peter Palfrader]

On Wed, 28 Nov 2018, Petar Marić wrote:

> I accidentally missed your initial "source packages" related email. I've
> updated the ftpsync configuration and forced a new mirror sync.
> 
> Can you please recheck debian.petarmaric.com?

Ok, added.

Thanks!
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#913768: transition: glibc

[Aurelien Jarno]

On 2018-11-28 13:07, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 14/11/2018 23:10, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.28. It is available in
> > experimental for almost 3 weeks and there is no known issue or
> > regression. It's also the version shipped in Ubuntu 18.10. It has been
> > built successfully on all release architectures. It fails to builds on a
> > few non-release architectures, but only due to a few testsuite issues
> > that needs to be investigated and which do not looks really worrying.
> > 
> > As the glibc is using symbol versioning, there is no soname change. That
> > said a few packages are using libc internal symbols and have to be
> > rebuilt for this transition:
> >  - apitrace
> >  - bro
> >  - dante
> >  - libnih
> >  - libnss-db
> >  - p11-kit
> >  - unscd
> > 
> > Here is the corresponding ben file:
> >   title = "glibc";
> >   is_affected = .depends ~ /libc[0-9.]* \(< >   is_good = .depends ~ /libc[0-9.]* \(<< 2.29\)/;
> >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.28\)/;
> > 
> > In addition a few new symbols have been added that might prevent a few
> > other packages to migrate to testing until glibc migrates if they pick
> > up the new symbols. Most of those symbols are related to C11 thread or
> > narrowing math functions from TS 18661-1. I doubt they are used in a lot
> > of packages yet.
> > 
> > Thanks for considering.
> 
> Please go ahead.
> 

Thanks, I have just uploaded it.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#914960: openbox: Missing alternative in recommends

[Oliver Schode]

Package: openbox
Version: 3.6.1-7
Severity: minor

Hi!

Openbox recommends obconf, which is GTK based, but there's also a Qt-version 
available, obconf-qt, providing roughly equivalent functionality. I'd like to 
suggest both being recommended as an option. Recommendations should be 
satisfiable without having to install duplicate software.

Best regards,
Oliver

Bug#831369: audacity: In LADSPA effect settings, sliders cannot handle negative integers

[Kyanos]

Package: audacity
Version: 2.2.2-1+b1
Followup-For: Bug #831369

On 7/14/16 7:29 PM, Kyanos wrote:
> Package: audacity
> Version: 2.1.2-1+b1
> Severity: minor
> 
> Dear Maintainer,
> 
> In the settings window for LADSPA effects, the sliders do not move to
> negative integers. If, for example, an integer option ranges from -3 to
> 3 (inclusive), the slider will only move within one half of the bar.
> 
> What is interesting is that negative values can still be entered
> manually, and the slider will even move to the appropriate position in
> the negative part! But trying to adjust the slider will cause it to jump
> back to the 0 position.
> 
> Also, the lower-bound label for the slider is incorrect when negative
> integers are involved: It is one greater than the true lower bound. So,
> if the range were from -3 to 3, the lower-bound label would be -2.
> However, the slider seems to behave as if the lower bound is correct.
> 
> I first discovered these issues while using Tom Baran's Autotalent
> plugin (packaged as "autotalent"), so that may be used to reproduce
> these issues. I have also attached a test plugin which may help.


Dear Maintainer,

Bug still exists in the latest version (2.2.1-1), confirmed with both
Autotalent and the test plugin.

To reiterate, the problems lie only in *integer* options; non-integer
options are okay.

Kyanos


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

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

Versions of packages audacity depends on:
ii  audacity-data   2.2.2-1
ii  libasound2  1.1.7-1+b1
ii  libavcodec587:4.0.3-1
ii  libavformat58   7:4.0.3-1
ii  libavutil56 7:4.0.3-1
ii  libc6   2.27-8
ii  libexpat1   2.2.6-1
ii  libflac++6v51.3.2-3
ii  libflac81.3.2-3
ii  libgcc1 1:8.2.0-9
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgtk2.0-0 2.24.32-3
ii  libid3tag0  0.15.1b-13
ii  liblilv-0-0 0.24.2~dfsg0-2
ii  libmad0 0.15.1b-9
ii  libmp3lame0 3.100-2+b1
ii  libogg0 1.3.2-1+b1
ii  libportaudio2   19.6.0-1
ii  libportsmf0 0.1~svn20101010-5
ii  libsndfile1 1.0.28-4
ii  libsoundtouch1  2.0.0-1
ii  libsoxr00.1.2-3
ii  libstdc++6  8.2.0-9
ii  libsuil-0-0 0.10.0~dfsg0-1
ii  libtwolame0 0.3.13-4
ii  libvamp-hostsdk3v5  2.7.1~repack0-1
ii  libvorbis0a 1.3.6-1
ii  libvorbisenc2   1.3.6-1
ii  libvorbisfile3  1.3.6-1
ii  libwxbase3.0-0v53.0.4+dfsg-7
ii  libwxgtk3.0-0v5 3.0.4+dfsg-7

audacity recommends no packages.

Versions of packages audacity suggests:
ii  caps [ladspa-plugin] 0.9.26-1
ii  ladspa-sdk [ladspa-plugin]   1.13-3
ii  swh-plugins [ladspa-plugin]  0.4.17-2
ii  tap-plugins [ladspa-plugin]  1.0.0-1

-- no debconf information

Bug#914959: network-manager: Unable to use machine account for 802.1x authorization

[kpp]

Package: network-manager
Version: 1.6.2-3+deb9u2
Severity: normal

Dear maintainer.

If a machine is a member of AD domain and security policy assumes 802.1x 
authorization it is impossible to use machine's account for authorization.
It is possible to manually extract machine's credentials from 
secrets.tdb file, but it is not very good.
Password of machine's AD account is changed frequently and transparently 
so this method is not suitable.
Could you add some option, helper or someone else for integration 
network manager's 802.1x authorization with samba client and/or forward 
this proposal to upstream?


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.26-0+deb9u1
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libbluetooth3  5.43-2+deb9u1
ii  libc6  2.24-11+deb9u3
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u4
ii  libgudev-1.0-0 230-3
ii  libjansson42.9-1
ii  libmm-glib01.6.4-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.19-1+b1
ii  libnl-3-2003.2.27-2
ii  libnm0 1.6.2-3+deb9u2
ii  libpam-systemd 232-25+deb9u6
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libreadline7   7.0-3
ii  libselinux12.6-3+b3
ii  libsoup2.4-1   2.56.0-2+deb9u2
ii  libsystemd0232-25+deb9u6
ii  libteamdctl0   1.26-1+b1
ii  libuuid1   2.29.2-1+deb9u1
ii  lsb-base   9.20161125
ii  policykit-10.105-18
ii  udev   232-25+deb9u6
ii  wpasupplicant  2:2.4-1+deb9u2

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base 2.76-5+deb9u2
ii  iptables 1.6.0+snapshot20161117-6
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3+deb9u1
ii  modemmanager 1.6.4-1
ii  ppp  2.4.7-1+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- debconf-show failed

Bug#914957: login: removal of pts/* from /etc/securetty wasn't applied in stretch

[Salvatore Bonaccorso]

Control: fixed -1 1:4.5-1

Hi,

[disclaimer: not the maintainer here]

On Thu, Nov 29, 2018 at 02:15:18PM +1100, russm wrote:
> Package: login
> Version: 1:4.4-4.1
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> The addition of pts/* to /etc/securetty was reverted in 1:4.5-1 but
> *not* in packages installed to stretch. Please backport this fix to
> 1:4.4-*

The stretch update part of this is requested here:
https://bugs.debian.org/877374

Regards,
Salvatore

Bug#866653: RFS: thawab 4.1-1 [UPDATE]

[Ahmed El-Mahmoudy]

as-salamu alaykom,

On Sat, Nov 24, 2018 at 11:14:46AM -0500, Jeremy Bicha wrote:
> I could upload othman today (it will need to go through the NEW queue)
> but I prefer to wait until after you start the autobuild process. That
> way, we will not have this issue again for othman.
---end quoted text---

Thanks for uploading othman, I re-uploaded thawab now.
I didin't do the autobuild thing for 2 reasons:
1. It didn't work with slmodem, although I did get the permission years 
ago !
2. thawab, othman & probably hijra will migrate to a new Waqf version, 
which I beleive is DFSG compliant.

-- 
‎أحمد المحمودي (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#914957: additional

[russm]

Specifically, the current status means that on stretch systems, any
accounts relying on the default pam_unix nullok_secure to allow null-
password accounts to log in from local terminals only are open to access
by anyone who ssh's in and happens to get get pts/0 or pts/1.

Bug#896165: linux: request packaging of bpftool

[Noah Meyerhans]

On Tue, Nov 27, 2018 at 09:50:17AM -0800, Jakub Kicinski wrote:
> > > Please see https://salsa.debian.org/kernel-team/linux/merge_requests/72
> > 
> > Ugh. We cannot currently package bpftool in Debian. There are several
> > GPLv2-only files in its source tree, and it links unconditionally
> > against the GPLv3 libbfd. :(
> 
> If we relicense the GPLv2-only files to be GPLv2-only OR BSD-2-Clause
> - like the majority of bpftool sources - would that work?
> 
> I wanted to make sure GPLv2-only + BSD-2-Clause will satisfy the
> license requirement when linking against libbfd, before I start chasing
> people for acks on the relicense :)

Yes, the BSD 2-clause license is OK. GPLv2 or greater would be OK, too.
It's really just GPLv2-only in this case that's causing the problem.

noah



signature.asc
Description: PGP signature

Bug#914958: ITS: ruby-mixlib-install

[Mathieu Parent]

Package: ruby-mixlib-install
Version: 1.1.0-1
Severity: important

Hi,

I plan to salvage the package. It currently FTBFS (#867656), has new version 
(1.1.0-1 -> 3.11.7) and has no upload since 2017-08-22.

I will co-maintain it under pkg-ruby-extras, as a sole Uploader unless someone 
wants to co-maintain.

Note0: Needed for test-kitchen, see #914955.

Note1: I've request access on salsa in the ruby-team.

Note2: I want to package the following gems next: kitchen-docker, kitchen-salt, 
and maybe kitchen-inspec.

Regards

Mathieu Parent


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

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

Bug#914957: login: removal of pts/* from /etc/securetty wasn't applied in stretch

[russm]

Package: login
Version: 1:4.4-4.1
Severity: grave
Tags: security
Justification: user security hole

The addition of pts/* to /etc/securetty was reverted in 1:4.5-1 but
*not* in packages installed to stretch. Please backport this fix to
1:4.4-*


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

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

Versions of packages login depends on:
ii  libaudit1   1:2.6.7-2
ii  libc6   2.24-11+deb9u3
ii  libpam-modules  1.1.8-3.6
ii  libpam-runtime  1.1.8-3.6
ii  libpam0g1.1.8-3.6

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#914956: crashes randomly after 1.0.1 upgrade

[Antoine Beaupre]

Package: taffybar
Version: 1.0.0-1
Severity: important

I'm running buster and ever since the 1.0.0 upgrade, I've had trouble
keeping taffybar running, so much so that I'm looking at going back at
xmonad or whatever else would offer me a status bar while this bug is
fixed. Obviously, downgrading would be a huge challenge because of the
complex dependency chain around this package...

I'm not sure what's going on, to be honest. There's been some API
changes, of course, in the new release, so I had to
... er... basically guess my way around those. Here's the patch I had
to make to my config - I have no idea if it's correct, but it made
Haskell happy, so I assume it is:

<#part type="text/x-diff" filename="~/patches/taffybar.hs-1.0.patch" 
disposition=inline>
<#/part>

Notice how I completely disabled the battery part (I didn't immediately
need it) and the network monitor (which makes the whole thing crash
*faster*).

The symptom is that things generally go well and I have a beautiful
taffybar on top (although the colors have changed and I still need to
figure out how to tweak that). Then, after a delay ranging between few
seconds and a few minutes, it just crashes:

curie:~139$ pkill -f .cache/taffybar/taffybar; taffybar 
Launching custom binary /home/anarcat/.cache/taffybar/taffybar-linux-x86_64

Got error
ErrorEvent {ev_type = 0, ev_display = Display 0x7f5d84000b70, ev_serialnum 
= 13, ev_error_code = 3, ev_request_code = 2, ev_minor_code = 0, ev_resourceid 
= 1072682}
Erreur de segmentation (core dumped)
"pkill -f .cache/taffybar/taffybar; taffybar " took 2 mins

Boom. The kernel tells me:

nov 28 21:57:18 curie kernel: taffybar-linux-[28287] segfault at 
fff8 ip 00421b75 sp 7ffe4f0e2630 error 5 in 
taffybar-linux-x86_64[40+5f] 
nov 28 21:57:18 curie kernel: Code: 06 81 e2 c0 3f 00 00 48 09 ca 0f b7 4a 2e 
66 f7 c1 0b 02 0f 85 3c 15 00 00 48 8b 2b 0f b7 52 2a 40 f6 c5 01 0f 85 cb 15 
00 00 <8b> 75 f8 83 fe 3e 0f 87 5d 13 00 00 89 f1 48 63 0c 8f 48 01 f9 ff  

gdb tells me it crashes in the garbage collector:

(gdb) bt
#0  0x00421b75 in evacuate1 ()
#1  0x00420edd in scavenge_block1 ()
#2  0x009a6be2 in scavenge_loop1 ()
#3  0x00991bc2 in scavenge_until_all_done ()
#4  0x009924fc in GarbageCollect ()
#5  0x00981cd4 in scheduleDoGC ()
#6  0x009825b0 in schedule ()
#7  0x00983401 in scheduleWaitThread ()
#8  0x00708fb2 in  ()
#9  0x7f5d9afc3b6d in g_closure_invoke ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7f5d9afd68f3 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x7f5d9afdef43 in g_signal_emit_valist ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x7f5d9afdfecf in g_signal_emit ()
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x7f5d9b7fe9b2 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x7f5d9b5ea1ca in gtk_container_propagate_draw ()
at /lib/x86_64-linux-gnu/libgtk-3.so.0
#15 0x7f5d9b5ea29d in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#16 0x7f5d9b59c604 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#17 0x7f5d9b5ef32d in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#18 0x7f5d9b5f4002 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
---Type  to continue, or q  to quit---
#19 0x7f5d9b59ee91 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#20 0x7f5d9b7fe854 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#21 0x7f5d9b5ea1ca in gtk_container_propagate_draw ()
at /lib/x86_64-linux-gnu/libgtk-3.so.0
#22 0x7f5d9b5ea29d in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#23 0x7f5d9b59c604 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#24 0x7f5d9b5ef32d in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#25 0x7f5d9b5f4002 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#26 0x7f5d9b59ee91 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#27 0x7f5d9b7fe854 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#28 0x7f5d9b5ea1ca in gtk_container_propagate_draw ()
at /lib/x86_64-linux-gnu/libgtk-3.so.0
#29 0x7f5d9b5ea29d in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#30 0x7f5d9b80cba2 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#31 0x7f5d9b7fe854 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#32 0x7f5d9b807878 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#33 0x7f5d9b6b70a9 in gtk_main_do_event ()
at /lib/x86_64-linux-gnu/libgtk-3.so.0
#34 0x7f5d9b3b82a5 in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#35 0x7f5d9b3c87d6 in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#36 0x7f5d9b3c9946 in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#37 0x7f5d9b3c9b04 in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#38 0x7f5d9afc3b6d in g_closure_invoke ()
---Type  to continue, or q  to quit---
at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#39 0x7f5d9afd68f3 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#40 0x7f5d9afdf882 in g_signal_emit_valist ()
at 

Bug#914955: ITS: test-kitchen

[Mathieu Parent]

Package: test-kitchen
Version: 1.11.1-1
Severity: important

Hi,

I plan to salvage the package. It currently FTBFS (#869178), has new version 
(1.1.11 -> 1.23.2) and has no upload since 2017-08-22.

I will co-maintain it under pkg-ruby-extras, as a sole Uploader unless someone 
wants to co-maintain.

Note1: I've request access on salsa in the ruby-team.

Note2: I want to package the following gems next: kitchen-docker, kitchen-salt, 
and maybe kitchen-inspec.

Regards

Mathieu Parent

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

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

Bug#914931: [Pkg-openssl-devel] Bug#914931: pagekite: Fail to connect to pagekite.me services with openssl installed

[Bjarni Runar Einarsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Oh shoot, I just noticed this bug is filed against the pagekite
package, not against openssl. The pagekite maintainers obviously
cannot fix the issues I was ranting about in my previous message,
please accept my apologies for noise.

- -- 
PageKite.net lets your personal computer be part of the web

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAlv/S9QACgkQjgA3FgDP
lJFT3Af+NRfNxaQT16KGWft3S4+Szg/eSnvwVJZH7cp9K7CZx/2EqZon+UGxULrT
u7O507mQuDG3cM2qpghe9jR2rtOBb3ISk/JzIz60uWQ77iFLKzN1hjueAjxW6wMm
dJKW+uHH7wWoLrIXwgbVT+bf8ayxKPfta2HRPiX8DgNWrpzm6Gl1lQ9pYSlC/5aD
ByYGAAl0QgCwvUv1IRnNRMELakRh4a7JlGnzAF1AjUnvJqbWiDLEqM8lldU1iGqg
54i/ILOD+Ies8kwFpaQeLhQDEI0Q0cVls59OC+xRV1vTRhds2j7SFVGlA+f9t8Lb
Oz9XslUjHWF/2IlsWgoGT5bf+4ROEQ==
=Plp5
-END PGP SIGNATURE-

Bug#914931: [Pkg-openssl-devel] Bug#914931: pagekite: Fail to connect to pagekite.me services with openssl installed

[Bjarni Runar Einarsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello!

Thanks Petter, for reporting this and helping me debug it today.
I can confirm that just allowing TLSv1 would allow connections to
the existing PageKite infrastructure. Upgrading the server in
question is increasingly becoming a priority for me, I hope to
get this sorted out relatively soon. But this is certainly going
to be an issue for others as well.

The idea that any user of the next version of Debian will be
unable to connect to anything using TLSv1 or TLSv1.1, strikes me
as a bit excessive. These protocols have issues, but AFAIK they
are NOT so broken as to require blacklisting. Please correct me
if I'm wrong.

These defaults would make sense on web servers, where we know the
mainstream clients are updated and patched promptly - but Debian
is used in many other environments, for many other tasks where
that is simply not the case. Debian users are NOT always in a
position to force upgrades upon all the systems they need to
communicate with.

So I strongly urge you to reconsider this policy. Is it really
necessary? Do the security benefits justify the breakage? If
security were the only concern, we'd all just switch our
computers off and unplug them. There has to be a balance.


Responding to the comments above re SSLv3: given the choice
between supporting SSLv3 and falling back to plain-text, I'll
choose to support SSLv3 any day. Due to some legacy clients, that
was my reality. The idea that everyone should just upgrade
everything is a luxury not afforded to people who are supporting
diverse hardware in the field - and for better or worse, PageKite
was embedded in devices that could not easily be upgraded.

I am hoping there are few enough of them left in the wild that I
can drop SSLv3 entirely, and soon - because given current Debian
policies, I'm now being forced to choose between supporting them
and supporting Debian. I'll probably choose Debian, but it won't
be without a fair bit of cursing and frustration...

The need to support legacy devices was actually one of the main
reasons of why I haven't upgraded that server: at some point
Debian chose to remove SSLv3 support from OpenSSL at compile
time, thus preventing me from upgrading, and forcing me to keep a
bunch of my servers at obsolete versions of Debian. So, I don't
have support for TLSv1.2 on that machine (and a few others),
because maintainers of this package forced me to choose one or
the other (maintaining my own forked OpenSSL packages was more
work than I could reasonably handle). I do wish this had been
handled differently, and I'm very glad this time it's just a
config file!


That said thanks for all your hard work on this!

I know everyone's doing their best, even though I rather strongly
disagree with some of your choices. Thanks for reading! :-)

- -- 
PageKite.net lets your personal computer be part of the web

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAlv/SogACgkQjgA3FgDP
lJHPDgf/fO6nKz3BQAa5E82BpCbsasRpu3mOWD0IIbPhjYG54GLmgKgzzgnV2K7l
fNgIiCSxigt/JMxt8u0dADYdprM4Nk+ihN7BHrz1P7SOXGdIKWkiZw9Ddmrg7GtM
UcGl9lwBvDWPKILz7Ug1EH5QP66AhIi4M1WLlHoq8w9z53U+aOvZnLANO4O4mK1T
4CO2DH2nD0GWmLi9YmFNTxCtlTByJgaZ4dMbwFHbGd6H0yORspbOc7i3REcULWvG
9S00Zve9Lsm4rH9XKMPdPSxyxHeEdYdKOPfLczU7rOz6rVynL3sdCt0KAfeUIQAu
ceIFLBRMiZSzba0En3+ZdPUbrzvfwA==
=cLaF
-END PGP SIGNATURE-

Bug#914954: Fails to upgrade from 3.4.0 to 3.4.1: ERROR:root:After system restart, the values must be saved into db. Please, execute tuptime with a privileged user.

[Axel Beckert]

Package: tuptime
Version: 3.4.1
Severity: serious

Hi,

tuptime failed to upgrade from 3.4.0 to 3.4.1 for me as follows:

Setting up tuptime (3.4.1) ...
Installing new version of config file /etc/init.d/tuptime ...
ERROR:root:After system restart, the values must be saved into db. Please, 
execute tuptime with a privileged user.
dpkg: error processing package tuptime (--configure):
 installed tuptime package post-installation script subprocess returned error 
exit status 255

As I'm reading the error message, it seems to think for some reason
that root is not a privileged user… O.o

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

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

Versions of packages tuptime depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56
ii  lsb-base 10.2018112800
ii  python3  3.7.1-2

tuptime recommends no packages.

tuptime suggests no packages.

-- no debconf information

Bug#874176: wrk: Fails to run with 'PANIC: unprotected error in call to Lua API'

[Chris AtLee]

Package: wrk
Version: 4.0.2-2
Followup-For: Bug #874176

Downgrading libluajit to 2.0.4+dfsg-1 fixes this for me.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable-updates'), 
(500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages wrk depends on:
ii  libc62.27-8
ii  libluajit-5.1-2  2.0.4+dfsg-1+b1
ii  libssl1.11.1.1a-1

wrk recommends no packages.

wrk suggests no packages.

-- no debconf information

Bug#912557: Removal of British hyphenation patterns from TeX Live

[Dominik Wujastyk]

Thank you, Mojca for this interesting and clear explanation.  I tend to
roll my eyes and eat chocolate when people start talking about licenses,
but you make it seem clear and sensible.

Thanks!
Dominik


On Sat, 3 Nov 2018 at 13:12, Mojca Miklavec 
wrote:

> Hi,
>
> I just want to thank Dominik Wujastyk and Graham Toal for giving us
> the permission to use the MIT licence for the British patterns.
>
> We will take care of the required modifications, release a new version
> of hyph-utf8 and also ask for update in ConTeXt which triggered the
> initial bug report.
>
>
> To try to answer the concerns regarding the stability of old documents
> ... I believe that what we need in TeX distributions is something
> different from "please rename the file if you make any changes". (I
> don't know what this could or should be, but I'm open to suggestions.)
>
> While the "TeX licence" made a lot of sense at the time when it was
> written by D.E. Knuth, the "please rename" clause on its own provides
> absolutely no guarantee that hyphenation of the English documents
> won't ever change. Yes, the "TeX licence" is still sending a very
> strong message to developers that Knuth wants others to rename their
> new engines based on TeX to avoid confusion, but it doesn't legally
> prevent anyone from using the same name for completely unrelated
> software, or perhaps from creating a symlink like tex -> luatex in
> some distribution. What keeps people back from doing that is more of a
> "social contract" than the actual licence itself.
>
> As a case in point: anyone could have easily REMOVED the British
> patterns from the distribution without violating the existing licence
> in any way, yet the documents would change – despite the licence's
> best efforts to prevent such changes. Or somebody could create some
> nonsense patterns under any given filename, and only modify the
> language.dat to load those nonsense patterns *instead of* the existing
> British English ones, and again we would get rubbish output without
> violating the old licence in any way.
>
> So: thanks again for the permission. And if needed, let's come up with
> a better idea about how to keep stability and quality of old documents
> within the TeX community.
>
> Thank you very much to everyone involved,
> Mojca
>

Bug#914822: Issues with error message "Invalid MIT-MAGIC-COOKIE-1 key"

[Michael Gilbert]

control: tag -1 upstream
control: severity -1 wishlist

On Nov 28, 2018 at 7:12 PM Vincent Lefevre wrote:
> 1. When X11 is not used like here, there is no reason to try to use
> DISPLAY (or at least, error messages should be deferred). Note that
> "env -u DISPLAY wine tversion.exe" doesn't output any error message.

Why not correct the invalid DISPLAY setting in your displayless environment?

I suppose wine could delay initializing X until it knows the
application its launching actually needs it, but that is not how it is
designed now.  This is a new feature that you could request of
upstream.

Best wishes,
Mike

Bug#914951: 4.19.5 fails to boot as Xen dom0

[Hans van Kranenburg]

On 11/29/18 1:20 AM, Hans van Kranenburg wrote:
> Package: src:linux
> Version: 4.19.5-1~exp1
> Severity: normal
> 
> Hi,
> 
> Latest 4.19 upload fails to boot as Xen dom0.

Copy at
https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html

But at least if someone else would also report or search for it, we have
this one to point to. :)

> Attached are two serial console output logs. One is starting with Xen
> 4.11 (from debian unstable) as dom0, and the other one without Xen.
> 
> [2.085543] BUG: unable to handle kernel paging request at
> 888d9fffc000
> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> [2.085674] Oops:  [#1] SMP NOPTI
> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1

Ehm, paste fail for this snippet, this is from my 4.19.5-1~exp1+pvh1
with extra Xen (domU) PVH patches. However, the full attached log is
from 4.19.5-1~exp1 which fails in exactly the same way.

> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> [...]
> 
> The pti=off setting on the PV dom0 kernel is left behind from the time
> when 4.9 failed to boot as Xen dom0 because of the bug handling that.

-- 
Hans van Kranenburg

Bug#913069: python3-arcus + python3-savitar missing in the transition page, but uninstallable

[Axel Beckert]

Hi,

Emilio Pozuelo Monfort wrote:
> > https://release.debian.org/transitions/html/python3.7-default.html
> > says: "Affected: .build-depends ~ /python3-dev/"
> > 
> > But that doesn't suffice, there's likely a "| .build-depends ~
> > /python3-all-dev/" missing.
> 
> That would introduce a lot of false positives, because most packages that
> build-dep on python3-all-dev are not affected by the default change, as they
> should already build for all the supported versions, including python3.7. I
> would prefer to handle this via
> 
> is_affected: .depends ~ /python3 (< 
> or similar.

I see. Thanks for the explanation.

> Both packages binNMUed.

Thanks!

libsavitar seems to have worked well, but libarcus FTBFS on many, but
not all architectures. I filed a bug report to track this one:
https://bugs.debian.org/914953

Mattia Rizzolo wrote:
> Anyway, I'm confident we will find such weird causes other ways.

q.e.d. ;-)

> > Affected source package is e.g. libarcus whose binary package
> > python3-arcus is currently uninstallable, but has no python3-dev in
> > the build-dependencies:
> > 
> >   Build-Depends: debhelper (>= 10.2.1), cmake (>= 2.8.12), dh-python,
> >libprotobuf-dev (>= 3.0.0), libprotoc-dev (>= 3.0.0),
> >protobuf-compiler (>= 3.0.0), python3-all-dev, python3-sip-dev
> 
> That's a bug: https://bugs.debian.org/905803
> 
> > The same counts for python3-savitar and src:libsavitar:
> > 
> >   Build-Depends: debhelper (>= 10.2.1), cmake (>= 2.8.12), dh-python,
> >libpugixml-dev (>= 1.7), python3-all-dev, python3-sip-dev (>=
> >4.19.12+dfsg-1) | python3-sip-dev (<< 4.19.11+dfsg-1)
> 
> And another bug: https://bugs.debian.org/909730

Thanks for referring to these bug reports!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#914953: FTBFS with Python 3.7 on many architectures

[Axel Beckert]

Source: libarcus
Version: 3.3.0-1+b1
Severity: serious
Tags: ftbfs

Hi,

for the Python 3.7 default transition, libarcus was binNMUed against
Python 3.7, but FTBFS on at least amd64, arm64, i386, mips, ppc64el
and s390x:

https://buildd.debian.org/status/package.php?p=libarcus=unstable

So far it only build fine only on these release architectures" armel,
armhf, mipsel64.

Probably relevant log excerpt on amd64:

dpkg-gensymbols -plibarcus3 -Idebian/libarcus3.symbols -Pdebian/libarcus3 
-edebian/libarcus3/usr/lib/x86_64-linux-gnu/libArcus.so.1.1.0
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libarcus3/DEBIAN/symbols doesn't match 
completely debian/libarcus3.symbols
--- debian/libarcus3.symbols (libarcus3_3.3.0-1+b2_amd64)
+++ dpkg-gensymbolsiZ3ci6   2018-11-28 18:20:30.346117939 +
@@ -29,12 +29,12 @@
  (c++)"Arcus::Private::PlatformSocket::flush()@Base" 2.3.1
  (c++)"Arcus::Private::PlatformSocket::getNativeErrorCode()@Base" 2.3.1
  (c++)"Arcus::Private::PlatformSocket::listen(int)@Base" 2.3.1
- (c++|optional)"Arcus::Private::PlatformSocket::readBytes(unsigned int, 
char*)@Base" 3.0.3
+#MISSING: 3.3.0-1+b2# 
(c++|optional)"Arcus::Private::PlatformSocket::readBytes(unsigned int, 
char*)@Base" 3.0.3
  (c++|optional)"Arcus::Private::PlatformSocket::readBytes(unsigned long, 
char*)@Base" 2.3.1
  (c++)"Arcus::Private::PlatformSocket::readUInt32(unsigned int*)@Base" 2.5.0
  (c++)"Arcus::Private::PlatformSocket::setReceiveTimeout(int)@Base" 2.3.1
  
(c++)"Arcus::Private::PlatformSocket::shutdown(Arcus::Private::PlatformSocket::ShutdownDirection)@Base"
 2.3.1
- (c++|optional)"Arcus::Private::PlatformSocket::writeBytes(unsigned int, char 
const*)@Base" 3.0.3
+#MISSING: 3.3.0-1+b2# 
(c++|optional)"Arcus::Private::PlatformSocket::writeBytes(unsigned int, char 
const*)@Base" 3.0.3
  (c++|optional)"Arcus::Private::PlatformSocket::writeBytes(unsigned long, char 
const*)@Base" 2.3.1
  (c++)"Arcus::Private::PlatformSocket::writeUInt32(unsigned int)@Base" 2.5.0
  (c++)"Arcus::Private::PlatformSocket::~PlatformSocket()@Base" 2.3.1
@@ -65,83 +65,88 @@
  (c++)"Arcus::SocketListener::setSocket(Arcus::Socket*)@Base" 2.3.1
  (c++)"ErrorCollector::AddError(std::__cxx11::basic_string, std::allocator > const&, int, int, 
std::__cxx11::basic_string, std::allocator > 
const&)@Base" 2.3.1
  (c++)"ErrorCollector::~ErrorCollector()@Base" 2.3.1
+ 
_ZNSt10_HashtableIPKN6google8protobuf10DescriptorESt4pairIKS4_jESaIS7_ENSt8__detail10_Select1stESt8equal_toIS4_ESt4hashIS4_ENS9_18_Mod_range_hashingENS9_20_Default_ranged_hashENS9_20_Prime_rehash_policyENS9_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeEmmPNS9_10_Hash_nodeIS7_Lb0EEEm@Base
 3.3.0-1+b2
+ 
_ZNSt10_HashtableIjSt4pairIKjPKN6google8protobuf7MessageEESaIS7_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS9_18_Mod_range_hashingENS9_20_Default_ranged_hashENS9_20_Prime_rehash_policyENS9_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeEmmPNS9_10_Hash_nodeIS7_Lb0EEEm@Base
 3.3.0-1+b2
+ 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Base
 3.3.0-1+b2
+ 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base
 3.3.0-1+b2
+ _ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag@Base 3.3.0-1+b2
  (c++)"createAddress(std::__cxx11::basic_string, 
std::allocator > const&, int)@Base" 2.3.1
  
(c++)"google::protobuf::compiler::MultiFileErrorCollector::AddWarning(std::__cxx11::basic_string, std::allocator > const&, int, int, 
std::__cxx11::basic_string, std::allocator > 
const&)@Base" 2.3.1
- (c++|optional)"google::protobuf::internal::pLinuxKernelCmpxchg@Base" 3.0.3
- (c++|optional)"google::protobuf::internal::pLinuxKernelMemoryBarrier@Base" 
3.0.3
+#MISSING: 3.3.0-1+b2# 
(c++|optional)"google::protobuf::internal::pLinuxKernelCmpxchg@Base" 3.0.3
+#MISSING: 3.3.0-1+b2# 
(c++|optional)"google::protobuf::internal::pLinuxKernelMemoryBarrier@Base" 3.0.3
  (c++)"hash(std::__cxx11::basic_string, 
std::allocator > const&)@Base" 2.3.1
  (c++)"operator<<(std::basic_ostream >&, 
Arcus::Error const&)@Base" 2.3.1
- (c++|optional)"std::_Deque_base, 
std::allocator > 
>::_M_initialize_map(unsigned int)@Base" 3.0.3
+#MISSING: 3.3.0-1+b2# 
(c++|optional)"std::_Deque_base, 
std::allocator > 
>::_M_initialize_map(unsigned int)@Base" 3.0.3
  (c++|optional)"std::_Deque_base, 
std::allocator > 
>::_M_initialize_map(unsigned long)@Base" 2.3.1
- (c++|optional)"std::_Hashtable, 
std::allocator >, std::__detail::_Select1st, std::equal_to, std::hash, 
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, 
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_insert_unique_node(unsigned int, unsigned int, 
std::__detail::_Hash_node, false>*)@Base" 3.0.3
- 

Bug#914159: Bug reported to upstream

[Er_Maqui]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I've reported the bug to the upstream. The report are:
https://gitlab.com/gitlab-org/gitlab-ce/issues/54615


https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQIUZK8y555KYqDrRx8WMDgQjPp8gUCW/89awAKCRB8WMDgQjPp
8ksYAKCtv6nvlseJYaeiJXaXRYSCwL9QlACg6zY2rYk4FuZsvEZ5fMCDrpDYlcA=
=nA93
-END PGP SIGNATURE-

Bug#525082: upstream help request

[Gabriel F. T. Gomes]

Control: tags -1 upstream

On 28 Nov 2018, Gabriel F. T. Gomes wrote:

>I'll ask for advice upstream.

Help requested upstream at:
https://github.com/scop/bash-completion/pull/263

Bug#914949: Issues with error message "Invalid MIT-MAGIC-COOKIE-1 key"

[Vincent Lefevre]

Control: forwarded -1 https://gitlab.freedesktop.org/xorg/lib/libx11/issues/80

On 2018-11-29 01:10:06 +0100, Vincent Lefevre wrote:
> 2. As seen above, the error message does not end with a newline
> character. This breaks the parsing of the output (at least when
> both the standard output and the standard error are redirected
> to the same file).
> 
> This is confirmed with:
> 
> $ DISPLAY=:0 wine tversion.exe > /dev/null
> Invalid MIT-MAGIC-COOKIE-1 key%
> 
> under zsh, where the "%" output by zsh means that the newline character
> is missing.
> 
> I get the same issue with:
> 
> $ DISPLAY=:0 xterm
> Invalid MIT-MAGIC-COOKIE-1 key/usr/bin/xterm: Xt error: Can't open display: :0
> 
> and with gxmessage (which doesn't use Xt), so that I assume that
> this comes from libX11. Reassigning this one to libx11-6.

Also reported upstream (hoping this is the right one).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#914159: More information

[Er_Maqui]

Control: tag -1 upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I've tested this problem one more time.

Apparently, the problem are on gitlab itself. Maybe some change between
gitlab 10 and 11.

I've tested on gitlab 11.5.1 .deb package (from packages.gitlab.com), the
problem are the same.

After this, I've tested on gitlab.com webpage and I have the same problem.
Gitlab only shows one of the identities on the GPG key.

I'll be reporting this bug on gitlab webpage by myself.


https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQIUZK8y555KYqDrRx8WMDgQjPp8gUCW/82VwAKCRB8WMDgQjPp
8sVIAJ0U6UDgSqtYjFIoR6rbdxVgWSc9MwCggY3fU61x+ca0bplULwq0+Rmk7RA=
=p2AA
-END PGP SIGNATURE-

Bug#525082: reassign 525082 to bash,bash-completion

[Gabriel F. T. Gomes]

Control: reassign -1 bash-completion

On Fri, 24 Jul 2009 20:38:23 +0200 Luk Claes  wrote:
> # Automatically generated email from bts, devscripts version 2.10.25~bpo40+1
> # this seems like a bug introduced by the package split
> reassign 525082 bash,bash-completion 

When bash-completion is *not* installed, this bug cannot be reproduced,
thus I'm removing bash from it.

I have investigate what causes this problem and found out that it is
due to bash_completion unsetting hostcomplete (shopt -u hostcomplete)
before installing completions for finger, ssh, and others, but never
restoring the original setting.

This is done in the following lines:

  shopt -u hostcomplete && complete -F _user_at_host talk ytalk finger
  (from 
https://github.com/scop/bash-completion/blob/78aa9236df56016ded1185f877b0ba1c656fc439/bash_completion#L1419)

  shopt -u hostcomplete && complete -F _sftp sftp
  (from 
https://github.com/scop/bash-completion/blob/78aa9236df56016ded1185f877b0ba1c656fc439/completions/ssh#L297)

I have created a fix for it (see below), but it has unanticipated
side-effects that cause a regression when trying to complete `@' as an
array index:
  
Unsufficient fix:

diff --git a/bash_completion b/bash_completion
index 546cc39b..b1f6a7c3 100644
--- a/bash_completion
+++ b/bash_completion
@@ -1426,7 +1426,9 @@ _user_at_host()
 compopt -o nospace
 fi
 }
+shopt_reset=$( shopt -p hostcomplete )
 shopt -u hostcomplete && complete -F _user_at_host talk ytalk finger
+$shopt_reset
 
 # NOTE: Using this function as a helper function is deprecated.  Use
 #   `_known_hosts_real' instead.
diff --git a/completions/ssh b/completions/ssh
index 1335f302..2c68c676 100644
--- a/completions/ssh
+++ b/completions/ssh
@@ -273,7 +273,9 @@ _ssh()
 fi
 fi
 } &&
+shopt_reset=$( shopt -p hostcomplete )
 shopt -u hostcomplete && complete -F _ssh ssh slogin autossh sidedoor
+$shopt_reset
 
 # sftp(1) completion
 #
@@ -329,7 +331,9 @@ _sftp()
 _known_hosts_real $ipvx -a -F "$configfile" -- "$cur"
 fi
 } &&
+shopt_reset=$( shopt -p hostcomplete )
 shopt -u hostcomplete && complete -F _sftp sftp
+$shopt_reset
 
 # things we want to backslash escape in scp paths
 _scp_path_esc='[][(){}<>",:;^&!$=?`|\\'"'"'[:space:]]'


I'll ask for advice upstream.

Bug#914952: lintian: Two typos in tests; patch attached

[Adam Conrad]

Package: lintian
Version: 2.5.114
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch



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

  * Fix two typos introduced when parameterising test architectures in:
- 9e128d0f0087ce7025bd09dee7188b57269da992
- fd01abbf7c2551dfed48e72f38c59f8e5a48b95d

Looking at the context of those two commits, and the attached patch,
it should all be fairly self-explanatory, I'd imagine.

Cheers,

... Adam

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

Kernel: Linux 4.18.0-11-lowlatency (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lintian-2.5.114ubuntu1/t/tests/binaries-missing-lfs/debian/control.in 
lintian-2.5.114ubuntu2/t/tests/binaries-missing-lfs/debian/control.in
--- lintian-2.5.114ubuntu1/t/tests/binaries-missing-lfs/debian/control.in   
2018-11-26 01:21:31.0 -0700
+++ lintian-2.5.114ubuntu2/t/tests/binaries-missing-lfs/debian/control.in   
2018-11-28 14:07:00.0 -0700
@@ -7,7 +7,7 @@
 Rules-Requires-Root: no
 
 Package: libbasic2
-Architecture: ${package_architecture}
+Architecture: {$package_architecture}
 Section: libs
 Depends: $\{misc:Depends\}, $\{shlibs:Depends\}
 Description: {$description}
diff -Nru 
lintian-2.5.114ubuntu1/t/tests/deb-format-udeb-compression/debian/control.in 
lintian-2.5.114ubuntu2/t/tests/deb-format-udeb-compression/debian/control.in
--- 
lintian-2.5.114ubuntu1/t/tests/deb-format-udeb-compression/debian/control.in
2018-11-26 01:21:31.0 -0700
+++ 
lintian-2.5.114ubuntu2/t/tests/deb-format-udeb-compression/debian/control.in
2018-11-28 14:07:00.0 -0700
@@ -7,7 +7,7 @@
 Rules-Requires-Root: no
 
 Package: some-udeb
-Architecture: ${package_architecture}
+Architecture: {$package_architecture}
 Depends: $\{misc:Depends\}
 Package-Type: udeb
 Description: {$description}

Bug#914951: 4.19.5 fails to boot as Xen dom0

[Hans van Kranenburg]

Package: src:linux
Version: 4.19.5-1~exp1
Severity: normal

Hi,

Latest 4.19 upload fails to boot as Xen dom0.

Attached are two serial console output logs. One is starting with Xen
4.11 (from debian unstable) as dom0, and the other one without Xen.

[2.085543] BUG: unable to handle kernel paging request at
888d9fffc000
[2.085610] PGD 200c067 P4D 200c067 PUD 0
[2.085674] Oops:  [#1] SMP NOPTI
[2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
[2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
[2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
[...]

The pti=off setting on the PV dom0 kernel is left behind from the time
when 4.9 failed to boot as Xen dom0 because of the bug handling that.

-- 
Hans van Kranenburg
Loading Linux 4.19.0-trunk-amd64 ...L   
 oading initial ramdisk 
... 
Loading initial ramdisk ...L

[0.00] Linux version 4.19.0-trunk-amd64 
(debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-10)) #1 SMP 
Debian 4.19.5-1~exp1 (2018-11-27)   
  [
0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-trunk-amd64 
root=UUID=f6c5313c-c1b7-4491-b017-e1512d716979 ro console=ttyS1 pti=off 

   [0.00] x86/fpu: x87 FPU will use 
FXSAVE  
   [0.00] BIOS-provided physical RAM map:   
   [
0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable 
   [0.00] BIOS-e820: 
[mem 0x0009f400-0x0009] reserved
  [0.00] BIOS-e820: [mem 
0x000f-0x000f] reserved 
 [0.00] BIOS-e820: [mem 
0x0010-0xdf62efff] usable   
 [0.00] BIOS-e820: [mem 
0xdf62f000-0xdf63bfff] ACPI data
 [0.00] BIOS-e820: [mem 
0xdf63c000-0xdf63cfff] usable
[0.00] BIOS-e820: [mem 0xdf63d000-0xe3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfee0] reserved
[0.00] BIOS-e820: [mem 0xff80-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x001b1fffefff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: HP ProLiant DL360 G7, BIOS P68 05/21/2018
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2666.735 MHz processor
[0.002284] last_pfn = 0x1b1 max_arch_pfn = 0x4
[0.003585] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.003975] last_pfn = 0xdf63d max_arch_pfn = 0x4
[0.008526] found SMP MP-table at [mem 0x000f4f80-0x000f4f8f] mapped at 
[(ptrval)]
[0.008604] Kernel/User page tables isolation: disabled on command line.
[0.008605] Using GB pages for direct mapping
[0.008850] RAMDISK: [mem 0x349d5000-0x364e1fff]
[0.008855] ACPI: Early table checksum verification disabled
[0.008922] ACPI: RSDP 0x000F4F00 024 (v02 HP)
[0.008925] ACPI: XSDT 0xDF630140 B4 (v01 HP ProLiant 
0002 �?   162E)
[0.008931] ACPI: FACP 0xDF630240 F4 (v03 HP ProLiant 
0002 �?   162E)
[0.008935] ACPI BIOS Warning (bug): Invalid length for 
FADT/Pm1aControlBlock: 32, using default 16 (20180810/tbfadt-674)
[0.008938] ACPI BIOS Warning (bug): Invalid length for 
FADT/Pm2ControlBlock: 32, using default 8 (20180810/tbfadt-674)
[0.008941] ACPI: DSDT 0xDF630340 0020BD (v01 HP DSDT 
0001 INTL 20030228)
[0.008945] ACPI: FACS 0xDF62F100 40
[0.008948] ACPI: FACS 0xDF62F100 40
[0.008951] ACPI: SPCR 0xDF62F140 50 (v01 HP SPCRRBSU 
0001 �?   162E)
[0.008954] ACPI: MCFG 0xDF62F1C0 3C (v01 HP ProLiant 
0001  )
[0.008958] ACPI: HPET 0xDF62F200 38 (v01 HP ProLiant 
0002 �?   162E)
[0.008961] ACPI: 

Bug#914822: Issues with error message "Invalid MIT-MAGIC-COOKIE-1 key"

[Vincent Lefevre]

Control: clone -1 -2
Control: retitle -1 libwine: spurious error message "Invalid MIT-MAGIC-COOKIE-1 
key" with invalid/old DISPLAY when X11 is not used
Control: reassign -2 libx11-6 2:1.6.7-1
Control: retitle -2 libx11-6: error message "Invalid MIT-MAGIC-COOKIE-1 key" 
not followed by a newline character

On 2018-11-28 18:19:46 +0100, Vincent Lefevre wrote:
> The output is actually present, but was filtered out later by
> the script due to an unexpected error message without a \n.
> 
> The tests/tversion.log starts with:
> 
> Invalid MIT-MAGIC-COOKIE-1 key[tversion] MPFR 4.1.0-dev
> [tversion] Compiler: GCC 7.3-win32 20180506
> 
> This message "Invalid MIT-MAGIC-COOKIE-1 key" is in tversion.log
> only, perhaps because the tversion test is executed first.

I can reproduce the issue with:

$ DISPLAY=:0 wine tversion.exe
Invalid MIT-MAGIC-COOKIE-1 key[tversion] MPFR 4.1.0-dev
[tversion] Compiler: GCC 7.3-win32 20180506
[...]

while there is no corresponding X server associated with :0. FYI,
this happens when the test is run in GNU screen and the X server
has shut down in the meantime.

Even though there is a workaround (unset DISPLAY), there are two
issues that should be fixed:

1. When X11 is not used like here, there is no reason to try to use
DISPLAY (or at least, error messages should be deferred). Note that
"env -u DISPLAY wine tversion.exe" doesn't output any error message.

2. As seen above, the error message does not end with a newline
character. This breaks the parsing of the output (at least when
both the standard output and the standard error are redirected
to the same file).

This is confirmed with:

$ DISPLAY=:0 wine tversion.exe > /dev/null
Invalid MIT-MAGIC-COOKIE-1 key%

under zsh, where the "%" output by zsh means that the newline character
is missing.

I get the same issue with:

$ DISPLAY=:0 xterm
Invalid MIT-MAGIC-COOKIE-1 key/usr/bin/xterm: Xt error: Can't open display: :0

and with gxmessage (which doesn't use Xt), so that I assume that
this comes from libX11. Reassigning this one to libx11-6.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#914948: udisks2: udisksctl power-off causes system freeze

[EP]

Package: udisks2
Version: 2.1.8-1
Severity: important

Dear Maintainer,

on my system with Samsung 970 Evo M2 SSD, the command udisksctl
"power-off --block-device /dev/sdx" causes a complete system freeze.
Input devices are not responding, only hard reset is possible.
Logfiles report series of null bytes only (syslog, messages, even
jounalctl -f).
The problem occurred after installing a new system on a M2 SSD. The
problem does not occur using my old (quite similar) system, installed on
a SATA SSD (Samsung 850 Pro).
It does not depend on which kind of USB device (HDD or pendrives) is
powered off.
The power-off is successful before the system freezes. (though nothing
is recorded in logfiles)
The only way to avoid the freeze is not using the command (and the
thunar filmanager unmount feature using it).
It may be a hardware problem, but other users have similar problems.

My hardware (unchanged except SSD):
ASRock Z170 Extreme4 (latest firmware)
Intel i5 6600T (using integrated graphics)
8 GB RAM 


-- System Information:
Debian Release: 9.6
  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=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8),
LANGUAGE=de_AT:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages udisks2 depends on:
ii  dbus   1.10.26-0+deb9u1
ii  libacl1    2.2.52-3+b1
ii  libatasmart4   0.19-4+b1
ii  libc6  2.24-11+deb9u3
ii  libglib2.0-0   2.50.3-2
ii  libgudev-1.0-0 230-3
ii  libpam-systemd 232-25+deb9u6
ii  libpolkit-agent-1-0    0.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libsystemd0    232-25+deb9u6
ii  libudisks2-0   2.1.8-1
ii  parted 3.2-17
ii  udev   232-25+deb9u6

Versions of packages udisks2 recommends:
ii  dosfstools   4.1-1
ii  eject    2.1.5+deb1+cvs20081104-13.2
ii  exfat-utils  1.2.5-2
ii  gdisk    1.0.1-1
ii  ntfs-3g  1:2016.2.22AR.1+dfsg-1
ii  policykit-1  0.105-18

Versions of packages udisks2 suggests:
pn  btrfs-progs | btrfs-tools  
pn  cryptsetup-bin 
pn  mdadm  
pn  reiserfsprogs  
pn  xfsprogs   

-- no debconf information

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

Hi Manuel,

> > That seems to me the best solution indeed. So I can offer this:
> >
> > - I add these two new versions for all functions involved (quite a
> >   few); we'd just need to agree about naming ("old" and "new" won't
> >   do, since in this complicated situation it's not even clear which
> >   one is old and which one is new; different users will view it
> >   differently, just like in special relativity ;), also "old" and
> >   "new" in function names always sounds silly; so perhaps something
> >   like "RenderBasic" and "RenderDefault" or so ...).
> >
> > - I deprecate the "Render" functions, adding a special README to
> >   explain things.
> >
> > - I change my sources to use "RenderBasic" (or whatever it'll be
> >   called) and test them. Other users of this fork will have to do
> >   the same (hopefully after seeing the deprecation warnings and
> >   reading that README).
> >
> > - I release 2.4.0 with those changes.
> >
> > - You put 2.4.0 in Debian. Applications using it will get the
> >   deprecation warnings, but should otherwise work.
> >
> > - A bit later, I remove the deprecated functions and release 3.0.0.
> >
> > - After the release of Buster, you put 3.0.0 in Debian with the
> >   required transitions.
> >
> > - Applications using it will break, but fixing them will only
> >   require changing "Render" to "RenderDefault" in some places
> >   (which are found by compiler errors). This can also be done before
> >   you upload 3.0.0 (as "RenderDefault" will be available in 2.4.0
> >   already), so the transition can be smoohter.
> >
> > Does this sound like a viable plan?
> 
> I am not sure if I understand.  According to your plan, do the
> applications in Debian using ftgl will need to change anything at all
> to keep working?  Because there's not much time for making changes
> before the freeze, I will be quite busy for a couple of weeks at least
> (so please excuse delays in replies if they don't arrive in a timely
> manner), and changes of this kind usually take months to be
> accomplished.  It's not like we can commit changes to one or several
> git repos and rebuild the packages, it's quite more complex than that.
>
> IMO from the Debian side and for Buster there's no material time for
> changes to all packages that depend on fgtl, the only practical
> solutions are either to revert the change making some applications
> unuseable via extra patch from Debian; or have this transition and
> deprecation messages etc. in a way that existing packages don't need
> changes at all.
> 
> Sorry, but I don't think that anything else works for Buster.

As I said, in the first step (2.4.0), they should not (assuming some
new warnings while recompiling are no problems).

Some changes will be necessary for 3.0.0, after Buster.

Cheers,
Frank

Bug#914695: dgit autopkgtest breaks with git 2.20

[Ian Jackson]

Control: fixed -1 1:2.11.0-3+deb9u3
Control: fixed -1 1:2.19.2-1

Ian Jackson writes ("Re: Bug#914695: dgit autopkgtest breaks with git 2.20"):
> I have investigated and the bug seems to be that git-rebase --onto now
> fails to honour GIT_REFLOG_ACTION for the initial checkout.
> 
> In a successful run with older git I get a reflog like this:
> 
>   4833d74 HEAD@{0}: rebase finished: returning to refs/heads/with-preexisting
>   4833d74 HEAD@{1}: debrebase new-upstream 2.1-1: rebase: Add another new 
> upstream file
>   cabd5ec HEAD@{2}: debrebase new-upstream 2.1-1: rebase: Edit the .c file
>   0b362ce HEAD@{3}: debrebase new-upstream 2.1-1: rebase: Add a new upstream 
> file
>   29653e5 HEAD@{4}: debrebase new-upstream 2.1-1: rebase: checkout 
> 29653e5a17bee4ac23a68bba3e12bc1f52858ac3
>   85e0c46 HEAD@{5}: debrebase: launder for new upstream

FTR, I get this correct output in stretch and buster.
Please let me know if you actually need a minimal test case.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Manuel A. Fernandez Montecelo]

Hi Frank,

Em dom, 25 de nov de 2018 às 18:29, Frank Heckenbach
 escreveu:
>
> : Perhaps the only sane way out is to add *two* new versions of each
> : rendering function, one with each behaviour, and deprecate the old
> : ones entirely. This will require changes in all applications (if
> : only to select the correct one of the two which should be easy if
> : ones knows which branch of the library they used before), but at
> : least it will be clear at compile time.
>
> That seems to me the best solution indeed. So I can offer this:
>
> - I add these two new versions for all functions involved (quite a
>   few); we'd just need to agree about naming ("old" and "new" won't
>   do, since in this complicated situation it's not even clear which
>   one is old and which one is new; different users will view it
>   differently, just like in special relativity ;), also "old" and
>   "new" in function names always sounds silly; so perhaps something
>   like "RenderBasic" and "RenderDefault" or so ...).
>
> - I deprecate the "Render" functions, adding a special README to
>   explain things.
>
> - I change my sources to use "RenderBasic" (or whatever it'll be
>   called) and test them. Other users of this fork will have to do
>   the same (hopefully after seeing the deprecation warnings and
>   reading that README).
>
> - I release 2.4.0 with those changes.
>
> - You put 2.4.0 in Debian. Applications using it will get the
>   deprecation warnings, but should otherwise work.
>
> - A bit later, I remove the deprecated functions and release 3.0.0.
>
> - After the release of Buster, you put 3.0.0 in Debian with the
>   required transitions.
>
> - Applications using it will break, but fixing them will only
>   require changing "Render" to "RenderDefault" in some places
>   (which are found by compiler errors). This can also be done before
>   you upload 3.0.0 (as "RenderDefault" will be available in 2.4.0
>   already), so the transition can be smoohter.
>
> Does this sound like a viable plan?

I am not sure if I understand.  According to your plan, do the
applications in Debian using ftgl will need to change anything at all
to keep working?  Because there's not much time for making changes
before the freeze, I will be quite busy for a couple of weeks at least
(so please excuse delays in replies if they don't arrive in a timely
manner), and changes of this kind usually take months to be
accomplished.  It's not like we can commit changes to one or several
git repos and rebuild the packages, it's quite more complex than that.

IMO from the Debian side and for Buster there's no material time for
changes to all packages that depend on fgtl, the only practical
solutions are either to revert the change making some applications
unuseable via extra patch from Debian; or have this transition and
deprecation messages etc. in a way that existing packages don't need
changes at all.

Sorry, but I don't think that anything else works for Buster.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#914947: tslib: missing build dependency on pkg-config

[Adrian Bunk]

Source: tslib
Version: 1.18-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=tslib=sid

...
   dh_autoreconf -a
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4/internal'.
libtoolize: copying file 'm4/internal/libtool.m4'
libtoolize: copying file 'm4/internal/ltoptions.m4'
libtoolize: copying file 'm4/internal/ltsugar.m4'
libtoolize: copying file 'm4/internal/ltversion.m4'
libtoolize: copying file 'm4/internal/lt~obsolete.m4'
configure:13637: error: possibly undefined macro: AC_MSG_ERROR
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
make: *** [debian/rules:32: build-arch] Error 2

Bug#914648: tracker: Confirmed

[Manuel Bilderbeek]

Package: tracker
Followup-For: Bug #914648

Dear Maintainer,

I can confirm this issue on my system. It causes 100% CPU usage (on one core)...

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

Kernel: Linux 4.18.0-2-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)
LSM: AppArmor: enabled

Versions of packages tracker depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.1-1
ii  libc6 2.27-8
ii  libglib2.0-0  2.58.1-2
ii  libglib2.0-bin2.58.1-2
ii  libtracker-control-2.0-0  2.1.6-1
ii  libtracker-sparql-2.0-0   2.1.6-1
ii  shared-mime-info  1.10-1

Versions of packages tracker recommends:
ii  tracker-miner-fs  2.1.5-1

tracker suggests no packages.

-- no debconf information

Bug#914946: linux-config-4.19: Enable CONFIG_EDAC_PND2

[corubba]

Package: linux-config-4.19
Version: 4.19.5-1~exp1
Severity: wishlist
Tags: patch

Dear Maintainer,

I would like to kindly request the inclusion of the CONFIG_EDAC_PND2=m kernel
config option, allowing systems with a intel pondicherry2 memory controller out
of the box to monitor the installed ecc ram. The option was introduced with
v4.11 and is currently not set on any architecture. I don't know of any side
effects, as this option just results in an additional kernel module to be build.

It may also be desirable to enable this option in the linux-config-4.18 package.

As a workaround, I manually build the pnd2_edac module using the corresponding
linux-headers and linux-source packages.


--- debian/config/kernelarch-x86/config.orig2018-11-29 00:33:10.918463988 
+0100
+++ debian/config/kernelarch-x86/config 2018-11-29 00:33:36.241809179 +0100
@@ -454,6 +454,7 @@
 CONFIG_EDAC_I5100=m
 CONFIG_EDAC_I7300=m
 CONFIG_EDAC_SKX=m
+CONFIG_EDAC_PND2=m
 CONFIG_EDAC_AMD8131=m
 CONFIG_EDAC_AMD8111=m


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

Kernel: Linux 4.18.0-0.bpo.1-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 /bin/dash
Init: systemd (via /run/systemd/system)
--- debian/config/kernelarch-x86/config.orig	2018-11-29 00:33:10.918463988 +0100
+++ debian/config/kernelarch-x86/config	2018-11-29 00:33:36.241809179 +0100
@@ -454,6 +454,7 @@
 CONFIG_EDAC_I5100=m
 CONFIG_EDAC_I7300=m
 CONFIG_EDAC_SKX=m
+CONFIG_EDAC_PND2=m
 CONFIG_EDAC_AMD8131=m
 CONFIG_EDAC_AMD8111=m
 

Bug#914945: separate vm does not work with xemacs21

[Ian Jackson]

Package: vm
Version: 8.2.0b-3
Severity: important
Tags: help

To reproduce
  install xemacs21 and vm in a sid chroot
  xemacs21 -q -f vm

Expected output
  Display of an empty inbox, or something

Actual output
  Minibuffer error message:
  Invalid byte code: "invalid opcode 0 in instruction stream" 

I note that xemacs21 comes with a vm.el.  I don't know the
relationship between that and the vm package.  The vm package seems to
work with `emacs'.

For now I am going to remove xemacs21 from the passlist of supported
emacsen flavours.  The result will be that xemacs21 users will get the
vm which comes with xemacs21, rather than an error.

So after I do that, to reproduce the bug it will be necessary to
revert that commit.  I will write to this bug again when I have its
commitid etc.

Apologies for the inconvenience.  I would appreciate help from an
xemacs21 expert on what this might mean.

Note that the way vm deals with the emacsen-common stuff is rather
odd.  The upstream build system is not just .el files - it contains
other stuff.  So what the Debian package does is ship (enough of) the
upstream build system into
  /usr/share/emacs/site-lisp/vm.in
and run it during emacsen-common install and remove.  See the files
  debian/vm.emacsen-install
  debian/vm.emacsen-remove
in the source package.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#914944: gnupg: importing a key fails when there's no tty (regression from 2.1.18-8~deb9u2)

[Lucas Nussbaum]

Package: gnupg
Version: 2.1.18-8~deb9u3
Severity: normal

Hi,

Importing the attached key fails when there's no tty.

To reproduce:
works fine: gpg --import kameleon.gpg
doesn't work: setsid sh -c 'gpg --import kameleon.gpg' &>log

it fails with:
gpg: cannot open '/dev/tty': No such device or address

It worked fine with 2.1.18-8~deb9u2.
It also works with 2.2.10-3~bpo9+1.
It doesn't work with 2.1.18-8~deb9u3.
So it looks like a regression in the recent stable
update.

Thanks

Lucas


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

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

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.18-8~deb9u3
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u3
ii  libgcrypt201.7.6-2+deb9u3
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.16.2-5+deb9u1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnupg recommends:
ii  dirmngr 2.1.18-8~deb9u3
pn  gnupg-l10n  

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information


kameleon.gpg
Description: application/pgp-keys

Bug#879034: Use pdfarranger by Jerome Robert

[Marcel Schnirring]

This fork is maintained and includes all necessary bug fixes. It also
listens to push requests and other issues.




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#914688: Default defines discrepancy

[Markus Koschany]

Hi,

Am 26.11.18 um 15:13 schrieb Gianfranco Costamagna:
> control: tags -1 -wontfix -moreinfo
> control: affects -1 src:performous
> 
> Markus, please have a look at this bug :)

I don't know how I can help here. Performous only fails on powerpc
architectures which looks like a Boost bug to me. This only happened
recently when we switched to 1.67, so maybe forward upstream and let's
find out what the upstream developers think about that?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#914286: new stable upstream version 1.3 available

[Kevin Otte]

I'm not a developer, but I am quite interested in seeing this happen.

I was able to build a test package on a stretch VM by:
- downloading the 1.3 tarball from upstream
- grabbing the debian directory out of git
(https://salsa.debian.org/ron/opus.git)
- updating debian/changelog with a test entry for the upstream version
(I called it 1.3-1)
- running dpkg-buildpackage -b

So unless I'm missing something, it should be fairly straightforward to
sync salsa up with upstream and push a new package out.

Bug#914770: llvm-toolchain-7: baseline violation on i386

[Fanael Linithien]

śr., 28 lis 2018 o 09:55 Sylvestre Ledru  napisał(a):
> Excellent, many thanks.
>
> Could you please do a MR here
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/tree/7/ ?

Sure, done.

Bug#914943: libbg-dev: Please provide diet-libc version of library

[Gianfranco Costamagna]

On Wed, 28 Nov 2018 22:28:57 + Dmitry Bogatov  wrote:
> Package: libbg-dev
> Version: 2.04+dfsg-1
> Severity: wishlist
> 
> Dear Maintainer, please provide static version of library, linked with
> diet libc.
> 

Hello Dmitry,

the package is QA maintained, so feel free to do it and upload!

thanks in advance!

Gianfranco

> 

Bug#914841: egg 4.2.0-1.1+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

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

Thanks for your contribution!

Upload details
==

Package: egg
Version: 4.2.0-1.1+deb9u1

Explanation: skip emacsen-install for unsupported xemacs21

Bug#914392: transition: coin3

[Leopold Palomo-Avellaneda]

El 28/11/18 a les 19:12, Emilio Pozuelo Monfort ha escrit:
> On 22/11/2018 23:33, Leopold Palomo-Avellaneda wrote:
>> Subject: transition: coin3
>> Package: release.debian.org
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> Severity: normal
>>
>> Dear release team,
>>
>> I would like to ask a transition slot for the coin3 library. The package
>> has been reworked and a new version of the upstream has been packaged.
>>
>> Upstream have changed the build system to CMake and this has been used
>> for the package. This has an implication that it will break with FTBFS
>> the packages that use it: pivy, freecad, openscenegraph-3.4 and soqt, I
>> have contacted with all the maintainers and they are aware about it and
>> we are preparing patches or simple disable in any case.
> 
> Where are you discussing that? 

Almost all of them in private mails. I will adopt SoQt. I have been
working with that package and Anton Gladky know all my work. You can
check [1] qt5 branch.

With Kurt Kremitzki (freecad and pivy) we are in contact about how to
solve the migration.

And with openscenegraph I have interchanged some mail with one of the
maintainer about that.

I don't see bug reports for those packages.
> Please file bugs so that we can track the status and decide when to start this
> transition based on the disruption that it will cause. Also please make those
> bugs block this one.

we are waiting to have coin in unstable to push new versions/patches. About:

- soqt, no problematic. I have done it
- pivy. I was not able to build it with the coin3 cmake version. Waiting
that Kurt work on it. I'm not an Python expert. But it should be reasonable.
- Freecad, depends on pivy. The new version doesn't depends on soqt.
- openscengraph, it only uses coin to import wrl files in a plugin. In
the worse case it can be disabled, but that

Are you proposing that I fill a bug before the package fails?

Cheers,


Leopold


[1] https://salsa.debian.org/science-team/soqt/tree/Qt5



-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



signature.asc
Description: OpenPGP digital signature

Bug#914943: libbg-dev: Please provide diet-libc version of library

[Dmitry Bogatov]

Package: libbg-dev
Version: 2.04+dfsg-1
Severity: wishlist

Dear Maintainer, please provide static version of library, linked with
diet libc.

Bug#914867: emacspeak Info documentation not installed

[Samuel Thibault]

Zachary Kline, le mer. 28 nov. 2018 14:22:57 -0800, a ecrit:
> > On Nov 28, 2018, at 2:21 PM, Samuel Thibault  wrote:
> > 
> > Control: retitle -1 emacspeak Info documentation not installed because it 
> > is not free
> > Control: forwarded https://github.com/tvraman/emacspeak/issues/31
> > 
> > Zachary Kline, le mar. 27 nov. 2018 21:37:10 -0800, a ecrit:
> >> I expected Emacspeak's Info manual would be displayed.
> > 
> > Unfortunately we can not distributed it in Debian, because it is
> > non-free.  I have forwarded the issue upstream.
> 
> What about a non-dfsg package, as is done with the main Emacs info 
> documentation? Is that a possibility

We could upload that to the non-free archive yes, it's a matter of
taking the time to do it.

Samuel

Bug#914867: emacspeak Info documentation not installed

[Zachary Kline]

> On Nov 28, 2018, at 2:21 PM, Samuel Thibault  wrote:
> 
> Control: retitle -1 emacspeak Info documentation not installed because it is 
> not free
> Control: forwarded https://github.com/tvraman/emacspeak/issues/31
> 
> Zachary Kline, le mar. 27 nov. 2018 21:37:10 -0800, a ecrit:
>> I expected Emacspeak's Info manual would be displayed.
> 
> Unfortunately we can not distributed it in Debian, because it is
> non-free.  I have forwarded the issue upstream.
> 
> Samuel

What about a non-dfsg package, as is done with the main Emacs info 
documentation? Is that a possibility

Bug#913069: python3-arcus + python3-savitar missing in the transition page, but uninstallable

[Gregor Riepl]

>> But that doesn't suffice, there's likely a "| .build-depends ~
>> /python3-all-dev/" missing.
> 
> As pochu explained, that's not true.
> 
>> Affected source package is e.g. libarcus whose binary package
>> python3-arcus is currently uninstallable, but has no python3-dev in
>> the build-dependencies:
> 
> That's a bug: https://bugs.debian.org/905803
> 
>> The same counts for python3-savitar and src:libsavitar:
> 
> And another bug: https://bugs.debian.org/909730

I'm aware of the issues, but haven't found time to work on them lately.

> I'm CCing the maintainer, so he can be more aware of the small noises
> such "buggy" packages cause.

I can replace python3-all-dev with python3-dev for now, but it would be better
to actually fix this and have multi-python builds.

Arcus and Savitar are SIP modules written in C++ and built with cmake.
It's not trivial to make them build automagically for all installed Python
versions.

Any help on these bugs would be very much appreciated.

Bug#914942: mutter: why not having NEWS?

[Patrice Duroux]

Package: mutter
Version: 3.30.2-1
Severity: wishlist

Hi,
Here is my proposed patch to have the NEWS file as for the other GNOME
packages.
Thanks,
Patrice

ps: sorry but still not familiar with the great salsa.


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

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

Versions of packages mutter depends on:
ii  gnome-settings-daemon  3.30.1.2-1
ii  gsettings-desktop-schemas  3.28.1-1
ii  libc6  2.27-8
ii  libglib2.0-0   2.58.1-2
ii  libmutter-3-0  3.30.2-1
ii  libx11-6   2:1.6.7-1
ii  libxcomposite1 1:0.4.4-2
ii  mutter-common  3.30.2-1
ii  zenity 3.30.0-1

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:3.30.2-1
ii  xdg-user-dirs 0.17-1
>From e12f5d0a1227fc506e5eb328a096612e4f453a6e Mon Sep 17 00:00:00 2001
From: Patrice Duroux 
Date: Thu, 15 Nov 2018 21:54:10 +0100
Subject: [PATCH] add back lost NEWS

---
 debian/mutter.docs | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 debian/mutter.docs

diff --git a/debian/mutter.docs b/debian/mutter.docs
new file mode 100644
index 000..edc0071
--- /dev/null
+++ b/debian/mutter.docs
@@ -0,0 +1 @@
+NEWS
--
libgit2 0.27.4

Bug#914867: emacspeak Info documentation not installed

[Samuel Thibault]

Control: retitle -1 emacspeak Info documentation not installed because it is 
not free
Control: forwarded https://github.com/tvraman/emacspeak/issues/31

Zachary Kline, le mar. 27 nov. 2018 21:37:10 -0800, a ecrit:
> I expected Emacspeak's Info manual would be displayed.

Unfortunately we can not distributed it in Debian, because it is
non-free.  I have forwarded the issue upstream.

Samuel

Bug#914941: http-parser: CVE-2018-12121

[Jérémy Lal]

Source: http-parser
Severity: important
Tags: security

Hi,

I believe this commit should partly be applied to http-parser:
https://github.com/nodejs/node/commit/a8532d4d2

Specifically setting HTTP_MAX_HEADER_SIZE to a more reasonnable
default (8192 instead of 81920 bytes) should be good for all other
software depending on http-parser...

Jérémy


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

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

Bug#914940: libvirt-daemon-system: AppArmor definition missing for qemu-system-riscv64

[Evgheni Dereveanchin]

Package: libvirt-daemon-system
Version: 4.7.0-1+b1
Severity: normal

Dear Maintainer,

/etc/apparmor.d/abstractions/libvirt-qemu is missing the riscv64 binary
which is causing libvirt errors when trying to run a VM with this arch
on systems where AppArmor is enabled:

libvirt:  error : cannot execute binary /usr/bin/qemu-system-riscv64:
Permission denied

This binary is part of qemu-system-misc package and other ones shipped with it
are present in the above mentioned file.

Related AppArmor log line:

audit: type=1400 audit(1543440433.257:40): apparmor="DENIED"
operation="exec"
profile="libvirt-e2902a0d-9410-44b9-944f-81f470234b49"
name="/usr/bin/qemu-system-riscv64" pid=2210 comm="
libvirtd" requested_mask="x" denied_mask="x" fsuid=115 ouid=0


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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  gettext-base   0.19.8.1-9
ii  iptables   1.8.2-2
ii  libacl12.2.52-3+b1
ii  libapparmor1   2.13.1-3+b1
ii  libaudit1  1:2.8.4-2
ii  libblkid1  2.32.1-0.2
ii  libc6  2.27-8
ii  libcap-ng0 0.7.9-1
ii  libdbus-1-31.12.10-1
ii  libdevmapper1.02.1 2:1.02.145-4.1
ii  libgnutls303.5.19-1+b1
ii  libnl-3-2003.4.0-1
ii  libnl-route-3-200  3.4.0-1
ii  libnuma1   2.0.12-1
ii  libselinux12.8-1+b1
ii  libvirt-clients4.7.0-1+b1
ii  libvirt-daemon 4.7.0-1+b1
ii  libvirt0   4.7.0-1+b1
ii  libxml22.9.4+dfsg1-7+b2
ii  libyajl2   2.1.0-3
ii  logrotate  3.14.0-4
ii  lsb-base   9.20170808
ii  policykit-10.105-21

Versions of packages libvirt-daemon-system recommends:
ii  bridge-utils 1.5-16
ii  dmidecode3.2-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  ebtables 2.0.10.4-5
ii  iproute2 4.18.0-2
ii  parted   3.2-23

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.1-3+b1
pn  auditd  
pn  nfs-common  
pn  open-iscsi  
ii  pm-utils1.4.1-18
pn  radvd   
ii  systemd 239-13
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permission denied:
'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permission denied:
'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permission denied:
'/etc/libvirt/nwfilter/allow-ipv4.xml'
/etc/libvirt/nwfilter/clean-traffic-gateway.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/clean-traffic-gateway.xml'
/etc/libvirt/nwfilter/clean-traffic.xml [Errno 13] Permission denied:
'/etc/libvirt/nwfilter/clean-traffic.xml'
/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-spoofing.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/no-arp-spoofing.xml'
/etc/libvirt/nwfilter/no-ip-multicast.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/no-ip-multicast.xml'
/etc/libvirt/nwfilter/no-ip-spoofing.xml [Errno 13] Permission denied:
'/etc/libvirt/nwfilter/no-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-mac-broadcast.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/no-mac-broadcast.xml'
/etc/libvirt/nwfilter/no-mac-spoofing.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/no-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-other-l2-traffic.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/no-other-l2-traffic.xml'
/etc/libvirt/nwfilter/no-other-rarp-traffic.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/no-other-rarp-traffic.xml'
/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml [Errno 13]
Permission denied: '/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml'
/etc/libvirt/nwfilter/qemu-announce-self.xml [Errno 13] Permission
denied: '/etc/libvirt/nwfilter/qemu-announce-self.xml'
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'
/etc/libvirt/qemu/networks/default.xml [Errno 13] Permission denied:

Bug#914939: linux-image-4.9.0-8-amd64: broken DPMS on Libreboot/Thinkpad X200/i915/GMA4500

[Jakub Filo]

Package: src:linux
Version: 4.9.130-2
Severity: normal

Dear Maintainer,


* What leads up to the situation?

Turning off the display via DPMS (xset dpms force off), closing,
opening the lid and pressing a key to turn the display back on.

I can blindly use i3wm keyboard shortcuts to summon a terminal and 
type into it, but only black screen with a mouse cursor is visible. 
I can run pkill Xorg which kills my session and starts a new one 
bringing everything back to normal.

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

Downgraded to linux-image-4.9.0-7-amd64 as I knew that it worked well before.

* What was the outcome of this action?

DPMS works as expected

** Kernel log from the incident:

[  163.811458] [ cut here ]
[  163.811549] WARNING: CPU: 1 PID: 4654 at
/build/linux-EbeuWA/linux-4.9.130/drivers/gpu/drm/i915/intel_display.c:12482 
intel_plane_atomic_calc_changes+0x227/0x570 [i915]
[  163.811551] WARN_ON(was_visible)
[  163.811555] Modules linked in:
[  163.811557]  ctr ccm bnep iTCO_wdt iTCO_vendor_support coretemp
kvm_intel kvm irqbypass snd_hda_codec_conexant snd_hda_codec_generic
pcspkr psmouse bridge stp llc arc4 uvcvideo videobuf2_vmalloc ath9k
videobuf2_memops videobuf2_v4l2 ath9k_common videobuf2_core videodev
ath9k_hw sg ip6table_filter media ath ip6_tables i915 mac80211 btusb
btrtl btbcm btintel cfg80211 ipt_REJECT bluetooth nf_reject_ipv4 e1000e
xt_tcpudp drm_kms_helper drm lpc_ich i2c_i801 nf_conntrack_ipv4
snd_hda_intel mfd_core nf_defrag_ipv4 snd_hda_codec i2c_smbus
i2c_algo_bit snd_hda_core ptp ehci_pci snd_hwdep pps_core snd_pcm
snd_timer shpchp xt_conntrack nf_conntrack iptable_filter thinkpad_acpi
nvram snd soundcore rfkill ac battery binfmt_misc video acpi_cpufreq
button ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic
[  163.811703]  fscrypto ecb glue_helper lrw ablk_helper cryptd
aes_x86_64 mbcache xts gf128mul dm_crypt dm_mod sd_mod hid_generic
usbhid hid ahci libahci evdev libata serio_raw scsi_mod uhci_hcd
ehci_hcd usbcore usb_common thermal
[  163.811757] CPU: 1 PID: 4654 Comm: Xorg Tainted: G  I
4.9.0-8-amd64 #1 Debian 4.9.130-2
[  163.811760] Hardware name: LENOVO 74598Z4/74598Z4, BIOS CBET4000
3774c98 09/07/2016
[  163.811764]   99533d74 a0ea81893a88

[  163.811774]  9927a59e 8c7628da6180 a0ea81893ae0
8c762abc6c00
[  163.811782]  8c7629413000 0001 
9927a61f
[  163.811789] Call Trace:
[  163.811804]  [] ? dump_stack+0x5c/0x78
[  163.811810]  [] ? __warn+0xbe/0xe0
[  163.811815]  [] ? warn_slowpath_fmt+0x5f/0x80
[  163.811867]  [] ? drm_rect_calc_vscale+0x23/0x50
[drm]
[  163.811937]  [] ?
intel_plane_atomic_calc_changes+0x227/0x570 [i915]
[  163.811963]  [] ?
drm_atomic_helper_check_planes+0x7a/0x1e0 [drm_kms_helper]
[  163.812029]  [] ? intel_atomic_check+0xa7b/0x1080
[i915]
[  163.812069]  [] ? drm_atomic_check_only+0x307/0x5a0
[drm]
[  163.812107]  [] ?
drm_atomic_set_crtc_for_connector+0xb9/0xf0 [drm]
[  163.812145]  [] ? drm_atomic_commit+0x12/0x50 [drm]
[  163.812164]  [] ?
drm_atomic_helper_set_config+0x79/0xb0 [drm_kms_helper]
[  163.812201]  [] ?
drm_mode_set_config_internal+0x67/0x110 [drm]
[  163.812239]  [] ? drm_mode_setcrtc+0x3c7/0x4a0
[drm]
[  163.812272]  [] ? drm_ioctl+0x1ed/0x470 [drm]
[  163.812309]  [] ? drm_mode_getcrtc+0x120/0x120
[drm]
[  163.812318]  [] ? do_vfs_ioctl+0xa2/0x620
[  163.812325]  [] ? vfs_read+0x119/0x130
[  163.812330]  [] ? SyS_ioctl+0x74/0x80
[  163.812337]  [] ? do_syscall_64+0x8d/0xf0
[  163.812344]  [] ?
entry_SYSCALL_64_after_swapgs+0x58/0xc6
[  163.812393] ---[ end trace f68728a0d3053b54 ]---
[  172.563349] [ cut here ]
[  172.563440] WARNING: CPU: 1 PID: 4654 at
/build/linux-EbeuWA/linux-4.9.130/drivers/gpu/drm/i915/intel_display.c:12482
intel_plane_atomic_calc_changes+0x227/0x570 [i915]
[  172.563442] WARN_ON(was_visible)
[  172.563445] Modules linked in:
[  172.563448]  ctr ccm bnep iTCO_wdt iTCO_vendor_support coretemp
kvm_intel kvm irqbypass snd_hda_codec_conexant snd_hda_codec_generic
pcspkr psmouse bridge stp llc arc4 uvcvideo videobuf2_vmalloc ath9k
videobuf2_memops videobuf2_v4l2 ath9k_common videobuf2_core videodev
ath9k_hw sg ip6table_filter media ath ip6_tables i915 mac80211 btusb
btrtl btbcm btintel cfg80211 ipt_REJECT bluetooth nf_reject_ipv4 e1000e
xt_tcpudp drm_kms_helper drm lpc_ich i2c_i801 nf_conntrack_ipv4
snd_hda_intel mfd_core nf_defrag_ipv4 snd_hda_codec i2c_smbus
i2c_algo_bit snd_hda_core ptp ehci_pci snd_hwdep pps_core snd_pcm
snd_timer shpchp xt_conntrack nf_conntrack iptable_filter thinkpad_acpi
nvram snd soundcore rfkill ac battery binfmt_misc video acpi_cpufreq
button ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic
[  172.563594]  fscrypto ecb glue_helper lrw ablk_helper cryptd
aes_x86_64 mbcache xts gf128mul dm_crypt dm_mod sd_mod hid_generic
usbhid hid ahci libahci evdev libata serio_raw 

Bug#914931: [Pkg-openssl-devel] Bug#914931: pagekite: Fail to connect to pagekite.me services with openssl installed

[Sebastian Andrzej Siewior]

On 2018-11-28 21:25:45 [+0100], Petter Reinholdtsen wrote:
> The upgrade from openssl version 1.1.0h-4 to 1.1.1-1 break pagekite on
> the FreedomBox.  After a debug session with the pagekite author I
> discovered the reason is changes in /etc/ssl/openssl.cfg, which now
> block connection to the pagekite.net services.

nitpick, .cnf not cfg.

> The following change got the pagekite service working again.
> 
> The backdrop for this issue is that some of the pagekite.net servers are
> running fairly old software that can not be quickly reconfigured to work
> with newer versions of TLS.  This make fixing it on the server side
> unlikely to happen any time soon.

The server still supports SSLv3. Even if nobody wants to touch the
server I would suggest disabling SSLv3 be a priority.

> CC to the openssl and freedombox teams to make them aware of the issue.

We tried to cover this in
/usr/share/doc/libssl1.1/NEWS.Debian.gz

> The following patch got pagekite working again:
> 
> diff --git a/ssl/openssl.cnf b/ssl/openssl.cnf
> index d155d1e..309081a 100644
> --- a/ssl/openssl.cnf
> +++ b/ssl/openssl.cnf
> @@ -351,12 +351,12 @@ ess_cert_id_chain = no# Must the ESS cert id chain 
> be included?
> # (optional, default: no)
>  ess_cert_id_alg= sha1  # algorithm to compute certificate
> # identifier (optional, default: sha1)
> -[default_conf]
> -ssl_conf = ssl_sect
> -
> -[ssl_sect]
> -system_default = system_default_sect
> -
> -[system_default_sect]
> -MinProtocol = TLSv1.2
> -CipherString = DEFAULT@SECLEVEL=2
> +#[default_conf]
> +#ssl_conf = ssl_sect
> +#
> +#[ssl_sect]
> +#system_default = system_default_sect
> +#
> +#[system_default_sect]
> +#MinProtocol = TLSv1.2
> +#CipherString = DEFAULT@SECLEVEL=2

You might not need to get rid of everything. Judging by
https://www.ssllabs.com/ssltest/analyze.html?d=pagekite.net

it might be enough to just allow TLS1.0. You might want to add this
override only for pagekite and not system wide.

Sebastian

Bug#914938: man.1: Rephrase the explanation of "MANROFFOPT" in the manual

[Bjarni Ingi Gislason]

Package: man-db
Version: 2.8.4-3
Severity: minor

Dear Maintainer,

  the current wording for the option "MANROFFOPT" is:

The contents of $MANROFFOPT are added to the command line every time man
invokes the formatter (nroff, troff, or groff).


  1) This has lead to a misconception by me, understanding "command
line" as being for the "man" command.

  2) The piece "ROFF" in the name is "buried" in the name, so it was
not really noticed by me until now ("MAN_ROFF_OPT" would let "ROFF"
stand out).

  So I suggest making it explicit what "command line" refers to:

... added to the command line of the formatter (nroff, troff, or groff)
every time man invokes it.

  The option "MANROFFOPT" can solve a "problem" I have had with the
input variable 'F' in manuals created by "pod2man".

  See for example debian bug #847972, bug-groff #52983, and web page
rt.cpan.org/Ticket/Display.html?id=75434.



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

Kernel: Linux 4.18.10-2 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.69
ii  dpkg   1.19.2
ii  groff-base 1.22.3-10
ii  libc6  2.27-8
ii  libgdbm6   1.18.1-2
ii  libpipeline1   1.5.0-2
ii  libseccomp22.3.3-3
ii  zlib1g 1:1.2.11.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor   
ii  firefox-esr [www-browser]  60.3.0esr-1
ii  groff  1.22.3-10
ii  less   487-0.1+b1
ii  lynx [www-browser] 2.8.9rel.1-2
ii  w3m [www-browser]  0.5.3-36+b1

-- debconf information:
  man-db/auto-update: true
  man-db/install-setuid: false

-- 
Bjarni I. Gislason

Bug#910609: updated patch

[Jeffrey Cliff]

looks like I garbled the last patch, this one works better:
diff -cr -x '*.git' colors.js-1.1.2/debian/changelog colors.js-1.2.4/debian/changelog
*** colors.js-1.1.2/debian/changelog	2018-10-08 16:44:05.0 +
--- colors.js-1.2.4/debian/changelog	2018-10-08 16:48:54.959668251 +
***
*** 1,3 
--- 1,9 
+ colors.js (1.2.4-1) UNRELEASED; urgency=medium
+ 
+   * New upstream version 1.2.4-1
+ 
+  -- Jeffrey Cliff   Mon, 08 Oct 2018 09:57:02 +0500
+ 
  colors.js (1.1.2-1) unstable; urgency=medium
  
* New upstream version 1.1.2
diff -cr -x '*.git' colors.js-1.1.2/debian/control colors.js-1.2.4/debian/control
*** colors.js-1.1.2/debian/control	2018-10-08 16:44:05.0 +
--- colors.js-1.2.4/debian/control	2018-10-08 16:46:38.563887826 +
***
*** 11,16 
  
  Package: node-colors
  Architecture: all
! Depends: ${misc:Depends}, nodejs
  Description: Get color and style in your node.js console
   This package contains the NodeJS module.
--- 11,16 
  
  Package: node-colors
  Architecture: all
! Depends: ${misc:Depends}, nodejs(>= 0.1.90)
  Description: Get color and style in your node.js console
   This package contains the NodeJS module.
Only in colors.js-1.2.4/debian: .debhelper
Only in colors.js-1.2.4/debian: files
Only in colors.js-1.2.4/debian: node-colors.substvars
Only in colors.js-1.2.4: .eslintrc.json
diff -cr -x '*.git' colors.js-1.1.2/examples/normal-usage.js colors.js-1.2.4/examples/normal-usage.js
*** colors.js-1.1.2/examples/normal-usage.js	2015-06-17 13:01:51.0 +
--- colors.js-1.2.4/examples/normal-usage.js	2018-10-08 16:23:36.922055319 +
***
*** 1,34 
  var colors = require('../lib/index');
  
! console.log("First some yellow text".yellow);
  
! console.log("Underline that text".yellow.underline);
  
! console.log("Make it bold and red".red.bold);
  
! console.log(("Double Raindows All Day Long").rainbow)
  
! console.log("Drop the bass".trap)
  
! console.log("DROP THE RAINBOW BASS".trap.rainbow)
  
  
! console.log('Chains are also cool.'.bold.italic.underline.red); // styles not widely supported
! 
! console.log('So '.green + 'are'.underline + ' ' + 'inverse'.inverse + ' styles! '.yellow.bold); // styles not widely supported
! console.log("Zebras are so fun!".zebra);
  
  //
  // Remark: .strikethrough may not work with Mac OS Terminal App
  //
! console.log("This is " + "not".strikethrough + " fun.");
  
! console.log('Background color attack!'.black.bgWhite)
! console.log('Use random styles on everything!'.random)
! console.log('America, Heck Yeah!'.america)
  
  
! console.log('Setting themes is useful')
  
  //
  // Custom themes
--- 1,36 
  var colors = require('../lib/index');
  
! console.log('First some yellow text'.yellow);
  
! console.log('Underline that text'.yellow.underline);
  
! console.log('Make it bold and red'.red.bold);
  
! console.log(('Double Raindows All Day Long').rainbow);
  
! console.log('Drop the bass'.trap);
  
! console.log('DROP THE RAINBOW BASS'.trap.rainbow);
  
+ // styles not widely supported
+ console.log('Chains are also cool.'.bold.italic.underline.red);
  
! // styles not widely supported
! console.log('So '.green + 'are'.underline + ' ' + 'inverse'.inverse
!   + ' styles! '.yellow.bold);
! console.log('Zebras are so fun!'.zebra);
  
  //
  // Remark: .strikethrough may not work with Mac OS Terminal App
  //
! console.log('This is ' + 'not'.strikethrough + ' fun.');
  
! console.log('Background color attack!'.black.bgWhite);
! console.log('Use random styles on everything!'.random);
! console.log('America, Heck Yeah!'.america);
  
  
! console.log('Setting themes is useful');
  
  //
  // Custom themes
***
*** 45,74 
help: 'cyan',
warn: 'yellow',
debug: 'blue',
!   error: 'red'
  });
  
  // outputs red text
! console.log("this is an error".error);
  
  // outputs yellow text
! console.log("this is a warning".warn);
  
  // outputs grey text
! console.log("this is an input".input);
  
  console.log('Generic logging theme as file'.green.bold.underline);
  
  // Load a theme from file
! colors.setTheme(__dirname + '/../themes/generic-logging.js');
  
  // outputs red text
! console.log("this is an error".error);
  
  // outputs yellow text
! console.log("this is a warning".warn);
  
  // outputs grey text
! console.log("this is an input".input);
  
- //console.log("Don't summon".zalgo)
\ No newline at end of file
--- 47,81 
help: 'cyan',
warn: 'yellow',
debug: 'blue',
!   error: 'red',
  });
  
  // outputs red text
! console.log('this is an error'.error);
  
  // outputs yellow text
! console.log('this is a warning'.warn);
  
  // outputs grey text
! console.log('this is an input'.input);
  
  console.log('Generic logging theme as file'.green.bold.underline);
  
  // Load a theme from file
! try {
!   colors.setTheme(require(__dirname + '/../themes/generic-logging.js'));
! } catch (err) {
!   console.log(err);
! }
  

Bug#914516: transition: hunspell

[Rene Engelhard]

Hi,

On Wed, Nov 28, 2018 at 07:07:54PM +0100, Emilio Pozuelo Monfort wrote:
> On 24/11/2018 11:07, Rene Engelhard wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > hunspell 1.7 was finally released. It includes a load of fixes
> > we miss e.g. in LibreOffice because instead of using the
> > patched-internal version we use the system version.
> > 
> > Cleared NEW just now.
> > 
> > So I'd like to get this transition done asap after
> > icu/boost/python3.7-as-default is done :)
> > 
> > Did a rebuild using ratt and (almost) all packages built fine, except
> > some otherwise failing packages (mudlet and plume-creator (both sid
> > only) because of #907159 and #887534)
> > I skipped firefox, too; firefox-esr is fine.
> > (And libreoffice, but libreoffice is "of course" fine, too)
> 
> Go ahead.

Uploaded.

Regards,

Rene

Bug#914934:

[Patrice Duroux]

Sorry I have not tried this yet. Sure you can consider me as a beginner (or to
old school) so I just follow my instinct (more over giving a look at 
https://wiki.debian.org/HowToGetABacktrace does not help so much :-))

Then if this is not a useful suggestion at all it can be closed.
Again sorry for that.

Thanks,
Patrice

Bug#914937: edfbrowser: fix dh_auto_configure overriding

[Pino Toscano]

Source: edfbrowser
Version: 1.66+dfsg-1
Severity: minor
Tags: patch

Hi,

the current rules overrides dh_auto_build to run qmake manually again,
specifying build flags.  OTOH, this runs qmake again, and it is not
needed with newer debhelper: using the DEB__MAINT_APPEND interface
of dpkg-buildflags will append the right flags when qmake is called by
the default dh_auto_configure invocation.  Also, debhelper already
handles noopt in DEB_BUILD_OPTIONS already.

Hence, the attached patch simplifies rules a lot, dropping also
variables not needed (anymore).

Thanks,
-- 
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -5,37 +5,19 @@
 # export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE  )
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE )
-DEB_BUILD_ARCH_OS   ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS  )
-ARCH:= $(shell dpkg-architecture -qDEB_BUILD_ARCH )
-
-Q_LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) -Wl,--as-needed
-export Q_LDFLAGS
-
-# of course, qmake wants to do it its own way
-QMAKE_CXXFLAGS += $(CPPFLAGS) -Wall -Wshadow -Wextra -ggdb3
-ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-  QMAKE_CXXFLAGS_RELEASE = -O0
-else
-  QMAKE_CXXFLAGS_RELEASE = -O2
-endif
+export DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed
+export DEB_CXXFLAGS_MAINT_APPEND := -Wall -Wshadow -Wextra -ggdb3
 
 export QT_SELECT=qt5
 
 %:
dh $@
 
-override_dh_auto_build:
-   qmake -makefile -after \
-   QMAKE_CXXFLAGS="$(QMAKE_CXXFLAGS)" \
-   QMAKE_CXXFLAGS_RELEASE="$(QMAKE_CXXFLAGS_RELEASE)" \
-   QMAKE_LFLAGS="$(Q_LDFLAGS)"
+override_dh_auto_configure:
+   dh_auto_configure
# libpthread is only used indirectly; no need for linking against it
sed -i -e 's/-lpthread//' Makefile
 
-   $(MAKE)
-
 override_dh_clean:
test ! -f Makefile  ||  $(MAKE) distclean
dh_clean

Bug#914936: netcf: reproducible build (usrmerge): Embeds full path to ifup/ifdown found via PATH

[Andreas Henriksson]

Package: netcf
Version: 0.2.8-1
Severity: normal
Tags: patch
User: m...@linux.it
Usertags: usrmerge

Dear Maintainer,

The reproducible build spotted a difference in your package when
built on a usrmerged system vs a non-merged system:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/netcf.html

It seems a few files contains the full path of 'ifup' and 'ifdown' found
via AC_PROG_PATH during build.

Since PATH defaults to contain /usr/sbin before /sbin the found path will
be /usr/sbin/if{up,down} on a usrmerged system, since both paths are
essentially the same thing there. This is however not desirable on
a non-merged system where it needs to be /sbin/if{up,down}.

The attached patch fixes the problem by explicitly specifying
the default path via IFUP and IFDOWN variable passed to configure
as documented in AC_PROG_PATH documentation.

(This is likely a good idea either way, since otherwise hypothetical
problems could happen for users building on their system with
/usr/local/bin/... or ~/bin/)

An alternative way to fix this:
You're already explicitly appending :sbin to $PATH in configure.ac.
You could prepend instead of append and that should thus make
the tools be found via the path that's desired here.
This feels a bit like taking a chance to me though, so I still think
explicitly passing the correct path is the better thing to do.

Regards,
Andreas Henriksson
diff -Nru netcf-0.2.8/debian/changelog netcf-0.2.8/debian/changelog
--- netcf-0.2.8/debian/changelog2015-09-23 22:46:21.0 +0200
+++ netcf-0.2.8/debian/changelog2018-11-28 22:11:09.0 +0100
@@ -1,3 +1,11 @@
+netcf (1:0.2.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Pass IFUP=/sbin/ifup and IFDOWN=/sbin/ifdown arguments to configure
+- this fixes reproducible build issue on merged-usr vs non-merged.
+
+ -- Andreas Henriksson   Wed, 28 Nov 2018 22:11:09 +0100
+
 netcf (1:0.2.8-1) unstable; urgency=medium
 
   * Import new upstream 2.8.0
diff -Nru netcf-0.2.8/debian/rules netcf-0.2.8/debian/rules
--- netcf-0.2.8/debian/rules2014-08-28 22:21:45.0 +0200
+++ netcf-0.2.8/debian/rules2018-11-28 22:11:06.0 +0100
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 DEB_BUILD_PARALLEL = yes
-DEB_CONFIGURE_EXTRA_FLAGS := --with-driver=debian
+DEB_CONFIGURE_EXTRA_FLAGS := --with-driver=debian IFUP=/sbin/ifup 
IFDOWN=/sbin/ifdown
 
 LDFLAGS += -Wl,--as-needed
 

Bug#914934: systemd-coredump: at least suggest lz4?

[Michael Biebl]

On Wed, 28 Nov 2018 21:58:07 +0100 Patrice Duroux
 wrote:
> Package: systemd-coredump
> Version: 239-13
> Severity: normal
> 
> Hi,
> 
> Trying to debug a trouble with the tracker package (in fact with 
> tracker-extract) so I have installed systemd-coredump. Then I got in few 
> seconds 2,2G for 118 files in /var/lib/systemd/coredump. Ok that is another 
> point. They are LZ4 compressed by default. Then should systemd-coredump 
> suggest lz4 tool?
> gdb is not able to read such coredump, isn't it?
> 

See man coredumpctl how to execute gdb. Compressed coredumps will be
handled automatically by coredumpctl.
Are you saying this is not the case?

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#911627: python-openflow: diff for NMU version 2017.2b1+dfsg-2.1

[Adrian Bunk]

On Tue, Nov 27, 2018 at 10:20:57AM -0200, Paulo Henrique de Lima Santana wrote:
> Hi Adrian,
> 
> Thanks for your help!
> Do you mind if you cancel your NMU?

Fine for me, cancelled.

> I will update the upstream software and use your solution.

Thanks!

> Best regards.

cu
Adrian

-- 

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

Bug#914935: enca: reproducible build (usrmerge): Embeds full path to mktemp found via PATH

[Andreas Henriksson]

Package: enca
Version: 1.19-1
Severity: normal
Tags: patch
User: m...@linux.it
Usertags: usrmerge

Dear Maintainer,

The reproducible build spotted a difference in your package when
built on a usrmerged system vs a non-merged system:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/enca.html

It seems a few files contains the full path of 'mktemp' found via
AC_PROG_PATH during build.

Since PATH defaults to contain /usr/bin before /bin the found path will
be /usr/bin/mktemp on a usrmerged system, since both paths are
essentially the same thing there. This is however not desirable on
a non-merged system where it needs to be /bin/mktemp.

The attached patch fixes the problem by explicitly specifying
the default path via MKTEMP_PROG environment variable as documented
in AC_PROG_PATH documentation.

(This is likely a good idea either way, since otherwise hypothetical
problems could happen for users building on their system with
/usr/local/bin/... or ~/bin/)

Regards,
Andreas Henriksson
diff -Nru enca-1.19/debian/changelog enca-1.19/debian/changelog
--- enca-1.19/debian/changelog  2016-09-05 16:23:32.0 +0200
+++ enca-1.19/debian/changelog  2018-11-28 21:59:20.0 +0100
@@ -1,3 +1,11 @@
+enca (1.19-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Pass MKTEMP_PROG=/bin/mktemp to configure instead of finding in PATH
+- this fixes reproducible build issue on merged-usr vs non-merged.
+
+ -- Andreas Henriksson   Wed, 28 Nov 2018 21:59:20 +0100
+
 enca (1.19-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru enca-1.19/debian/rules enca-1.19/debian/rules
--- enca-1.19/debian/rules  2016-01-07 09:27:18.0 +0100
+++ enca-1.19/debian/rules  2018-11-28 21:59:15.0 +0100
@@ -5,7 +5,8 @@
   --libexecdir=\$${prefix}/lib \
   --with-librecode \
   --with-libiconv \
-  --disable-rpath
+  --disable-rpath \
+  MKTEMP_PROG=/bin/mktemp
 
 override_dh_strip:
dh_strip --dbg-package=libenca-dbg

Bug#914934: systemd-coredump: at least suggest lz4?

[Patrice Duroux]

Package: systemd-coredump
Version: 239-13
Severity: normal

Hi,

Trying to debug a trouble with the tracker package (in fact with 
tracker-extract) so I have installed systemd-coredump. Then I got in few 
seconds 2,2G for 118 files in /var/lib/systemd/coredump. Ok that is another 
point. They are LZ4 compressed by default. Then should systemd-coredump suggest 
lz4 tool?
gdb is not able to read such coredump, isn't it?

Thanks,
Patrice 

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

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

Versions of packages systemd-coredump depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libc62.27-8
ii  libdw1   0.175-1
ii  libelf1  0.175-1
ii  systemd  239-13

systemd-coredump recommends no packages.

systemd-coredump suggests no packages.

-- no debconf information

Bug#914933: usermode: reproducible build (usrmerge): Embeds full path to fdformat in usermount binary

[Andreas Henriksson]

Package: usermode
Version: 1.109-1
Severity: normal
Tags: patch
User: m...@linux.it
Usertags: usrmerge

Dear Maintainer,

The reproducible build spotted a difference in your package when
built on a usrmerged system vs a non-merged system:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/usermode.html

It seems usermount contains the full path of 'fdformat' (et.al.) found via
AC_PROG_PATH during build.

Unlike other similar cases, the usermode configure.ac specifies its
own PATHs to search (rather than relyin on $PATH from environment).
While explicitly passing in paths to search as an argument it orders
/bin and /sbin before /usr/bin and /usr/sbin respectively (opposite
to how PATH is normally configured).

This makes tools always be found via /bin or /sbin (which are symlinks
to /usr/bin and /usr/sbin or merged-usr systems), thus the fdformat
path ends up as /sbin/fdformat on a merged-usr system. As the tool
really lives at /usr/sbin/fdformat, the result thus differs on a
merged-usr system vs a non-merged one.

Another possible way to fix this is to change the directory ordering
for fdformat in configure.ac, but that makes several assumptions:
- other distributions places things the same way we do (or don't
  care because they've already made usrmerge mandatory).
- no tool will be moved in the future
I thus don't think this is a good idea and it's probably a better
idea to just explicitly specifying the paths we want and expect
explicitly at configure time.

The attached patch fixes the problem by explicitly specifying
the default path via MOUNT, UMOUNT, MKFS, FDFORMAT variables
passed to configure as documented in AC_PROG_PATH documentation.

Regards,
Andreas Henriksson

diff -Nru usermode-1.109/debian/changelog usermode-1.109/debian/changelog
--- usermode-1.109/debian/changelog 2012-03-08 02:01:51.0 +0100
+++ usermode-1.109/debian/changelog 2018-11-28 21:41:25.0 +0100
@@ -1,3 +1,12 @@
+usermode (1.109-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly set paths for fdformat, et.al. to avoid relying
+on automatically finding them through path. This fixes
+reproducible builds on merged-usr vs non-merged systems.
+
+ -- Andreas Henriksson   Wed, 28 Nov 2018 21:41:25 +0100
+
 usermode (1.109-1) unstable; urgency=low
 
   * New maintainer (Closes: #583242).
diff -Nru usermode-1.109/debian/rules usermode-1.109/debian/rules
--- usermode-1.109/debian/rules 2012-03-08 02:01:51.0 +0100
+++ usermode-1.109/debian/rules 2018-11-28 21:40:43.0 +0100
@@ -6,6 +6,13 @@
 %:
dh $@
 
+override_dh_auto_configure:
+   dh_auto_configure -- \
+   MOUNT=/bin/mount \
+   UMOUNT=/bin/umount \
+   MKFS=/sbin/mkfs \
+   FDFORMAT=/usr/bin/fdformat
+
 override_dh_install: user_icon.xpm password.xpm disks.xpm
dh_install 
# this functionality doesn't appear to be supported in Debian

Bug#914932: flatpak: accumulation of /var/tmp/flatpak-cache-XXXXXX directory

[Patrice Duroux]

Package: flatpak
Version: 1.0.6-1
Severity: normal

Dear Maintainer,

By curiosity I have done a look at the /var/tmp directory to discover an 
accumulation of flatpak-cache-XX for months for my single user. Is that 
really something desired? What could be the situation on a server? Should not 
it be in at least in /tmp?

Regards,
Patrice

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

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

Versions of packages flatpak depends on:
ii  bubblewrap 0.3.1-2
ii  libappstream-glib8 0.7.12-1
ii  libarchive13   3.2.2-5
ii  libc6  2.27-8
ii  libglib2.0-0   2.58.1-2
ii  libgpgme11 1.12.0-4
ii  libjson-glib-1.0-0 1.4.4-1
ii  libostree-1-1  2018.9.1-1
ii  libpolkit-gobject-1-0  0.105-22
ii  libseccomp22.3.3-3
ii  libsoup2.4-1   2.64.2-1
ii  libxau61:1.0.8-1+b2
ii  libxml22.9.4+dfsg1-7+b2
ii  xdg-desktop-portal 1.0.3-1

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.23-4
ii  gtk-update-icon-cache3.24.1-2
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   239-13
ii  p11-kit  0.23.14-2
ii  policykit-1  0.105-22
ii  shared-mime-info 1.10-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.0.2-2

Versions of packages flatpak suggests:
ii  avahi-daemon  0.7-4+b1

-- no debconf information

Bug#914931: pagekite: Fail to connect to pagekite.me services with openssl installed

[Petter Reinholdtsen]

Package: pagekite
Version: 0.5.9.3-2
Severity: important
X-Debbugs-CC: Debian OpenSSL Team , 
FreedomBox packaging team 

The upgrade from openssl version 1.1.0h-4 to 1.1.1-1 break pagekite on
the FreedomBox.  After a debug session with the pagekite author I
discovered the reason is changes in /etc/ssl/openssl.cfg, which now
block connection to the pagekite.net services.

The following change got the pagekite service working again.

The backdrop for this issue is that some of the pagekite.net servers are
running fairly old software that can not be quickly reconfigured to work
with newer versions of TLS.  This make fixing it on the server side
unlikely to happen any time soon.

CC to the openssl and freedombox teams to make them aware of the issue.

The following patch got pagekite working again:

diff --git a/ssl/openssl.cnf b/ssl/openssl.cnf
index d155d1e..309081a 100644
--- a/ssl/openssl.cnf
+++ b/ssl/openssl.cnf
@@ -351,12 +351,12 @@ ess_cert_id_chain = no# Must the ESS cert id chain be 
included?
# (optional, default: no)
 ess_cert_id_alg= sha1  # algorithm to compute certificate
# identifier (optional, default: sha1)
-[default_conf]
-ssl_conf = ssl_sect
-
-[ssl_sect]
-system_default = system_default_sect
-
-[system_default_sect]
-MinProtocol = TLSv1.2
-CipherString = DEFAULT@SECLEVEL=2
+#[default_conf]
+#ssl_conf = ssl_sect
+#
+#[ssl_sect]
+#system_default = system_default_sect
+#
+#[system_default_sect]
+#MinProtocol = TLSv1.2
+#CipherString = DEFAULT@SECLEVEL=2

-- 
Happy hacking
Petter Reinholdtsen

Bug#914930: dbus-python: FTBCFS in python3-defaults transition

[Simon McVittie]

What does the acronym FTBCFS mean? I know about FTBFS (fails to build
from source), and I know about FTCBFS (fails to cross-build from source),
but I don't know what FTBCFS is. Fails to build in CI from source? Fails
to build completely from source?

If you're filing similar bugs on other packages it would be helpful to
expand the acronym or choose a non-acronym term for what you mean.

(I know you've closed this particular bug as a false positive.)

smcv

Bug#908834: please build libzstd udeb so that btrfs-progs can use zstd in Debian Installer

[Alex Mestiashvili]

> It seems libzstd 1.3.5+dfsg-2 hasn't yet reached the archive.  Maybe
> it was not uploaded, or maybe it was rejected for some reason?
> 
>   
> https://salsa.debian.org/med-team/libzstd/commit/9b865b77d2bfc41c5865f255cf3e4aae18bbe934
> 
> Thanks you for working on this!
> Nicholas


Hi Nicholas, it is in the new queue:

 https://ftp-master.debian.org/new/libzstd_1.3.5+dfsg-2.html

We just need to wait or ?

Bug#914048: closed by Peter Palfrader (Re: Bug#914048: mirror submission for debian.petarmaric.com)

[Petar Marić]

Hi Peter,

I accidentally missed your initial "source packages" related email. I've
updated the ftpsync configuration and forced a new mirror sync.

Can you please recheck debian.petarmaric.com?

Cheers,

On Wed, 28 Nov 2018 at 12:54, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the mirrors package:
>
> #914048: mirror submission for debian.petarmaric.com [missing sources]
>
> It has been closed by Peter Palfrader .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Peter Palfrader <
> wea...@debian.org> by
> replying to this email.
>
>
> --
> 914048: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914048
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Peter Palfrader 
> To: Petar Maric , 914048-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 28 Nov 2018 11:50:44 +
> Subject: Re: Bug#914048: mirror submission for debian.petarmaric.com
> Rejecting this ticket for now.  Feel free to resubmit once you have
> sources.
>
> Cheers,
>
> On Mon, 19 Nov 2018, Peter Palfrader wrote:
>
> > On Sun, 18 Nov 2018, Petar Maric wrote:
> >
> > > Site: debian.petarmaric.com
> > > Archive-architecture: amd64 i386
> > > Archive-http: /debian/
> > > Maintainer: Petar Maric 
> > >
> > > Trace Url: http://debian.petarmaric.com/debian/project/trace/
> > > Trace Url:
> http://debian.petarmaric.com/debian/project/trace/ftp-master.debian.org
> > > Trace Url:
> http://debian.petarmaric.com/debian/project/trace/debian.petarmaric.com
> >
> > It appears this mirror does not have sources.
> >
> > We require that mirrors we list also have source packages, please mirror
> > those also.
> >
> > Independent of our listing requirement, the license of various pieces of
> > Debian might require you to also ship sources if you ship binaries.
>
>
> -- Forwarded message --
> From: Petar Maric 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 18 Nov 2018 20:02:12 +
> Subject: mirror submission for debian.petarmaric.com
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
>
> Submission-Type: new
> Site: debian.petarmaric.com
> Type: leaf
> Archive-architecture: amd64 i386
> Archive-http: /debian/
> Maintainer: Petar Maric 
> Country: RS Serbia
> Location: Novi Sad
> Sponsor: Faculty of Technical Sciences, University of Novi Sad
> http://www.ftn.uns.ac.rs/
> Comment: INFO_THROUGHPUT=500Mb
>
>
>
>
>
> Trace Url: http://debian.petarmaric.com/debian/project/trace/
> Trace Url:
> http://debian.petarmaric.com/debian/project/trace/ftp-master.debian.org
> Trace Url:
> http://debian.petarmaric.com/debian/project/trace/debian.petarmaric.com
>


-- 
Petar Marić
petar.ma...@gmail.com
http://www.petarmaric.com/

Bug#914930: dbus-python: FTBCFS in python3-defaults transition

[Paul Gevers]

Source: dbus-python
Version: 1.2.8-2
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

[X-Debbugs-CC: debian...@lists.debian.org,
python3-defau...@packages.debian.org]

Dear maintainers,

After a binNMU [1] of dbus-python in the python3-defaults transition
(from python3.6 to python3.7 as default python3) your package is
uninstallable because of the following dependencies:
 Depends: dbus, python3-dbus, python3 (<< 3.7), python3 (>= 3.6~),
python3.7, python3.7:any, python3:any (>= 3.3.2-2~), python3.6,
python3.6:any, libc6 (>= 2.4), libdbus-1-3 (>= 1.9.14), libpython3.6 (>=
3.6.5), libpython3.7 (>= 3.7.0~b3)

python3 is now at version 3.7.1-2. Something apparently went wrong
during the build. Can you investigate?

Paul

[1]
https://buildd.debian.org/status/fetch.php?pkg=dbus-python=amd64=1.2.8-2%2Bb1=1530370863=0



signature.asc
Description: OpenPGP digital signature

Bug#908834: please build libzstd udeb so that btrfs-progs can use zstd in Debian Installer

[Nicholas D Steeves]

Hi Alex, Cyril, and anyone else reading this,

On Fri, Oct 12, 2018 at 10:09:48AM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Alex Mestiashvili  (2018-10-12):
> > Fixed all the mentioned above issues in the repository.
> 
> That's looking good indeed.
> 
> Please note that by building a udeb you'll be subject to this once in a
> while:
> 
>   https://lists.debian.org/debian-devel-announce/2014/08/msg3.html
> 
> (That hasn't happened in a long while because I've been otherwise busy,
> but I still hope to resume regular d-i releases at some point.)
> 
> > Thank you for the detailed answer!
> 
> No problem, always easier/happier to catch such issues before packages
> reach the archive. ;)

It seems libzstd 1.3.5+dfsg-2 hasn't yet reached the archive.  Maybe
it was not uploaded, or maybe it was rejected for some reason?

  
https://salsa.debian.org/med-team/libzstd/commit/9b865b77d2bfc41c5865f255cf3e4aae18bbe934

Thanks you for working on this!
Nicholas


signature.asc
Description: PGP signature

Bug#888695: nftables: Enabled systemd service blocks boot sequence

[Pablo Pasquín Rosillo]

Just checked and it works fine with DefaultDependencies=no :)

Gracias!
On Wed, Nov 28, 2018 at 10:32 AM Arturo Borrero Gonzalez
 wrote:
>
> Control: tags -1 moreinfo
>
> On Thu, 1 Feb 2018 09:50:31 +0100 Paolo Rosquin  wrote:
> > No idea why it only happens to me. Anyway, I have narrowed down the
> > problem to one line in nftables.service:
> >
> > DefaultDependencies=no
> >
> > Without this everything works fine.
> >
>
> Could you please check if this still happens in more recent versions of
> nftables?
>
> specifically:
> * nft 0.9.0
> * kernel 4.18
>
> Thanks!

Bug#914929: tcl8.7: FTBFS: dh_installdocs: Cannot find (any matches for) "debian/README.TCL_INC" (tried in .)

[Andreas Beckmann]

Source: tcl8.7
Version: 8.7.0~a1+dfsg-4
Severity: serious
Tags: ftbfs

Hi,

tcl8.7 FTBFS after some recent debhelper fixes:

[...]
   dh_install
   dh_installdocs
dh_installdocs: Cannot find (any matches for) "debian/README.TCL_INC" (tried in 
.)

make: *** [debian/rules:28: binary] Error 2


Cheers,

Andreas


tcl8.7_8.7.0~a1+dfsg-4.log.gz
Description: application/gzip

Bug#914927: curl: Please recompile with new libssl-dev headers (1.1.1+).

[Witold Baryluk]

Package: curl
Version: 1.1.1a-1
Severity: important


Hi,

I discovered that during test with curl, that curl in Debian doesn't support 
TLSv1.3.

$ dpkg -l libssl1.1:amd64 | grep ^i
ii  libssl1.1:amd64 1.1.1a-1 amd64Secure Sockets Layer toolkit - 
shared libraries
$ dpkg -l curl | grep ^i
ii  curl   7.61.0-1 amd64command line tool for transferring 
data with URL syntax
$

curl links against libssl.so.1.1 here

$ ldd `which curl` | grep ssl
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x7f4b61807000)
$ ldd `which openssl` | grep ssl
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x7fbe574fc000)
$


$ curl --tlsv1.3 -v https://www.cloudflare.com/
*   Trying 198.41.214.162...
* TCP_NODELAY set
* Connected to www.cloudflare.com (198.41.214.162) port 443 (#0)
* OpenSSL was built without TLS 1.3 support
* Closing connection 0
curl: (4) OpenSSL was built without TLS 1.3 support
$
$ curl --tls-max 1.3 -v https://www.cloudflare.com/
*   Trying 198.41.214.162...
* TCP_NODELAY set
* Connected to www.cloudflare.com (198.41.214.162) port 443 (#0)
* OpenSSL was built without TLS 1.3 support
* Closing connection 0
curl: (4) OpenSSL was built without TLS 1.3 support
$


$ openssl version
OpenSSL 1.1.1a  20 Nov 2018
$



$ openssl s_client -tls1_3 www.cloudflare.com:443
CONNECTED(0003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High 
Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 
Extended Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US, 
jurisdictionST = Delaware, serialNumber = 4710875, C = US, ST = California, L = 
San Francisco, O = "Cloudflare, Inc.", CN = cloudflare.com
verify return:1
---
Certificate chain
 0 s:businessCategory = Private Organization, jurisdictionC = US, 
jurisdictionST = Delaware, serialNumber = 4710875, C = US, ST = California, L = 
San Francisco, O = "Cloudflare, Inc.", CN = cloudflare.com
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 
Extended Validation Server CA
 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 
Extended Validation Server CA
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High 
Assurance EV Root CA
---
Server certificate
-BEGIN CERTIFICATE-
MIIHUzCCBjugAwIBAgIQA33kBvlAKyQzxZW8HLqPiDANBgkqhkiG9w0BAQsFADB1

MFXwvTAcfgVdQpdSALgo/VdC3KWNFNFBBi/0Kx/wxcHJsHmmRT6wiyVT0H1l+7hu
yUcvQcYmUw==
-END CERTIFICATE-
subject=businessCategory = Private Organization, jurisdictionC = US, 
jurisdictionST = Delaware, serialNumber = 4710875, C = US, ST = California, L = 
San Francisco, O = "Cloudflare, Inc.", CN = cloudflare.com

issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 
Extended Validation Server CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3584 bytes and written 322 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID: DD0AA308DEA397DACDA55BA926C2D1EE6FEBFFA52AF9D802B80261EC7C55131D
Session-ID-ctx: 
Resumption PSK: 
B03F1EDD4972188E44C3DEDFB8C610991DE6A309CDB198C7D90A27D67CC263C295ECC4EA16A995F0E334990368B4FC4D
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 172800 (seconds)
TLS session ticket:
 - 30 ee 0c 4d d3 16 de 1f-1e d6 50 eb 69 1e a0 44   0..M..P.i..D

00c0 - 96 d3 2f 27 93 60 e7 02-4b 17 d7 ec eb 35 68 3d   ../'.`..K5h=

Start Time: 1543431295
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 14336
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID: 25F08DC191E37AF3BB5F26CFE246C6C3F8EEDF46701130E22B0A29C4165F7B4D
Session-ID-ctx: 
Resumption PSK: 
CCF4A9294184421DFF28387E22082DA3781290A2CBA562D36153655C8A6E2272F6353FF95B6E04F24309019F591ACFB7
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 172800 (seconds)
TLS session ticket:
 - 30 ee 0c 4d d3 16 de 1f-1e d6 50 eb 69 1e a0 44   0..M..P.i..D

00c0 - ac ab f0 99 28 c5 bd 19-63 e0 18 64 0d c0 e0 e4   (...c..d

Start Time: 1543431295
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 14336
---
read R BLOCK



...
^C
$





The problem with curl / 

Bug#914928: ITP: python-typing-extensions -- Backported and Experimental Type Hints for Python

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: python-typing-extensions
  Version : 3.6.6
  Upstream Author : Guido van Rossum, Jukka Lehtosalo, Lukasz Langa, Michael 
Lee 
* URL : 
https://github.com/python/typing/blob/master/typing_extensions/README.rst
* License : PSF
  Programming Lang: Python
  Description : Backported and Experimental Type Hints for Python

 The typing module was added to the standard library in Python 3.5 on a
 provisional basis and will no longer be provisional in Python 3.7. However,
 this means users of Python 3.5 - 3.6 who are unable to upgrade will not be
 able to take advantage of new types added to the typing module, such as
 typing.Text or typing.Coroutine.
 .
 The typing_extensions module contains both backports of these changes as well
 as experimental types that will eventually be added to the typing module, such
 as Protocol.
 .
 Users of other Python versions should continue to install and use the typing
 module from PyPi instead of using this one unless specifically writing code
 that must be compatible with multiple Python versions or requires experimental
 types.

A dependency of the latest release of python-schema-salad. This package will be
team-maintained by Debian Med

Bug#914788: Please don't enable getty services for tty devices that don't exist

[Dmitry Bogatov]

[2018-11-27 11:14] Andras Korn 

> Ideally, I wouldn't even have to install the getty-run package, but I
> understand it's there to help avoid people shooting themselves in the
> foot by installing runit and then not having any way to log in.

True. I too do not like hard dependency, but Debian users expect things
to work out-of-box.

> However, whenever the getty-run package is installed in a vserver, I have to
> manually remove the /service/getty-tty* symlinks.
>
> Can you please modify the postinst script so it only installs getty services
> for /dev/tty* devices that are actually there?

I do not like maintainer scripts. They are pain to get right.  I can
propose you to pre-provision your servers with
`/etc/sv/getty{1-6}-run/down' file. See runsv(8).

> Or can we come up with a way to help people avoid shooting themselves in the
> foot while not requiring me to install getty-run in vservers? For example,
> runit-init could depend on "getty-run | some-way-to-log-in-interactively",
> and "some-way-to-log-in-interactively" could be provided by an empty
> "runit-no-getty" package as well as an "ssh-run" package that sets up a
> runit service for ssh.

If it would help you, I can add dependency on 'getty-run | access-run'.
You are free to provide `access-run' in whatever way you like.

I am fine with `bin:unsafe-no-tty-run' package too, but not now. I do not
want to get stuck in NEW before freeze.

Bug#768939: startpar: obsolete conffiles /etc/init/startpar-bridge.conf

[Dmitry Bogatov]

[2018-11-27 17:33] Ivan Shmakov 
> I’m not going to claim I’m that familiar with Debian packaging
> practices, but wouldn’t .postinst alone be enough?  .postrm
> isn’t going to do anything if .postinst has already removed the
> file, and there seem to be nothing to warrant a .preinst, either.

Manual page of dpkg-maintscript-helper suggests so:

Many of those tasks require coordinated actions from several maintainer
scripts (preinst, postinst, prerm, postrm). To avoid mistakes the  same
call  simply  needs  to  be  put  in  all  scripts and the program will
automatically adapt its behaviour based  on  the  environment  variable
DPKG_MAINTSCRIPT_NAME  and on the maintainer scripts arguments that you
have to forward after a double hyphen.

Bug#838480: Next revision, suggestion accounted

[Dmitry Bogatov]

[2018-11-16 18:55] Martin Pitt 
> Hello Dmitry,
> 
> Dmitry Bogatov [2016-10-20 13:33 +0300]:
> > runit_2.1.2-9 in testing, and it:
> > 
> >  - Depends on getty-run, which means that user end up without tty
> 
> Not sure what "getty-run" is, but indeed I don't get a TTY. But I don't even
> get that far. This is my current experience:
> 
>  * Standard vmdebootstrap install of sid.
>  * Install runit-init, "do as I say!", reboot (that works)

Hi! Maybe you could export VM image or something like this?

I am worried: freeze is coming, and nothing is happening. I am not going
to miss another release.

Bug#914923: RFP: shellshare -- Live terminal broadcast (client/server)

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist

* Package name: shellshare
  Version : 1.0.3
  Upstream Author : Vitor Baptista 
* URL : https://shellshare.net/
* License : Apache 2.0
  Programming Lang: JS (node), Python
  Description : Live terminal broadcast (client/server)

shellshare provides live webcasting (one way) of the local shell session.
Very useful for live webcasts without demanding full blown screen sharing.

Bug#914922: http-parser: Please move repository to salsa

[Jérémy Lal]

Source: http-parser
Severity: normal

Hi,

i suggest moving it to Debian group.

Jérémy

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

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

Bug#912201: RFS: manticore/2.7.3 [ITP]

[Dmitry Bogatov]

[ Top posting is discouraged ]


[2018-11-27 21:11] Adrian Nuta 
>  * Since this package is not debian-specific, and have its own release
>process, package must be foreign (with -1 revision), not native.
> changed to 1.0, not sure if this is correct

No. Source format 1.0 is long deprecated. You want to use 3.0 (quilt).

And, by the way, where is the source of debianization?

While not strictly mandatory, Vcs-* fields are very useful. I suggest
git, obliviously.

Bug#914695: dgit autopkgtest breaks with git 2.20

[Ian Jackson]

Control: reassign -1 git 1:2.20.0~rc1-1

Jonathan Nieder writes ("Bug#914695: dgit autopkgtest breaks with git 2.20"):
>t-gdr-good laundered
>git reflog | egrep 'debrebase new-upstream.*checkout'

I have investigated and the bug seems to be that git-rebase --onto now
fails to honour GIT_REFLOG_ACTION for the initial checkout.

In a successful run with older git I get a reflog like this:

  4833d74 HEAD@{0}: rebase finished: returning to refs/heads/with-preexisting
  4833d74 HEAD@{1}: debrebase new-upstream 2.1-1: rebase: Add another new 
upstream file
  cabd5ec HEAD@{2}: debrebase new-upstream 2.1-1: rebase: Edit the .c file
  0b362ce HEAD@{3}: debrebase new-upstream 2.1-1: rebase: Add a new upstream 
file
  29653e5 HEAD@{4}: debrebase new-upstream 2.1-1: rebase: checkout 
29653e5a17bee4ac23a68bba3e12bc1f52858ac3
  85e0c46 HEAD@{5}: debrebase: launder for new upstream

With a newer git I get this:

  6d3fb91 HEAD@{0}: rebase finished: returning to refs/heads/master
  6d3fb91 HEAD@{1}: debrebase new-upstream 2.1-1: rebase: Add another new 
upstream file
  86c0721 HEAD@{2}: debrebase new-upstream 2.1-1: rebase: Edit the .c file
  50ba56c HEAD@{3}: debrebase new-upstream 2.1-1: rebase: Add a new upstream 
file
  8272825 HEAD@{4}: rebase: checkout 8272825bb4ff6eba89afa936e32b6460f963a36a
  c78db55 HEAD@{5}: debrebase: launder for new upstream

This breaks the test because my test suite is checking that I set
GIT_REFLOG_ACTION appropriately.

If you want I can provide a minimal test case but this should suffice
to see the bug I hope...

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#914317: dgit: less than helpful error if debian/patches/ exists as untracked files

[Ian Jackson]

Ian Jackson writes ("Re: Bug#914317: dgit: less than helpful error if 
debian/patches/ exists as untracked files"):
> Why does this not complain about the uncommitted files in
> debian/patches ?  Clearly you're not using --clean=git.  Are you using
> --clean=dpkg-source,no-check or something ?  Or is debian/patches in
> your .gitignore ?

I tried this:

  git clone https://salsa.debian.org/haskell-team/git-annex
  git reset --hard c6dda1ee~1
  git-cherry-pick -n c6dda1ee
  git-deborig
  dgit --build-products-dir=.. --include-dirty build-source

That left the situation you describe, with debian/patches and .pc
created.

After that,

  dgit --build-products-dir=.. -wgf quilt-fixup
=> complaint from dgit that the tree is dirty

  git commit -m X
  dgit --build-products-dir=.. -wgf quilt-fixup
=> deletes the .pc and debian/patches, success

But, if I restore that state I can repro your message like this:

  git commit -m X
  dgit --build-products-dir=.. -wddn quilt-fixup
=> error you quote

Is it possible you were using an earlier version of dgit ?  dgits
before 8.0 do not detect and fail on untracked files.

I'm not sure it is worth making a special check for this given that
the user has had to already override something.

Other ways I can repro this include

  git commit -m X
  dgit --build-products-dir=.. -wn quilt-fixup

  # with dgit 7.0
  git commit -m X
  dgit --build-products-dir=.. -wdd quilt-fixup

I can't get any kind of repro, even with dgit 7.0, with --clean=git.
That always seems to delete the loose .pc and debian/patches as I
would expect.

I guess your shell history is not illuminating ?

FYI my script for resetting after each test case and generating the
situation with loose patch files and staged upstream changes, is this:

  git clean -xdff
  git reset --hard c6dda1ee~1
  git-cherry-pick -n c6dda1ee
  git-deborig ||:
  dgit --build-products-dir=.. -v7.20181105-1 --include-dirty build-source

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#914345: [pkg-lxqt-devel] Bug#914345: pcmanfm-qt: the desktop background should be compliant with desktop-base

[Alf Gaida]

You are absolutely right with all your ideas, only a few things to consider:
* the background/theme thing right now has a really low priority
  (aka i will do nothing about in the next two weeks)
* all the needed changes will be in the 0.14.0 packages
* involving debian-desktop is a good idea
* there will be a debian branding/theme package with 0.14.0 - once
  0.14.0 is released and packaged

And that is the reason for the current priorities - i'm writing right
now the changelogs and release notes for 0.14.0, one can expect the
release soon. So the whole "mess" will be fixed hopefully next month.

Cheers Alf



signature.asc
Description: OpenPGP digital signature

Bug#913069: python3-arcus + python3-savitar missing in the transition page, but uninstallable

[Mattia Rizzolo]

On Wed, Nov 28, 2018 at 02:07:40PM +0100, Axel Beckert wrote:
> But that doesn't suffice, there's likely a "| .build-depends ~
> /python3-all-dev/" missing.

As pochu explained, that's not true.

Anyway, I'm confident we will find such weird causes other ways.

> Affected source package is e.g. libarcus whose binary package
> python3-arcus is currently uninstallable, but has no python3-dev in
> the build-dependencies:
> 
>   Build-Depends: debhelper (>= 10.2.1), cmake (>= 2.8.12), dh-python,
>libprotobuf-dev (>= 3.0.0), libprotoc-dev (>= 3.0.0),
>protobuf-compiler (>= 3.0.0), python3-all-dev, python3-sip-dev

That's a bug: https://bugs.debian.org/905803

> The same counts for python3-savitar and src:libsavitar:
> 
>   Build-Depends: debhelper (>= 10.2.1), cmake (>= 2.8.12), dh-python,
>libpugixml-dev (>= 1.7), python3-all-dev, python3-sip-dev (>=
>4.19.12+dfsg-1) | python3-sip-dev (<< 4.19.11+dfsg-1)

And another bug: https://bugs.debian.org/909730



I'm CCing the maintainer, so he can be more aware of the small noises
such "buggy" packages cause.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#914771: bundler: cannot load such file -- bundler-1.16.1/exe/bundle

[李健秋]

Package: bundler
Followup-For: Bug #914771

Hi,

I built the package from git and then installed the package in a chroot.
I tried to build the package again and got following errors:
```
┌──┐
│ Run tests for ruby2.5 from debian/ruby-tests.rake│
└──┘

RUBYLIB=/home/alee/sources/rubygems/ruby-team/ruby-appraisal/debian/ruby-appraisal/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-appraisal/usr/share/rubygems-integration/all:/home/alee/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
 ruby2.5 -S rake -f debian/ruby-tests.rake
/usr/bin/ruby2.5 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
FFF..bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
ERROR:  While executing gem ... (Gem::InstallError)
gem "dummy" is not installed
Fbin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
ERROR:  While executing gem ... (Gem::InstallError)
gem "dummy" is not installed
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
from bin/bundle:104:in `'
bin/bundle:104:in `load': cannot load such file -- 
/usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle