Bug#848791: lshw causes a crash if executed with root permissions

[Yuan-Chen Cheng]

can't see crash in buster with lshw version 02.18.85-0.1.

I think we can close  this bug.


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

Bug#944042: broken with pandas 0.25

[Rebecca N. Palmer]

Control: severity -1 serious

pandas 0.25 is now in unstable.

The explicit Breaks: (causing the current "badpkg" status) end on the 
next upload of these packages, but the underlying issues (see above log) 
also need to be dealt with.

Bug#944707: lintian: check for missing and unsigned .buildinfo files

[Vagrant Cascadian]

On 2019-11-14, Chris Lamb wrote:
>> It would be nice if lintian checked for the presence of a .buildinfo
>> file when processing a .changes file.
>
> I'm obviously sold on the idea of .buildinfo files but what error or
> mistake might such a missing file imply on behalf of the developer?

I'm not sure it's a mistake, per se, but suggests that they're using
very old tooling to build packages, or home-grown tooling, both of which
might have various bugs... but that seems a weak argument to me.

My goal in filing this bug is to gently nudge developers to include
developer built .buildinfo files, and ideally sign them as well, which
increases the number of .buildinfo files we are able to use to verify a
given build.

It is in Debian policy that packages *should* be reproducible, and
.buildinfo files are a cruicial element to be able to demonstrate and
verify that packages are reproducible.

Ideally with a source-only upload, every build would have at least one
.buildinfo from the build daemon and one .buildinfo from the developer
who submitted the source package and at least two potential points of
convergence.

I would think something at the info or pedantic level would be most
appropriate at this point in time, if deemed appropriate at all...

All of which you're probably well aware, but at least this is forcing me
to think it out more verbosely...

Maybe lintian isn't the right place for this (yet), but happy to have
started and to continue the conversation.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#938691: trace-cmd: Python2 removal in sid/bullseye

[Sudip Mukherjee]

Hi All,

On Fri, Aug 30, 2019 at 07:56:16AM +, Matthias Klose wrote:
> Package: src:trace-cmd
> Version: 2.6.1-0.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

trace-cmd/2.8.3-1 is not using python anymore and so I have marked this
as fixed, but it seems the updated version is not listed for:
alpha, m68k, powerpcspe, sh4 and so I am not too sure if I should close
this bug as fixed or leave it open.

--
Regards
Sudip

Bug#915648: ldd can not find libQt5Core.so.5 (Was: phantomjs: failed to detect theversion of the executable)

[Andreas Tille]

Hi,

I'm running buster with

apt-cache policy phantomjs
phantomjs:
  Installiert:   2.1.1+dfsg-2
  Installationskandidat: 2.1.1+dfsg-2
  Versionstabelle:
 *** 2.1.1+dfsg-2 500
500 http://httpredir.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status

and get

$ phantomjs --version
/usr/lib/phantomjs/phantomjs: error while loading shared libraries: 
libQt5Core.so.5: cannot open shared object file: No such file or directory

$ ldd /usr/lib/phantomjs/phantomjs | grep "not found"
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found
libQt5Core.so.5 => not found

This is quite suspicious since 


apt-cache policy libqt5core5a
libqt5core5a:
  Installiert:   5.11.3+dfsg1-1+deb10u1
  Installationskandidat: 5.11.3+dfsg1-1+deb10u1
  Versionstabelle:
 *** 5.11.3+dfsg1-1+deb10u1 500
500 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
 5.11.3+dfsg1-1 500
500 http://httpredir.debian.org/debian buster/main amd64 Packages


I've tried a local build for phantomjs with no better result.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#944707: lintian: check for missing and unsigned .buildinfo files

[Chris Lamb]

tags 944707 + moreinfo
thanks

Hi Vagrant,

> It would be nice if lintian checked for the presence of a .buildinfo
> file when processing a .changes file.

I'm obviously sold on the idea of .buildinfo files but what error or
mistake might such a missing file imply on behalf of the developer?


Regards,

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

Bug#838994: Bug#891493: unresolved gtk2-engines-murrine situation (was: numix-gtk-theme: Undocumented and very likely also broken Breaks against murrine-themes since 2.6.7-2)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2019-11-13 at 20:58 +, Mike Gabriel wrote:
> One last question: For the themes you maintain, is it ok if I provide  
> the "Provides: any-murrine-theme" patches (as MRs or pushed commits)  
> and possibly even NMU them for those murrine-like themes that need them?
> 
> Like in numix-gtk-theme [1].
> 
> Alternative option is me filing wishlist bugs against all related packages.

Go ahead with NMU, and yes I guess you can directly commit/push to the
repository. At that point I think I should just remove myself from
maintainers/uploaders of the theme packages, I'm unlikely to have time for
them in the near future.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3M/F0ACgkQ3rYcyPpX
RFvtLggAtPb/BMDo5FtGG1Z51pEqRbrfijD0ad16ymSR5PUoxReL5aVL5Ygt3zFX
b1Pgn3fH9FFAsE6guzo59WfK51+erWSGI52t3AEWOCdenAU4GKfBUSs6HyU9WmAk
Bii5Hre2Cu/hsyOWcm28pXhtvK3SwLqA7GKxK2r1xIOV1rhIFcziLFF7KohcO66i
/EV/xkK+pVv1JYY/hMx+wvGIaKVIhurHyusj0AaUx5b5QgQ6aWYcWw7PsBRcv+Fr
FHjyxLLM6WePaFBjdBCoKy3bXpVJG54r8Shtj3L4d+zK42r8GcUf2qt8pGH9dYk0
6KbO+P+VHKoALQLyNRlxdvglnmsZBg==
=ZlSB
-END PGP SIGNATURE-

Bug#944708: feh-cam missing

[Moshe Piekarski]

Package: feh
Version: 3.2.1-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

feh includes a manpage for feh-cam which is not included in the package.

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

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

Versions of packages feh depends on:
ii  libc6 2.29-2
ii  libcurl4  7.66.0-1+b1
ii  libexif12 0.6.21-5.1
ii  libimlib2 1.5.1-1
ii  libpng16-16   1.6.37-1
ii  libx11-6  2:1.6.8-1
ii  libxinerama1  2:1.1.4-2
ii  yudit-common  2.9.6-8

Versions of packages feh recommends:
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1

feh suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQJNBAEBCAA3FiEEXbk7X2RxJi0NGP5lMn/Nf3K/IoEFAl3M/EwZHGRlYmlhbi5i
dWdzQG1lbGFjaGltLm5ldAAKCRAyf81/cr8igU1TD/sF3AjDWIYzO+Fu2NsxxiPH
qGM6xaUX22Swars8HWKS5DKK27+EiAnKv7RojXXl6jwPBKtADLkqC2b/t29GsAtS
c3OquShhbaoQPO5yQfaRZD32Db0rxYirEY4NcXkJq72N1qY3ObnX10BCUa5BGFDu
89EP8bt3j6vZHlck9uM/43EnEyPI/76B6RLCSW0bRmX1Ur4kD85LWJWOincpNVAm
k6nbanVJp5N3Jw2ZUt67HBUggudJsuqfgR7orkckSxdN+f/3u//4ZTJYHAlXZud8
12J4bg/PDj8JKen8Z5dsy7256IVtxGuSnXEqNPuDssqtQe10rNMO3FkXgcJ6Nw2R
Y3Xj4C2SrJ3voF3zHqU5fTGX9eTAakIC0c2PfmJEn6b+7po7Vco4CIHm4Pc1lo+8
uWGfT/dJ7ysF+Q35IrXfUB0P/uVm/lIU1hqJ4b07cVFYGIvLYG5kSycvW8bH9l08
RQJnJIcb5tcbkH/4NOStIy4Xe852Bkz0wwc7zQkA9QPv+wuIQAS79z/N4BKF6AK1
M9bOcHTtqAp7Q8w0JyKO+zgLL45bluflTvouOFu6469iZrO3lGP0f5RcsTuBOPyT
zxtnuywM1tQCA/x7ceJD68ro4w+3NhifJ0IZ850gwrk7GKQ4JO4FIkFUO40i3kA8
TPvysdIh9rKhNoNkTbzenA==
=4bly
-END PGP SIGNATURE-

Bug#944707: lintian: check for missing and unsigned .buildinfo files

[Vagrant Cascadian]

Package: lintian
Version: 2.33.0
Severity: wishlist

It would be nice if lintian checked for the presence of a .buildinfo
file when processing a .changes file.

For a stretch goal, it would be nice if it also checked if the
.buildinfo file was signed. :)

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#944706: firefox-esr: Tab crashes immediately after start up and Firefox ESR was unusable.

[ISHIKAWA,chiaki]

Package: firefox-esr
Version: 68.2.0esr-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I don't know where to report, but I want to share an experience and
possible workaround.

I hav filed a mozilla bugzilla entry:
https://bugzilla.mozilla.org/show_bug.cgi?id=1596338
Bug 1596338
firefox-esr 68.2.0.ESR startup error under Debian GNU/Linux

My debian kernel version is:
$ uname -a
Linux ip030 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64 
GNU/Linux


I am using a testing package of Debian. So, that may be one of the
reasons of ill-behavior.

SYMPTOM of the problem:

(1) I upgraded my Debian GNU/Linux packages, and firefox seemed to
updated itself some days ago or yesterday, I am not sure when.

When I tried to run Firefox for the first time after these events by
invoking it from the application menu maybe for the first time in a
few days, Firefox was not usable because any tab including the startup
tab(s) that I wanted to create crashed, and firefox displayed the
error message and offered to close the tab or restore the tab.

Since the tab(s) crashed immediately after startup, if I closed the
tab, Firefox terminated.
If I tried to restore the tabs, this again resulted in the same tab
crashing dialog screen page.  There was no way out.

(2) Another bug I noticed is incorrect link in the help dialog.

I get Page not found error when I clicked on the "What's New" link:

HELP -> About Firefox -> What's New link

I get Page not Found error.

The page shown with BIG "Whoops1" message has URL:
https://www.mozilla.org/en-US/und/firefox/68.2.0/releasenotes/?utm_campaign=whatsnew_medium=firefox-browser_source=firefox-browser

If I delete the "/und" part manually and hit return in the URL bar,
I think the correct page s being accessed.
(I am not sure if the incorrect URL is Debian-specific or originated
in the mozilla binary.)

In then accessed page I see clearly the following message. So it *IS*
the release note.

--- begin quote

Firefox ESR
Release Notes

Release Notes tell you what’s new in Firefox. As always, we welcome
your feedback. You can also file a bug in Bugzilla or see the system
requirements of this release.

    Desktop
    Android
    iOS
    Pre-releases

68.2.0
Firefox ESR

October 22, 2019
Version 68.2.0, first offered to ESR channel users on October 22, 2019

--- end quote



ERROR messages:
While the error in (1) was observed, I saw something like the
following (quoted/pasted at the end of this memo.)
in the startup console where I typed /usr/bin/firefox-esr

Possible Workaround ??? :

I found a solution by accident. I have no idea if this works for everybody.

I tried to restart Firefox after disabling plugin, i.e., safe-mode
from the menu.
This operation failed again and no window was created.
Usually Firefox restart after disabling plugins. But I saw no such
window and there does not seem to be any live firefox process anymore.

ps axg | grep firefox

does not show firefox process.

So, after this, I ran firefox-esr again by typing the command line
this time.  To my relief, this time no tab crashed error screen
appeared, and I can access google search, for example eventually.
Something, maybe some profile or whatever, was changed for the better
(?) is my best guess.

Just thought to share my experience.

---
Note; Some error messages that appeared on the command tty window where I
typed
firefox-esr to start Firefox.

Error messages uring the error (1) above:

$ firefox-esr
IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 

Bug#944705: alembic: failing tests with python3.8

[Steve Langasek]

Package: python3-mako
Version: 1.0.7+ds-1
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Dear maintainers,

The alembic package fails to build from source in Ubuntu focal, because
Ubuntu has begun the transition to python3.8 and mako is not
source-compatible with python3.8:

[...]
=== FAILURES ===
___ TemplateArgsTest.test_bad_render ___
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8_alembic/build/alembic/util/pyfiles.py", 
line 18, in template_to_file
output = template.render_unicode(**kw).encode(output_encoding)
  File "/usr/lib/python3/dist-packages/mako/template.py", line 467, in 
render_unicode
return runtime._render(self,
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 837, in _render
_render_context(template, callable_, context, *args,
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 873, in 
_render_context
_exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 899, in 
_exec_template
callable_(context, *args, **kwargs)
  File "scratch_scripts_script_py_mako", line 23, in render_body
TypeError: unsupported operand type(s) for +: 'Undefined' and 'Undefined'
[...]

  (https://launchpad.net/ubuntu/+source/alembic/1.0.11-5ubuntu1/+build/17988507)

Debian has not yet started the transition to python3.8 - the version of
python3-defaults that adds python3.8 as supported is currently in
experimental - but this will eventually become a serious bug in Debian as
well once that transition begins.

For the moment I have worked around the failure in Ubuntu by changing the
packaging to test only against the current version of python3 and not
against all supported versions, but this is a very short-term fix given that
python3.8 will become the default in the next 6 months.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru alembic-1.1.0/debian/control alembic-1.1.0/debian/control
--- alembic-1.1.0/debian/control2019-10-31 06:41:59.0 -0700
+++ alembic-1.1.0/debian/control2019-11-13 21:33:35.0 -0800
@@ -8,7 +8,7 @@
 Build-Depends:
  debhelper-compat (= 12),
  dh-python (>= 3.20180927~),
- python3-all,
+ python3,
  python3-changelog,
  python3-setuptools,
  python3-sphinx,

Bug#944704: ITP: org-html-themes -- export Emacs Org mode files into awesome HTML in 2 minutes or less

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

* Package name: org-html-themes
  Version : 1.0.0
  Upstream Author : 
* URL : https://github.com/fniessen/org-html-themes
* License : GPL-3+
  Programming Lang: Org_style_markdown, HTML, CSS, js vs Debian's libjs-foos
  Description : export Emacs Org mode files into awesome HTML in 2 minutes

 Org-HMTL themes is an open source framework that enables the
 exportation of Org documents to beautiful cross-browser HTML. Use
 this to style your docs, and your colleagues will come up to tell you
 that you are a genius!  Whether it's for a web page, something like
 an IOT frame that displays TODO lists and project progress, or
 something else this package elevates Org export and publication to
 something truly impressive.
 .
 At this time the following themes are included:
   * Bigblow, a modern and minimal theme with pastel colours and a clean design.
   * ReadTheOrg, a clone of the well known and loved Read The Docs theme.

This package lowers the barrier to entry to professional-looking
Org-mode export/publish results.  In the future I'd like to see it
extended via conveniences like yasnippet and/or some sort of template
selection menu.  I discovered this package when working on generating
Ivy/Counsel/Swiper's HTML docs (now with no invariants section!)  The
most similar type of package would probably be the various Sphinx
themes.

I plan to maintain it on the Debian Emacsen Team, and I look forward
to navigating between the requirements of users who are using it for
offline docs and those who will use it to publish to a web server.  I
will require a sponsor for the initial upload.

If someone would like to work on porting Sphinx themes to this
framework, please speak up :-)  A publication kit that provides unified
look & feel between Sphinx and Org could be a fun project.

I anticipate it will become popular with fans of Org-mode.


Sincerely,
Nicholas

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

Don't forget to provide GSequencer configuration in $HOME/.gsequencer/ags.conf

regards,
Joël

On Wed, Nov 13, 2019 at 1:25 PM Joël Krähemann  wrote:
>
> Hi,
>
> I just installed realtime kernel and gsequencer from debian repository.
>
> I am not able to reproduce.
>
> please provide more information and your kernel configuration.
>
> cheers,
> Joël
>
> On Wed, Nov 13, 2019 at 11:50 AM Joël Krähemann  wrote:
> >
> > Hi,
> >
> > thank you for reporting the bug.
> >
> > Do you use a custom realtime kernel configuration?
> >
> > best regards,
> > Joël
> >
> > On Tue, Nov 12, 2019 at 10:18 AM westlake  wrote:
> > >
> > > Package: gsequencer
> > > Version: 2.1.53-2
> > > Severity: important
> > >
> > > stalls a system that is running on an RT kernel
> > >

Bug#944703: nvidia-graphics-drivers: Vcs-* fields points to non existent location for nvidia-graphics-driver source package

[Vasudev Kamath]

Source: nvidia-graphics-drivers
Severity: normal

Dear Maintainer,

Vcs-* fields for nvidia-graphics-drivers points to 
https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers
but going to this link leads to 404 error. I'm unable to checkout the source 
using debcheckout
Can some one point me to the right location till this is fixed?

Cheers,
Vasudev

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

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

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Status update: I've deferred the question of Webkit vs Web Engine and
am working on Martchus' prerequisite libraries, starting with
"c++utilities" aka "cpputilities".  I will need to consult with
someone more how to package this for Debian such that it doesn't make
such a huge namespace grab, or at least get an ACK that this would be
ok.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#944702: ftp.debian.org: ltsp arch:all binary missing from archive

[Vagrant Cascadian]

Package: ftp.debian.org
Severity: normal

The recent LTSP upload seems to be missing the arch:all "ltsp" binary
from sid's Packages files...

 < vagrantc> so, the packaging for "ltsp" was radically changed; it only
   ships one arch:all package also named "ltsp" now rather than several
   arch:all and arch:any ltsp-* packages... it went through NEW, landed
   in experimental, and then i uploaded to unstable ... the buildd built
   it, installed it ... but the "ltsp" package is not present in the
   Packages file for sid.

 < vagrantc> it's been in unstable for two days now ... so it isn't just
   that i haven't waited long enough...

 < kibi> I think get rid of old binaries.

 < vagrantc> i expected it to block migration, but i guess i was
   surprised that the binaries aren't present in Packages at all

 < kibi> a while ago and if I remember correctly, all packages only
   showed up in $arch's Packages when the $arch build came up

 < vagrantc> they're even visible at
   https://deb.debian.org/debian/pool/main/l/ltsp/

 < kibi> there are no such things here, so this might explain why it's
  here (see rmadison) but not there.

 < kibi> transitioning (existing) packages from/to arch:all has always
   been “fun” anyway; not sure whether you could be hitting another
   issue though


Thanks for your help!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#944701: doit: fails autopkgtest due to stderr

[Michael Hudson-Doyle]

Source: doit
Version: 0.31.1-3
Severity: important
Tags: patch

Dear Maintainer,

After the pytest fix in 0.31.1-3, unfortunately the autopkgtest still
fails due to output on stderr:

https://ci.debian.net/data/autopkgtest/testing/amd64/d/doit/3403646/log.gz

Easy to fix though, I'm attaching what I just uploaded to Ubuntu.

Cheers,
mwh

-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan'), (400, 'eoan-proposed'), 
(100, 'eoan-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru doit-0.31.1/debian/changelog doit-0.31.1/debian/changelog
--- doit-0.31.1/debian/changelog2019-10-26 21:26:14.0 +1300
+++ doit-0.31.1/debian/changelog2019-11-14 15:29:40.0 +1300
@@ -1,3 +1,10 @@
+doit (0.31.1-3ubuntu1) focal; urgency=medium
+
+  * d/tests/unittests: Pass --no-warn-script-location to pip to suppress
+warning on stderr. 
+
+ -- Michael Hudson-Doyle   Thu, 14 Nov 2019 
15:29:40 +1300
+
 doit (0.31.1-3) unstable; urgency=medium
 
   [ Salsa Pipeline ]
diff -Nru doit-0.31.1/debian/control doit-0.31.1/debian/control
--- doit-0.31.1/debian/control  2019-10-26 21:26:14.0 +1300
+++ doit-0.31.1/debian/control  2019-11-14 15:29:40.0 +1300
@@ -1,7 +1,8 @@
 Source: doit
 Section: python
 Priority: optional
-Maintainer: Agustin Henze 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Agustin Henze 
 Uploaders:
  Ulises Vitulli ,
  Iñaki Malerba ,
diff -Nru doit-0.31.1/debian/tests/unittests doit-0.31.1/debian/tests/unittests
--- doit-0.31.1/debian/tests/unittests  2019-10-26 21:26:14.0 +1300
+++ doit-0.31.1/debian/tests/unittests  2019-11-14 15:29:40.0 +1300
@@ -1,2 +1,2 @@
-pip3 install -r dev_requirements.txt
+pip3 install --no-warn-script-location -r dev_requirements.txt
 doit ut

Bug#651528:

[Siti Rofia]

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Pirate Praveen]

Control: retitle -1 gitlab ssh access broken with protobuf 3.10
Control: severity -1 serious

On ബു, Nov 13, 2019 at 23:44, Pirate Praveen 
 wrote:

On Mon, 11 Nov 2019 22:15:20 +0530 Pirate Praveen
mailto:prav...@onenetbeyond.org>> wrote:

 Control: retitle -1 ssh access fails with gitaly-upload-pack: fatal:
 error: %v
 On Sat, 2 Nov 2019 14:51:42 +0100 Romain Bignon > wrote:

 > Hello,
 >
 > The problem is still here, and is so not related to compatibility 
between

 > versions of gitlab/gitlab-shell/gitality…
 >
 > Is there anything I can do to find the origin of this issue?

 Fortunately or unfortunately the same error hit my instance as 
well. I'm

 digging deeper into it now.

 As a workaround you can use https access till we fix this (only ssh
 access is affected).


Found the root cause to be ruby-google-protobuf update from 3.7 to 
3.10.

But to actually get it work is tricky.

If we downgrade ruby-google-protobuf to 3.7.1, then gitaly fails to 
build.


 has protobuf 3.7 and grpc 
1.19. You need to downgrade both and use gitaly 1.59.3+dfsg-1~bpo10+2 
(which allows these versions).


And because of 
 you may need 
to regenrate Gemfile.lock


# cd /usr/share/gitlab
# sudo -u gitlab truncate -s0 Gemfile.lock
# sudo -u gitlab bundle install --local
# systemctl restart gitlab-sidekiq
# systemctl restart gitlab gitaly

I had to use a separate repo with protobuf 3.10 and grpc 1.23 -> 
https://people.debian.org/~praveen/protobuf/ to build gitaly


I'm keeping this bug open till we can use same version of protobuf for 
both gitaly build and gitlab. I have opened 
https://gitlab.com/gitlab-org/gitaly/issues/2164 to work with upstream 
on this

Bug#944700: python-multipletau: tries to test removed python2 packages in autopkgtest

[Michael Hudson-Doyle]

Source: python-multipletau
Version: 0.3.3+ds-2
Severity: normal
Tags: patch

Dear Maintainer,

As subject. Patch attached, but really, making the needed change will
take about as long as opening the patch.

Cheers,
mwh

-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan'), (400, 'eoan-proposed'), 
(100, 'eoan-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-multipletau-0.3.3+ds/debian/changelog 
python-multipletau-0.3.3+ds/debian/changelog
--- python-multipletau-0.3.3+ds/debian/changelog2019-09-05 
02:41:07.0 +1200
+++ python-multipletau-0.3.3+ds/debian/changelog2019-11-14 
15:13:30.0 +1300
@@ -1,3 +1,9 @@
+python-multipletau (0.3.3+ds-2ubuntu1) focal; urgency=medium
+
+  * Do not test dropped Python2 libraries in autopkgtest. 
+
+ -- Michael Hudson-Doyle   Thu, 14 Nov 2019 
15:13:30 +1300
+
 python-multipletau (0.3.3+ds-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-multipletau-0.3.3+ds/debian/control 
python-multipletau-0.3.3+ds/debian/control
--- python-multipletau-0.3.3+ds/debian/control  2019-09-05 02:41:07.0 
+1200
+++ python-multipletau-0.3.3+ds/debian/control  2019-11-14 15:13:30.0 
+1300
@@ -1,5 +1,6 @@
 Source: python-multipletau
-Maintainer: Debian Med Packaging Team 

+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Med Packaging Team 

 Uploaders: Alexandre Mestiashvili 
 Section: python
 Priority: optional
diff -Nru python-multipletau-0.3.3+ds/debian/tests/control 
python-multipletau-0.3.3+ds/debian/tests/control
--- python-multipletau-0.3.3+ds/debian/tests/control2019-09-05 
02:41:07.0 +1200
+++ python-multipletau-0.3.3+ds/debian/tests/control2019-11-14 
15:13:25.0 +1300
@@ -1,6 +1,4 @@
-Test-Command: for p in $(pyversions -s) $(py3versions -s); do $p -m pytest 
tests/; done
+Test-Command: for p in $(py3versions -s); do $p -m pytest tests/; done
 Depends:
- python-pytest,
- python-multipletau,
  python3-pytest,
  python3-multipletau,

Bug#944699: bsdutils: logger uses username as process

[Meeuwissen Olaf]

Package: bsdutils
Version: 1:2.33.2-0.1
Severity: normal

I was debugging a dhclient-script hook when I noticed this in the
journal

  Nov 14 09:31:23 debian olaf[3598]: 
/etc/dhcp/dhclient-exit-hooks.d/local-static-route returned non-zero exit 
status 1

THe issue is not with the non-zero exit status, that's my fault and has
been fixed, but the process name had me scratch my head.  I would have
expected `dhclient-script` (which sources the hook) or `dhclient` which
run the `dhclient-script`, *not* my username.

BTW, my username was used because I'd been running ifup/ifdown via sudo
for testing purposes.  When I restarted networking.service, the username
changed to `root`.

Also, simply running `logger` from the command-line will reproduce this.

  $ logger 'Hello World!'
  $ journalctl -n 1 2>/dev/null
  -- Logs begin at Wed 2019-11-06 16:20:35 JST, end at Thy 2019-11-14 09:37:18 
JST. --
  Nov 14 09:37:18 debian olaf[2001]: Hello World!

In this case I would have expected the process to be `bash`, the shell
from which I ran the `logger` command, not my username.

I don't know if using the username instead of the parent process name is
intended behaviour or not but if it is a note in the manual page would
be nice.  If it is not intended behaviour, it ought to be fixed.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Join the Free Software Foundationhttps://my.fsf.org/join

Bug#943611: cegui-mk2 fails to package extensions for python 3.8

[Olek Wojnar]

Hi Matthias,


Thanks for filing this bug report, I'll try to fix it as soon as I can.


On 10/27/19 6:33 AM, Matthias Klose wrote:
> Package: src:cegui-mk2
> Version: 0.8.7-3
> Severity: important
> Tags: sid bullseye patch
> User: debian-pyt...@lists.debian.org
> Usertags: python3.8


I noticed the "patch" tag but I don't see a patch in the BTS. Did you
intend to upload a patch?


-Olek




signature.asc
Description: OpenPGP digital signature

Bug#944698: regenerate Gemfile.lock when native gems with gem-install layout is updated

[Pirate Praveen]

Package: gitlab
Version: 12.2.9-2
severity: important

Currently only pure ruby gems are handled in debian/gitlab.triggers

Bug#944633: Acknowledgement (Moreutils parallel does not always flush output on single CPU machine)

[Mark Blakeney]

Note if I run the example command under gdb then it always works so that
implies a timing/race condition.

Bug#927727: [Panorama] photos display only grey for pixels to the right of ~16000 pixels

[scott092707]

As of eog version  3.34.1-1 , bug is still present.

Bug#944696: python-apt: relies on MD5 internally to download packages

[Cyril Brulebois]

Cyril Brulebois  (2019-11-14):
> Looking at the current (as of 2019-11-14 00:27:00 UTC) indices for
> buster/updates on security.debian.org, one can only see SHA256 entries
> in Release and Packages files, which is likely the reason for
> python-apt's explosion. I've asked #debian-ftp to add MD5Sum entries
> back at least for buster/updates, and will file another bug report for
> that in a moment to make sure it isn't lost.

For completeness, this is tracked in #944697.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#944697: security.debian.org: please bring back MD5Sum, at least for buster/updates

[Cyril Brulebois]

Package: ftp.debian.org
Severity: serious
Justification: breaks image generation tools

Hi,

I've mentioned this on #debian-ftp already, but filing a bug report in
addition to make sure it's not lost.

Assuming the FTP team is responsible for security's dak setup as well,
we'd like to get MD5Sum back in buster/updates.

python-apt relies on md5 fields internally, as documented in #944696,
and a current symptom is live-wrapper's tracebacking accordingly when
packages are available in security; this has been the case for the
intel-microcode package, for a few hours.

jessie/updates and stretch/updates seem fine (MD5Sum is present there).
I don't have an opinion regarding bulleyes/updates (MD5Sum is missing
there) at this point, but given at least some apt bindings don't support
missing MD5Sum, it would seem premature to remove it from there as well?


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages

[Cyril Brulebois]

Daniel Kahn Gillmor  (2019-10-22):
> The Packages file is growing, and we would like to keep it smaller.
> 
> The MD5sum lines are vestigial at this point.  Anything that they do
> can be done better with the data from the SHA256sum lines.
> 
> Removal of the MD5sum lines would reduce the size of the gzip'ed
> Packages file by ~13%, a significant win for a frequently-downloaded
> file:
> 
> $ grep -v ^MD5sum < 
> /var/lib/apt/lists/ftp.debian.org_debian_dists_sid_main_binary-amd64_Packages 
> | gzip -9 | wc -c
> 9541056
> 0 dkg@alice:~$ cat < 
> /var/lib/apt/lists/ftp.debian.org_debian_dists_sid_main_binary-amd64_Packages 
> | gzip -9 | wc -c
> 10913735
> 0 dkg@alice:~$ echo $(( 100 - 100 * 9541056 / 10913735 ))
> 13
> 0 dkg@alice:~$ 
> 
> This removal was attempted once before, as documented in #818463, and
> all of the subsequent blocking bugs appear to have been fixed in the
> archive for several years.

I don't think python-apt is quite ready yet: #944696.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#944696: python-apt: relies on MD5 internally to download packages

[Cyril Brulebois]

Package: python-apt
Version: 1.8.4
Severity: serious
Justification: some people want to get rid of MD5Sum in indices

Hi,

While debugging a live-wrapper (lwr) failure that started occurring
(literally) overnight, I ended up discovering it was triggered by the
intel-microcode package's getting a security upgrade.

live-wrapper 0.10 isn't affected, but live-wrapper's master branch has
an extra commit that automatically enables security sources for stable
releases.

Here's the traceback for a simple build (with a local mirror but anyone
would do) with that master branch:

$ sudo lwr -d buster -m http://wodi.home/debian -f intel-microcode
[…]
DEBUG environment: LWR_MIRROR = 'http://wodi.home/debian'
DEBUG environment: LWR_EXTRA_PACKAGES = ''
DEBUG environment: LWR_BASE_DEBS = ''
DEBUG environment: LWR_DISTRIBUTION = 'buster'
DEBUG environment: LWR_FIRMWARE_PACKAGES = 'intel-microcode'
DEBUG environment: LWR_TASK_PACKAGES = ''
[…]
Downloading udebs for Debian Installer...
INFO Downloading udebs for Debian Installer...
Updating a local cache for amd64 buster ...
DEBUG Updating local cache...
CRITICAL Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 193, in _run
self.process_args(args)
  File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 143, in 
process_args
self.start_ops()
  File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 286, in start_ops
apt_udeb.download_udebs(exclude_list)
  File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 157, in 
download_udebs
self.download_apt_file(pkg_name, pool_dir, False)
  File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 141, in 
download_apt_file
version.fetch_binary(destdir=pkg_dir)
  File "/usr/lib/python2.7/dist-packages/apt/package.py", line 867, in 
fetch_binary
if _file_is_same(destfile, self.size, self._records.md5_hash):
SystemError: error return without exception set


After some debugging, it turned out that merely accessing the
self._records.md5_hash item is sufficient to reproduce this issue.

Looking at the current (as of 2019-11-14 00:27:00 UTC) indices for
buster/updates on security.debian.org, one can only see SHA256 entries
in Release and Packages files, which is likely the reason for
python-apt's explosion. I've asked #debian-ftp to add MD5Sum entries
back at least for buster/updates, and will file another bug report for
that in a moment to make sure it isn't lost.

Looking at even the most recent python-apt code in experimental (1.9.0),
MD5 still seems hardwired, e.g. in apt/packages.py's fetch_binary():


def fetch_binary(self, destdir='', progress=None):
# type: (str, AcquireProgress) -> str
"""Fetch the binary version of the package.

The parameter *destdir* specifies the directory where the package will
be fetched to.

The parameter *progress* may refer to an apt_pkg.AcquireProgress()
object. If not specified or None, apt.progress.text.AcquireProgress()
is used.

.. versionadded:: 0.7.10
"""
base = os.path.basename(self._records.filename)
destfile = os.path.join(destdir, base)
if _file_is_same(destfile, self.size, self._records.md5_hash):
logging.debug('Ignoring already existing file: %s' % destfile)
return os.path.abspath(destfile)
acq = apt_pkg.Acquire(progress or apt.progress.text.AcquireProgress())
acqfile = apt_pkg.AcquireFile(acq, self.uri, self._records.md5_hash,  # 
type: ignore # TODO: Do not use MD5 # nopep8
  self.size, base, destfile=destfile)
acq.run()

if acqfile.status != acqfile.STAT_DONE:
raise FetchError("The item %r could not be fetched: %s" %
 (acqfile.destfile, acqfile.error_text))

return os.path.abspath(destfile)


Notice the TODO on the apt_pkg.AcquireFile(), but it would probably
break in the same way as in the live-wrapper case a few lines before, on
the self._records.md5_hash item.

The same goes for fetch_source().


Since getting rid of MD5Sum entirely is a topic that comes up on a
regular fashion (with fingers being pointed at jigdo in particular), it
looks to me python-apt should get some attention as well; hence filing
at serious severity. Feel free to adjust as required.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#944695: sddm: Multi-monitor settings lost on reboot

[Jesse Rhodes]

Package: sddm
Version: 0.18.0-1
Severity: normal

Dear Maintainer,

My system has 2 screens - a primary display connected to HDMI-0 and a
smaller secondary display to
the right, on DVI-D-1. On boot, the displays are swapped so that the
smaller display is configured
on the left. In the Displays section of KDE system settings, I switch
them around to match their
real-world orientation, but if I reboot, they are swapped again, with
the mouse leaving the right side of
the right-hand screen and appearing on the left side of the left-hand
screen at the sddm login interface,
before logging into the kde session.

It is the same as this thread I found on the KDE forum:
https://forum.kde.org/viewtopic.php?f=309=153057
Workarounds specified seem to be targeting sddm, and read as
countering a race condition with xrandr, maybe?
But there's really no reason the settings shouldn't stay the same
across reboots.

sney

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.73
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-19
ii  libpam0g1.3.1-5
ii  libqt5core5a5.12.5+dfsg-2
ii  libqt5dbus5 5.12.5+dfsg-2
ii  libqt5gui5  5.12.5+dfsg-2
ii  libqt5network5  5.12.5+dfsg-2
ii  libqt5qml5  5.12.5-3
ii  libqt5quick55.12.5-3
ii  libstdc++6  9.2.1-19
ii  libsystemd0 243-5
ii  libxcb-xkb1 1.13.1-2
ii  libxcb1 1.13.1-2
ii  qml-module-qtquick2 5.12.5-3
ii  x11-common  1:7.7+20
ii  xserver-xorg [xserver]  1:7.7+20

Versions of packages sddm recommends:
ii  haveged 1.9.8-2
ii  libpam-systemd  243-5
ii  sddm-theme-breeze [sddm-theme]  4:5.14.5.1-4

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

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#944694: resource-agents: Fix typo in heartbeat/MailTo

[Vagrant Cascadian]

Source: resource-agents
Version: 1:4.4.0-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Attached is a patch to fix a typo in heartbeat/MailTo that behaves
differently when /bin/sh is bash vs. dash by using curly-braces instead
of square brackets to define the variable.

Without this either "0" or "$[OCF_RESKEY_email_default]" is embedded
in the ocf_heartbeat_MailTo.7 manpage depending on the shell, neither
of which are probably the intended value.

This impacts the reproducibility of the build:

  https://reproducible-builds.org/docs/

There is also a merge request submitted if that's easier for you:

  https://salsa.debian.org/ha-team/resource-agents/merge_requests/1


live well,
  vagrant

From 2b003a7b5f0a0194adaeee04604dafa05a0132fc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 13 Nov 2019 15:49:29 -0800
Subject: [PATCH] Fix typo in heartbeat/MailTo that behaves differently when
 /bin/sh is bash vs. dash by using curly-braces instead of square brackets to
 define the variable.

Without this either "0" or "$[OCF_RESKEY_email_default]" is embedded
in the ocf_heartbeat_MailTo.7 manpage depending on the shell, neither
of which are probably the intended value.

This impacts the reproducibility of the build:

  https://reproducible-builds.org/docs/
---
 debian/patches/series |  1 +
 debian/patches/typo-in-mailto | 26 ++
 2 files changed, 27 insertions(+)
 create mode 100644 debian/patches/typo-in-mailto

diff --git a/debian/patches/series b/debian/patches/series
index f58907b..fc8054b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,3 +7,4 @@ gitignore.patch
 reproducible.patch
 var-run.patch
 mysql-exit-code.patch
+typo-in-mailto
diff --git a/debian/patches/typo-in-mailto b/debian/patches/typo-in-mailto
new file mode 100644
index 000..44c07e5
--- /dev/null
+++ b/debian/patches/typo-in-mailto
@@ -0,0 +1,26 @@
+From: Vagrant Cascadian 
+
+Fix typo that behaves differently when /bin/sh is bash vs. dash by
+using curly-braces instead of square brackets to define the variable.
+
+Without this either "0" or "$[OCF_RESKEY_email_default]" is embedded
+in the ocf_heartbeat_MailTo.7 manpage depending on the shell, neither
+of which are probably the intended value.
+
+This impacts the reproducibility of the build:
+
+  https://reproducible-builds.org/docs/
+
+Index: resource-agents/heartbeat/MailTo
+===
+--- resource-agents.orig/heartbeat/MailTo
 resource-agents/heartbeat/MailTo
+@@ -67,7 +67,7 @@ a takeover occurs.
+ The email address of sysadmin.
+ 
+ Email address
+-
++
+ 
+ 
+ 
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#944687: terminaltables: please remove config from debian/gbp.conf

[Sandro Tosi]

Ya the branch and pristine tar config can stay the rest is better left as a
local config, thanks!!

On Wed, Nov 13, 2019, 18:40 Carl Suster  wrote:

> Thanks for sponsoring!
>
> Sure, I'd left this config there since my first attempts at learning the
> gbp workflow. I understand why things like the pbuilder config don't
> belong in the package repo, but the branch/tag naming config is still
> relevant, no?
>
> Cheers,
> Carl
>

Bug#944687: terminaltables: please remove config from debian/gbp.conf

[Carl Suster]

Thanks for sponsoring!

Sure, I'd left this config there since my first attempts at learning the 
gbp workflow. I understand why things like the pbuilder config don't 
belong in the package repo, but the branch/tag naming config is still 
relevant, no?


Cheers,
Carl

Bug#944298: mesa: CVE-2019-5068

[Sylvain Beucler]

Hi,

I backported and tried the patch for Debian LTS.
The patch is trivial (basically s/0777/0600/).

However, I could not find a way to reproduce the initial issue.
The only way to get those 0777 shm in `ipcs` is to run Kali specifically
in virt-manager or VirtualBox.
I could not reproduce this issue with Debian.
Any ideas?

(Also, upstream patch was reviewed/approved at last:)
https://lists.freedesktop.org/pipermail/mesa-dev/2019-November/223771.html

Cheers!
Sylvain

Bug#944651: gcl: FTBFS on ppc64el

[Camm Maguire]

Greetings, and thanks!  I'm on it...

Take care,

Ivo De Decker  writes:

> package: src:gcl
> version: 2.6.12-88
> severity: serious
> tags: ftbfs
>
> Hi,
>
> The latest upload of gcl to unstable fails on ppc64el:
>
> https://buildd.debian.org/status/package.php?p=gcl
>
> I suspect the FTBFS of acl2 is related.
>
> Cheers,
>
> Ivo
>
>
>

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

Bug#938107: Quick update

[Iustin Pop]

Just for the record, this does build a python 3 module, removing the
python 2 one is just a matter of rdeps being migrated.

Bug#914577: fixed in dropwatch 1.5.1-1

[Alexandros Kosiaris]

On Wed, Nov 13, 2019 at 9:35 PM Dmitry Smirnov  wrote:
>
> On Thursday, 14 November 2019 3:33:42 AM AEDT Alexandros Kosiaris wrote:
> > Thanks, I 'll take up on your offer. If anything I 'll manage to learn
> > more about the bureaucracy aspects of package maintainer ship and
> > avoid such mistakes in the future.
>
> That's not a bureaucracy but important aspects of cooperation. Notion of
> ownership matters only as long as you have something to deliver. Therefore
> transparency (not bureaucracy) is crucial. Even when the work is unfinished,
> announce that you are on the task and where your work-in-progress repository
> is. That's precisely what ITP bugs are about - cooperation and coordination.

I think I might have used the term bureaucracy a bit too liberally.
What I meant is the administrative processes governing this (which I
clearly am not familiar with yet).

But otherwise, fully agreed.


>
> --
> All the best,
>  Dmitry Smirnov.
>
> ---
>
> Success consists of going from failure to failure without loss of enthusiasm.
> -- Winston Churchill

Bug#938073: Quick update

[Iustin Pop]

Just for the record, this does build a python 3 module, removing the
python 2 one is just a matter of rdeps being migrated.

Bug#937929: Quick update

[Iustin Pop]

Just for FYI, this now exports a Python 3 module, droppin the Python 2
one is just a matter of rdeps.

Bug#936604: getmail: Python2 removal in sid/bullseye

[Iustin Pop]

On 2019-11-14 00:24:15, Osamu Aoki wrote:
> On Wed, Nov 13, 2019 at 03:31:04PM +0100, Iustin Pop wrote:
> > On 2019-11-13 15:06:54, Thomas Goirand wrote:
> > > On 11/12/19 4:37 PM, Osamu Aoki wrote:
> > > > The related binary packages are available in 2 binary names (depending 
> > > > on release)
> > > >  getmail4 (version=4,5) popcon installed ~2000
> > > >  getmail  (version=3,5) popcon installed ~1000
> > > >
> > > > https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1
> > > >
> > > > I think this qualifies for "py2keep".
> > >
> > > IMO, this qualifies for RM-RoM. getmail is an alternative to fetchmail,
> > > which is still available in Debian (and with 4 times the number of
> > > installed package in popcon...). So I see no reason to keep getmail
> > > then. Maybe tell this to upstream, and they may think another time.
> >
> > Uh, no. Functionality-wise, they're quite different. getmail is (AFAIK)
> > the only tool that works for gmail with ASPs disabled (i.e. with OAUTH).
> >
> > Heck, I'd be very willing to maintain Py3 patches myself, because I need
> > this tool.
> 
> Please take over packaging from me then.  You are welcome.

I would gladly help with co-maintenance, but taking over packaging would
be my least preferred option.

Thanksfully, it seems the upstream is willing to move to Python 3, so I
think situation is pretty good, actually.

thank you!

Bug#944693: mailavenger: license incompatibility between 4-clause BSD and GPL

[Francesco Poli (wintermute)]

Package: mailavenger
Version: 0.8.5-2
Severity: serious
Justification: Policy 2.2.1

Hello,
I [noticed] that package mailavenger includes some files which are
derived from code originally released under the terms of the
4-clause BSD license, but their modifications are released under
the terms of the GNU GPL v2 or later, or anyway the files are part
of a whole released under the terms of the GNU GPL v3 or later.

[noticed]: 


The third clause in the 4-clause BSD license (the so-called "obnoxious
advertising clause") is incompatible with both the GNU GPL v2 and the
GNU GPL v3, as [stated] on the FSF license list.

[stated]: 

I believe this makes the package undistributable as is, hence
the "serious" severity of the bug report.


Luckily, the issue could be relatively easy to address.

As far as [libasync/convertint.C] and [libasync/suio_vuprintf.C]
are concerned, the parts covered by the 4-clause BSD license
are copyrighted by the The Regents of the University of California.
I think their general [re-licensing] applies, so the advertising
clause may be dropped: the code is effectively re-licensed under
the terms of the 3-clause BSD license (which is GPL-compatible!).

[libasync/convertint.C]: 

[libasync/suio_vuprintf.C]: 

[re-licensing]: 

As far as [libasync/getopt_long.c] and [util/getopt_long.c]
are concerned, the parts covered by the 4-clause BSD license
are copyrighted by the The NetBSD Foundation, Inc.
As far as I can tell, [NetBSD switched] to the 2-clause BSD license.
I am not 100 % sure this implies that any file copyrighted by
NetBSD Foundation under the 4-clause BSD license may now be effectively
considered as under the 2-clause BSD license (and thus
GPL-compatible!), but it may be worth getting in touch with
the Foundation and asking... I recommend doing so, in order to
get confirmation.

[libasync/getopt_long.c]: 

[util/getopt_long.c]: 

[NetBSD switched]: 


Please fix these issues.
Thanks for your time.

Bye!

Bug#944692: thin-provisioning-tools version 0.7.6-2.1 FTBFS

[Lucas Kanashiro]

I submitted a merge request on salsa which fixes this issue (and some 
others): 
https://salsa.debian.org/lvm-team/thin-provisioning-tools/merge_requests/2


Thanks for considering this!

--
Lucas Kanashiro

Bug#937330: Remove pyoptical from Debian, [or?] upgrade psychopy to latest upstream to enable Pandas migration

[Rebecca N. Palmer]

psychopy isn't blocking pandas' testing migration because psychopy 
already isn't in testing (for reasons unrelated to py2removal). 
Upstream say it's now Python 3 compatible [0], but I haven't tried to 
fix its other problems.


The ones that are blocking pandas [1] are python-skbio, 
python-feather-format and dask.


[0] https://github.com/psychopy/psychopy/blob/master/setup.cfg#22
[1] https://qa.debian.org/excuses.php?package=pandas (cnvkit since fixed)

Bug#936277: fixed in cctools 7.0.9-3

[Moritz Mühlenhoff]

reopen 936277
thanks

>  cctools (7.0.9-3) unstable; urgency=medium
>  .
>* Move to debhelper-compat 12
>* Drop python-workqueue for python2 transition. Closes: #936277

Hi Alastair, 
coop-computing-tools still depends on python:

$ apt-cache show coop-computing-tools
(..)
Version: 7.0.9-3
(..)
Depends: libc6 (>= 2.29), libfuse2 (>= 2.8), libglobus-common0 (>= 17), 
libglobus-gss-assist3 (>= 11), libglobus-gssapi-gsi4 (>= 13), libgomp1 (>= 
4.2.1), libncurses6 (>= 6), libreadline8 (>= 6.0), libsqlite3-0 (>= 3.7.15), 
libtinfo6 (>= 6), zlib1g (>= 1:1.2.0), python:any, python3

 ^^

Cheers,
Moritz

Bug#804629: Still present in buster, another (the?) workaround

[Jakob Haufe]

I stumbled across this issue yet again in a fresh buster installation.

Various conversions did not solve it for me, but after reading [1], I
checked and found that my initramfs indeed did not contain raid1.ko.

Adding raid1 to /etc/initramfs/modules made my system boot.

This suggests /usr/share/initramfs-tools/hooks/lvm2 might be at fault here.

I have to check whether this applies to bullseye/sid as well, but I
guess it does.

Cheers,
sur5r

[1] https://unix.stackexchange.com/questions/187236/grub2-lvm2-raid1-boot


pgp6e9gQcrrPC.pgp
Description: OpenPGP digital signature

Bug#944571: mmdebstrap: the license is not the actual Expat license

[Francesco Poli]

On Wed, 13 Nov 2019 11:55:12 +0100 Johannes Schauer wrote:

> Control: tag -1 + pending
> 
> Hi,
> 
> the bug is now fixed upstream:
> 
> https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/bc423e6ab63f7db04ef3deefe40a0068442ac7a5
> 
> Thanks!

Thanks to you!   :-)


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp7KXsQSQHdg.pgp
Description: PGP signature

Bug#944640: gtk-d: FTBFS on armel/armhf with many "multiple definition" messages

[Matthias Klumpp]

Am Mi., 13. Nov. 2019 um 08:45 Uhr schrieb Raphaël Hertzog
:
>
> Source: gtk-d
> Version: 3.9.0-2
> Severity: important
> Tags: ftbfs
>
> Hi,
>
> can you make a new source upload to let the package migrate to testing
> please ?
>
> I also noticed that the package still fails to build on armel/armhf with
> hundreds of message like these:
>
> /usr/bin/ld: ./libgtkd-3.a(ColorSelection.o): in function 
> `_D3std4conv110__T8textImplTAyaTAyaTPvTAyaTiTAyaTiTAyaTaTAyaThTAyaThTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTAxaTAyaTAxaTAyaZ8textImplFNaNfAyaPvAyaiAyaiAyaaAyahAyahAyabAyabAyabAyabAyabAyabAyaAxaAyaAxaAyaZAya':
> ./generated/gtkd/gtk/ColorSelection.d:401: multiple definition of 
> `_DT24_D3gtk6Widget6Widget10__mixin37720setBuildablePropertyMFC3gtk7Builder7BuilderAyaC7gobject5Value5ValueZv';
>  ./libgtkd-3.a(Button.o):./generated/gtkd/gtk/Button.d:565: first defined here
> /usr/bin/ld: ./libgtkd-3.a(ColorSelection.o): in function 
> `_D3std4conv110__T8textImplTAyaTAyaTPvTAyaTiTAyaTiTAyaTaTAyaThTAyaThTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTAxaTAyaTAxaTAyaZ8textImplFNaNfAyaPvAyaiAyaiAyaaAyahAyahAyabAyabAyabAyabAyabAyabAyaAxaAyaAxaAyaZAya':
> ./generated/gtkd/gtk/ColorSelection.d:401: multiple definition of 
> `_DT24_D3gtk6Widget6Widget10__mixin37716buildableSetNameMFAyaZv'; 
> ./libgtkd-3.a(Button.o):./generated/gtkd/gtk/Button.d:565: first defined here
> collect2: error: ld returned 1 exit status
> make[2]: *** [GNUmakefile:252: TestWindow] Error 1
> make[2]: Leaving directory '/<>'
> dh_auto_build: make -j8 "INSTALL=install --strip-program=true" test shared 
> prefix=/usr returned exit code 2
> make[1]: *** [debian/rules:19: override_dh_auto_build] Error 255

The cause of this is a GDC bug, the bugtracker should actually have
marked this package to be affected, but somehow that isn't the case...
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944380 for
details.
I will leave this issue open until the compiler issue is resolved.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#944645: systemd: upgrade breaks dbus

[Martin-Éric Racine]

ke 13. marrask. 2019 klo 23.16 Michael Biebl (bi...@debian.org) kirjoitti:
>
> Ok, at this point I guess it's best to involve upstream.
> Would you mind filing an upstream bug report at
> https://github.com/systemd/system/issues
> mentionting that a daemon-reload triggers an assert in
> manager_unref_uid_internal() and attaching your backtrace.

https://github.com/systemd/systemd/issues/14026

Bug#939270: inspircd: does not start reliably after reboot

[Christoph Biedl]

Marc Dequènes wrote...

> On 2019-11-01 19:32, Christoph Biedl wrote:
>
> > Upstream uses "After=network.target" only, basically
> > https://sources.debian.org/src/inspircd/3.3.0-1/make/template/inspircd.service/
> 
> Yes, but as referenced on this other bug systemd upstream recommends both
> statements. I see no downside in doing so, so why not go for it?

Well, I prefer minimal changes, especially in stable point releases. Also
it increases my work :)  since I should notify upstream¹ about that then.

However, after reading the systemd documentation and digesting some
headache pills needed after that, I have some vague idea what this all
is about, that it's at least the safer way to go, and therefore will
prepare according updates.

Stay tuned, and kind regards,

Christoph

¹ Now done: https://github.com/inspircd/inspircd/issues/1729


signature.asc
Description: PGP signature

Bug#937300: plaso: Python2 removal in sid/bullseye

[Sandro Tosi]

Hi Hilko,

On Fri, 30 Aug 2019 07:31:12 + Matthias Klose  wrote:
> Package: src:plaso
> Version: 20190131-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

can you just go ahead and remove py2 support here? thanks!

Bug#943992: transition: qscintilla2, soname 13 -> 15

[Gudjon I. Gudjonsson]

Hi Paul

A bit more info. I have tested to compile all of the reverse dependencies of 
qscintilla2-2.11.2 and all compile without problems.

$apt rdepends libqscintilla2-qt5-13
libqscintilla2-qt5-13
Reverse Depends:
  Depends: sqlitebrowser (>= 2.10.2)
  Depends: sonic-pi (>= 2.8.4)
  Depends: qgis-plugin-grass (>= 2.8.4)
  Depends: openscad (>= 2.8.4)
  Depends: octave (>= 2.8.4)
  Depends: juffed (>= 2.8.4)
$apt rdepends python3-pyqt5.qsci
python3-pyqt5.qsci
Reverse Depends:
  Depends: mu-editor
  Depends: geophar
  Depends: eric

I hope that helps with the transition.

Regards
Gudjon

Bug#944645: systemd: upgrade breaks dbus

[Michael Biebl]

Ok, at this point I guess it's best to involve upstream.
Would you mind filing an upstream bug report at
https://github.com/systemd/system/issues
mentionting that a daemon-reload triggers an assert in
manager_unref_uid_internal() and attaching your backtrace.

Thanks,
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#944691: dh: set umask 022 for all operations

[Thorsten Glaser]

Package: debhelper
Version: 12.7.1
Severity: wishlist

I’ve recently gained a build reproducibility error in src:musescore where
cmake is used to first copy a few files around, generate some, and then
create a PKZIP archive from them using its built-in archiver. The files
in that archive were different in permissions.

I’ve tried setting the umask globally by doing this:

• add “SHELL:=$(abspath debian/rwrap)” to debian/rules
• create debian/rwrap (executable) with the following content:

tglase@tglase:~/Projekte/musescore $ cat debian/rwrap 
#!/bin/lksh
# ${SHELL} wrapper to fix the umask

umask 022
eval "$2"

For some reason the desired effect is not observed, although
I had some debugging echos in debian/rwrap earlier whose output
was seen during a local build.

As there’s a general recommendation of using the dh wrapper
nowadays anyway, please (feature request, wishlist severity)
make it reset umask.

debian/rules has:

%:
dh $@ --buildsystem=cmake

I could probably change that to…

%:
umask 022 && exec dh $@ --buildsystem=cmake

… but everyone needs to do that then, and this is a good example
of harmonisation potential.

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.6.2-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-2
ii  file 1:5.37-6
ii  libdebhelper-perl12.7.1
ii  libdpkg-perl 1.19.7
ii  man-db   2.9.0-1
ii  perl 5.30.0-9
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#944664: [Python-modules-team] Bug#944664: pymodbus: please update to new 2.3.0 stable version

[Emmanuel Arias]

Hi,

I am trying to package v2.3.0 but we need upload python3-m2r  to unstable.

Pymodbus depends of m2r (2.3.0 and 2.2.0 too) for documentation.

We should submit a bugs for m2r upload?

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El mié., 13 de nov. de 2019 a la(s) 11:39, Gianfranco Costamagna
(locutusofb...@debian.org) escribió:
>
> Source: pymodbus
> Version: 2.1.0+dfsg-2
> Severity: normal
>
> Hello, can you please package 2.3.0 that is now stable?
> I personally need the new "register" feature of ModbusTcpClient class added 
> probably in 2.2.0
>
> thanks for maintaining it!
>
> Gianfranco
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#838994: Bug#891493: unresolved gtk2-engines-murrine situation (was: numix-gtk-theme: Undocumented and very likely also broken Breaks against murrine-themes since 2.6.7-2)

[Mike Gabriel]

Hi Yves-Alexis,

thanks for your reply.

On  Mi 13 Nov 2019 16:27:06 CET, Yves-Alexis Perez wrote:


On Tue, 2019-11-12 at 12:09 +0100, Mike Gabriel wrote:


As I haven't had any reply nor statement nor veto nor anything from any
of you on the above, here is what is going to happen, if noone interacts...


Hi Mike,

I'm unfortunately quite busy these days with a lot of stuff, and clearly the
various murrine themes are low priority for me. So I'll let you go ahead with
your plans, don't count on me for anything on this…


Ok. Thanks.


Thanks for the work anyway.


Thanks for the appreciation.

One last question: For the themes you maintain, is it ok if I provide  
the "Provides: any-murrine-theme" patches (as MRs or pushed commits)  
and possibly even NMU them for those murrine-like themes that need them?


Like in numix-gtk-theme [1].

Alternative option is me filing wishlist bugs against all related packages.

Thanks + Greets,
Mike

[1]  
https://salsa.debian.org/desktop-themes-team/numix-gtk-theme/commit/765624c473612866ab9227a41d0592816154e00e

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpBHloG1octk.pgp
Description: Digitale PGP-Signatur

Bug#944690: python-debianbts: Please rebuid your packaging with source-only upload

[Boyuan Yang]

Package: python3-debianbts
Severity: important
Version: 3.0.0

Dear python-debianbts developer,

Your package python-debianbts will not migrate to Debian Testing due to
uploads that contain maintainer-built packages. Please rebuild your package
and make another source-only upload to allow it to migrate to Testing.

You may find more information around Source-only upload at
https://wiki.debian.org/SourceOnlyUpload .

Please let me know if you have any questions or concerns.

-- 
Regards,
Boyuan Yang


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

Bug#943595: virtualbox-guest-additions-iso: New upstream version available: 6.0.14

[Thorsten Ehlers]

While waiting for resolve this issue we can use the 6.0.14 version from
Ubuntu which is linked
on the debian tracker site:
https://tracker.debian.org/pkg/virtualbox-guest-additions-iso

(right side below "links")

On Wed, 30 Oct 2019 17:16:49 +0100 =?UTF-8?Q?Holger_Schr=c3=b6der?= <
holgi@gmx.de> wrote:> I also wonder why the additions are no longer up
to date. It's been that
> way at 6.0.12, too.

Bug#944443: kopano-webapp and/or kopanocore missing a versioned (test) dependency on the other?

[Carsten Schoenert]

Hello Paul,

Am 13.11.19 um 19:35 schrieb Paul Gevers:
> Hi Carsten,
> 
> On 13-11-2019 07:20, Carsten Schoenert wrote:
>> But I"m struggling *how* to add such an versioned test dependency. This
>> version requirements are only needed for the autopkgtest(s) so because
>> of this we haven't bumped regulary and wanted package dependency.
> 
> Test version requirements go into debian/tests/control. Just add them to
> the appropriate Depends field.

unfortunately this is not possible this way as the test for
kopano-webapp itself is structured as various depending segments (like
in kopanocore too) there new packages get installed and we need a
pre-configured mariadb-server instance to get the test working.

https://salsa.debian.org/giraffe-team/kopano-webapp/blob/debian/sid/debian/tests/smoke

So the test is first installing the database server and afterwards the
kopano-webapp-apache2 package as we want to see all automatic pulled in
dependencies are working. One of the dependencies here is
kopano-contacts from src:kopanocore, and we pull also kopano-utils. The
tool kopano-admin (provided by kopano-utils) is currently working
internally differently in testing. As we install packages from
kopanocore as an automatic dependency I see no way to control within the
test the version we need as we can only relay on the version controlling
within the packages itself.

Sure, we could add a versioned dependency on kopanocore within
kopano-webapp, but there is no real technical reason for this, it would
only help that the autopkgtests do work. And as there is no real need
for a version bump on kopanocore we didn't have done this yet.

>> I'm happy to add such a needed version anywhere but I simply don't know
>> how. Any example package I can look at something similar.

I see currently only two possibilities to get kopanocore migrating to
testing. One is to add a new higher version on the depending
kopano-contacts in kopano-webapp-common (which then pulls kopano-libs),
and the second option would be an unblock by the RT. This is still the
right solution in my eyes.

The first option would need of course a new upload of kopano-webapp.


-- 
Regards
Carsten Schoenert

Bug#944118:

[PICCA Frederic-Emmanuel]

You are right, the file was downloaded from github, and files gives,

picca@cush:~/Debian/tango$ file tango-9.3.4-rc2.tar.gz
tango-9.3.4-rc2.tar.gz: gzip compressed data, from FAT filesystem (MS-DOS, 
OS/2, NT), original size 284221440

once repack with tar

picca@cush:~/Debian/tango$ file tango-9.3.4-rc2.tar.xz
tango-9.3.4-rc2.tar.xz: XZ compressed data

it works perfectly

picca@cush:~/Debian/tango/tango$ mk-origtargz --package tango --version 
9.3.4~rc2 --repack-suffix +dfsg1 --compression default --directory .. 
--copyright-file debian/copyright ../tango-9.3.4-rc2.tar.xz
Successfully repacked ../tango-9.3.4-rc2.tar.xz as 
../tango_9.3.4~rc2+dfsg1.orig.tar.xz, deleting 472 files from it.

Bug#944615: pam-python: please do a source-only upload

[Salvatore Bonaccorso]

Hi Ivo,

On Tue, Nov 12, 2019 at 06:55:45PM +0100, Ivo De Decker wrote:
> package: pam-python
> version: 1.0.7-1
> severity: important
> 
> Hi,
> 
> The latest upload of pam-python contains maintainer binaries, which blocks the
> transition to testing. Please do a source-only upload to allow the migration.

As this did fix
https://security-tracker.debian.org/tracker/CVE-2019-16729 (allowing
for local root escalation in certain PAM setups), I think this should
be RC in the sense we would not want 1.0.6-1.1 in 'bullseye' (if we
would be short before the release). 1.0.6-1.1+deb10u1 Contains the fix
so I guess this would "prop-up" at point release time to testing?

Regards,
Salvatore

Bug#666530: cups fails to configure under cdebconf

[Brian Potkin]

A nine year old bug with no response. I am closing it. If it has

relevance to today's printing system, someone will reopen it.

-- 
Brian.

Bug#885529: bumping severity of pygtk bugs

[Sudip Mukherjee]

Hi,

On Sun, Oct 06, 2019 at 05:09:30PM -0400, Jeremy Bicha wrote:
> Control: severity -1 serious
> Control: tags -1 -buster
> 
> 
> As part of the Python2 removal, it is our intent that pygtk will be removed 
> from Testing before the release of Debian 11
> "Bullseye". Therefore, I am bumping the severity of this bug to Serious to 
> ensure that there is plenty of warning before
> the Debian 11 release and to make the eventual removal of pygtk as smooth as 
> possible.

trace-cmd/2.8.3-1 is fixing this as it now uses qt and not pygtk. But
I am not sure if I should close this bug now or wait for you to verify
and close it.

--
Regards
Sudip

Bug#944654: prometheus: Broken dependency on transitional package libjs-moment-timezone

[Martina Ferrari]

Hi Ovidijus,

On 13/11/2019 11:18, Ovidijus Balkauskas wrote:
> Installing this version of prometheus on either:
>   - A machine that has a previous version of prometheus installed
>   - A machine that does not have a version of prometheus installed
> fails during installation due to dependent-upon package 
> 'libjs-moment-timezone' not available in the main Debian Stretch or Stretch 
> Backports repository not having this package available.
> 
> I've tested this on a couple of different machines and it seems its a 
> universal issue.

Indeed, this was my mistake, and I quickly corrected it by uploading the
missing package to stretch-backports, but it is still waiting in the NEW
queue: https://ftp-master.debian.org/backports-new.html

Hopefully, it will be accepted in a few days, and this will be solved.

-- 
Martina Ferrari (Tina, the artist formerly known as Tincho)

Bug#941799: lepton: should this package be removed?

[Ryan Tandy]

reassign -1 ftp.debian.org
retitle -1 RM: lepton -- RoQA; FTBFS; NPOASR; RC-buggy for 2 years
severity -1 normal
thanks

Dear maintainer,

As there was no response in over a month I hereby reassign this bug to 
ftp-masters as a removal request (RoQA).

Bug#941775: Debian isn't vulnerable

[dann frazier]

Just a note that, even though I've merged these fixes, we are actually
not vulnerable because we do not enable HTTP*S*BOOT in our builds.
That would require setting -DNETWORK_TLS_ENABLE=TRUE at build time,
which we do not do currently.

Bug#944645: systemd: upgrade breaks dbus

[Michael Biebl]

Am 13.11.19 um 20:48 schrieb Martin-Éric Racine:
> ke 13. marrask. 2019 klo 21.03 Michael Biebl (bi...@debian.org) kirjoitti:
>>
>> Btw, this reminds me of
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883877#103
>>
>> Is this the same host where this is happening (again)?
>> Is this a Virtualbox guest?
> 
> Same host. This has never been a Virtualbox guest.
> 

Ok, I'm asking because in the bug report referenced above you talked
about a /etc/ld.so.conf.d/i386-linux-gnu_GL.conf being the source of a
lot of troubles and afaics this file is shipped by virtualbox-guest-x11.

I assume you have since then purged virtualbox-guest-x11 and fixed the
ld.so.conf.d symlinks?
Last time, this seems to have fixed the crash.

-- 
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#944645: systemd: upgrade breaks dbus

[Martin-Éric Racine]

ke 13. marrask. 2019 klo 21.03 Michael Biebl (bi...@debian.org) kirjoitti:
>
> Btw, this reminds me of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883877#103
>
> Is this the same host where this is happening (again)?
> Is this a Virtualbox guest?

Same host. This has never been a Virtualbox guest.

Bug#944645: systemd: upgrade breaks dbus

[Martin-Éric Racine]

ke 13. marrask. 2019 klo 20.52 Michael Biebl (bi...@debian.org) kirjoitti:
>
> Thanks a lot for the information so far.
>
> Am 13.11.19 um 16:53 schrieb Martin-Éric Racine:
>
> > Setting up udev (243-5) ...
>
> Could you add a "set -x" to
> /var/lib/dpkg/info/udev.postinst to see which command triggers the segfault.

$ sudo dpkg --configure --pending
Setting up udev (243-5) ...
+ update_hwdb
+ systemd-hwdb --usr update
+ addgroup --quiet --system input
+ addgroup --quiet --system kvm
+ addgroup --quiet --system render
+ [ -z 242-7 ]
+ upgrade_fixes configure 242-7
+ dpkg --compare-versions 242-7 lt-nl 239-8
+ chrooted
+ stat -c %d/%i /
+ stat -Lc %d/%i /proc/1/root
+ [ 2049/2 = 2049/2 ]
+ return 1
+ can_start_udevd
+ [ ! -d /sys/class/ ]
+ return 0
+ [ -d /run/systemd/system ]
+ systemctl daemon-reload
Failed to reload daemon: Failed to activate service
'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
+ true
+ invoke-rc.d udev restart
Failed to reload daemon: Failed to activate service
'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
Failed to retrieve unit state: Yhteys aikakatkaistu
Failed to restart udev.service: Yhteys aikakatkaistu
See system logs and 'systemctl status udev.service' for details.
invoke-rc.d: initscript udev, action "restart" failed.
Failed to get properties: Yhteys aikakatkaistu
dpkg: error processing package udev (--configure):
 installed udev package post-installation script subprocess returned
error exit status 1
dpkg: dependency problems prevent configuration of network-manager:
 network-manager depends on udev; however:
  Package udev is not configured yet.
dpkg: error processing package network-manager (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 udev
 network-manager

> I suspect it's the daemon-reload, if so, it would be interesting if a
> simple "systemctl daemon-reload" is sufficient to trigger the crash.

Did not produce a core dump, but then again systemd presumably is dead
already at this point.

Bug#941078: transition: postgresql-12

[Paul Gevers]

Hi

On 12-11-2019 10:52, Christoph Berg wrote:
> Here's the list of remaining packages that need a "rebuild on buildd"
> binnmu:
> 
> bgw-replstatus
> ip4r
> jsquery
> orafce
> pg-cron
> pg-dirtyread
> pgextwlist
> pgfincore
> pgmemcache
> pg-partman
> pgq
> pg-qualstats
> pg-rage-terminator
> pg-rational
> pg-similarity
> pg-snakeoil
> pgsql-asn1oid
> pg-stat-kcache
> plr
> postgresql-debversion
> postgresql-hll
> postgresql-mysql-fdw
> postgresql-numeral
> postgresql-periods
> postgresql-pgmp
> postgresql-pllua
> postgresql-plproxy
> postgresql-plsh
> postgresql-prioritize
> postgresql-rum
> postgresql-unit
> powa-archivist
> prefix
> preprepare
> toastinfo
> vip-manager

Scheduled.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#944688: deal.ii ftbfs everywhere it build before during binNMU's for assimp 5.0.0

[Paul Gevers]

Source: deal.ii
Version: 9.1.1-6
Severity: serious
Tags: ftbfs sid bullseye
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

Your package is part of the assimp transition. I scheduled binNMU's but you
package fails to build everywhere it build in the past.

Looking at the reproducible-builds infra, it seems your package started to
FTBFS before this transition with the same error. Maybe this is related to the
gcc-9 change?

Paul

https://buildd.debian.org/status/package.php?p=deal.ii

Tail of log for deal.ii on amd64:

Source file was:

#include 

int main()
{
  int *i = new int;
  std::auto_ptr x(i);
  return 0;
}

dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
"-DDEAL_II_CXX_FLAGS=-Wno-nonnull-compare -Wno-address" 
-DCMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/hdf5/openmpi\;/usr/include/hdf5/openmpi
 -DCMAKE_BUILD_TYPE=DebugRelease -DDEAL_II_ALLOW_AUTODETECTION=OFF 
-DDEAL_II_ALLOW_BUNDLED=OFF -DDEAL_II_ALLOW_PLATFORM_INTROSPECTION=OFF 
-DDEAL_II_HAVE_FP_EXCEPTIONS=FALSE -DDEAL_II_COMPONENT_DOCUMENTATION=ON 
-DDEAL_II_WITH_ARPACK=ON -DDEAL_II_WITH_ASSIMP=ON -DDEAL_II_WITH_BOOST=ON 
-DDEAL_II_WITH_BZIP2=ON -DDEAL_II_WITH_GMSH=ON -DDEAL_II_WITH_GSL=ON 
-DDEAL_II_WITH_HDF5=ON -DDEAL_II_WITH_LAPACK=ON -DDEAL_II_WITH_MPI=ON 
-DDEAL_II_WITH_MUPARSER=ON -DDEAL_II_WITH_NETCDF=ON 
-DDEAL_II_WITH_OPENCASCADE=ON -DDEAL_II_WITH_P4EST=ON -DDEAL_II_WITH_PETSC=ON 
-DDEAL_II_WITH_SCALAPACK=ON -DDEAL_II_WITH_SLEPC=ON -DDEAL_II_WITH_SUNDIALS=ON 
-DDEAL_II_WITH_THREADS=ON -DDEAL_II_WITH_TRILINOS=ON -DDEAL_II_WITH_UMFPACK=ON 
-DDEAL_II_WITH_ZLIB=ON -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=OFF 
-DDEAL_II_BASE_NAME=deal.ii 
-DDEAL_II_DOCHTML_RELDIR=share/doc/libdeal.ii-doc/html 
-DDEAL_II_DOCREADME_RELDIR=share/doc/libdeal.ii-doc 
-DDEAL_II_EXAMPLES_RELDIR=share/doc/libdeal.ii-doc/examples 
-DDEAL_II_LIBRARY_RELDIR=lib/x86_64-linux-gnu 
-DDEAL_II_PROJECT_CONFIG_RELDIR=share/cmake/deal.II 
-DDEAL_II_SHARE_RELDIR=share/deal.ii/ .. returned exit code 1
make[1]: *** [debian/rules:10: override_dh_auto_configure] Error 255
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary-arch] Error 2



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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl3MWl4ACgkQnFyZ6wW9
dQrxEAf8CG69Mbfvso8sU1HZrRrDy4Qq7RB+vWDaWYd3MPuXGgsAS+B+h7oyqvJL
G6aCdWz9Z1YOXw5KLDi31R72O24GtBW5wqb9KKDWC049H3ACMXXIf6NU6+13Fsd+
iJZNOWn0C2MJ3KyJL5yrpTze+JAMOYHZXUqaT38EWcI1JoLqf7EchKKdTVPuNJLt
f9reZDe7/25D6e47BHOq5r1/PAkG5HhRe48v72adRW3LPIFY3l2NEv86nxzdfCoA
B4oQS+bDQTSHsct2y96ORkOpGfTBiwr9rq5uLU1dF66YXQQ+V7a09ZhOboUa48+x
+QeCc/XcN+/LADOH8dFWb0RnNhsECw==
=RTT1
-END PGP SIGNATURE-

Bug#939262: firmware-iwlwifi: Consider update to newest version (20190815)

[Sean Enck]

Small updates/notes:
- Apparently a few additional "release" tags have been made since opening
this
- I believe #940813 is the same issue

Bug#923314: unbound: Regression: systemctl reload unbound broken after upgrade from 1.8.1-1 to 1.9.0-2

[Ralf Jung]

I can confirm this, I just spent half an hour debugging this exact problem until
I realized the package is buggy, not my server.

Kind regards,
Ralf

Bug#944675: udev: Keyboard and mouse not working in X.org with udev 243-5

[Michael Biebl]

control: notfound -1 242-8
control: found -1 243-5

Am 13.11.19 um 17:01 schrieb Peter Habcak:
> Package: udev
> Version: 242-8
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgrading systemd (including udev) from 242-8 to 243-5 on my SID laptop,
> keyboard and mouse suddenly stopped working in X.org (lightdm login window in


-- 
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#944675: udev: Keyboard and mouse not working in X.org with udev 243-5

[Michael Biebl]

Hi Peter,

can you file this issue to upstream at
https://github.com/systemd/systemd/issues and report back with the issue
number.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#914577: fixed in dropwatch 1.5.1-1

[Dmitry Smirnov]

On Thursday, 14 November 2019 3:33:42 AM AEDT Alexandros Kosiaris wrote:
> Thanks, I 'll take up on your offer. If anything I 'll manage to learn
> more about the bureaucracy aspects of package maintainer ship and
> avoid such mistakes in the future.

That's not a bureaucracy but important aspects of cooperation. Notion of 
ownership matters only as long as you have something to deliver. Therefore 
transparency (not bureaucracy) is crucial. Even when the work is unfinished, 
announce that you are on the task and where your work-in-progress repository 
is. That's precisely what ITP bugs are about - cooperation and coordination.

-- 
All the best,
 Dmitry Smirnov.

---

Success consists of going from failure to failure without loss of enthusiasm.
-- Winston Churchill


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

Bug#944687: terminaltables: please remove config from debian/gbp.conf

[Sandro Tosi]

Source: terminaltables
Severity: important

most of those configs are your personal preferences, that are not strictly
needed to build a package from the DPMT repo.

while sponsoring this package, i had to empty its content so that i could build
it properly, extra work id rather dedicate to fix something.

please move them to ~/.gbp.conf if needed

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

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

Bug#944645: systemd: upgrade breaks dbus

[Michael Biebl]

Btw, this reminds me of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883877#103

Is this the same host where this is happening (again)?
Is this a Virtualbox guest?

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#944645: systemd: upgrade breaks dbus

[Michael Biebl]

Thanks a lot for the information so far.

Am 13.11.19 um 16:53 schrieb Martin-Éric Racine:

> Setting up udev (243-5) ...

Could you add a "set -x" to
/var/lib/dpkg/info/udev.postinst to see which command triggers the segfault.
I suspect it's the daemon-reload, if so, it would be interesting if a
simple "systemctl daemon-reload" is sufficient to trigger the crash.

-- 
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#944686: spectre-meltdown-checker: support for new TAA CVE-2019-11135

[Matt Taggart]

Package: spectre-meltdown-checker
Version: 0.42-2
Severity: wishlist

It looks like upstream added some changes for the new TAA vulnerability
CVE-2019-11135, made some other fixes since 0.42, updated the mcedb,
etc. but hasn't yet issued a new release. It looks like maybe they are
still working on solving #314 first?

Anyway hopefully a new upstream is coming soon and it would be good to
make available for stretch/buster.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#944684: mmdebstrap: APT list files for /etc/apt/sources.list.d/*.list remain in image

[Benjamin Drung]

Am Mittwoch, den 13.11.2019, 19:25 +0100 schrieb Johannes Schauer:
> Hi,
> 
> Quoting Benjamin Drung (2019-11-13 19:22:14)
> > mmdebstrap fails to remove all APT list files at the cleanup stage.
> > APT
> > list files for /etc/apt/sources.list.d/*.list remain in image. You
> > can
> > reproduce it by running:
> > 
> > mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg 
> > \
> >   -v --component=main \
> >   --setup-hook="echo \"deb http://deb.debian.org/debian $suite
> > contrib\" > \"\$1/etc/apt/sources.list.d/example.list\""
> >   buster /tmp/buster.tar.xz
> > 
> 
> why do you think this is a bug?

Since mmdebstrap echos "cleaning package lists and apt cache..." and
runs

   apt-get --option Dir::Etc::SourceList=/dev/null update

Running 'rm -rf "$0/var/lib/apt/lists/"*' in a customize hook has no
effect.

-- 
Benjamin Drung

Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet


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

Bug#944685: nmu: petsc_3.12.0+dfsg1-2

[Andreas Beckmann]

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

nmu petsc_3.12.0+dfsg1-2 . ANY . experimental . -m "Rebuild against libhypre 
2.18.2"


Andreas

Bug#942761: mmdebstrap: hooks not documented in man page / --help

[Benjamin Drung]

Am Mittwoch, den 13.11.2019, 19:22 +0100 schrieb Johannes Schauer:
> Hi,
> 
> Quoting Benjamin Drung (2019-11-13 19:03:31)
> > > If you are successfully using hooks today, then I'd be happy to
> > > hear
> > > whether the way the work now is useful for you or not.
> > Yes, I am successfully using hooks now. I migrated our custom in-
> > house build
> > script from using debootstrap to use mmdebstrap using custom hooks.
> > So the
> > hooks are useful and work. They are easy enough to use. I thought
> > about
> > alternatives, but found nothing better.
> 
> okay, that's good to know.
> 
> > One hook is missing: A clean hook that is run after the cleanup,
> > which would
> > be run at last step of the setup function.
> 
> What kind of stuff would you run there instead of putting it into the
> customize
> hook?

My cleanup script contains two things:

1) Removal of different stuff like /etc/resolv.conf,
/etc/udev/rules.d/70-persistent-net.rules, and /var/lib/apt/lists/"*
(removing the apt lists in the customize hook is too early, see
#944684)

2) Adjusting the timestamp of files/directories, e.g.:

find "$0/etc/" "$0/var/" -newermt "@${SOURCE_DATE_EPOCH}" \
\( -type f -o -type l \) -print0 | \
xargs -0r touch -hm -d "@${SOURCE_DATE_EPOCH}"

> > I have only one issue related to the hooks: There is no easy, safe,
> > and
> > reliable way to copy stuff out of the image to an existing
> > directory.  Use
> > case: copy the kernel+initrd out of the image for PXE booting.
> 
> I agree and I have needed this myself several times already. I'm
> still thinking
> of a good way to implement this because it does not only involve
> copying the
> data itself but also assuring right permission and ownership
> information.
> Furthermore, it should be possible to copy files in and out of the
> chroot at
> any point where hook are currently run.
> 
> Currently I'm doing a lot of this in my own scripts:
> 
> --customize-hook='cp -a tmpfile "$1/target/directory"'
> --customize-hook='echo foobar > "$1/target/file"'
> 
> I have been considering adding another option that allows extracting
> a tarball
> or copying a directory structure into the chroot but everytime I
> somehow feel
> that it's a bit overkill to create a new option for something that
> some shell
> snippet in the --customize-hook can already do.

Copying files into the chroot is no problem, since it can be done by
simple cp or rsync.

> I did not yet see a need for copying stuff out of the chroot because
> whatever
> is needed can be simply taken from the final tarball or the created
> directory.

Copying files out of the chroot is the problem. Currently I have to
create a temporary directory and make it world writable.

Copying the files after the final tarball was created is not a
solution, because I do not want to have some files in the tarball.
Example: I want to run

   dpkg-query -f='${Package}\t${Version}\n' -W

and store the output outside of the chroot. How about supporting
mounting directories into the chroot during building? Would that give
me the option to just copy/create the files inside that mounted
directory in a safe manner?

-- 
Benjamin Drung

Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet


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

Bug#944684: mmdebstrap: APT list files for /etc/apt/sources.list.d/*.list remain in image

[Johannes Schauer]

Hi,

Quoting Benjamin Drung (2019-11-13 19:22:14)
> mmdebstrap fails to remove all APT list files at the cleanup stage. APT
> list files for /etc/apt/sources.list.d/*.list remain in image. You can
> reproduce it by running:
> 
> mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \
>   -v --component=main \
>   --setup-hook="echo \"deb http://deb.debian.org/debian $suite contrib\" > 
> \"\$1/etc/apt/sources.list.d/example.list\""
>   buster /tmp/buster.tar.xz
> 

why do you think this is a bug?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#942761: mmdebstrap: hooks not documented in man page / --help

[Johannes Schauer]

Hi,

Quoting Benjamin Drung (2019-11-13 19:03:31)
> > If you are successfully using hooks today, then I'd be happy to hear
> > whether the way the work now is useful for you or not.
> Yes, I am successfully using hooks now. I migrated our custom in-house build
> script from using debootstrap to use mmdebstrap using custom hooks. So the
> hooks are useful and work. They are easy enough to use. I thought about
> alternatives, but found nothing better.

okay, that's good to know.

> One hook is missing: A clean hook that is run after the cleanup, which would
> be run at last step of the setup function.

What kind of stuff would you run there instead of putting it into the customize
hook?

> I have only one issue related to the hooks: There is no easy, safe, and
> reliable way to copy stuff out of the image to an existing directory.  Use
> case: copy the kernel+initrd out of the image for PXE booting.

I agree and I have needed this myself several times already. I'm still thinking
of a good way to implement this because it does not only involve copying the
data itself but also assuring right permission and ownership information.
Furthermore, it should be possible to copy files in and out of the chroot at
any point where hook are currently run.

Currently I'm doing a lot of this in my own scripts:

--customize-hook='cp -a tmpfile "$1/target/directory"'
--customize-hook='echo foobar > "$1/target/file"'

I have been considering adding another option that allows extracting a tarball
or copying a directory structure into the chroot but everytime I somehow feel
that it's a bit overkill to create a new option for something that some shell
snippet in the --customize-hook can already do.

I did not yet see a need for copying stuff out of the chroot because whatever
is needed can be simply taken from the final tarball or the created directory.

If you have any ideas, feel free and try to convince me. :)

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#944684: mmdebstrap: APT list files for /etc/apt/sources.list.d/*.list remain in image

[Benjamin Drung]

Package: mmdebstrap
Version: 0.5.1-2
Severity: normal

Hi,

mmdebstrap fails to remove all APT list files at the cleanup stage. APT
list files for /etc/apt/sources.list.d/*.list remain in image. You can
reproduce it by running:

mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \
  -v --component=main \
  --setup-hook="echo \"deb http://deb.debian.org/debian $suite contrib\" > 
\"\$1/etc/apt/sources.list.d/example.list\""
  buster /tmp/buster.tar.xz

-- 
Benjamin Drung

Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet

Bug#944629: RFP: libcatalyst-plugin-session-store-redis-perl -- Redis Session store for Catalyst

[gregor herrmann]

On Tue, 12 Nov 2019 23:51:02 +0100, Guillem Jover wrote:

> * Package name: libcatalyst-plugin-session-store-redis-perl

> Attached a working and tested packaging, where only the ITP bug number
> needs to be filled in the debian/changelog, Maintainer changed, and
> Vcs fields added if appropriate.

Thanks, imported into the pkg-perl namespace on salsa and uploaded to
NEW with micro-changes.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Pirate Praveen]

On Mon, 11 Nov 2019 22:15:20 +0530 Pirate Praveen
 wrote:
> Control: retitle -1 ssh access fails with gitaly-upload-pack: fatal:
> error: %v
> On Sat, 2 Nov 2019 14:51:42 +0100 Romain Bignon  wrote:
> > Hello,
> > 
> > The problem is still here, and is so not related to compatibility between
> > versions of gitlab/gitlab-shell/gitality…
> > 
> > Is there anything I can do to find the origin of this issue?
> 
> Fortunately or unfortunately the same error hit my instance as well. I'm
> digging deeper into it now.
> 
> As a workaround you can use https access till we fix this (only ssh
> access is affected).

Found the root cause to be ruby-google-protobuf update from 3.7 to 3.10.
But to actually get it work is tricky.

If we downgrade ruby-google-protobuf to 3.7.1, then gitaly fails to build.

Bug#942761: mmdebstrap: hooks not documented in man page / --help

[Benjamin Drung]

Am Montag, den 21.10.2019, 13:59 +0200 schrieb Johannes Schauer:
> Hi,
> 
> Quoting Benjamin Drung (2019-10-21 09:41:37)
> > The hooks are not documented in the man page / --help output
> > despite
> > having them documented in the end of the mmdebstrap file:
> > 
> > $ man mmdebstrap | grep hook
> > $
> 
> yes, that is a feature not a bug. :)
> 
> I was never quite sure about how I want to implement hooks with
> mmdebstrap as
> in what interface would be useful and easy enough to use. So I
> implemented the
> functionality but by not documenting it, it is still experimental and
> might
> change in future releases.
> 
> If you are successfully using hooks today, then I'd be happy to hear
> whether
> the way the work now is useful for you or not.

Yes, I am successfully using hooks now. I migrated our custom in-house
build script from using debootstrap to use mmdebstrap using custom
hooks. So the hooks are useful and work. They are easy enough to use. I
thought about alternatives, but found nothing better.

One hook is missing: A clean hook that is run after the cleanup, which
would be run at last step of the setup function.

I have only one issue related to the hooks: There is no easy, safe, and
reliable way to copy stuff out of the image to an existing directory.
Use case: copy the kernel+initrd out of the image for PXE booting.

-- 
Benjamin Drung

Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet


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

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

[Diane Trout]

On Tue, 2019-11-12 at 20:43 -0800, Vagrant Cascadian wrote:
> On 2019-05-28, Vagrant Cascadian wrote:
> > On 2019-05-16, Vagrant Cascadian wrote:
> > > So in a bit of a focused run of packaging, I've been chasing the
> > > dependency chain necessary to get guix building on Debian:
> 
> Summary: all the dependencies are in Debian!
> 

Congratulations!


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

Bug#944683: FTBFS: missing file /usr/lib/nodejs/axios/dist/axios.min.js

[Gert Wollny]

Package: orthanc-dicomweb
Version: orthanc-dicomweb_1.0+dfsg-1
Severity: serious
Justification: 4

Dear Maintainer,

While I was trying to rebuild the package to use libgdcm-dev instead
of 
libgdcm2-dev (change already pushed to the repo) the package failed to
build for another reason with the following error: 

  CMake Error at
debian/ThirdPartyDownloads/JavaScriptLibraries.cmake:10 (file):
file COPY cannot find "/usr/lib/nodejs/axios/dist/axios.min.js".
  Call Stack (most recent call first):
CMakeLists.txt:68 (include)

It seems like the file has changed its location to 

   /usr/share/nodejs/axios/dist/axios.min.js

Best, 
Gert 


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

Kernel: Linux 5.3.9-gentoo (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages orthanc-dicomweb depends on:
ii  libboost-filesystem1.67.0  1.67.0-13
ii  libboost-locale1.67.0  1.67.0-13
ii  libboost-regex1.67.0   1.67.0-13
ii  libboost-system1.67.0  1.67.0-13
ii  libboost-thread1.67.0  1.67.0-13
ii  libc6  2.29-3
ii  libgcc11:9.2.1-19
ii  libgdcm2.8 2.8.8-9+b1
ii  libjsoncpp11.7.4-3+b1
ii  libpugixml1v5  1.9-3
ii  libstdc++6 9.2.1-19
ii  libuuid1   2.34-0.1
pn  orthanc

orthanc-dicomweb recommends no packages.

orthanc-dicomweb suggests no packages.

Bug#943325: mmdebstrap requires that the correct keyring is specified

[Johannes Schauer]

Hi,

Quoting Benjamin Drung (2019-11-13 18:47:09)
> Thanks for implementing it. Specifying --keyring before --aptopt fails:
> 
> mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \
>   -v --aptopt='Acquire::http { Proxy "123"; }' \
>   buster /tmp/buster.tar.xz
> 

I know. The situation is actually worse. The problem is, that apt only allows a
single keyring file or directory. This means that we cannot have apt use the
keyrings on the host and any manually specified keyrings at the same time. This
is a problem.

A solution would be to copy all keyring material from the host plus all
additionally specified keys into the chroot. But this would dirty the chroot
with all kinds of keyrings from the host, many of which are probably not meant
to end up in every chroot the user creates.

I'm still thinking about the right solution to this problem...

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#944649: e2fsprogs: FTBFS on hurd-i386

[Theodore Y. Ts'o]

On Wed, Nov 13, 2019 at 11:38:55AM +0100, Svante Signell wrote:
> Source: e2fsprogs
> Version: 1.45.4-1
> Severity: important
> Tags: patch
> Usertags: hurd
> User: debian-h...@lists.debian.org
> 
> Hello,
> 
> The latest version of e2fsprogs in sid, 1.45.4-1, FTBFS on GNU/Hurd due to two
> reasons:
> 1)  is not available.
> 2) PATH_MAX is not defined.
> 
> 1) is fixed with the attached patch, configure.ac.diff where a variable MOUNT 
> is
> introduced and checked for.

That's not the correct patch.  The right fix is to drop the test for
sys/mount in AX_CHECK_MOUNT_OPT in acinclude.m4.  If sys/mount doesn't
exist, this will be interpreted as the system not supporting nosuid
and nodev.  (Which is fine, since as I recall HURD doesn't support
fuse, and HAVE_MOUNT_{NOSUID,NODEV} is only used for fuse2fs.)

> 2) is fixed by lib_ext2fs_dirhash.c.diff, which simply defines  PATH_MAX, if 
> not
> defined. Instead of using PATH_MAX this could probably be solved more 
> elegantly
> by dynamic allocation of the needed size of buff, but grepping for PATH_MAX in
> the code shows plenty of occurrences already, solved in various ways, so I did
> not find the motivation for doing that.

Thanks, that's look good.  I'll apply that for the next release.

> Additionally, in order to test the packages on a GNU/Linux system, not using
> systemd, patches debian_control.diff and debian_e2fsprogs.install were needed.

Yeah, but that's not something I can apply, because we need systemd to
be present on the build boxes so we can properly create the e2fsprogs
debs to support systemd systems --- and the only way to enforce this
is with a build dependency.

> Regarding the tests for GNU/Hurd they have to be disabled for now. Plenty of
> failing tests are not applicable to Hurd. Patches for the failing tests are in
> the works, the list is now 38 entries with some more to fix. That patch is
> pending and will be reported in a separate bug report.

Please ensure that the any changes to the tests do not cause them to
break on Linux, and if possible it would be nice if you could check to
make sure it doesn't cause test regressions on FreeBSD as well.

Thanks!

- Ted

Bug#943325: mmdebstrap requires that the correct keyring is specified

[Benjamin Drung]

Am Freitag, den 25.10.2019, 09:57 +0200 schrieb Johannes Schauer:
> Hi,
> 
> Quoting Benjamin Drung (2019-10-24 11:54:14)
> > Since automatically choosing the right keyring is non-reliable and
> > adding symlinks into /etc/apt/trusted.gpg.d affects the host
> > system, I
> > like to have a --keyring parameter until there is a better solution
> > found.
> > 
> > This --keyring parameter should set the apt option
> > Dir::Etc::Trusted if
> > it points to a file and Dir::Etc::TrustedParts if it points to a
> > directory. I can remember --keyring and find the correct full path
> > without needing to look into a man page.
> 
> actually I found an even better reason why a --keyring parameter is
> no problem:
> debootstrap has it as well!
> 
> So the user might actually expect the parameter to exist and has an
> idea of how
> it works.
> 
> And yes, it should set the apt options you mention depending on
> whether a file
> or directory is passed and it should be possible to specify the --
> keyring
> parameter multiple times.
> 
> Thanks!

Thanks for implementing it. Specifying --keyring before --aptopt fails:

mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \
  -v --aptopt='Acquire::http { Proxy "123"; }' \
  buster /tmp/buster.tar.xz

-- 
Benjamin Drung

Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet


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

Bug#943327: mmdebstrap: Please support using pixz

[Benjamin Drung]

Am Mittwoch, den 13.11.2019, 17:54 +0100 schrieb Johannes Schauer:
> Quoting Benjamin Drung (2019-11-13 17:08:46)
> > > with some minor changes committed here:
> > > 
> > > https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/4b82a664daa5b2430a00b737706ee77c75288158
> > 
> > Sadly, this change breaks mmdebstrap:
> > 
> > $ LANG=C tar -tf root.tar.xz 
> > ./dev/
> > ./dev/console
> > ./dev/fd
> > ./dev/full
> > ./dev/null
> > ./dev/ptmx
> > ./dev/pts/
> > ./dev/random
> > ./dev/shm/
> > ./dev/stderr
> > ./dev/stdin
> > ./dev/stdout
> > ./dev/tty
> > ./dev/urandom
> > ./dev/zero
> > tar: Skipping to next header
> > tar: Exiting with failure status due to previous errors
> > 
> > When I developed the patch, I just checked that the tarball was
> > created and
> > the file size matches, but I didn't check the content.
> 
> ah indeed. This is of course because mmdebstrap assembles the tarball
> from two
> parts and then runs the compressor outside of tar. A correct patch
> probably
> look more like this:
> 
> @@ -161,7 +161,7 @@ sub get_tar_compressor($) {
>  } elsif ($filename =~ /\.lz4$/) {
> return 'lz4';
>  } elsif ($filename =~ /\.(xz|txz)$/) {
> -   return 'xz';
> +   return ('xz', '--threads=0');
>  } elsif ($filename =~ /\.zst$/) {
> return 'zstd';
>  }

I have tested this proposed change by dirty patching the two exec
lines:

exec ($tar_compressor, '--threads=0') or error "[...]";

It works and creates a tarball. The generated tarball is actually
working (verified by using it).

-- 
Benjamin Drung

Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet


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

Bug#944682: nmu: slic3r-prusa_1.41.3+dfsg-1

[Andreas Beckmann]

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

nmu slic3r-prusa_1.41.3+dfsg-1 . ANY . experimental . -m "Rebuild against Perl 
5.30."

slic3r-prusa/experimental still depends on perl 5.28 packages.


Andreas

Bug#944681: py-libzfs: FTBFS: libzfs.c:1:2: error: #error Do not use this file, it is the result of a failed Cython compilation.

[Andreas Beckmann]

Source: py-libzfs
Version: 0.0+git20190717.39ccb15-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

py-libzfs FTBFS on all architectures:
https://buildd.debian.org/status/package.php?p=py-libzfs=experimental
I can also reproduce it on amd64.

   dh_auto_build -a -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_ext
cythoning libzfs.pyx to libzfs.c
building 'libzfs' extension
creating build
creating build/temp.linux-arm64-3.7
aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security 
-g -fwrapv -O2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.7m -c libzfs.c -o 
build/temp.linux-arm64-3.7/libzfs.o -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -I/usr/include/libzfs/ -I/usr/include/libspl/ 
-D_MACHINE_ENDIAN_H_ -DHAVE_ISSETUGID -Werror=implicit-function-declaration 
-Wdate-time -D_FORTIFY_SOURCE=2
libzfs.c:1:2: error: #error Do not use this file, it is the result of a failed 
Cython compilation.
1 | #error Do not use this file, it is the result of a failed Cython 
compilation.
  |  ^
warning: ./pxd/nvpair.pxd:56:3: 'DATA_TYPE_UINT8_ARRAY' redeclared 
warning: libzfs.pyx:571:24: Non-trivial type declarators in shared declaration 
(e.g. mix of pointers and values). Each pointer declaration should be on its 
own line.
warning: libzfs.pyx:571:31: Non-trivial type declarators in shared declaration 
(e.g. mix of pointers and values). Each pointer declaration should be on its 
own line.
warning: libzfs.pyx:572:29: Non-trivial type declarators in shared declaration 
(e.g. mix of pointers and values). Each pointer declaration should be on its 
own line.
warning: libzfs.pyx:572:35: Non-trivial type declarators in shared declaration 
(e.g. mix of pointers and values). Each pointer declaration should be on its 
own line.

Error compiling Cython file:

...

with nogil:
IF HAVE_ZPOOL_SEARCH_IMPORT_LIBZUTIL and 
HAVE_ZPOOL_SEARCH_IMPORT_PARAMS == 3:
result = libzfs.zpool_search_import(self.handle, , 
_config_ops)
ELSE:
result = libzfs.zpool_search_import(self.handle, )
  ^


libzfs.pyx:814:31: cimported module has no attribute 'zpool_search_import'

Error compiling Cython file:

...
raise OSError(errno.EINVAL, 'Not a character device')

IF HAVE_ZPOOL_READ_LABEL_PARAMS == 3:
ret = libzfs.zpool_read_label(fd, , NULL)
ELSE:
ret = libzfs.zpool_read_label(fd, )
   ^


libzfs.pyx:3390:20: cimported module has no attribute 'zpool_read_label'

Error compiling Cython file:

...

with nogil:
IF HAVE_ZPOOL_SEARCH_IMPORT_LIBZUTIL and 
HAVE_ZPOOL_SEARCH_IMPORT_PARAMS == 3:
result = libzfs.zpool_search_import(self.handle, , 
_config_ops)
ELSE:
result = libzfs.zpool_search_import(self.handle, )
  ^


libzfs.pyx:814:51: Calling gil-requiring function not allowed without gil
error: command 'aarch64-linux-gnu-gcc' failed with exit status 1
E: pybuild pybuild:341: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build 
dh_auto_build: pybuild --build -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:8: build-arch] Error 255

Andreas

Bug#944680: python-ftputil: Python2 removal in sid/bullseye

[Stuart Prescott]

Source: python-ftputil
Version: 3.4-1
Severity: serious
Tags: sid bullseye
Justification: Python 2 is going away.
User: debian-pyt...@lists.debian.org
Usertags: py2removal

New Python 2 packages shouldn't be added to bullseye at this stage unless it's
the *only* way of helping some other package transition from Python 2 to
Python 3 *and* there is a clear plan on how and when to remove them in early
2020.

--- boilerplate of the rest of the py2rm bug below ---

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:python-debian

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#944645: systemd: upgrade breaks dbus

[Martin-Éric Racine]

ke 13. marrask. 2019 klo 17.37 Michael Biebl (bi...@debian.org) kirjoitti:
>
> Am 13.11.19 um 16:06 schrieb Martin-Éric Racine:
>
> >> Can you provide a dmesg dump and the output of journalctl -alb.
> >
> > Attached.
> >
> >> Please mark the time when the upgrade happened.
> >
> > It happened about 10 minutes before I sent the bug report.
> >
> > /var/log/apt/term.log indicates Log started: 2019-11-13  10:24:05
> >
> > term.log attached
> >
>
>
> The dmesg and journalctl log don't show a crash.
> They are apparently after a (forced) reboot.
>
> Could you retrigger the apt update and once you hit the crash, attach
> journal/dmesg/coredump

Here's what gdb sees with the core dump from PID 716:

Reading symbols from /bin/systemd...
Reading symbols from
/usr/lib/debug/.build-id/88/f695a88e6d77205e02c54057685cdc8eca97e0.debug...
[New LWP 716]
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `/sbin/init noquiet nosplash'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb7f3e851 in __kernel_vsyscall ()
[Current thread is 1 (LWP 716)]
(gdb) bt
#0  0xb7f3e851 in __kernel_vsyscall ()
#1  0xb7d7e1d6 in kill () at ../sysdeps/unix/syscall-template.S:78
#2  0x0053d774 in crash (sig=6) at ../src/core/main.c:212
#3  
#4  0xb7f3e851 in __kernel_vsyscall ()
#5  0xb7d7dee2 in __libc_signal_restore_set (set=0xbfc8d85c) at
../sysdeps/unix/sysv/linux/internal-signals.h:84
#6  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#7  0xb7d682bd in __GI_abort () at abort.c:79
#8  0xb7ad57f6 in log_assert_failed_realm (realm=LOG_REALM_SYSTEMD,
text=0x559ba4 "n > 0", file=0x53e338 "src/core/manager.c", line=4282,
func=0x55b3d8 <__PRETTY_FUNCTION__.21510>
"manager_unref_uid_internal") at ../src/basic/log.c:801
#9  0x004f5144 in manager_unref_uid_internal (m=,
uid_refs=0x22399e0, uid=4294948095, destroy_now=false,
_clean_ipc=0xb7c129f0 )
at ../src/core/manager.c:4282
#10 0x004ca8fe in unit_unref_uid_internal (u=u@entry=0x226d0c0,
ref_uid=ref_uid@entry=0x226d2d8, destroy_now=destroy_now@entry=false,
_manager_unref_uid=0x4f5150 )
at ../src/core/unit.c:5063
#11 0x004ccdd8 in unit_unref_gid (destroy_now=false, u=0x226d0c0) at
../src/core/unit.c:5166
#12 unit_unref_uid_gid (u=0x226d0c0, destroy_now=false) at
../src/core/unit.c:5166
#13 0x004da200 in unit_free (u=) at ../src/core/unit.c:646
#14 0x00504bd5 in manager_clear_jobs_and_units (m=) at
../src/core/manager.c:1299
#15 manager_clear_jobs_and_units (m=0x2239610) at ../src/core/manager.c:1293
#16 0x0053bbc3 in manager_reload (m=0x2239610) at ../src/core/manager.c:3521
#17 invoke_main_loop (m=0x2239610, saved_rlimit_nofile=, saved_rlimit_memlock=, ret_reexecute=, ret_retval=,
ret_shutdown_verb=, ret_fds=,
ret_switch_root_dir=, ret_switch_root_init=, ret_error_message=)
at ../src/core/main.c:1734
#18 0x0048ab3a in main (argc=, argv=) at
../src/core/main.c:2642
(gdb)

Martin-Éric

Bug#944679: extlinux: Visual bugs while editing a long kernel command line

[Mikhail Morfikov]

Package: extlinux
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

My current kernel command line is about 400-character long. When it was
shorter, I didn't have any issues when I wanted to edit this line in the
bootloader screen by selecting some entry and pressing "E".

I recently added some other kernel parameters to the cmd line, and I noticed
many visual bugs in the bootloader screen. Basically with each cursor movement
(back and forth), I get an extra text line in the screen output (copy of the
current line scrolled up). Also characters in the cmd line disappear or change
when I move the cursor back. The visual bugs make it almost impossible to edit
the kernel cmd line. Also When I press the backspace key (or the back arrow
key)
for a longer period of time (let's assume I want to delete some parameters
entirely from the line), I hear the hardware beeper which is really annoying.

I found out that the problem appears when I have more than 4 lines of text on
the screen when editing the cmd line. So fifth (and next ones) will trigger the
visual bugs, while 4 (and less) won't.

So what to do with it?



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

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

Versions of packages extlinux depends on:
ii  libc6  2.29-3

Versions of packages extlinux recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-1

extlinux suggests no packages.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAl3MNmEACgkQzQRoEHcb
ZSCybg/+LbzriiSLoPsLRK9iW+GmMD4U82YnK6OoEjz7YMIWi8yJzzzgsRgoSJs5
yOpXTdbMQchScmbrloMb7jBDWkaK594+2RvL+ZOyeYt7SNAwIyZEv4AdA1DiNArn
moKQk48WPKV4gNqVXnjlvs+Eab6nFh7AokzMSG7TxHiZ283s1aQYOdUjiVWdU2YH
pLgd1qRsKf7tz1kJfTmTx4tx8w8dR7Qxe6vuesShEr+QHwb4PjliroXzxrTJYBAe
WVikkk6aYkWrDJHmn2SOmrXdwzUOpkIOuSludoP2ctDZfjsHbigNMI40smQI/t0F
qnLwZ0QscOybxE1z4l4WHnpr3opl3EyLg2XNvbdDCXBZdFP+YmVHG06sZrEwJktc
UALj5pTAytB87vK7p77kMsAOniZJj2T47mdh8ggJmYiGby4JkGWr3Ya9YTWRoQxX
v1ohflHg8OC88iXWaAQPzi/gtpcM17IkeR5EDWV+/FtOzSVReqjpXwI37DvJ0CUp
BcB/ZBdLJ2MTAU5D7UKm/0OIjPcfE110ICXrbCn+oBvhZ+Tn1GeYrQje4nW1Rfb5
dWU2Ue4FzGPun/d/M1zVmVSUYocPpY6nLOn6Qh5+t6yK0vKzkuyhFgsrURrJwLQ8
qFEjFQfep4vpM0NF+JHriPGglyVpkaEHklCl9IqxcPVbIEL7AjQ=
=QWGV
-END PGP SIGNATURE-

Bug#943327: mmdebstrap: Please support using pixz

[Johannes Schauer]

Quoting Benjamin Drung (2019-11-13 17:08:46)
> > with some minor changes committed here:
> > 
> > https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/4b82a664daa5b2430a00b737706ee77c75288158
> 
> Sadly, this change breaks mmdebstrap:
> 
> $ LANG=C tar -tf root.tar.xz 
> ./dev/
> ./dev/console
> ./dev/fd
> ./dev/full
> ./dev/null
> ./dev/ptmx
> ./dev/pts/
> ./dev/random
> ./dev/shm/
> ./dev/stderr
> ./dev/stdin
> ./dev/stdout
> ./dev/tty
> ./dev/urandom
> ./dev/zero
> tar: Skipping to next header
> tar: Exiting with failure status due to previous errors
> 
> When I developed the patch, I just checked that the tarball was created and
> the file size matches, but I didn't check the content.

ah indeed. This is of course because mmdebstrap assembles the tarball from two
parts and then runs the compressor outside of tar. A correct patch probably
look more like this:

@@ -161,7 +161,7 @@ sub get_tar_compressor($) {
 } elsif ($filename =~ /\.lz4$/) {
return 'lz4';
 } elsif ($filename =~ /\.(xz|txz)$/) {
-   return 'xz';
+   return ('xz', '--threads=0');
 } elsif ($filename =~ /\.zst$/) {
return 'zstd';
 }



signature.asc
Description: signature