Bug#931083: [Debian-ha-maintainers] Bug#931083: ocfs2-tools FTCBFS: broken, outdated, embedded copies of PKG_PROG_PKG_CONFIG and AM_PATH_GLIB_2_0

[Valentin Vidić]

On Wed, Jun 26, 2019 at 06:21:12AM +0200, Helmut Grohne wrote:
> Thank you for the quick reply. I confirm that the patch makes
> ocfs2-tools cross buildable. I suggest that next time, you try cross
> building it yourself to avoid waiting for me. If you normally use
> sbuild, add "--host=somearch". If you normally use pbuilder add
> "--host-arch somearch". If either doesn't work as advertised, complain
> at debian-cr...@lists.debian.org. For uploaded versions, you can also
> check http://crossqa.debian.net/src/ocfs2-tools.

Great and thanks for the info, sbuild --host seems to work fine for me too.

-- 
Valentin

Bug#930887: [Debian-ha-maintainers] Bug#930887: Bug#930887: CVE-2019-10153

[Valentin Vidić]

On Tue, Jun 25, 2019 at 09:32:48AM +0200, wf...@niif.hu wrote:
> I think so, but I may overlook something.  Also, I find the switch to
> UTF-8 decoding a somewhat unsatisfactory fix: is it wise to depend on
> the result being correctly UTF-8 encoded?  If anything goes wrong, an
> exception is thrown all the same, it depends on the server.  It may be
> desirable, though, I don't know a thing about rhevm.

Yes, I guess it assumes the rhevm service returns UTF-8, but I also don't
have access to check this so we'll have to trust the upstream that this is
fixed for now.

-- 
Valentin

Bug#931083: [Debian-ha-maintainers] Bug#931083: ocfs2-tools FTCBFS: broken, outdated, embedded copies of PKG_PROG_PKG_CONFIG and AM_PATH_GLIB_2_0

[Helmut Grohne]

On Wed, Jun 26, 2019 at 05:00:30AM +0200, Valentin Vidić wrote:
> Thanks for the report. Can you perhaps check if the attached patch helps
> with the cross build of the package?

Thank you for the quick reply. I confirm that the patch makes
ocfs2-tools cross buildable. I suggest that next time, you try cross
building it yourself to avoid waiting for me. If you normally use
sbuild, add "--host=somearch". If you normally use pbuilder add
"--host-arch somearch". If either doesn't work as advertised, complain
at debian-cr...@lists.debian.org. For uploaded versions, you can also
check http://crossqa.debian.net/src/ocfs2-tools.

Helmut

Bug#931092: libirman FTCBFS: Makefile.am hard codes pkg-config

[Helmut Grohne]

Source: libirman
Version: 0.5.2-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libirman fails to cross build from source, because the upstream
Makefile.am hard codes the build architecture pkg-config. After making
it substitutable, libirman cross builds successfully. Please consider
applying the attached patch.

Helmut
--- libirman-0.5.2.orig/Makefile.am
+++ libirman-0.5.2/Makefile.am
@@ -16,9 +16,9 @@
 uninstall-hook:
 	rm -f $(DESTDIR)$(plugindir)/irman.so
 
-plugindir   = $(shell pkg-config --variable=plugindir lirc-driver)
-configdir   = $(shell pkg-config --variable=configdir lirc-driver)
-plugindocsdir   = $(shell pkg-config --variable=plugindocs lirc-driver)
+plugindir   = $(shell $(PKG_CONFIG) --variable=plugindir lirc-driver)
+configdir   = $(shell $(PKG_CONFIG) --variable=configdir lirc-driver)
+plugindocsdir   = $(shell $(PKG_CONFIG) --variable=plugindocs lirc-driver)
 
 plugin_LTLIBRARIES  = irman.la
 irman_la_SOURCES= lirc-plugin/irman.c

Bug#929772: ResidualVM should be built against SDL2 instead of SDL 1.2

[Markus Koschany]

Hello,

Am 30.05.19 um 20:55 schrieb Bastien Bouclet:
> Package: residualvm
> 
> Version: 0.3.1+dfsg-1
> 
> I'm an upstream maintainer of ResidualVM and just noticed the version
> packaged in Debian was build against SDL 1.2. At this point we recommend
> linking against SDL 2, as ResidualVM can take advantage of the new
> capabilities of that version. Our support of SDL 1.2 should be considered
> as deprecated.
> 
> Please switch the dependency to SDL 2, the configure script should detect
> it automatically.

Thanks for the report. We will update the package after Debian 10
"Buster" was released and switch to SDL 2.

Best,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#931083: [Debian-ha-maintainers] Bug#931083: ocfs2-tools FTCBFS: broken, outdated, embedded copies of PKG_PROG_PKG_CONFIG and AM_PATH_GLIB_2_0

[Valentin Vidić]

On Tue, Jun 25, 2019 at 08:03:07PM +0200, Helmut Grohne wrote:
> Source: ocfs2-tools
> Version: 1.8.5-7
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> ocfs2-tools fails to cross build from source, because it uses broken,
> outdated, embedded copies of PKG_PROG_PKG_CONFIG and AM_PATH_GLIB_2_0.
> Please remove these copies. Alternatively, please update and register
> them with the security tracker. This bug report comes without a patch,
> because it is already fixed in pkg-config and glib2.0 respectively.
> ocfs2-tools just happens to have a copy of the bug.

Thanks for the report. Can you perhaps check if the attached patch helps
with the cross build of the package?

-- 
Valentin
--- a/aclocal.m4
+++ /dev/null
@@ -1,7 +0,0 @@
-m4_include([pkg.m4])
-m4_include([glib-2.0.m4])
-m4_include([runlog.m4])
-m4_include([python.m4])
-m4_include([pythondev.m4])
-m4_include([blkid.m4])
-m4_include([mbvendor.m4])
--- /dev/null
+++ b/acinclude.m4
@@ -0,0 +1,3 @@
+m4_include([pythondev.m4])
+m4_include([blkid.m4])
+m4_include([mbvendor.m4])
--- a/pythondev.m4
+++ b/pythondev.m4
@@ -8,8 +8,8 @@
 [AC_REQUIRE([AM_PATH_PYTHON])
 AC_MSG_CHECKING(for headers required to compile python extensions)
 dnl deduce PYTHON_INCLUDES
-py_prefix=`$PYTHON -c "import sys; print sys.prefix"`
-py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"`
+py_prefix=`$PYTHON -c "import sys; print(sys.prefix)"`
+py_exec_prefix=`$PYTHON -c "import sys; print(sys.exec_prefix)"`
 PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
 if test "$py_prefix" != "$py_exec_prefix"; then
   PYTHON_INCLUDES="$PYTHON_INCLUDES -I${py_exec_prefix}/include/python${PYTHON_VERSION}"

Bug#800518: ITA: 9base -- Plan 9 userland tools

[Boyuan Yang]

在 2019-06-25二的 19:18 -0400，Elliott Pardee写道：
> Understood, is there anything else I need to do besides making the guest 
> account on Salsa?

The most important part is to prepare the proper packaging source code and
make sure it's working well -- either in a git repo on salsa.debian.org or
using the traditional method on mentors.debian.net -- after that, contact an
available Debian Developer for review and package upload sponsorship. Reading
the old intro page https://mentors.debian.net/intro-maintainers might be
benificial.

Regards,
Boyuan Yang


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

Bug#931091: Search in older tags pages of github for --download-version or --download-current-version

[Pirate Praveen]

Package: devscripts
Severity: wishlist

Currently only one page of tags is checked by uscan. For many fast moving 
projects sometimes we want an older tag (for example when there is a lot of 
alpha, beta or rc releases, we may need the last stable release). We end up 
having to manually download the tarball. Please add an option or even better by 
default search in older tags for --download-version or 
--download-current-version  options.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#931090: xserver-xorg: After login the screen flashes and becomes dark

[Gabor Nagy]

Package: xserver-xorg
Version: 1:7.7+19
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Maybe I have updated some packages recently. Today when I started my
laptop, it behaved like this.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

After boot, I can see sddm. I enter my login information, and where I
should see my desktop, I see a blank black screen.
If I switch to console by pressing ctrl-alt-1, I can see the login
prompt there. If I switch back to X using alt-7, I can see my KDE
desktop.
I noticed that if I use konsole, the graphical interface appears to be
stable. If I start Chrome and try to watch a Youtube video, there are
black flashes. Often after some flashes I can see Chrome and the video
plays, but in some cases it remains blank, and I need to switch to
console and back again.

   * What outcome did you expect instead?

I expected to see my KDE desktop after logging in, and I expected to be
able to watch a Youtube video using Chrome without any problem.

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


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

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of 

Bug#926633: FutureWarning: Possible nested set at position 1

[John Scott]

Control: reassign -1 gdebi-core

> Tags: l10n
This happens to me on my plain en-US system when saying no. The locale might 
not have anything to do with it.

Do you want to install the software package? [y/N]:n 
/usr/bin/gdebi:113: FutureWarning: Possible nested set at position 1
  c = findall("[[(](\S+)/\S+[])]", msg)[0].lower()

Bug#902343: osifont

[Kurt Kremitzki]

Hi Gürkan,

On 6/25/19 3:38 AM, Gürkan Myczko wrote:
> Hi Kurt and Martin
> 
> Kurt: please go ahead. How's progress? haven't found it on salsa.d.o? If
> you're on irc, there's #debian-fonts
> 
> Martin: I don't think it's similar at all, so I don't see any objections
> to have that ISO standardized isofont
> in Debian.
> 
> Cheers,

I haven't worked on it lately; the last time I did, I was looking for a
good reference package to learn more about fonts packaging in Debian.
Thanks for the IRC reference, I'll lurk there for a while and ask when I
get a chance to return to working on this.

Also, I'm currently in the application process to become a DD, so once I
can upload this package myself, I'll be more likely to put some effort
into it.

Bug#800518: ITA: 9base -- Plan 9 userland tools

[Elliott Pardee]

Understood, is there anything else I need to do besides making the guest 
account on Salsa?


Warm regards,
Elliott Pardee

On 6/25/2019 2:53 p. m., Boyuan Yang wrote:

On Mon, 24 Jun 2019 05:19:02 + Elliott Pardee  wrote:

I'd like to try my hand at this. Get my toes wet in maintaining packages. :)

Advice appreciated!


My advice: take a look at all the existing work at both the h
ttps://salsa.debian.org/debian/9base and the upstream development repo. Let me
know if you need write permission to the repository on Salsa or package upload
review/sponsorship.

Regards,
Boyuan Yang

Bug#754513: CFP - Thailand International Conference - July 2019

[Stefania Wilson]

Dear Friends,


We would like to invite you to submit research article in the 9th Joint 
International Conference organised by Institute of Research Engineers and 
Doctors at Bangkok, Thailand. The theme for the 2019 Thailand conference is to 
bring together innovative academics and industrial experts to a common forum. 
We would be delighted to have you present at this conference to hear what the 
technology experts and researchers have to share about the technology 
advancements and their impact on our daily lives.


Joint International Conference Consists of following tracks:




Track 1: 9th International Conference on Advances in Computing, Electronics and 
Communication - ACEC


Official Website: www.acec.theired.org




Track 2: 9th International Conference On Advances in Civil, Structural and 
Environmental Engineering - ACSEE


Official Website: www.acsee.theired.org




Track 3: 9th International Conference On Advances in Mechanical and Robotics 
Engineering - AMRE


Official Website: www.amre.theired.org




Track 4: 9th International Conference On Advances in Social Science, Management 
and Human Behaviour - SMHB


Official Website: www.smhb.theired.org


Conference Venue: Hotel Lebua at State Tower, Bangkok, Thailand


Conference Date: 13 - 14 September 2019


Abstract/ Full Paper Submission For Review: 14 July 2019




About Publication:

All the registered papers will proudly be published by IRED-CPS and stored in 
the SEEK digital Library 

(www.seekdl.org). Each Paper will be assigned DOI (Digital Object Identifier) 
from CROSSREF. The Proc. will be submitted to ISI Thomson for Review and 
Indexing. Proc. will also be published in International Journals with ISSN 
Numbers.


Remote Presentation via Skype can also be arranged.


We would also like to share some conference photographs of previous held 
International conference that has been worldwide.


Kindly refer to the below link to access the conference photographs.




https://gallery.theired.org/previous-conferences/



We Request you to forward this email to your colleagues/Researchers/students in 
order to promote the conference.


The aim of the conference is to provide a platform to the researchers and 
practitioners from both academia as well as industry to meet and share 
cutting-edge development in the field.
Please take the time to explore the website for more details, check on 
important dates, and keep yourself up to date on recent changes. 



Registered Papers (IRED Extended paper guidelines applicable) will be published 
in the various issues of International journals.
Prospective authors are invited to submit full (original) research papers; 
which are NOT submitted or published or under consideration anywhere in other 
conferences or journals; in electronic format via email. 




Thanks Much 
Stefania 

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Barry Arndt]

A few things:
 
I verified that this problem does not recreate on buster, as Ryan 
mentioned earlier, because of the disabling of lock elision in glibc.
 
I verified that this problem still exists on a Debian 9.8 base with 
upstream kernel 5.1.0-x, which contains up-to-date TM fixes.
 
Our kernel team is actively debugging this problem on upstream kernel 
5.2.0-rc5, and is in favor of disabling TM in Debian until this issue is 
resolved.
 
Thanks.
Barry

Bug#930988: libtifiles FTCBFS: Missing dependency tfdocgen

[Lionel Debroux]

Hi Helmut,

On 25/06/2019 19:39, Helmut Grohne wrote:
> On Tue, Jun 25, 2019 at 09:43:24AM +0200, Lionel Debroux wrote:
> > tfdocgen is a simple HTML documentation generator, which supports a
> > Doxygen-like (but not Doxygen-compatible) syntax for C/C++ code, and
> > maybe other languages which supports /** */ comments, I haven't
> > tried. It was written by the previous maintainer over a decade ago,
> > I have barely modified it. The files it produces are packaged in the
> > -dev packages.
>
> Thank you for chiming in. So do you confirm that tfdocgen consumes
> only textual formats (source code with comment markup) and produces
> only textual formats (html) and that the behaviour and output is
> independent of the processor architecture being executed on?
Yes, yes and yes.
In Git HEAD, tfdocgen.c is a 600+ RLOC file, which can build with GCC
-std=gnu89 CFLAG (it uses C++-style // comments), and only depends on
the standard library + Glib. From a fairly cursory glance, I don't see
obvious portability issues in the code: no occurrence of "long" as a
data type, no usage of &, |, ^, << and >> operators indicating
(de)serialization and bit arithmetic.

In the 11-year-old 1.0 version packaged by Debian, this holds as well,
but several minor fixes of mine, the latest one from 2015, are missing.
I, uh, haven't produced a release of tfdocgen myself, so I'm the one to
blame for the fact distros are using an older version :)
I suppose I should produce one as part of the next release cycle,
hopefully by the end of the year. I should soon be down to two
significant items left on the todo list, but adding support for a 4th
calc <-> computer communication protocol is nontrivial work.


Bye,
Lionel.

Bug#931089: ITP: ocaml-ffmpeg -- OCaml interface for FFmpeg

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 

* Package name: ocaml-ffmpeg
  Version : 0.2.1
  Upstream Author : Savonet Team 
* URL : https://github.com/savonet/ocaml-ffmpeg
* License : LGPL
  Programming Lang: OCaml
  Description : OCaml interface for FFmpeg

The modules currently available are:

Av: the module containing demuxers and muxers for reading and writing
multimedia container formats.

Avcodec: the module containing decoders and encoders for audio, video and
subtitle codecs.

Swresample: the module performing audio resampling, rematrixing and sample
format conversion operations.

Swscale: the module performing image scaling and color space/pixel format
conversion operations.

Avdevice: the module containing input and output devices for grabbing from
and rendering to many common multimedia input/output software frameworks.

This is a dependency of the new version of Liquidsoap and will be
maintained as part of the Ocaml Maintainers team.

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Michael Biebl]

Control: severity -1 important

Hi Raphael

On Wed, 19 Jun 2019 22:33:21 +0200 Michael Biebl  wrote:
> Hi Raphael,
> 
> On Tue, 11 Jun 2019 15:51:14 +0200 Raphael Hertzog 
> wrote:
> > Hi,
> > 
> > On Wed, 05 Jun 2019, Michael Biebl wrote:
> > > systemd-networkd.service in v241 is locked down more tightly then v232.
> > > It might be worth a try to comment out the hardening features one by one
> > > to see if one of them causes your problem.
> > 
> > Thanks for the idea! I tried that but it did not help. I found the issue
> > after a few more tries tweaking the network configuration file. It's
> > simply that the system has IPv6 disabled in the kernel policy while the
> > .network file instructs to configure an IPv6 address.
> > 
> > Both are contradictory but they happily lived together up-to-now.
> > I don't know what changed but if we don't improve systemd-networkd
> > to just skip IPv6 configuration when the kernel has a policy disabling
> > IPv6, then we will have plenty of servers broken on upgrades because
> > it's quite common to keep the network configuration file provided by
> > the hoster and just disable IPv6 at the kernel level with sysctl:
> > 
> > $ grep ipv6 /etc/sysctl.conf
> > # Disable ipv6
> > net.ipv6.conf.all.disable_ipv6 = 1
> > net.ipv6.conf.default.disable_ipv6 = 1
> > net.ipv6.conf.lo.disable_ipv6 = 1
> 
> Ok, thanks for figuring out the root cause.
> Given that this only happens under very special circumstances and
> networkd not being enabled by default, I'm not entirely sure if this
> issue should qualify as RC.
> Cherry-picking the 6 upstream commits leads to a merge conflict when
> applied on top of v241 and I haven't yet investigated if those can
> easily be resolved.
> TBH, I feel a bit uneasy doing this change so late in the release cycle
> and personally I would downgrade this issue to non-RC and fix this via a
> v243 upload to buster-backports.
> 
> If you feel strongly about this though, please feel free ask the release
> team if the change is ok. A tested patch set would be great in this case.

I haven't heard back from you and my current gut feeling is that this
issue is not RC, so I'm downgrading it to important.
I'm open to be persuaded otherwise though.

Whether we are going to fix this via a stable point release or
stretch-backports remains to be decided. The latter is easier for me, as
it doesn't mean all the administrative overhead of a stable upload.


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#929730: systemd: boot-and-services test expects first kernel log line, but not always in logs

[Michael Biebl]

Am 25.06.19 um 22:51 schrieb Michael Biebl:
> Dan, could you submit your patch as merge request?

Btw, we use gbp-dch style commit messages.

E.g. Debian bugs are closed by adding a

Closes: #929730

line to the git commit message.

http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/man.gbp.dch.html
-- 
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#930652: systemd removes static ipv4 address from ethernet sporadically

[Michael Biebl]

Control: reassign -1 ifupdown

Am 25.06.19 um 22:47 schrieb Joshua Hudson:
> I have attached a copy of /etc/network/interfaces. We're now waiting
> for another recurrence.
> 

/etc/network/interfaces is not a systemd config file, so it seems your
network interface is managed by ifupdown.
So I'm reassigning this to ifupdown. Hopefully the maintainers can help
you further.
It would be a good idea if you attach the output of
reportbug --template ifupdown

to the bug report.

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#929730: systemd: boot-and-services test expects first kernel log line, but not always in logs

[Michael Biebl]

On Wed, 5 Jun 2019 13:04:50 +0200 Michael Biebl  wrote:
> Am 29.05.19 um 18:49 schrieb Dan Streetman:
> > On Wed, May 29, 2019 at 12:35 PM Michael Biebl  wrote:
> >>
> >> Am 29.05.19 um 18:19 schrieb Dan Streetman:
> >>> Package: systemd
> >>> Version: 241-5
> >>> Severity: normal
> >>> Tags: patch
> >>> User: ubuntu-de...@lists.ubuntu.com
> >>> Usertags: origin-ubuntu eoan ubuntu-patch
> >>>
> >>> Dear Maintainer,
> >>>
> >>> boot-and-services test expects the first(ish) kernel log line to be in 
> >>> the system logs, but that is not guaranteed to be in the logs.
> >>>
> >>> -- Package-specific info:
> >>>
> >>>
> >>>   * d/t/boot-and-services:
> >>> - don't fail if some kernel msgs are missed (LP: #1830479)
> >>
> >>
> >> Afair, this is due to the kernel ring buffer being too small (on arm64)
> >> Wouldn't it be better to address that? After all, you also want early
> >> boot messages when running systemd in production.
> > 
> > that's one reason; is systemd missing kernel messages due to no fault
> > of its own really something that should fail the test case?

I guess I agree here. The purpose of the test is not to check if the
kernel ring buffer is setup appropriately.

> Good question. Since Martin is our autopkgtest expert, it's probably
> best to wait for his reply here.
> 
> Again, if you submit a MR via salsa, you make it a bit easier for us to
> review and apply the changes.

Dan, could you submit your patch as merge request?
Martin, your feedback would also be most welcome here.

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#930652: systemd removes static ipv4 address from ethernet sporadically

[Joshua Hudson]

I have attached a copy of /etc/network/interfaces. We're now waiting
for another recurrence.


interfaces
Description: Binary data

Bug#929011: unblock: singularity-container/3.1.1+ds-1

[Afif Elghraoui]

Control: tag -1 - moreinfo

On June 25, 2019 4:16:17 PM EDT, Salvatore Bonaccorso  wrote:
>Hi Paul, hi Afif,
>
[...]
>> 
>> Your proposed changes very much do not align with the freeze policy,
>so
>> you're asking for an exception for a new upstream release. This
>package
>> is currently listed to be auto-removed due to docker.io, so I am not
>> going to review it now. docker.io is a major concern for the
>> security-team so that needs to be resolved first. If that gets
>resolved
>> in a timely manner, i.e. before it is auto-removed, please ping this
>bug
>> (e.g. by removing the moreinfo bug).
>
>I do agree that the changes are not really reviewable given the size
>of the diff. But with Afifs argument and now the package not beeing
>marked as autoremoved: if we want to support singularity-container
>security wise in buster we would need to bite into the apple and
>accept this late new version bump for buster as the 3.1 version.
>
>So I think the two options we have is (in order of preference): 1.
>unblock singularity-container and let the 3.1 based version in to
>buster, or 2. remove singularity-container from buster.
>
>Cc'in team@s.d.o for further comments.
>

Thanks, Salvatore. I'm removing the moreinfo tag as Paul said to do since the 
autoremoval warning has been lifted.

regards
Afif

Bug#929363: enigmail: CVE-2019-12269

[Moritz Mühlenhoff]

On Fri, May 24, 2019 at 09:49:54AM +0200, Salvatore Bonaccorso wrote:
> Source: enigmail
> Source-Version: 2:2.0.11+ds1-1
> 
> On Wed, May 22, 2019 at 02:25:42PM +0200, Salvatore Bonaccorso wrote:
> > Source: enigmail
> > Version: 2:2.0.10+ds1-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://sourceforge.net/p/enigmail/bugs/983/
> > 
> > Hi,
> > 
> > The following vulnerability was published for enigmail.
> > 
> > CVE-2019-12269[0]:
> > | Enigmail before 2.0.11 allows PGP signature spoofing: for an inline
> > | PGP message, an attacker can cause the product to display a "correctly
> > | signed" message indication, but display different unauthenticated
> > | text.
> 
> This issue was adressed 2.0.11 upstream, closing manually.

Buster still has 2.0.10, what's the plan for it (and for stretch),
should we fix this in older releases?

Cheers,
Moritz

Bug#931088: CVE-2019-12481 CVE-2019-12482 CVE-2019-12483

[Moritz Muehlenhoff]

Package: gpac
Version: 0.5.2-426-gc5ad4e4+dfsg5-5
Severity: important
Tags: security

Please see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12481
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12482
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12483

For all three of them:
https://github.com/gpac/gpac/issues/1249
https://github.com/gpac/gpac/commit/f40aaaf959d4d1f7fa0dcd04c0666592e615c8f1

Cheers,
Moritz

Bug#931087: fdisk/sfdisk: creates scripts that don't work

[Matthias Urlichs]

Package: fdisk
Version: 2.33.1-0.1
Severity: important

I have created a GPT-partitioned image where the first partition
needs to start at block 64. The problem is that fdisk/sfdisk is unable to
replicate this partition layout using an sfdisk script, because the
generated script doesn't work when it's read back in.

This seems to be a problem with interpreting the "table-length" value.
It appears to be multiplied by 4 instead of divided by 4 when checking
sector limits.

# ls -l /tmp/bmb_root
-rw-r--r-- 1 smurf smurf 1170228224 Jun 25 22:16 /tmp/bmb_root
# bc
bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free 
Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
1170228224/512-34
2285568

# cat /tmp/lb  ### minimum/maximum working LBA values
label: gpt
label-id: 3C0E3DAC-3069-354E-BA0E-CB74029F5A5C
device: /tmp/bmb_root
unit: sectors
table-length: 8
first-lba: 34
last-lba: 2285568

# sfdisk /tmp/bmb_root 

Bug#929011: unblock: singularity-container/3.1.1+ds-1

[Salvatore Bonaccorso]

Hi Paul, hi Afif,

On Sat, Jun 08, 2019 at 09:26:06PM +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Afif,
> 
> On Wed, 15 May 2019 03:47:28 -0400 Afif Elghraoui  wrote:
> > Please unblock package singularity-container/3.1.1+ds-1
> > 
> > This package is prone to security vulnerabilities. Upstream provides
> > long-term support for selected versions to their paid users, but also
> > releases all code changes (including backported security patches) to the
> > community.
> > 
> > Both 3.0.x and 3.1.x were released earlier this year and it was not
> > known at the time which of these would be the LTS version. 3.0.3 is what
> > I bet on and what is in Testing now, but it now turns out that I was
> > wrong and it's actually 3.1. Using it would greatly facilitate our
> > ability to provide support over the lifetime of Buster.
> > 
> > The benefits of doing this have also just been clearly demonstrated:
> > Upstream just released 3.2.0, adding new features as well as fixing
> > security issues affecting versions 3.1.0 and up, but because 3.1 is
> > under LTS support for their paid users, they also provided the security
> > patches backported to 3.1 (see the 3.2.0 release notes -
> > https://github.com/sylabs/singularity/releases/tag/v3.2.0 ).
> > 
> > So I apologize for the large diff, but I think we'd be in much better
> > shape having this upstream version in Buster. Especially because of the
> > large diff, backporting patches to 3.0 without the help from upstream
> > that we'd get by using 3.1 would be unnecessarily more burdensome.
> > 
> > many thanks for your time and consideration
> 
> Your proposed changes very much do not align with the freeze policy, so
> you're asking for an exception for a new upstream release. This package
> is currently listed to be auto-removed due to docker.io, so I am not
> going to review it now. docker.io is a major concern for the
> security-team so that needs to be resolved first. If that gets resolved
> in a timely manner, i.e. before it is auto-removed, please ping this bug
> (e.g. by removing the moreinfo bug).

I do agree that the changes are not really reviewable given the size
of the diff. But with Afifs argument and now the package not beeing
marked as autoremoved: if we want to support singularity-container
security wise in buster we would need to bite into the apple and
accept this late new version bump for buster as the 3.1 version.

So I think the two options we have is (in order of preference): 1.
unblock singularity-container and let the 3.1 based version in to
buster, or 2. remove singularity-container from buster.

Cc'in team@s.d.o for further comments.

Regards,
Salvatore

Bug#931086: bro/2.5.5-1+deb10u1 buster upload?

[Hilko Bengen]

Package: release.debian.org
Severity: normal

bro/2.5.5-1 (unstable, testing) is affected by CVE-2018-16807,
CVE-2018-17019 (#908614, #908779) and bro/2.6.1+ds1-1 is still sitting
in NEW.

May I upload bro/2.5.5-1+deb10u1 to buster?

I have attached a debdiff.

Cheers,
-Hilko

diff -Nru bro-2.5.5/debian/changelog bro-2.5.5/debian/changelog
--- bro-2.5.5/debian/changelog	2019-06-25 21:26:53.0 +0200
+++ bro-2.5.5/debian/changelog	2018-09-05 16:05:40.0 +0200
@@ -1,10 +1,3 @@
-bro (2.5.5-1+deb10u1) buster; urgency=medium
-
-  * Add patches for CVE-2018-16807, CVE-2018-17019 (Closes: #908614,
-#908779)
-
- -- Hilko Bengen   Tue, 25 Jun 2019 21:26:53 +0200
-
 bro (2.5.5-1) unstable; urgency=medium
 
   * New upstream version 2.5.5
diff -Nru bro-2.5.5/debian/patches/0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch bro-2.5.5/debian/patches/0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch
--- bro-2.5.5/debian/patches/0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch	2019-06-25 21:26:53.0 +0200
+++ bro-2.5.5/debian/patches/0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch	1970-01-01 01:00:00.0 +0100
@@ -1,38 +0,0 @@
-From: Jon Siwek 
-Date: Mon, 10 Sep 2018 18:06:07 -0500
-Subject: Fix potential memory leak in Kerberos scripts
-
-Reported by Maksim Shudrak.
-

-
-Stripped files:
- testing/btest/Traces/krb/optional-service-name.pcap
- testing/btest/core/leaks/krb-service-name.test
-

-
-diff --git a/scripts/base/protocols/krb/main.bro b/scripts/base/protocols/krb/main.bro
-index 02abced..9621378 100644
 a/scripts/base/protocols/krb/main.bro
-+++ b/scripts/base/protocols/krb/main.bro
-@@ -140,7 +140,8 @@ event krb_as_request(c: connection, msg: KDC_Request) =5
- 
- 	c$krb$request_type = "AS";
- 	c$krb$client   = fmt("%s/%s", msg?$client_name ? msg$client_name : "", msg$service_realm);
--	c$krb$service  = msg$service_name;
-+	if ( msg?$service_name )
-+		c$krb$service  = msg$service_name;
- 
- 	if ( msg?$from )
- 		c$krb$from = msg$from;
-@@ -183,7 +184,8 @@ event krb_tgs_request(c: connection, msg: KDC_Request) =5
- 		return;
- 
- 	c$krb$request_type = "TGS";
--	c$krb$service = msg$service_name;
-+	if ( msg?$service_name )
-+		c$krb$service = msg$service_name;
- 	if ( msg?$from ) 
- 		c$krb$from = msg$from;
- 	c$krb$till = msg$till;
diff -Nru bro-2.5.5/debian/patches/0007-Fix-IRC-names-command-parsing.patch bro-2.5.5/debian/patches/0007-Fix-IRC-names-command-parsing.patch
--- bro-2.5.5/debian/patches/0007-Fix-IRC-names-command-parsing.patch	2019-06-25 21:24:57.0 +0200
+++ bro-2.5.5/debian/patches/0007-Fix-IRC-names-command-parsing.patch	1970-01-01 01:00:00.0 +0100
@@ -1,35 +0,0 @@
-From: Jon Siwek 
-Date: Wed, 12 Sep 2018 19:47:57 -0500
-Subject: Fix IRC names command parsing
-

-
-Stripped files:
- testing/btest/Traces/irc-353.pcap
- testing/btest/scripts/base/protocols/irc/names-weird.bro
- testing/btest/Baseline/scripts.base.protocols.irc.names-weird/weird.log
-

-
-diff --git a/src/analyzer/protocol/irc/IRC.cc b/src/analyzer/protocol/irc/IRC.cc
-index a26045f..de8846c 100644
 a/src/analyzer/protocol/irc/IRC.cc
-+++ b/src/analyzer/protocol/irc/IRC.cc
-@@ -252,14 +252,15 @@ void IRC_Analyzer::DeliverStream(int length, const u_char* line, bool orig)
- 			{
- 			vector parts = SplitWords(params, ' ');
- 
--			// Remove nick name.
--			parts.erase(parts.begin());
--			if ( parts.size() < 2 )
-+			if ( parts.size() < 3 )
- {
- Weird("irc_invalid_names_line");
- return;
- }
- 
-+			// Remove nick name.
-+			parts.erase(parts.begin());
-+
- 			string type = parts[0];
- 			string channel = parts[1];
diff -Nru bro-2.5.5/debian/patches/series bro-2.5.5/debian/patches/series
--- bro-2.5.5/debian/patches/series	2019-05-11 00:56:50.0 +0200
+++ bro-2.5.5/debian/patches/series	2018-06-17 12:44:48.0 +0200
@@ -3,5 +3,3 @@
 0003-Fix-btest-paths.patch
 0004-Port-most-of-bro-to-OpenSSL-1.1.patch
 0005-Disable-OCSP-features-that-can-t-yet-be-ported-to-Op.patch
-0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch
-0007-Fix-IRC-names-command-parsing.patch

Bug#929011: unblock: singularity-container/3.1.1+ds-1

[Ansgar]

Control: tag -1 - moreinfo

Paul Gevers writes:
> On Wed, 15 May 2019 03:47:28 -0400 Afif Elghraoui  wrote:
>> Please unblock package singularity-container/3.1.1+ds-1
>> 
>> This package is prone to security vulnerabilities. Upstream provides
>> long-term support for selected versions to their paid users, but also
>> releases all code changes (including backported security patches) to the
>> community.
>> 
>> Both 3.0.x and 3.1.x were released earlier this year and it was not
>> known at the time which of these would be the LTS version. 3.0.3 is what
>> I bet on and what is in Testing now, but it now turns out that I was
>> wrong and it's actually 3.1. Using it would greatly facilitate our
>> ability to provide support over the lifetime of Buster.
>> 
>> The benefits of doing this have also just been clearly demonstrated:
>> Upstream just released 3.2.0, adding new features as well as fixing
>> security issues affecting versions 3.1.0 and up, but because 3.1 is
>> under LTS support for their paid users, they also provided the security
>> patches backported to 3.1 (see the 3.2.0 release notes -
>> https://github.com/sylabs/singularity/releases/tag/v3.2.0 ).
>> 
>> So I apologize for the large diff, but I think we'd be in much better
>> shape having this upstream version in Buster. Especially because of the
>> large diff, backporting patches to 3.0 without the help from upstream
>> that we'd get by using 3.1 would be unnecessarily more burdensome.
>> 
>> many thanks for your time and consideration
>
> Your proposed changes very much do not align with the freeze policy, so
> you're asking for an exception for a new upstream release. This package
> is currently listed to be auto-removed due to docker.io, so I am not
> going to review it now. docker.io is a major concern for the
> security-team so that needs to be resolved first. If that gets resolved
> in a timely manner, i.e. before it is auto-removed, please ping this bug
> (e.g. by removing the moreinfo bug).

I've removed the moreinfo tag as docker.io was unblocked.

Ansgar

Bug#800518: ITA: 9base -- Plan 9 userland tools

[Boyuan Yang]

On Mon, 24 Jun 2019 05:19:02 + Elliott Pardee  wrote:
> I'd like to try my hand at this. Get my toes wet in maintaining packages. :)
> 
> Advice appreciated!


My advice: take a look at all the existing work at both the h
ttps://salsa.debian.org/debian/9base and the upstream development repo. Let me
know if you need write permission to the repository on Salsa or package upload
review/sponsorship.

Regards,
Boyuan Yang


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

Bug#931085: mailavenger: drops TCP immediately after receiving 'QUIT', without sending the 221 response

[Philip Hands]

Package: mailavenger
Version: 0.8.5-1
Severity: normal

Hi Dererk,

It seems that mailavenger does not actually send the '221 {hostname}' message
that it is supposed to (despite showing it doing so in its debugging output).

This appears to make some SMTP clients decide that the email was not sent
(despite having received the '250 ok' after the data, resulting in them
sending the same mail repeatedly.

One can easily confirm this with swaks, thus:

  swaks --from h...@example.com --to th...@example.com --server=my.avenger.host

Which will give you a result which ends with something like this:

=-=-=-=-
...
 -> This is a test mailing
 -> 
 -> 
 -> .
<-  250 ok
 -> QUIT
*** Remote host closed connection unexpectedly.
=-=-=-=-

The thing that makes this "unexpected" is that the 221 response is missing.

This would seem to be because the IO is not being flushed when the socket
is closed.  This can be fixed by adding a flush, as you can see in this
git branch:

  https://salsa.debian.org/philh/mailavenger/tree/premature-close-bug-fixed

Specifically in this patch file:

  
https://salsa.debian.org/philh/mailavenger/blob/premature-close-bug-fixed/debian/patches/flush-aio-to-force-sending-of-farewell-p.patch

(I've attached that patch to this report, just for completeness)

It would not surprise me if there's a better way to do this, but this
does at least work.  The reason I suspect that there's a better way is
that presumably there are other places where the connection is being
dropped with unsent messages in the buffers, so it probably ought to be
fixed in the code responsible for bringing the connection down.

The result of building with this patch is currently running on my smtp
server, so one can demonstrate the correct behaviour that this results
in with telnet, thus:

=-=-=-=-
phil@whist  ~ % telnet mail.hands.com 25
Trying 78.129.164.123...
Connected to mail.hands.com.
Escape character is '^]'.
220 free.hands.com ESMTP
quit
221 free.hands.com
Connection closed by foreign host.
=-=-=-=-

Note the line "221 free.hands.com" -- this line is missing when running the 
0.8.5-1 version.

BTW also in that salsa repo, I've added a configuration to run salsa-CI,
as well as the beginnings of an autopkgtest test.  The autopkgtest does
work when run locally, but seems not to work within docker as in the
salsa-CI setup, presumably because networking is different within the
container -- I'll fix that if I can work out what's up.

The following system information is from my laptop, which exhibits the
same symptoms as the server, but may well have more recent packages.
Feel free to ask for the info from the server if you think it's important.

Cheers, Phil.

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

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

Versions of packages mailavenger depends on:
ii  adduser 3.118
ii  dma [mail-transport-agent]  0.11-1+b1
ii  libc6   2.28-10
ii  libdb5.35.3.28+dfsg1-0.5
ii  libgcc1 1:8.3.0-6
ii  libpcap0.8  1.8.1-6
ii  libssl1.1   1.1.1c-1
ii  libstdc++6  8.3.0-6
ii  lsb-base10.2019051400

mailavenger recommends no packages.

mailavenger suggests no packages.

-- no debconf information
From: Philip Hands 
Date: Tue, 25 Jun 2019 12:32:00 +0200
X-Dgit-Generated: 0.8.5-1.1~hands1 aeafef4798f48117120eb6e9eef9d11c77ee2dfb
Subject: flush aio, to force sending of farewell packet

I suspect that there's a better way to do this, as it seems
to me that the library should know to flush all IO when the
socket is closed.  However this is a trivial change, and it
does work.

---

--- mailavenger-0.8.5.orig/asmtpd/smtpd.C
+++ mailavenger-0.8.5/asmtpd/smtpd.C
@@ -889,6 +889,7 @@ smtpd::getcmd (str line, int err)
   }
   else if (cmd == "quit") {
 aio << "221 " << opt->hostname << "\r\n";
+aio->flush ();
 delete this;
   }
   else if (cmd == "noop")

Bug#930664: ITP: libcamera/0~190601-1

[Andrej Shadura]

On Wed, 19 Jun 2019 10:38:39 -0300 "eamanu15 ."
 wrote:
> > hi.
> > i haven't looked into your packaging yet, but...
> >
> > - i'm interested in sponsoring the package
> >
> Great!

I am too interested in sponsoring :)

> - would you consider maintaining the package under the multimedia-team
> > umbrella?
> >
> 
> It would be great. I think I will need to ask for permission to
> multimedia-team. I will send a mail :-)

I have added you to the salsa project. I have create a repo and will
push a cleaned up version of your work for you to have a look at.

> > - last time i checked libcamera it wasn't really usable. do you know
> > anything about the timeframe for a first upstream release? (i haven't
> > really followed any discussion)

> I think is usable for test. Maybe we will be start with a experimental
> release for Debian? (Not unstable).
> 
> I open the discussion for a release, but the developers don't feel that
> libcamera is ready for a first release yet.  I will contact them for new
> news.

Probably uploading to experimental first is a good idea.

-- 
Cheers,
  Andrej

Bug#931084: unblock: netdata/1.12.2-2

[Daniel Baumann]

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

Please unblock package netdata.

First, I'm sorry.. I'm terribly late with this and there's no excuse for
that.

Second, I seem to have miscalculated the
'last-possible-point-in-time-to-upload-to-unstable-and-migrate-to-testing-before-full-freeze'
by one hour on 2019-02-27. so netdata 1.12.2-2 which was supposed to be
the one for buster just didn't make it in time into testing before the
freeze on 2019-03-12. If I didn't make that mistake, netdata 1.12-2-2
would have migrated on its own.

Now, netdata 1.12.0-1..1.12.2-2 fixes two important things:

a) the web frontend as well as the documentation has been fixed to not
   spy on its users (via googleanalytics).

b) opt-out to send telemetry to upstream

Preferably, netdata 1.12.2-2 could be allowed to migrate to testing. If
that's not possible, both should be fixed through stable updates for
buster r1 which I'd like to avoid the extra-work for everyone.

Would you mind allow netdata to migrate at this point?

(debdiff of debian/ is attached)

Regards,
Daniel
diff -Naurp debian_1.12.0-1/changelog debian_1.12.2-2/changelog
--- debian_1.12.0-1/changelog	2019-06-25 20:27:42.597478366 +0200
+++ debian_1.12.2-2/changelog	2019-06-25 20:28:01.646098056 +0200
@@ -1,3 +1,47 @@
+netdata (1.12.2-2) unstable; urgency=medium
+
+  [ Federico Ceratto ]
+  * Add patch to remove Sign In button
+
+  [ Daniel Baumann ]
+  * When disabling the 'Sign In' button on the right side, only turn it
+off in the javascript and keep the html unmodified.
+  * Sorting patch series.
+
+ -- Daniel Baumann   Sat, 02 Mar 2019 16:46:44 +0100
+
+netdata (1.12.2-1) unstable; urgency=medium
+
+  * Merging upstream version 1.12.2.
+
+ -- Daniel Baumann   Thu, 28 Feb 2019 22:18:45 +0100
+
+netdata (1.12.1-2) unstable; urgency=medium
+
+  * Downgrading nodejs depends in netdata-plugins-nodejs to recommends as
+not all architectures have nodejs at the moment.
+
+ -- Daniel Baumann   Wed, 27 Feb 2019 22:09:05 +0100
+
+netdata (1.12.1-1) unstable; urgency=medium
+
+  [ Lennart Weller ]
+  * Add patch to remove Google Analytics from generated docs
+
+  [ Daniel Baumann ]
+  * Rediffing remove-googleanalytics.patch.
+  * Opting out by default from sending anonymous statistics (Closes: #923114).
+  * Merging upstream version 1.12.1.
+  * Refreshing remove-googleanalytics.patch for new upstream version.
+  * Updating lintian overrides.
+  * Removing currently usless depends on bash as it's still an essential
+package.
+  * Adding missing GPL-3-only license stanza in copyright file.
+  * Debranding license references in copyright.
+  * Updating TODO file.
+
+ -- Daniel Baumann   Sun, 24 Feb 2019 21:32:56 +0100
+
 netdata (1.12.0-1) unstable; urgency=medium
 
   * Merging upstream version 1.12.0.
diff -Naurp debian_1.12.0-1/control debian_1.12.2-2/control
--- debian_1.12.0-1/control	2019-06-25 20:27:42.597478366 +0200
+++ debian_1.12.2-2/control	2019-06-25 20:28:01.646098056 +0200
@@ -97,7 +97,6 @@ Section: net
 Architecture: all
 Multi-Arch: foreign
 Depends:
- bash,
  netdata-core (>= ${source:Version}) | netdata-core-no-sse (>= ${source:Version}),
  ${misc:Depends},
 Suggests:
@@ -120,8 +119,9 @@ Architecture: all
 Multi-Arch: foreign
 Depends:
  netdata-core (>= ${source:Version}) | netdata-core-no-sse (>= ${source:Version}),
- nodejs,
  ${misc:Depends},
+Recommends:
+ nodejs,
 Provides:
  netdata-plugins,
 Enhances:
diff -Naurp debian_1.12.0-1/copyright debian_1.12.2-2/copyright
--- debian_1.12.0-1/copyright	2019-06-25 20:27:42.597478366 +0200
+++ debian_1.12.2-2/copyright	2019-06-25 20:28:01.650098186 +0200
@@ -183,7 +183,7 @@ Files:
  collectors/python.d.plugin/python_modules/third_party/boinc_client.py
 Copyright: 2013 Rodrigo Silva (MestreLion) 
2017 Austin S. Hemmelgarn
-License: GPL-3.0
+License: GPL-3
 
 Files:
  collectors/python.d.plugin/python_modules/third_party/mcrcon.py
@@ -224,8 +224,8 @@ License: LGPL-3+
  You should have received a copy of the GNU Lesser General Public
  License along with this library;  If not, see .
  .
- On Debian systems, the complete text of the GNU Lesser General Public
- License version 3 can be found in /usr/share/common-licenses/LGPL-3.
+ The complete text of the GNU Lesser General Public License version 3
+ can be found in /usr/share/common-licenses/LGPL-3.
 
 License: LGPL-2.1
  This program is free software; you can redistribute it and/or modify
@@ -242,9 +242,23 @@ License: LGPL-2.1
  along with this program; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  .
- On Debian GNU/Linux systems, the complete text of the GNU Library
- General Public License, version 2, can be found in
- /usr/share/common-licenses/LGPL-2.
+ The complete text of the GNU Library General Public License, version 2,
+ can be found in 

Bug#930803: new program: runcached

[Nicolas Schier]

tags -1 + moreinfo
thanks

Hi András,

> I just wrote this script:
> https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought
> it might be a good addition to moreutils.
> 
> It caches the stdout, stderr and exit status of arbitrary commands for a
> configurable length of time, returning data from cache on subsequent
> invocations if the cache is still fresh.

thanks for your suggestion; I think it's quite an interesting idea!
And you made me curious:  which commands are you running through
'runcached'?  All programs I thought of have their basic functionality
based on side-effects as file system or network access.

> It currently has semi-esoteric dependencies: it's written in zsh and uses
> chpst from the runit package for locking. If you're willing to include the
> script I can change it to use flock(1) instead, but I'm not rewriting it in
> POSIX sh.

Adding new scripts to the moreutils collection is usually done by
forwarding to the upstream maintainer (Joey Hess ) and
asking for script inclusion.  But, as Joey keeps more than just one eye
on cross platform compatibility, I expect non-POSIX implementations to
be rejected.  Do you keep your non-POSIX statement?

Did you think about the license you want to stick it to? GPL2+?

Kind regards,
Nicolas

-- 
epost: nico...@fjasle.eu   irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature

Bug#931066: Info

[MaXaMaR]

It seems to involve mesa package.
I have recompiled radeonsi_dri.so, maybe now someone can make sense out of it.

(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5609d99fc889]
(EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) 
[0x7fe8a6ea0f8f]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (memcpy+0x2d7) [0x7fe8a6d5a387]
(EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (si_buffer_subdata+0xa4) 
[0x7fe8a5524098]
(EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (pipe_buffer_write+0x46) 
[0x7fe8a54d3233]
(EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(si_pm4_upload_indirect_buffer+0x193) [0x7fe8a54d3ac7]
(EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (si_init_config+0x775) 
[0x7fe8a54ebeab]
(EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(si_init_state_functions+0x301) [0x7fe8a54eb479]
(EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (si_create_context+0x648) 
[0x7fe8a54d0ed9]
(EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(radeonsi_screen_create_impl+0xf57) [0x7fe8a54d2d93]
(EE) 10: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(amdgpu_winsys_create+0x472) [0x7fe8a559de54]
(EE) 11: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(radeonsi_screen_create+0x71) [0x7fe8a54d2faf]
(EE) 12: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(pipe_radeonsi_create_screen+0x24) [0x7fe8a53e6a57]
(EE) 13: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(pipe_loader_drm_create_screen+0x3a) [0x7fe8a54c787c]
(EE) 14: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(pipe_loader_create_screen+0x52) [0x7fe8a54c6bd5]
(EE) 15: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (dri2_init_screen+0xcd) 
[0x7fe8a53ee2e2]
(EE) 16: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(driCreateNewScreen2+0x1ed) [0x7fe8a53e7d7e]
(EE) 17: /lib/x86_64-linux-gnu/libgbm.so.1 (gbm_format_get_name+0x189e) 
[0x7fe8a6455d0e]
(EE) 18: /lib/x86_64-linux-gnu/libgbm.so.1 (gbm_format_get_name+0x1c23) 
[0x7fe8a64563b3]
(EE) 19: /lib/x86_64-linux-gnu/libgbm.so.1 (gbm_create_device+0x57) 
[0x7fe8a64525e7]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 20: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (?+0x0) [0x7fe8a646d650]
(EE) 21: /usr/lib/xorg/Xorg (InitOutput+0xbac) [0x5609d98deb5c]
(EE) 22: /usr/lib/xorg/Xorg (InitFonts+0x1cf) [0x5609d98a17df]
(EE) 23: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) 
[0x7fe8a6cc6b6b]
(EE) 24: /usr/lib/xorg/Xorg (_start+0x2a) [0x5609d988b67a]
(EE)
(EE) Illegal instruction at address 0x7fe8a6d5a2c7

Bug#931083: ocfs2-tools FTCBFS: broken, outdated, embedded copies of PKG_PROG_PKG_CONFIG and AM_PATH_GLIB_2_0

[Helmut Grohne]

Source: ocfs2-tools
Version: 1.8.5-7
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ocfs2-tools fails to cross build from source, because it uses broken,
outdated, embedded copies of PKG_PROG_PKG_CONFIG and AM_PATH_GLIB_2_0.
Please remove these copies. Alternatively, please update and register
them with the security tracker. This bug report comes without a patch,
because it is already fixed in pkg-config and glib2.0 respectively.
ocfs2-tools just happens to have a copy of the bug.

Helmut

Bug#931043: unblock: expat/2.2.6-2

[Ivo De Decker]

Control: tags -1 d-i

Hi,

On Tue, Jun 25, 2019 at 06:59:09AM +0200, Salvatore Bonaccorso wrote:
> Please unblock package expat, it fixes CVE-2018-20843 and got fixed by
> Laszlo cherry-picking the upstream fix. The issue is tracked as
> #931031 in the BTS:
> 
> > expat (2.2.6-2) unstable; urgency=high
> > 
> >   * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
> > (closes: #931031).
> > 
> >  -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 
> > +
> 
> unblock expat/2.2.6-2

I'm fine with this, but expat has a udeb, so this needs a d-i ack. Kibi Cc's
(and diff quoted below for easy review).

Thanks,

Ivo


> diff -Nru expat-2.2.6/debian/changelog expat-2.2.6/debian/changelog
> --- expat-2.2.6/debian/changelog  2018-08-15 17:18:15.0 +0200
> +++ expat-2.2.6/debian/changelog  2019-06-24 23:18:31.0 +0200
> @@ -1,3 +1,10 @@
> +expat (2.2.6-2) unstable; urgency=high
> +
> +  * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
> +(closes: #931031).
> +
> + -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 
> +
> +
>  expat (2.2.6-1) unstable; urgency=medium
>  
>* New upstream release.
> diff -Nru 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
> --- 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  1970-01-01 01:00:00.0 +0100
> +++ 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  2019-06-24 23:18:31.0 +0200
> @@ -0,0 +1,23 @@
> +From 11f8838bf99ea0a6f0b76f9760c43704d00c4ff6 Mon Sep 17 00:00:00 2001
> +From: Sebastian Pipping 
> +Date: Wed, 12 Jun 2019 15:42:22 +0200
> +Subject: [PATCH] xmlparse.c: Fix extraction of namespace prefix from XML name
> + (#186)
> +
> +---
> + expat/lib/xmlparse.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
> +index 30d55c5c..737d7cd2 100644
> +--- a/expat/lib/xmlparse.c
>  b/expat/lib/xmlparse.c
> +@@ -6080,7 +6080,7 @@ setElementTypePrefix(XML_Parser parser, ELEMENT_TYPE 
> *elementType)
> +   else
> + poolDiscard(>pool);
> +   elementType->prefix = prefix;
> +-
> ++  break;
> + }
> +   }
> +   return 1;
> diff -Nru expat-2.2.6/debian/patches/series expat-2.2.6/debian/patches/series
> --- expat-2.2.6/debian/patches/series 1970-01-01 01:00:00.0 +0100
> +++ expat-2.2.6/debian/patches/series 2019-06-24 23:18:31.0 +0200
> @@ -0,0 +1 @@
> +Fix_extraction_of_namespace_prefix_from_XML_name.patch

Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files (was: "Re: debhelper: something in the dh sequencer changes the tIME chunk of installed PNGs")

[Chris Lamb]

Hi Thorsten,

> thanks! I did not want to get too deep into yak shaving in the
> dark hours of the night

Absolutely nothing to apologise for. It's far better the report exists
rather than it falling between the cracks and not being reported, even
if it requires a quick 'n' easy reassign (thanks Niels).

> >(Just as an aside, how come the tests fail? Are they looking
> 
> No, I just said this might make tests in packages fail, or
> something worse, like embedding PNGs into output of programs
> causing them to not be reproducible any more.

I can see how it may make tests fail if they were naively comparing
checksums or similar, but I'm not sure how this could make a package
not reproducible. As in, we would surely just be moving from one set
timestamp (the "original") to another timestamp (taken from the
changelog in this particular case), both of which are fixed between
builds of the same version.


Best wishes,

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

Bug#930988: libtifiles FTCBFS: Missing dependency tfdocgen

[Helmut Grohne]

Hi Lionel,

On Tue, Jun 25, 2019 at 09:43:24AM +0200, Lionel Debroux wrote:
> tfdocgen is a simple HTML documentation generator, which supports a
> Doxygen-like (but not Doxygen-compatible) syntax for C/C++ code, and
> maybe other languages which supports /** */ comments, I haven't tried.
> It was written by the previous maintainer over a decade ago, I have
> barely modified it. The files it produces are packaged in the -dev packages.

Thank you for chiming in. So do you confirm that tfdocgen consumes only
textual formats (source code with comment markup) and produces only
textual formats (html) and that the behaviour and output is independent
of the processor architecture being executed on?

If so, the tfdocgen package meets the requirements for being marked
Multi-Arch: foreign and should be thus marked. Any :native annotations
on tfdocgen should be reverted in this case.

You can confirm by sending the following paragraph to
cont...@bugs.debian.org:

reassign 930985 tfdocgen
reassign 930986 tfdocgen
reassign 930987 tfdocgen
reassign 930988 tfdocgen
forcemerge 930985 930986 930987 930988
retitle 930985 mark tfdocgen Multi-Arch: foreign
tags 930985 =
affects 930985 = src:libticables src:libticalcs src:libticonv src:libtifiles
user debian-cr...@lists.debian.org
usertags 930985 ftcbfs
thanks

Helmut

Bug#931064: unblock: grub2/2.02+dfsg1-20

[Ivo De Decker]

Control: tags -1 confirmed d-i

Hi,

On Tue, Jun 25, 2019 at 01:33:50PM +0100, Steve McIntyre wrote:
> Subject: unblock: grub2/2.02+dfsg1-20

Unblocked. Still needs the unblock u-deb (kibi Cc'ed).

Thanks,

Ivo

Bug#931082: netgen: Dead link in man 1 netgen

[Sebastian Bachmann]

Package: netgen
Version: 6.2.1804+dfsg1-3
Severity: minor

Dear Maintainer!

The manpage of netgen contains a link to http://www.mathcces.rwth-
aachen.de/netgen/doku.php which appears to be dead.
As far as I understand, the homepage of netgen is now https://ngsolve.org/

When greping for the URL in the netgen repo at sala.debian.org, I find other
occurences too:

$ git grep rwth-aachen.de
debian/manpages/netgen.sgml:Homepage: http://www.mathcces.rwth-
aachen.de/netgen/doku.php
debian/manpages/ng_stl.1:Homepage: http://www.mathcces.rwth-
aachen.de/netgen/doku.php
debian/manpages/ng_vol.1:Homepage: http://www.mathcces.rwth-
aachen.de/netgen/doku.php
doc/ng4.tex:Aachen University, Germany (http://www.mathcces.rwth-
aachen.de/netgen).
doc/ng4.tex:http://www.mathcces.rwth-aachen.de/netgen

best regards
Sebastian Bachmann



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

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

Versions of packages netgen depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libglu1-mesa [libglu1]   9.0.0-2.1+b3
ii  libmetis55.1.0.dfsg-5+b2
ii  libnglib-6.2.18046.2.1804+dfsg1-3
ii  libocct-data-exchange-7.37.3.0+dfsg1-5
ii  libocct-foundation-7.3   7.3.0+dfsg1-5
ii  libocct-modeling-algorithms-7.3  7.3.0+dfsg1-5
ii  libocct-modeling-data-7.37.3.0+dfsg1-5
ii  libocct-ocaf-7.3 7.3.0+dfsg1-5
ii  libocct-visualization-7.37.3.0+dfsg1-5
ii  libopenmpi3  3.1.3-11
ii  libpython3.7 3.7.3-2
ii  libstdc++6   8.3.0-6
ii  libtcl8.68.6.9+dfsg-2
ii  libtk8.6 8.6.9-2
ii  libx11-6 2:1.6.7-1
ii  libxmu6  2:1.1.2-2+b3
ii  tix  8.4.3-10
ii  zlib1g   1:1.2.11.dfsg-1

netgen recommends no packages.

Versions of packages netgen suggests:
pn  netgen-doc  

-- no debconf information

Bug#931081: libyubikey-udev: missing Breaks+Replaces: libykpers-1-1 (<< 1.19.3)

[Andreas Beckmann]

Package: libyubikey-udev
Version: 1.19.3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libyubikey-udev_1.19.3-3_all.deb ...
  Unpacking libyubikey-udev (1.19.3-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libyubikey-udev_1.19.3-3_all.deb (--unpack):
   trying to overwrite '/lib/udev/rules.d/69-yubikey.rules', which is also in 
package libykpers-1-1:amd64 1.17.3-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libyubikey-udev_1.19.3-3_all.deb

The version (<< 1.19.3) is based on this changelog entry in 1.19.3-1:
  * Replace custom udev rules with libu2f-udev.
Also drop build dependency on udev


cheers,

Andreas


libykpers-1-1=1.17.3-1_libyubikey-udev=1.19.3-3.log.gz
Description: application/gzip

Bug#931080: asciiflowqt: Wish for new package: asciiflowqt

[georg]

Package: asciiflowqt
Version: v0.3.3
Severity: wishlist

Dear Maintainer,

i would like to add asciiflowqt to debian. It has already a debian branch with
debian packaging.

The URL is:
https://github.com/schorsch1976/AsciiFlowQT

It is a offline ascii art editor. It is mostly used for programming issues to
document structure in an header or source as a comment.

Features:
=
- Export and Import ascii to/from the clipboard
- Export and Import ascii to/from a file
- Move parts of the ascii art
- draw rectangles
- resize rectangles
- draw class diagramms
- draw arrows
- draw lines
- draw freehand
- add text to any position
- undo and redo any change
- practicly unlimited space. The drawing area grows when you move out of it.

Licence
===
GPL-3.0

Used Libraries:
===
QT-5



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#931079: ITP: mimalloc -- compact general purpose allocator with excellent performance

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: mimalloc
  Version : for-experimental
  Upstream Authors: Microsoft Corporation, Daan Leijen
* URL : https://github.com/microsoft/mimalloc
* License : MIT
  Description : compact general purpose allocator with excellent 
performance
 This is a general purpose allocator with excellent performance 
characteristics.
 Initially developed by Daan Leijen for the run-time systems of the Koka 
and

 Lean languages.
 .
 It is a drop-in replacement for malloc and can be used in other 
programs

 without code changes.

Package will be availabe at http://phd-sid.ethz.ch/debian/mimalloc/

Bug#931078: A patch for LIRC with kernel 4.19 and gpio-ir for Raspbian Buster

[Takashi Kanamaru]

Package: lirc
Version: 0.10.1-5.2
Severity: important

Dear Maintainer,

When using kernel 4.19.X and LIRC on Raspberry Pi with Raspbian Buster,
gpio-ir should be used because lirc_dev is not officially installed.

However, pulse-space sequences generated by gpio-ir is slightly
different from that of lirc_dev.

Therefore, irrecord, mode2, irw do not work correctly with kernel 4.19
and gpio-ir
on Raspberry Pi.

I created a patch to modify the above problem.
This patch also works with earlier kernel and lirc_dev.
https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir-0.10.patch

Could you please merge this patch into the deb package of LIRC?

You can see the discussions in the following URL.
https://www.raspberrypi.org/forums/viewtopic.php?f=28=235256

Sincerely,

Takashi Kanamaru

Bug#931052: unblock: webkit2gtk/2.24.2-2

[Alberto Garcia]

On Tue, Jun 25, 2019 at 11:04:59AM +0300, Alberto Garcia wrote:

> This upload disables the JIT compiler and enables the CLoop
> JavaScript interpreter, which is slower but works on all CPUs. It
> also removes the gcc SSE2 flags. Only the i386 build is affected by
> these changes.

I realized that this is not accurate: in this particular version of
webkit2gtk the JIT compiler is already disabled for i386 (work is
being done upstream to have it enabled back again), so in practice
this line is a no-op because these are already the current values:

> + EXTRA_CMAKE_ARGUMENTS += -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON

I would still keep that line because it will be necessary as soon as
upstream brings back JIT support for x86.

This patch still removes -msse2 -mfpmath=sse from CFLAGS, and that's
what makes the package work in non-SSE2 CPUs.

Berto

Bug#870814: show message if unable to play video

[積丹尼 Dan Jacobson]

AG> With gstreamer1.0-libav installed ? What video are you exactly trying
AG> to play ?

Yes.
The first one that youtube shows me.
So OK, give me a youtube movie url that plays for you and I'll try it.

Bug#925906: sqlite3: FTCBFS: configure fails to find readline.h

[Helmut Grohne]

Control: clone -1 -2
Control: reassign -2 cross-config
Control: retitle -2 drop ac_cv_header_readline_h from cross-config.cache
Control: tags -2 =
Control: block -2 by -1

Thank you for the quick followup with details!

On Tue, Jun 25, 2019 at 11:43:01AM +0300, Yuriy M. Kaminskiy wrote:
> I built for armhf on i386/stretch host with pbuilder.

Important bit. I think pbuilder does not inject cross-config. This could
be a feature, because cross-configs are wrong sometimes.

> Relevant lines from
> http://crossqa.debian.net/build/sqlite3_3.27.2-3_armhf_20190622023957.log
> (with mysteriously successful readline.h detection)
> 
> checking for library containing readline... no
> checking for library containing tgetent... -lncurses
> checking for readline in -lreadline... yes
> checking for readline.h... (cached) yes

Please observe:  
This variable is injected by some cache. Likely from the cross-config
package split off dpkg-cross.

So cross-config was working around the bug and you fix it at the root
now. We should drop the workaround from cross-config:
https://sources.debian.org/src/dpkg-cross/2.6.15-3/config/cross-config.cache/#L242

Thank you for lifting this mystery. Given your explanations, I fully
agree with your patch now.

Helmut

Bug#870814: show message if unable to play video

[Alberto Garcia]

On Tue, Jun 25, 2019 at 11:55:46PM +0800, 積丹尼 Dan Jacobson wrote:
> It still says "your browser does not recognize any of the video formats 
> available."

With gstreamer1.0-libav installed ? What video are you exactly trying
to play ?

Berto

Bug#931068: zenity: Window icon is not displayed under Wayland

[Simon McVittie]

On Tue, 25 Jun 2019 at 15:47:13 +0200, Yvan Masson wrote:
> Window icon (which can be chosen with --window-icon) does not work when
> using Wayland, but works using Gnome.

Wayland is a protocol, not an implementation.

What is the environment in which this doesn't work for you? Is it Weston,
or GNOME Shell 3.30 in Wayland mode, or KDE in Wayland mode, or Sway,
or something else?

What is the environment in which this does work for you? Is it GNOME Shell
3.30 in Wayland mode, or GNOME Shell 3.30 in Xorg mode, or something else?

The results I get are:

- GNOME Shell 3.30 in Xorg mode: chosen icon appears in top bar and dash
  (sidebar in overview)
- GNOME Shell 3.30 in Wayland mode: a "broken image" icon appears instead

smcv

Bug#870814: show message if unable to play video

[積丹尼 Dan Jacobson]

It still says "your browser does not recognize any of the video formats 
available."

Bug#870814: show message if unable to play video

[Alberto Garcia]

On Tue, Jun 25, 2019 at 11:28:54PM +0800, 積丹尼 Dan Jacobson wrote:
> Currently going to
> $ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser 
> https://www.youtube.com/
> and trying to play a video now shows a message with a link to
> https://www.youtube.com/supported_browsers
> so I suppose this is an improvement.

Does installing gstreamer1.0-libav allow you to play the video?

If so, I propose to recommend that package and close this bug with
that. What do you think?

Berto

Bug#931076: systemd: __main__.SeccompTest is failing on Ubuntu CI

[Dan Streetman]

Package: systemd
Version: 240-6ubuntu5.1
Severity: normal

Dear Maintainer,

Upstream systemd CI is broken on Ubuntu due to a recent upstream change.  The 
d/t/boot-and-services test needs to be fixed to account for the new upstream 
change.

This is reported upstream at:
https://github.com/systemd/systemd/issues/12709

This is reported for Ubuntu at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831296

Since upstream systemd CI uses the debian test packaging from experimental, 
this has to be corrected in that repo.  Merge request is open here:
https://salsa.debian.org/systemd-team/systemd/merge_requests/33

Please consider merging.  Thanks.

Bug#870814: show message if unable to play video

[積丹尼 Dan Jacobson]

Currently going to
$ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser https://www.youtube.com/
and trying to play a video now shows a message with a link to
https://www.youtube.com/supported_browsers
so I suppose this is an improvement.

Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x and i386

[Olivier Tilloy]

Workaround submitted upstream:
https://bugs.chromium.org/p/skia/issues/detail?id=9202

Bug#931075: ITP: r-cran-lasso2 -- GNU R L1 constrained estimation aka `lasso'

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-lasso2 -- GNU R L1 constrained estimation aka `lasso'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-lasso2
  Version : 1.2
  Upstream Author : Justin Lokhorst, Bill Venables and Berwin Turlach;
* URL : https://cran.r-project.org/package=lasso2
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R L1 constrained estimation aka `lasso'
 Routines and documentation for solving regression problems
 while imposing an L1 constraint on the estimates, based on
 the algorithm of Osborne et al. (1998).

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-lasso2

Bug#931074: ITP: r-cran-logging -- GNU R logging package

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-logging -- GNU R logging package
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-logging
  Version : 0.9
  Upstream Author : Mario Frasca,
* URL : https://cran.r-project.org/package=logging
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R logging package
 Pure R implementation of the ubiquitous log4j package. It offers
 hierarchic loggers, multiple handlers per logger, level based filtering,
 space handling in messages and custom formatting.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-logging

Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files (was: "Re: debhelper: something in the dh sequencer changes the tIME chunk of installed PNGs")

[Thorsten Glaser]

Hi Chris,

>I've forwarded this upstream here:

thanks! I did not want to get too deep into yak shaving in the
dark hours of the night as I had something to do with a deadline,
so I’ve only seen that something in dh did it.

>(Just as an aside, how come the tests fail? Are they looking

No, I just said this might make tests in packages fail, or
something worse, like embedding PNGs into output of programs
causing them to not be reproducible any more.

I just found them by diffing the two MuseScore builds.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#931073: ITP: r-cran-ggdendro -- GNU R create dendrograms and tree diagrams using 'ggplot2'

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-ggdendro -- GNU R create dendrograms and tree diagrams 
using 'ggplot2'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-ggdendro
  Version : 0.1
  Upstream Author : Andrie de Vries,
* URL : https://cran.r-project.org/package=ggdendro
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R create dendrograms and tree diagrams using 'ggplot2'
 This is a set of tools for dendrograms and
 tree plots using 'ggplot2'.  The 'ggplot2' philosophy is to
 clearly separate data from the presentation.
 Unfortunately the plot method for dendrograms plots
 directly to a plot device without exposing the data.
 The 'ggdendro' package resolves this by making available
 functions that extract the dendrogram plot data. The package
 provides implementations for tree, rpart, as well as diana and agnes
 cluster diagrams.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-ggdendro

Bug#931072: ITP: fonts-havana -- Old communism style script font from Poland

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: fonts-havana
  Version : 1.0
  Upstream Authors: Stowarzyszenie Kulturotwórcze Miastodwa
* URL : https://kroje.org/en/fonts/havana/
* License : OFL-1.1
  Description : Old communism style script font from Poland
 This font is inspired by Warsaw neon signs from before 1989. Just like 
the
 lettering of that period, the “Havava” design is detail oriented, 
coherent
 and sophisticated. Some letters are directly drawn from specific signs 
–
 letters “K” and “m” from “Kosmetyki” or letter “t” from “Mister” sign. 
The

 font’s name itself refers to a former cafe “Havana” in Warsaw.

Package will be availabe at http://phd-sid.ethz.ch/debian/fonts-havana/

Bug#931071: hard-coded path in icebox_vlog

[Lars Dölle]

Package: fpga-icestorm
Version: 0~20181109git9671b76-1

Hi,

thank you very much for maintaining the icestorm package.

As the subject says, icebox_vlog contains a hard-coded path
in line 386 making the program fail to find the chipdb.

|with open("/usr/local/share/icebox/chipdb-%s.txt" % ic.device, "r") as f:

Kind regards

  Lars Dölle

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

[Andre Noll]

On Wed, Jun 19, 14:01, Adam Borowski wrote
> > Both issues have been fixed in v2 of the t/tfortunes branch which
> > I've just pushed out.  This branch also contains two new commits
> > which fix a gcc warning and a harmless memory leak.
> 
> Uploaded, with some changes.

Thanks a bunch for fixing my mistakes!

> > PS: I shall be offline until next Tuesday.
> 
> To skip the wait, I applied some fixes myself.  They are: a bogus
> day-of-week (which our tools detect and complain about) and the data package
> not being Arch:all.  Here's the diff:

[snip]

I've applied your patch and folded in the fixes into the existing
commit. See the v2 -> v3 section of the modified commit message.

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


signature.asc
Description: PGP signature

Bug#716463: Patch

[Jeremy Sowden]

This crash involves calling /usr/lib/wmcoincoin/wmcoincoin_player
directly with an empty environment.  Under those circumstances
XOpenDisplay returns NULL:

   disp  = XOpenDisplay(NULL);

   if (argc == 1) {
 printf("kikou je suis un player pourri\n");
 printf("mes options toutes plus nazes les unes que les autres sont:\n");
 printf(" wmcoincoin_player uneimagepour voir une image\n");
 printf(" wmcoincoin_player -z unchiffre uneimage  pour voir une image avec 
un certain facteur de zoom\n");
 printf(" wmcoincoin_player -i uneimage pour connaitres les dimensions 
d'une image\n");
 printf(" wmcoincoin_player -s uneimage le stack-mode (pour 
debeuggai)\n");
 printf(" le dernier argument, optionel, est l'id de la fenetre a 
utiliser\n");
 exit(0);
   }
   if (argc >= 3 && strcmp(argv[1], "-i") == 0) {
 query_mode = 1;
 argc--; argv++;
   }
   if (argc >= 3 && strcmp(argv[1], "-s") == 0) {
 stack_mode = 1;
 argc--; argv++;
   }
   if (argc >= 3 && strcmp(argv[1], "-z") == 0) {
 prefs.zoom = atof(argv[2]);
 argc-=2; argv += 2;
   }
   if (argc == 2) {
 fname  = argv[1];
 if (!query_mode) {
   vis   = DefaultVisual(disp, DefaultScreen(disp));
   depth = DefaultDepth(disp, DefaultScreen(disp));
   cm= DefaultColormap(disp, DefaultScreen(disp));
   win   = XCreateSimpleWindow(disp, DefaultRootWindow(disp), 0, 0, 10, 10,
   0, 0, 0);
   XSelectInput(disp, win, ButtonPressMask | ButtonReleaseMask |
ButtonMotionMask | PointerMotionMask);
 }
   } else {
 XWindowAttributes attr;
 unsigned long lwin;
 sscanf(argv[2],"0x%lx",); win = lwin;
 //printf("win=%08lx\n", lwin);
 fname = argv[1];

which leads to a NULL-pointer being passed to XGetWindowAttributes:

 XGetWindowAttributes(disp, win, );
 vis = attr.visual;
 depth = attr.depth;
 cm = attr.colormap;
   }

However, wmcoincoin_player is not supposed to be run like this.  It is
intended to be execked by wmcoincoin once the application is up and
running, which implies that the environment is correctly set up.

I've attached a fix.

J.
From 94bb12f2c1ba22d4d09fce286e4305f8c36e4155 Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Tue, 25 Jun 2019 14:01:38 +0100
Subject: [PATCH] If XOpenDisplay return NULL, exit.

---
 platypus/wmcoincoin_player.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/platypus/wmcoincoin_player.c b/platypus/wmcoincoin_player.c
index b11239ad15fa..06cb04bbe93f 100644
--- a/platypus/wmcoincoin_player.c
+++ b/platypus/wmcoincoin_player.c
@@ -104,6 +104,9 @@ main (int argc, char **argv)
init_anim();
 
disp  = XOpenDisplay(NULL);
+   if (disp == NULL)
+ return 1;
+
if (argc == 1) {
  printf("kikou je suis un player pourri\n");
  printf("mes options toutes plus nazes les unes que les autres sont:\n");
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#931070: Man page shows less options than "help" command

[積丹尼 Dan Jacobson]

Package: anbox
Version: 0.0~git20190124-1
File: /usr/share/man/man1/anbox.1.gz

$ anbox help
reveals a "check-features" command not mentioned on the man page.
There may be more too.

Bug#931069: Indicate if monitor has been turned "--off"

[積丹尼 Dan Jacobson]

Package: x11-xserver-utils
Version: 7.7+8
Severity: wishlist
File: /usr/bin/xrandr

If one does
$ xrandr --output LVDS-1 --off
the output of
$ xrandr
or
$ xrandr --verbose
does not reflect the change.

We have made that screen totally black but xrandr doesn't mention the
fact one single bit.

Sure, the screen is 1366x768 pixels and not 1366x767 pixels, so it tells
us that very precisely. But wouldn't you think it would mention that by
the way current status is "--off"?

Bug#931068: zenity: Window icon is not displayed under Wayland

[Yvan Masson]

Package: zenity
Version: 3.30.0-2
Severity: normal

Dear Maintainer,

Window icon (which can be chosen with --window-icon) does not work when 
using Wayland, but works using Gnome. You can test with the following 
command (assuming this icon exists on your system):


$ zenity --info 
--window-icon=/usr/share/icons/Adwaita/16x16/actions/call-start.png


Do not hesitate to ask if you want me to submit this bug report upstream.

Also, it seems the issue also exists with Yad (a Zenity fork), as I 
already reported in #926736.


Regards,
Yvan

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zenity depends on:
ii  libc6 2.28-10
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2
ii  libgtk-3-03.24.5-1
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-6
ii  libwebkit2gtk-4.0-37  2.24.2-1
ii  libx11-6  2:1.6.7-1
ii  zenity-common 3.30.0-2

zenity recommends no packages.

zenity suggests no packages.

-- no debconf information

Bug#931067: ITP: r-bioc-consensusclusterplus -- GNU R determining cluster count and membership

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-consensusclusterplus -- GNU R determining cluster count 
and membership
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-consensusclusterplus
  Version : 1.48.0
  Upstream Author : Matt Wilkerson , Peter Waltman
* URL : https://bioconductor.org/packages/ConsensusClusterPlus/
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R determining cluster count and membership
 ConsensusClusterPlus is a BioCOnductor package providing an algorithm
 for determining cluster count and membership by stability evidence in
 unsupervised analysis.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-consensusclusterplus

Bug#931066: xserver-xorg-core: X crash - libfb

[MaXaMaR]

Package: server-xorg-core
Version: 2:1.20.4-1
Severity: grave

Hello I have a similar to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911680 
 bug I think, also in 
VM which is KVM (Proxmox) with AMD RX590 PCI passthru.
Happens on latest sid & experimental 5.0 kernels, also in latest Ubuntu 19.04 & 
19.10.
Previously it worked ok in ESXI, Xen with Ubuntu.
It works in KVM Windows 10.

Or is it amdgpu bug?

Thanks.

root@dev:/var/log# cat Xorg.0.log
[   131.766]
X.Org  X Server 1.20.4
X Protocol Version 11, Revision 0
[   131.766] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[   131.766] Current Operating System: Linux dev 5.0.0-trunk-amd64 #1 SMP 
Debian 5.0.2-1~exp1 (2019-03-18) x86_64
[   131.766] Kernel command line: BOOT_IMAGE=/vmlinuz-5.0.0-trunk-amd64 
root=UUID=e4607c3b-74e7-45bf-be63-5cc5d816194d ro quiet
[   131.766] Build Date: 05 March 2019  08:11:12PM
[   131.766] xorg-server 2:1.20.4-1 (https://www.debian.org/support 
)
[   131.766] Current version of pixman: 0.36.0
[   131.766]Before reporting problems, check http://wiki.x.org 

to make sure that you have the latest version.
[   131.766] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   131.767] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 25 13:48:04 
2019
[   131.767] (++) Using config file: "/root/xorg.conf.new"
[   131.767] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   131.767] (==) ServerLayout "X.org  Configured"
[   131.767] (**) |-->Screen "Screen0" (0)
[   131.767] (**) |   |-->Monitor "Monitor0"
[   131.768] (**) |   |-->Device "Card0"
[   131.768] (**) |-->Screen "Screen1" (1)
[   131.768] (**) |   |-->Monitor "Monitor1"
[   131.768] (**) |   |-->Device "Card1"
[   131.768] (**) |-->Screen "Screen2" (2)
[   131.768] (**) |   |-->Monitor "Monitor2"
[   131.768] (**) |   |-->Device "Card2"
[   131.768] (**) |-->Input Device "Mouse0"
[   131.768] (**) |-->Input Device "Keyboard0"
[   131.768] (==) Automatically adding devices
[   131.768] (==) Automatically enabling devices
[   131.768] (==) Automatically adding GPU devices
[   131.768] (==) Max clients allowed: 256, resource mask: 0x1f
[   131.768] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   131.768]Entry deleted from font path.
[   131.768] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   131.768]Entry deleted from font path.
[   131.768] (**) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   131.768] (**) ModulePath set to "/usr/lib/xorg/modules"
[   131.768] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 
'vmmouse' will be disabled.
[   131.768] (WW) Disabling Mouse0
[   131.768] (WW) Disabling Keyboard0
[   131.768] (II) Loader magic: 0x55f57d015e20
[   131.769] (II) Module ABI versions:
[   131.769]X.Org  ANSI C Emulation: 0.4
[   131.769]X.Org  Video Driver: 24.0
[   131.769]X.Org  XInput driver : 24.1
[   131.769]X.Org  Server Extension : 10.0
[   131.769] (--) using VT number 3

[   131.769] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[   131.771] (II) xfree86: Adding drm device (/dev/dri/card0)
[   131.771] (II) xfree86: Adding drm device (/dev/dri/card1)
[   131.799] (--) PCI:*(0@0:1:0) 1234::1af4:1100 rev 2, Mem @ 
0xf000/16777216, 0xfea14000/4096, BIOS @ 0x/131072
[   131.799] (--) PCI: (1@0:0:0) 1002:67df:1da2:e366 rev 225, Mem @ 
0x6/8589934592, 0x8/2097152, 0xfe80/262144, I/O @ 
0x5000/256, BIOS @ 0x/131072
[   131.799] (II) "glx" will be loaded. This was enabled by default and also 
specified in the config file.
[   131.799] (II) LoadModule: "glx"
[   131.799] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   131.801] (II) Module glx: vendor="X.Org  Foundation"
[   131.801]compiled for 1.20.4, module version = 1.0.0
[   131.801]ABI class: X.Org  Server Extension, version 10.0
[   131.801] (II) LoadModule: "amdgpu"
[   131.801] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so
[   131.801] (II) Module amdgpu: 

Bug#716467: Fix available

[Jeremy Sowden]

The crash was the result of passing a null pointer to strlen when
allocating memory for the PID file:

/* we can theoretically live without a config file */
home = getenv("HOME");
if (home) {
config.file = calloc(1, strlen(home) + 9);
sprintf(config.file, "%s/.wmixrc", home);
}

/* handle writing PID file, silently ignore if we can't do it */
pid = calloc(1, strlen(home) + 10);
sprintf(pid, "%s/.wmix.pid", home);
fp = fopen(pid, "w");
if (fp) {
fprintf(fp, "%d\n", getpid());
fclose(fp);
}
free(pid);

This was fixed in a later release, 3.3, which has since packaged and
uploaded to the archive:

  $ apt-cache policy wmix
  wmix:
Installed: 3.3-1
Candidate: 3.3-1
Version table:
   *** 3.3-1 990
  990 http://mirror.ox.ac.uk/debian testing/main amd64 Packages
  990 http://ftp.uk.debian.org/debian testing/main amd64 Packages
  990 http://ftp.debian.org/debian testing/main amd64 Packages
   99 http://mirror.ox.ac.uk/debian unstable/main amd64 Packages
   99 http://ftp.uk.debian.org/debian unstable/main amd64 Packages
   99 http://ftp.debian.org/debian unstable/main amd64 Packages
  100 /var/lib/dpkg/status
   3.1-5.1 900
  900 http://mirror.ox.ac.uk/debian stable/main amd64 Packages
  900 http://ftp.uk.debian.org/debian stable/main amd64 Packages
  900 http://ftp.debian.org/debian stable/main amd64 Packages

J.


signature.asc
Description: PGP signature

Bug#931065: ITP: r-bioc-all -- Bioconductor data package used by several bioc tools

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-all -- Bioconductor data package used by several bioc tools
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-all
  Version : 1.26.0
  Upstream Author : Xiaochun Li
* URL : https://bioconductor.org/packages/data/experiment/ALL/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : Bioconductor data package used by several bioc tools
 Data of T- and B-cell Acute Lymphocytic Leukemia from the Ritz
 Laboratory at the DFCI (includes Apr 2004 versions)

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-all

Bug#852032: libjavascriptcoregtk-4.0-18: Segmentation fault in LLIntAssembly.h:2610 on powerpc64

[Alberto Garcia]

On Mon, Jan 23, 2017 at 11:14:16AM +0100, Alberto Garcia wrote:
> webkit2gtk itself builds fine, seed-webkit2 is what fails:

I wanted to test this with the latest versions of WebKitGTK, but I
don't seem to have access to any porterbox with ppc64 (only ppc64el,
in which things work fine).

Is this still a thing? Do we still care about ppc64? I'll close the
bug otherwise.

Berto

Bug#931044: installing python3.4 fails

[Paul Boddie]

Package: python3.4
Version: 3.4.2-1+deb8u3
Followup-For: Bug #931044

The following fix could be applied to the faulty Python standard library file
ultimately used by the /var/lib/dpkg/info/python3.4.postinst script:

--- /usr/lib/python3.4/http/client.py   2019-06-25 14:41:35.0 +0200
+++ /usr/lib/python3.4/http/client.py   2019-06-25 14:41:55.0 +0200
@@ -1011,8 +1011,9 @@
 # Prevent CVE-2019-9740.
 match = _contains_disallowed_url_pchar_re.search(url)
 if match:
-raise InvalidURL(f"URL can't contain control characters. {url!r} "
- f"(found at least {match.group()!r})")
+raise InvalidURL("URL can't contain control characters. {url!r} "
+ "(found at least {group!r})"
+ .format(url=url, group=match.group()))
 request = '%s %s %s' % (method, url, self._http_vsn_str)

 # Non-ASCII characters should have been eliminated earlier

Sorry to provide this patch inline, but I am using the textual bug reporting
interface! I imagine that this regression has occurred because someone has
applied the noted vulnerability countermeasure without backporting it to the
syntax understood by Python 3.5 or earlier.

I hope this helps others experiencing the same problem.

Paul

-- System Information:
Debian Release: 8.11
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-9-586
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3.4 depends on:
ii  libpython3.4-stdlib  3.4.2-1+deb8u3
ii  mime-support 3.58
ii  python3.4-minimal3.4.2-1+deb8u3

python3.4 recommends no packages.

Versions of packages python3.4 suggests:
ii  binutils2.25-5+deb8u1
pn  python3.4-doc   
pn  python3.4-venv  

-- no debconf information

Bug#931017: dkms: "install" loads modules immediately, and loads more than the newly installed modules

[Raphael Hertzog]

Control: forwarded -1 https://github.com/dell/dkms/issues/85

On Mon, 24 Jun 2019, Raphaël Hertzog wrote:
> The reason is that "dkms install" runs this:
> find /sys/devices -name modalias -print0 | xargs -0 cat | xargs modprobe -a 
> -b -q

This was added in this commit:
https://github.com/dell/dkms/commit/f5bfb12fef1fc06e56355cdba500eaa98d4e6aa8

The rationale given there does not apply at all to Debian where
the modules are built/installed as soon as the DKMS package is installed
and not only on next reboot...

So we can likely just patch this out until upstream provides a way
to disable this code.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#870814: show message if unable to play video

[Alberto Garcia]

On Fri, Aug 25, 2017 at 10:21:36PM +0800, 積丹尼 Dan Jacobson wrote:

> OK I installed all the packages libwebkit2gtk-4.0-37 suggests, and
> recommends, and can finally play the video. (But with no sound...).
> 
> Anyway, most browsers say "plugin cannot be used" instead of the
> black screen we discussed.

I cannot reproduce the original problem anymore, does it still happen
to you?

Berto

Bug#931064: unblock: grub2/2.02+dfsg1-20

[Steve McIntyre]

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

Please unblock package grub2

While testing the Buster d-i RC2 build yesterday, I realised that we
hadn't *quite* finished all the packaging changes for Secure Boot. At
the moment, only the signed grub packages on amd64 Recommend:
shim-signed, but we also want that for i386 and arm64 too, as this
Recommend: is what causes shim-signed etc. to be pulled in at
installation time.

At the point when we first did this signing-template work, we didn't
*have* a shim-signed package on the other arches, so it didn't make
sense at the time.

I've made a tiny 1-line patch to just the signing-template and
uploaded. Ansgar says he'll prod the signing queue tonight to make the
-signed packages appear then.

Here's the trivial debdiff, excluding some noise in .bzrignore and
.gitignore files:

diff -Nru --exclude '.*ignore' grub2-2.02+dfsg1/debian/changelog 
grub2-2.02+dfsg1/debian/changelog
--- grub2-2.02+dfsg1/debian/changelog   2019-06-14 19:04:01.0 +0100
+++ grub2-2.02+dfsg1/debian/changelog   2019-06-25 10:11:12.0 +0100
@@ -1,3 +1,13 @@
+grub2 (2.02+dfsg1-20) unstable; urgency=medium
+
+  [ Steve McIntyre ]
+  * Make all the signed EFI arches have a Recommends: from
+grub-efi-ARCH-signed to shim-signed, not just amd64.
+Closes: #931038
+  * Add myself to Uploaders
+
+ -- Steve McIntyre <93...@debian.org>  Tue, 25 Jun 2019 10:11:12 +0100
+
 grub2 (2.02+dfsg1-19) unstable; urgency=medium
 
   [ Colin Watson ]
diff -Nru --exclude '.*ignore' grub2-2.02+dfsg1/debian/control 
grub2-2.02+dfsg1/debian/control
--- grub2-2.02+dfsg1/debian/control 2019-06-14 19:04:01.0 +0100
+++ grub2-2.02+dfsg1/debian/control 2019-06-25 10:09:06.0 +0100
@@ -2,7 +2,7 @@
 Section: admin
 Priority: optional
 Maintainer: GRUB Maintainers 
-Uploaders: Felix Zielcke , Jordi Mallach , 
Colin Watson , Ian Campbell 
+Uploaders: Felix Zielcke , Jordi Mallach , 
Colin Watson , Ian Campbell , Steve 
McIntyre <93...@debian.org>
 Build-Depends: debhelper (>= 10~),
  patchutils,
  python,
diff -Nru --exclude '.*ignore' 
grub2-2.02+dfsg1/debian/signing-template/control.in 
grub2-2.02+dfsg1/debian/signing-template/control.in
--- grub2-2.02+dfsg1/debian/signing-template/control.in 2019-06-14 
19:04:01.0 +0100
+++ grub2-2.02+dfsg1/debian/signing-template/control.in 2019-06-25 
10:08:26.0 +0100
@@ -12,7 +12,7 @@
 Package: @pkg_signed@
 Architecture: @arch@
 Depends: grub-common (= @version_binary@)
-Recommends: shim-signed [amd64]
+Recommends: shim-signed
 Built-Using: grub2 (= @version_binary@)
 Description: GRand Unified Bootloader, version 2 (@arch@ UEFI signed by Debian)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a


unblock grub2/2.02+dfsg1-20
unblock grub-efi-amd64-signed/1+2.02+dfsg1+20
unblock grub-efi-arm64-signed/1+2.02+dfsg1+20
unblock grub-efi-ia32-signed/1+2.02+dfsg1+20

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

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

Bug#931063: dpkg: error processing package python3.4 (--configure):

[Bas Couwenberg]

Should be fixed soon, see the thread on the lts list:

 https://lists.debian.org/debian-lts/2019/06/msg00025.html

Kind Regards,

Bas

Bug#930998: RM: ompl/1.4.2+ds1-3

[Leopold Palomo-Avellaneda]

Just some clarifications:


As Jochen said:

> Reason: The package in testing is RC buggy with #930507. Leo pushed a
> new -3 revision over a week ago to unstable but expressed in

> https://lists.debian.org/debian-release/2019/06/msg00526.html
> 
> that he is not 'very happy with the patches'. 

he missed the final sentence ... but "they are valid". When I was saying that I
was not happy I asked three possible options and I didn't receive any answer. I
just create another set of patch different from upstream to solve the same and I
don't think that it was a good idea (not follow Upstream solving the same). And
the most formal solution should be to use the Depends field of pkg-config.

The bug mentioned the dependencies of the pkgfile about the includes and that
was solved. The problem has been that I introduce a more strong dependency
(libode-dev)

After discussing the state
> in #debian-release today, I had a look at the -3 version and tested it
> using
> 
> http://ompl.kavrakilab.org/RigidBodyPlanningWithIntegrationAndControls_8cpp_source.html
> 
> and
> 
> g++ $(pkg-config --cflags --libs ompl) -o 
> RigidBodyPlanningWithIntegrationAndControls 
> RigidBodyPlanningWithIntegrationAndControls.cpp
> 
> I found that that libompl-dev was still missing dependencies, i.e.
> libode-dev and boost.

boost is added, Jochen do it. But libode no. I just solved the pkg issue but I
didn't pay attention that that changed brought the libode-dev. You only need
libode if you use one extension. For instance, the example that Jochen mentioned
generate:

 g++ -I/usr/include/eigen3 -lompl /usr/lib/x86_64-linux-gnu/libode.so
/usr/lib/x86_64-linux-gnu/libboost_serialization.so
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so
/usr/lib/x86_64-linux-gnu/libboost_system.so -lpthread -o
RigidBodyPlanningWithIntegrationAndControls
RigidBodyPlanningWithIntegrationAndControls.cpp

if I drop the ode part (/usr/lib/x86_64-linux-gnu/libode.so) the program
compiles and links perfectly, and runs. If I uninstall libode-dev the program
works (and builds without the libode.so). Only needs libode-dev because
pkg-config add that flag. And it added because if you use the ode extension in
theory you need to link against it, but it's not clear to me. libompl is linked
against ode because that extension, but if you don't use any ode symbols I think
that you don't need to link against it.

> Given that the deadline for change in buster passed and the package would need
> more review to get fixed, I propose to drop it from the buster release.

It's a pity and a sad thing to me. I have been working with this package and
tried to keep it in a good shape and now because a last time bug, bad resolved
and with a simple solution (change Suggest to depends of libode-dev) it's out of
buster.

I have pushed a new version replacing my patches with an adaptation of upstream
patches to solve the problem from here:

https://bitbucket.org/ompl/ompl/commits/e3855102b037643a9625ff6694bb2f559eecb411

Here my patches:

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0002-Patch-from-upstream-to-add-include-dirs.patch

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0003-Patch-from-upstream-to-add-include-dirs-to-pkg-confi.patch

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0004-Patch-from-upstream-to-add-include-dirs-to-pkg-confi.patch


Leopold


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

Bug#930223: [Pkg-javascript-devel] need help with building node-dagre-d3-renderer with webpack

[Pirate Praveen]

On Tue, 25 Jun, 2019 at 3:13 PM, Pirate Praveen 
 wrote:
Same error when changing package.json#main to dist/dagre-d3.js (umd 
format).


To confirm it is not a browser only library, I downloaded the 
dagre-d3-renderer dist.tarball from npmjs.com and the require command 
succeeds there.

Bug#931063: dpkg: error processing package python3.4 (--configure):

[Larry Kraemer]

Package: upgrade-reports
Severity: important

Dear Maintainer,

I executed the following this morning:
sudo apt-get update
sudo apt-get upgrade

and I got these error statements:
Setting up python3.4 (3.4.2-1+deb8u3) ...
  File "/usr/lib/python3.4/http/client.py", line 1014
raise InvalidURL(f"URL can't contain control characters. {url!r} "
..^
SyntaxError: invalid syntax
dpkg: error processing package python3.4 (--configure);
 subprocess installed post-installation script returned error exit status 1



-- System Information:
Debian Release: 8.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-8-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#931061: crossbuild-essential-ARCH shouldn't depend on all

[Evgeny Golyshev]

Source: build-essential
Version: 12.6
Severity: wishlist
Tags: patch

The following packages
* crossbuild-essential-amd64
* crossbuild-essential-armel
* crossbuild-essential-arm64
* crossbuild-essential-armhf
* crossbuild-essential-i386
* crossbuild-essential-mips
* crossbuild-essential-mipsel
* crossbuild-essential-mips64el
* crossbuild-essential-powerpc
* crossbuild-essential-ppc64el
* crossbuild-essential-s390x

should depend on all architectures _except_ its own one. For example,
crossbuild-essential-arm64 should depend on amd64, armel, armhf, i386,
mips, mipsel, mips64el, powerpc, ppc64el, s390x but _not_ on arm64.
Otherwise, the package will be available for the arm64 architecture
but installing of the package will lead to

The following packages have unmet dependencies:
 crossbuild-essential-arm64 : Depends: gcc-aarch64-linux-gnu (>= 7.2)
but it is not installable
  Depends: g++-aarch64-linux-gnu (>= 7.2)
but it is not installable
E: Unable to correct problems, you have held broken packages.

I'm attaching the patch which solves the problem.

--
Evgeny Golyshev
--- a/debian/control	2019-03-01 15:05:10.0 +0300
+++ b/debian/control	2019-06-25 13:16:43.794744574 +0300
@@ -51,7 +51,7 @@
  package depends on.
 
 Package: crossbuild-essential-arm64
-Architecture: all
+Architecture: amd64 armel armhf i386 mips mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -70,7 +70,7 @@
  package depends on.
 
 Package: crossbuild-essential-armel
-Architecture: all
+Architecture: amd64 arm64 armhf i386 mips mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -89,7 +89,7 @@
  package depends on.
 
 Package: crossbuild-essential-armhf
-Architecture: all
+Architecture: amd64 arm64 armel i386 mips mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -108,7 +108,7 @@
  package depends on.
 
 Package: crossbuild-essential-i386
-Architecture: all
+Architecture: amd64 arm64 armel armhf mips mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -127,7 +127,7 @@
  package depends on.
 
 Package: crossbuild-essential-mips
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -146,7 +146,7 @@
  package depends on.
 
 Package: crossbuild-essential-mipsel
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -165,7 +165,7 @@
  package depends on.
 
 Package: crossbuild-essential-mips64el
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -184,7 +184,7 @@
  package depends on.
 
 Package: crossbuild-essential-powerpc
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -203,7 +203,7 @@
  package depends on.
 
 Package: crossbuild-essential-ppc64el
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el powerpc s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -222,7 +222,7 @@
  package depends on.
 
 Package: crossbuild-essential-s390x
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el powerpc ppc64el
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need

Bug#931062: unblock: ionit/0.3.2+really0.2.1-2

[Benjamin Drung]

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

Please unblock package ionit

The ionit.service fix for bug #919690 introduced a systemd dependency
loop. systemd will break the loop at a (random?) place which can make
boot behave incorrectly.

I fixed the dependency loop in ionit 0.3.2+really0.2.1-2. A debdiff is
attached.

unblock ionit/0.3.2+really0.2.1-2

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

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

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet
diff -Nru ionit-0.3.2+really0.2.1/debian/changelog 
ionit-0.3.2+really0.2.1/debian/changelog
--- ionit-0.3.2+really0.2.1/debian/changelog2019-06-20 15:36:08.0 
+0200
+++ ionit-0.3.2+really0.2.1/debian/changelog2019-06-25 13:18:08.0 
+0200
@@ -1,3 +1,10 @@
+ionit (0.3.2+really0.2.1-2) unstable; urgency=medium
+
+  * Drop After=local-fs.target from ionit.service to break dependency loop
+(Closes: #931060)
+
+ -- Benjamin Drung   Tue, 25 Jun 2019 13:18:08 
+0200
+
 ionit (0.3.2+really0.2.1-1) unstable; urgency=medium
 
   * Run ionit.service before systemd-modules-load.service
diff -Nru 
ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch
 
ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch
--- 
ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch
  1970-01-01 01:00:00.0 +0100
+++ 
ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch
  2019-06-25 13:16:16.0 +0200
@@ -0,0 +1,45 @@
+From ce7c305312bb68319784e2d693955297138c273a Mon Sep 17 00:00:00 2001
+From: Benjamin Drung 
+Date: Tue, 25 Jun 2019 12:00:24 +0200
+Subject: [PATCH] Drop After=local-fs.target from ionit.service
+
+Letting `ionit.service` run before `systemd-udev-trigger.service`
+introduces a dependency loop:
+
+```
+systemd[1]: systemd-udev-trigger.service: Found ordering cycle on 
ionit.service/start
+systemd[1]: systemd-udev-trigger.service: Found dependency on 
local-fs.target/start
+systemd[1]: systemd-udev-trigger.service: Found dependency on 
local-fs-pre.target/start
+systemd[1]: systemd-udev-trigger.service: Found dependency on 
multipathd.service/start
+```
+
+`systemd-udev-trigger.service` runs before `multipathd.service` which
+runs before `local-fs-pre.target` which runs before `local-fs.target`.
+`ionit.service` wants to run before `systemd-udev-trigger.service` but
+after `local-fs.target`.
+
+Therefore drop `After=local-fs.target` from `ionit.service` to break the
+dependency loop. `/etc` and `/usr` is probably mounted inside the initrd
+already.
+
+Bug-Debian: https://bugs.debian.org/931060
+Signed-off-by: Benjamin Drung 
+---
+ ionit.service | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/ionit.service b/ionit.service
+index 8f56106..4c4e1c8 100644
+--- a/ionit.service
 b/ionit.service
+@@ -2,7 +2,6 @@
+ Description=Render configuration files from Jinja templates
+ Documentation=man:ionit(1)
+ DefaultDependencies=no
+-After=local-fs.target
+ Before=ferm.service network-pre.target openibd.service shutdown.target 
sysinit.target systemd-modules-load.service systemd-udev-trigger.service
+ Wants=network-pre.target
+ RequiresMountsFor=/usr
+-- 
+2.20.1
+
diff -Nru ionit-0.3.2+really0.2.1/debian/patches/series 
ionit-0.3.2+really0.2.1/debian/patches/series
--- ionit-0.3.2+really0.2.1/debian/patches/series   2019-06-20 
13:54:04.0 +0200
+++ ionit-0.3.2+really0.2.1/debian/patches/series   2019-06-25 
13:16:39.0 +0200
@@ -1,2 +1,3 @@
 Run-ionit.service-before-systemd-modules-load.service.patch
 Run-ionit.service-before-systemd-udev-trigger.service.patch
+Drop-After-local-fs.target-from-ionit.service.patch

Bug#930484: e2fsck corrupts sparse files with -E bmap2extent

[Florian Zumbiehl]

Hi,

[...]
> In my mind, this is why Debian Backports exists.  If you want the
> latest bug fixes (including one whhich avoids data corruption when
> doing off-line shrinks using resize2fs), and/or you are doing anything
> at all exotic, my only recommendation is to use the Debian Backports
> version of e2fsprogs.

Well, the big problem with that argument is that it presumes people know
what's exotic? The man page doesn't say it's exotic. The program doesn't
warn you that what you are doing is exotic. The only person who kinda knows
what's exotic is you. But you don't do what would be necessary to make
users aware of it. Plus, I don't even see how you would really know, given
that there probably is no telemetry in e2fsck.

Now that I had noticed by pure luck that a file had been corrupted during a
recent conversion, I went back and found files that were corrupted during
conversions that I did four years ago. Now, that was before you were aware
of the bug, so nothing you could have done to prevent that, but it shows
how long the damage caused by this bug can stay undiscovered/how difficult
it is for you to have an accurate view of the impact of this bug.

> Bottom line, for *this* particular bug (as opposed to the various
> resize2fs shrink fixes) preparing an update to 1.43.4-2 is pretty
> simple.

Now, I don't know any details about this other bug, but simply bailing out
in the risky case presumably shouldn't be that difficult either?! I mean, I
can see why you wouldn't want to spend lots of time porting fixes to old
versions that they don't readily apply on, and I wouldn't really see any
value in that anyway. But preventing damage does not require porting the
fix, bailing out does the job as well?!

>  And if I had any optimism that the Release Team would be
> willing to take a very late update to Debian Stretch at the point when
> it's just about become oldstable, I might even be willing to do the
> upload.  But it's not something where I'm feeling particularly
> motivated to convince the release team that this is a change they
> should be taking, and respinning the Stretch installer at this point.

That reads more like you think the bug actually should be fixed, but the
Release Team is likely to create tons of unnecessary work, and possibly
preventing it anyway, that you don't feel like wasting your time with that?

What is the problem with respinning the installer? That sounds like
something that should be automated?! But also, fixing this only in the
non-installer package sure would be better than nothing, if fixing the
installer is a big problem.

Regards, Florian

Bug#931060: ionit.service creates a systemd dependency loop

[Benjamin Drung]

Package: ionit
Version: 0.3.2+really0.2.1-1
Severity: serious
Tags: patch upstream

Letting ionit.service run before systemd-udev-trigger.service (fix for
Deiban bug #919690) introduces a dependency loop:

systemd[1]: systemd-udev-trigger.service: Found ordering cycle on
ionit.service/start
systemd[1]: systemd-udev-trigger.service: Found dependency on
local-fs.target/start
systemd[1]: systemd-udev-trigger.service: Found dependency on
local-fs-pre.target/start
systemd[1]: systemd-udev-trigger.service: Found dependency on
multipathd.service/start

systemd will break the loop where the dependency is required for correct
booting.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

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

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#931058: linux: enable CONFIG_USB_DUMMY_HCD=m for simulating USB UDCs for USB gadgets

[Paul Wise]

Package: src:linux
Severity: wishlist

I would like the CONFIG_USB_DUMMY_HCD=m option to be enabled, so that I
can experiment with USB gadgets on x86 desktop systems where a USB UDC
is not available. The other gadget-related config options are already
enabled in the Debian version of the Linux kernel. More info about
using dummy-hcd for experimenting with USB gadgets here:

https://www.collabora.com/news-and-blog/blog/2019/06/24/using-dummy-hcd/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#930935: webkit2gtk: Baseline violation on i386

[Adrian Bunk]

On Tue, Jun 25, 2019 at 10:16:48AM +0200, Alberto Garcia wrote:
> On Mon, Jun 24, 2019 at 04:48:43PM +0300, Alberto Garcia wrote:
> 
> > If no one has anything to say I'll upload it today. This should work
> > on all i386 CPUs, and we can later discuss if it's worth thinking of
> > a solution for SSE2-capable machines.
> 
> Uploaded, unblock request at #931052
> 
> I don't have an Athlon XP myself but I can reproduce the bug (and
> verify that the fix works) emulating a Pentium 3 with QEMU.

Thanks a lot!

> Berto

cu
Adrian

-- 

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

Bug#931057: python3: Error while upgrading python3.4

[mediaf]

Package: python3
Version: 3.4.2-2
Severity: normal

Dear Maintainer,

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

I have done apt update, apt ugrade and I received this message :

Paramétrage de python3.4 (3.4.2-1+deb8u3) ...
  File "/usr/lib/python3.4/http/client.py", line 1014
raise InvalidURL(f"URL can't contain control characters. {url!r} "
 ^
SyntaxError: invalid syntax
dpkg: erreur de traitement du paquet python3.4 (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de
sortie d'état 1
dpkg: des problèmes de dépendances empêchent la configuration de python3 :
 python3 dépend de python3.4 (>= 3.4.2-0) ; cependant :
 Le paquet python3.4 n'est pas encore configuré.

dpkg: erreur de traitement du paquet python3 (--configure) :
 problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
 python3.4
 python3



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

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

Versions of packages python3 depends on:
ii  dh-python  1.2014-2
ii  libpython3-stdlib  3.4.2-2
ii  python3-minimal3.4.2-2
ih  python3.4  3.4.2-1+deb8u3

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
pn  python3-tk
pn  python3-venv  

-- no debconf information

Bug#930648: exim4-daemon-heavy: Weird leakage of unrelated data like /etc/aliases into /var/spool/exim4/input/*-H

[Bjoern Buerger]

* Andreas Metzler (ametz...@bebt.de) [190621 09:58]:
> On 2019-06-19 Bjoern Buerger  wrote:
> > * Andreas Metzler (ametz...@bebt.de) [190618 19:15]:
> [...] 
> > > Could you try
> > > a) disabling BDAT (set chunking_advertise_hosts = )
> > > b) try a backport of sa-exim 4.2.1-17?
> 
> > > See #879687.
> 
> > We could give it a try, but I don't see the point.
> 
> Did you test it yet?

We are testing it now. I wanted to check first, if this 
might be a onetime error. But yesterday it happened again. 

chunking_advertise_hosts is now disabled, 
sa-exim is 4.2.1-17. 

Now, we need to wait again. Last time it took ~7 days.

Bjørn

-- 
Pengutronix e.K.  | Bjørn Bürger|
Industrial Linux Solutions| https://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5002 |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917- |

Bug#931044: Quick workaround

[Peppo Brambilla]

I fixed is as follows:

root@woody:/usr/lib/python3.4/http# diff -c3  client.py.orig client.py
*** client.py.orig  2019-06-21 03:20:41.0 +0200
--- client.py   2019-06-25 09:12:35.0 +0200
***
*** 1011,1018 
  # Prevent CVE-2019-9740.
  match = _contains_disallowed_url_pchar_re.search(url)
  if match:
! raise InvalidURL(f"URL can't contain control characters. {url!r} "
!  f"(found at least {match.group()!r})")
  request = '%s %s %s' % (method, url, self._http_vsn_str)
  
  # Non-ASCII characters should have been eliminated earlier
--- 1011,1018 
  # Prevent CVE-2019-9740.
  match = _contains_disallowed_url_pchar_re.search(url)
  if match:
! raise InvalidURL("URL can't contain control characters. {!r} 
".format(url) + 
!  "(found at least {!r})".format(match.group()))
  request = '%s %s %s' % (method, url, self._http_vsn_str)
  
  # Non-ASCII characters should have been eliminated earlier

Cheers -- Peppo

On Tue, 25 Jun 2019 11:09:28 +0200 jens persson  wrote:

> A quick workaround to get our old environments to work was to remove the
> f:s on line 1014 and 1015 in /usr/lib/python3.4/http/client.py as:
> raise InvalidURL("URL can't contain control characters. {url!r}
> "
> "(found at least {match.group()!r})")
>
> This will give bad error messages but allow things to work.
>
> /jp
>
> --
> jens persson
> 
> Mäster Olofsväg 24
> S-224 66 LUND;SWEDEN

-- 
Peppo Brambilla
Universitaet Bern, Institut fuer Informatik
Neubrueckstr. 10, CH-3012 Bern 
Tel +41 31 631 3310

Bug#930223: [Pkg-javascript-devel] need help with building node-dagre-d3-renderer with webpack

[Pirate Praveen]

On Tue, 25 Jun, 2019 at 3:07 PM, Pirate Praveen 
 wrote:
Now there is another error (tried replacing commonjs2 with commonjs, 
also tried with nodejs 12),


  dh_auto_test --buildsystem=nodejs
/usr/bin/node -e require\(\".\"\)
/<>/dist/dagre-d3.core.js:950
function (node, name, id, index, group, timing) {
^

SyntaxError: Unexpected token (
   at new Script (vm.js:79:7)
   at createScript (vm.js:251:10)
   at Object.runInThisContext (vm.js:303:10)
   at Module._compile (internal/modules/cjs/loader.js:657:28)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

   at Module.load (internal/modules/cjs/loader.js:599:32)
   at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
   at Function.Module._load (internal/modules/cjs/loader.js:530:3)
   at Module.require (internal/modules/cjs/loader.js:637:17)
   at require (internal/modules/cjs/helpers.js:22:18)
dh_auto_test: /usr/bin/node -e require\(\".\"\) returned exit code 1


Same error when changing package.json#main to dist/dagre-d3.js (umd 
format).

Bug#930223: [Pkg-javascript-devel] need help with building node-dagre-d3-renderer with webpack

[Pirate Praveen]

Control: tag -1 help

On Tue, 25 Jun, 2019 at 1:49 PM, Pirate Praveen 
 wrote:
While looking for something else in package.json, I realized, there 
was a line excluding node_modules and there was two places I needed 
to update. With the following patch, webpack is successful.


Now there is another error (tried replacing commonjs2 with commonjs, 
also tried with nodejs 12),


  dh_auto_test --buildsystem=nodejs
/usr/bin/node -e require\(\".\"\)
/<>/dist/dagre-d3.core.js:950
function (node, name, id, index, group, timing) {
^

SyntaxError: Unexpected token (
   at new Script (vm.js:79:7)
   at createScript (vm.js:251:10)
   at Object.runInThisContext (vm.js:303:10)
   at Module._compile (internal/modules/cjs/loader.js:657:28)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

   at Module.load (internal/modules/cjs/loader.js:599:32)
   at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
   at Function.Module._load (internal/modules/cjs/loader.js:530:3)
   at Module.require (internal/modules/cjs/loader.js:637:17)
   at require (internal/modules/cjs/helpers.js:22:18)
dh_auto_test: /usr/bin/node -e require\(\".\"\) returned exit code 1

Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files

[Chris Lamb]

forwarded 931039 
https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/7
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/7


Regards,

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

Bug#905226: Acknowledgement (openssh-server: SSH AuthorizedKeysCommand hangs when output is too large)

[Moritz Muehlenhoff]

On Mon, Aug 06, 2018 at 12:04:46PM +0200, Dennis Schridde wrote:
> I confirm that the patch [1] to the upstream bug report [2] solves the issue 
> for us.

JFTR, we've also run into this at work at the Wikimedia Foundations's 
Phabricator
installation (https://phabricator.wikimedia.org/T224677) and can confirm
that the attached patch fixes it.

Colin, from my PoV this seems suitable for an update shipped in
a Stretch point release. I'd be happy to take care of an upload and
interacting with SRMs if you agree.

Cheers,
Moritz

diff -Naur openssh-7.4p1.orig/debian/patches/fix-deadlock-in-keys-principals-command.patch openssh-7.4p1/debian/patches/fix-deadlock-in-keys-principals-command.patch
--- openssh-7.4p1.orig/debian/patches/fix-deadlock-in-keys-principals-command.patch	1970-01-01 01:00:00.0 +0100
+++ openssh-7.4p1/debian/patches/fix-deadlock-in-keys-principals-command.patch	2019-06-25 11:04:11.723638028 +0200
@@ -0,0 +1,37 @@
+From ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2 Mon Sep 17 00:00:00 2001
+From: "d...@openbsd.org" 
+Date: Fri, 30 Dec 2016 22:08:02 +
+Subject: [PATCH] upstream commit
+
+fix deadlock when keys/principals command produces a lot of
+output and a key is matched early; bz#2655, patch from jboning AT gmail.com
+
+Upstream-ID: e19456429bf99087ea994432c16d00a642060afe
+---
+ auth2-pubkey.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/auth2-pubkey.c b/auth2-pubkey.c
+index 20f3309e1..70c021589 100644
+--- a/auth2-pubkey.c
 b/auth2-pubkey.c
+@@ -727,6 +727,9 @@ match_principals_command(struct passwd *user_pw, const struct sshkey *key)
+ 
+ 	ok = process_principals(f, NULL, pw, cert);
+ 
++	fclose(f);
++	f = NULL;
++
+ 	if (exited_cleanly(pid, "AuthorizedPrincipalsCommand", command) != 0)
+ 		goto out;
+ 
+@@ -1050,6 +1053,9 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key)
+ 
+ 	ok = check_authkeys_file(f, options.authorized_keys_command, key, pw);
+ 
++	fclose(f);
++	f = NULL;
++
+ 	if (exited_cleanly(pid, "AuthorizedKeysCommand", command) != 0)
+ 		goto out;
+ 
diff -Naur openssh-7.4p1.orig/debian/patches/series openssh-7.4p1/debian/patches/series
--- openssh-7.4p1.orig/debian/patches/series	2019-03-01 17:19:28.0 +0100
+++ openssh-7.4p1/debian/patches/series	2019-06-25 11:06:56.429841721 +0200
@@ -44,3 +44,4 @@
 have-progressmeter-force-update-at-beginning-and-end-transfer.patch
 check-filenames-in-scp-client.patch
 scp-handle-braces.patch
+fix-deadlock-in-keys-principals-command.patch

Bug#931056: debian-installer: keyboard setup skipped when using initrd preseeding

[Christian Rudolph]

Package: debian-installer
Version: 20190410
Severity: normal
Tags: d-i

Dear Maintainer,

when installing debian using initrd preseeding, keyboard setup gets
skipped completely.
After some debugging and code reading I found out that the root cause
is the /var/run/auto-install.active file, which doesn't get updated when
using plain initrd preseeding. The file-preseed.postinst and
network-preseed.postinst installation steps both update the file
correctly.

My additional boot options were auto=true and keymap=de. Manually adding
file=file:///preseed.cfg fixed this issue.

This behavior is unexpected, because preseeding succeeds successfully in
every other aspect.

Kind regards,

Christian

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3

[Ilias Tsitsimpis]

Hey Paul,

It looks like everything has been rebuilt without errors. Moreover,
git-annex now works, so I assume that the problem has been resolved.

Could you please unblock ghc/8.4.4+dfsg1-3 as well as every Haskell
package that was rebuilt on armel? One exception to the above is the
taffybar package, which has a newer version in unstable than in testing,
and was on my binNMU list by mistake. Thankfully, this is a leaf package
(no other Haskell libraries depend on it) so it is safe to first allow
all other packages to migrate to testing and then binNMU it directly on
testing.

Please let me know if there is anything else I can do to help.

Cheers,

-- 
Ilias

Bug#931044: Quick workaround

[jens persson]

A quick workaround to get our old environments to work was to remove the
f:s on line 1014 and 1015 in /usr/lib/python3.4/http/client.py as:
raise InvalidURL("URL can't contain control characters. {url!r}
"
 "(found at least {match.group()!r})")

This will give bad error messages but allow things to work.

/jp

-- 
jens persson

Mäster Olofsväg 24
S-224 66 LUND;SWEDEN

Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3

[Ilias Tsitsimpis]

On Tue, Jun 25, 2019 at 09:24AM, Emanuele Olivetti wrote:
> I am very happy to announce that git-annex v.7.20190129-3+b1 for armel
> works perfectly on my QNAP TS-219P (armv5tel)!

Great news! Thank you for helping us out with this.

Best,

-- 
Ilias

Bug#930932: zenity: Zenity crashes out on Athlon XP CPU.

[Alberto Garcia]

On Tue, Jun 25, 2019 at 09:04:25AM +1000, Iris (Delta) wrote:

> If you do still intend to test any packages on Athlon XP era
> hardware I would be happy to help.

This is a test build of webkit2gtk 2.24.2-2 backported for stretch:

https://people.debian.org/~berto/webkit2gtk/

If you can test them on your system I'd appreciate it!

The SHA256 sums are signed by me.

Berto

Bug#931055: ITP: r-bioc-complexheatmap -- make complex heatmaps using GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-complexheatmap -- make complex heatmaps using GNU R
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-complexheatmap
  Version : 2.0.0
  Upstream Author : Zuguang Gu
* URL : https://bioconductor.org/packages/ComplexHeatmap/
* License : MIT
  Programming Lang: GNU R
  Description : make complex heatmaps using GNU R
 Complex heatmaps are efficient to visualize associations
 between different sources of data sets and reveal potential patterns.
 Here the ComplexHeatmap package provides a highly flexible way to arrange
 multiple heatmaps and supports various annotation graphics.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-complexheatmap

Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files (was: "Re: debhelper: something in the dh sequencer changes the tIME chunk of installed PNGs")

[Chris Lamb]

retitle 931039 dh-strip-nondeterminism: Does not appear to clamp timestamps in 
PNG files
thanks

Hi,

> While I’m sure the reproducible builds people appreciate
> limiting the mtime, raising it is not done otherwise.

Yes, it is curious why strip-nondeterminism is not "clamping" the
timestamps here, in other words only changing them to the changelog
date if they are newer than this time.

(Just as an aside, how come the tests fail? Are they looking
specifically for these timestamps or is it just that the files have
been changed at all?)


Best wishes,

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

Bug#931044: CVE-2019-9740-CVE-2019-9947.diff

[Olivier Bonvalet]

Hi,

in the patch CVE-2019-9740-CVE-2019-9947.diff, the code use "formatted
string literals", which is a Python 3.6 feature.

Bug#931054: ITP: r-cran-cowplot -- GNU R streamlined plot theme and plot annotations for 'ggplot2'

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-cowplot -- GNU R streamlined plot theme and plot 
annotations for 'ggplot2'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-cowplot
  Version : 0.9.4
  Upstream Author : Claus O. Wilke,
* URL : https://cran.r-project.org/package=cowplot
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R streamlined plot theme and plot annotations for 
'ggplot2'
 Some helpful extensions and modifications to the 'ggplot2'
 package. In particular, this package makes it easy to combine multiple
 'ggplot2' plots into one and label them with letters, e.g. A, B, C, etc.,
 as is often required for scientific publications. The package also provides
 a streamlined and clean theme that is used in the Wilke lab, hence the
 package name, which stands for Claus O. Wilke's plot package.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-cowplot