Bug#927165: debian-installer: improve support for LUKS

[Roger Shimizu]

On Tue, Jun 11, 2019 at 12:06 AM Guilhem Moulin  wrote:
>
> Hi there,
>
> On Mon, 15 Apr 2019 at 23:24:19 +0200, Cyril Brulebois wrote:
> >>> One could argue that cryptodisk support has never been supported by
> >>> d-i anyway,
> >>
> >> Yup, and I suppose that's why I overlooked this in my mail to
> >> debian-boot :-P  Jonathan Carter had a similar report last week
> >>
> >> https://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/2019-April/008196.html
> >
> > While I'm usually fine to dismiss some bug reports as “it's unsupported,
> > sorry”, making users' life harder doesn't seem really reasonable… :/
>
> During last week's gathering at MiniDebConf Hamburg we (cryptsetup package
> maintainer + KiBi) talked and came up with the following guide/notes:
>
> https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

Thank for the above doc, which is quite easy understanding and straightforward!
I didn't notice this until it's mentioned by release announcement of
D-I RC2 [1].

I confirmed with /boot set up in LUKS1, everything works fine.
It‘d configure non encrypted /boot when in D-I, then after finishing
D-I, and reboot to system, manually make LUKS1 for /boot partition.

However, I found adding:
  GRUB_PRELOAD_MODULES="luks cryptodisk"
to /etc/default/grub is not necessary.
  GRUB_ENABLE_CRYPTODISK=y
is the only setting need to append manually.
(/etc/fstab /etc/crypttab need to be edited for sure)

Thanks again for your effort on the guide/notes above!

[1] https://lists.debian.org/debian-devel-announce/2019/06/msg5.html
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#931214: ImportError: No module named oslo.config

[Paul Gevers]

Hi Thomas,

On 29-06-2019 23:02, Thomas Goirand wrote:
> On 6/29/19 10:12 AM, Paul Gevers wrote:
>> On Fri, 28 Jun 2019 13:52:43 +0200 =?iso-8859-1?Q?J=F6?= Fahlke
>>  wrote:
>>> Package: python-os-collect-config
>>> Version: 0.1.15-1
>>> Severity: grave
>>
>> This is on the radar of the release team, due to the very late time in
>> the release. Please, any comment from your side helps judging what to do.
>>
>>> I'm trying to use os-collect-config in a Debian stretch instance in an
>>> openstack cluster.  However, running it immediately leads to an import 
>>> error:
>>
>> [...]
>>
>>> ImportError: No module named oslo.config

> It looks like it's just missing a runtime dependency. Just manually
> installing oslo.config would fix this. So I do contest that the package
> is not usable. It is, as long as you install pyhon-oslo.config.

Did you check that that dependency is missing? I checked before and I
believe that python-oslo.config is in the listed dependencies *and*
installed on the machine where the log came from. What am I missing?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk

[Roger Shimizu]

After reading release announcement of D-I RC2 [1], it's got my
attention that there's an well written doc [2].
It's mentioned that /boot should be in LUKS1, due to grub doesn't
support LUKS2 yet [3], which is why this ticket originally reported, I
guess.

I confirmed with /boot set up in LUKS1, everything works fine.
It‘d configure non encrypted /boot when in D-I, then after finishing
D-I, and reboot to system, manually make LUKS1 for /boot partition.
Detail procedure is in the doc [2].

[1] https://lists.debian.org/debian-devel-announce/2019/06/msg5.html
[2] https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
[3] https://savannah.gnu.org/bugs/?55093
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#931267: times out and drops into useless emergency shell with fsck still ongoing

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Steve!

Am 30.06.19 um 01:46 schrieb Steve McIntyre:

> [ Ignore the system info etc. below - I'm running reportbug on a
>   different system. ]
> 
> I've just dist-upgraded my headless home firewall/server from Stretch
> to Buster. I did the usual task of config file merging. and then
> rebooted the machine. It didn't come up on the network again
> afterwards.
> 
> After rummaging around to connect a serial cable, there was no
> interaction on the console so I rebooted again. Now I see that the
> machine is running a fsck on the multiple large filesystems (Debian
> mirror, video/audio data etc.) Fine - the machine had not been
> rebooted in a long time, so the fsck was overdue. Then I see that
> systemd has decided to time out startup of services and drop me into
> an Emergency shell. With fsck going on and writing to the console, I
> cannot useful interact with the shell. The fsck completed
> successfully, but I had a headless machine that still needed
> interaction to make it work again.
> 
> Several points/questions:
> 
>  * Why on earth do things have a short timeout when fsck is still
>running? It's normal for fsck on a large fs to take a long time,
>and this should not break bootup. Especially not on a headless box.

This is odd. /lib/systemd/system/systemd-fsckd@.service uses
"TimeoutSec=0", so it should not timeout.

I quickly gave this a test. See
https://people.debian.org/~biebl/boot.mp4
I artifically modified systemd-fsckd@.service to sleep for 200s to
simulate a long fsck, I chose this deliberate to be > 180s, which is the
default systemd timeout for services.
As you can see, after 30s the eye-of-cylon animation kicks in and after
300s the boot proceeds and successfully completes.
This is even a more elaborate setup with LVM and stuff.

So I guess we need more information to debug this. Do you remember which
job timed out? Do you have any logs from this failed boot which could
give a clue which service triggered the start of the emergency shell?


>  * Why does systemd try to start an Emergency shell on an already-busy
>console? This is *not* useful.

The default output goes to /dev/console, i.e. the currently active. I
think what you are seeing here is another manifestation of
https://github.com/systemd/systemd/issues/1840

>  * I haven't tried to reproduce this, but the initial interaction on
>the console seemed to show a hung machine. I had no useful
>interaction there. Is the Emergency shell setup meant to prompt
>again on password failure if I just hit  several times?

It should, yes.

-- 
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#931223: [Debian-science-sagemath] Fwd: sagemath: sage test fails to test sagetex example_doctest.sage generated from sagetex example.tex

[Jerome BENOIT]

On 30/06/2019 02:47, Dima Pasechnik wrote:
> On Sat, Jun 29, 2019 at 11:58 AM Jerome BENOIT  wrote:
>>
>> Hello,
>>
>> On 29/06/2019 12:26, Dima Pasechnik wrote:
>>> On Fri, Jun 28, 2019 at 3:56 PM Jerome BENOIT  wrote:




  Forwarded Message 
 Subject: sagemath: sage test fails to test sagetex example_doctest.sage 
 generated from sagetex example.tex
 Date: Fri, 28 Jun 2019 18:25:20 +0400
 From: Jerome Benoit 
 To: Debian Bug Tracking System 

 Source: sagemath
 Version: 8.6-6
 Severity: normal

 Dear Maintainer,

 for the sake of curiosity, I have just tried to doctest the sage script 
 generated
 by SageTeX for the example.tex : the test reveals an issue with 
 sage-runtests .
 The issue can be reproduce as follows (when sagetex-doc is installed):

 cd 
 cp -p /usr/share/doc/sagetex/examples/example.tex .
 pdflatex example.tex
 sage -t example_doctest.sage

 The last command gives:

 Traceback (most recent call last):
>>>
>>> Start Sage shell before doing `sage -t ...`, by running
>>> `sage -sh`. Then everything should be set up properly to let
>>> `sage -t` work.
>>
>> The issue remains. This is consistent with the remark previously made by 
>> Tobias.
> 
> However, the `sage -sh` way works for me on a recent vanilla Sage
> install, so it must be a discrepancy with Debian here.

This is what Tobias told, and it is why it is a bug.

Jerome

> 
> Dima
> 
>>
>> Thanks,
>> Jerome
>>
>>>
>>> HTH
>>> Dima
>>>
>>>
   File "/usr/share/sagemath/bin/sage-runtests", line 162, in 
 DC = DocTestController(options, args)
 File "/usr/lib/python2.7/dist-packages/sage/doctest/control.py", 
 line 357, in __init__
 for pkg in list_packages('optional', local=True).values():
 File "/usr/lib/python2.7/dist-packages/sage/misc/package.py", line 
 228, in list_packages
 for p in os.listdir(SAGE_PKGS):
 OSError: [Errno 2] No such file or directory: 
 '/usr/share/sagemath/build/pkgs'

 As it does not look as a sagetex issue but rather as a sagemath issue, I 
 submitted this issue
 as sagemath bug.

 Thanks,
 Jerome



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

 Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
 LANGUAGE=en_GB:en (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: sysvinit (via /sbin/init)

 ___
 Debian-science-sagemath mailing list
 debian-science-sagem...@alioth-lists.debian.net
 https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
>>>
>>> ___
>>> Debian-science-sagemath mailing list
>>> debian-science-sagem...@alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
>>>
>>
>> --
>> Jerome BENOIT | calculus+at-rezozer^dot*net
>> https://qa.debian.org/developer.php?login=calcu...@rezozer.net
>> AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
>>
>> ___
>> Debian-science-sagemath mailing list
>> debian-science-sagem...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
> 
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#931268: imagej: ImageJ does not launch

[Andreas Tille]

Hi,

thanks for this bug report.  Unfortunately it is to late for Buster to
fix it since we are in deep freeze.  You have to options to deal with
this on your local installation:

   1. apt get install dpkg-dev
   2. export JAVA_HOME=/usr/lib/jvm/java-1.11.0-openjdk-amd64
  (or whatever JDK you are using)

We'll come up with a proper fix once Buster is released but for the
moment this should help you on your installation.

Kind regards

 Andreas.

On Sun, Jun 30, 2019 at 12:57:05AM +0100, Keng Wooi Ng wrote:
> Package: imagej
> Version: 1.52j-1
> Severity: important
> 
> Dear Maintainer,
> 
> Installed ImageJ from the repo on a fresh installation of Debian 10. Clicking
> the launcher in GNOME should, but does not, launch ImageJ (no apparent 
> response
> shown). Launching it from the command line produces the following error:
> 
> /usr/bin/imagej: line 32: dpkg-architecture: command not found
> 
> This seems to be an issue with the way /usr/bin/imagej tries to detect the JVM
> on line 32. It uses dpkg-architecture which isn't found on a default
> installation.
> 
> Doing "apt search dpkg-architecture" indicates it's associated with dh-exec. I
> installed dh-exec and it solved the problem, but that also pulled in a bunch 
> of
> other packages.
> 
> After some digging, it seems the dpkg-dev package is where dpkg-architecture 
> is
> found. However, dpkg-dev is not installed by default and is not listed as a
> dependency for the imagej package.
> 
> Not sure if it's useful, but I used the netinst iso (Buster RC2) for this 
> clean
> install of Debian 10. GNOME is the only desktop environment selected during
> installation.
> 
> 
> 
> -- 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_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages imagej depends on:
> ii  default-jre [java6-runtime] 2:1.11-71
> ii  libij-java  1.52j-1
> ii  openjdk-11-jre [java6-runtime]  11.0.3+7-5
> 
> imagej recommends no packages.
> 
> imagej suggests no packages.
> 
> -- no debconf information
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#673273: (fwd) Re: Bug#673273: texlive-pstricks: auto-pst-pdf.sty unusable without ifplatform

[Norbert Preining]

Hi Karl,

here down at Debian we see the following:
auto-pst-pdf.sty needs ifplatform.sty
But ifplatform is in collection-latexextra, and auto-pst-pdf in
pstricks.

I made a git grep seaching for ifplatform in texmf-dist/tex, and found:
latex/asyfig/asyfig.sty
latex/asyfig/asyprocess.sty
latex/asypictureb/asypictureB.sty
latex/dot2texi/dot2texi.sty
collection-pictures

latex/auto-pst-pdf-lua/auto-pst-pdf-lua.sty
collection-luatex

latex/auto-pst-pdf/auto-pst-pdf.sty
latex/pdftricks2/pdftricks2.sty
latex/pstricks/pst-platform.sty
collection-pstricks

latex/autopdf/autopdf.sty
latex/hardwrap/hardwrap.sty
latex/minted/minted.sty
latex/minted/minted1.sty
latex/moodle/moodle.sty
latex/pstool/pstool.sty
latex/svg/svg-extract.sty
latex/svg/svg.sty
c-latexextra

latex/lwarp/lwarp.sty
c-latexrecommended

latex/mpgraphics/mpgraphics.sty
c-metapost

latex/tudscr/tudscrmanual.cls
latex/tudscr/tudscrtutorial.sty
c-publishers

It looks like a good idea to move ifplatform to collection-base ???
(Not -pstricks as Hilmar recommends, though)

WDYT?

Norbert



- Forwarded message from Hilmar Preuße  -

> Date: Sat, 29 Jun 2019 20:58:07 +0200
> From: Hilmar Preuße 
> To: Norbert Preining 
> Cc: 673...@bugs.debian.org
> Subject: Re: Bug#673273: texlive-pstricks: auto-pst-pdf.sty unusable without 
> ifplatform
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Am 17.05.2012 um 14:50 teilte Patrice Duroux mit:
> 
> Hi Norbert,
> 
> > But I have found that ifplatform is currently in texlive-latex-extra.
> > 
> Could you coordinate w/ TL upstream to move ifplatform to
> texlive-pstricks(-doc). AFAICT this is a quite small package:
> 
> hille@sid:~ $ apt-file search ifplatform
> texlive-latex-extra:
> /usr/share/texlive/texmf-dist/tex/latex/ifplatform/ifplatform.sty
> texlive-latex-extra-doc: /usr/share/doc/texlive-doc/latex/ifplatform/README
> texlive-latex-extra-doc:
> /usr/share/doc/texlive-doc/latex/ifplatform/ifplatform.pdf
> 
> So it should not have much impact.
> 
> Thanks,
>   Hilmar
> --
> #206401 http://counter.li.org

- End forwarded message -

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#670654: couldn't recognize image format debian-logo.png

[Yamandu Ploskonka]

reproduced bug multiple times while running Update Manager for LinuxCNC
(wheezy)

nevertheless, the update process ended with success (though it was a real
PIB to set the sources for the update to work)

Bug#931268: imagej: ImageJ does not launch

[Keng Wooi Ng]

Package: imagej
Version: 1.52j-1
Severity: important

Dear Maintainer,

Installed ImageJ from the repo on a fresh installation of Debian 10. Clicking
the launcher in GNOME should, but does not, launch ImageJ (no apparent response
shown). Launching it from the command line produces the following error:

/usr/bin/imagej: line 32: dpkg-architecture: command not found

This seems to be an issue with the way /usr/bin/imagej tries to detect the JVM
on line 32. It uses dpkg-architecture which isn't found on a default
installation.

Doing "apt search dpkg-architecture" indicates it's associated with dh-exec. I
installed dh-exec and it solved the problem, but that also pulled in a bunch of
other packages.

After some digging, it seems the dpkg-dev package is where dpkg-architecture is
found. However, dpkg-dev is not installed by default and is not listed as a
dependency for the imagej package.

Not sure if it's useful, but I used the netinst iso (Buster RC2) for this clean
install of Debian 10. GNOME is the only desktop environment selected during
installation.



-- 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_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages imagej depends on:
ii  default-jre [java6-runtime] 2:1.11-71
ii  libij-java  1.52j-1
ii  openjdk-11-jre [java6-runtime]  11.0.3+7-5

imagej recommends no packages.

imagej suggests no packages.

-- no debconf information

Bug#931267: times out and drops into useless emergency shell with fsck still ongoing

[Steve McIntyre]

Package: systemd
Version: 241-5
Severity: important

Hi,

[ Ignore the system info etc. below - I'm running reportbug on a
  different system. ]

I've just dist-upgraded my headless home firewall/server from Stretch
to Buster. I did the usual task of config file merging. and then
rebooted the machine. It didn't come up on the network again
afterwards.

After rummaging around to connect a serial cable, there was no
interaction on the console so I rebooted again. Now I see that the
machine is running a fsck on the multiple large filesystems (Debian
mirror, video/audio data etc.) Fine - the machine had not been
rebooted in a long time, so the fsck was overdue. Then I see that
systemd has decided to time out startup of services and drop me into
an Emergency shell. With fsck going on and writing to the console, I
cannot useful interact with the shell. The fsck completed
successfully, but I had a headless machine that still needed
interaction to make it work again.

Several points/questions:

 * Why on earth do things have a short timeout when fsck is still
   running? It's normal for fsck on a large fs to take a long time,
   and this should not break bootup. Especially not on a headless box.

 * Why does systemd try to start an Emergency shell on an already-busy
   console? This is *not* useful.

 * I haven't tried to reproduce this, but the initial interaction on
   the console seemed to show a hung machine. I had no useful
   interaction there. Is the Emergency shell setup meant to prompt
   again on password failure if I just hit  several times?
 
-- Package-specific info:

-- 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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-5

Versions of packages systemd suggests:
ii  policykit-10.105-25
ii  systemd-container  241-5

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 241-5

-- Configuration Files:
/etc/systemd/logind.conf changed [not included]

-- no debconf information

Bug#930869: Don't release with buster

[Michael Biebl]

Control: severity -1 serious

-- 
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#931266: e2fsprogs: Build-Depends on udev and systemd on non-Linux architectures

[James Clarke]

Source: e2fsprogs
Version: 1.45.0-1
Severity: important

Hi,
As of the above version, e2fsprogs Build-Depends on udev and systemd
(and cron too which, whilst somewhat perplexing, is not the issue here),
thereby rendering its build dependencies unsatisfiable on non-Linux
architectures, namely GNU/kFreeBSD and GNU/Hurd (the latter being
particularly important given it uses ext2fs as its filesystem). I went
digging to see why this was but the commit[1] that added it isn't any
more enlightening. I haven't tried building it without those packages, but can
only assume the upstream code still works without udev and systemd. Can we
please have this fixed in Debian so e2fsprogs builds everywhere again?

Regards,
James

[1] 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/debian/control?h=debian/master=68e00dc507acc3f3381f8f60bce71ecae371f794

Bug#931256: Failure of DHE key exchanges with OpenSSL security level 2

[Julien ÉLIE]

I think that we are way too late for 10.0, but I will make a new package
in ~1 month aiming for 10.1.


That would be great.
Thanks, Marco.

--
Julien

Bug#931211: s2s connections are broken after upgrading to buster

[Marco d'Itri]

On Jun 29, Philipp Huebner  wrote:

> Could you try my no-change rebuild of ejabberd under buster?
> https://apt.debalance.de/pool/main/e/ejabberd/ejabberd_18.12.1-2.1_i386.deb
Thank you, still broken.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#931250:

[Jochen Sprickerhof]

Control: retitle -1 mariaDB example configuration
Control: severity -1 wishlist
Control: tag -1 moreinfo

Hi Mechtilde,

* Mechtilde Stehmann  [2019-06-29 13:54]:

I create a config file to use Hibiscus with MariaDB as a backend.

Therefore you need an additional config  file which is described under
https://www.willuhn.de/wiki/doku.php?id=support:mysql#hibiscus_konfigurieren.


The diff contains my anonymised config file to publish as an example


Thanks. Looking at the website, I think the example file is not really 
usable without the website documentation. Could you add some 
documentation for a README.Debian?


Cheers Jochen


signature.asc
Description: PGP signature

Bug#931214: ImportError: No module named oslo.config

[Thomas Goirand]

On 6/29/19 10:12 AM, Paul Gevers wrote:
> Control: tags -1 sid buster stretch
> 
> Dear OpenStack maintainers,
> 
> On Fri, 28 Jun 2019 13:52:43 +0200 =?iso-8859-1?Q?J=F6?= Fahlke
>  wrote:
>> Package: python-os-collect-config
>> Version: 0.1.15-1
>> Severity: grave
> 
> This is on the radar of the release team, due to the very late time in
> the release. Please, any comment from your side helps judging what to do.
> 
>> I'm trying to use os-collect-config in a Debian stretch instance in an
>> openstack cluster.  However, running it immediately leads to an import error:
> 
> [...]
> 
>> ImportError: No module named oslo.config
> 
> Paul
> 

Hi Paul,

It looks like it's just missing a runtime dependency. Just manually
installing oslo.config would fix this. So I do contest that the package
is not usable. It is, as long as you install pyhon-oslo.config.

Of course, this needs to be fixed, as since it's too late for fixing
before buster, I can do such a fix for the first point release.

Cheers,

Thomas Goirand (zigo)

Bug#871721: After upgrade to stretch, booting fails due to late mounting of /var

[Michael Biebl]

Control: reassign -1 binfmt-support

On Fri, 11 Aug 2017 00:26:18 +0200 mat...@web.de wrote:
> Package: release-notes
> 
> After upgrading from jessie to stretch, the boot process fails and goes into 
> the emergency mode. Several programs try to access /var which is, however, 
> mounted later.
> 
> The Release Notes comment on /usr but not on /var:
> 
> https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en.html#late-mounting-usr
> 
> I got the system booting again after spending hours with reading man pages 
> and finally creating /etc/systemd/system/var.mount, a modified version of 
> /run/systemd/generator/var.mount:
> 
> [Unit]
> SourcePath=/etc/fstab
> Documentation=man:fstab(5) man:systemd-fstab-generator(8)
> Before=console-kit-log-system-start.service binfmt-support.service

That sounds like a bug in consolekit and/or binfmt-support (in stretch).
consolekit has been removed from the archive, which leaves binfmt-support.
binfmt-support.service uses DefaultDependencies=no [1], so is
responsible for declaring all necessary dependencies/orderings itself.

I'm thus re-assigning this bug to binfmt-support. Might be that this
issue is already fixed, but I'd like its maintainers have a look first.

Regards,
Michael



[1]
https://salsa.debian.org/debian/binfmt-support/blob/master/init/systemd/binfmt-support.service.in
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#931265: libapache2-mod-auth-mellon: CVE-2019-13038

[Salvatore Bonaccorso]

Source: libapache2-mod-auth-mellon
Version: 0.14.2-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libapache2-mod-auth-mellon.

CVE-2019-13038[0]:
| mod_auth_mellon through 0.14.2 has an Open Redirect via the
| login?ReturnTo= substring, as demonstrated by omitting the // after
| http: in the target URL.

see [1] for more information.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13038
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13038
[1] https://github.com/Uninett/mod_auth_mellon/issues/35#issuecomment-503974885

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#931211: s2s connections are broken after upgrading to buster

[Philipp Huebner]

Other than your user block being indented one more space than necessary
I don't see anything wrong.

Am 29.06.19 um 18:59 schrieb Marco d'Itri:
> acl:
>   admin:
>  user:
>- "xxx": "jabber.linux.it"
>- "xxx": "jabber.linux.it"

Could you try my no-change rebuild of ejabberd under buster?
https://apt.debalance.de/pool/main/e/ejabberd/ejabberd_18.12.1-2.1_i386.deb

Best wishes
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#931052: release-notes text proposal for bug 931052: webkit2gtk not supported on non-sse2 i386 hardware

[Justin B Rye]

Paul Gevers wrote:
> Justin B Rye wrote:
>> And how are we deciding when it's "WebKitGTK" and when it's
>> "webkit2gtk"?  Bear in mind that users have no easy way of mapping
>> from the name of a source package to the name of the specific library
>> they might or might not have installed.
> 
> To be honest, I don't know. Feeling?

The trouble with talking about WebKitGTK is that besides
libwebkit2gtk-* there are also a couple of packages like
libwebkitgtk3.0-cil that look as if they'd be relevant to this but
aren't.  Maybe we should only mention "webkit2gtk", which turns out
after all to be fairly transparently connected to the name of the main
library packages it builds (even if the -gtk2 suffix on one of them is
a bit mystifying).
 
>> This is also a bit short on concrete advice for users.
> 
> I see.
> 
>>  Could we add
>> something like
>> 
>> Users of a modern desktop environment with older (roughly,
>>  pre-Pentium IV) CPUs may wish to delay upgrading until then.
> 
> Reading again bug 930935 it seems that there are still devices in
> production, so age isn't a good qualifier. I put it in because it seems
> I don't have much inspiration for this at this moment.

I was thinking about mentioning both

dpkg -l | grep -i webkit2gtk

and grep sse2 /proc/cpuinfo

or combining them and saying to check if you get any output from

grep -q sse2 /proc/cpuinfo || dpkg -l | grep -i webkit2gtk

But maybe that's going too far.

>> None of my machines are this ancient, but "dpkg -l | grep -i webkit"
>> gives no output, so I would be safe anyway - right?
> 
> Close. https://tracker.debian.org/pkg/webkit2gtk shows that there is
> also javascriptcoregtk to grep.

It looks like the only way I'd have that is if I had manually
installed it to support some sort of local JavaScript GUI, and I'm
hoping I would remember writing one of those.
 
> How about the attached version?
> 
> Paul

> diff --git a/en/issues.dbk b/en/issues.dbk
> index cdf71c12..6f56d9d7 100644
> --- a/en/issues.dbk
> +++ b/en/issues.dbk
> @@ -288,6 +288,32 @@ $ sudo update-initramfs -u
>  
>
>  
> +  
> +WebKitGTK (initially) requires SSE2 support

Maybe "Webkit2gtk", or then again maybe just "WebKit".

> +
> +  Due to changes in the upstream code,  +  role="package">webkit2gtk has been built requiring SSE2
> +  support. Fixes for this in the Debian code came too late to be
> +  incorporated in the initial buster release. This means that systems 
> that
> +  don't have SSE2 support built into their CPU can't run applications 
> which
> +  use WebKitGTK, e.g. liferea or

Here it might say "applications that depend on libwebkit2gtk-*"?

> +  zenity. These applications will
> +  crash, most likely with an Illegal instruction error
> +  message.
> +
> +
> +  It is expected that webkit2gtk
> +  will support these older systems after the first update of  +  role="package">webkit2gtk in either a point release or

Simplifying:

 The first update of webkit2gtk 
is
 expected to restore support for these older systems, in either a point
 release or

> +  security update. Users of a modern desktop environment with older
> +  (roughly, pre-Pentium IV) CPUs may wish to delay upgrading until then.
> +  It is also intended that the buster-backports archive will receive an
> +  updated package once that archive opens up for uploads, so an 
> alternative
> +  could be to install webkit2gtk
> +  from there once it's available.
> +
> +  
> +
>
>  Noteworthy obsolete packages
>  



-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#931264: irssi: CVE-2019-13045

[Salvatore Bonaccorso]

Source: irssi
Version: 1.2.0-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/irssi/irssi/pull/1058
Control: found -1 1.0.7-1~deb9u1
Control: found -1 1.0.7-1
Control: found -1 0.8.18-1

Hi,

The following vulnerability was published for irssi.

CVE-2019-13045[0]:
| Irssi before 1.0.8, 1.1.x before 1.1.3, and 1.2.x before 1.2.1, when
| SASL is enabled, has a use after free when sending SASL login to the
| server.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13045
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13045
[1] https://github.com/irssi/irssi/pull/1058
[2] 
https://github.com/irssi/irssi/commit/5a67b983dc97caeb5df1139aabd0bc4f260a47d8

Regards,
Salvatore

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Michael Biebl]

Am 29.06.2019 um 19:52 schrieb Justin B Rye:
> diff --git a/en/issues.dbk b/en/issues.dbk
> index 2edb9838..bf007277 100644
> --- a/en/issues.dbk
> +++ b/en/issues.dbk
> @@ -203,33 +203,28 @@ $ sudo update-initramfs -u
>  
>  Module configuration for bonding and dummy interfaces
>  
> -  Administrators who are using channel bonding and/or dummy
> -  interfaces (for instance to configure a machine as a router), and
> -  who have set up module parameters in a file under
> -  /etc/modprobe.d, may need to change the name
> -  of the local configuration file used, to avoid these parameters
> -  being ignored after the upgrade to buster.
> -
> -
> -  In buster, udev ships a
> -  file /lib/modprobe.d/systemd.conf designed to
> -  make it easier to configure such interfaces using
> -  systemd-networkd. This contains the lines
> +  Systems using channel bonding and/or dummy interfaces, for instance to
> +  configure a machine as a router, may encounter problems upgrading to 
> buster.
> +  New versions of systemd 
> install a
> +  file /lib/modprobe.d/systemd.conf (intended to
> +  simplify configuration via systemd-networkd) which
> +  contains the lines
>  
>  
>   options bonding max_bonds=0
>   options dummy numdummies=0
>  
>  
> - A file in /lib/modprobe.d can be overridden by
> - one with the same name under /etc/modprobe.d,
> - but the names are processed in alphabetical order, so
> - /lib/modprobe.d/systemd.conf follows and
> - overrides (for instance)
> - /etc/modprobe.d/dummy.conf. Make sure that any
> - local configuration file has a name that sorts after
> - systemd.conf, such as
> - /etc/modprobe.d/zz-local.conf.
> +  Admins who were depending on different values will need to ensure they 
> are
> +  set in the correct way to take precedence. A file in
> +  /etc/modprobe.d will override one with the same 
> name
> +  under /lib/modprobe.d, but the names are
> +  processed in alphabetical order, so
> +  /lib/modprobe.d/systemd.conf follows and overrides
> +  (for instance) /etc/modprobe.d/dummy.conf. Make 
> sure
> +  that any local configuration file has a name that sorts after
> +  systemd.conf, such as
> +  /etc/modprobe.d/zz-local.conf.
>  
>

lgtm, fwiw.

Thanks Justin.

-- 
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#673273: texlive-pstricks: auto-pst-pdf.sty unusable without ifplatform

[Hilmar Preuße]

Am 17.05.2012 um 14:50 teilte Patrice Duroux mit:

Hi Norbert,


But I have found that ifplatform is currently in texlive-latex-extra.


Could you coordinate w/ TL upstream to move ifplatform to
texlive-pstricks(-doc). AFAICT this is a quite small package:

hille@sid:~ $ apt-file search ifplatform
texlive-latex-extra:
/usr/share/texlive/texmf-dist/tex/latex/ifplatform/ifplatform.sty
texlive-latex-extra-doc: /usr/share/doc/texlive-doc/latex/ifplatform/README
texlive-latex-extra-doc:
/usr/share/doc/texlive-doc/latex/ifplatform/ifplatform.pdf

So it should not have much impact.

Thanks,
  Hilmar
--
#206401 http://counter.li.org

Bug#931052: release-notes text proposal for bug 931052: webkit2gtk not supported on non-sse2 i386 hardware

[Paul Gevers]

Hi Justin,

On 29-06-2019 12:24, Justin B Rye wrote:
> And how are we deciding when it's "WebKitGTK" and when it's
> "webkit2gtk"?  Bear in mind that users have no easy way of mapping
> from the name of a source package to the name of the specific library
> they might or might not have installed.

To be honest, I don't know. Feeling?

> This is also a bit short on concrete advice for users.

I see.

>  Could we add
> something like
> 
> Users of a modern desktop environment with older (roughly,
>   pre-Pentium IV) CPUs may wish to delay upgrading until then.

Reading again bug 930935 it seems that there are still devices in
production, so age isn't a good qualifier. I put it in because it seems
I don't have much inspiration for this at this moment.

> None of my machines are this ancient, but "dpkg -l | grep -i webkit"
> gives no output, so I would be safe anyway - right?

Close. https://tracker.debian.org/pkg/webkit2gtk shows that there is
also javascriptcoregtk to grep.

How about the attached version?

Paul
diff --git a/en/issues.dbk b/en/issues.dbk
index cdf71c12..6f56d9d7 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -288,6 +288,32 @@ $ sudo update-initramfs -u
 
   
 
+  
+WebKitGTK (initially) requires SSE2 support
+
+  Due to changes in the upstream code, webkit2gtk has been built requiring SSE2
+  support. Fixes for this in the Debian code came too late to be
+  incorporated in the initial buster release. This means that systems that
+  don't have SSE2 support built into their CPU can't run applications which
+  use WebKitGTK, e.g. liferea or
+  zenity. These applications will
+  crash, most likely with an Illegal instruction error
+  message.
+
+
+  It is expected that webkit2gtk
+  will support these older systems after the first update of webkit2gtk in either a point release or
+  security update. Users of a modern desktop environment with older
+  (roughly, pre-Pentium IV) CPUs may wish to delay upgrading until then.
+  It is also intended that the buster-backports archive will receive an
+  updated package once that archive opens up for uploads, so an alternative
+  could be to install webkit2gtk
+  from there once it's available.
+
+  
+
   
 Noteworthy obsolete packages
 


signature.asc
Description: OpenPGP digital signature

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Justin B Rye]

Back from my walk in the lovely warm pouring rain...

Justin B Rye wrote:
> Michael Biebl wrote:
>> Am 29.06.19 um 15:09 schrieb Justin B Rye:
>>> [...] A file in
>>> +  /lib/modprobe.d can be overridden by one with 
>>> the
>>> +  same name under /etc/modprobe.d, but the names 
>>> are
>>> +  processed in alphabetical order, so
>> 
>> That sentence is a bit confusing: files with the same name are
>> overridden. period. there is no but.

Okay, coming back to it, it can't be helping that this is a useless
use of passive voice.  Swapping it around:

  [...] A file in
  /etc/modprobe.d will override one with the same
  name under /lib/modprobe.d, but the names are
  processed in alphabetical order, so [...]

This way we start off with the focus in the right place: on the
existing dummy.conf in /etc.  It's not a problem if an upstream
/lib/modprobe.d/dummy.conf turns up, *but*...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 2edb9838..bf007277 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -203,33 +203,28 @@ $ sudo update-initramfs -u
 
 Module configuration for bonding and dummy interfaces
 
-  Administrators who are using channel bonding and/or dummy
-  interfaces (for instance to configure a machine as a router), and
-  who have set up module parameters in a file under
-  /etc/modprobe.d, may need to change the name
-  of the local configuration file used, to avoid these parameters
-  being ignored after the upgrade to buster.
-
-
-  In buster, udev ships a
-  file /lib/modprobe.d/systemd.conf designed to
-  make it easier to configure such interfaces using
-  systemd-networkd. This contains the lines
+  Systems using channel bonding and/or dummy interfaces, for instance to
+  configure a machine as a router, may encounter problems upgrading to buster.
+  New versions of systemd install a
+  file /lib/modprobe.d/systemd.conf (intended to
+  simplify configuration via systemd-networkd) which
+  contains the lines
 
 
  options bonding max_bonds=0
  options dummy numdummies=0
 
 
- A file in /lib/modprobe.d can be overridden by
- one with the same name under /etc/modprobe.d,
- but the names are processed in alphabetical order, so
- /lib/modprobe.d/systemd.conf follows and
- overrides (for instance)
- /etc/modprobe.d/dummy.conf. Make sure that any
- local configuration file has a name that sorts after
- systemd.conf, such as
- /etc/modprobe.d/zz-local.conf.
+  Admins who were depending on different values will need to ensure they are
+  set in the correct way to take precedence. A file in
+  /etc/modprobe.d will override one with the same name
+  under /lib/modprobe.d, but the names are
+  processed in alphabetical order, so
+  /lib/modprobe.d/systemd.conf follows and overrides
+  (for instance) /etc/modprobe.d/dummy.conf. Make sure
+  that any local configuration file has a name that sorts after
+  systemd.conf, such as
+  /etc/modprobe.d/zz-local.conf.
 
   
 

Bug#931261: release-notes: Paragraph for release notes from Debian Med team

[Justin B Rye]

Andreas Tille wrote:
> Package: release-notes
> Severity: normal
> Tags: patch
> 
> Hi release team,

(I'm not in that team, or even that league!)

> I hope it is not to late for Debian Med release notes paragraph (I was
> waiting for comments from the team ...),  Here is a draft paragraph:

Looks good; so we wrap it in ..
I don't see any other similar ads for new features in blends, but the
obvious place to put it is whats-new.dbk.  I'm not sure where... oh,
but now I notice the stretch release-notes had it as just the
second-last entry on the page.  It fits well enough right at the end.

> News from Debian Med Blend
> 
> The Debian Med team has added several new packages and updates for
> software targeting life sciences and medicine.  The effort to add
> Continuous Integration support for the packages in this field was (and
> will be) continued.
> 
> To install packages maintained by the Debian Med team, install the
> metapackages named med-*, which are at version 3.3 for Debian Buster.
> Feel free to visit the
> http://blends.debian.org/med/tasks;>Debian Med tasks 
> pages
> to see the full range of biological and medical software available in 
> Debian.
> 

Patch attached implementing that.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/whats-new.dbk b/en/whats-new.dbk
index 0e0d67ce..943fa148 100644
--- a/en/whats-new.dbk
+++ b/en/whats-new.dbk
@@ -617,5 +617,24 @@ Among many others, this release also includes the following software updates:
   
 
 
+
+  
+  News from Debian Med Blend
+  
+The Debian Med team has added several new packages and updates for
+software targeting life sciences and medicine. The effort to add
+Continuous Integration support for the packages in this field was (and
+will be) continued.
+  
+  
+To install packages maintained by the Debian Med team, install the
+metapackages named med-*, which are at version
+3.3 for Debian buster. Feel free to visit the
+http://blends.debian.org/med/tasks;>Debian Med tasks
+pages to see the full range of biological and medical
+software available in Debian.
+  
+
+
 
 

Bug#931211: s2s connections are broken after upgrading to buster

[Marco d'Itri]

On Jun 29, Philipp Huebner  wrote:

> If you're willing to share your ejabberd configuration files I am happy
> to take a look, otherwise I don't know how to help you.
Thank you, I surely may have got something wrong in the conversion:

---
loglevel: 4

log_rotate_count: 0
log_rotate_date: ""

hosts:
  - "jabber.linux.it"

certfiles:
  - "/etc/ejabberd/ejabberd.pem"

define_macro:
  'TLS_CIPHERS': "HIGH:!aNULL:!eNULL:!3DES:@STRENGTH"
  'TLS_OPTIONS':
- "no_sslv3"
- "no_tlsv1"
- "no_tlsv1_1"
- "cipher_server_preference"
- "no_compression"

c2s_ciphers: 'TLS_CIPHERS'
s2s_ciphers: 'TLS_CIPHERS'
c2s_protocol_options: 'TLS_OPTIONS'
s2s_protocol_options: 'TLS_OPTIONS'

listen:
  -
port: 5222
ip: "::"
module: ejabberd_c2s
max_stanza_size: 262144
shaper: c2s_shaper
access: c2s
starttls_required: true
protocol_options: 'TLS_OPTIONS'
  -
port: 5223
ip: "::"
module: ejabberd_c2s
max_stanza_size: 262144
shaper: c2s_shaper
access: c2s
tls: true
protocol_options: 'TLS_OPTIONS'
  -
port: 5269
ip: "::"
module: ejabberd_s2s_in
max_stanza_size: 524288
  -
port: 5280
ip: "::"
module: ejabberd_http
request_handlers:
  "/api": mod_http_api
  "/bosh": mod_bosh
  "/ws": ejabberd_http_ws
captcha: true
register: true
tls: true
protocol_options: 'TLS_OPTIONS'
web_admin: true

disable_sasl_mechanisms:
  - "digest-md5"
  - "X-OAUTH2"

s2s_use_starttls: required

auth_password_format: scram


acl:
  admin:
 user:
   - "xxx": "jabber.linux.it"
   - "xxx": "jabber.linux.it"

  local:
user_regexp: ""
  loopback:
ip:
  - "127.0.0.0/8"
  - "::1/128"
  - ":::127.0.0.1/128"

access_rules:
  local:
- allow: local
  c2s:
- deny: blocked
- allow
  announce:
- allow: admin
  configure:
- allow: admin
  muc_create:
- allow: local
  pubsub_createnode:
- allow: local
  register:
- allow
  trusted_network:
- allow: loopback

api_permissions:
  "console commands":
from:
  - ejabberd_ctl
who: all
what: "*"
  "admin access":
who:
  - access:
  - allow:
- acl: loopback
- acl: admin
  - oauth:
- scope: "ejabberd:admin"
- access:
  - allow:
- acl: loopback
- acl: admin
what:
  - "*"
  - "!stop"
  - "!start"
  "public commands":
who:
  - ip: "127.0.0.1/8"
what:
  - "status"
  - "connected_users_number"

shaper:
  normal: 1000
  fast: 5

shaper_rules:
  max_user_sessions: 10
  max_user_offline_messages:
- 5000: admin
- 100
  c2s_shaper:
- none: admin
- normal
  s2s_shaper: fast

modules:
  mod_adhoc: {}
  mod_admin_extra: {}
  mod_announce:
access: announce
  mod_avatar: {}
  mod_blocking: {}
  mod_bosh: {}
  mod_caps: {}
  mod_carboncopy: {}
  mod_client_state: {}
  mod_configure: {}
  mod_disco: {}
  mod_echo: {}
  mod_fail2ban: {}
  mod_http_api: {}
  mod_last: {}
  mod_muc:
access:
  - allow
access_admin:
  - allow: admin
access_create: muc_create
access_persistent: muc_create
default_room_options:
  mam: true
  mod_muc_admin: {}
  mod_offline:
access_max_user_messages: max_user_offline_messages
  mod_ping: {}
  mod_pres_counter:
count: 5
interval: 60
  mod_privacy: {}
  mod_private: {}
  mod_pubsub:
access_createnode: pubsub_createnode
plugins:
  - "flat"
  - "pep"
force_node_config:
  "eu.siacs.conversations.axolotl.*":
access_model: open
  "storage:bookmarks":
access_model: whitelist
  mod_push: {}
  mod_push_keepalive: {}
  mod_register:
ip_access: trusted_network
  mod_roster:
versioning: true
  mod_s2s_dialback: {}
  mod_shared_roster: {}
  mod_sic: {}
  mod_stream_mgmt:
resend_on_timeout: if_offline
  mod_vcard:
search: false
  mod_vcard_xupdate: {}
  mod_version: {}

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#931051: firejail hangs on strace with the firefox or waterfox profile

[Reiner Herrmann]

Hi Vincent,

On Tue, Jun 25, 2019 at 10:00:32AM +0200, Vincent Lefevre wrote:
> zira:~> /usr/bin/firejail --allow-debuggers --profile=firefox strace /bin/ls
> Reading profile /etc/firejail/firefox.profile
> Reading profile /etc/firejail/firefox-common.profile
> Reading profile /etc/firejail/disable-common.inc
> Reading profile /etc/firejail/disable-interpreters.inc
> Reading profile /etc/firejail/disable-programs.inc
> Reading profile /etc/firejail/whitelist-common.inc
> Reading profile /etc/firejail/whitelist-var-common.inc
> Warning: networking feature is disabled in Firejail configuration file
> Parent pid 2285, child pid 2286
> Warning: An abstract unix socket for session D-BUS might still be available. 
> Use --net or remove unix from --protocol set.
> Post-exec seccomp protector enabled
> Seccomp list in: 
> @clock,@cpu-emulation,@debug,@module,@obsolete,@raw-io,@reboot,@resources,@swap,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,ni_syscall,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,request_key,setdomainname,sethostname,syslog,umount,umount2,userfaultfd,vhangup,vmsplice,
>  check list: @default-keep, prelist: 
> adjtimex,clock_adjtime,clock_settime,settimeofday,modify_ldt,lookup_dcookie,perf_event_open,process_vm_writev,delete_module,finit_module,init_module,_sysctl,afs_syscall,create_module,get_kernel_syms,getpmsg,putpmsg,query_module,security,sysfs,tuxcall,uselib,ustat,vserver,ioperm,iopl,kexec_load,kexec_file_load,reboot,set_mempolicy,migrate_pages,move_pages,mbind,swapon,swapoff,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,request_key,setdomainname,sethostname,syslog,umount2,userfaultfd,vhangup,vmsplice,
> Child process initialized in 78.27 ms
> 
> and nothing else occurs. This makes impossible to try to see why
> some application does not work in firejail.
> 
> Ditto when using --profile=/etc/firejail/firefox.profile directly
> (as given as an example for --allow-debuggers in the firejail(1)
> man page).
> 
> No problems with the default profile or without strace.

I can reproduce the problem.
When commenting out "apparmor" and the "seccomp.drop" line in the
profile, it is working. The reason is that strace needs to use the
ptrace syscall (which was disallowed by the profile) (and after allowing
it, apparmor also had further ptrace restrictions).

But it's strange that firejail just hangs instead of terminating.

Btw for debugging profiles maybe --trace or --tracelog could also help you.

I will ask upstream about your issue.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#931260: linux-image-4.19.0-5-amd64: Boot fail IO-APIC timer syncing causes kernel panic

[Kinky Nekoboi]

Hey Giorgio,

i have also trouble with the buster kernel:

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

maybe try earlyprintk=vga or an other value to get more verbose early
kernel output


Am 29.06.19 um 17:31 schrieb Giorgio Pioda:
> Package: src:linux
> Version: 4.19.37-5
> Severity: critical
> Tags: newcomer
> Justification: breaks the whole system
>
> Dear Maintainer,
>
> upgrade from stretch to buster (kernel from 4.9 to 4.19) makes the machine
> unbootable. IO-APIC timer syncing issue with kernel panic, very early during
> boot. apic=debug gives no clue. tsc=unstable as boot parameter doesn't help. I
> can boot 4.19 only with noapic (like right now as I report the bug).
>
> Machine has an old A8N SLI Deluxe mainboard. Bug looks like a regression of 
> bug
> #883294
>
> Best regards
>
> Giorgio
>
>
>
> -- Package-specific info:
> ** Version:
> Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
> 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)
>
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
> root=UUID=dae993a6-e557-44a9-a8b3-c35e5ab9a9ca noapic ro quiet
>
> ** Not tainted
>
> ** Kernel log:
> [5.185543] systemd[1]: Listening on Syslog Socket.
> [5.185640] systemd[1]: Started Forward Password Requests to Wall 
> Directory Watch.
> [5.186003] systemd[1]: Created slice User and Session Slice.
> [5.186137] systemd[1]: Listening on Journal Socket (/dev/log).
> [5.250873] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
> [5.276861] lp: driver loaded but no devices found
> [5.284765] ppdev: user-space parallel port driver
> [5.288381] parport_pc 00:05: reported by Plug and Play ACPI
> [5.288458] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
> [5.378056] lp0: using parport0 (interrupt-driven).
> [5.411730] loop: module loaded
> [5.465417] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> [5.521890] systemd-journald[224]: Received request to flush runtime 
> journal from PID 1
> [5.686063] audit: type=1400 audit(1561820978.475:2): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
> pid=269 comm="apparmor_parser"
> [5.797377] audit: type=1400 audit(1561820978.583:3): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" name="/usr/bin/evince" pid=270 
> comm="apparmor_parser"
> [5.797382] audit: type=1400 audit(1561820978.583:4): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" 
> name="/usr/bin/evince//sanitized_helper" pid=270 comm="apparmor_parser"
> [5.797385] audit: type=1400 audit(1561820978.583:5): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" 
> name="/usr/bin/evince-previewer" pid=270 comm="apparmor_parser"
> [5.797387] audit: type=1400 audit(1561820978.583:6): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" 
> name="/usr/bin/evince-previewer//sanitized_helper" pid=270 
> comm="apparmor_parser"
> [5.797389] audit: type=1400 audit(1561820978.583:7): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" 
> name="/usr/bin/evince-thumbnailer" pid=270 comm="apparmor_parser"
> [5.804884] gameport gameport0: NS558 PnP Gameport is pnp00:08/gameport0, 
> io 0x201, speed 908kHz
> [5.828810] audit: type=1400 audit(1561820978.615:8): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
> pid=277 comm="apparmor_parser"
> [5.851608] sr 6:0:0:0: Attached scsi generic sg0 type 5
> [5.851660] sd 5:0:0:0: Attached scsi generic sg1 type 0
> [5.870467] audit: type=1400 audit(1561820978.659:9): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" 
> name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=279 
> comm="apparmor_parser"
> [5.870472] audit: type=1400 audit(1561820978.659:10): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" 
> name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" 
> pid=279 comm="apparmor_parser"
> [5.897208] audit: type=1400 audit(1561820978.683:11): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" name="libreoffice-soffice" 
> pid=273 comm="apparmor_parser"
> [5.903336] media: Linux media interface: v0.10
> [5.954245] snd_intel8x0 :00:04.0: enabling device ( -> 0003)
> [5.954491] PCI Interrupt Link [LACI] enabled at IRQ 5
> [5.976870] videodev: Linux video capture interface: v2.00
> [6.037390] ivtv: Start initialization, version 1.4.3
> [6.037493] ivtv0: Initializing card 0
> [6.037496] ivtv0: Autodetected Hauppauge card (cx23416 based)
> [6.040612] k8temp :00:18.3: hwmon_device_register() is deprecated. 
> Please convert the driver to use hwmon_device_register_with_info().
> [6.056613] ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
> [6.061066] input: PC Speaker as 

Bug#931263: sponsorship-requests: blastem/0.6.3.2-1 -- Fast and accurate Genesis emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: blastem
   Version : 0.6.3.2-1
   Upstream Author : Michael Pavone 
 * URL : https://www.retrodev.com/blastem
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  blastem - Fast and accurate Genesis emulator

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blastem/blastem_0.6.3.2-1.dsc

  More information about BlastEm can be obtained from 
https://gitlab.com/coringao/blastem.

  Changes since the last upload:

  blastem (0.6.3.2-1) unstable; urgency=medium

  * New upstream release: 0.6.3.2

  blastem (0.6.3.1-1) unstable; urgency=medium

  * New upstream release (Closes: #926498)
  * Fix FTCBFS: (Thanks - Helmut Grohne)
+ Let dh_auto_build pass cross tools to make
  * Fixed spelling error in d/upstream/metadata

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#931262: Bug in ntp

[Leandro Cunha]

Package: ntp
Version: 1: 4.2.8p12+dfsg-4
It seems that the bug happened again in version 1: 4.2.8p12+dfsg-4 because
of the apparmor, checking in logs here.

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

[0.298598] Mountpoint-cache hash table entries: 8192 (order: 4, 65536
bytes)
[   10.285550] audit: type=1400 audit(1561808943.458:2): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=282
comm="apparmor_parser"
[  944.068018] audit: type=1400 audit(1561820678.188:22): apparmor="STATUS"
operation="profile_replace" profile="unconfined" name="/usr/sbin/ntpd"
pid=6829 comm="apparmor_parser"
[ 1126.048457] audit: type=1400 audit(1561820860.167:23): apparmor="STATUS"
operation="profile_replace" profile="unconfined" name="/usr/sbin/ntpd"
pid=7592 comm="apparmor_parser"

Jun 26 21:41:30 debian-pc kernel: [ 4101.350713] audit: type=1400
audit(1561596090.032:19): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=24985 comm="apparmor_parser"
Jun 26 22:37:37 debian-pc kernel: [9.741181] audit: type=1400
audit(1561599450.929:8): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=277 comm="apparmor_parser"
Jun 26 22:41:00 debian-pc kernel: [   10.652741] audit: type=1400
audit(1561599654.837:4): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=274 comm="apparmor_parser"
Jun 26 22:50:41 debian-pc kernel: [9.819088] audit: type=1400
audit(1561600236.014:3): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=280 comm="apparmor_parser"
Jun 26 23:02:29 debian-pc kernel: [9.799241] audit: type=1400
audit(1561600943.966:8): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=274 comm="apparmor_parser"
Jun 26 23:05:03 debian-pc kernel: [9.737864] audit: type=1400
audit(1561601097.926:2): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=278 comm="apparmor_parser"
Jun 26 23:12:17 debian-pc kernel: [9.698507] audit: type=1400
audit(1561601530.888:8): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=276 comm="apparmor_parser"
Jun 27 09:46:42 debian-pc kernel: [   10.133655] audit: type=1400
audit(1561639596.323:10): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=281 comm="apparmor_parser"
Jun 27 11:38:25 debian-pc kernel: [9.804472] audit: type=1400
audit(1561646299.968:2): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=274 comm="apparmor_parser"
Jun 27 11:42:21 debian-pc kernel: [   10.020724] audit: type=1400
audit(1561646536.208:2): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=275 comm="apparmor_parser"
Jun 27 16:10:08 debian-pc kernel: [9.966975] audit: type=1400
audit(1561662603.150:4): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=278 comm="apparmor_parser"
Jun 28 09:32:49 debian-pc kernel: [   10.929609] audit: type=1400
audit(1561725164.112:4): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=278 comm="apparmor_parser"
Jun 28 10:24:15 debian-pc kernel: [9.878144] audit: type=1400
audit(1561728249.071:2): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=281 comm="apparmor_parser"
Jun 29 08:49:08 debian-pc kernel: [   10.285550] audit: type=1400
audit(1561808943.458:2): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="/usr/sbin/ntpd" pid=282 comm="apparmor_parser"
Jun 29 12:04:38 debian-pc kernel: [  944.068018] audit: type=1400
audit(1561820678.188:22): apparmor="STATUS" operation="profile_replace"
profile="unconfined" name="/usr/sbin/ntpd" pid=6829 comm="apparmor_parser"
Jun 29 12:07:40 debian-pc kernel: [ 1126.048457] audit: type=1400
audit(1561820860.167:23): apparmor="STATUS" operation="profile_replace"
profile="unconfined" name="/usr/sbin/ntpd" pid=7592 comm="apparmor_parser"

ntp (1:4.2.8p12+dfsg-4) unstable; urgency=medium

 * CVE-2019-8936: Crafted null dereference attack in authenticated
   mode 6 packet (Closes: #924228)
 * ntp: exit 0 from init script if daemon does not exist (Closes: #764546)
 * Drop locking from ntp initscript/systemd-wrapper
 * Only delete ntpd statistics files in cronjob (Closes: #772790)

-- Bernhard Schmidt   Thu, 21 Mar 2019 23:42:36 +0100

ntp (1:4.2.8p12+dfsg-3) unstable; urgency=low

 * Treat testsuite errors as non-fatal on some architectures
   Fixes FTBFS on ppc64el, ia64, powerpc, ppc64

-- Bernhard Schmidt   Fri, 14 Sep 2018 22:31:42 +0200

ntp (1:4.2.8p12+dfsg-2) unstable; urgency=low

 * Drop ntpdate ifupdown hooks (Closes: #908286)
   These have been a constant source of problems and one-shot syncs
   are not a proper solution for timekeeping. See 

Bug#931261: release-notes: Paragraph for release notes from Debian Med team

[Andreas Tille]

Package: release-notes
Severity: normal
Tags: patch

Hi release team,

I hope it is not to late for Debian Med release notes paragraph (I was
waiting for comments from the team ...),  Here is a draft paragraph:



News from Debian Med Blend

The Debian Med team has added several new packages and updates for
software targeting life sciences and medicine.  The effort to add
Continuous Integration support for the packages in this field was (and
will be) continued.

To install packages maintained by the Debian Med team, install the
metapackages named med-*, which are at version 3.3 for Debian Buster.
Feel free to visit the
http://blends.debian.org/med/tasks;>Debian Med tasks 
pages
to see the full range of biological and medical software available in 
Debian.




Thanks for working for the Debian release

   Andreas.


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

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

Bug#931259: linux-image-4.19.0-5-amd64: Boot fail IO-APIC timer syncing causes kernel panic

[Giorgio Pioda]

Package: src:linux
Version: 4.19.37-5
Severity: critical
Tags: newcomer
Justification: breaks the whole system

Dear Maintainer,

upgrade from stretch to buster (kernel from 4.9 to 4.19) makes the machine
unbootable. IO-APIC timer syncing issue with kernel panic, very early during
boot. apic=debug gives no clue. tsc=unstable as boot parameter doesn't help. I
can boot 4.19 only with noapic (like right now as I report the bug).

Machine has an old A8N SLI Deluxe mainboard. Bug looks like a regression of bug
#883294

Best regards

Giorgio



-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=dae993a6-e557-44a9-a8b3-c35e5ab9a9ca noapic ro quiet

** Not tainted

** Kernel log:
[5.185543] systemd[1]: Listening on Syslog Socket.
[5.185640] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[5.186003] systemd[1]: Created slice User and Session Slice.
[5.186137] systemd[1]: Listening on Journal Socket (/dev/log).
[5.250873] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[5.276861] lp: driver loaded but no devices found
[5.284765] ppdev: user-space parallel port driver
[5.288381] parport_pc 00:05: reported by Plug and Play ACPI
[5.288458] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
[5.378056] lp0: using parport0 (interrupt-driven).
[5.411730] loop: module loaded
[5.465417] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[5.521890] systemd-journald[224]: Received request to flush runtime journal 
from PID 1
[5.686063] audit: type=1400 audit(1561820978.475:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=269 comm="apparmor_parser"
[5.797377] audit: type=1400 audit(1561820978.583:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince" pid=270 
comm="apparmor_parser"
[5.797382] audit: type=1400 audit(1561820978.583:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince//sanitized_helper" pid=270 comm="apparmor_parser"
[5.797385] audit: type=1400 audit(1561820978.583:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince-previewer" 
pid=270 comm="apparmor_parser"
[5.797387] audit: type=1400 audit(1561820978.583:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince-previewer//sanitized_helper" pid=270 
comm="apparmor_parser"
[5.797389] audit: type=1400 audit(1561820978.583:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince-thumbnailer" pid=270 comm="apparmor_parser"
[5.804884] gameport gameport0: NS558 PnP Gameport is pnp00:08/gameport0, io 
0x201, speed 908kHz
[5.828810] audit: type=1400 audit(1561820978.615:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=277 comm="apparmor_parser"
[5.851608] sr 6:0:0:0: Attached scsi generic sg0 type 5
[5.851660] sd 5:0:0:0: Attached scsi generic sg1 type 0
[5.870467] audit: type=1400 audit(1561820978.659:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=279 
comm="apparmor_parser"
[5.870472] audit: type=1400 audit(1561820978.659:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" 
pid=279 comm="apparmor_parser"
[5.897208] audit: type=1400 audit(1561820978.683:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice" 
pid=273 comm="apparmor_parser"
[5.903336] media: Linux media interface: v0.10
[5.954245] snd_intel8x0 :00:04.0: enabling device ( -> 0003)
[5.954491] PCI Interrupt Link [LACI] enabled at IRQ 5
[5.976870] videodev: Linux video capture interface: v2.00
[6.037390] ivtv: Start initialization, version 1.4.3
[6.037493] ivtv0: Initializing card 0
[6.037496] ivtv0: Autodetected Hauppauge card (cx23416 based)
[6.040612] k8temp :00:18.3: hwmon_device_register() is deprecated. 
Please convert the driver to use hwmon_device_register_with_info().
[6.056613] ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
[6.061066] input: PC Speaker as /devices/platform/pcspkr/input/input9
[6.108116] tveeprom: Hauppauge model 26154, rev F1B3, serial# 10302873
[6.108118] tveeprom: tuner model is TCL M2523_3DB_E (idx 113, type 55)
[6.108119] tveeprom: TV standards PAL(B/G) PAL(D/D1/K) (eeprom 0x44)
[6.108121] tveeprom: audio processor is CX25843 (idx 37)
[6.108121] tveeprom: decoder processor is CX25843 (idx 30)
[6.108122] tveeprom: has no radio, has IR receiver, has IR 

Bug#931260: linux-image-4.19.0-5-amd64: Boot fail IO-APIC timer syncing causes kernel panic

[Giorgio Pioda]

Package: src:linux
Version: 4.19.37-5
Severity: critical
Tags: newcomer
Justification: breaks the whole system

Dear Maintainer,

upgrade from stretch to buster (kernel from 4.9 to 4.19) makes the machine
unbootable. IO-APIC timer syncing issue with kernel panic, very early during
boot. apic=debug gives no clue. tsc=unstable as boot parameter doesn't help. I
can boot 4.19 only with noapic (like right now as I report the bug).

Machine has an old A8N SLI Deluxe mainboard. Bug looks like a regression of bug
#883294

Best regards

Giorgio



-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=dae993a6-e557-44a9-a8b3-c35e5ab9a9ca noapic ro quiet

** Not tainted

** Kernel log:
[5.185543] systemd[1]: Listening on Syslog Socket.
[5.185640] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[5.186003] systemd[1]: Created slice User and Session Slice.
[5.186137] systemd[1]: Listening on Journal Socket (/dev/log).
[5.250873] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[5.276861] lp: driver loaded but no devices found
[5.284765] ppdev: user-space parallel port driver
[5.288381] parport_pc 00:05: reported by Plug and Play ACPI
[5.288458] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
[5.378056] lp0: using parport0 (interrupt-driven).
[5.411730] loop: module loaded
[5.465417] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[5.521890] systemd-journald[224]: Received request to flush runtime journal 
from PID 1
[5.686063] audit: type=1400 audit(1561820978.475:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=269 comm="apparmor_parser"
[5.797377] audit: type=1400 audit(1561820978.583:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince" pid=270 
comm="apparmor_parser"
[5.797382] audit: type=1400 audit(1561820978.583:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince//sanitized_helper" pid=270 comm="apparmor_parser"
[5.797385] audit: type=1400 audit(1561820978.583:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince-previewer" 
pid=270 comm="apparmor_parser"
[5.797387] audit: type=1400 audit(1561820978.583:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince-previewer//sanitized_helper" pid=270 
comm="apparmor_parser"
[5.797389] audit: type=1400 audit(1561820978.583:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince-thumbnailer" pid=270 comm="apparmor_parser"
[5.804884] gameport gameport0: NS558 PnP Gameport is pnp00:08/gameport0, io 
0x201, speed 908kHz
[5.828810] audit: type=1400 audit(1561820978.615:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=277 comm="apparmor_parser"
[5.851608] sr 6:0:0:0: Attached scsi generic sg0 type 5
[5.851660] sd 5:0:0:0: Attached scsi generic sg1 type 0
[5.870467] audit: type=1400 audit(1561820978.659:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=279 
comm="apparmor_parser"
[5.870472] audit: type=1400 audit(1561820978.659:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" 
pid=279 comm="apparmor_parser"
[5.897208] audit: type=1400 audit(1561820978.683:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice" 
pid=273 comm="apparmor_parser"
[5.903336] media: Linux media interface: v0.10
[5.954245] snd_intel8x0 :00:04.0: enabling device ( -> 0003)
[5.954491] PCI Interrupt Link [LACI] enabled at IRQ 5
[5.976870] videodev: Linux video capture interface: v2.00
[6.037390] ivtv: Start initialization, version 1.4.3
[6.037493] ivtv0: Initializing card 0
[6.037496] ivtv0: Autodetected Hauppauge card (cx23416 based)
[6.040612] k8temp :00:18.3: hwmon_device_register() is deprecated. 
Please convert the driver to use hwmon_device_register_with_info().
[6.056613] ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
[6.061066] input: PC Speaker as /devices/platform/pcspkr/input/input9
[6.108116] tveeprom: Hauppauge model 26154, rev F1B3, serial# 10302873
[6.108118] tveeprom: tuner model is TCL M2523_3DB_E (idx 113, type 55)
[6.108119] tveeprom: TV standards PAL(B/G) PAL(D/D1/K) (eeprom 0x44)
[6.108121] tveeprom: audio processor is CX25843 (idx 37)
[6.108121] tveeprom: decoder processor is CX25843 (idx 30)
[6.108122] tveeprom: has no radio, has IR receiver, has IR 

Bug#931256: Failure of DHE key exchanges with OpenSSL security level 2

[Marco d'Itri]

On Jun 29, Julien ÉLIE  wrote:

> Here is a patch to improve how INN selects appropriate parameters:
>   https://inn.eyrie.org/trac/changeset/10344/
> 
> Could it please be included in the inn2 package shipped with Buster?
I think that we are way too late for 10.0, but I will make a new package 
in ~1 month aiming for 10.1.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#931258: kicad: bad marging when printing

[Carsten Schoenert]

Hi,

On Sat, Jun 29, 2019 at 04:34:34PM +0200, gpe92 wrote:
> When printing with Kicad 5.1.2+dfsg1-1 the output is shifted to the
> right compare to the same with Kicad 5.0.2. This leads that the extrem
> right part is not printed.
> My printer is a HP Envy 7640.

My guess is this is obviously not a Debian specific (packaging) issue
and is related to upstream changes betwen 5.0.2 and 5.1.2.

Would you mind to report this problem to the upstream tracker?
Note: This requires a Launchpad account.

https://bugs.launchpad.net/kicad/+filebug

Regards
Carsten

Bug#931052: release-notes text proposal for bug 931052: webkit2gtk not supported on non-sse2 i386 hardware

[Alberto Garcia]

On Sat, Jun 29, 2019 at 12:03:05PM +0200, Alberto Garcia wrote:
> > @Alberto, did you have any intention to upload to backports once
> > buster is released? If so, do you think it is OK to mention this
> > in the release-notes?
> 
> Yes, my plan is to publish backports of every stable WebKitGTK
> release. I have been doing it for stretch without problems for the
> last couple of years.

I'll elaborate a bit more:

- The next upload that goes to buster (either via backports or any
  other means) will support non-SSE2 CPUs. It's most likely going to
  be a backport of 2.24.2-2.

- WebKitGTK upstream has a dependency policy according to which the
  package is supported in Debian stable until one year after the
  release of the next major version. So stretch is supported until
  summer 2020 and buster until one year after bullseye.

  https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy

- When upstream publishes a new version I upload it to unstable
  typically on the same day, and to stable-backports as soon as
  the package hits testing. stretch-backports has always had an
  up-to-date version of webkit2gtk, and I plan to do the same for
  buster-backports (and for stretch-backports as long as it works).

- In addition to that we are also having buster-security updates of
  webkit2gtk for the first time. However we are not cherry-picking
  security fixes, we will be using the latest upstream stable release
  (the same that goes to buster-backports, actually). My plan is to
  delay the security updates for some days in order to have time to
  test them and detect regressions.

One may argue that it's a bit pointless to have the same upstream
releases going to buster-backports and buster-security, but the former
will also receive updates that don't contain security fixes and will
generally be less conservative with the timings.

Berto

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Justin B Rye]

Michael Biebl wrote:
> Am 29.06.19 um 15:09 schrieb Justin B Rye:
>> +  configure a machine as a router, may encounter problems upgrading to 
>> buster.
>> +  New versions of udev install a
> 
> That modprobe config file is shipped by the systemd package, not by udev.

Ah, thanks.
 
>> A file in
>> +  /lib/modprobe.d can be overridden by one with the
>> +  same name under /etc/modprobe.d, but the names 
>> are
>> +  processed in alphabetical order, so
> 
> That sentence is a bit confusing: files with the same name are
> overridden. period. there is no but.

If there wasn't a "but", people wouldn't have been caught out!  It's
true that if you create a file in /etc then you don't need to worry
about the one it masks in /lib, but you do still need to worry about
others that might turn up in /lib with names that sort later.

> Are you trying to say that files can be overridden as a whole but
> usually its better to only override specific settings in a local
> configuration file which doesn not have the same name?

No, I *could* have added a paragraph explaining the drawbacks of using
the filename /etc/modprobe.d/systemd.conf, but it seemed simpler just
to not mention the suboptimal solution.  After all, who knows what
might turn up in bullseye's /etc/modprobe.d/udev.conf?

> (which is indeed a useful recommendation because future updates of
> systemd.conf might be missed if you name the file
> /etc/modprobe.d/systemd.conf).

The simplest way of looking at this bug is that the old approach
(as recommended in legacy HOWTOs) of using filenames like
"/etc/modprobe.d/dummy.conf" needs to be updated to using something
like "/etc/modprobe.d/zz-local.conf".  My explanation covers things in
what I hoped was just enough detail to make it clear why that change
is needed.


I've stared at it quite a bit and can't find a clearer way of saying
it.  Here's a patch with just the s/udev/systemd/ change; I'll go for
a walk and then try looking at it again.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 2edb9838..9d7ae1ae 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -203,33 +203,28 @@ $ sudo update-initramfs -u
 
 Module configuration for bonding and dummy interfaces
 
-  Administrators who are using channel bonding and/or dummy
-  interfaces (for instance to configure a machine as a router), and
-  who have set up module parameters in a file under
-  /etc/modprobe.d, may need to change the name
-  of the local configuration file used, to avoid these parameters
-  being ignored after the upgrade to buster.
-
-
-  In buster, udev ships a
-  file /lib/modprobe.d/systemd.conf designed to
-  make it easier to configure such interfaces using
-  systemd-networkd. This contains the lines
+  Systems using channel bonding and/or dummy interfaces, for instance to
+  configure a machine as a router, may encounter problems upgrading to buster.
+  New versions of systemd install a
+  file /lib/modprobe.d/systemd.conf (intended to
+  simplify configuration via systemd-networkd) which
+  contains the lines
 
 
  options bonding max_bonds=0
  options dummy numdummies=0
 
 
- A file in /lib/modprobe.d can be overridden by
- one with the same name under /etc/modprobe.d,
- but the names are processed in alphabetical order, so
- /lib/modprobe.d/systemd.conf follows and
- overrides (for instance)
- /etc/modprobe.d/dummy.conf. Make sure that any
- local configuration file has a name that sorts after
- systemd.conf, such as
- /etc/modprobe.d/zz-local.conf.
+  Admins who were depending on different values will need to ensure they are
+  set in the correct way to take precedence. A file in
+  /lib/modprobe.d can be overridden by one with the
+  same name under /etc/modprobe.d, but the names are
+  processed in alphabetical order, so
+  /lib/modprobe.d/systemd.conf follows and overrides
+  (for instance) /etc/modprobe.d/dummy.conf. Make sure
+  that any local configuration file has a name that sorts after
+  systemd.conf, such as
+  /etc/modprobe.d/zz-local.conf.
 
   
 

Bug#931230: moving the pointer to the bottom of the screen doesn't bring up the tabs bar

[Eduard Bloch]

Control: tags + upstream confirmed

* 積丹尼 Dan Jacobson [Sat, Jun 29 2019, 12:20:25AM]:
> Package: icewm
> Version: 1.5.5+git20190610-1
>
> In chromium or firefox F11 fullscreen, moving the pointer to the bottom
> of the screen should bring up the row of icewm tabs, but doesn't these days.

Thank you. Continued at: https://github.com/bbidulock/icewm/issues/361 .

Best regards,
Eduard.

Bug#930856: autopkgtest-build-qemu: captures something from host

[Cyril Brulebois]

Hi,

Dmitry Bogatov  (2019-06-29):
> [ After futher investigation, this command fails with same error directly,
>  without autopkgtest, so reassigning ]
> 
> control: reassing -1 debootstrap
> control: retitle -1 debootstrap uses wrong keyring
> 
> Dear maintainer of debootstrap, I can't create chroot due following error:
> 
>   # debootstrap --variant - unstable /tmp/foo.dir http://deb.debian.org
>   I: Checking Release signature
>   E: Release signed by unknown key (key id 04EE7237B7D453EC)
>  The specified keyring /usr/share/keyrings/devuan-archive-keyring.gpg may 
> be incorrect or out of date.
>  You can find the latest Debian release key at 
> https://ftp-master.debian.org/keys.html
> 
> Note that APT tries to use Devuan keyring to validate Debian release and
> fail. How does `debootstrap' decides, which keyring to use?

What debootstrap version is that? And what distribution is it?

In a sid chroot I'm getting this:

(sid-amd64-devel)kibi@armor:/tmp$ sudo debootstrap --variant - unstable 
/tmp/foo.dir http://deb.debian.org
I: Target architecture can be executed
I: Retrieving InRelease 
I: Retrieving Release 
E: Failed getting release file http://deb.debian.org/dists/unstable/Release

which is sensible because there's a missing /debian directory.

With that fixed:

(sid-amd64-devel)kibi@armor:/tmp$ sudo debootstrap --variant - unstable 
/tmp/foo.dir http://deb.debian.org/debian
I: Target architecture can be executed
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
[…]

> I am aware about --keyring option, original bug was about
> `autopkgtest-build-qemu', which invokes debootstrap through several
> layers and does not allow passing additional arguments to `debootstrap'.

There's no devuan-archive-keyring.gpg in Debian anyway, so I'd suggest
filing this issue with your actual vendor.


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


signature.asc
Description: PGP signature

Bug#930856: autopkgtest-build-qemu: captures something from host

[Bastian Blank]

On Sat, Jun 29, 2019 at 02:25:55PM +, Dmitry Bogatov wrote:
> Note that APT tries to use Devuan keyring to validate Debian release and
> fail. How does `debootstrap' decides, which keyring to use?

"dpkg -s debootstrap"?  How did that keyring get on the system in the
first place?

Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4

Bug#903392: want support for packaging-only maintainer views

[Ian Jackson]

Sean Whitton writes ("Re: Bug#903392: want support for packaging-only 
maintainer views"):
> On Sat 29 Jun 2019 at 02:55pm +0100, Ian Jackson wrote:
> > Sean Whitton writes ("Re: Bug#903392: want support for packaging-only 
> > maintainer views"):
> >> On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:
> >> > Secondly:
> >> >
> >> > If the user says "use upstream from git" but there is no git, the user
> >> > gets an error message mentioning git tags and that can also say
> >> > something about the other quilt mode.
> >> >
> >> > If the user says "use upstream tarball" but they had git available,
> >> > the result is to silently ignore the upstream history and use a
> >> > tarball import instead.
> >> >
> >> > In keeping with the philosophy of making doing the right thing
> >> > convenient, suboptimals things possible, and requiring mistakes to be
> >> > explicit, ISTM that the tarball variant should mention that.
> >>
> >> "mention that"?  Sorry, I'm not sure about how what you say here is a
> >> response to what I wrote.
> >
> > I mean, the name for the tarball variant should mention tarball.
> 
> Okay.  I do not think what you've written is right, if I'm properly
> understanding its implications.  You seem to be suggesting that
> baredebian+git is better than baredebian+tarball, in the sense that the
> latter is a fallback when an upstream git tag is not available.  I do
> not think that is how people who use baredebian+tarball think of their
> workflow.
> 
> Perhaps I'm just misunderstanding what you're trying to say.

No, I mean that there is a risk of dgit accidentally and unnecessarily
using a worse quilt mode, due to user error.

That is I think baredebian+tarball is inferior to the +git version,
but the latter cannot always be used (depending on the user's prior
choices, we we are not - here - trying to influence).

> > I could make baredebian+git an alias for it.  Or, rename it.  It's not
> > released yet...
> 
> I think it should be renamed.  Otherwise, it might unhelpfully imply
> that the dgit developers think that baredebian+git is better than
> baredebian+tarball in some way.

But we do.  I agree we don't want to make value judgements about this
kind of thing unnecessarily, but:

baredebian+tarball will always work, whereas baredebian+git will
sometimes fail (wrong git tag, git tag contents are wrong).

People will generally think that it is better to use an option which
will always work, rather than one which might fail for additional
reasons.

Or to put it another way: users who need +tarball need it and do not
have a choice.

Users who can use +git need to be told that +git is better thaj
+tarball because it (i) publishes upstream git history
(ii) double checks that their package is sane.

Does that make sense ?

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#930922: dgit: combination of -wgf and --include-dirty nukes untracked files

[Ian Jackson]

Sean Whitton writes ("Re: Bug#930922: dgit: combination of -wgf and 
--include-dirty nukes untracked files"):
> On Mon 24 Jun 2019 at 12:02pm +0100, Ian Jackson wrote:
> >> A possible alternative would be to actually add --include-all-dirty, but
> >> the problem in #914317 suggests that might not be a great idea.
> >
> > Your --include-all-dirty is roughly equivalent to -wn or -wdd ?
> 
> If -wn and -wdd imply not building in a playtree (I can't recall what we
> decided there), I think that's right, yes.

No, they don't.  I meant "--include-all-dirty = --include-dirty -wn"
or som such, and --include-dirty means not playtree.

> > Therefore, any files which are not to be included in the result, must
> > be deleted.  (Doing otherwise would involve programmatic construction
> > of dpkg -I -i options.  Yikes.)
> >
> > Conversely, files which *are* to be included in the result could in
> > principle be deleted *after* package building, but cannot be deleted
> > before.  I really don't think I want to extend the post-build stuff in
> > dgit (currently just patch deapplication) any further.  The tangle of
> > execution flow is quite bad enough.
> 
> Er, yes, I don't see why deleting anything after package building would
> be desirable.  (Not sure what you have in mind here aside from
> completeness in your reasoning.)

Just that.

> > We already have 11 subtly different variations of --clean, to specify
> > exactly which files should be tolerated and which cleaned.  These 11
> > variations are therefore precisely the possibilities for
> > --include-dirty's unclean file handling.
> 
> Assuming those 11 variations are exhaustive of the possibilities, yes.

I think they are :-).

> > Can we express this situation somehow in the manpage definition for
> > --include-dirty ?  Something like:
> >
> >   Note that dgit will still clean the working tree before building the
> >   source packsage.  Depending on the --clean mode, files not tracked
> >   by git, and/or files deleted by debian/rules clean, are at risk of
> >   being deleted, rather than included in the built source package.
> >   Consider passing a --clean= (-w...) option along with
> >   --include-dirty.
> >
> > maybe.
> 
> I think this is unnecessarily demanding of the reader as compared with
> my proposed patch.
> 
> I'd suggest just updating my patch to say "you can use --clean=none or
> --clean=dpkg-source[-d] in addition to --include-dirty".

OK, can you fold that in for me ?  Thanks.

> > Should --include-dirty --quilt={linear,smash} be treated as
> > --quilt=nofix ?
> 
> Is what you have in mind, here, helping the user avoid hitting the
> #914317 problem?

Yes.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#931258: kicad: bad marging when printing

[gpe92]

Package: kicad
Version: 5.1.2+dfsg1-1
Severity: normal

Dear Maintainer,

When printing with Kicad 5.1.2+dfsg1-1 the output is shifted to the right 
compare to the same with Kicad 5.0.2. This leads that the extrem right part is 
not printed.
My printer is a HP Envy 7640.

BR

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
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=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#930856: autopkgtest-build-qemu: captures something from host

[Dmitry Bogatov]

[ After futher investigation, this command fails with same error directly,
 without autopkgtest, so reassigning ]

control: reassing -1 debootstrap
control: retitle -1 debootstrap uses wrong keyring

Dear maintainer of debootstrap, I can't create chroot due following error:

  # debootstrap --variant - unstable /tmp/foo.dir http://deb.debian.org
  I: Checking Release signature
  E: Release signed by unknown key (key id 04EE7237B7D453EC)
 The specified keyring /usr/share/keyrings/devuan-archive-keyring.gpg may 
be incorrect or out of date.
 You can find the latest Debian release key at 
https://ftp-master.debian.org/keys.html

Note that APT tries to use Devuan keyring to validate Debian release and
fail. How does `debootstrap' decides, which keyring to use?

I am aware about --keyring option, original bug was about
`autopkgtest-build-qemu', which invokes debootstrap through several
layers and does not allow passing additional arguments to `debootstrap'.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Paride!

Paride Legovini wrote in :
 |Steffen Nurpmeso wrote on 28/06/2019:
 |> Paride Legovini wrote in  r.org>:
 |>|Steffen Nurpmeso wrote on 27/06/2019:
 |>|> Paride Legovini wrote in |> o\
 |>|> r.org>:
 |>|>|Steffen Nurpmeso wrote on 20/06/2019:
 ...
 |>|>|this bug? I would like to have it fixed in buster, but given that we're
 |>|>|so deep in the freeze I'll have to ship only a minimal fix for this
 |>|>|specific bug; an import of a new minor version changing other stuff
 |>|>|won't be accepted. This will mean patching 14.9.11.
 |>|> 
 |>|> Oh-oh, 14.9.11 is a year old! :)  I do not understand that
 |>|> security policy of Debian, for such a small program with a single
 |>|> developer.  So many bugs fixed!  I would even update to [master]
 |>|> or [stable/stable] and use the grappa mode!  Sigh. :)
 |>|
 |>|Yeah I'm sorry for the skipped release, I promise I will backport the
 |>|latest one once buster is released, but for the moment v14.9.11 is the
 |>|version we have to work with.
 |>|
 |>|The policy for acceptable changes during the full freeze period is
 |>|pretty clear:
 |>|
 |>|https://release.debian.org/buster/freeze_policy.html
 |>|
 |>|and I don't think an update to e.g. 14.9.14 will fit.
 |> 
 |> That definetely not, i had to rewrite the entire child process and
 |> job control signal handling to something that i almost like.  And
 |> the rest of the way we will make, too!
 |> 
 |> I was thinking more of the [stable/stable] branch, which is
 |> v14.9.13 plus fixes, and which can be turned into a release with
 |> the grappa mode of mk/make-release.sh (as documented in README).
 |
 |This would totally make sense in my opinion, the problem is we don't
 |have v14.9.13 in Debian, but v14.9.11, and we need two "UPDATE" version
 |bumps (in the MAJOR.MINOR.UPDATE semantic) to get to 14.9.13, on which
 |we can apply the bug fixes in the stable/stable branch. And UPDATE
 |releases are not bugfix-only releases, so not really suitable for
 |inclusion while Debian is in deep freeze.

I see, i had forgotten that 14.9.13 came to late for the Debian
freeze, and it really is v14.9.11.  Yeah, it really is v14.9.11.
Well...

 |I can of course backport the latest stable version of s-nail once Buster
 |is released, and I will, but that's not the same of course.
 |
 |Please let me know if I misunderstood something, and thanks a lot for
 |your feedback.

Nah, it is ok.  But in general i have doubts regarding this Debian
policy, so many bugs have been fixed .. that possibly the few that
came anew count less.  In my opinion.  Of course, if i had more
time i could cherry-pick more bugfixes to even elder releases, but
i think that will not happen.  So, pfff, busted.

Ciao, Paride.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#931257: dh-runit: overly lax dependency on runit-helper

[Dmitry Bogatov]

Package: dh-runit
Version: 2.8.11
Severity: wishlist

Dear Maintainer,

dh-runit=2.8.8 introduced new option: "since", but this option actually
work (symlinks correctly created in /etc/runit/runsvdir/default) only
with matching version of "runit-helper", but it is not enforced:

runit:Depends contains much weaker dependency on runit-helper >= 2.8.1~

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

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

Versions of packages dh-runit depends on:
ii  debhelper12.1.1
ii  libfile-copy-recursive-perl  0.44-1
ii  libfile-slurp-perl   .27-1
ii  libtext-hogan-perl   2.01-1

dh-runit recommends no packages.

dh-runit suggests no packages.

-- no debconf information


pgpVYRIxt3WzQ.pgp
Description: PGP signature

Bug#851774: Bug#928931: Bug #928931: more info + patch

[Cyril Brulebois]

Hi Raphaël,

Raphaël Halimi  (2019-06-29):
> I don't mean to rush you, but […]

Hrm.

> My current workaround is to add a hook in base-installer.d (because it
> has to be done just before apt gets configured) to replace
> /usr/lib/apt-setup/generators/60local with a version including a line
> to install gnupg before "apt-key add" is called (patch included).
> 
> (the modification can also be done manually during the base system
> installation phase, but it is error-prone, has to be done very quickly
> at the right moment, and of course completely defeats the purpose of
> an unattended installation)
> 
> I noticed that gnupg used to be Priority: important, whereas it's now
> Priority: optional.
> 
> If installing gnupg is what it takes to fix the bug, IMHO it should be
> done; anyway, with this patch, it would be installed only if a local
> repository with a GnuPG key is used at all.

Well, I proposed doing so a while ago but that didn't happen. Looking at
the current gnupg package, it's not about installing just a single,
extra package:

Depends: dirmngr (<< 2.2.13-2.1~), dirmngr (>= 2.2.13-2), gnupg-l10n (= 
2.2.13-2), gnupg-utils (<< 2.2.13-2.1~), gnupg-utils (>= 2.2.13-2), gpg (<< 
2.2.13-2.1~), gpg (>= 2.2.13-2), gpg-agent (<< 2.2.13-2.1~), gpg-agent (>= 
2.2.13-2), gpg-wks-client (<< 2.2.13-2.1~), gpg-wks-client (>= 2.2.13-2), 
gpg-wks-server (<< 2.2.13-2.1~), gpg-wks-server (>= 2.2.13-2), gpgsm (<< 
2.2.13-2.1~), gpgsm (>= 2.2.13-2), gpgv (<< 2.2.13-2.1~), gpgv (>= 2.2.13-2)

I'm also not sure what part of dirmngr and/or gpg-agent are going to
stay around running, after calling “apt-key add” with gnupg installed.

Testing that was conceivable a couple of weeks/months back; a few days
before an archive freeze, not so much.

Plus, we've got a MR against apt-setup now, see #851774. It's also come
late and nobody reviewed it yet. Plus, the other, serious bug report was
marked as buster-ignore by a release team member, so there's no *need*
to fix this before buster.

> I hope this fix (or another one of your own choice) will make it to
> d-i before release.

All in all, it looks like we're instead going to consider the MR at the
beginning of the bullseye release cycle, and backport the fix to buster
if it proves to be working fine.

Letting the other bug and Moritz know through cc.


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


signature.asc
Description: PGP signature

Bug#931256: Failure of DHE key exchanges with OpenSSL security level 2

[Julien ÉLIE]

Package: inn2
Version: 2.6.3-1

Hi,

There is a TLS-related issue with INN 2.6.3 if the "security level" 
feature of OpenSSL 1.1 is used:  negotiations for ciphersuites using DHE 
key exchange fail if the security level is set to something beyond 1. 
The upcoming Debian 10 (Buster) seems to do this by default:

  https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1

INN 2.6.3 negotiates 1028-bit parameters with for instance the 
"DHE-RSA-AES256-GCM-SHA384" cipher suite, which is disallowed by the 
security level 2 enforced by Debian Buster.  At least 2048-bit 
parameters are expected.



According to OpenSSL documentation:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html

"WARNING at this time setting the security level higher than 1 for 
general internet use is likely to cause considerable interoperability 
issues and is not recommended.  This is because the SHA1 algorithm is 
very widely used in certificates and will be rejected at levels higher 
than 1 because it only offers 80 bits of security."




Here is a patch to improve how INN selects appropriate parameters:
  https://inn.eyrie.org/trac/changeset/10344/

Could it please be included in the inn2 package shipped with Buster?


P.-S.:  This issue was found by Michael Bäuerle, and reported in the 
news.software.nntp newsgroup.


--
Julien ÉLIE

« Qui joue des flûtes perd sa hutte ! » (Mme Agecanonix)

Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1

[Sébastien Béhuret]

On Fri, Jun 28, 2019 at 10:40 AM Alex Mestiashvili 
wrote:

> > With your solution I assume that /lib/udev/hdparm would call hdparm
> > twice on each HDD during udev invocation, once for non-spindown options
> > returned by /lib/hdparm/hdparm-functions, and once through
> > /usr/lib/pm-utils/power.d/95hdparm-apm for spindown options.
>
> Exactly, for the APM options, apm, spindown_time and force_spindown_time
> /lib/udev/hdparm will call "/usr/lib/pm-utils/power.d/95hdparm-apm"
> For the other option hdparm will be called the second time. But I see no
> problem here. Please see the updated script here:
>
> https://salsa.debian.org/debian/hdparm/blob/930796/debian/udev-scripts/hdparm
>

The updated script looks just right with -B and -S options going through
95hdparm-apm and other options applied locally.

Thanks!



> With the new /lib/udev/hdparm, hdparm follows the logic below:
>
> No config (/etc/hdparm.conf doesn't list any drives):
>   * If disk supports APM, the defaults:
> - on boot, -B 254
> - on power, -B 254
> - on battery -B 128 -S36 (3 min)
>   * no APM support:
> - hdparm will not run (no config!)
> If disk config is present in /etc/hdparm.conf:
>   * disk supports APM
> - on boot, udev will call /lib/udev/hdparm, which in turn will call
>   /usr/lib/pm-utils/power.d/95hdparm-apm for apm options and hdparm
>   for other options.
> - on power, /usr/lib/pm-utils/power.d/95hdparm-apm
> - on battery, defaults -B 128 -S 36, use apm_battery and
>   spindown_time to set non-default values
>   * no APM support:
> - force_spindown_time and other options are applied,
>   apm and spindown_time are ignored
>

This is great default behavior. Calling 95hdparm-apm from /lib/udev/hdparm
also prevents setting options that laptop-mode-tools would normally handle.


> For USB or FireWere disks, APM & spindown_time options are ignored,
> other options are applied, force_spindown_time will be applied too.
> There is bug, https://bugs.launchpad.net/bugs/515023
> explaining why USB and FireWire drives are ignored, however the
> situation might have improved since then.
>

I was unaware of this bug and never experienced this issue with external
USB drives. I do remember external USB drives going into standby mode
shortly after backup completion, but this does not occur anymore in debian
buster/testing. The drives in question do not support APM so it makes sense
given that -S36 is no longer applied in this case.


>
> > Custom
> > scripts relying on hdparm_options() function in
> > /lib/hdparm/hdparm-functions would still fail if force_spindown_time is
> > used in /etc/hdparm.conf. I would suggest implementing the conversion
> > code directly into hdparm_options() function to avoid code duplication,
> > prevent misuse, and possibly avoid calling hdparm twice on each HDD.
>
> This makes sense, but
> 1. hdparm-functions is the debian specific helper script. The chances
> that somebody will use it for custom scripts is very low.
> 2. force_spindown_time is a hackish workaround and in order to implement
> it I need to parse this option later in "95hdparm-apm" script.
> Implementing proper handling of "force_spindown_time" in
> hdparm-functions will result in bringing part of
> resume_hdparm_spindown() function from 95hdparm-apm in hdparm-functions
> code. I don't like this idea, but please feel free to implement and send
> me a patch. :)
>

The logic that you described above is just fine and you are absolutely
right that it is unlikely hdparm-functions is/will be used for custom
scripts. If the force_spindown_time hack was implemented in
hdparm-functions, it would also be necessary to detect laptop-mode-tools
and parse its configuration there, making things a little trickier.


> >
> > 4. Thanks for your feedback. I have done some experiments and it appears
> > that the -S issue comes from something else. I can only confirm that the
> > -S option was still working fine at the time of hdparm 9.56+ds-2 in
> > buster/testing (Fall 2018) and it had been working for over 5 years with
> > various kernel and hdparm versions. Between hdparm 9.56+ds-2 and hdparm
> > 9.58+ds-1, the kernel was updated (4.17.8-1 => 4.19.37-3) and there were
> > also changes in udev (239-7 => 241-3).
>
> To exclude hdparm, one can try to build hdparm 9.58 on a stretch system.
> Building it with make will also work.
>


You are right, unfortunately I won't be able to make this test now.

I'm confident that hdparm -S is somehow broken is recent buster debian due
to:
- Multiple drives affected by the issue (internal and USB external)
- These drives will spin down successfully with hdparm -y, and will stay in
standby mode unless manually accessed (tested for over 48 hours)
- hdparm -S runs successfully but none of the delays work (tested delays
ranged from a few seconds to a few hours)
- It had been working flawlessly with this hardware running debian testing
up to Fall 2018 (hdparm 9.56, kernel 4.17, udev 

Bug#903392: want support for packaging-only maintainer views

[Sean Whitton]

Hello,

On Sat 29 Jun 2019 at 02:55pm +0100, Ian Jackson wrote:

> Control: clone -1 -2
> Control: retitle -2 want bare-debian tarball-orig quilt mode
> Control: tags -2 - pending
>
> Sean Whitton writes ("Re: Bug#903392: want support for packaging-only 
> maintainer views"):
>> On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:
>> > Secondly:
>> >
>> > If the user says "use upstream from git" but there is no git, the user
>> > gets an error message mentioning git tags and that can also say
>> > something about the other quilt mode.
>> >
>> > If the user says "use upstream tarball" but they had git available,
>> > the result is to silently ignore the upstream history and use a
>> > tarball import instead.
>> >
>> > In keeping with the philosophy of making doing the right thing
>> > convenient, suboptimals things possible, and requiring mistakes to be
>> > explicit, ISTM that the tarball variant should mention that.
>>
>> "mention that"?  Sorry, I'm not sure about how what you say here is a
>> response to what I wrote.
>
> I mean, the name for the tarball variant should mention tarball.

Okay.  I do not think what you've written is right, if I'm properly
understanding its implications.  You seem to be suggesting that
baredebian+git is better than baredebian+tarball, in the sense that the
latter is a fallback when an upstream git tag is not available.  I do
not think that is how people who use baredebian+tarball think of their
workflow.

Perhaps I'm just misunderstanding what you're trying to say.

I do think, to be clear, that we should just use 'baredebian+git' and
'baredebian+tarball' and have there be no 'baredebian' splitting quilt
mode.

>> >> An alternative to 'packaging' would be 'debiandir'.
>> >
>> > In my new taxonomy, I call this "bare debian" so baredebian would be a
>> > possibility.
>> >
>> > I think quilt modes could contain + signs so perhaps
>> >baredebian+git
>> >baredebian+tarball
>>
>> This, or debiandir+git and debiandir+tarball, LGTM.
>
> So far I have implemented `baredebian' to mean the with-upstream-git
> variant.
>
> I could make baredebian+git an alias for it.  Or, rename it.  It's not
> released yet...

I think it should be renamed.  Otherwise, it might unhelpfully imply
that the dgit developers think that baredebian+git is better than
baredebian+tarball in some way.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#930880: Local variables don't work

[積丹尼 Dan Jacobson]

> "DB" == David Bremner  writes:
DB> To be honest I'm not sure supporting local variables in
DB> /etc/apt/sources.list is a good idea...

OK, but at least have emacs say "Local variables detected in important
file. Not allowed!"

Else when they silently don't work people will think it is a bug.

Bug#931255: regexps used seems to be incompatible with libpcre2 10.32

[Felix Zielcke]

Package: php-horde-text-filter
Version: 2.3.5-3
Severity: grave
Tags: patch

On buster with PHP 7.3 the tabs used on the horde settings webpage are empty 
instead of the usual General/Database etc.
With PHP 7.2 from packages.surey.org they work fine. They are linked against 
libpcre3 2:8.42

Log says:

WARN: HORDE [horde] PHP ERROR: preg_replace_callback(): Compilation failed: 
invalid range in character class at offset 68 [pid 21655 on line 99 of 
"/usr/share/php/Horde/Text/Filter.php"]

Problem seems to be that it doestn't like anymore ranges like [\w-+]. The 
hyphen needs to be first

Attached patch fixes it for me.

-- 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/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php-horde-text-filter depends on:
ii  php-common   2:69
ii  php-horde-exception  2.0.8-4
ii  php-horde-idna   1.1.1-3
ii  php-horde-util   2.5.8-3

Versions of packages php-horde-text-filter recommends:
pn  php-horde-test 
ii  php-horde-text-flowed  2.0.3-5
ii  php-horde-translation  2.2.2-3
pn  php-tidy   

Versions of packages php-horde-text-filter suggests:
pn  php-horde-text-filter-jsmin  

-- no debconf information
diff --git a/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php 
b/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php
index ad760b9..929d829 100644
--- a/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php
+++ b/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Emails.php
@@ -61,7 +61,7 @@ class Horde_Text_Filter_Emails extends Horde_Text_Filter_Base
 ((?(1)\s*\]))
 |
 # Version 2 Pattern 9 and 10: simple email addresses.
-(^|\s||<|\[)([\w-+.=]+@[-A-Z0-9.]*[A-Z0-9])
+(^|\s||<|\[)([-\w+.=]+@[-A-Z0-9.]*[A-Z0-9])
 # Pattern 11 to 13: Optional parameters
 ((\?)([^\s"<]*[\w+#?\/&=]))?
 # Pattern 14: Optional closing bracket
diff --git a/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Linkurls.php 
b/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Linkurls.php
index a88dc12..72e19ec 100644
--- a/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Linkurls.php
+++ b/Horde_Text_Filter-2.3.5/lib/Horde/Text/Filter/Linkurls.php
@@ -86,7 +86,7 @@ class Horde_Text_Filter_Linkurls extends 
Horde_Text_Filter_Base
 (?:\b|^)
 (  # Capture 1: entire matched URL
   (
-   (?:[a-z][\w-+]{0,19})?:/{1,3}  # URL protocol and colon followed by 1-3
+   (?:[a-z][-\w+]{0,19})?:/{1,3}  # URL protocol and colon followed by 1-3
   # slashes, or just colon and slashes (://)
 | #  - or -
 (?

Bug#930922: dgit: combination of -wgf and --include-dirty nukes untracked files

[Sean Whitton]

Hello,

On Mon 24 Jun 2019 at 12:02pm +0100, Ian Jackson wrote:

>> A possible alternative would be to actually add --include-all-dirty, but
>> the problem in #914317 suggests that might not be a great idea.
>
> Your --include-all-dirty is roughly equivalent to -wn or -wdd ?

If -wn and -wdd imply not building in a playtree (I can't recall what we
decided there), I think that's right, yes.

> I think this is a useful behaviour for non-`3.0 (quilt)' packages.
> For `3.0 (quilt)' packages where upstream files are modified, it is
> even sensible with --quilt=nofix.  The problems described in #914317
> occur with nontrivial quilt fixup modes, in quilt packages, only.
>
> (And this is true even after we support split brain with non-splitting
> quilt modes, since --include-dirty implies not building in a playtree,
> but split brain always involves building in a playtree.)
>
>
> Having thought about this some more, ISTM that: it is not really
> sensible to try to implement --include-dirty with building in
> playtree.  That would involve trying to copy untracked stuff out of
> the maintree.

Certainly.  --include-dirty should turn off building in a playtree.

> Therefore, any files which are not to be included in the result, must
> be deleted.  (Doing otherwise would involve programmatic construction
> of dpkg -I -i options.  Yikes.)
>
> Conversely, files which *are* to be included in the result could in
> principle be deleted *after* package building, but cannot be deleted
> before.  I really don't think I want to extend the post-build stuff in
> dgit (currently just patch deapplication) any further.  The tangle of
> execution flow is quite bad enough.

Er, yes, I don't see why deleting anything after package building would
be desirable.  (Not sure what you have in mind here aside from
completeness in your reasoning.)

> What this means is that --include-dirty will always include precisely
> the things that were not cleaned.  Any particular file is either
> included, xor cleaned.  (Or causes dgit to barf.)

Yes.

> We already have 11 subtly different variations of --clean, to specify
> exactly which files should be tolerated and which cleaned.  These 11
> variations are therefore precisely the possibilities for
> --include-dirty's unclean file handling.

Assuming those 11 variations are exhaustive of the possibilities, yes.

> Can we express this situation somehow in the manpage definition for
> --include-dirty ?  Something like:
>
>   Note that dgit will still clean the working tree before building the
>   source packsage.  Depending on the --clean mode, files not tracked
>   by git, and/or files deleted by debian/rules clean, are at risk of
>   being deleted, rather than included in the built source package.
>   Consider passing a --clean= (-w...) option along with
>   --include-dirty.
>
> maybe.

I think this is unnecessarily demanding of the reader as compared with
my proposed patch.

I'd suggest just updating my patch to say "you can use --clean=none or
--clean=dpkg-source[-d] in addition to --include-dirty".

> Should --include-dirty --quilt={linear,smash} be treated as
> --quilt=nofix ?

Is what you have in mind, here, helping the user avoid hitting the
#914317 problem?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#903392: want support for packaging-only maintainer views

[Ian Jackson]

Control: clone -1 -2
Control: retitle -2 want bare-debian tarball-orig quilt mode
Control: tags -2 - pending

Sean Whitton writes ("Re: Bug#903392: want support for packaging-only 
maintainer views"):
> On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:
> > Secondly:
> >
> > If the user says "use upstream from git" but there is no git, the user
> > gets an error message mentioning git tags and that can also say
> > something about the other quilt mode.
> >
> > If the user says "use upstream tarball" but they had git available,
> > the result is to silently ignore the upstream history and use a
> > tarball import instead.
> >
> > In keeping with the philosophy of making doing the right thing
> > convenient, suboptimals things possible, and requiring mistakes to be
> > explicit, ISTM that the tarball variant should mention that.
> 
> "mention that"?  Sorry, I'm not sure about how what you say here is a
> response to what I wrote.

I mean, the name for the tarball variant should mention tarball.

> >> An alternative to 'packaging' would be 'debiandir'.
> >
> > In my new taxonomy, I call this "bare debian" so baredebian would be a
> > possibility.
> >
> > I think quilt modes could contain + signs so perhaps
> >baredebian+git
> >baredebian+tarball
> 
> This, or debiandir+git and debiandir+tarball, LGTM.

So far I have implemented `baredebian' to mean the with-upstream-git
variant.

I could make baredebian+git an alias for it.  Or, rename it.  It's not
released yet...

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Michael Biebl]

Am 29.06.19 um 15:09 schrieb Justin B Rye:
> +  configure a machine as a router, may encounter problems upgrading to 
> buster.
> +  New versions of udev install a

That modprobe config file is shipped by the systemd package, not by udev.

> A file in
> +  /lib/modprobe.d can be overridden by one with the
> +  same name under /etc/modprobe.d, but the names are
> +  processed in alphabetical order, so

That sentence is a bit confusing: files with the same name are
overridden. period. there is no but.

Are you trying to say that files can be overridden as a whole but
usually its better to only override specific settings in a local
configuration file which doesn not have the same name?
(which is indeed a useful recommendation because future updates of
systemd.conf might be missed if you name the file
/etc/modprobe.d/systemd.conf).




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

Bug#931252: lximage-qt: should have a manpage

[Yvan Masson]

Package: lximage-qt
Version: 0.14.1-1

Dear maintainers,

Currently, lximage-qt command does not have a manpage. I thought this 
was mandatory in Debian.


It seems that upstream does not have a manpage either: do not hesitate 
to ask if you want me to report this issue upstream.


Best regard,
Yvan

Bug#903392: want support for packaging-only maintainer views

[Sean Whitton]

Hello,

On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:

> Are you sure about this conclusion ?  Firstly, about "how common": eg,
> the current Linux kernel packages have upstream git.

Probably best not to assume it's more common, if we can avoid that,
indeed.

> Secondly:
>
> If the user says "use upstream from git" but there is no git, the user
> gets an error message mentioning git tags and that can also say
> something about the other quilt mode.
>
> If the user says "use upstream tarball" but they had git available,
> the result is to silently ignore the upstream history and use a
> tarball import instead.
>
> In keeping with the philosophy of making doing the right thing
> convenient, suboptimals things possible, and requiring mistakes to be
> explicit, ISTM that the tarball variant should mention that.

"mention that"?  Sorry, I'm not sure about how what you say here is a
response to what I wrote.

>> An alternative to 'packaging' would be 'debiandir'.
>
> In my new taxonomy, I call this "bare debian" so baredebian would be a
> possibility.
>
> I think quilt modes could contain + signs so perhaps
>baredebian+git
>baredebian+tarball

This, or debiandir+git and debiandir+tarball, LGTM.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#930274: RFS: junitparser/1.3.2-1 [ITP]

[Bastian Germann]

Hi Herbert,

Thanks for coming back to me. I uploaded a new version with the
suggested changes.

> # lintian-info -t 'tag'
> 
>  - upstream-metadata-file-is-missing
>
>It is pedantic. There are info here to fix that:
>Refer to https://dep-team.pages.debian.net/deps/dep12/ and
>https://wiki.debian.org/UpstreamMetadata for details.

I have included a metadata file.

>  - debian-watch-does-not-check-gpg-signature
>
>There is gpg signature. Ignore.
> 
>  - library-package-name-for-application usr/bin/junitparser
>application-in-library-section python usr/bin/junitparser
> 
>Junitparser README.rst file shows how to use it as a module and
>by command line. The command 'tree debian/python3-junitparser'
>shows the module and the command line script. The manpage is
>the README.rst file.
> 
>Please split the package (one depends on other):
>   
>- python3-junitparser is the module
>- junitparser is the 'utils' (in Section)
> 
>The README.rst file. The command line part can be the manpage.
>The rest can be a documentation in '/usr/share'

Okay. I have included the README.rst in python3-junitparser and moved
the binary and its edited manpage to the package junitparser.

> The package does not build twice because junitparser.egg-info dir
> is not removed between builds. Please override dh_clean to do that.

I used the debian/clean file for that.

> There is no 'debian/tests/control' file. No CI. Please see to how
> run upstream tests by autopkgtest. 
> 
> https://ci.debian.net/

I already had a "Testsuite: autopkgtest-pkg-python" line in d/control. I
guess this is also picked up by ci.debian.net. If not, what should I put
into debian/tests/control to run the same tests there?

Cheers,
Bastian

Bug#931251: www.debian.org: /misc/laptops/ and /misc/related_links removed from repo but still served

[Rafa]

Package: www.debian.org
Severity: normal

Dear Maintainers,

I could be misinterpreting something but, taking into account that in
commit 00ee01a963076d499ecc72b4197a38bf69001e36 misc/laptops/ and
misc/related_links were removed from the repository (as one of bug
#924888-related tasks), I expected that, as of today, pages
https://www.debian.org/misc/laptops/index.html and
https://www.debian.org/misc/related_links.html would return a 404 error
code. However, those pages are still being served.

Is that correct?

Thanks.

Regards,

Rafa.



signature.asc
Description: PGP signature

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Justin B Rye]

Justin B Rye wrote:
> Okay, back to the drawing board:

I attach a slightly rephrased version with markup.

> [...]
>
> It sounds as if we should also be adding something to the effect that
> 
>  With systemd it may be simpler to configure virtual network devices
>  using a .netdev file - see
>  "https://www.freedesktop.org/software/systemd/man/systemd.netdev.html#[Bond] 
> Section Options".

I left this out.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 2edb9838..d837b921 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -203,33 +203,28 @@ $ sudo update-initramfs -u
 
 Module configuration for bonding and dummy interfaces
 
-  Administrators who are using channel bonding and/or dummy
-  interfaces (for instance to configure a machine as a router), and
-  who have set up module parameters in a file under
-  /etc/modprobe.d, may need to change the name
-  of the local configuration file used, to avoid these parameters
-  being ignored after the upgrade to buster.
-
-
-  In buster, udev ships a
-  file /lib/modprobe.d/systemd.conf designed to
-  make it easier to configure such interfaces using
-  systemd-networkd. This contains the lines
+  Systems using channel bonding and/or dummy interfaces, for instance to
+  configure a machine as a router, may encounter problems upgrading to buster.
+  New versions of udev install a
+  file /lib/modprobe.d/systemd.conf (intended to
+  simplify configuration via systemd-networkd) which
+  contains the lines
 
 
  options bonding max_bonds=0
  options dummy numdummies=0
 
 
- A file in /lib/modprobe.d can be overridden by
- one with the same name under /etc/modprobe.d,
- but the names are processed in alphabetical order, so
- /lib/modprobe.d/systemd.conf follows and
- overrides (for instance)
- /etc/modprobe.d/dummy.conf. Make sure that any
- local configuration file has a name that sorts after
- systemd.conf, such as
- /etc/modprobe.d/zz-local.conf.
+  Admins who were depending on different values will need to ensure they are
+  set in the correct way to take precedence. A file in
+  /lib/modprobe.d can be overridden by one with the
+  same name under /etc/modprobe.d, but the names are
+  processed in alphabetical order, so
+  /lib/modprobe.d/systemd.conf follows and overrides
+  (for instance) /etc/modprobe.d/dummy.conf. Make sure
+  that any local configuration file has a name that sorts after
+  systemd.conf, such as
+  /etc/modprobe.d/zz-local.conf.
 
   
 

Bug#907183: can be closed?

[Dominik Stadler]

as far as I see this is resolved since some time already via

lirc (0.10.1-1) unstable; urgency=medium

  * New minor upstream release.
  * Add fix for lirc-setup(1) crash on startup.
  * Services besides lircd.socket disabled after install.
  * Bump standards-version to 4.2.1 without changes.
  * Drop 0001-build... patch now upstreamed.
  * Obsolete priority: extra => optional.

 -- Alec Leamas   Fri, 12 Oct 2018 16:51:50 -0400

Bug#174424: Advertising Promotion On Your Vehicle

[SPIKE ENERGY INC]

Hello

Drive through your normal routine with our company stickers & get Four hundred 
dollars compensation Weekly.


Thanks
Spike Energy Inc

Bug#931250:

[Mechtilde Stehmann]

Package: hibiscus
Version: 2.8.10+dfsg-1
Severity: normal

I create a config file to use Hibiscus with MariaDB as a backend.

Therefore you need an additional config  file which is described under
https://www.willuhn.de/wiki/doku.php?id=support:mysql#hibiscus_konfigurieren.


The diff contains my anonymised config file to publish as an example

The package libmariadb-java was installed with jameica.

System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages hibiscus depends on:
ii  jameica  2.8.4+dfsg-1
ii  libhbci4j-core-java  3.0.22+dfsg-1
ii  libitext5-java   5.5.13-1
ii  libobantoo-java  2.1.12+ds1-2
ii  libpostgresql-jdbc-java  42.2.5-2
ii  libsuper-csv-java2.4.0-2
ii  libswtchart-java 0.10.0-3

hibiscus recommends no packages.

hibiscus suggests no packages.

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
diff --git a/debian/examples/de.willuhn.jameica.hbci.rmi.HBCIDBService.properties b/debian/examples/de.willuhn.jameica.hbci.rmi.HBCIDBService.properties
new file mode 100644
index 000..9650196
--- /dev/null
+++ b/debian/examples/de.willuhn.jameica.hbci.rmi.HBCIDBService.properties
@@ -0,0 +1,7 @@
+#Sat Nov 17 18:44:32 CET 2018
+#https://www.willuhn.de/wiki/doku.php?id=support:mysql#hibiscus_konfigurieren
+database.driver=de.willuhn.jameica.hbci.server.DBSupportMySqlImpl
+database.driver.mysql.jdbcdriver=org.mariadb.jdbc.Driver
+database.driver.mysql.jdbcurl=jdbc\:mysql\://\:3306/hibiscus?useUnicode\=Yes\=ISO8859_1\=Europe/Paris
+database.driver.mysql.username=
+database.driver.mysql.password=
diff --git a/debian/hibiscus.examples b/debian/hibiscus.examples
new file mode 100644
index 000..e2cfb36
--- /dev/null
+++ b/debian/hibiscus.examples
@@ -0,0 +1 @@
+debian/examples/de.willuhn.jameica.hbci.rmi.HBCIDBService.properties


signature.asc
Description: OpenPGP digital signature

Bug#928111: [pre-approval] unblock: icu/63.2-1

[GCS]

Hi Paul and Ivo,

On Tue, Jun 18, 2019 at 7:23 PM Paul Gevers  wrote:
> On 17-06-2019 22:05, László Böszörményi (GCS) wrote:
> > On Mon, Jun 17, 2019 at 9:50 PM Paul Gevers  wrote:
>
> >> Do I understand correctly that what we are now getting with this version 
> >> is:
> >>
> >> - Reiwa support
> >> - fix for the speed regression?
 This is a friendly ping on how you decide on ICU. As a recap, ICU 63
is in a maintenance mode with only bugfixes applied.
As of this, the ICU 63.2-2 in Sid which should be part of Buster
contains the following changes over 63.1-6:
- speed up one of its working (MutableCodePointTrie.build()) with hashtables,
- include the previously backported security fixes,
- adds Japanese Reiwa support,
- updates to the IANA tzdata 2019a release.

It's in our archives _and_ in Ubuntu for almost three weeks without
any regression.

Thanks for consideration,
Laszlo/GCS

Bug#931249: ITP: q2-cutadapt -- QIIME 2 plugin to work with adapters in sequence data

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-cutadapt
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin to work with adapters in sequence data
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-cutadapt

Bug#931248: pan: No icon bar.

[Nicolas Patrois]

Package: pan
Version: 0.145-1
Severity: normal

Dear Maintainer,

After some years without launching Pan, I saw that the post message windows has
no icons in the icon bar.
I’ll send a screenshot.



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

Kernel: Linux 4.17.0-3-686-pae (SMP w/3 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pan depends on:
ii  gnome-keyring3.28.2-5
ii  gnupg2.2.13-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libenchant1c2a   1.6.0-11.1+b1
ii  libfribidi0  1.0.5-3.1
ii  libgcc1  1:8.3.0-7
ii  libgck-1-0   3.28.1-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgcr-ui-3-13.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2
ii  libgmime-2.6-0   2.6.23+dfsg1-4
ii  libgnutls30  3.6.7-4
ii  libgtk-3-0   3.24.5-1
ii  libgtkspell3-3-0 3.0.9-3
ii  libnotify4   0.7.7-4
ii  libp11-kit0  0.23.15-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libsecret-1-00.18.7-1
ii  libstdc++6   8.3.0-7
ii  zlib1g   1:1.2.11.dfsg-1

pan recommends no packages.

pan suggests no packages.

-- no debconf information

Bug#931223: [Debian-science-sagemath] Fwd: sagemath: sage test fails to test sagetex example_doctest.sage generated from sagetex example.tex

[Jerome BENOIT]

Hello,

On 29/06/2019 12:26, Dima Pasechnik wrote:
> On Fri, Jun 28, 2019 at 3:56 PM Jerome BENOIT  wrote:
>>
>>
>>
>>
>>  Forwarded Message 
>> Subject: sagemath: sage test fails to test sagetex example_doctest.sage 
>> generated from sagetex example.tex
>> Date: Fri, 28 Jun 2019 18:25:20 +0400
>> From: Jerome Benoit 
>> To: Debian Bug Tracking System 
>>
>> Source: sagemath
>> Version: 8.6-6
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> for the sake of curiosity, I have just tried to doctest the sage script 
>> generated
>> by SageTeX for the example.tex : the test reveals an issue with 
>> sage-runtests .
>> The issue can be reproduce as follows (when sagetex-doc is installed):
>>
>> cd 
>> cp -p /usr/share/doc/sagetex/examples/example.tex .
>> pdflatex example.tex
>> sage -t example_doctest.sage
>>
>> The last command gives:
>>
>> Traceback (most recent call last):
> 
> Start Sage shell before doing `sage -t ...`, by running
> `sage -sh`. Then everything should be set up properly to let
> `sage -t` work.

The issue remains. This is consistent with the remark previously made by Tobias.

Thanks,
Jerome

> 
> HTH
> Dima
> 
> 
>>   File "/usr/share/sagemath/bin/sage-runtests", line 162, in 
>> DC = DocTestController(options, args)
>> File "/usr/lib/python2.7/dist-packages/sage/doctest/control.py", 
>> line 357, in __init__
>> for pkg in list_packages('optional', local=True).values():
>> File "/usr/lib/python2.7/dist-packages/sage/misc/package.py", line 
>> 228, in list_packages
>> for p in os.listdir(SAGE_PKGS):
>> OSError: [Errno 2] No such file or directory: 
>> '/usr/share/sagemath/build/pkgs'
>>
>> As it does not look as a sagetex issue but rather as a sagemath issue, I 
>> submitted this issue
>> as sagemath bug.
>>
>> Thanks,
>> Jerome
>>
>>
>>
>> -- System Information:
>> Debian Release: Stretch*
>>   APT prefers stable
>>   APT policy: (990, 'stable'), (500, 'stable-updates')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
>> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
>> LANGUAGE=en_GB:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: sysvinit (via /sbin/init)
>>
>> ___
>> Debian-science-sagemath mailing list
>> debian-science-sagem...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
> 
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#929084: Maybe at least document those keystrokes?

[Justin B Rye]

Paul Gevers wrote:
> +  
> +
> +Accessing GNOME Settings app without mouse
> +
> +  Without a pointing device, it isn't directly possible to change 
> settings

Finding a good place for "directly" is tricky, so how about

 Without a pointing device, there is no direct way of changing settings

> +  in the GNOME Settings app provided by  +  role="package">gnome-control-center. As a work-around, one

The release-notes just use "generic you" rather than "one", which
avoids the problem that different branches of English use "one"
differently - in US English "one uses one's tab key" sounds impossibly 
formal and usually becomes "one uses his or her tab key", but in my
own dialect it has to be the former and the latter is ungrammatical.

I was also going to say "nobody hyphenates workaround", but it turns
out some dictionaries do!

> +  can navigate from the sidebar to the main content by pressing the
> +  Right Arrow twice. To get back to the sidebar, one can
> +  start a search with  +  action='simul'>CtrlF, type
> +  something, then hit Esc to cancel the search. Now one
> +  can use the Up Arrow and Down Arrow 
> to
> +  navigate the sidebar. It is not possible to select search results with
> +  the keyboard.
> +
> +  
> +
>  
>  
>  

Revised patch attached (I've cheated and just edited yours).
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 2edb9838..dc38df0a 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -646,6 +646,24 @@ $ sudo update-initramfs -u
 
   
 
+  
+
+Accessing GNOME Settings app without mouse
+
+  Without a pointing device, there is  no direct way to change settings
+  in the GNOME Settings app provided by gnome-control-center. As a work-around, you
+  can navigate from the sidebar to the main content by pressing the
+  Right Arrow twice. To get back to the sidebar, you can
+  start a search with CtrlF, type
+  something, then hit Esc to cancel the search. Now you
+  can use the Up Arrow and Down Arrow to
+  navigate the sidebar. It is not possible to select search results with
+  the keyboard.
+
+  
+
 
 
 

Bug#931224: In default style, lettered lists come out as numbered

[Adam D. Barratt]

On Fri, 2019-06-28 at 22:19 +0100, Ian Jackson wrote:
> Adam D. Barratt writes ("Re: Bug#931224: In default style, lettered
> lists come out as numbered"):
> > This appears to be due to the main Debian CSS setting "list-style-
> > type: 
> > decimal" for OL elements. That could be overridden on the wiki side
> > by
> > setting "ol[type=A] {list-style-type:upper-alpha;}" in one of the
> > stylesheets that is applied later.
> 
> Is there a good reason for the main CSS setting ?

I'm afraid I don't know specifically, just debugged the style to see
what was going on. The web team might know, I'm not sure who's still
around from when the current style was designed.

Regards,

Adam

Bug#931052: release-notes text proposal for bug 931052: webkit2gtk not supported on non-sse2 i386 hardware

[Justin B Rye]

Paul Gevers wrote:
> +  
> +Initially no support for WebKitGTK based applications on non-SSE2

   No initial support for WebKitGTK-based applications on non-SSE2

Or maybe just

   WebKitGTK (initially) requires SSE2 support

And how are we deciding when it's "WebKitGTK" and when it's
"webkit2gtk"?  Bear in mind that users have no easy way of mapping
from the name of a source package to the name of the specific library
they might or might not have installed.

> +systems
> +
> +  Due to changes in the upstream code,  +  role="package">webkit2gtk has been built with SSE2
> +  support. The changes in the Debian code came too late to be 
> incorporated

Surely the change is that it now *lacks* support for *non*-SSE2
systems?  Or you could say that it has been built with a dependency
on SSE2 support.  Or:

 role="package">webkit2gtk has been built requiring SSE2
 support. Fixes for this in the Debian code came too late to be 
incorporated

> +  in the initial buster release. This means that systems that don't have
> +  SSE2 support build into their CPU can't run applications which use

s/build/built/

> +  WebKitGTK, e.g. liferea or
> +  zenity. These applications will
> +  crash, most likely with an Illegal instruction error
> +  message. It is expected that  +  role="package">webkit2gtk will support these older systems
> +  after the first update of  +  role="package">webkit2gtk in either a point release or
> +  security update.

This is also a bit short on concrete advice for users.  Could we add
something like

Users of a modern desktop environment with older (roughly,
pre-Pentium IV) CPUs may wish to delay upgrading until then.

None of my machines are this ancient, but "dpkg -l | grep -i webkit"
gives no output, so I would be safe anyway - right?

> +
> +  
> +
>
>  Noteworthy obsolete packages
>  

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#931247: linux-image-5.0.0-trunk-amd64-unsigned: could enable pressure stall information?

[Ryutaroh Matsumoto]

Package: src:linux
Version: 5.0.2-1~exp1
Severity: wishlist

Dear Maintainer,

Could you consider to set the kernel config variables as follows?
CONFIG_PSI=y
CONFIG_PSI_DEFAULT_DISABLED=y

PSI stands for "pressure stall information" as described in
https://lwn.net/ml/cgroups/20180712172942.10094-1-han...@cmpxchg.org/

It is enabled only if "psi=1" is given as the boot kernel parameter,
so the only interested users can try and be affected.

Best regards,
Ryutaroh Matsumoto


-- Package-specific info:
** Version:
Linux version 5.0.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-3)) #1 SMP Debian 5.0.2-1~exp1 (2019-03-18)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.0.0-trunk-amd64 
root=UUID=2fac8e46-9da0-4d9c-8b22-79bc7c6e1a8d ro psi=1 i8042.reset=1 
systemd.unified_cgroup_hierarchy=1

** Tainted: E (8192)
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Panasonic Corporation
product_name: CF-LX3YEUCU
product_version: 001
chassis_vendor: Panasonic Corporation
chassis_version: 001
bios_vendor: American Megatrends Inc.
bios_version: V1.11L16
board_vendor: Panasonic Corporation
board_name: CFLX3-1L
board_version: 1

** Loaded modules:
fuse(E)
ufs(E)
qnx4(E)
hfsplus(E)
hfs(E)
minix(E)
ntfs(E)
msdos(E)
jfs(E)
xfs(E)
dm_mod(E)
nft_chain_route_ipv4(E)
xt_CHECKSUM(E)
nft_chain_nat_ipv4(E)
ipt_MASQUERADE(E)
nf_nat_ipv4(E)
nf_nat(E)
xt_conntrack(E)
nf_conntrack(E)
nf_defrag_ipv6(E)
nf_defrag_ipv4(E)
ipt_REJECT(E)
nf_reject_ipv4(E)
nft_counter(E)
xt_tcpudp(E)
nft_compat(E)
tun(E)
bridge(E)
stp(E)
llc(E)
nf_tables(E)
devlink(E)
nfnetlink(E)
ctr(E)
ccm(E)
cmac(E)
bnep(E)
nls_ascii(E)
nls_cp437(E)
vfat(E)
fat(E)
intel_rapl(E)
x86_pkg_temp_thermal(E)
intel_powerclamp(E)
coretemp(E)
arc4(E)
kvm_intel(E)
btusb(E)
kvm(E)
irqbypass(E)
uvcvideo(E)
btrtl(E)
btbcm(E)
iwlmvm(E)
videobuf2_vmalloc(E)
videobuf2_memops(E)
videobuf2_v4l2(E)
btintel(E)
mac80211(E)
snd_hda_codec_realtek(E)
snd_hda_codec_generic(E)
snd_hda_codec_hdmi(E)
ledtrig_audio(E)
videobuf2_common(E)
snd_hda_intel(E)
videodev(E)
snd_hda_codec(E)
snd_hda_core(E)
iwlwifi(E)
media(E)
snd_hwdep(E)
snd_pcm(E)
snd_timer(E)
snd(E)
bluetooth(E)
drbg(E)
ansi_cprng(E)
ecdh_generic(E)
acpi_als(E)
soundcore(E)
crct10dif_pclmul(E)
cfg80211(E)
crc32_pclmul(E)
mei_me(E)
ghash_clmulni_intel(E)
kfifo_buf(E)
industrialio(E)
sg(E)
mei(E)
joydev(E)
rfkill(E)
iTCO_wdt(E)
iTCO_vendor_support(E)
serio_raw(E)
efi_pstore(E)
efivars(E)
int3400_thermal(E)
processor_thermal_device(E)
panasonic_laptop(E)
intel_smartconnect(E)
acpi_thermal_rel(E)
intel_soc_dts_iosf(E)
int3403_thermal(E)
intel_pch_thermal(E)
int3402_thermal(E)
int340x_thermal_zone(E)
evdev(E)
pcspkr(E)
sparse_keymap(E)
pcc_cpufreq(E)
intel_cstate(E)
intel_uncore(E)
intel_rapl_perf(E)
battery(E)
ac(E)
parport_pc(E)
ppdev(E)
lp(E)
parport(E)
efivarfs(E)
ip_tables(E)
x_tables(E)
autofs4(E)
ext4(E)
crc16(E)
mbcache(E)
jbd2(E)
fscrypto(E)
ecb(E)
btrfs(E)
xor(E)
zstd_decompress(E)
zstd_compress(E)
raid6_pq(E)
libcrc32c(E)
crc32c_generic(E)
sd_mod(E)
crc32c_intel(E)
aesni_intel(E)
i915(E)
ahci(E)
sdhci_pci(E)
ehci_pci(E)
libahci(E)
xhci_pci(E)
i2c_algo_bit(E)
cqhci(E)
aes_x86_64(E)
crypto_simd(E)
xhci_hcd(E)
libata(E)
psmouse(E)
cryptd(E)
ehci_hcd(E)
glue_helper(E)
sdhci(E)
drm_kms_helper(E)
lpc_ich(E)
i2c_i801(E)
scsi_mod(E)
mmc_core(E)
usbcore(E)
e1000e(E)
usb_common(E)
drm(E)
thermal(E)
fan(E)
video(E)
button(E)

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller 
[8086:0a04] (rev 09)
Subsystem: Matsushita Electric Industrial Co., Ltd. Haswell-ULT DRAM 
Controller [10f7:8338]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: hsw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT 
Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA 
controller])
Subsystem: Matsushita Electric Industrial Co., Ltd. Haswell-ULT 
Integrated Graphics Controller [10f7:8338]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller 
[8086:0a0c] (rev 09)
Subsystem: Matsushita Electric Industrial Co., Ltd. Haswell-ULT HD 
Audio Controller [10f7:8338]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:04.0 Signal processing controller [1180]: Intel Corporation 

Bug#930880: Local variables don't work

[David Bremner]

積丹尼 Dan Jacobson  writes:

Control: severity -1 minor

> Package: elpa-debian-el
> Version: 37.8
> File: /usr/share/emacs/site-lisp/elpa-src/debian-el-37/apt-sources.el
>
> Don't disable local variables set in files please.
>
> # cat /etc/apt/sources.list.d/jidanni.list
> deb http://opensource.nchc.org.tw/debian/ experimental main contrib non-free
> deb http://opensource.nchc.org.tw/debian/ unstable main contrib non-free
>
> # Local Variables:
> # compile-command: "perl -nwle 's!//\K[a-z.]+tw!ftp.tw.debian.org! && print;' 
> jidanni.list | tee temp.list"
> # End:

I suppose it is technically a bug, since the (ancient) documentation
suggests using local variables.

To be honest I'm not sure supporting local variables in
/etc/apt/sources.list is a good idea. What happens when someone edit's
the file as root?

As a workaround the can always do something like M-:
(hack-local-variables) ; or some automation of that.

Bug#931052: release-notes text proposal for bug 931052: webkit2gtk not supported on non-sse2 i386 hardware

[Alberto Garcia]

On Sat, Jun 29, 2019 at 11:18:52AM +0200, Paul Gevers wrote:

> On 27-06-2019 13:27, Paul Gevers wrote:
> > We like to support non-sse2 on i386, but we are not comfortable fixing
> > webkit2gtk at this stage of the release. Therefore, we will not unblock
> > this change, but we want the release notes to mention this, so users are
> > warned.
> 
> I cooked up the attached proposal for the release notes. Reviews
> very welcome.
> 
> @Alberto, did you have any intention to upload to backports once
> buster is released? If so, do you think it is OK to mention this in
> the release-notes?

Yes, my plan is to publish backports of every stable WebKitGTK
release. I have been doing it for stretch without problems for the
last couple of years.

Berto

Bug#781177: How to reproduce this bug

[Manolo Díaz]

Dear Maintainer,

This bug does not appear in a fresh install, but upgrading from version
1.20.1* (tested 1.20.1-3). After upgrading
/usr/lib/python2.7/dist-packages/veusz/resources remains as a dangling
symlink, pointing to the old place. Forcing a reinstall makes this
symlink point to the right place.

It happens the same upgrading from to 1.20.1-3 to 1.21.1-1.*. Versions
3.0* seem to be free of this bug.

Best Regards,
-- 
Manolo Díaz

Bug#928931: Bug #928931: more info + patch

[Raphaël Halimi]

Control: tags -1 +patch

Hi,

I don't mean to rush you, but I noticed that this bug is still not fixed
in d-i RC2.

My current workaround is to add a hook in base-installer.d (because it
has to be done just before apt gets configured) to replace
/usr/lib/apt-setup/generators/60local with a version including a line to
install gnupg before "apt-key add" is called (patch included).

(the modification can also be done manually during the base system
installation phase, but it is error-prone, has to be done very quickly
at the right moment, and of course completely defeats the purpose of an
unattended installation)

I noticed that gnupg used to be Priority: important, whereas it's now
Priority: optional.

If installing gnupg is what it takes to fix the bug, IMHO it should be
done; anyway, with this patch, it would be installed only if a local
repository with a GnuPG key is used at all.

I hope this fix (or another one of your own choice) will make it to d-i
before release.

Regards,

-- 
Raphaël Halimi
--- 60local.orig	2018-08-10 21:20:36.0 +0200
+++ 60local	2019-06-29 10:36:46.0 +0200
@@ -35,6 +35,7 @@
 		while :; do
 			if fetch-url "$key" "$ROOT/tmp/key$i.pub"; then
 # add it to the keyring
+$chroot $ROOT apt-get --yes --no-install-recommends install gnupg
 $chroot $ROOT apt-key add "/tmp/key$i.pub"
 rm -f "$ROOT/tmp/key$i.pub"
 break


signature.asc
Description: OpenPGP digital signature

Bug#931052: release-notes text proposal for bug 931052: webkit2gtk not supported on non-sse2 i386 hardware

[Paul Gevers]

Hi all,

On 27-06-2019 13:27, Paul Gevers wrote:
> We like to support non-sse2 on i386, but we are not comfortable fixing
> webkit2gtk at this stage of the release. Therefore, we will not unblock
> this change, but we want the release notes to mention this, so users are
> warned.

I cooked up the attached proposal for the release notes. Reviews very
welcome.

@Alberto, did you have any intention to upload to backports once buster
is released? If so, do you think it is OK to mention this in the
release-notes?

Paul
diff --git a/en/issues.dbk b/en/issues.dbk
index 2edb9838..5d657f2a 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -293,6 +293,26 @@ $ sudo update-initramfs -u
 
   
 
+  
+Initially no support for WebKitGTK based applications on non-SSE2
+systems
+
+  Due to changes in the upstream code, webkit2gtk has been built with SSE2
+  support. The changes in the Debian code came too late to be incorporated
+  in the initial buster release. This means that systems that don't have
+  SSE2 support build into their CPU can't run applications which use
+  WebKitGTK, e.g. liferea or
+  zenity. These applications will
+  crash, most likely with an Illegal instruction error
+  message. It is expected that webkit2gtk will support these older systems
+  after the first update of webkit2gtk in either a point release or
+  security update.
+
+  
+
   
 Noteworthy obsolete packages
 


signature.asc
Description: OpenPGP digital signature

Bug#929611: CVE-2019-13031

[Xavier]

Hi all,

my previous debdiff fixes CVE-2019-13031 (#931117). I'll update
debian/changelog if you agree with this update

Bug#929084: Maybe at least document those keystrokes?

[Paul Gevers]

Control: tags -1 patch

Hi,

On 16-05-2019 20:15, Paul Gevers wrote:
> On Sat, 27 Apr 2019 13:16:05 -0700 Tassia Camoes Araujo
>  wrote:
>> From what I could understand, it is unlikely this will be fixed before
>> Buster release. So how should we proceed about his bug?
>> Even if a backport can possibly be provided later, would it be possible
>> to just document the keystrokes "workaround" mentioned by Jeremy Bicha
>> in the package shipped with Buster?
>> It might be a big difference for users in need of this accessibility
>> feature.
> 
> Although I rather have the bug fixed (who doesn't) I think documenting
> is the least that can be done. @a11y team, anybody willing to update the
> Wiki? I'll make sure the release notes have something.

I propose the attached text for the release-notes. Are the instructions
correctly copied (I don't use GNOME)?

Paul
diff --git a/en/issues.dbk b/en/issues.dbk
index 2edb9838..dc38df0a 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -646,6 +646,24 @@ $ sudo update-initramfs -u
 
   
 
+  
+
+Accessing GNOME Settings app without mouse
+
+  Without a pointing device, it isn't directly possible to change settings
+  in the GNOME Settings app provided by gnome-control-center. As a work-around, one
+  can navigate from the sidebar to the main content by pressing the
+  Right Arrow twice. To get back to the sidebar, one can
+  start a search with CtrlF, type
+  something, then hit Esc to cancel the search. Now one
+  can use the Up Arrow and Down Arrow to
+  navigate the sidebar. It is not possible to select search results with
+  the keyboard.
+
+  
+
 
 
 


signature.asc
Description: OpenPGP digital signature

Bug#931246: flightcrew: CVE-2019-13032

[Salvatore Bonaccorso]

Source: flightcrew
Version: 0.7.2+dfsg-13
Severity: important
Tags: security upstream
Forwarded: https://github.com/Sigil-Ebook/flightcrew/issues/53
Control: found -1 0.7.2+dfsg-9

Hi,

The following vulnerability was published for flightcrew.

CVE-2019-13032[0]:
| An issue was discovered in FlightCrew v0.9.2 and earlier. A NULL
| pointer dereference occurs in GetRelativePathToNcx() or
| GetRelativePathsToXhtmlDocuments() when a NULL pointer is passed to
| xc::XMLUri::isValidURI(). This affects third-party software (not
| Sigil) that uses FlightCrew as a library.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13032
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13032
[1] https://github.com/Sigil-Ebook/flightcrew/issues/53

Regards,
Salvatore

Bug#931214: ImportError: No module named oslo.config

[Paul Gevers]

Control: tags -1 sid buster stretch

Dear OpenStack maintainers,

On Fri, 28 Jun 2019 13:52:43 +0200 =?iso-8859-1?Q?J=F6?= Fahlke
 wrote:
> Package: python-os-collect-config
> Version: 0.1.15-1
> Severity: grave

This is on the radar of the release team, due to the very late time in
the release. Please, any comment from your side helps judging what to do.

> I'm trying to use os-collect-config in a Debian stretch instance in an
> openstack cluster.  However, running it immediately leads to an import error:

[...]

> ImportError: No module named oslo.config

Paul



signature.asc
Description: OpenPGP digital signature

Bug#931211: s2s connections are broken after upgrading to buster

[Philipp Huebner]

Hi again,

I tried to reproduce your problem by setting up two fresh Debian Buster
installations, one i386 one amd64. s2s between them works like a charm,
and the list of installed packages is identical to yours.

For that reason I assume your problem is either in your ejabberd
configuration or you got some erlang/ejabberd stuff outside of the
package management mixed up in it.

If you're willing to share your ejabberd configuration files I am happy
to take a look, otherwise I don't know how to help you.

Best wishes
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#928956: Document removal of ecryptfs-utils from Buster

[Paul Gevers]

Hi all,

On 01-06-2019 22:06, Paul Gevers wrote:
> On Wed, 15 May 2019 13:00:52 +0100 Justin B Rye
>  wrote:
>> Daniel Lange wrote:
   * reason for removal
 not essential, but it helps to understand the issue
>>> #765854
>>> ecryptfs cannot unmount encrypted home directories due to systemd keeping
>>> the pam session active even after logout.
>>> Upstream bug https://github.com/systemd/systemd/issues/8598
>>> A work around (user unit file) has not been implemented and tested.
>>>
   * what would be the alternative(s) available in buster
>>> there is none
>>
>> Does Debian really not provide any alternative mechanisms for
>> filesystem encryption that users could switch over to?  A quick "apt
>> search" suggests that they could try encfs...
>>
   * is there a (documented) migration path
>>> there is none
>>
>> Sounds as if someone needs to write one, then.
>>  
>>> People with ecryptfs should not upgrade to Buster or enable and pin sid
>>> repositories where ecryptfs-utils, libecryptfs1 and friends are still
>>> available and continue to work (including the unmount bug linked above).
>>
>> Is the problem a result of changes in ecryptfs-utils, PAM, systemd, or
>> what?  Would upgrading systemd etc to Buster but keeping the Stretch
>> version of ecryptfs-utils installed be a better or worse option than
>> installing the Sid version?
> 
> In absence of other text, I am about to push the attached text to the
> release-notes. I hope this isn't the final text, but at least the draft
> document now mentions the problem.

Did anybody learn about (documented) migration paths in the mean time?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#931002: [Pkg-rust-maintainers] Bug#931003: Updating crates for Debian stable release

[Sylvestre Ledru]

Le 24/06/2019 à 20:03, Ximin Luo a écrit :

I am on vacation for the next two weeks, please can someone else deal with the 
following:

Due to Firefox we updated/unblocked rustc 1.34.2 for Debian Testing (and the 
next Debian Stable) release.

This causes two FTBFS bugs for crates which no longer build on rustc 1.34.2:

- #931002 coresimd https://crates.io/crates/coresimd
- #931003 simd https://crates.io/crates/simd

In fact these crates are deprecated and should be RMd. We also need to:

- update encoding-rs so it doesn't depend on simd


Done in encoding-rs 0.8.15-2. unblock request is #931245

thanks to kpcyrd!


- update packed-simd so it doesn't depend on coresimd
Should be done with packed-simd 0.3.3-2 but the dep on sleef-sys is 
still in the CI (not locally, not sure why)


I will have a deeper look today.

S

Bug#931245: unblock: encoding-rs/0.8.15-2

[Sylvestre Ledru]

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

Please unblock package encoding-rs

Last minute, we had to update rustc to facilitate the packaging
of Firefox ESR 68.
However, this new version of rustc, platform intrinsics crate aren't
supported anymore:
https://github.com/rust-lang/rust/pull/57416

This broke the rust-simd package.
This encoding-rs version is removing the dep.

The patch is big because most of it is generated code.
However, I am not worried because:
* the rust programming language is doing a huge number of checks at 
  compilation time.
* ripgrep (the main program using encoding-rs) testsuite executes
  without any issue.

unblock encoding-rs/0.8.15-2

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'stable'), 
(300, 'experimental')
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 /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru rust-encoding-rs-0.8.15/debian/0001-fix-the-copyright.patch 
rust-encoding-rs-0.8.15/debian/0001-fix-the-copyright.patch
--- rust-encoding-rs-0.8.15/debian/0001-fix-the-copyright.patch 2019-02-03 
10:33:38.0 +0100
+++ rust-encoding-rs-0.8.15/debian/0001-fix-the-copyright.patch 1970-01-01 
01:00:00.0 +0100
@@ -1,30 +0,0 @@
-From 0181b7b648e12fcaf9c8f6c1614f5055ce59 Mon Sep 17 00:00:00 2001
-From: Sylvestre Ledru 
-Date: Sat, 14 Jul 2018 18:04:25 +0200
-Subject: [PATCH] fix the copyright
-

- src/encoding-rs/debian/copyright | 6 +-
- 1 file changed, 1 insertion(+), 5 deletions(-)
-
-diff --git a/src/encoding-rs/debian/copyright 
b/src/encoding-rs/debian/copyright
-index 73b469a..87e40d2 100644
 a/src/encoding-rs/debian/copyright
-+++ b/src/encoding-rs/debian/copyright
-@@ -5,12 +5,8 @@ Source: https://github.com/hsivonen/encoding_rs
- 
- Files: *
- Copyright: 2013-2016 Henri Sivonen 
-+ 2015-2016 Mozilla Foundation
- License: MIT or Apache-2.0
--Comment:
-- FIXME (overlay): Since upstream copyright years are not available in
-- Cargo.toml, they were extracted from the upstream Git repository. This may 
not
-- be correct information so you should review and fix this before uploading to
-- the archive.
- 
- Files: debian/*
- Copyright:
--- 
-2.17.0
-
diff -Nru rust-encoding-rs-0.8.15/debian/cargo-checksum.json 
rust-encoding-rs-0.8.15/debian/cargo-checksum.json
--- rust-encoding-rs-0.8.15/debian/cargo-checksum.json  2019-02-03 
10:33:38.0 +0100
+++ rust-encoding-rs-0.8.15/debian/cargo-checksum.json  2019-06-29 
08:46:08.0 +0200
@@ -1 +1 @@
-{"package":"fd251508d65030820f3a4317af2248180db337fdb25d89967956242580277813","files":{}}
+{"package":"Could not get crate checksum","files":{}}
diff -Nru rust-encoding-rs-0.8.15/debian/changelog 
rust-encoding-rs-0.8.15/debian/changelog
--- rust-encoding-rs-0.8.15/debian/changelog2019-02-03 10:33:38.0 
+0100
+++ rust-encoding-rs-0.8.15/debian/changelog2019-06-29 08:46:08.0 
+0200
@@ -1,3 +1,9 @@
+rust-encoding-rs (0.8.15-2) unstable; urgency=high
+
+  * Disable simd to get ripgrep in buster
+
+ -- kpcyrd   Sat, 29 Jun 2019 08:46:08 +0200
+
 rust-encoding-rs (0.8.15-1) unstable; urgency=medium
 
   * Package encoding_rs 0.8.15 from crates.io using debcargo 2.2.10
diff -Nru rust-encoding-rs-0.8.15/debian/control 
rust-encoding-rs-0.8.15/debian/control
--- rust-encoding-rs-0.8.15/debian/control  2019-02-03 10:33:38.0 
+0100
+++ rust-encoding-rs-0.8.15/debian/control  2019-06-29 08:46:08.0 
+0200
@@ -2,7 +2,7 @@
 Section: rust
 Priority: optional
 Build-Depends: debhelper (>= 11),
- dh-cargo (>= 15),
+ dh-cargo (>= 18),
  cargo:native ,
  rustc:native ,
  libstd-rust-dev ,
@@ -10,7 +10,8 @@
 Maintainer: Debian Rust Maintainers 

 Uploaders:
  Sylvestre Ledru ,
- Wolfgang Silbermayr 
+ Wolfgang Silbermayr ,
+ kpcyrd 
 Standards-Version: 4.2.0
 Vcs-Git: https://salsa.debian.org/rust-team/debcargo-conf.git [src/encoding-rs]
 Vcs-Browser: 
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/encoding-rs
@@ -25,9 +26,7 @@
  librust-cfg-if-0.1+default-dev
 Suggests:
  librust-encoding-rs+fast-legacy-encode-dev (= ${binary:Version}),
- librust-encoding-rs+serde-dev (= ${binary:Version}),
- librust-encoding-rs+simd-dev (= ${binary:Version}),
- librust-encoding-rs+simd-accel-dev (= ${binary:Version})
+ librust-encoding-rs+serde-dev (= ${binary:Version})
 Provides:
  librust-encoding-rs+default-dev (= ${binary:Version}),
  librust-encoding-rs+fast-big5-hanzi-encode-dev (= ${binary:Version}),
@@ -38,6 +37,7 @@
  librust-encoding-rs+less-slow-big5-hanzi-encode-dev (= ${binary:Version}),
  librust-encoding-rs+less-slow-gb-hanzi-encode-dev (= ${binary:Version}),
  librust-encoding-rs+less-slow-kanji-encode-dev (= ${binary:Version}),
+ 

Bug#931244: whois: [INTL:ru] Russian program translation update

[Yuri Kozlov]

Package: whois
Version: 5.4.4
Severity: wishlist
Tags: l10n patch

Russian program translation update is attached.

-- 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/8 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


ru.po.gz
Description: application/gzip