Bug#924389: vim-tutor: E484: Can't open file /usr/share/nvim/runtime/tutor/tutor.vim

[James McCoy]

On Tue, Mar 12, 2019 at 12:25:51PM +0100, Arnaud Loonstra wrote:
> Running vim-tutor results in: E484: Can't open file 
> /usr/share/nvim/runtime/tutor/tutor.vim

It looks like you've changed the vim alternative to use nvim.  Neovim
has a different mechanism for running the tutor, so vimtutor isn't going
to work.

> It seems it tries to load a wrong file, ie. tutor.vim

I'll look into providing a vimtutor script for neovim and then having
vimtutor be part of the vim alternatives group.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#920024: Doesn't parse package architectures correctly when any-amd64 is used (etc.)

[Johannes Schauer]

On Tue, 22 Jan 2019 00:44:03 +0100 Raphael Hertzog  wrote:
> On Mon, 21 Jan 2019, Steve McIntyre wrote:
> > I've just been looking at the details for sbsigntool
> > (https://tracker.debian.org/pkg/sbsigntool) It looks like the tracker
> > code is confused by the architecture list for sbsigntool:
> > 
> >   Architecture: any-amd64 any-i386 arm64 armhf
> > 
> > and is just showing 
> > 
> >   arch: arm64 armhf
> > 
> > which is quite confusing!
> 
> Yeah, the data model includes a list of architectures by source package
> and the parsing keeps only entries which are real architectures, the
> architecture wildcards are just not handled.
> 
> Extract from distro_tracker/core/retrieve_data.py:
> 
> # Convert the parsed data into corresponding model instances
> if 'architectures' in entry:
> # Map the list of architecture names to their objects
> # Discards any unknown architectures.
> entry['architectures'] = Architecture.objects.filter(
> name__in=entry['architectures'])
> 
> I think we don't have any code in the tracker to handle architecture wildcard
> and try to do any mapping or expansion. Given the data model, that's we should
> aim to do here. Creating all the possible wildcards would be wrong, instead we
> want to process the list of architectures that the tracker knows of and see
> whether it matches the wildcards listed in the source package field.

Feel free to use this Debian architecture wildcard matching implementation:

https://gitlab.mister-muffin.de/josch/debarchwildcardtest/blob/master/debarch.py

In my opinion this code should really live in python-debian but hasn't been put
there yet (#771058).

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#925582: Allow telling installer about local deb and Package list locations

[積丹尼 Dan Jacobson]

Package: debian-installer

User has a USB drive, loaded with
$ mount
/dev/sdg2 on /var/cache/apt/archives type ext4
/dev/sdg1 on /var/lib/apt/lists type ext4

He takes this drive, along with another drive,
containing a Debian installation ISO, to a remote mountain (offline)
computer, intending to install Debian on it.

Alas, while running the ISO there is no way to tell it about the other
stick where those the .debs are.
Thus making an offline
https://haydenjames.io/direct-install-debian-sid-rolling-release-using-mini-iso-w-screenshots/
not possible.

See also
https://wiki.debian.org/SourcesList#CD-ROM
https://www.debian.org/releases/stretch/amd64/ch06s03.html.en#di-install-software
"/etc/apt/sources.list. You can examine and edit this file to your liking 
**after** the installation is complete."

Anyway the user would like to offline, have a way to say to the
installer:

This  is the location of a lot of *.debs.
and
This ... is a Packages file I made from them.
and
This ... is a list of packages I want you to install from it.

Sure, "just do that all later after you get Debain installed".

But that is very wasteful.

Bug#925581: impossible to scroll in mate-panel

[DC-1]

Package: libgtk-3-0
Version: 3.24.5-1

It's impossible to select new keyboard layout, due to can't scroll in
mate-keyboard-preferences .

It is a known bug discussed at:
https://github.com/mate-desktop/mate-panel/issues/920

The bug was fixed in gtk 3.24.6 with this patch:
https://gitlab.gnome.org/GNOME/gtk/commit/1d4eac211c09624d29b9309e2b92173f7477a9b7


Please backport this patch for 3.24.5 before first Buster release.

Bug#925556: UEFI or not, can't mount /dev

[積丹尼 Dan Jacobson]

LS> Clearly the initramfs was able to mount /dev and run fsck, but mounting
LS> it to /root/dev to transfer to the real rootfs failed due to a missing
LS> directory.

So it booted, meaning it is not a
https://www.debian.org/releases/stretch/amd64/ch03s06.html.en#UEFI
problem...

Bug#925580: Never leave the user staring at an empty screen, even for a second

[積丹尼 Dan Jacobson]

Package: debian-installer

Here the user is left staring at an empty screen. (Many look that way
for a while at the beginning. Even with the latest fastest hardware.)

Not for long you might say.

But long enough for the user to scratch his head, and then casually get
out his cellphone and take a picture, then wonder some more.

Please for every screen, add a "Please wait..." first.

Bug#925579: User could have just as easily clicked the UEFI or non-UEFI...

[積丹尼 Dan Jacobson]

Package: debian-installer

In https://wiki.debian.org/UEFI
We read

"debian-installer's support for UEFI is mostly contained in two modules.
 First comes the partman-efi module, and this will be loaded
 automatically if d-i recognises it has been booted in UEFI mode."

The problem here is that on e.g., ASUS, there is a 50% chance that a
user could have picked the plain JetFlash (where the d-i ISO is),
or the same ISO, but with the UEFI: prefix...


(Don't worry about the highlighted line in that photo.)

Bug#925578: Update Package: Arduino : 1.8.9

[Brian Holaday]

Package: arduino
Version: 2:1.0.5+dfsg2-4.1
severity: important

Issue:

Can the Arduino package be updated to 1.8.9 as per Arduino homepage? I
created a script for easier install.

# Install: 1.8.9 from Arduino Site

mkdir "$HOME/Arduino"
sudo mkdir /usr/local/bin/arduino
cd /usr/local/bin/arduino || exit
sudo wget "https://downloads.arduino.cc/arduino-1.8.9-linux64.tar.xz;
sudo mv arduino-1.8.9-linux64.tar.xz arduino-amd64.tar.xz
sudo tar xfJ arduino-amd64.tar.xz
sudo mv arduino-1.8.9/* /usr/local/bin/arduino/
./install.sh
sudo rm -rf arduino-1.8.9
sudo rm -rf arduino-1.8.9/ arduino-amd64.tar.xz

Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10

[Karl O. Pinc]

On Sat, 23 Mar 2019 10:44:15 +0100
Paul Gevers  wrote:

> On Tue, 14 Nov 2017 17:07:54 -0600 "Karl O. Pinc" 
> wrote:
> > Section 4.7 "Preparing for the next release" of the jessie->stretch
> > release notes do not mention that Debian 10 will require migration
> > to the kernel's "predictable network names".  (Or, I imagine, manual
> > assignment of network names.)
> > 
> > Because users are going to have to migrate anyway it might be useful
> > to do so sooner rather than later and "prepare for the next
> > release".  :-)
> > 
> > See:
> > /usr/share/doc/udev/README.Debian.gz
> > https://sources.debian.org/src/systemd/235-2/debian/udev.README.Debian/
> > Bug#881769  
> 
> We have missed the boat for the stretch release-notes, but I think
> this would also be good to mention in the buster release notes,
> right.

Yes.  It is very important to mention.  The udev README.Debian says
that new-style (not eth*, wlan*) interface names are required
under buster.  If this is true, anyone upgrading a stretch system 
that was upgraded from wheezy will have networking break, badly.

> I am not familiar with this change, could you propose a text
> for the release notes? If not, do you have ideas on who to ask?

I will see if I can get you something next week.  I started,
but am unable to finish right now.

I am no expert on this.  I hope to provide a starting point for
someone else to verify and build upon.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#833608: lintian: version-substvar-for-external-package, but external package is versioned provides

[Chris Lamb]

[Forwarding to #833608 after "unarchive" & "found"...]

- Original message -
From: Ximin Luo 
To: Chris Lamb , 833...@bugs.debian.org
Cc: 
Subject: Re: lintian: version-substvar-for-external-package, but external 
package is versioned provides
Date: Monday, 25 March 2019 10:37 PM

Control: reopen -1

Unfortunately the fix doesn't work, and lintian is still reporting these errors 
for rust packages, e.g:

https://lintian.debian.org/maintainer/pkg-rust-maintain...@alioth-lists.debian.net.html#rust-goblin

librust-goblin+default-dev -> librust-goblin+archive-dev
librust-goblin+default-dev -> librust-goblin+elf32-dev
librust-goblin+default-dev -> librust-goblin+elf64-dev
librust-goblin+default-dev -> librust-goblin+endian-fd-dev
librust-goblin+mach32-dev -> librust-goblin+endian-fd-dev
librust-goblin+mach64-dev -> librust-goblin+endian-fd-dev
librust-goblin+pe32-dev -> librust-goblin+endian-fd-dev
librust-goblin+pe64-dev -> librust-goblin+endian-fd-dev

$ aptitude show '~erust-goblin ~rnative' | grep 'Package\|Provides' | manual 
formatting

Package: librust-goblin+pe32-dev
Provides:
 librust-goblin-0+pe32-dev (= 0.0.19-1),
 librust-goblin-0.0+pe32-dev (= 0.0.19-1),
 librust-goblin-0.0.19+pe32-dev (= 0.0.19-1)

Package: librust-goblin+mach64-dev
Provides:
 librust-goblin-0+mach64-dev (= 0.0.19-1),
 librust-goblin-0.0+mach64-dev (= 0.0.19-1),
 librust-goblin-0.0.19+mach64-dev (= 0.0.19-1)

Package: librust-goblin+alloc-dev
Provides:
 librust-goblin+archive-dev (= 0.0.19-1),
 librust-goblin+endian-fd-dev (= 0.0.19-1),
 librust-goblin-0+alloc-dev (= 0.0.19-1),
 librust-goblin-0+archive-dev (= 0.0.19-1),
 librust-goblin-0+endian-fd-dev (= 0.0.19-1),
 librust-goblin-0.0+alloc-dev (= 0.0.19-1),
 librust-goblin-0.0+archive-dev (= 0.0.19-1),
 librust-goblin-0.0+endian-fd-dev (= 0.0.19-1),
 librust-goblin-0.0.19+alloc-dev (= 0.0.19-1), 
 librust-goblin-0.0.19+archive-dev (= 0.0.19-1),
 librust-goblin-0.0.19+endian-fd-dev (= 0.0.19-1)

Package: librust-goblin+mach32-dev
Provides:
 librust-goblin-0+mach32-dev (= 0.0.19-1),
 librust-goblin-0.0+mach32-dev (= 0.0.19-1),
 librust-goblin-0.0.19+mach32-dev (= 0.0.19-1)

Package: librust-goblin-dev
Provides:
 librust-goblin+elf32-dev (= 0.0.19-1),
 librust-goblin+elf64-dev (= 0.0.19-1),
 librust-goblin-0+elf32-dev (= 0.0.19-1),
 librust-goblin-0+elf64-dev (= 0.0.19-1),
 librust-goblin-0-dev (= 0.0.19-1),
 librust-goblin-0.0+elf32-dev (= 0.0.19-1),
 librust-goblin-0.0+elf64-dev (= 0.0.19-1),
 librust-goblin-0.0-dev (= 0.0.19-1),
 librust-goblin-0.0.19+elf32-dev (= 0.0.19-1),
 librust-goblin-0.0.19+elf64-dev (= 0.0.19-1),
 librust-goblin-0.0.19-dev (= 0.0.19-1)

Package: librust-goblin+log-dev
Provides:
 librust-goblin-0+log-dev (= 0.0.19-1),
 librust-goblin-0.0+log-dev (= 0.0.19-1),
 librust-goblin-0.0.19+log-dev (= 0.0.19-1)

Package: librust-goblin+pe64-dev
Provides:
 librust-goblin-0+pe64-dev (= 0.0.19-1),
 librust-goblin-0.0+pe64-dev (= 0.0.19-1),
 librust-goblin-0.0.19+pe64-dev (= 0.0.19-1)

Package: librust-goblin+default-dev
Provides:
 librust-goblin-0+default-dev (= 0.0.19-1),
 librust-goblin-0.0+default-dev (= 0.0.19-1),
 librust-goblin-0.0.19+default-dev (= 0.0.19-1)

Package: librust-goblin+std-dev
Provides:
 librust-goblin-0+std-dev (= 0.0.19-1),
 librust-goblin-0.0+std-dev (= 0.0.19-1),
 librust-goblin-0.0.19+std-dev (= 0.0.19-1)

Chris Lamb:
> tags 833608 + pending
> thanks
> 
> Thanks all. Fixed in Git, pending upload:
> 
>   
> https://salsa.debian.org/lintian/lintian/commit/83c2c79535714c8457697ea567aec645db0fdc27
> 
>   checks/version-substvars.pm| 4 
>   debian/changelog   | 4 
>   t/tests/version-substvars-general/debian/debian/control.in | 2 ++
>   3 files changed, 10 insertions(+)
> 
> 
> Regards,
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#925354: [Debian-ha-maintainers]: Bug#925354: pacemaker-dev: missing Breaks+Replaces: libcrmcluster1-dev

[Andreas Beckmann]

On 2019-03-27 00:48, wf...@niif.hu wrote:
> Yes, I'm on it.  It's somewhat bizarre: libcrmcluster1-dev wasn't part
> of jessie or stretch.  Similarly, pacemaker-dev was present in wheezy
> only, until I reintroduced it recently, and looks like its ghost came
> back to haunt us.  I didn't anticipate piuparts to start with wheezy
> when testing buster upgrades.

Well, I'm running tests starting from all stable releases since lenny
upgrading release by release to testing, keeping all the cruft ...
Sometimes it returns such gems. :-)

Andreas

Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages

[Justin B Rye]

Paul Gevers wrote:
> I wonder what is missing there from the perspective of this bug. The
> section about dummy packages exists since before 2009 and currently reads:
> '''
> Dummy packages
> 
>   Some packages from  have been split into several
> packages in , often to improve system maintainability.  To
> ease the upgrade path in such cases,  often provides
> dummy packages: empty packages that have the same name as
> the old package in  with dependencies that cause the new
> packages to be installed.  These dummy packages are
> considered redundant after the upgrade and can be safely removed.
> 
> 
>   Most (but not all) dummy packages' descriptions indicate their
> purpose. Package descriptions for dummy packages are not uniform,
> however, so you might also find deborphan with the
> --guess-* options (e.g.
> --guess-dummy) useful to detect them in your system.
>  Note that some dummy packages are not intended to be removed after an
> upgrade but are, instead, used to keep track of the current available
> version of a program over time.
> 
>   
> '''
> 
> Suggestions on how to improve that text are welcome.

One thing it doesn't have is any mention of the word "transitional",
which is the one you're actually better off searching for.

(It might also usefully end by referring to the *other* sort of dummy
packages as "dependency metapackages".)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#925577: shairport-sync: Crashes with "free(): double free detected in tcache 2" with instance name changed

[Ari Sovijarvi]

Package: shairport-sync
Version: 3.2.2-1
Severity: normal

If the name-parameter is changed within the general block to something else 
than "%H", shairport-sync
will crash with following error when either launched from init scripts or with 
--daemon parameter:

Looking for configuration file at full path "/etc/shairport-sync.conf"
free(): double free detected in tcache 2
Aborted

Running it without the daemon parameter or leaving the system name as "%H" 
stops the crash.

In my case, the offending configuration option was:

general =
{
   name = "Arcade";
};


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

Kernel: Linux 4.19.0-2-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)

Versions of packages shairport-sync depends on:
ii  adduser   3.118
ii  avahi-daemon  0.7-4+b1
ii  libasound21.1.8-1
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libc6 2.28-8
ii  libconfig91.5-0.4
ii  libdaemon00.14-7
ii  libgcc1   1:8.3.0-2
ii  libpopt0  1.16-12
ii  libpulse0 12.2-4
ii  libsndfile1   1.0.28-6
ii  libsoxr0  0.1.2-3
ii  libssl1.1 1.1.1b-1
ii  libstdc++68.3.0-2

shairport-sync recommends no packages.

shairport-sync suggests no packages.

-- Configuration Files:
/etc/shairport-sync.conf changed [not included]

-- no debconf information

Bug#925539: gnome-weather: Crashes when typing a place's name

[Bernhard Übelacker]

Control: fixed 925539 3.26.1-1


Dear Maintainer,
unfortunately realised just now that there is
already a newer version 3.26.1-1 in unstable which
contains both patches - should therefore fix the issue.

Kind regards,
Bernhard

Bug#864017: release-notes: Assumes /etc/apt/sources.list is used (and not /etc/apt/sources.list.d/*.list or deb822) [general]

[Justin B Rye]

Paul Gevers wrote:
>>> we mean by "APT source-list files", if only by pointing at
>>> sources.list(5).
>> 
>> I wanted to link to that man page as well, so let's find a place. I'm
>> nearly of to bed now, so if you find a good spot before I do tomorrow,
>> don't hesitate to mail.
> 
> I have added a link to the manpages (3 places), but I am not totally
> happy with how it reads.
> 
> What do you think?

I don't know whether we're "allowed" to link to manpages.d.o here; the
only other place I see a man page pointer is in whats-new.dbk, which
just says

 See the cryptsetup manpage

On the other hand if we *are* going to point at manpages.d.o there are
probably lots of other places where it might help.

Reading through the patch:
> From 710a6ac851e47e6952087aec89a5b7e8397cf9be Mon Sep 17 00:00:00 2001
> From: Paul Gevers 
> Date: Sun, 24 Mar 2019 20:31:48 +0100
> Subject: [PATCH] Generalize use of APT source-list files
> 
> Closes: #864017
> ---
>  en/old-stuff.dbk | 36 ++--
>  en/upgrading.dbk | 85 +---
>  2 files changed, 63 insertions(+), 58 deletions(-)
> 
> diff --git a/en/old-stuff.dbk b/en/old-stuff.dbk
> index 0a53d737..ec26ca91 100644
> --- a/en/old-stuff.dbk
> +++ b/en/old-stuff.dbk
> @@ -27,14 +27,14 @@ upgraded to the latest  point release.
>  
>  
>  
> -Checking your sources list
> +Checking your APT source-list files
>  
> -If any of the lines in your /etc/apt/sources.list
> -refer to stable, it effectively
> -points to  already. This might not be what you want if
> -you are not ready yet for the upgrade.  If you have already run
> -apt update, you can still get back without
> -problems by following the procedure below.
> +  If any of the lines in your APT source-list files (see  +  
> url="https://manpages.debian.org//apt/sources.list.5.en.html;>sources.list(5))
> +  refer to stable, it effectively points to
> +   already. This might not be what you want if you are not ready
> +  yet for the upgrade.  If you have already run apt 
> update,
> +  you can still get back without problems by following the procedure below.
>  

Instead of trying to cram this into parentheses we should explain it
more fully the first time we mention it:

   
 The main configuration file that APT uses to decide what sources it should
 download packages from is /etc/apt/sources.list, but
 it can also use files in the /etc/apt/sources.list.d/
 directory - for details see https://manpages.debian.org//apt/sources.list.5.html;>sources.list(5).
 If your system is using multiple source-list files then you will need to 
ensure
 they stay consistent.
   
   
 If any of your APT source-list files contain references to
 stable, this is effectively pointing to
  already. This might not be what you want if you are not yet
 ready for the upgrade. If you have already run apt 
update,
 you can still get back without problems by following the procedure below.
   

Note that I've subtracted the ".en" component from the manpage URL;
but it's possible that the URL should be defined in release-notes.ent
instead.

Oh, wait, I hadn't realised that old-stuff.dbk is only alphabetically
the first section; it gets turned into an appendix.  So instead the
paragraph giving the full explanation should go in upgrading.dbk, and
then this paragraph in old-stuff.dbk should just refer back to that:

 If any of your APT source-list files (see ) contain
 references to stable, this is 
effectively pointing to

>  
>  If you have also already installed packages from , there 
> probably
> @@ -43,28 +43,28 @@ that case you will have to decide for yourself whether 
> you want to continue or
>  not.  It is possible to downgrade packages, but that is not covered here.
>  
>  
> -Open the file /etc/apt/sources.list with your favorite
> +  Open the relevant APT source-list file, e.g.
> +  /etc/apt/sources.list, with your favorite
>  editor (as root) and check all lines beginning with

It might be a good idea to rearrange this sentence:

 As root, open the relevant APT source-list file (such as
 /etc/apt/sources.list) with your favorite
 editor, and check all lines beginning with

>  deb http:, deb https:,
> -deb tor+http:, deb tor+https: or
> -deb ftp: for a reference to
> +deb tor+http:, deb tor+https:,
> +URIs: http:,
> +URIs: https:,
> +URIs: tor+http: or URIs: tor+https:
> +for a reference to
>  stable.  If you find any, change
>  stable to .
>  
> -
> -  
> -Lines in sources.list starting with deb ftp: and pointing 
> to debian.org
> -addresses should be changed into deb http: lines.
> -  
> -
>  
> -If you have any lines starting with deb file:, you will 
> have
> +  If you have any lines starting with deb file: or
> +  URIs: file:, you will have
>  to check for yourself if the location they refer to contains an
>   or a  archive.
>  

I've just noticed: "contains AN "?  There has only
been one releasename beginning with a 

Bug#925354: [Debian-ha-maintainers]: Bug#925354: pacemaker-dev: missing Breaks+Replaces: libcrmcluster1-dev

[wferi]

Valentin Vidic  writes:

> On Mon, Mar 25, 2019 at 03:45:58PM +0100, Andreas Beckmann wrote:
>
>> In that case you should probably add Breaks+Replaces against all of the
>> old -dev packages that were merged, just to be on the safe side.
>
> Yes, that is the plan. I think wferi will take care of it if he
> has time?

Yes, I'm on it.  It's somewhat bizarre: libcrmcluster1-dev wasn't part
of jessie or stretch.  Similarly, pacemaker-dev was present in wheezy
only, until I reintroduced it recently, and looks like its ghost came
back to haunt us.  I didn't anticipate piuparts to start with wheezy
when testing buster upgrades.
-- 
Thanks,
Feri

Bug#925576: unblock: python-trustme/0.4.0-2

[Robie Basak]

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

Please unblock package python-trustme

This fixes an FTBFS. The package previously built fine, pulling in
python3-idna implicitly via python3-cryptography via python3-openssl.
Since then, python3-cryptography stopped depending on python3-idna,
exposing the bug that python-trustme's build does actually depend on
python3-idna but this wasn't explicitly declared. This change declares
explicitly what was being pulled in previously, so shouldn't in itself
cause any functional change; only the FTBFS will be fixed (along with
the usual regression risk associated with a rebuild).

diff -Nru python-trustme-0.4.0/debian/changelog 
python-trustme-0.4.0/debian/changelog
--- python-trustme-0.4.0/debian/changelog   2018-10-13 22:48:59.0 
+0100
+++ python-trustme-0.4.0/debian/changelog   2019-03-26 23:23:50.0 
+
@@ -1,3 +1,10 @@
+python-trustme (0.4.0-2) unstable; urgency=medium
+
+  * Explicitly build-depend on python3-idna to fix FTBFS.
+Closes: #925566.
+
+ -- Robie Basak   Tue, 26 Mar 2019 23:22:42 +
+
 python-trustme (0.4.0-1) unstable; urgency=low
 
   * Initial release. Closes: #910951.
diff -Nru python-trustme-0.4.0/debian/control 
python-trustme-0.4.0/debian/control
--- python-trustme-0.4.0/debian/control 2018-10-13 22:48:59.0 +0100
+++ python-trustme-0.4.0/debian/control 2019-03-26 23:21:57.0 +
@@ -6,6 +6,7 @@
 Build-Depends: debhelper (>= 9~),
dh-python,
python3,
+   python3-idna,
python3-openssl,
python3-pytest,
python3-service-identity,

unblock python-trustme/0.4.0-2


signature.asc
Description: PGP signature

Bug#925533: libspring-java: stopped building libspring-jms-java and libspring-messaging-java

[tony mancill]

On Tue, Mar 26, 2019 at 02:46:35PM +0100, Mattia Rizzolo wrote:
> Source: libspring-java
> Version: 4.3.22-2
> Severity: serious
> X-Debbugs-Cc: tony mancill 
> Control: block 925390 924635 924634 by -1
> 
> Dear maintainer (and tony, whose upload 4.3.22-2 caused this bug),
> 
> your package libspring-java suddenly stopped building two binaries that
> were actively used by other packages, like activemq.
> 
> What's very worse, the changelog doesn't mention any reason for doing
> so.

Hi Mattia,

Are you sure about the upload of 4.3.22-2 changing the number of binary
packages built?  If that is the case, it was completely unintentional.
I compared the package I uploaded to a clean chroot build of the
previous version *before* I uploaded it on March 3rd:

/data/debian/sponsor/libspring-java/build-area$ ls -al *deb | grep 4.3.22-2 | 
wc -l
17
/data/debian/sponsor/libspring-java/build-area$ ls -al *deb | grep 4.3.22-1 | 
wc -l
17

The full debdiff for that upload is attached.

Regarding the OpenHFT, I tried to help the overall situation by
uploading new versions to experimental several months back but as was
discussed on the list (I'd have to find the link), was requested to
hold-off on transitioning them into unstable.

Thanks,
tony
diff --git a/debian/changelog b/debian/changelog
index a416f6ad..8a133409 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+libspring-java (4.3.22-2) unstable; urgency=medium
+
+  * Team upload.
+  * Update dependency on aspectj to be versioned (>= 1.9.2)
+Thank you to Matthias Klose for the bug report.  (Closes: #923554)
+  * Update Homepage URL in debian/control to use https
+  * Update Source URL in debian/copyright
+  * Freshen debian/copyright year for upstream
+  * Add a patch to use SOURCE_DATE_EPOCH to compute the copyright year
+that appears in JAR files META-INF.  This should help with build
+reproducibility.
+
+ -- tony mancill   Sun, 03 Mar 2019 20:35:23 -0800
+
 libspring-java (4.3.22-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 838cb945..736eaa53 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Build-Depends-Indep: bsh,
  libactivation-java,
  libapache-poi-java (>= 4.0),
  libasm-java (>= 5.0),
- libaspectj-java,
+ libaspectj-java (>= 1.9.2),
  libatinject-jsr330-api-java,
  libc3p0-java,
  libcastor-xml-java,
@@ -95,7 +95,7 @@ Build-Depends-Indep: bsh,
 Standards-Version: 4.3.0
 Vcs-Git: https://salsa.debian.org/java-team/libspring-java.git
 Vcs-Browser: https://salsa.debian.org/java-team/libspring-java
-Homepage: http://spring.io/projects/spring-framework
+Homepage: https://spring.io/projects/spring-framework
 
 Package: libspring-core-java
 Architecture: all
@@ -104,7 +104,7 @@ Depends: libactivation-java,
  libcommons-logging-java,
  libjaxb-api-java,
  ${misc:Depends}
-Suggests: libaspectj-java,
+Suggests: libaspectj-java (>= 1.9.2),
   libcommons-collections3-java,
   liblog4j1.2-java
 Description: modular Java/J2EE application framework - Core
diff --git a/debian/copyright b/debian/copyright
index 6b067e29..002ad044 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,14 +1,14 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: Spring Framework
 Upstream-Contact: SpringSource Inc.
-Source: http://springframework.org/download
+Source: https://github.com/spring-projects/spring-framework/tags
 Files-Excluded: *.jar
 .settings
 gradlew*
 gradle/wrapper/*
 
 Files: *
-Copyright: 2002-2011, the original author or authors
+Copyright: 2002-2019, the original author or authors
2004, 2005 Acegi Technology Pty Limited
2009 SpringSource Inc.
 License: Apache-2.0
diff --git a/debian/patches/0051-reproducible-build-source-date.patch 
b/debian/patches/0051-reproducible-build-source-date.patch
new file mode 100644
index ..22c413d2
--- /dev/null
+++ b/debian/patches/0051-reproducible-build-source-date.patch
@@ -0,0 +1,15 @@
+Description: use a reproducible copyright date in the JAR metadata
+Author: tony mancill 
+Forwarded: not-needed
+
+--- a/build.gradle
 b/build.gradle
+@@ -234,7 +234,7 @@
+   include "license.txt"
+   include "notice.txt"
+   into "META-INF"
+-  expand(copyright: new Date().format(""), version: 
project.version)
++  expand(copyright: new 
Date(Long.valueOf(System.getenv("SOURCE_DATE_EPOCH")) * 1000).format(""), 
version: project.version)
+   }
+   }
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 4bd9f9f5..ec84d3b3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ 

Bug#925575: tclxml: please make the build reproducible

[Chris Lamb]

Source: tclxml
Version: 1:3.2.7-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that tclxml could not be built reproducibly.

This is because it installs a tclxmlConfig.sh file that includes
the absolute build path.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-03-26 19:23:59.010597720 -0400
--- b/debian/rules  2019-03-26 19:25:54.263410098 -0400
@@ -15,3 +15,6 @@
 override_dh_shlibdeps:
dh_shlibdeps
tcltk-depends
+
+override_dh_install:
+   dh_install -X/tclxmlConfig.sh

Bug#925574: Filename corrected

[Américo Monteiro]

Well, i have forgotten to change the file name, and to avoid the old mistake
here it is the translation with the corrected "language" in the filename

sorry


gkdebconf_2.0.4_pt.po.gz
Description: application/gzip

Bug#925498: afterstep: v2.2.12-12 FTBFS due to patch#57 generates libAfterImage/Makefile incorrectly.

[Robert Luberda]

Jim Turner pisze:

Hi,

> truetype fonts, and instead use pkg-config.  Problem is that the patch
> properly removes it from configure.in, but NOT from configure itself

The configure script is regenerated during the build process, so there
is no need to change it via a patch.

> I simply untacked the latest source package v2.2.12-12 from Debian Testing
> (http://ftp.gr.debian.org/debian/) on March 25, 2019, ran:
> 
> ./configure
> make


This is not a proper way to build Debian packages. Use 'quilt push -a &&
debian/rules binary' or tools like dpkg-buildpackage or debuild instead.


Regards,
robert

Bug#925566: python-trustme: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Robie Basak]

On Tue, Mar 26, 2019 at 09:49:00PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in buster (in a buster chroot, not a
> sid chroot), your package failed to build on amd64.

Thank you for this report.

It looks like python-trustme (build time) tests uses the idna directly,
so an explicit Build-Depends on python3-idna would be correct.

Previously the build worked because python3-openssl happened to depend
on python3-cryptography which happened to depend on python3-idna.
However python3-cryptography no longer depends on python3-idna,
triggering this latent bug.


signature.asc
Description: PGP signature

Bug#925573: gcc-9-cross-ports: incomplete copyright

[Matthias Klose]

On 27.03.19 00:03, Sean Whitton wrote:
> Source: gcc-9-cross-ports
> Severity: important
> 
> Hello,
> 
> The copyright information should be updated to include recent copyright
> years and holders.  It looks to be out-of-date, listing only Linaro, a
> long time ago.

this is for the packaging; sure, I can add myself as a copyright holder, but the
binary packages take their copyright from the gcc-9-source package.

Bug#925574: gkdebconf: [INTL:pt] Updated Portuguese translation - prog messages

[Américo Monteiro]

Package: gkdebconf
Version: 2.0.4
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for  gkdebconf's messages
Translator: Américo Monteiro 
Feel free to use it.

Please place this file in the "pt" directory and not in pt_PT this time 

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


gkdebconf_2.0.4_pt_PT.po.gz
Description: application/gzip

Bug#478704: texlive-xetex: 478704: fontconfig instead

[Norbert Preining]

Hi Hilmar,

On Tue, 26 Mar 2019, Hilmar Preuße wrote:
> > - drop a conf file into /etc/fonts/conf.avail plus the link
> > - file a bug against fontconfig to have interest (trigger) on 
> >   /usr/share/texmf-texlive/fonts, too.
> > 
> > The reason, there is already
> > /usr/share/texmf/fonts
> > in the triggers of fontconfig ...
> > 
> > That sounds like a nice idea, and easy to implement.
> > 
> Ping!
> 
> I guess that was never implemented, right?

Which one? The second one is not up to us, but the fontconfig
maintainers.

Still, I don't think it is a good idea ... I am pretty sure that some
fonts will break fontconfig and font selection ...

The first version would only allow the admin to activate the fonts on
his own responability, ...

Norbert

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

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Thanks, yes, that did the trick.

I’ve installed it on one of my test computers.  It seems to work fine.  I’ve 
tried a couple of things that should trigger the bug, if it’s still there.

In particular, rebooting the computer then examining the journal shows that it 
does get to poll all of the configured pools.

Another experiment I have tried is this:
Boot the computer and let everything settle.
un-plug the ethernet (RJ45)
restart ntpsec and watch the journal for evidence of attempts to 
contact the configured pools (which will fail, since the   ethernet is 
disconnected)
re-plug the ethernet and continue to watch the journal for attempts to 
contact the pools (which succeed this time).

In this experiment, I saw no evidence of the bug — i.e. no evidence of having 
forgotten all but one of the configured pools.

Thanks for all your help!
Rick


> On Mar 25, 2019, at 4:30 PM, Richard Laager  wrote:
> 
>> sudo apt update
>> sudo apt install build-essential devscripts
>> sudo apt build-dep ntpsec
>> apt source ntpsec
>> cd ntpsec-1.1.3+dfsg1
>> patch -p1 < ~/ntpsec_1.1.3+dfsg1-3~1.gbpdde9c0.debdiff
> 
> I missed a step here, as `apt source` applies the existing patches, so
> we apparently need to apply this patch too:
> 
> patch -p1 < debian/patches/0001-Fix-for-577-DNS-retry-sloth.patch
> 
>> debuild -uc -us
> If you can try this and confirm this patch as packaged fixes your
> problem, that would help me move forward with this.
> 
> -- 
> Richard

Bug#925573: gcc-9-cross-ports: incomplete copyright

[Sean Whitton]

Source: gcc-9-cross-ports
Severity: important

Hello,

The copyright information should be updated to include recent copyright
years and holders.  It looks to be out-of-date, listing only Linaro, a
long time ago.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#925562: Acknowledgement (libreadline7: readline exits on ctrl-c even when SIGINT is caught)

[d wk]

I think this is actually expected behavior. Sorry for the bug report.
I'll just use siglongjmp.
https://stackoverflow.com/questions/16828378/readline-get-a-new-prompt-on-sigint

On Tue, Mar 26, 2019 at 6:09 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 925562: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925562.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   dwk...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Matthias Klose 
>
> If you wish to submit further information on this problem, please
> send it to 925...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 925562: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925562
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#925572: ITP: dnlib -- .NET module/assembly reader/writer library

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist
Control: block 925570 by -1

* Package name: dnlib
  Version : 2.1
  Upstream Author : de4...@gmail.com
* URL or Web page : https://github.com/0xd4d/dnlib
* License : MIT
  Description : .NET module/assembly reader/writer library

dnlib is a dependency for de4dot and will be maintained within the
Debian Security Tools Team.

Bug#478704: texlive-xetex: 478704: fontconfig instead

[Hilmar Preuße]

On 05.12.09 16:25, Norbert Preining wrote:
> On Sa, 05 Dez 2009, Paul Wise wrote:

>> Perhaps adding /usr/share/texmf-texlive/fonts to the fontconfig
>> configuration and triggers is the way to go? It would suck to have to
> 
> Hmm, looking into the fontconfig package I find a different solution
> even better:
> 
> - drop a conf file into /etc/fonts/conf.avail plus the link
> - file a bug against fontconfig to have interest (trigger) on 
>   /usr/share/texmf-texlive/fonts, too.
> 
> The reason, there is already
>   /usr/share/texmf/fonts
> in the triggers of fontconfig ...
> 
> That sounds like a nice idea, and easy to implement.
> 
Ping!

I guess that was never implemented, right?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#925380: [Pkg-utopia-maintainers] Bug#925380: network-manager-gnome: ifupdown no longer appears in the applet and no longer does not detects hotplug event

[Michael Biebl]

Control: tags -1 moreinfo

Am 24.03.19 um 01:52 schrieb Jack Underwood:
> Package: network-manager-gnome
> Version: 1.8.20-1
> Severity: important
> 
> Dear Maintainer,
> 
> Sometime in (late) 2018 the NetworkManager stopped showing ifupdown (eth0) in 
> the interfaces, iirc
> eth0 would only sometimes appear as a seperate entry to ifupdown (eth0) in 
> the Ethernet Network
> section of the applet.  Now when I unplug the ethernet cable eth0 disappears 
> with only a greyed out
> "disconnected" appearing in the Ethernet Network section of the applet, and 
> when I plug the cable
> back in nothing happens to the applet, and clicking on "Connection 
> Information" says "Error displaying
> connection information:" "No valid active connections found!" despite the 
> connection clearly working again.

Can you attach the contents of /run/network/ifstate when you change your
network connection with ifup/ifdown.

A verbose debug log of NetworkManager would be helpful as well.
https://wiki.gnome.org/Projects/NetworkManager/Debugging

-- 
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#925410: Translations of redirect page

[Andreas Ronnquist]

On Sun, 24 Mar 2019 16:01:27 +0100,
gus...@debian.org wrote:
>Unfortunately this seems like it isn't enough - I have translated the
>string for Swedish, but still the message is presented in English. (See
>the link above to see for yourself).
>
>Converted to a bug-report, to easier track.
>
>As said, I don't see this as a pressing matter, and I fully understand
>if it is lower on priority-lists.
>
>thanks for all your work!

I have made a Merge request for a fix for this in Salsa:

https://salsa.debian.org/webmaster-team/webwml/merge_requests/90

I would appreciate tests of the fix before I (or you) apply it to the
webwml repo. (It doesn't include any translations or updated
pot/po-files, this will be needed to test).

regards
-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net

Bug#925411: Kernel-package: Not suitable for release

[Durand]

Package: kernel-package
Version: 13.018+nmu1

Just wanted to let you know I'm a user of kernel-package and it works 
fine on my amd64 debian testing machine. Just finished compiling 
linux-5.0.4-amd64 kernel for my specific use case. I'm not seeing any 
major bugs like what I see on my x86 machine which seems to reset the 
.config file after running make-kpkg clean. To work around that bug, I 
just copy the .config to outside of the kernel tree, run make-kpkg 
clean, then copy the .config back to compile. Annoying, but not a 
deal-breaker.


--
---
Regards,

Durand Hicks

Bug#925571: node-opencv: CVE-2019-10061

[Salvatore Bonaccorso]

Source: node-opencv
Version: 6.0.0+git20180416.cfc96ba0-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for node-opencv.

CVE-2019-10061[0]:
| utils/find-opencv.js in node-opencv (aka OpenCV bindings for Node.js)
| prior to 6.1.0 is vulnerable to Command Injection. It does not
| validate user input allowing attackers to execute arbitrary commands.


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-10061
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10061
[1] https://www.npmjs.com/advisories/789

Regards,
Salvatore

Bug#244506: info: menu lacks icon

[Hilmar Preuße]

On 18.04.04 20:17, Fabian Franz wrote:

Hi,

Can we use this address for communication or should we use a different one?

> please add a icon to your package.
> 
> You can take one from KDE or Gnome iconsets called "khelpcenter".
> Even if I would prefer a icon like a questionmark: ?
> 
This bug is still open. Is the requirement still valid, given the fact
that menu is deprecated?
Maybe we'll migrate to the Gnome menu system: do you eventually know a
package containing an icon, which fulfills your request?

Thanks!
  Hilmar



signature.asc
Description: OpenPGP digital signature

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

[Aurelien Jarno]

On 2019-03-22 17:30, Florian Weimer wrote:
> > About the archive rebuild: The rebuild was done on EC2 VM instances from
> > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> > failed build was retried once to eliminate random failures.
> 
> I believe the actual test failure is tst-pkey.
> 
> Presumably, this rebuild was performed on some Xeon SP CPU.  Do you
> know which model?  Do you have any information about the kernel and
> hypervisor used?
> 
> 32-bit protection key support has had issues from time to time.

Do you have some more details about the issue? Is it a glibc or a kernel
problem?

If we can't fix the issue easily on the libc side, I guess the way to
fix that is to XFAIL that test on 32-bit x86. 

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

Bug#922097: inkscape stops with message complaining about an internal illegal instruction on start

[Bernhard Übelacker]

Hello Mattia,

Am 26.03.19 um 15:32 schrieb Mattia Rizzolo:
> On Tue, Mar 26, 2019 at 01:40:47AM +0100, Bernhard Übelacker wrote:
>> Therefore gdb may not show the line information I guess.
>>
>> Maybe you can please send the output of the disassemble
>> and x command from gdb having loaded the core dump?
> 
> retrying this core dump is already getting bothersome since the archive
> moved on and I already need to download stuff from snapshot .. :(
>
> Can I pass the core dump to you?  (the OP sent it to me privately, I
> assume it's best to not post it publicly, even if I didn't spot anything
> private in it).

I would have expected both commands work without having the actual
binary installed and the information taken from the core.
But as this seems not the case it would just show me the
instructions from the files I or you have installed ...

So I should ask the submitter for a current example and/or
running an automated gdb session.

Kind regards,
Bernhard

Bug#925568: cnvkit: FTBFS: FileExistsError: [Errno 17] File exists: 'build/'

[Lucas Nussbaum]

Source: cnvkit
Version: 0.9.5-2
Severity: serious
Tags: buster sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20190325 qa-ftbfs
Justification: FTBFS in buster on amd64

Hi,

During a rebuild of all packages in buster (in a buster chroot, not a
sid chroot), your package failed to build on amd64.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/test'
> python3 ../cnvkit.py import-picard picard/p2-5_5.targetcoverage.csv 
> picard/p2-5_5.antitargetcoverage.csv picard/p2-9_5.targetcoverage.csv 
> picard/p2-9_5.antitargetcoverage.csv picard/p2-20_5.targetcoverage.csv 
> picard/p2-20_5.antitargetcoverage.csv -d build/
> python3 ../cnvkit.py import-picard picard/p2-5_5.targetcoverage.csv -d build/
> python3 ../cnvkit.py import-picard picard/p2-5_5.antitargetcoverage.csv -d 
> build/
> python3 ../cnvkit.py import-picard picard/p2-9_2.targetcoverage.csv -d build/
> WARNING: Ambiguous gene name 'TERT|TERT Promoter'; using 'TERT Promoter'
> WARNING: Ambiguous gene name 'TERT|TERT Promoter'; using 'TERT Promoter'
> WARNING: Ambiguous gene name 'TERT|TERT Promoter'; using 'TERT Promoter'
> Created directory build/
> Traceback (most recent call last):
>   File "../cnvkit.py", line 13, in 
> args.func(args)
>   File "/<>/cnvlib/commands.py", line 1368, in _cmd_import_picard
> os.mkdir(args.output_dir)
> FileExistsError: [Errno 17] File exists: 'build/'
> Wrote build/p2-5_5.targetcoverage.cnn with 6646 regions
> Wrote build/p2-9_2.targetcoverage.cnn with 6646 regions
> make[2]: *** [Makefile:58: build/p2-5_5.targetcoverage.cnn] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2019/03/25/cnvkit_0.9.5-2_testing.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#925570: ITP: de4dot -- .NET deobfuscator and unpacker

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: de4dot
  Version : Git snapshot
  Upstream Author : de4...@gmail.com
* URL or Web page : https://github.com/0xd4d/de4dot
* License : GPL-3+
  Description : .NET deobfuscator and unpacker

This package will be maintained within the Debian Security Tools Team.

The current Git "master" seems to require Microsoft C# compiler; I'll
initially pacakge a version of which I know that it can be built using
Mono.

Bug#925569: stretch-pu: package flatpak/0.8.9-0+deb9u3

[Simon McVittie]

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

I've prepared a flatpak update for stable to fix CVE-2019-10063 in
the next point release. The security team told me they don't intend to
release a DSA for this.

May I upload?

I've uploaded 1.2.3-2 to unstable to fix the same thing, although I'm
hoping to replace it with a new upstream release.

Thanks,
smcv
diffstat for flatpak-0.8.9 flatpak-0.8.9

 changelog   |   11 +++
 patches/run-Only-compare-the-lowest-32-ioctl-arg-bits-for-TIOCSTI.patch |   32 ++
 patches/series  |1 
 3 files changed, 43 insertions(+), 1 deletion(-)

diff -Nru flatpak-0.8.9/debian/changelog flatpak-0.8.9/debian/changelog
--- flatpak-0.8.9/debian/changelog	2019-02-11 21:13:02.0 +
+++ flatpak-0.8.9/debian/changelog	2019-03-26 21:11:16.0 +
@@ -1,10 +1,19 @@
+flatpak (0.8.9-0+deb9u3) stretch; urgency=medium
+
+  * d/p/run-Only-compare-the-lowest-32-ioctl-arg-bits-for-TIOCSTI.patch:
+Reject all ioctls that the kernel will interpret as TIOCSTI,
+including those where the high 32 bits in a 64-bit word are nonzero.
+(Closes: #925541, CVE-2019-10063)
+
+ -- Simon McVittie   Tue, 26 Mar 2019 21:11:16 +
+
 flatpak (0.8.9-0+deb9u2) stretch-security; urgency=medium
 
   * d/p/Don-t-expose-proc-when-running-apply_extra.patch:
 Backport patch from upstream v1.2.3: do not let the apply_extra
 script for a system installation modify the host-side executable
 via /proc/self/exe, similar to CVE-2019-5736 in runc
-(Closes: #922059)
+(Closes: #922059; CVE-2019-8308)
 
  -- Simon McVittie   Mon, 11 Feb 2019 21:13:02 +
 
diff -Nru flatpak-0.8.9/debian/patches/run-Only-compare-the-lowest-32-ioctl-arg-bits-for-TIOCSTI.patch flatpak-0.8.9/debian/patches/run-Only-compare-the-lowest-32-ioctl-arg-bits-for-TIOCSTI.patch
--- flatpak-0.8.9/debian/patches/run-Only-compare-the-lowest-32-ioctl-arg-bits-for-TIOCSTI.patch	1970-01-01 01:00:00.0 +0100
+++ flatpak-0.8.9/debian/patches/run-Only-compare-the-lowest-32-ioctl-arg-bits-for-TIOCSTI.patch	2019-03-26 21:11:16.0 +
@@ -0,0 +1,32 @@
+From: Ryan Gonzalez 
+Date: Mon, 25 Mar 2019 13:00:15 -0500
+Subject: run: Only compare the lowest 32 ioctl arg bits for TIOCSTI
+
+Closes #2782.
+
+Closes: #2783
+Approved by: alexlarsson
+
+(cherry picked from commit a9107feeb4b8275b78965b36bf21b92d5724699e)
+
+Origin: upstream, 1.2.4, commit:8e0aaf4b70d6d7c02c331c655e1a05763485085e
+Bug: https://github.com/flatpak/flatpak/issues/2782
+Bug-Debian: https://bugs.debian.org/925541
+Bug-CVE: CVE-2019-10063
+---
+ common/flatpak-run.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/common/flatpak-run.c b/common/flatpak-run.c
+index 9a69f7b..b3ed2ea 100644
+--- a/common/flatpak-run.c
 b/common/flatpak-run.c
+@@ -3866,7 +3866,7 @@ setup_seccomp (GPtrArray  *argv_array,
+ {SCMP_SYS (clone), _A0 (SCMP_CMP_MASKED_EQ, CLONE_NEWUSER, CLONE_NEWUSER)},
+ 
+ /* Don't allow faking input to the controlling tty (CVE-2017-5226) */
+-{SCMP_SYS (ioctl), _A1(SCMP_CMP_EQ, (int)TIOCSTI)},
++{SCMP_SYS (ioctl), _A1 (SCMP_CMP_MASKED_EQ, 0xu, (int) TIOCSTI)},
+   };
+ 
+   struct
diff -Nru flatpak-0.8.9/debian/patches/series flatpak-0.8.9/debian/patches/series
--- flatpak-0.8.9/debian/patches/series	2019-02-11 21:13:02.0 +
+++ flatpak-0.8.9/debian/patches/series	2019-03-26 21:11:16.0 +
@@ -1 +1,2 @@
 Don-t-expose-proc-when-running-apply_extra.patch
+run-Only-compare-the-lowest-32-ioctl-arg-bits-for-TIOCSTI.patch

Bug#925566: python-trustme: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Lucas Nussbaum]

Source: python-trustme
Version: 0.4.0-1
Severity: serious
Tags: buster sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20190325 qa-ftbfs
Justification: FTBFS in buster on amd64

Hi,

During a rebuild of all packages in buster (in a buster chroot, not a
sid chroot), your package failed to build on amd64.

Relevant part (hopefully):
>  debian/rules build
> dh build --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:217: python3.7 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.7/build/trustme
> copying trustme/__init__.py -> 
> /<>/.pybuild/cpython3_3.7/build/trustme
> copying trustme/_version.py -> 
> /<>/.pybuild/cpython3_3.7/build/trustme
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:217: cd /<>/.pybuild/cpython3_3.7/build; 
> python3.7 -m pytest tests
> = test session starts 
> ==
> platform linux -- Python 3.7.3rc1, pytest-3.10.1, py-1.7.0, pluggy-0.8.0
> rootdir: /<>, inifile:
> collected 0 items / 1 errors
> 
>  ERRORS 
> 
> __ ERROR collecting .pybuild/cpython3_3.7/build/tests/test_trustme.py 
> __
> ImportError while importing test module 
> '/<>/.pybuild/cpython3_3.7/build/tests/test_trustme.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> tests/test_trustme.py:20: in 
> import trustme
> trustme/__init__.py:11: in 
> import idna
> E   ModuleNotFoundError: No module named 'idna'
> !!! Interrupted: 1 errors during collection 
> 
> === 1 error in 0.14 seconds 
> 
> E: pybuild pybuild:341: test: plugin distutils failed with: exit code=2: cd 
> /<>/.pybuild/cpython3_3.7/build; python3.7 -m pytest tests
> dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned 
> exit code 13

The full build log is available from:
   http://qa-logs.debian.net/2019/03/25/python-trustme_0.4.0-1_testing.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

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

[Lucas Nussbaum]

Source: gcc-8-cross
Version: 26
Severity: serious
Tags: buster sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20190325 qa-ftbfs
Justification: FTBFS in buster on amd64

Hi,

During a rebuild of all packages in buster (in a buster chroot, not a
sid chroot), your package failed to build on amd64.

Relevant part (hopefully):
> /usr/bin/ld: /tmp/cc7hDO1R.o: in function `main':
> /<>/gcc/build/libbacktrace/conftest.c:72: undefined reference to 
> `getexecname'
> collect2: error: ld returned 1 exit status

The full build log is available from:
   http://qa-logs.debian.net/2019/03/25/gcc-8-cross_26_testing.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#925565: ruby-voight-kampff: FTBFS: ERROR: Test "ruby2.5" failed: RuntimeError

[Lucas Nussbaum]

Source: ruby-voight-kampff
Version: 1.1.3-2
Severity: serious
Tags: buster sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20190325 qa-ftbfs
Justification: FTBFS in buster on amd64

Hi,

During a rebuild of all packages in buster (in a buster chroot, not a
sid chroot), your package failed to build on amd64.

Relevant part (hopefully):
> RuntimeError:
>   Application has been already initialized.
> # 
> /usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/application.rb:360:in
>  `initialize!'
> # 
> /usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/railtie.rb:190:in
>  `public_send'
> # 
> /usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/railtie.rb:190:in
>  `method_missing'
> # 
> /usr/share/rubygems-integration/all/gems/combustion-1.0.0/lib/combustion.rb:32:in
>  `initialize!'
> # ./spec/spec_helper.rb:5:in `'
> # 
> /usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in
>  `require'
> # 
> /usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in
>  `block in require'
> # 
> /usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:257:in
>  `load_dependency'
> # 
> /usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in
>  `require'
> # ./spec/lib/voight_kampff_spec.rb:1:in `'
> # 
> /usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:285:in
>  `load'
> # 
> /usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:285:in
>  `block in load'
> # 
> /usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:257:in
>  `load_dependency'
> # 
> /usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:285:in
>  `load'
> No examples found.
> 
> 
> Finished in 0.00018 seconds (files took 1.01 seconds to load)
> 0 examples, 0 failures, 4 errors occurred outside of examples
> 
> rake aborted!
> Command failed with status (1): [rspec...]
> /<>/debian/ruby-tests.rake:4:in `block in '
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby2.5" failed: 

The full build log is available from:
   http://qa-logs.debian.net/2019/03/25/ruby-voight-kampff_1.1.3-2_testing.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages

[Paul Gevers]

Control: tags -1 moreinfo

On Sun, 10 Jun 2018 02:15:51 +0100 Ben Hutchings 
wrote:
> > Perhaps a better location would be the upgrading chapter of the release
> > notes? [1]
> > 
> > That includes various things that one can do to clean up your system
> > after the upgrade; removing transitional packages would seem like a good
> > thing to do at that point.
> > 
> > [1]  
> > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#for-next
> 
> That would also be a good place.

I wonder what is missing there from the perspective of this bug. The
section about dummy packages exists since before 2009 and currently reads:
'''
Dummy packages

  Some packages from  have been split into several
packages in , often to improve system maintainability.  To
ease the upgrade path in such cases,  often provides
dummy packages: empty packages that have the same name as
the old package in  with dependencies that cause the new
packages to be installed.  These dummy packages are
considered redundant after the upgrade and can be safely removed.


  Most (but not all) dummy packages' descriptions indicate their
purpose. Package descriptions for dummy packages are not uniform,
however, so you might also find deborphan with the
--guess-* options (e.g.
--guess-dummy) useful to detect them in your system.
 Note that some dummy packages are not intended to be removed after an
upgrade but are, instead, used to keep track of the current available
version of a program over time.

  
'''

Suggestions on how to improve that text are welcome.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#244506: info: menu lacks icon

[Hilmar Preuße]

On 18.04.04 20:17, Fabian Franz wrote:

Hi,

> please add a icon to your package.
> 
> You can take one from KDE or Gnome iconsets called "khelpcenter".
> Even if I would prefer a icon like a questionmark: ?
> 
This bug is still open. Is the requirement still valid, given the fact
that menu is deprecated?
Maybe we'll migrate to the Gnome menu system: do you eventually know a
package containing an icon, which fulfills your request?

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



signature.asc
Description: OpenPGP digital signature

Bug#916042: Leafpad no longer on the archive

[Santiago Garcia Mantinan]

Hi!

Per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913765 leafpad has
been removed, it is no longer taking part on Buster.

I think it is time for lxde on Debian to remove the leafpad dependency.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#925563: dxvk installation script doesn't install 32 bit libraries to 64 bit prefix

[Anton Vorobyov]

Package: dxvk
Version: 0.96+ds1-1


Repro:

  1. Initialize wineprefix WINEPREFIX=~/.wine_exp wine-development winecfg
  2. Attempt to install dxvk into it: WINEPREFIX=~/.wine_exp dxvk-setup install 
-d

Oberved result:

Installation of 32-bit libraries is not launched.

installing dxvk-wine64-development in the wine prefix...
    [1/2] Creating override for dxgi
    The operation completed successfully
    [2/2] Creating link link to dxgi
    [1/2] Creating override for d3d10
    The operation completed successfully
    [2/2] Creating link link to d3d10
    [1/2] Creating override for d3d10_1
    The operation completed successfully
    [2/2] Creating link link to d3d10_1
    [1/2] Creating override for d3d10core
    The operation completed successfully
    [2/2] Creating link link to d3d10core
    [1/2] Creating override for d3d11
    The operation completed successfully
    [2/2] Creating link link to d3d11
wine: WINEARCH set to win32 but '/home/dfx/.wine_exp' is a 64-bit installation.

Due to this, 32-bit applications fail to run (i.e. EVE online launcher). 
Installer skips 32-bit libs due to prefix check failing:

dfx@kreo:~$ WINEPREFIX=~/.wine_exp WINEARCH=win32 wine-development wineboot
wine: WINEARCH set to win32 but '/home/dfx/.wine_exp' is a 64-bit installation.
dfx@kreo:~$ echo $?
1

Removing this check fixes the issue.

Expected result: 32-bit libraries are installed.

Additional data:

$ uname -a
Linux kreo 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux

wine-development 4.2-2

Bug#925562: libreadline7: readline exits on ctrl-c even when SIGINT is caught

[DWK]

Package: libreadline7
Version: 7.0-5
Severity: normal

Dear Maintainer,

I'm writing a readline program which handles CTRL-C (SIGINT). I call
rl_set_signals() and verify with strace that readline installs a
signal handler for SIGINT. But, pressing CTRL-C still terminates my
program. Here is a reproducible example:

  #include 
  #include 
  
  #include 
  
  int main(int argc, char** argv) {
printf("pressing ctrl-c should not exit this program.\n");
  
rl_catch_signals = 1;
rl_set_signals();
  
rl_bind_key('\t', rl_insert);
  
char *buf;
while((buf = readline(">> ")) != NULL) {
  printf("[%s]\n", buf);
  free(buf);
}
return 0;
  }

I modified readline 8.0 source as follows. I managed to make CTRL-C
do nothing, but the expected behaviour (readline aborts the current
line and starts a new one) still doesn't occur.

*** orig/readline-8.0/signals.c 2018-03-28 16:23:45.0 -0400
--- new/readline-8.0/signals.c  2019-03-26 17:50:45.201930497 -0400
***
*** 215,224 
--- 215,225 
_rl_reset_completion_state ();
rl_free_line_state ();
  #if defined (READLINE_CALLBACKS)
rl_callback_sigcleanup ();
  #endif
+   break;
  
/* FALLTHROUGH */
  
  #if defined (SIGTSTP)
  case SIGTSTP:


It's possible that this is expected behaviour, but I assume that pressing
CTRL-C should not terminate a readline program. This assumption is backed
up by existing materials on readline, e.g.
https://lists.gnu.org/archive/html/bug-readline/2016-04/msg00071.html

I suspect this may be a regression since the behaviour was different in
the past. Tested on readline 7 and 8 to similar effect. P.S. Programs like
bash or gdb still trap CTRL-C properly.

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

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

Versions of packages libreadline7 depends on:
ii  libc62.28-2
ii  libtinfo66.1+20181013-2
ii  readline-common  7.0-3

libreadline7 recommends no packages.

libreadline7 suggests no packages.

-- no debconf information

Bug#923750: gdcm: FTBFS in buster/sid

[Santiago Vila]

On Tue, Mar 26, 2019 at 07:29:12PM +0100, Gert Wollny wrote:

> the problem is I at least don't know the offending package because I
> was not able to reproduce the build failure. Whatever it was, it has
> probably already benn fixed. 

My build history for buster:

Status: successful  gdcm_2.8.8-5_amd64-20181230T191455.669Z
Status: successful  gdcm_2.8.8-5_amd64-20190114T071348.822Z
Status: successful  gdcm_2.8.8-6_amd64-20190124T082314.888Z
Status: failed  gdcm_2.8.8-6_amd64-20190205T224359.890Z
Status: failed  gdcm_2.8.8-6_amd64-20190219T002627.991Z
Status: failed  gdcm_2.8.8-6_amd64-20190302T232244.473Z
Status: failed  gdcm_2.8.8-6_amd64-20190304T231307.933Z
Status: successful  gdcm_2.8.8-6_amd64-20190321T073112.209Z

This means the buggy build-depends (some texlive package, I suppose)
entered testing somewhere between 20190124 and 20190205 and the fixed
package entered testing somewhere between 20190304 and 20190321.

If this information is not enough to determine which one it was,
feel free to close the bug.

Thanks.

Bug#925541: CVE-2019-10063: incomplete TIOCSTI filtering, similar to snapd's CVE-2019-7303

[Simon McVittie]

On Tue, 26 Mar 2019 at 21:35:31 +0100, Salvatore Bonaccorso wrote:
> On Tue, Mar 26, 2019 at 03:28:03PM +, Simon McVittie wrote:
> > Security team: I assume you probably won't want to do a DSA for this?
> 
> Ack. Can you fix the issue via (upcoming) point release for stretch?

Yes, that should be fine.

smcv

Bug#925561: xfce4-weather-plugin: API Outdated

[Lili-Anne Girard]

Package: xfce4-weather-plugin
Version: 0.8.9-1
Severity: important

Hi,

The xfce4-weather-plugin started issuing "HTTP 404, cause: Not Found" error 
messages in ~/.xsession-errors because the current API is outdated.

Please consider upgrading to the new stable release that solves this problem:

https://mail.xfce.org/pipermail/xfce-announce/2019-March/thread.html

Thank you.



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

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

Versions of packages xfce4-weather-plugin depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libsoup2.4-1 2.56.0-2+deb9u2
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  xfce4-panel  4.12.1-2

xfce4-weather-plugin recommends no packages.

xfce4-weather-plugin suggests no packages.

-- no debconf information

Bug#925541: CVE-2019-10063: incomplete TIOCSTI filtering, similar to snapd's CVE-2019-7303

[Salvatore Bonaccorso]

Hi Simon,

On Tue, Mar 26, 2019 at 03:28:03PM +, Simon McVittie wrote:
> Package: flatpak
> Version: 0.8.0-2
> Severity: important
> Tags: patch security upstream
> Forwarded: https://github.com/flatpak/flatpak/issues/2782
> 
> flatpak versions since 0.8.1 (and Debian's 0.8.0-2, which has backports
> of the upstream changes that became 0.8.1) attempt to prevent malicious
> apps from escalating their privileges by injecting commands into the
> controlling terminal with the TIOCSTI ioctl (CVE-2017-5226).
> 
> This fix was incomplete: on 64-bit platforms, seccomp looks at the whole
> 64-bit word, but the kernel only looks at the low 32 bits. This means we
> also have to block commands like (0x12345678 | TIOCSTI).
> CVE-2019-10063 has been allocated for this vulnerability, which closely
> resembles CVE-2019-7303 in snapd.
> 
> Mitigation: as usual with Flatpak sandbox bypasses, this can only be
> exploited if you install a malicious app from a trusted source. The
> sandbox parameters used for most apps are currently sufficiently weak
> that a malicious app could do other equally bad things that we cannot
> prevent, for example by abusing the X11 protocol.
> 
> For the testing/unstable distribution (buster/sid) this will be fixed
> in version 1.2.4, or in 1.2.3-2 if 1.2.4 isn't released soon.
> 
> For the stable distribution (stretch) upstream do not intend to do a
> new 0.8.x release, so this will have to be fixed by backporting. It's
> a simple backport.
> 
> Security team: I assume you probably won't want to do a DSA for this?

Ack. Can you fix the issue via (upcoming) point release for stretch?

Salvatore

Bug#925557: linux-image-4.19.0-4-amd64: kworker CPU hog, abundance of interrupts on PCI-E port with ath9k wireless card

[Vladimir K]

Tried booting into old kernels from Debian Snapshots, down to 
linux-image-4.14.0-2-amd64. Problem persists. Either I just didn't notice it 
before, or the problem originated from something other than kernel.

Bug#923640: "ifupdown" 0.8.35 breaks DHCP and DNS resolving.

[Ian Abel]

Package: ifupdown
Version: 0.8.35
Followup-For: Bug #923640

Dear Maintainer,

  This bug is seemingly due to misguided single-stack DHCPv4 servers 
that are still
  found in the wild. If dhclient sents a client identifier at all, they 
will NAK
  and not respond. Hence the previous report of being able to obtain an 
IP address
  via a manual 'dhclient eth0', which will default to not using the 
'-i' option
  that is now the default in ifupdown (see #906894).

  On my installation I have confirmed the following (options setting
  pid files and leases files removed for brevity, they 
do not
  change anything):

  dhclient -4 -v -I works
  dhclient -4 -v -i -I fails with a DHCPNAK from the server
  dhclient -4 -v -I fails if 'send dhcp-client-identifier' is set in
  /etc/dhcp/dhclient.conf [a non-exhaustive search of possible
  identifiers ahs yet to find one that the server will accept].

  A possible solution is to add a configuration option for
  /etc/network/interfaces to enable/disable this on a per-interface
  basis. Or to be able to flag an interface as 'legacy v4' or similar
  and entirely disable v6 and related features.

  Severity has been flagged as important because this results in an
  unusable system silently across upgrade if you're on a network with
  such a server.

  Yours,

  Ian Abel

-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto enp0s31f6
iface enp0s31f6 inet dhcp

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rwxr-xr-x 1 root root 372 Jul 30  2018 openvpn

/etc/network/if-post-down.d:
total 0
lrwxrwxrwx 1 root root 23 Oct 10 04:17 avahi-daemon -> ../if-up.d/avahi-daemon

/etc/network/if-pre-up.d:
total 4
-rwxr-xr-x 1 root root 344 Jun 30  2016 ethtool

/etc/network/if-up.d:
total 12
-rwxr-xr-x 1 root root  484 Apr 27  2018 avahi-daemon
-rwxr-xr-x 1 root root 1685 Jun 30  2016 ethtool
-rwxr-xr-x 1 root root  385 Jul 30  2018 openvpn


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

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

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-8
ii  lsb-base  10.2019031300

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-2+4.1
pn  rdnssd  

-- no debconf information

Bug#925517: [Pkg-javascript-devel] Bug#925517: Non-NSA/Microsoft upstream repo, new version

[Jeffrey Cliff]

> many packages come from GitHub

And I intend on filing a bug report on every single one of those packages,
as they come up.  This is a huge problem, but one that can be solved since
it is free software we are talking about.


On Tue, 26 Mar 2019 at 15:28, Xavier  wrote:

> Le 26/03/2019 à 20:17, Jeffrey Cliff a écrit :
> > As maintainer, that's up to you, but I do not accept any project hosted
> > in the NSA/Microsoft walled garden as the legitimate upstream of
> > anything and I will continue to host 'progress', in particular,
> > somewhere, until a 2.0.0+ version is available in some other upstream
> place.
>
> So I recommend you to no more use Debian since many packages come from
> GitHub. Anyway, publishing a fork of a software without changing its
> name isn't a good thing and may be invalid. Please host this somewhere
> else.
>


-- 
GENERATION 26: The first time you see this, copy it into your sig on any
forum and add 1 to the generation

Bug#925556: UEFI or not, can't mount /dev

[Lennart Sorensen]

On Tue, Mar 26, 2019 at 07:13:21PM +, Steve McIntyre wrote:
> On Wed, Mar 27, 2019 at 02:58:36AM +0800, 積丹尼 Dan Jacobson wrote:
> >Package: debian-installer
> >
> >Guess what, seen with ASUS X370-A:
> 
> Dan, you know better than this. A useful bug report needs much more
> information. For a start, what image did you use to install with? This
> looks like it *might* be on first boot after installation, but you're
> leaving me to guess at that. How did you partition, etc.? Were there
> any errors reported during installation?
> 
> Please help us to help you...

Well the picture appears to show root is sdb2 on a disk with sdb1 and
sdb2 partitions, and it can't mount /dev apparently because there is no
/dev directory on the root filesystem to mount it on.

At least that's what it looks like in the picture.

Clearly the initramfs was able to mount /dev and run fsck, but mounting
it to /root/dev to transfer to the real rootfs failed due to a missing
directory.

-- 
Len Sorensen

Bug#924129: debian-installer: Kernel for armhf for stretch unbootable

[Adam D. Barratt]

On Tue, 2019-03-26 at 10:39 -0700, Vagrant Cascadian wrote:
> On 2019-03-26, Adam D. Barratt wrote:
> > On 2019-03-15 06:44, Adam D. Barratt wrote:
> > > The updated images for armhf have been available in p-u for a
> > > couple of
> > > days now.
> > > 
> > > Feedback would be appreciated, as we would like to be able to
> > > accept
> > > the new kernel upload into p-u, which will block a further
> > > rebuild here
> > > as it brings an ABI bump. (The existing images should continue to
> > > work
> > > until the older packages are decrufted in the next point
> > > release.)
> > 
> > Thanks to Peter for the feedback.
> > 
> > Vagrant (or anyone else) - anything to add?
> 
> Just tested fine on BananaPI:
> 
>   https://cdn-aws.deb.debian.org/debian/dists/stretch-proposed-update
> s/main/installer-
> armhf/20170615+deb9u5+b3/images/netboot/netboot.tar.gz
> 
> Installed to SATA. No surprises or anything unusual.
> 
> I'd say it's ready; please push it into stretch.

Thanks for testing.

As I mentioned on IRC, we can't "push it into stretch" without a point
release, and the whole point of this exercise was to avoid having to
schedule another short-notice point release.

However, assuming KiBi has no objections, it sounds like we can go
ahead with getting the -9 ABI kernel into p-u in preparation for the
9.9 point release in a few weeks time. Assuming I haven't missed
anything, the d-i version in p-u should continue to be suitable for
installing stretch on armhf in the meantime (at least until the p-u
freeze hits, at which point d-i will get rebuilt against the new
kernel).

Regards,

Adam

Bug#925559: unblock: netlib-java/0.9.3-5

[Andreas Tille]

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

Please unblock package netlib-java


diff -Nru netlib-java-0.9.3/debian/changelog netlib-java-0.9.3/debian/changelog
--- netlib-java-0.9.3/debian/changelog  2019-01-13 21:11:05.0 +0100
+++ netlib-java-0.9.3/debian/changelog  2019-03-26 16:47:32.0 +0100
@@ -1,3 +1,10 @@
+netlib-java (0.9.3-5) unstable; urgency=medium
+
+  * Fix URLClassLoader
+Closes: #923759
+
+ -- Andreas Tille   Tue, 26 Mar 2019 16:47:32 +0100
+
 netlib-java (0.9.3-4) unstable; urgency=medium
 
   * Deactivate watch file since in debian/README.source is declared that
diff -Nru netlib-java-0.9.3/debian/patches/series 
netlib-java-0.9.3/debian/patches/series
--- netlib-java-0.9.3/debian/patches/series 2019-01-13 21:11:05.0 
+0100
+++ netlib-java-0.9.3/debian/patches/series 2019-03-26 16:47:32.0 
+0100
@@ -1 +1,2 @@
 update_classpath.patch
+URLClassLoader.patch
diff -Nru netlib-java-0.9.3/debian/patches/URLClassLoader.patch 
netlib-java-0.9.3/debian/patches/URLClassLoader.patch
--- netlib-java-0.9.3/debian/patches/URLClassLoader.patch   1970-01-01 
01:00:00.0 +0100
+++ netlib-java-0.9.3/debian/patches/URLClassLoader.patch   2019-03-26 
16:47:32.0 +0100
@@ -0,0 +1,48 @@
+From: Markus Koschany 
+Date: Mon, 25 Mar 2019 14:44:22 +0100
+Bug-Debian: https://bugs.debian.org/923759
+Subject: URLClassLoader
+
+---
+ src/org/netlib/generate/JavaGenerator.java | 14 --
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/src/org/netlib/generate/JavaGenerator.java 
b/src/org/netlib/generate/JavaGenerator.java
+index fda8e9d..15815de 100644
+--- a/src/org/netlib/generate/JavaGenerator.java
 b/src/org/netlib/generate/JavaGenerator.java
+@@ -51,6 +51,8 @@ import org.netlib.util.doubleW;
+ import org.netlib.util.floatW;
+ import org.netlib.util.intW;
+ 
++import java.net.MalformedURLException;
++
+ /**
+  * Due to the depressing number of LAPACK routines, it is much more efficient 
to
+  * auto-generate the Java code for the wrapper and corresponding Java and JNI
+@@ -643,7 +645,8 @@ class JavaGenerator {
+* @return all classes in a given package
+* @see 
http://forum.java.sun.com/thread.jspa?threadID=757391=4326850
+*/
+-  private List> getClasses(String packageName, IClassFilter 
filter) {
++  private List> getClasses(String packageName, IClassFilter 
filter)
++  throws MalformedURLException{
+   String packagePath = packageName.replace('.', '/');
+ //ArrayList classpath = new ArrayList();
+ //String[] classpathString = 
System.getProperty("java.class.path").split(":");
+@@ -658,7 +661,14 @@ class JavaGenerator {
+ //log(Level.SEVERE, classpathString[i] + 
" " + ex.getMessage());
+ //}
+ //}
+-  URL [] classpath = ((URLClassLoader) 
ClassLoader.getSystemClassLoader()).getURLs();
++  URL url1 = new URL("file:///usr/share/java/junit-3.8.2.jar");
++  URL url2 = new URL("file:///usr/share/java/f2jutil-0.8.1.jar");
++  URL url3 = new 
URL("file:///usr/share/java/jlapack-blas-0.8.jar");
++  URL url4 = new 
URL("file:///usr/share/java/jlapack-lapack-0.8.jar");
++  URL url5 = new 
URL("file:///usr/share/java/jlapack-xerbla-0.8.jar");
++  URL url6 = new 
URL("file:///build/netlib-java-0.9.3/build/classes/");
++
++  URL [] classpath = { url1, url2, url3, url4, url5, url6 };
+   List> result = new ArrayList>();
+   System.out.println(Arrays.toString(classpath));
+   for (URL url : classpath) {


unblock netlib-java/0.9.3-5

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

Kernel: Linux 4.9.0-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#924913: trackpad on L480 unusable after upgrade to testing

[Romain Perier]

On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote:
> On 3/18/19 7:46 PM, Romain Perier wrote:
> > On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:
> >> On 3/18/19 12:20 PM, Romain Perier wrote:
> >>> Hello,
> >>>
> >>> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
>  Source: linux
>  Severity: normal
> 
>  Dear Maintainer,
> 
>     On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
>  (testing).
>     After the upgrade, the touchpad and the trackpoint was not usable
>  anymore.
> 
> 
>     This already has some bug report here,
>     https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> 
>     As a workaround, one can run the command,
>     sudo sh -c 'echo -n "elantech">
>  /sys/bus/serio/devices/serio1/protocol'
>     in order to use the touchpad. However, on a GUI Interface and without
>     an external mouse, it's impossible to apply this workaround
>    (switching to the terminal -F1, login, and run the command
>  above might work)
> 
>     I expect to be able to use the touchpad just out of the box, not 
>  needing
>     to run the above workaround
> 
> >>> Could you :
> >>>
> >>> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and 
> >>> confirm or
> >>>   not is the problem still exists ?
> >> Dear Romain
> >>
> >>
> >> I upgraded the kernel and rebooted:
> >>
> >> schloegl@debian10:~$ uname -a
> >> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
> >> x86_64 GNU/Linux
> >>
> >>
> >> With this kernel the trackpoint is working, the trackpad is still not
> >> usable.
> >>
> >> (This improves the situation because now at least one pointer device is
> >> available).
> >>
> >>
> > Good, we did some progress :)
> >
> >>> - According to the bug on launchpad and to the fix pushed upstream, the
> >>>   fix seems to be an hardware quirks, could you give me the output of the
> >>>   following command :
> >>>   $ /sys/bus/serio/devices/serio1/firmware_id
> >> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
> >> PNP: LEN2036 PNP0f13
> >>
> > Could you test the patch attached to this reply ?
> > (if you don't know how to do this, I can provide support)
> >
> > Regards,
> > Romain
> 
> 
> 
> I tried to followed these instructions:
> 
> https://kernel-team.pages.debian.net/kernel-handbook/ch-comm
> 
> 4.5. Building a custom kernel from Debian kernel source
> 
> Specifically using the patched the sources,
> 
> *scripts/config --disable MODULE_SIG*
> **scripts/config --disable DEBUG_INFO**
> ||*|make clean|* ||*|make deb-pkg
> 
> |*
> 
> and ended up with a kernel that does not boot (missing HD audio firmware),
> 
> 
> Which procedure do you recommend to build and install a modified kernel ?
> 
> 

Hi,

Section 4.2 from
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
, until test-patches should work. For the test-patches script, use the flavour 
and a
featureset as argument, when you invoke it, like this :

# debian/bin/test-patches -f amd64 -s none 
/path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch

This will apply the patch on the fly, configure the kernel for amd64
and build a version with a special changelog entry and a special suffix
version dedicated to the test version you generate.


In case of troubles, I can provide another way, from git with few
commands.


Hope this helps,
Regards,
Romain


signature.asc
Description: PGP signature

Bug#925489: unblock: elogind/241.1-1+debian1

[Michael Biebl]

Am 26.03.19 um 19:45 schrieb Adam Borowski:
> On Tue, Mar 26, 2019 at 06:52:11PM +0100, Michael Biebl wrote:
>> Just to set the record straight here:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244
>>
>> This bug report is from Mon, 25 Feb 2019 11:49:14 +
> 
> That's the "plan 3" bug.  We had plan 1 over a year ago.

I'm not aware of such a bug report. References please.

>> That this all is getting rushed on the last minute is not the fault of
>> the policykit-1 maintainers and I'm not amused that Adam tries to paint
>> it like that.
> 
> I'm not amused either how long it takes to get any response to even a
> single-line patch that had been discussed before.  But, the blame game is
> counterproductive. 

Why did you start it then?

> It had been requested that the point of alternative gets moved.  That
> request is now fulfilled, the code is uploaded, and has seen 12 days of
> testing.  At this point, I kindly request your review.  Is the current
> version of elogind, as packaged by Mark Hindley, good enough for you?

You honestly think with a behaviour like yours I'm motivated to review
your package and spend my time on it? The motivation/time I had dropped
basically to zero reading what you wrote.

If you had a carefully layed out plan, why do we have chaotic and rushed
bug reports like [1]. That doesn't look like a well thought out plan to me.

Anyway, I don't have any interest anymore to spend more time on this, so
don't expect any responses from me from now on.

Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922160#31
-- 
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#864017: release-notes: Assumes /etc/apt/sources.list is used (and not /etc/apt/sources.list.d/*.list or deb822) [general]

[Paul Gevers]

Hi,

On 25-03-2019 22:13, Paul Gevers wrote:
> On 24-03-2019 23:27, Justin B Rye wrote:
>> Also, when we first mention APT configuration we need to set out what
>> we mean by "APT source-list files", if only by pointing at
>> sources.list(5).
> 
> I wanted to link to that man page as well, so let's find a place. I'm
> nearly of to bed now, so if you find a good spot before I do tomorrow,
> don't hesitate to mail.

I have added a link to the manpages (3 places), but I am not totally
happy with how it reads.

What do you think?

Paul
From 710a6ac851e47e6952087aec89a5b7e8397cf9be Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Sun, 24 Mar 2019 20:31:48 +0100
Subject: [PATCH] Generalize use of APT source-list files

Closes: #864017
---
 en/old-stuff.dbk | 36 ++--
 en/upgrading.dbk | 85 +---
 2 files changed, 63 insertions(+), 58 deletions(-)

diff --git a/en/old-stuff.dbk b/en/old-stuff.dbk
index 0a53d737..ec26ca91 100644
--- a/en/old-stuff.dbk
+++ b/en/old-stuff.dbk
@@ -27,14 +27,14 @@ upgraded to the latest  point release.
 
 
 
-Checking your sources list
+Checking your APT source-list files
 
-If any of the lines in your /etc/apt/sources.list
-refer to stable, it effectively
-points to  already. This might not be what you want if
-you are not ready yet for the upgrade.  If you have already run
-apt update, you can still get back without
-problems by following the procedure below.
+  If any of the lines in your APT source-list files (see https://manpages.debian.org//apt/sources.list.5.en.html;>sources.list(5))
+  refer to stable, it effectively points to
+   already. This might not be what you want if you are not ready
+  yet for the upgrade.  If you have already run apt update,
+  you can still get back without problems by following the procedure below.
 
 
 If you have also already installed packages from , there probably
@@ -43,28 +43,28 @@ that case you will have to decide for yourself whether you want to continue or
 not.  It is possible to downgrade packages, but that is not covered here.
 
 
-Open the file /etc/apt/sources.list with your favorite
+  Open the relevant APT source-list file, e.g.
+  /etc/apt/sources.list, with your favorite
 editor (as root) and check all lines beginning with
 deb http:, deb https:,
-deb tor+http:, deb tor+https: or
-deb ftp: for a reference to
+deb tor+http:, deb tor+https:,
+URIs: http:,
+URIs: https:,
+URIs: tor+http: or URIs: tor+https:
+for a reference to
 stable.  If you find any, change
 stable to .
 
-
-  
-Lines in sources.list starting with deb ftp: and pointing to debian.org
-addresses should be changed into deb http: lines.
-  
-
 
-If you have any lines starting with deb file:, you will have
+  If you have any lines starting with deb file: or
+  URIs: file:, you will have
 to check for yourself if the location they refer to contains an
  or a  archive.
 
 
   
-Do not change any lines that begin with deb cdrom:.
+Do not change any lines that begin with deb cdrom: or
+URIs: cdrom:.
 Doing so would invalidate the line and you would have to
 run apt-cdrom again.  Do not be alarmed if a
 cdrom: source line refers to unstable.
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index a22924f3..54a6eb9f 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -290,12 +290,14 @@ $ apt-forktracer | sort
 
 
   Because of this you should review if there are any pending actions in the
-  package manager aptitude.  If a package is scheduled for
-  removal or update in the package manager, it might negatively impact the
-  upgrade procedure.  Note that correcting this is only possible if your
-  sources.list still points to 
-  and not to stable or ; see .
+  package manager aptitude.  If a package is scheduled
+  for removal or update in the package manager, it might negatively impact
+  the upgrade procedure.  Note that correcting this is only possible if
+  your APT source-list files, i.e. the files described in the https://manpages.debian.org//apt/sources.list.5.en.html;>sources.list(5)
+  manpage, still point to  and not to
+  stable or ; see
+  .
 
 
   To perform this review, launch aptitude in full-terminal mode and
@@ -381,7 +383,7 @@ $ apt-forktracer | sort
 
 
   If there is anything you need to fix, it is best to make sure your
-  sources.list still refers to  as explained in .
 
   
@@ -389,23 +391,23 @@ $ apt-forktracer | sort
   
 The proposed-updates section
 
-  If you have listed the proposed-updates section
-  in your /etc/apt/sources.list file, you
-  should remove it from that file before attempting to upgrade your
-  system.  This is a precaution to reduce the likelihood of
-  conflicts.
+  If you have listed the proposed-updates section in
+  your APT source-list files, you should remove it from those files before
+  attempting 

Bug#925499: [Debian-med-packaging] Bug#925499: bowtie2 arm64 (aarch64) package

[Alex Mestiashvili]

Hi All,

as far as I see, we need to get SIMDe into Debian before we can build
bowtie2 for ARM64.
See:
https://github.com/BenLangmead/bowtie2/commit/4213c394cb21311e01c4a8e8778e27980c38d0be

Best,
Alex

Bug#925558: please add example scripts

[W. Martin Borgert]

Package: python3-aioxmpp-doc
Version: 0.10.3-2
Severity: wishlist

Please add the example scripts to the -doc package:
echo examples > debian/python3-aioxmpp-doc.examples
Too late for buster, unfortunately.

Bug#925517: [Pkg-javascript-devel] Bug#925517: Non-NSA/Microsoft upstream repo, new version

[Xavier]

Le 26/03/2019 à 20:17, Jeffrey Cliff a écrit :
> As maintainer, that's up to you, but I do not accept any project hosted
> in the NSA/Microsoft walled garden as the legitimate upstream of
> anything and I will continue to host 'progress', in particular,
> somewhere, until a 2.0.0+ version is available in some other upstream place.

So I recommend you to no more use Debian since many packages come from
GitHub. Anyway, publishing a fork of a software without changing its
name isn't a good thing and may be invalid. Please host this somewhere else.

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[BERTRAND Joël]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Gabriel Filion a écrit :
> On 2019-03-26 2:43 p.m., Gabriel Filion wrote:
>> Did you recently upgrade smokeping? if so what version were you
>> using before? (maybe check your dpkg logs for signs of upgrade of
>> the smokeping package)
> 
> I just thought of something else: if you were using the 2.7.3-1
> package previously, it's possible that the service was running as
> root (which was fixed in -2 so that it would run as
> "smokeping:smokeping")
> 
> maybe check ownership of the /run/smokeping directory to see if it
> is owned by root. If it is, then rmdir the directory before
> restarting the service.
> 
> There might be other files owned by root, too. Check out files in 
> smokeping's data directory, /var/lib/smokeping/. if anything in
> there is owned by root, run a chown -R smokeping:smokeping -- but
> make sure to avoid squashing the group on /var/lib/smokeping/__cgi
> and anything inside : they should be owned by smokeping but have
> their group set to www-data and the __cgi directory should have the
> group sticky bit set (e.g. mode 2775)

Unfortunately, all files required by smokeping are owned by smokeping
user.

Best regards,

JKB
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAlyafX4ACgkQOAfo0lKQ
8+cb5g//ax8e4ukzmq7lBwSZLWlZ84CleFWGz+8SdjqH9CE8nPiUE18l+gl/3CLJ
FZlpTfdvZ9YIhl5/sE02/nv7aBIGqLhH7arclXyltOFerlOX4WiHHVkiOjW6Fgjt
1KrXjhM3YlBvUr7DOvEMAgV/p1z0XKH81VFi7cV6NXY1IVR2pM1+44zj4JZau36r
cjMojrnahQZN3wEkS1edl6OLStwKBAaWzlgrhE8nH/U+dKZ0XfqzkE9f4ANS6fgQ
EBd3sOeglYePvDh1Xy1n3ZvRAyIP8VXacV9+9hAPLkMBsY9LZXIeO1w2pwDTAFad
9e6hZfkdX99PHagAfRfcDpnhrH4wBa81d+uPzE4rQt7LknEYW5qT5IMOCad1zFmq
zdbV3B2hfmeXu09jXwwNm6mpo6l9cFPPIkCxEMW9UQbYgvWRbsiBf8yXugdCm67j
5awffUXu+1TzVIjWgTxRdz/qPUN9O9oQFvnuesfvbEjPBLqief9d5puhi7IE+o6/
PdsAZH+4ia5fB8+DM/tu4MomaQwjRVlQmjNZ5ES54eVmd3IsdUl9A4atKIJhOZpK
aDuorXY3tlouR0AQSodXVw9WDKe9j4CY73XIOmf52NRKp38Q923qoTVGtPULHgv4
IQ2VPVAgj8+8icZyN8Zc52ukGdlEmzr/1o+ySdeph8r6uqVoEC0=
=9CBl
-END PGP SIGNATURE-

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[BERTRAND Joël]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Gabriel Filion a écrit :
> Hi Bertrand,

Hello,

> e.g. the file is in /run/smokeping and systemd is able to use it
> to restart the servce.

In my case, systemd doesn't create /run/smokeping.

> Did you recently upgrade smokeping? if so what version were you
> using before? (maybe check your dpkg logs for signs of upgrade of
> the smokeping package)

Yes, I have.

- -> 2019-03-17 03:26:38 upgrade smokeping:all 2.7.2-3 2.7.3-2

> Do you have an override in place for the smokeping.service systemd
> unit? "service smokeping status" will show you if there is an
> override in place. e.g. it would look similar to this:
> 
> root@debian-10-amd64:~# service smokeping status ●
> smokeping.service - Latency Logging and Graphing System Loaded:
> loaded (/lib/systemd/system/smokeping.service; enabled; vendor
> preset: enabled) Drop-In: /etc/systemd/system/smokeping.service.d 
> └─slave_mode.conf

Root rayleigh:[/var/log] > service smokeping status
● smokeping.service - Latency Logging and Graphing System
   Loaded: loaded (/lib/systemd/system/smokeping.service; enabled;
vendor preset: enabled)
   Active: failed (Result: timeout) since Sun 2019-03-24 18:06:51 CET;
2 days ago
 Docs: man:smokeping(1)
   file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf

Warning: Journal has been rotated since unit was started. Log output
is incomplete or unavailable.

Best regards,

JKB

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAlyafNcACgkQOAfo0lKQ
8+f8eQ/+M+YgJT50Uu3+2b9n926Vz0o4oU8egqPRga1eTVoip5PxJZU7nmrEiJCO
bNsEgIFNTQfyWDsCMCsPBJmzC9c3JmgOwxaTmPyHTSJEGS1s1uztg+62k3dE7ynO
SYd2INd7ybopg8IQaJr6rJAP261pVKDhd5L1Lafa5wXna1JkNuMa8fuDl92vh+uq
zj6fCsEh5F3UrI0TEmoLDmImKRTnkrQuhn1KpCyiiZSnziRRT37oNRgR859ZX8sh
+yl2HKjtZ9XKZuVyIAldKNA2qUOEXOjEmnHUsyeuzlQeXxnkMzv4yLp0X7aJQbWk
ZQ9QLgX6Wi7POKSddeq1FysLNtIv3PXMaYire/pUyayd5ZVOQBeWVrKv0V8WUNkJ
TKFSi3l0qM7o5MeLkslTg/JsPpkKBpenjOSMn/zmUzLXmi3Pr9bOZKh1bYLpmh6f
Ezxb+OlzQsLfBtKkRGE9UIv/duUVWhPziaNWpSDL2RpAjtCYLO0bbI+dXLE2WFnS
EupDYt2TQx8yFF8SjF360IsD2Yee0+zmgbiKqgxDcqX79Bj/10ztwYFRM0L9Lz3C
sTjj8Rgb/yXYgEOUIGOGasmIqrX+0IXnzR3F8gGnrzKMTb2Ps/AzABbdMzbv5EPD
PRtlvE3Le3k1AL/CqKXzyKjmacym2uPikU7lcU47SxzQR5j2EkU=
=jDwr
-END PGP SIGNATURE-

Bug#861101: Can't enter disk encryption password

[Sven Bartscher]

Hi Laurent,

Sorry, I completely missed your email.

On Fri, 19 Jan 2018 11:50:05 +0100 Laurent Bigonville 
wrote:
> Could you please retry again with the version 0.9.3-2 that I've just 
> uploaded to unstable?
> 
> I've imported an upstream patch that might have an impact for nvidia 
> cards (fallback to text renderer if something is wrong with the DRM one)
I now have 0.9.4-1 installed and the problem is not present anymore.
Thanks for taking care of this issue!

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Bug#924488: CUDA 10.1 is now available

[Graham Inggs]

Hi Andreas

On Tue, 26 Mar 2019 at 19:33, Andreas Beckmann  wrote:
> If you can confirm that this now works on Ubuntu as well on both
> architectures, I would upload it to experimental. And then let you prod
> ftp-master for quick processing :-)

I confirm it now builds on Ubuntu amd64 and ppc64el.  Please go ahead
and upload to experimental, and I'll bug ftp-master.

> I assume you are targeting Ubuntu 19.04 :-)

Yes, I'm getting in early for a change!

> And then we would have another argument for doing this late transition
> for buster: it has been done on Ubuntu with(out) causing (serious)
> hassle :-)

Agreed.

Regards
Graham

Bug#925517: [Pkg-javascript-devel] Bug#925517: Non-NSA/Microsoft upstream repo, new version

[Jeffrey Cliff]

As maintainer, that's up to you, but I do not accept any project hosted in
the NSA/Microsoft walled garden as the legitimate upstream of anything and
I will continue to host 'progress', in particular, somewhere, until a
2.0.0+ version is available in some other upstream place.

On Tue, 26 Mar 2019 at 14:34, Xavier  wrote:

> Le 26/03/2019 à 19:04, Jeffrey Cliff a écrit :
> > 2.0.0 was the version when Microsoft captured Github.  That's the newest
> > one I have, but thankfully that's as new as is needed by the version of
> > eslint in RFP.
> >
> > I prefer to do my contributions anonymously.  I am not the author.
> >
> >> Following https://www.npmjs.com/package/progress, repo is
> > https://github.com/visionmedia/node-progress.
> >
> > Indeed, it does go to NSA/Microsoft's walled garden.
> >
> >> There is de debian/ dir in your repo, why ?
> >
> > I can remove that
>
> >> So if you're upstream author, I suggest you to publish a 2.0.4 in
> >> npmjs.com with new repo in your package.json, then we could safely
> >> change debian/watch.
>
> I won't update anything unless you publish a new version accepted by
> npmjs.com: it will prove that you've some rights on node-progress.
>
> Debian can't accept an hostile takeover. If you're not upstream, you can
> publish your fork under another name.
>


-- 
GENERATION 26: The first time you see this, copy it into your sig on any
forum and add 1 to the generation

Bug#925556: UEFI or not, can't mount /dev

[Steve McIntyre]

On Wed, Mar 27, 2019 at 02:58:36AM +0800, 積丹尼 Dan Jacobson wrote:
>Package: debian-installer
>
>Guess what, seen with ASUS X370-A:

Dan, you know better than this. A useful bug report needs much more
information. For a start, what image did you use to install with? This
looks like it *might* be on first boot after installation, but you're
leaving me to guess at that. How did you partition, etc.? Were there
any errors reported during installation?

Please help us to help you...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#925551: lintian: desktop-command-not-in-package - plugin where host command is executed

[Ross Gammon]

Hi Chris,

On 3/26/19 7:03 PM, Chris Lamb wrote:
> tags 925551 + moreinfo
> thanks
> 
> Hi Ross,
> 
>> To avoid a warning in this case, could lintian check if a package with a
>> similar name to the command exists as a dependency to the package with the
>> desktop file?
> 
> My worry is that this would make this check a little bit too "magical",
> especially when weighed up against providing an override for what I
> believe to be a somewhat rare case. What do you think?
> 
> 
> Regards,
> 

I thought it might be tricky, bug decided to report it in case you could
do magic :-)

There was a similar bug about the executable being in a different
package (update-alternatives).

It is the first time I have come across the issue. But there might be
other plugin type cases. Looking at the lintian website, there are lots
of overrides, and soon to be one more.

Thanks for the fast response. Feel free to close the bug.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#925557: linux-image-4.19.0-4-amd64: kworker CPU hog, abundance of interrupts on PCI-E port with ath9k wireless card

[Vladimir K]

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

Dear Maintainer, since an unknown moment possibly in the past several months 
I'm experiencing constant
90-100% CPU load on one core by a kworker/X:2+events process.

At least versions 4.19+101, 4.19+102, 4.19+104 are affected.

According to /proc/interrupts, an overwhelming amount of interrupts comes from 
a PCI-E port (IRQ 117):

CPU0 CPU1 CPU2 CPU3
   0: 8 0 0 0 IO-APIC 2-edge timer
   1: 0 4 0 0 IO-APIC 1-edge i8042
   5: 0 0 0 0 IO-APIC 5-edge parport0
   8: 0 0 0 0 IO-APIC 8-edge rtc0
   9: 0 0 0 0 IO-APIC 9-fasteoi acpi, INT0002
  12: 6 0 0 0 IO-APIC 12-edge i8042
  17: 0 318849 5361 2635 IO-APIC 17-fasteoi ath9k
  18: 0 0 0 0 IO-APIC 18-fasteoi i801_smbus
 115: 0 0 0 0 PCI-MSI 458752-edge PCIe PME
 116: 0 0 0 0 PCI-MSI 460800-edge PCIe PME
 117: 181796 0 132746756 0 PCI-MSI 462848-edge PCIe PME
 118: 0 0 0 0 PCI-MSI 464896-edge PCIe PME
 121: 10528 691 8054 11298 PCI-MSI 524288-edge wan0
 122: 488 26 539 2472 PCI-MSI 327680-edge xhci_hcd
 123: 0 6315 1148 14096 PCI-MSI 311296-edge ahci[:00:13.0]
 124: 0 0 0 0 PCI-MSI 1048576-edge lan0
 125: 343 0 641 142 PCI-MSI 3670016-edge ahci[:07:00.0]
 126: 0 0 0 0 INT0002 Virtual GPIO 2 ACPI:Event
 127: 14172 0 24300 1175 PCI-MSI 32768-edge i915
 128: 0 0 484 0 PCI-MSI 442368-edge snd_hda_intel:card0
 NMI: 8 6 313 4 Non-maskable interrupts
 LOC: 84303 67217 614766 36976 Local timer interrupts
 SPU: 0 0 0 0 Spurious interrupts
 PMI: 8 6 313 4 Performance monitoring interrupts
 IWI: 0 3 42 0 IRQ work interrupts
 RTR: 0 0 0 0 APIC ICR read retries
 RES: 51814 5319 1118 3337 Rescheduling interrupts
 CAL: 11937 5390 4781 5729 Function call interrupts
 TLB: 42 162 45 42 TLB shootdowns
 TRM: 0 0 0 0 Thermal event interrupts
 THR: 0 0 0 0 Threshold APIC interrupts
 DFR: 0 0 0 0 Deferred Error APIC interrupts
 MCE: 0 0 0 0 Machine check exceptions
 MCP: 8 8 8 8 Machine check polls
 HYP: 0 0 0 0 Hypervisor callback interrupts
 HRE: 0 0 0 0 Hyper-V reenlightenment interrupts
 HVS: 0 0 0 0 Hyper-V stimer0 interrupts
 ERR: 1
 MIS: 0
 PIN: 0 0 0 0 Posted-interrupt notification event
 NPI: 0 0 0 0 Nested posted-interrupt event
 PIW: 0 0 0 0 Posted-interrupt wakeup event



Device tree from that port:

/sys/devices/pci:00/:00:1c.2:
00:1c.2 PCI bridge [0604]: Intel Corporation Atom/Celeron/Pentium Processor 
x5-E8000/J3xxx/N3xxx Series PCI Express Port #3 [8086:22cc] (rev 21)
Kernel driver in use: pcieport

/sys/devices/pci:00/:00:1c.2/:03:00.0:
03:00.0 PCI bridge [0604]: ASMedia Technology Inc. Device [1b21:1182]
Kernel driver in use: pcieport

/sys/devices/pci:00/:00:1c.2/:03:00.0/:04:03.0:
04:03.0 PCI bridge [0604]: ASMedia Technology Inc. Device [1b21:1182]
Kernel driver in use: pcieport

/sys/devices/pci:00/:00:1c.2/:03:00.0/:04:03.0/:05:00.0:
05:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI 
Bridge [1b21:1080] (rev 04)

/sys/devices/pci:00/:00:1c.2/:03:00.0/:04:03.0/:05:00.0/:06:00.0:
06:00.0 Network controller [0280]: Qualcomm Atheros AR9227 Wireless Network 
Adapter [168c:002d] (rev 01)
Subsystem: Qualcomm Atheros AR9227 Wireless Network Adapter [168c:0300]
Kernel driver in use: ath9k
Kernel modules: ath9k

Please advise on further diagnostics.





-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 root=/dev/mapper/mt2_sysgroup-root ro 
quiet

** Not tainted

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

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: Default string
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F4
board_vendor: Gigabyte Technology Co., Ltd.
board_name: N3150ND3V
board_version: x.x

** Loaded modules:
msr
nft_masq_ipv4
nft_masq
nft_counter
nft_limit
nft_nat
nft_redir_ipv4
nft_redir
nft_objref
nf_tables_set
nft_ct
nft_chain_nat_ipv4
nf_nat_ipv4
nf_tables
nfnetlink
ctr
ccm
cpufreq_userspace
cpufreq_conservative
cpufreq_powersave
tun
snd_hda_codec_hdmi
snd_hda_codec_realtek
snd_hda_codec_generic
arc4
ath9k
ath9k_common
i915
ath9k_hw
uvcvideo
ath
mac80211
snd_usb_audio
snd_hda_intel
snd_hda_codec
snd_usbmidi_lib
intel_rapl
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
snd_hda_core
snd_rawmidi
videobuf2_common
snd_hwdep
snd_seq_device
videodev
drm_kms_helper
media
intel_powerclamp
cfg80211
snd_pcm
drm
kvm_intel
snd_timer
i2c_algo_bit
snd
hci_uart
kvm
btqca
soundcore
btrtl
btbcm
btintel
iTCO_wdt
bluetooth
sg
iTCO_vendor_support
drbg
irqbypass
ansi_cprng
ppdev
ecdh_generic
crct10dif_pclmul
crc32_pclmul

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[Gabriel Filion]

On 2019-03-26 2:43 p.m., Gabriel Filion wrote:
> Did you recently upgrade smokeping? if so what version were you using
> before? (maybe check your dpkg logs for signs of upgrade of the
> smokeping package)

I just thought of something else: if you were using the 2.7.3-1 package
previously, it's possible that the service was running as root (which
was fixed in -2 so that it would run as "smokeping:smokeping")

maybe check ownership of the /run/smokeping directory to see if it is
owned by root. If it is, then rmdir the directory before restarting the
service.

There might be other files owned by root, too. Check out files in
smokeping's data directory, /var/lib/smokeping/. if anything in there is
owned by root, run a chown -R smokeping:smokeping -- but make sure to
avoid squashing the group on /var/lib/smokeping/__cgi and anything
inside : they should be owned by smokeping but have their group set to
www-data and the __cgi directory should have the group sticky bit set
(e.g. mode 2775)



signature.asc
Description: OpenPGP digital signature

Bug#925489: unblock: elogind/241.1-1+debian1

[Adam Borowski]

On Tue, Mar 26, 2019 at 06:52:11PM +0100, Michael Biebl wrote:
> Just to set the record straight here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244
> 
> This bug report is from Mon, 25 Feb 2019 11:49:14 +

That's the "plan 3" bug.  We had plan 1 over a year ago.

> That this all is getting rushed on the last minute is not the fault of
> the policykit-1 maintainers and I'm not amused that Adam tries to paint
> it like that.

I'm not amused either how long it takes to get any response to even a
single-line patch that had been discussed before.  But, the blame game is
counterproductive.  Could we please discuss how to fix present state?

It had been requested that the point of alternative gets moved.  That
request is now fulfilled, the code is uploaded, and has seen 12 days of
testing.  At this point, I kindly request your review.  Is the current
version of elogind, as packaged by Mark Hindley, good enough for you?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄

Bug#925444: smokeping: --pid-dir doesn't worj as expected

[Gabriel Filion]

Hi Bertrand,

On 2019-03-25 2:57 a.m., BERTRAND Joël wrote:
> I have restarted a server last sunday and I have seen that smokeping doesn't
> start anymore.
> 
> In systemd config file, smokeping is launched with --pid-dir=/run/smokeping 
> and
> systemd complains about non existent pid file.
> 
> I have tried to launch smokeping in command line :
> [~] > /usr/sbin/smokeping --pid-dpid-dir=/run/smokepingir=/run/smokeping
> 
> and pid file is created in... /run and not in /run/smokeping, that confuses
> systemd.

I've tried to reproduce this in a vanilla debian buster VM in which I
installed smokeping and the behaviour you mentioned wasn't showing up.

e.g. I see this which is what is expected:

root@debian-10-amd64:~# ls -l /run/smokeping/
total 4
-rw-r--r-- 1 smokeping smokeping 5 Mar 26 18:32 smokeping.pid
root@debian-10-amd64:~# ls -l /run/ | grep smokeping
drwxr-xr-x  2 smokeping   smokeping 60 Mar 26 18:32 smokeping
root@debian-10-amd64:~# service smokeping restart
root@debian-10-amd64:~# ls -l /run/ | grep smokeping
drwxr-xr-x  2 smokeping   smokeping 60 Mar 26 18:33 smokeping
root@debian-10-amd64:~# ls -l /run/smokeping/
total 4
-rw-r--r-- 1 smokeping smokeping 5 Mar 26 18:33 smokeping.pid

e.g. the file is in /run/smokeping and systemd is able to use it to
restart the servce.


Did you recently upgrade smokeping? if so what version were you using
before? (maybe check your dpkg logs for signs of upgrade of the
smokeping package)

Do you have an override in place for the smokeping.service systemd unit?
"service smokeping status" will show you if there is an override in
place. e.g. it would look similar to this:

root@debian-10-amd64:~# service smokeping status
● smokeping.service - Latency Logging and Graphing System
   Loaded: loaded (/lib/systemd/system/smokeping.service; enabled;
vendor preset: enabled)
  Drop-In: /etc/systemd/system/smokeping.service.d
   └─slave_mode.conf


cheers!



signature.asc
Description: OpenPGP digital signature

Bug#925555: linux-image-4.19.0-4-amd64: Display manager fails to start or display anything on IvyBridge with linux-image-4.19.0-4-amd64

[Aurélien COUDERC]

Package: src:linux
Version: 4.19.28-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrading the kernel to 4.19.0-4 or later (5.0.0-trunk), my IvyBridge
laptop fails to start the display manager.
I end up with a black screen and a non blinking _ character in the top left
corner of the screen.

I tested with sddm, lightdm on X and GDM on wayland and have the same
behaviour everytime.
After advice from #debian-kernel I compared lspci for both kernels and it
gives the same output.

Switching to a text VT works (I'm reportbugging from there).
Reverting to 4.19.0-3 returns to the normal behaviour and the graphical
session starts normally.


Cheers,
--
Coucouf

-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-4-amd64 
root=UUID=9fccd33e-ceb6-48d4-8a47-f46fded95997 ro quiet splash

** Not tainted

** Kernel log:
[   16.220937] L1TF CPU bug present and SMT on, data leak possible. See 
CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html 
for details.
[   16.374742] media: Linux media interface: v0.10
[   16.391761] videodev: Linux video capture interface: v2.00
[   16.448128] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_1.3M 
(0c45:644d)
[   16.578804] uvcvideo 1-1.5:1.0: Entity type for entity Extension 4 was not 
initialized!
[   16.578808] uvcvideo 1-1.5:1.0: Entity type for entity Extension 3 was not 
initialized!
[   16.578810] uvcvideo 1-1.5:1.0: Entity type for entity Processing 2 was not 
initialized!
[   16.578812] uvcvideo 1-1.5:1.0: Entity type for entity Camera 1 was not 
initialized!
[   16.579413] input: Laptop_Integrated_Webcam_1.3M:  as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0/input/input14
[   16.579870] usbcore: registered new interface driver uvcvideo
[   16.579871] USB Video Class driver (1.1.1)
[   17.229059] BTRFS warning (device dm-0): excessive commit interval 600
[   17.229062] BTRFS info (device dm-0): disk space caching is enabled
[   17.455312] BTRFS warning (device sda2): excessive commit interval 600
[   17.455315] BTRFS info (device sda2): disk space caching is enabled
[   17.857618] BTRFS warning (device dm-0): excessive commit interval 600
[   17.857621] BTRFS info (device dm-0): disk space caching is enabled
[   18.152918] BTRFS warning (device dm-0): excessive commit interval 600
[   18.152920] BTRFS info (device dm-0): disk space caching is enabled
[   18.288277] BTRFS warning (device dm-0): excessive commit interval 600
[   18.288280] BTRFS info (device dm-0): disk space caching is enabled
[   18.366993] BTRFS warning (device dm-0): excessive commit interval 600
[   18.366995] BTRFS info (device dm-0): disk space caching is enabled
[   18.427687] BTRFS warning (device dm-0): excessive commit interval 600
[   18.427690] BTRFS info (device dm-0): disk space caching is enabled
[   18.531462] BTRFS warning (device dm-0): excessive commit interval 600
[   18.531464] BTRFS info (device dm-0): disk space caching is enabled
[   20.823734] BTRFS warning (device dm-0): excessive commit interval 600
[   20.823737] BTRFS info (device dm-0): disk space caching is enabled
[   20.877491] BTRFS warning (device sda2): excessive commit interval 600
[   20.877494] BTRFS info (device sda2): disk space caching is enabled
[   20.950215] BTRFS warning (device dm-0): excessive commit interval 600
[   20.950217] BTRFS info (device dm-0): disk space caching is enabled
[   21.008972] BTRFS warning (device dm-0): excessive commit interval 600
[   21.008975] BTRFS info (device dm-0): disk space caching is enabled
[   21.083457] BTRFS warning (device dm-0): excessive commit interval 600
[   21.083459] BTRFS info (device dm-0): disk space caching is enabled
[   21.150589] BTRFS warning (device dm-0): excessive commit interval 600
[   21.150591] BTRFS info (device dm-0): disk space caching is enabled
[   21.206446] BTRFS warning (device dm-0): excessive commit interval 600
[   21.206449] BTRFS info (device dm-0): disk space caching is enabled
[   21.265467] BTRFS warning (device dm-0): excessive commit interval 600
[   21.265469] BTRFS info (device dm-0): disk space caching is enabled
[   22.850814] BTRFS warning (device dm-0): excessive commit interval 600
[   22.850817] BTRFS info (device dm-0): disk space caching is enabled
[   22.885809] BTRFS warning (device sda2): excessive commit interval 600
[   22.885811] BTRFS info (device sda2): disk space caching is enabled
[   22.949103] BTRFS warning (device dm-0): excessive commit interval 600
[   22.949105] BTRFS info (device dm-0): disk space caching is enabled
[   23.008419] BTRFS warning (device dm-0): excessive commit interval 600
[   23.008422] BTRFS info (device dm-0): disk space caching is enabled
[   23.066638] BTRFS warning (device dm-0): excessive commit interval 600
[   23.066641] BTRFS 

Bug#925554: ruby-rails-assets-jquery-fullscreen-plugin: Missing copyright details of the uploader

[Utkarsh Gupta]

Package: ruby-rails-assets-jquery-fullscreen-plugin
Version: 0.5.0+dfsg-1
Severity: normal

Dear Maintainer,

The copyright details of the uploader are missing.
You should generally mention the copyright in order to avoid issues later
on.
Please update the same.


Best,
Utkarsh


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

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

Versions of packages ruby-rails-assets-jquery-fullscreen-plugin depends on:
ii  libjs-jquery-fullscreen-plugin  0.5.0+dfsg-1
ii  ruby1:2.5.1

ruby-rails-assets-jquery-fullscreen-plugin recommends no packages.

ruby-rails-assets-jquery-fullscreen-plugin suggests no packages.

Bug#925553: audacity: segfault in NumericTextCtrl::ValueToControls() ()

[Jeff Cliff]

Package: audacity
Version: 2.2.2-1+b1
Severity: normal

Dear Maintainer,

What I did:

ssh -X (hostname)  //ssh'd to remote host on network
audacity   // ran audacity on remote host with broadcast of UI to 
local host
recorded audio // hit red record button

What happened:

segfault/crash

recording host was using the following hardware:

*-multimedia
 description: Multimedia audio controller
 product: 82801G (ICH7 Family) AC'97 Audio Controller
 vendor: Intel Corporation
 physical id: 1e.2
 bus info: pci@:00:1e.2
 version: 01
 width: 32 bits
 clock: 33MHz
 capabilities: pm bus_master cap_list
 configuration: driver=snd_intel8x0 latency=0
 resources: irq:23 ioport:ec00(size=256) ioport:e8c0(size=64) 
memory:feabfa00-feabfbff memory:feabf900-feabf9ff

Audacity crashed/segfaulted in the following stack frames:

(gdb) 
(gdb) bt
#0  0x7f02396718bb in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f023965c535 in __GI_abort () at abort.c:79
#2  0x7f023965c40f in __assert_fail_base
(fmt=0x7f02397beee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
assertion=0x7f023dd7566e "ret == self->nfds", file=0x7f023dd6f038 
"src/hostapi/alsa/pa_linux_alsa.c", line=3641, function=) at 
assert.c:92
#3  0x7f023966a0f2 in __GI___assert_fail
(assertion=0x7f023dd7566e "ret == self->nfds", file=0x7f023dd6f038 
"src/hostapi/alsa/pa_linux_alsa.c", line=3641, function=0x7f023dd75be0 
"PaAlsaStreamComponent_BeginPolling") at assert.c:101
#4  0x7f023dd571c3 in  () at /usr/lib/x86_64-linux-gnu/libportaudio.so.2
#5  0x7f023dd64e85 in  () at /usr/lib/x86_64-linux-gnu/libportaudio.so.2
#6  0x7f023dd6563e in  () at /usr/lib/x86_64-linux-gnu/libportaudio.so.2
#7  0x7f0239b2ffa3 in start_thread (arg=) at 
pthread_create.c:486
#8  0x7f023973382f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f022e9a7700 (LWP 13226))]
bt
#0  0x7f0239b39bf0 in __GI___nanosleep (requested_time=0x7f022e9a65b0, 
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28  ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
(gdb) bt
#0  0x7f0239b39bf0 in __GI___nanosleep (requested_time=0x7f022e9a65b0, 
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  0x7f023cfe3fdc in wxMicroSleep(unsigned long) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#2  0x55d080a4e662 in AudioThread::Entry() ()
#3  0x7f023cfd8d72 in wxThread::CallEntry() () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#4  0x7f023cfe2374 in  () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5  0x7f0239b2ffa3 in start_thread (arg=) at 
pthread_create.c:486
#6  0x7f023973382f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 3
[Switching to thread 3 (Thread 0x7f022f1a8700 (LWP 13225))]
#0  0x7f0239b39bf0 in __GI___nanosleep (requested_time=0x7f022f1a75b0, 
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28  in ../sysdeps/unix/sysv/linux/nanosleep.c
(gdb) bt
#0  0x7f0239b39bf0 in __GI___nanosleep (requested_time=0x7f022f1a75b0, 
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  0x7f023cfe3fdc in wxMicroSleep(unsigned long) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#2  0x55d080a482ef in MidiThread::Entry() ()
#3  0x7f023cfd8d72 in wxThread::CallEntry() () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#4  0x7f023cfe2374 in  () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5  0x7f0239b2ffa3 in start_thread (arg=) at 
pthread_create.c:486
#6  0x7f023973382f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 4
[Switching to thread 4 (Thread 0x7f022ffa9600 (LWP 13219))]
#0  0x55d080a0f5d0 in void std::__cxx11::basic_string, std::allocator 
>::_M_construct(wchar_t*, wchar_t*, std::forward_iterator_tag) ()
(gdb) bt
#0  0x55d080a0f5d0 in void std::__cxx11::basic_string, std::allocator 
>::_M_construct(wchar_t*, wchar_t*, std::forward_iterator_tag) ()
#1  0x55d080e19255 in NumericTextCtrl::ValueToControls() ()
#2  0x55d080e19330 in NumericTextCtrl::SetValue(double) ()
#3  0x55d080d7461b in SelectionBar::ValuesToControls() ()
#4  0x55d080b1f9ff in AudacityProject::TP_DisplaySelection() ()
#5  0x55d080dc7b56 in PlayIndicatorOverlay::OnTimer(wxCommandEvent&) ()
#6  0x7f023d00a7ae in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#7  0x7f023d00ab2a in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#8  0x7f023d00abc0 in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#9  

Bug#925552: release-notes: document problems with hidepid vs Buster systemd

[Justin B Rye]

Package: release-notes
Severity: wishlist
Tags: patch

The "hidepid" mount-options for /proc (as recommended by various
online hardening HOWTOs) work with Stretch but cause problems on
Buster, and are considered an unsupported configuration by systemd
upstream - see #819808, #892585, #897654.  So users should probably be
advised to disable hidepid before doing a dist-upgrade.

Proposed text for issues.dbk:

  

Hidepid mount options for procfs unsupported

  The hidepid mount options to /proc are known to cause
  problems with current versions of systemd, and are considered by systemd
  upstream to be an unsupported configuration. Users who have modified
  /etc/fstab to enable these options are advised to
  disable them before the upgrade, to ensure login sessions work on
  . (A possible route to re-enabling them is outlined on the
  wiki's https://wiki.debian.org/Hardening#Mounting_.2Fproc_with_hidepid;>Hardening
  page.)

  

I can't claim to have tested the advice on that Hardening link on a
modern laptop running GNOME-on-wayland with pulseaudio and udisks2 and
network-manager and so on, but if it's wrong, we should correct the
wiki rather than the pointer.

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

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

-- 
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 35841ee6..b69e7dbe 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -39,6 +39,22 @@ information mentioned in .
 
   
 
+  
+
+Hidepid mount options for procfs unsupported
+
+  The hidepid mount options to /proc are known to cause
+  problems with current versions of systemd, and are considered by systemd
+  upstream to be an unsupported configuration. Users who have modified
+  /etc/fstab to enable these options are advised to
+  disable them before the upgrade, to ensure login sessions work on
+  . (A possible route to re-enabling them is outlined on the
+  wiki's https://wiki.debian.org/Hardening#Mounting_.2Fproc_with_hidepid;>Hardening
+  page.)
+
+  
+
   
 Noteworthy obsolete packages
 

Bug#925551: lintian: desktop-command-not-in-package - plugin where host command is executed

[Chris Lamb]

tags 925551 + moreinfo
thanks

Hi Ross,

> To avoid a warning in this case, could lintian check if a package with a
> similar name to the command exists as a dependency to the package with the
> desktop file?

My worry is that this would make this check a little bit too "magical",
especially when weighed up against providing an override for what I
believe to be a somewhat rare case. What do you think?


Regards,

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

Bug#925190: udev: Random execution order of RUN commands

[Michael Biebl]

Am 26.03.19 um 16:01 schrieb Celelibi:
> Note that some hunks apply with an offset. But nontheless, it applies
> and work.

Thanks for testing the patch. Very much appreciated.

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#925517: [Pkg-javascript-devel] Bug#925517: Non-NSA/Microsoft upstream repo, new version

[Xavier]

Le 26/03/2019 à 19:04, Jeffrey Cliff a écrit :
> 2.0.0 was the version when Microsoft captured Github.  That's the newest
> one I have, but thankfully that's as new as is needed by the version of
> eslint in RFP.
> 
> I prefer to do my contributions anonymously.  I am not the author.
> 
>> Following https://www.npmjs.com/package/progress, repo is
> https://github.com/visionmedia/node-progress.
> 
> Indeed, it does go to NSA/Microsoft's walled garden.
> 
>> There is de debian/ dir in your repo, why ?
> 
> I can remove that

>> So if you're upstream author, I suggest you to publish a 2.0.4 in
>> npmjs.com with new repo in your package.json, then we could safely
>> change debian/watch.

I won't update anything unless you publish a new version accepted by
npmjs.com: it will prove that you've some rights on node-progress.

Debian can't accept an hostile takeover. If you're not upstream, you can
publish your fork under another name.

Bug#925141: Should rdma-core be a dependency of ibverbs-providers or libverb1

[Jason Gunthorpe]

On Tue, Mar 26, 2019 at 02:51:25PM +0100, Thomas Monjalon wrote:
> 26/03/2019 10:21, Christian Ehrhardt:
> > > >
> > > > rdma-core configures modprobe for ib/rdma modules, installs some
> > > > helper daemons and installs some udev rules. It certainly makes
> > > > administration of the server an easier task, but it isn't *required*
> > > > when configuring a Debian server for rdma and user-space ibverbs.
> > >
> > > I didn't think it is required for mlx5 as the ethernet driver
> > > autoloads the rdma modules itself..
> > 
> > Below is the log that I got from Mellanox (thanks Alaa and Thomas.
> > To me the messages related to ib_uverbs seem interesting.
> > 
> > @Jason - this is triggered by DPDK. In regard to the autoloading - did
> > you refer to DPDKs net_mlx5 or the kernels net_mlx5 in e.g.
> > mlx5_core.ko?
> > I only found [1] which does not seem right, can you point at the
> > autoloading feature (a commit maybe) that you meant (keep in mind this
> > is DPDK 17.11.5)?
> > [1]: https://doc.dpdk.org/guides/nics/mlx5.html#compilation-options
> 
> There is no autoloading of kernel drivers when using DPDK.

It looks like it is only done if the mlx5 NIC driver detects some kind
of RDMA mode..

> > @Allaa/Thomas - due to the messages in the log, could you try if
> > instead of installing rdma-core just doing the modprobe would be
> > enough to resolve the problem?
> >   $ modprobe ib_uverbs # instead of the apt install
> 
> Yes, manual modprobe partially replaces rdma-core packages.
> 
> These are the files we identified as required from the rdma-core packages:
>   /etc/modprobe.d/mlx4.conf
>   /etc/rdma/modules/rdma.conf
>   /lib/udev/rules.d/90-rdma-hw-modules.rules
>   /lib/systemd/system/rdma-hw.target
> 
> The first file (mlx4.conf) is a template helping to get the right config
> by commenting out a line.
> The others files are for autoloading of the kernel drivers.
> 
> I think you should include the rdma-core package when using DPDK.
> It can be a dependency of the DPDK package, or a dependency of libibverbs.
> Does it make sense to install libibverbs without rdma-core configuration?

Many rdma drivers do properly autoload and don't need the udev magic.

I have a long term plan to avoid needing this, but nobody is working
on it right now.

Jason

Bug#925517: [Pkg-javascript-devel] Bug#925517: Non-NSA/Microsoft upstream repo, new version

[Xavier]

Le 26/03/2019 à 17:53, Jeffrey Cliff a écrit :
> I don't use NSA/Microsoft github so I'll assume you mean to update the
> readme in the repo I control, which I have added a note to.  Is there
> anything in specific you are interested in my adding?
> 
> On Tue, 26 Mar 2019 at 07:17, Xavier  > wrote:
> 
> Le 26/03/2019 à 08:07, Jeffrey Cliff a écrit :
> > Package: node-progress
> > Version: 1.1.8-1
> > Severity: normal
> >
> > As NSA/Microsoft has taken over Github, it is long since time to
> move to
> > a non-Microsoft source for projects like node-progress.  I have made a
> > non-microsoft repo at salsa
> > at https://salsa.debian.org/themusicgod1-guest/progress/ for use as a
> > future 'upstream' for this package.
> >
> > Also of note: the version of progress at the above repo is 2.0.0,
> which
> > is a newer version.  A diff can be made available if it is required. 
> >
> > Jeff Cliff
> 
> Hello,
> 
> could you also update
> https://github.com/visionmedia/node-progress#readme ?

There are some troubles here:
 * For now, you are not mentioned as node-progress contributor neither
   author
(https://github.com/visionmedia/node-progress/blob/master/package.json).
 * Github/npmjs version is 2.0.3 while yours is 2.0.0.
 * Following https://www.npmjs.com/package/progress, repo is
   https://github.com/visionmedia/node-progress.
 * There is de debian/ dir in your repo, why ?

So if you're upstream author, I suggest you to publish a 2.0.4 in
npmjs.com with new repo in your package.json, then we could safely
change debian/watch.

Debian package of node-progress is hosted on
https://salsa.debian.org/js-team/node-progress

Cheers,
Xavier

Bug#925489: unblock: elogind/241.1-1+debian1

[Michael Biebl]

Am 26.03.19 um 14:54 schrieb Adam Borowski:
> It's not a "niche" area.  Without this, any modern GUI desktop environments
> are not installable with any pid 1 other than systemd.  That'd be a massive
> regression that's certainly not acceptable (and it's caused by removal of a
> systemd component with a hard dependency).
> 
> This regression had a plan, with coded and tested patches by January 2018
> (with a refresh + retesting in June, then November, December).  In that
> plan, policykit packages had alternatives built against elogind.  Yet
> patches did not get applied.  Plan 2 was to dlopen() relevant libraries.
> 

Just to set the record straight here:

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

This bug report is from Mon, 25 Feb 2019 11:49:14 +

That this all is getting rushed on the last minute is not the fault of
the policykit-1 maintainers and I'm not amused that Adam tries to paint
it like that.




signature.asc
Description: OpenPGP digital signature

Bug#925551: lintian: desktop-command-not-in-package - plugin where host command is executed

[Ross Gammon]

Package: lintian
Version: 2.5.81ubuntu1
Severity: normal

Dear Maintainer,

Hexter is a package I am working on that runs as a plugin, and the desktop file
executes the host (dssi-host-jack) with hexter as an a further option in the
command (Exec=jack-dssi-host hexter.so).

https://salsa.debian.org/multimedia-team/hexter

To avoid a warning in this case, could lintian check if a package with a
similar name to the command exists as a dependency to the package with the
desktop file?

Regards,

Ross



-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500,
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils  2.30-21ubuntu1~18.04
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1build1
ii  dpkg  1.19.0.5ubuntu2.1
ii  file  1:5.32-2ubuntu0.2
ii  gettext   0.19.8.1-6ubuntu0.1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33build1
ii  libarchive-zip-perl   1.60-1ubuntu0.1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5ubuntu2.1
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1build3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-6ubuntu0.3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.3-2ubuntu0.1
ii  patchutils0.3.4-2
ii  perl  5.26.1-6ubuntu0.3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1build3

Versions of packages lintian suggests:
ii  binutils-multiarch 2.30-21ubuntu1~18.04
ii  dpkg-dev   1.19.0.5ubuntu2.1
ii  libhtml-parser-perl3.72-3build1
ii  libtext-template-perl  1.47-1

Bug#925550: grub-efi-amd64-signed: Cannot verify grubx64.efi.signed against "Debian Secure Boot CA"

[Marc Riedel]

Package: grub-efi-amd64-bin
Version: 1+2.02+dfsg1+16
Severity: important
Tags: upstream

I cannot verify grubx64.efi.signed against "Debian Secure Boot CA"
(https://dsa.debian.org/secure-boot-ca).

Steps to reproduce:

sbverify --list /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
signature 1
image signature issuers:
 - /CN=Debian Secure Boot CA
image signature certificates:
 - subject: /CN=Debian Secure Boot Signer
   issuer:  /CN=Debian Secure Boot CA

wget -q -O - https://dsa.debian.org/secure-boot-ca | openssl x509 -inform der
-outform  pem -out secure-boot-ca.pem

openssl x509 -in secure-boot-ca.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ed:54:a1:d5:af:87:48:94:8d:9f:89:32:ee:9c:7c:34
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = Debian Secure Boot CA
Validity
Not Before: Aug 16 18:09:18 2016 GMT
Not After : Aug  9 18:09:18 2046 GMT
Subject: CN = Debian Secure Boot CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:9d:95:d4:8b:9b:da:10:ac:2e:ca:82:37:c1:a4:
cb:4a:c3:1b:42:93:c2:7a:29:d3:6e:dd:64:af:80:
af:ea:66:a2:1b:61:9c:83:0c:c5:6b:b9:35:25:ff:
c5:fb:e8:29:43:de:ce:4b:3d:c6:12:4d:b1:ef:26:
43:95:68:cd:04:11:fe:c2:24:9b:de:14:d8:86:51:
e8:38:43:bd:b1:9a:15:e5:08:6b:f8:54:50:8b:b3:
4b:5f:fc:14:e4:35:50:7c:0b:b1:e2:03:84:a8:36:
48:e4:80:e8:ea:9f:fa:bf:c5:18:7b:5e:ce:1c:be:
2c:80:78:49:35:15:c0:21:cf:ef:66:d5:8a:96:08:
2b:66:2f:48:17:b1:e7:ec:82:8f:07:e6:ca:e0:5f:
71:24:39:50:0a:8e:d1:72:28:50:a5:9d:21:f4:e3:
61:ba:09:03:66:c8:df:4e:26:36:0b:15:0f:63:1f:
2b:af:ab:c4:28:a2:56:64:85:8d:a6:55:41:ae:3c:
88:95:dd:d0:6d:d9:29:db:d8:c4:68:b5:fc:f4:57:
89:6b:14:db:e0:ef:ee:40:0d:62:1f:ea:58:d4:a3:
d8:ba:03:a6:97:2e:c5:6b:13:a4:91:77:a6:b5:ad:
23:a7:eb:0a:49:14:46:7c:76:e9:9e:32:b4:89:af:
57:79
Exponent: 65537 (0x10001)
X509v3 extensions:
Authority Information Access:
CA Issuers - URI:https://dsa.debian.org/secure-boot-ca

X509v3 Authority Key Identifier:
keyid:6C:CE:CE:7E:4C:6C:0D:1F:61:49:F3:DD:27:DF:CC:5C:BB:41:9E:A1

Netscape Cert Type: critical
SSL Client, SSL Server, S/MIME, Object Signing, SSL CA, S/MIME
CA, Object Signing CA
X509v3 Extended Key Usage:
Code Signing
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
6C:CE:CE:7E:4C:6C:0D:1F:61:49:F3:DD:27:DF:CC:5C:BB:41:9E:A1
Signature Algorithm: sha256WithRSAEncryption
 77:96:3e:47:c9:ce:09:cf:8b:89:ce:59:ed:26:0e:26:0b:b9:
 ad:a9:2b:bd:a1:eb:88:79:02:ff:31:de:fe:f5:6a:07:ef:61:
 13:11:70:1e:bf:9c:4e:66:6c:e1:62:12:97:01:57:65:47:dd:
 4a:c6:f7:f4:de:a8:f1:13:62:cc:83:57:ac:3c:a6:91:15:af:
 55:26:72:69:2e:14:cd:dd:4d:b3:d1:60:24:2d:32:4f:19:6c:
 11:5e:f2:a3:f2:a1:5f:62:0f:30:ae:ad:f1:48:66:64:7d:36:
 44:0d:06:34:3d:2e:af:8e:9d:c3:ad:c2:91:d8:37:e0:ee:7a:
 5f:82:3b:67:8e:00:8a:c4:a4:df:35:16:c2:72:2b:4c:51:d7:
 93:93:9e:ba:08:0d:59:97:f2:e2:29:a0:44:4d:ea:ee:f8:3e:
 02:60:ca:15:cf:4e:9a:25:91:84:3f:b7:5a:c7:ee:bc:6b:80:
 a3:d9:fd:b2:6d:7a:1e:63:14:eb:ef:f1:b0:40:25:d5:e8:0e:
 81:eb:6b:f7:cb:ff:e5:21:00:22:2c:2e:9a:35:60:12:4b:5b:
 5f:38:46:84:0c:06:9c:cf:72:93:62:18:ee:5c:98:d6:b3:7d:
 06:25:39:95:df:4e:60:76:b0:06:7b:08:b0:6e:e3:64:9f:21:
 56:ad:39:0f

sbverify --cert secure-boot-ca.pem /usr/lib/grub/x86_64-efi-
signed/grubx64.efi.signed
Signature verification failed

Can you please point me to the right certificate?

Best Regards

Marc Riedel



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

Kernel: Linux 5.0.0-2.slh.1-aptosid-amd64 (SMP w/12 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages grub-efi-amd64-signed depends on:
ii  grub-common  2.02+dfsg1-16

Versions of packages grub-efi-amd64-signed recommends:
ii  shim-signed  1.28+nmu3+0.9+1474479173.6c180c6-1

grub-efi-amd64-signed suggests no packages.

Versions of 

Bug#925544: [Pkg-rust-maintainers] Bug#925544: ripgrep: Exits immediately without warning if it encounters a NUL byte inside the file to be searched, might exit with wrong exit code depending on the p

[Axel Beckert]

Hi Sylvestre,

Sylvestre Ledru wrote:
> Lowering the severity as rg remains functionnal in the huge majority
> of the cases.

Fair enough.

> I cannot reproduce the issue on my system
[…]
> doesn't show the warning
[…]
> cat aeh.txt | rg -a a
> cat aeh.txt | rg a
> returns the same thing
[…]
> afaik, with the correct file:
> % cat -v aeh.txt
> a
> M-CM-$
> 
> a

Nope. The third line should read "^@" with "cat -v", not "". And since
that ^@ (the escaped display of a NUL byte, sometimes also displayed
as "\0") is the relevant part to reproduce this issue, it's no wonder,
you couldn't reproduce it. :-)

I guess the file got wrecked while saving. Wouldn't surprise me since
the file contains a NUL byte which is often considered to be a string
terminator. (Which is probably what ripgrep does, too. :-) Maybe I
shouldn't have declared the attachment as "text/plain" as my mail
client suggested.

Anyway, at least these command show all the expected output:

$ GET 
https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=925544\;filename\=aeh.txt\;msg\=5
 | cat -v
$ wget -q -O-  
https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=925544\;filename\=aeh.txt\;msg\=5
 | cat -v
$ curl -s 
https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=925544\;filename\=aeh.txt\;msg\=5
 | cat -v

So it should be safe to download the file with one of these commands:

$ GET 
https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=925544\;filename\=aeh.txt\;msg\=5
 > aeh.txt
$ wget -q -O-  
https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=925544\;filename\=aeh.txt\;msg\=5
 > aeh.txt
$ curl -s 
https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=925544\;filename\=aeh.txt\;msg\=5
 > aeh.txt

(JFTR: I used the en_US.UTF-8 locale despite the example with German
umlauts. :-)

> BTW, don't hesitate to report this directly upstream as it doesn't
> seem to be a packaging issue.

Ok, will do.

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

Bug#924129: debian-installer: Kernel for armhf for stretch unbootable

[Vagrant Cascadian]

On 2019-03-26, Adam D. Barratt wrote:
> On 2019-03-15 06:44, Adam D. Barratt wrote:
>> The updated images for armhf have been available in p-u for a couple of
>> days now.
>> 
>> Feedback would be appreciated, as we would like to be able to accept
>> the new kernel upload into p-u, which will block a further rebuild here
>> as it brings an ABI bump. (The existing images should continue to work
>> until the older packages are decrufted in the next point release.)
>
> Thanks to Peter for the feedback.
>
> Vagrant (or anyone else) - anything to add?

Just tested fine on BananaPI:

  
https://cdn-aws.deb.debian.org/debian/dists/stretch-proposed-updates/main/installer-armhf/20170615+deb9u5+b3/images/netboot/netboot.tar.gz

Installed to SATA. No surprises or anything unusual.

I'd say it's ready; please push it into stretch.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#923812: please don't spam the BTS

[Jonatan Nyberg]

I didn't file two bugs for the same thing. Don't worry. I will not file
another bug report.

Den tis 26 mars 2019 18:22Alexandre Viau  skrev:

> Two bugs for the same thing is useless.
>
> You may send messages to the same bug if you want to discuss it, but
> please don't open a new one which I will have to merge every time.
>
> Please refer to the Debian wiki on reporting bugs:
>  - https://www.debian.org/Bugs/Reporting
>
> It wasn't upgraded because I haven't had the time yet.
>
> Cheers,
>
> --
> Alexandre Viau
> av...@debian.org
>
> On Tue, 26 Mar 2019 at 13:00, Jonatan Nyberg
>  wrote:
> >
> > Hello Alexandre,
> >
> > What spams? I just sent bug reports as a friendly reminder that the
> package should be upgraded upstream. Why wasn't it upgraded?
> >
> > Kind regards
> > Jonatan
> >
> > Den mån 25 mars 2019 14:45Alexandre Viau 
> skrev:
> >>
> >> Hello Jonatan,
> >>
> >>
> >> You opened two bugs asking for syncthing to be updated.
> >>
> >> Please don't spam the BTS uselessly.
> >>
> >>
> >> Cheers,
> >>
> >> --
> >> Alexandre Viau
> >> alexan...@alexandreviau.net
> >>
>

Bug#925549: unblock: libdatetime-timezone-perl/1:2.23-1+2019a

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.23-1+2019a to sid. It
contains the Olson timezone database 2019a as perl data files in a
quilt patch.

Changes in 2019a:

Palestine "springs forward" on 2019-03-30 instead of 2019-03-23.
Metlakatla "fell back" to rejoin Alaska Time on 2019-01-20 at 02:00.

Manually condensed debdiff attached.

As the above mentioned changes are already in effect, this might
warrant some aging as well.


unblock libdatetime-timezone-perl/1:2.23-1+2019a


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlyaYq1fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaZmhAAk5W8oNoQBpF7sVwrSip9VaNM87/eCMGsw5FfRfcvAHJTuKwK30d678eP
q5q2cbDvl6q7k6oZhqvDNTSvQxCPyGcnkOHfLpbjeTJoeB3wwyGpvkbt6yhVx3aA
POgoSXoWG1BiuWHAROQyUjqn+Usp/2tzNp60k0u9JYpGbe1K6FqUthEVNYLQ371j
vWlh3/ZFkZMu/kSASRrKGUe0Gf14YzX1JTUwGKq88PGb0foYd4rjY1I40CyYSlsb
GRFQVi/TfjDFrDRcwoPxz/mMp44bRen2P4tzP9WjTHvsr7cFLPG/RT7u05GnlIRi
+sp0D4+SF0aw/unbaEHGpRJ35DhrohsX2qMvXahG2bx1zW2ulLE328Sj3VL5gUab
Uq2XShvM80WyO2X9eJsOCc64sql1ffddah7BiZhEAe4aGJjpQvXKeYTAWQepDPAw
2NW3pPmmWdbvd6ObwNgTmI5WVyoViQkfQnYoG+g8NB+JTAHfgTucqM1sL8yRcVA1
2i+du4h3Fft/DxggWmJtWoH/MHzGZiGoEmr0pvTGsahw8ZefSkmkyc21ZI230686
sF2jHOH26CDUTLkQVpKhEX/KYZl3C4NtfRCIlVolk4WTiU1R5qRmaD00qCLeiwNl
upLadfiWRXdMAxm7kiFFhFFaG+8JSsk11HBxt44WNtl6TdHMdWQ=
=PMRt
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.23/debian/changelog 
libdatetime-timezone-perl-2.23/debian/changelog
--- libdatetime-timezone-perl-2.23/debian/changelog 2018-12-31 
16:21:58.0 +0100
+++ libdatetime-timezone-perl-2.23/debian/changelog 2019-03-26 
18:05:11.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.23-1+2019a) unstable; urgency=medium
+
+  * Update to Olson database version 2019a.
+This update contains contemporary changes for Palestine and Metlakatla.
+
+ -- gregor herrmann   Tue, 26 Mar 2019 18:05:11 +0100
+
 libdatetime-timezone-perl (1:2.23-1+2018i) unstable; urgency=high
 
   * Import upstream version 2.23.
diff -Nru libdatetime-timezone-perl-2.23/debian/patches/olson-2019a 
libdatetime-timezone-perl-2.23/debian/patches/olson-2019a
--- libdatetime-timezone-perl-2.23/debian/patches/olson-2019a   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.23/debian/patches/olson-2019a   2019-03-26 
18:05:11.0 +0100
@@ -0,0 +1,14273 @@
+Description: Update to Olson DB 2019a
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2019-03-26
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from /tmp/L68fv1TlrY/africa.  Olson data version 2018i
++# Generated from debian/tzdata/africa.  Olson data version 2019a
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,11 +43,11 @@
+ ],
+ ];
+ 
+-sub olson_version {'2018i'}
++sub olson_version {'2019a'}
+ 
+ sub has_dst_changes {0}
+ 
+-sub _max_year {2028}
++sub _max_year {2029}
+ 
+ sub _new_instance {
+ return shift->_init( @_, spans => $spans );
+--- a/lib/DateTime/TimeZone/Asia/Gaza.pm
 b/lib/DateTime/TimeZone/Asia/Gaza.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from /tmp/L68fv1TlrY/asia.  Olson data version 2018i
++# Generated from debian/tzdata/asia.  Olson data version 2019a
+ #
+ # Do not edit this file directly.
+ #
+@@ -367,8 +367,44 @@
+ ],
+ [
+ 62314347600, #utc_start 1975-08-30 21:00:00 (Sat)
+-62617960800, #  utc_end 1985-04-13 22:00:00 (Sat)
++62469698400, #  utc_end 1980-08-01 22:00:00 (Fri)
+ 62314354800, #  local_start 1975-08-30 23:00:00 (Sat)
++62469705600, #local_end 1980-08-02 00:00:00 (Sat)
++7200,
++0,
++'IST',
++],
++[
++62469698400, #utc_start 1980-08-01 22:00:00 (Fri)
++62473327200, #  utc_end 1980-09-12 22:00:00 (Fri)
++62469709200, #  local_start 1980-08-02 01:00:00 (Sat)
++62473338000, #local_end 1980-09-13 01:00:00 (Sat)
++10800,
++1,
++'IDT',
++],
++[
++62473327200, #utc_start 1980-09-12 22:00:00 (Fri)
++62588239200, #  utc_end 1984-05-04 22:00:00 (Fri)
++62473334400, #  local_start 1980-09-13 00:00:00 (Sat)
++62588246400, #local_end 1984-05-05 00:00:00 (Sat)
++7200,
++0,
++'IST',
++],
++[
++62588239200, #utc_start 1984-05-04 22:00:00 (Fri)
++62597916000, #  utc_end 1984-08-24 22:00:00 (Fri)
++6258825, #  local_start 1984-05-05 01:00:00 (Sat)
++62597926800, #local_end 1984-08-25 01:00:00 (Sat)
++10800,
++1,
++'IDT',
++],
++[
++62597916000, #utc_start 1984-08-24 22:00:00 (Fri)
++62617960800, #  utc_end 1985-04-13 22:00:00 (Sat)

Bug#925548: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2019a

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.09-1+2019a to strech. It
contains the Olson timezone database 2019a as perl data files in a
quilt patch.

Changes in 2019a:

Palestine "springs forward" on 2019-03-30 instead of 2019-03-23.
Metlakatla "fell back" to rejoin Alaska Time on 2019-01-20 at 02:00.

Manually condensed debdiff attached.

As the above mentioned changes are already in effect, this might be
material for stable-updates as well.


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlyaYq9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYm9w//a7MOYRqCmtoAn7rcXeWPzJM0e2qIWOhKsnAhwpfiCW735iqMsi+BMC3N
0lrDkiM53ecuFjE3rsabm/bBRz83qzddrzUGjFeXUQCBragOIGy7+CVLJpPsK0k1
QmjnK2lKCxwBdwLiCSCfHRhBNS5C8amtEEJ2A6YY3imeGszHUdvxiXNPJ89lOf+u
eegqhurmh3GRaub3zbtc5kUdYZ/RqZdKB7nuWRANEqr809BrqmPigF4ZHn1SOWvh
hvy5ad32gG59++A42Kc6wDAelf2QzCuVEOecvSk/uN2gjHqXtvuekN322J0NgN/6
5w01f6i9kaQbDUplb59C2OQO8V6tO46TQu+56U2MCsLA81JCPCvHNeAPSNtic73b
pGO8wPEgnWxj09Sgdu3usdC/aVvY9Mls929dZE0sLKCt/+JfWp8UNfm3eTE7hFyN
b+J6A9VAKAyF8sI03hA6HsDZdXlsrLtyonRgBnHsAoKr66Jf1tz3PHO+I3rD+8FQ
t0E+vq1RQgph+mUygCevNUufGsvqFkHUEVc5xE/FuuCywlQBaupvv4D4a0V3MbRy
wYHpYK6hFwfSMovmjIcgddgoTI17motsYP0BlL9HzSn/2xPmt72Bjo24DGl+05Oi
w1m2z1jBVQn6nzsFeCzkQTbO1c9nltqLBGC2/EBfjFG7UupWvCg=
=2Vlu
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.09/debian/changelog 
libdatetime-timezone-perl-2.09/debian/changelog
--- libdatetime-timezone-perl-2.09/debian/changelog 2018-12-31 
16:38:55.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/changelog 2019-03-26 
18:22:03.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.09-1+2019a) stretch; urgency=medium
+
+  * Update to Olson database version 2019a.
+This update contains contemporary changes for Palestine and Metlakatla.
+
+ -- gregor herrmann   Tue, 26 Mar 2019 18:22:03 +0100
+
 libdatetime-timezone-perl (1:2.09-1+2018i) stretch; urgency=medium
 
   * Update to Olson database version 2018i.
diff -Nru libdatetime-timezone-perl-2.09/debian/patches/olson-2019a 
libdatetime-timezone-perl-2.09/debian/patches/olson-2019a
--- libdatetime-timezone-perl-2.09/debian/patches/olson-2019a   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/patches/olson-2019a   2019-03-26 
18:22:03.0 +0100
@@ -0,0 +1,14677 @@
+Description: Update to Olson DB 2019a
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2019-03-26
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2018i
++# Generated from debian/tzdata/africa.  Olson data version 2019a
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,11 +43,11 @@
+ ],
+ ];
+ 
+-sub olson_version {'2018i'}
++sub olson_version {'2019a'}
+ 
+ sub has_dst_changes {0}
+ 
+-sub _max_year {2028}
++sub _max_year {2029}
+ 
+ sub _new_instance {
+ return shift->_init( @_, spans => $spans );
+--- a/lib/DateTime/TimeZone/Asia/Gaza.pm
 b/lib/DateTime/TimeZone/Asia/Gaza.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/asia.  Olson data version 2018i
++# Generated from debian/tzdata/asia.  Olson data version 2019a
+ #
+ # Do not edit this file directly.
+ #
+@@ -367,8 +367,44 @@
+ ],
+ [
+ 62314347600, #utc_start 1975-08-30 21:00:00 (Sat)
+-62617960800, #  utc_end 1985-04-13 22:00:00 (Sat)
++62469698400, #  utc_end 1980-08-01 22:00:00 (Fri)
+ 62314354800, #  local_start 1975-08-30 23:00:00 (Sat)
++62469705600, #local_end 1980-08-02 00:00:00 (Sat)
++7200,
++0,
++'IST',
++],
++[
++62469698400, #utc_start 1980-08-01 22:00:00 (Fri)
++62473327200, #  utc_end 1980-09-12 22:00:00 (Fri)
++62469709200, #  local_start 1980-08-02 01:00:00 (Sat)
++62473338000, #local_end 1980-09-13 01:00:00 (Sat)
++10800,
++1,
++'IDT',
++],
++[
++62473327200, #utc_start 1980-09-12 22:00:00 (Fri)
++62588239200, #  utc_end 1984-05-04 22:00:00 (Fri)
++62473334400, #  local_start 1980-09-13 00:00:00 (Sat)
++62588246400, #local_end 1984-05-05 00:00:00 (Sat)
++7200,
++0,
++'IST',
++],
++[
++62588239200, #utc_start 1984-05-04 22:00:00 (Fri)
++62597916000, #  utc_end 1984-08-24 22:00:00 (Fri)
++6258825, #  local_start 1984-05-05 01:00:00 (Sat)
++62597926800, #local_end 1984-08-25 01:00:00 (Sat)
++10800,
++1,
++'IDT',
++],
++[
++62597916000, #utc_start 1984-08-24 22:00:00 (Fri)
++62617960800, #  utc_end 1985-04-13 22:00:00 (Sat)
++62597923200, #  

Bug#924488: CUDA 10.1 is now available

[Andreas Beckmann]

On 2019-03-25 15:03, Graham Inggs wrote:
> Are the upstream tarballs likely to change?  If I were to upload to

Since I committed and pushed them to the tarball repo, I don't intend to
touch them :-)

I've applied fixes for the issues you encountered. (Note: branch has
been rebased).
This builds fine for me in a sid amd64 pbuilder chroot locally and on
the ppc64el porterbox plummer.d.o. Looks like I previously forgot to
integrate some of the ppc64el bits I had already fixed ... I always
tried to build in both environments ...

If you can confirm that this now works on Ubuntu as well on both
architectures, I would upload it to experimental. And then let you prod
ftp-master for quick processing :-)
I assume you are targeting Ubuntu 19.04 :-)
And then we would have another argument for doing this late transition
for buster: it has been done on Ubuntu with(out) causing (serious)
hassle :-)

Andreas

Bug#925547: firefox-esr: inappropiate settings for memory and number of cores

[Erich Minderlein]

Package: firefox-esr
Version: 60.6.0esr-1~deb9u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
downloading large videos with firefox and downloadhelper takes all memory
and high cpu load ald satlls the download with swapping and slowdown
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
opening a separate window about:memory and pressing the button for
garbage collection and minimize meory usage
   * What was the outcome of this action?
   cottnuation of download
   * What outcome did you expect instead?
   no need to press minimize memory usage.
firefox shall learn the available memory range and not use swap at all
firefox shall learn the real number of cpus and keep to n-1 cpus

-- Package-specific info:
firefox-esr 60.6.0esr (64-Bit)

-- Addons package information

Video DownloadHelper 7.3.5

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u4
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libx11-xcb1   2:1.6.4-3+deb9u1
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.2.12-1~deb9u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libgtk2.0-02.24.31-2
ii  pulseaudio 10.0-1+deb9u1

-- no debconf information

Bug#925546: panic: Can't find the package clause

[Joonas Kylmälä]

Package: gocode
Version: 20150303-3+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The gocode server only returns "PANIC" autocompletion because of the
following panic:

panic: Can't find the package clause
1(runtime.call32): /usr/lib/go-1.7/src/runtime/asm_amd64.s:479
2(runtime.gopanic): /usr/lib/go-1.7/src/runtime/panic.go:458
3(main.(*package_file_cache).process_package_data): 
/build/gocode-WMuvMl/gocode-20150303/obj-x86_64-linux-gnu/src/github.com/nsf/gocode/package.go:108
4(main.(*package_file_cache).update_cache): 
/build/gocode-WMuvMl/gocode-20150303/obj-x86_64-linux-gnu/src/github.com/nsf/gocode/package.go:91
5(main.update_packages.func1): 
/build/gocode-WMuvMl/gocode-20150303/obj-x86_64-linux-gnu/src/github.com/nsf/gocode/autocompletecontext.go:332
6(runtime.goexit): /usr/lib/go-1.7/src/runtime/asm_amd64.s:2086

panic: One of the package cache updaters panicked
1(runtime.call32): /usr/lib/go-1.7/src/runtime/asm_amd64.s:479
2(runtime.gopanic): /usr/lib/go-1.7/src/runtime/panic.go:458
3(main.update_packages): 
/build/gocode-WMuvMl/gocode-20150303/obj-x86_64-linux-gnu/src/github.com/nsf/gocode/autocompletecontext.go:340
4(main.(*auto_complete_context).update_caches): 
/build/gocode-WMuvMl/gocode-20150303/obj-x86_64-linux-gnu/src/github.com/nsf/gocode/autocompletecontext.go:165
5(main.(*auto_complete_context).apropos): 
/build/gocode-WMuvMl/gocode-20150303/obj-x86_64-linux-gnu/src/github.com/nsf/gocode/autocompletecontext.go:253
6(main.server_auto_complete): 
/build/gocode-WMuvMl/gocode-20150303/obj-x86_64-linux-gnu/src/github.com/nsf/gocode/server.go:155
7(main.(*RPC).RPC_auto_complete): 
/build/gocode-WMuvMl/gocode-20150303/obj-x86_64-linux-gnu/src/github.com/nsf/gocode/rpc.go:26
8(runtime.call64): /usr/lib/go-1.7/src/runtime/asm_amd64.s:480
9(reflect.Value.call): /usr/lib/go-1.7/src/reflect/value.go:434
10(reflect.Value.Call): /usr/lib/go-1.7/src/reflect/value.go:302
11(net/rpc.(*service).call): /usr/lib/go-1.7/src/net/rpc/server.go:383
12(runtime.goexit): /usr/lib/go-1.7/src/runtime/asm_amd64.s:2086


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

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

Versions of packages gocode depends on:
ii  libc6  2.24-11+deb9u3

gocode recommends no packages.

gocode suggests no packages.

-- no debconf information

Bug#925478: restart action breaks with systemd (Again)

[PICCORO McKAY Lenz]

El mar., 26 de mar. de 2019 a la(s) 03:42, Helmut Grohne (
helmut.gro...@intenta.de) escribió:

> You are listing two versions here. Does it really affect both versions?
>
YES


> > Severity: grave

Please use appropriate severity levels. `grave' is reserved for data
> loss, security holes are issues that make the package entirely unusable
> by anyone. Refer to https://www.debian.org/Bugs/Developer#severities for
> a more detailed explanation.
>
YES i setup some services and when users are acting on those.. data will
lose!


> I appreciate your help with reporting a bug. The additional polemic is
> not constructive though. Please stop that.
>
recently kamailio bugs was the same, a systemd service path was provide at
upstream..
recently lithttpd have similar problem that uptream solved and was related
to systemd


>  * Please specify versions of the following components:
>* Debian release in use
>
jessie (and later i install strech to test)


>* systemd
>
215-17+deb8up6  ?? the includes in jessie!

>* lighttpd
>
1.4.35-4+deb8u1


>  * How reliable is the problem? Does it happen every time you restart
>lighttpd?
>
nop! only after some time waqs passed
and specially if some changes are made to configuration


>  * In your log I marked the spot where lighttpd occurs in the process
>list. Notably, it lacks the -D flag, but the .service file supplies
>-D. Are you sure that this process is created by the .service file?
>
i use the command "service lighttpd restart" and seems in some cases
if there are a init script wil be converted on the fly to the "great"
systemd format!


>  * Did you customize the configuration or the .service file? Can you be
>specific about notable adjustments?
>
not! only added or change modules at the lighty.. main lighty config file
are original!


>  * Can you try reproducing the failure in a reduced setting (e.g. set up
>a VM with a bare minimal package set)?
>
that was a minimal install at VM
was hapened since jessie.. in wheeze does not happened..

as important point. i setup just for curiosity a Devuan VM and problems doe
snot happenD!
same was for kamailio conunterparts of systemd related scripts!


>
> Helmut
>

Bug#923812: please don't spam the BTS

[Alexandre Viau]

Two bugs for the same thing is useless.

You may send messages to the same bug if you want to discuss it, but
please don't open a new one which I will have to merge every time.

Please refer to the Debian wiki on reporting bugs:
 - https://www.debian.org/Bugs/Reporting

It wasn't upgraded because I haven't had the time yet.

Cheers,

--
Alexandre Viau
av...@debian.org

On Tue, 26 Mar 2019 at 13:00, Jonatan Nyberg
 wrote:
>
> Hello Alexandre,
>
> What spams? I just sent bug reports as a friendly reminder that the package 
> should be upgraded upstream. Why wasn't it upgraded?
>
> Kind regards
> Jonatan
>
> Den mån 25 mars 2019 14:45Alexandre Viau  skrev:
>>
>> Hello Jonatan,
>>
>>
>> You opened two bugs asking for syncthing to be updated.
>>
>> Please don't spam the BTS uselessly.
>>
>>
>> Cheers,
>>
>> --
>> Alexandre Viau
>> alexan...@alexandreviau.net
>>

Bug#925544: [Pkg-rust-maintainers] Bug#925544: ripgrep: Exits immediately without warning if it encounters a NUL byte inside the file to be searched, might exit with wrong exit code depending on the p

[Sylvestre Ledru]

severity 925544 normal
thanks

Hello,

Lowering the severity as rg remains functionnal in the huge majority of the 
cases.
And has a workaround and I can't reproduce.

Le 26/03/2019 à 18:12, Axel Beckert a écrit :

Package: ripgrep
Version: 0.10.0-2
Severity: important
Tags: upstream

Hi,

with several GB via STDIN, rg as well as rg -F immediately exited
without any output while fgrep found many hits until it issued the
warning "Binary file (standard input) matches".



I cannot reproduce the issue on my system
cat aeh.txt | fgrep a
doesn't show the warning
(french locale)


and both
cat aeh.txt | rg -a a
cat aeh.txt | rg a
returns the same thing


afaik, with the correct file:
% cat -v aeh.txt
a
M-CM-$

a


BTW, don't hesitate to report this directly upstream as it doesn't seem to be a 
packaging issue.

Thanks
S

Bug#616330: Reproducible?

[Dmitry Bogatov]

control: tags -1 +moreinfo

Hello!

Sorry for very late response. Before I dig into code, do you still
experience the problem?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgp2fl_qWpI_1.pgp
Description: PGP signature

Bug#427889: Proposing patch

[Dmitry Bogatov]

control: tags -1 patch

I believe this patch is adequate solution:

From 26e4989597d0fca9348443721c512f2b6774971c Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sun, 24 Mar 2019 22:18:22 +
Subject: [PATCH] Make init-d-scripts exit with sensible values (Closes:
 #427889)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

According to Policy=4.3.0.3,

The "init.d" scripts must ensure that they will behave sensibly (i.e.,
returning success and not starting multiple copies of a service) if
invoked with "start" when the service is already running, or with
"stop" when it isn’t, and that they don’t kill unfortunately-named
user processes.

This patch ensures, that exit values, returned by start-stop-daemon(8)
are sensible and propagated correctly into do_{start,stop,restart} functions.

Unfortunately, as resolved in #426877, --oknodo option is opt-in, and
default behaviour of start-stop-daemon is non-sensible with regard of
starting/stopping daemon, already running/stopped.
---
 debian/init-d-script | 38 +++---
 1 file changed, 15 insertions(+), 23 deletions(-)

diff --git a/debian/init-d-script b/debian/init-d-script
index 131dbd65..59ae3221 100755
--- a/debian/init-d-script
+++ b/debian/init-d-script
@@ -43,22 +43,10 @@ call() {
 # Function that starts the daemon/service
 #
 
-# Return
-#   0 if daemon has been started
-#   1 if daemon was already running
-#   2 if daemon could not be started
 do_start_cmd() {
-   start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
-   $START_ARGS \
-   --startas $DAEMON --name $NAME --exec $DAEMON --test > /dev/null \
-   || return 1
-   start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
-   $START_ARGS \
-   --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS \
-   || return 2
-   # Add code here, if necessary, that waits for the process to be ready
-   # to handle requests from services started subsequently which depend
-   # on this one.  As a last resort, sleep for some time.
+   start-stop-daemon --start --quiet --oknodo \
+   ${PIDFILE:+--pidfile ${PIDFILE}} $START_ARGS \
+   --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS
 }
 
 do_start()
@@ -68,12 +56,15 @@ do_start()
fi
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
call do_start_cmd
-   case "$?" in
+   retval=$?
+   case ${retval} in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
if is_call_implemented do_start_cleanup ; then
call do_start_cleanup
+   else
+   return ${retval}
fi
 }
 
@@ -81,11 +72,6 @@ do_start()
 # Function that stops the daemon/service
 #
 
-# Return
-#   0 if daemon has been stopped
-#   1 if daemon was already stopped
-#   2 if daemon could not be stopped
-#   other if a failure occurred
 do_stop_cmd() {
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
$STOP_ARGS \
@@ -114,12 +100,15 @@ do_stop()
fi
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
call do_stop_cmd
-   case "$?" in
+   retval=$?
+   case ${retval} in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
if is_call_implemented do_stop_cleanup ; then
call do_stop_cleanup
+   else
+   return ${retval}
fi
 }
 
@@ -130,12 +119,15 @@ do_restart() {
[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$NAME"
call do_stop_cmd
call do_start_cmd
-   case "$?" in
+   retval=$?
+   case ${retval} in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
if is_call_implemented do_restart_cleanup ; then
call do_restart_cleanup
+   else
+   return ${retval}
fi
 }
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpzdbvR43eVZ.pgp
Description: PGP signature