Bug#928224: AW: Bug#928224: Valgrind is broken on armhf

[Benjamin Wozniak]

Hi Bernhard,

thanks for your support. I installed the packages valgrind-dbg, libc6-l10n and 
locales
so that we can compare our systems. But the problem is still present.
I attached a file with my debugging output.

Kind regards,
Benjamin
root@localhost:~# valgrind /bin/true
==11507== Memcheck, a memory error detector
==11507== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11507== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==11507== Command: /bin/true
==11507== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:  index
valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:On Debian, Ubuntu: libc6-dbg
valgrind:On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.


root@localhost:~# dpkg -l | grep -E "2.28-8|1:3.14.0-3"
ii  libc-bin2.28-8  armhf
GNU C Library: Binaries
ii  libc-l10n   2.28-8  all  
GNU C Library: localization files
ii  libc6:armhf 2.28-8  armhf
GNU C Library: Shared libraries
ii  libc6-dbg:armhf 2.28-8  armhf
GNU C Library: detached debugging symbols
ii  locales 2.28-8  all  
GNU C Library: National Language (locale) data [support]
ii  valgrind1:3.14.0-3  armhf
instrumentation framework for building dynamic analysis tools
ii  valgrind-dbg1:3.14.0-3  armhf
instrumentation framework for building dynamic analysis tools (debug)


root@localhost:~# dpkg -S ld-linux-armhf.so.3
libc6:armhf: /lib/ld-linux-armhf.so.3
libc6:armhf: /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3


root@localhost:~# uname -a
Linux localhost 4.14.105-g7cb66ba74707 #1 SMP 2019-03-12 armv7l GNU/Linux


root@localhost:~# lscpu
Architecture:armv7l
Byte Order:  Little Endian
CPU(s):  2
On-line CPU(s) list: 0,1
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):   2
Vendor ID:   ARM
Model:   0
Model name:  Cortex-A9
Stepping:r3p0
BogoMIPS:666.66
Flags:   half thumb fastmult vfp edsp neon vfpv3 tls vfpd32

Bug#914399: git-branchmove: does not cope with restricted shell SSH remotes

[Sean Whitton]

Hello,

On Thu 22 Nov 2018 at 09:43PM -07, Sean Whitton wrote:

> git-branchmove does not work with SSH remotes which do not give the user
> a full shell, such as repository hosting services like GitLab, GitHub
> and Gitolite.

The assumption of full shell access is baked pretty deeply into
git-branchmove, so in order to fix this bug I rewrote the script.
Sharing it here for the benefit of passers by, but it would need a lot
more testing before it might replace the script in chiark-utils.

https://git.spwhitton.name/dotfiles/tree/bin/git-branchmove

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#914398: git-branchmove: does not respect insteadOf, pushInsteadOf git configuration keys

[Sean Whitton]

Hello Ian,

On Thu 02 May 2019 at 08:17PM +01, Ian Jackson wrote:

> Hi.  I'm not sure why are are treating these two cases so differently.
> The purpose the case statement is solely to try to avoid calling "git
> config" on things which are not remote names.
>
> But in both cases we want pushInsteadOf if there is one, I think ?
> (Ie, even for the source branch and even when it's not a configured
> remote.)  Is that possible DYK ?
>
> Hrm.  I tried git-ls-remote and it doesn't seem to have a --push.  And
> git-remote doesn't work on things that aren't configured remotes.
>
> Is that what you meant by "Beginnings of" ?

We do indeed want to expand pushInsteadOf in both cases.  However,
AFAICT, the only way to have git expand pushInsteadOf is `git remote
get-url --push`.  See [1].

My diff improves the situation by fixing things when there is insteadOf
but no pushInsteadOf in the user's config, but it is not a complete fix,
hence "Beginnings of".

Perhaps a complete fix would have to be something like

git remote add dummyOnlyWeUseThis $remote
remote=$(git remote get-url --push dummyOnlyWeUseThis)
git remote remove dummyOnlyWeUseThis

... which is pretty awful.

~ ~ ~ ~

I wanted to fix both this bug and #914399, but I found that #914399
would require basically rewriting git-branchmove, because the assumption
of shell access to the remote is baked pretty deeply into the script.

So I decided just to rewrite git-branchmove, this time in Perl, thereby
fixing both #914398 and #914399.  You can find my mostly untested work
at [2].  Once I've been using it successfully for a while, I was
thinking of proposing that it replace git-branchmove in chiark-utils.

Reading the logic of your script made it pretty straightforward and less
time-consuming to write mine :)

[1]  https://stackoverflow.com/a/32991784
[2]  https://git.spwhitton.name/dotfiles/tree/bin/git-branchmove

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928373: polari: fails to load help page

[Lev Lazinskiy]

Package: polari
Version: 3.30.2-1
Severity: normal

Dear Maintainer,

When clicking on Help in the Polari menu, there is a "Document Not Found" error
in Gnome Help message which states:

The URI ‘help:org.gnome.Polari/index’ does not point to a valid page.

I would expect the help page to load, or if there is no help page for this
application to remove the help menu item from the application to remove
confusion.



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

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

Versions of packages polari depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gspell-1  1.6.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-pango-1.0 1.42.4-6
ii  gir1.2-secret-1  0.18.7-1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-telepathyglib-0.120.24.1-2
ii  gir1.2-telepathylogger-0.2   0.8.2-3
ii  gjs  1.54.3-1
ii  libc62.28-8
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-1
ii  libglib2.0-bin   2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libtelepathy-glib0   0.24.1-2
ii  telepathy-idle   0.2.0-2+b1
ii  telepathy-logger 0.8.2-3
ii  telepathy-mission-control-5  1:5.16.4-2

polari recommends no packages.

polari suggests no packages.

-- no debconf information

Bug#928372: ITP: golang-github-anacrolix-dms-dev -- a UPnP DLNA Digital Media Server that includes basic video transcoding

[Drew Parsons]

On 2019-05-03 11:25, Drew Parsons wrote:

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: golang-github-anacrolix-dms-dev
  Version : 1.0.0
  Upstream Author : Matt Joiner 
* URL : https://github.com/anacrolix/dms

...

dms is a UPnP DLNA Digital Media Server.

...

This package is required by latest versions of rclone (providing a new
dlna server).



Hi Tobias and Go Team, do you have experience working with anacrolix?

The new rclone wants anacrolix/dms (for cmd/serve/dlna).  But anacrolix 
has an increasingly complex web of subdependencies.


anacrolix/dms requires fmpeg and anacrolix/ffprobe

ffprobe requires anacrolix/envpprof and anacrolix/missinggo

anacrolix/missinggo requires a whole suite of go modules, some are 
already in Debian, others are not.

https://github.com/anacrolix/missinggo/blob/master/go.mod


It's like it would be easier to simply delete the dlna server out of 
rclone, then we can just ignore the anacrolix web of dependencies.


How important do you consider dlna support in rclone?  The new rclone 
version itself is important for symlink support (Bug#924745).


Thoughts? Opinions?

Drew

Bug#926500: freecad: FreeCad crashes when attemting to edit a existing sketch

[Pere Nubiola Radigales]

 .FreeCADold.tar.gz


Pere Nubiola Radigales
Telf: +34 656316974
e-mail: p...@nubiola.cat
   pnubi...@fsfe.org
   pere.nubi...@gmail.com



Missatge de Kurt Kremitzki  del dia dj., 2 de maig
2019 a les 20:48:

> Hi Pere,
>
> On 5/2/19 2:28 AM, Pere Nubiola Radigales wrote:
> > It worked.
> > Pere Nubiola Radigales
> > Telf: +34 656316974
> > e-mail: p...@nubiola.cat 
> >pnubi...@fsfe.org 
> >pere.nubi...@gmail.com 
> >
>
> If moving ~/.FreeCAD worked, would you consider zipping up that
> directory and emailing it to me so I can try to reproduce the problem
> and fix it? There are likely other people experiencing it so something
> more than a workaround could benefit other users.
>

Bug#928372: ITP: golang-github-anacrolix-dms-dev -- a UPnP DLNA Digital Media Server that includes basic video transcoding

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: golang-github-anacrolix-dms-dev
  Version : 1.0.0
  Upstream Author : Matt Joiner 
* URL : https://github.com/anacrolix/dms
* License : BSD
  Programming Lang: Go
  Description : a UPnP DLNA Digital Media Server that includes basic video 
transcoding

dms is a UPnP DLNA Digital Media Server. It runs from the terminal,
and serves content directly from the filesystem from the working
directory, or the path given. The SSDP component will broadcast and
respond to requests on all available network interfaces.

dms advertises and serves the raw files, in addition to alternate
transcoded streams when it's able, such as mpeg2 PAL-DVD and WebM for
the Chromecast. It will also provide thumbnails where possible.

dms uses ffprobe/avprobe to get media data such as bitrate and
duration, ffmpeg/avconv for video transoding, and ffmpegthumbnailer
for generating thumbnails when browsing.


This package is required by latest versions of rclone (providing a new
dlna server).

Packaging will be managed under the Debian Go Packaging Team.

Bug#928371: evince: Doesn't restore previous position when opening pdf from New window

[Fabian Inostroza]

Package: evince
Version: 3.32.0-1
Severity: normal

Dear Maintainer,


Open some pdfs and move to any page different than the first.
Close evince.
Open any pdf then open a new evince window from the hamburger
menu and choose one of the previously opened pdfs.
They load at page 1, not at the previous page. If you open 
them from the file manager then the previous position is correctly
loaded.


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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evince-common3.32.0-1
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-8
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libevdocument3-4 3.32.0-1
ii  libevview3-3 3.32.0-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgnome-desktop-3-173.30.2.1-1
ii  libgtk-3-0   3.24.5-1
ii  libnautilus-extension1a  3.30.5-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libsecret-1-00.18.7-1
ii  shared-mime-info 1.10-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1

Versions of packages evince suggests:
ii  gvfs 1.38.1-3
ii  nautilus-sendto  3.8.6-3
ii  poppler-data 0.4.9-2
pn  unrar

-- no debconf information

Bug#928370: extra-cmake-modules: Should not recommend qt5-default

[Lisandro Damián Nicanor Pérez Meyer]

Source: extra-cmake-modules
Version: 5.54.0-1
Severity: important

The package recommends qt5-default as a wrong fix for the problem described in
the package's 654e1b98e48a614d4eedc48fb358813ed70fae75 commit (debian packagin).

Stuff using CMake should determine which version of Qt they will use, and thus
choose the right tools from there.

One could consider runtime calls, but adding an ecm dependency does not means
that the resulting binary will end up using the appropiate tool. Also the only
non-dev tool that might get called with this is qdbus, which is compatible.

Installing qt5-default will make the developer's machine default to qt5 except
manually overrided, which should never be the case except the user knows
*very* well what [s]he doing.

So please remove qt5-default as a recommendation.

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

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

-- no debconf information

Bug#928315: qtchooser: qdbus does not find qt5 qdbus

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 2 de mayo de 2019 22:02:36 -03 Stuart Prescott escribió:
> Control: tags -1 - unreproducible moreinfo
> Control: severity -1 normal
> 
> Hi all
> 
> Some updates to questions (combined into one reply for simplicity):
> > By default the qt4 version should be called except the user does something
> > to force the situation like installing qt5-default or passing -qt5
> > as argument or setting the environment variable you discovered above.
> 
> Ahh, now this rings a bell.
> 
> For some reason I cannot now recall (but was perhaps to do with changes in
> type marshalling?), I needed qdbus to call the qt5 version some years ago
> and created:
> 
> $ cat ~/.config/qtchooser/default.conf
> /usr/lib/x86_64-linux-gnu/qt5/bin
> /usr/lib/x86_64-linux-gnu
> 
> which works just fine under stretch but not under buster.
> 
> Deleting the file makes everything work just fine. Replacing it with the
> following also works fine:
> 
> /usr/lib/qt5/bin
> /usr/lib/x86_64-linux-gnu
> 
> So the cause of the problem was my config file and not a general problem
> (hence downgrading the severity).
> 
> There are some smaller bugs instead:
> 
> a) why does the old config file no longer work

Stuff was moved in order to support cross building IIRC. Dmitry knows better.
But definitely not a bug: we do reserve the right to move stuff around.
 
> b) when /usr/lib/x86_64-linux-gnu/qt5/bin is just a symlink farm to
> /usr/lib/ qt5/bin, why does one work and the other not?

Probably due to the algorithm inside qtchooser to detect symlinks:



Due to the changes done to allow cross building stuff with Qt it might detect 
a symlink to a symlink and thus fail.

> c) how can that rather useless error message be improved.

Can we? Qt 5 was not precisely designed to be used for cross building, and we 
are kind of stretching things here, so I guess a little bug per a huge 
advantage.

Moreover we will probably be able to get rid of qtchooser with qt6, or at 
least start ignoring it.
 
[snip] 
> qt4-default is not installed
> 
> qt5-default is installed:
> 
> $ apt list qt5-default
> qt5-default/testing,now 5.11.3+dfsg1-1 amd64 [installed,automatic]
> 
> $ aptitude why qt5-default
> i   extra-cmake-modules Recommends qt5-default

That's probably a bug. I still think creating qt?-default was a mistake :-/

-- 
If you have an apple and I have an apple and we exchange these apples then you
and I will still each have one apple. But if you have an idea and I have an
idea and we exchange these ideas, then each of us will have two ideas.
 George Bernard Shaw

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#928369: openjdk-11-jdk-headless: Broken symlink /usr/lib/jvm/java-11-openjdk-amd64/src.zip

[Ben Goodwin]

Package: openjdk-11-jdk-headless
Version: 11.0.3+1-1
Severity: normal



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

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

Versions of packages openjdk-11-jdk-headless depends on:
ii  libc62.28-8
ii  openjdk-11-jre-headless  11.0.3+1-1
ii  zlib1g   1:1.2.11.dfsg-1

openjdk-11-jdk-headless recommends no packages.

Versions of packages openjdk-11-jdk-headless suggests:
pn  openjdk-11-demo
ii  openjdk-11-source  11.0.3+1-1

-- no debconf information

The symlink installed by this package at
"/usr/lib/jvm/java-11-openjdk-amd64/src.zip" is set to
"../openjdk-11/src.zip" which is an invalid path. This is preventing
IDEs from finding and displaying javadoc. It seems that the src.zip file
was moved to "/usr/lib/jvm/openjdk-11/lib". Setting the symlink to
"../openjdk-11/lib/src.zip" solves this issue.

Bug#928315: qtchooser: qdbus does not find qt5 qdbus

[Stuart Prescott]

Control: tags -1 - unreproducible moreinfo
Control: severity -1 normal

Hi all

Some updates to questions (combined into one reply for simplicity):

> By default the qt4 version should be called except the user does something
> to force the situation like installing qt5-default or passing -qt5 
> as argument or setting the environment variable you discovered above. 

Ahh, now this rings a bell.

For some reason I cannot now recall (but was perhaps to do with changes in 
type marshalling?), I needed qdbus to call the qt5 version some years ago and 
created:

$ cat ~/.config/qtchooser/default.conf 
/usr/lib/x86_64-linux-gnu/qt5/bin
/usr/lib/x86_64-linux-gnu

which works just fine under stretch but not under buster.

Deleting the file makes everything work just fine. Replacing it with the 
following also works fine:

/usr/lib/qt5/bin
/usr/lib/x86_64-linux-gnu

So the cause of the problem was my config file and not a general problem 
(hence downgrading the severity). 

There are some smaller bugs instead: 

a) why does the old config file no longer work

b) when /usr/lib/x86_64-linux-gnu/qt5/bin is just a symlink farm to /usr/lib/
qt5/bin, why does one work and the other not?

c) how can that rather useless error message be improved. 

I have a feeling that (a) and (b) are linked and are probably packaging bugs.

> Please also check if you have any configuration file in /etc/xdg/qtchooser

nothing there

> > Do you have qt4-default or qt5-default installed? In case you do: did you
> > install it by hand or something else dragged it in? I have tried to
> > reproduce the issue with and without qt5-default installed without
> > success, so the issue might be somewhere else.
> 
> I would also like to know the version of qt5-default installed, and the
> contents of /usr/lib/x86_64-linux-gnu/qtchooser/default.conf file.

qt4-default is not installed

qt5-default is installed:

$ apt list qt5-default
qt5-default/testing,now 5.11.3+dfsg1-1 amd64 [installed,automatic]

$ aptitude why qt5-default
i   extra-cmake-modules Recommends qt5-default


cheers
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#483617: reassign

[devel]

Control: forwarded -1 https://github.com/munin-monitoring/munin/issues/1175
Control: tags -1 +fixed-upstream

Hello,


On Sat, 11 Feb 2012 10:40:28 +0100 Petter Reinholdtsen  wrote:
> Well, unless you can show me an example munin-node.conf file setting the
> reverse_lookups argument to Net::Server, I believe you are wrong.  I
> find no trace of any code in munin-node allowing the user to set this
> argument for Net::Server.  This make me convinced this issue need to be
> solved in munin-node, not Net::Server.

Yes, indeed the "reverse_lookups" argument is not passed to Net::Server at the
moment.


> One way to solve it would be to use the allow_deny_hook mechanism
> provided by Net::Server to look up connecting hosts using innetgr.
> Another and less flexible way would be to make it possible to set the
> reverse_lookups argument to Net::Server.

Allowing "reverse_lookups" is the easiest way forward.
But sadly Net::Server exposes two problems at the moment:
* CPAN #129377 [1]: no reverse DNS resolution if munin-node is bound to an IPv6
  socket (applicable for most hosts)
* CPAN #83909 [2] / Debian #702914 [3]: the reverse DNS name is not verified
  (it can easily be spoofed by anyone)

We just included the "reverse_lookups" setting upstream in commit 574d102b32 (to
be released as 2.0.48).
This should fix this issue as far as munin is converned. But the two issues with
Net::Server remain open.

Cheers,
Lars


[1] https://rt.cpan.org/Ticket/Display.html?id=129377
[2] https://rt.cpan.org/Public/Bug/Display.html?id=83909
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702914
[4] 
https://github.com/munin-monitoring/munin/commit/574d102b322b23da72e687c7cbe130d28f8fa8e2

Bug#928368: transition: papi

[Andreas Beckmann]

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

Hi,

I recently realized that libpapi5 (5.7.0-1) is not compatible with
applications built against papi 5.6 (or any other mismatching
major.minor version) due to the runtime checks performed in
PAPI_library_init() and the way this is to be called from applications.
Applications will abort after PAPI_library_init() returned an error and
require recompilation against the current version. (I ran into this
incompatibility myself.) #928367
Upstream confirmed that they only intend to maintain ABI compatibility
for major.minor.*.* releases, but not between different minor versions.
The soname therefore should have never been libpapi.so.major but rather
libpapi.so.major.minor

Patching out the check completely is non-trivial since it is some kind
of handshake beween caller and callee (app and lib). I'm pretty sure the
ABI has not changed between 5.5 (stretch) and 5.7, but I wouldn't put my
hand into the fire for it. And upstream has no way to track ABI
independently of major.minor version, given that the runtime check
exists for a long time already.
While I could patch papi to use version 5.6.99.99 internally instead of
5.7.0.0 to restore compatibility with the snapshot we had in buster
previously (only major.minor are being compared), this would still be
incompatible with programs built on stretch which had libpapi5 5.5.*

Given the limited amount of packages involved, I'd prefer to perform a
late but proper transition libpapi5 -> libpapi5.7 for buster.

# Depends:
eztrace: libeztrace0 [amd64 arm64 armel armhf i386 mips mips64el mipsel
ppc64el]

# Build-Depends:
eztrace: libpapi-dev
eztrace-contrib/contrib: libpapi-dev
mpqc3: libpapi-dev

Only one binNMU is needed. mpqc3 links statically (will fix post buster)
and eztrace-contrib probably shares the packaging with eztrace, and IIRC
only builds some addon modules.

If I had seen this coming, I would have done the transition in time for
the 5.6 snapshot we previously had and left 5.7 for bullseye.

Ben file:

title = "papi";
is_affected = .depends ~ "libpapi5" | .depends ~ "libpapi5.7";
is_good = .depends ~ "libpapi5.7";
is_bad = .depends ~ "libpapi5";

Bug#928367: libpapi5: SOVERSION is too wide for the runtime check in PAPI_library_init()

[Andreas Beckmann]

Source: papi
Version: 5.7.0-1
Severity: serious
Tags: upstream
Forwarded: 
https://groups.google.com/a/icl.utk.edu/forum/#!topic/perfapi-devel/Qgv4BpZl64U

applications built against libpapi5 (5.6.*-*) don't run with libpapi5
(5.7.*-*) (and vice versa and for all other mismatching major.minor
combinations as well) due to the runtime check in PAPI_library_init()
and the way PAPI_library_init() is to be called.

Andreas

Bug#928364: sbuild: autopkgtests should declare Restrictions: isolation-machine due to debootstrap

[Steve Langasek]

Package: sbuild
Version: 0.78.1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear maintainers,

In Ubuntu, we have patched sbuild to add an additional DEP8 restriction to
debian/tests/control, 'isolation-machine'.  The reason for this is that on
one architecture (armhf), Ubuntu runs all of its autopkgtests in lxd
containers rather than in VMs, and there the sbuild autopkgtest was failing
until we made this change because debootstrap is a container-unfriendly
privileged operation:

[...]
autopkgtest [15:35:00]: test build-procenv: [---
INFO: Creating sbuild chroot 'eoan-armhf-sbuild' for release 'eoan' in 
directory '/tmp/autopkgtest.VCrXM7/autopkgtest_tmp/schroot-eoan' from url 
'http://ports.ubuntu.com/ubuntu-ports'
mkdir /tmp/autopkgtest.VCrXM7/autopkgtest_tmp/schroot-eoan
mknod: /tmp/autopkgtest.VCrXM7/autopkgtest_tmp/schroot-eoan/test-dev-null: 
Operation not permitted
E: Cannot install into target 
'/tmp/autopkgtest.VCrXM7/autopkgtest_tmp/schroot-eoan' mounted with noexec or 
nodev
E: Error running debootstrap at /usr/bin/sbuild-createchroot line 381.
autopkgtest [15:35:03]: test build-procenv: ---]
autopkgtest [15:35:05]: test build-procenv:  - - - - - - - - - - results - - - 
- - - - - - -
build-procenvFAIL non-zero exit status 2
[...]

  (http://autopkgtest.ubuntu.com/packages/s/sbuild/cosmic/armhf)

It's best to be explicit that the tests must be run in a VM rather than a
container.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru sbuild-0.78.1/debian/tests/control sbuild-0.78.1/debian/tests/control
--- sbuild-0.78.1/debian/tests/control  2019-04-03 03:03:51.0 -0700
+++ sbuild-0.78.1/debian/tests/control  2019-04-03 09:12:01.0 -0700
@@ -1,3 +1,3 @@
 Tests: build-procenv
 Depends: @, debootstrap, distro-info, lsb-release, apt (>= 1.1~exp2), apt-utils
-Restrictions: needs-root
+Restrictions: needs-root, isolation-machine

Bug#928366: sbuild: Don't try to install packages from a different distro as part of autopkgtest

[Steve Langasek]

Package: sbuild
Version: 0.78.1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear maintainers,

The sbuild autopkgtest has the rather telling comment in it:

  # We should probably only attempt to install and run procenv if the release of
  # the build chroot is equal to the host, but lets be brave and try anyway

This results in autopkgtest failures for sbuild, any time the devel series
that is being test-built for generates newer libc dependencies than the
version of glibc present in the host environment.

Since Ubuntu routinely runs autopkgtests against stable releases as part of
CI for stable release updates, this results in autopkgtests that work fine
when a series is unreleased, and then regress at some later point because
the devel series has moved on.

We've applied the attached patch in Ubuntu to avoid this in the obvious
fashion.  Please consider applying in Debian as well.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru sbuild-0.78.1/debian/tests/build-procenv 
sbuild-0.78.1/debian/tests/build-procenv
--- sbuild-0.78.1/debian/tests/build-procenv2019-04-03 03:03:51.0 
-0700
+++ sbuild-0.78.1/debian/tests/build-procenv2019-04-03 09:12:01.0 
-0700
@@ -129,10 +129,7 @@
 echo "INFO: Extracting '$deb' to '$extract'"
 dpkg --extract "$deb" "$extract"
 
-# We should probably only attempt to install and run procenv if the release of
-# the build chroot is equal to the host, but lets be brave and try anyway
-if true
-#if [ "$release" = "$host_release" ]
+if [ "$release" = "$host_release" ]
 then
 echo "INFO: Installing package '$pkg' from '$deb'"
 apt -o Apt::Cmd::Disable-Script-Warning=1 -o APT::Get::Assume-Yes=1 
install "$(pwd)/$deb"

Bug#928365: dgit: more helpful error when --quilt=gbp but you meant --quilt=dpm?

[Colin Watson]

Source: dgit
Version: 8.4
Severity: wishlist

I did this in one of my packages
(https://salsa.debian.org/debian/spectemu
98b1b3de26fc9e7b5e857eeb5bf83d0d526c4001, if it matters):

  $ dgit -wn --quilt=gbp quilt-fixup
  Format `3.0 (quilt)', need to check/update patch stack
  examining quilt state (multiple patches, gbp mode)
  gzip: warning: GZIP environment variable is deprecated; use an alias or script
  dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
  dgit: base trees orig=b3aecce5e4a6e0caf8ae o+d/p=d27d28aa8170e9d16e66
  dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
  dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
  
  dgit: error: --quilt=gbp specified, implying patches-unapplied git tree
  dgit:  but git tree differs from orig in upstream files.
  dgit: For full diff showing the problem(s), type:
  dgit:  git diff b3aecce5e4a6e0caf8ae881a84e3c62de0507c23 HEAD -- :/ 
':!debian' ':!/.gitignore' ':!*/.gitignore'

On inspection of the diff I saw that it was basically just a combined
version of my debian/patches/ and so I was a bit confused for a few
minutes.  Actually the problem was that I'd retrieved this dgit command
line with C-r in bash and hadn't completely paid attention to the
--quilt option there, and this branch uses git-dpm and so is a
patches-applied branch.

dgit(1) tells me:

  If you have a branch like this it is essential to specify the
  appropriate --quilt= option!  This is because it is not always
  possible to tell: [...]

So I dutifully got into the habit of using a --quilt option, and I
understand that it makes sense for dgit to follow my explicit (if
incorrect) instruction.  However, in this case it *is* possible to tell,
at least with good probability: debian/.git-dpm exists, so --quilt=gbp
was probably a mistake.  Indeed, --quilt=dpm works fine.

I suggest that, at least, it would be helpful for dgit to notice the
situation where (1) there are quilt differences; (2) --quilt= was explicitly specified; (3) debian/.git-dpm exists.
It could then include something in the error message suggesting to the
user that they should probably omit --quilt= or use --quilt=dpm instead,
or something along those lines.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#928363: gau2grid: FTBFS if build directory contains "-D"

[Santiago Vila]

Package: src:gau2grid
Version: 1.3.1-1
Severity: serious
Tags: ftbfs patch

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch --with=python3 --buildsystem=pybuild
   dh_update_autotools_config -a -O--buildsystem=pybuild
   dh_autoreconf -a -O--buildsystem=pybuild
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure
I: pybuild base:217: python3.7 setup.py config 
running config
dh_auto_configure --buildsystem=cmake --\
-DCMAKE_BUILD_TYPE=Release  \
-DPYTHON_EXECUTABLE=/usr/bin/python3\
-DENABLE_XHOST=OFF
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 
-DENABLE_XHOST=OFF ..
-- The C compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Setting (unspecified) option MAX_AM: 8
-- Setting (unspecified) option SPHERICAL_ORDER: gaussian
-- Setting (unspecified) option CARTESIAN_ORDER: row
-- Setting option MAX_AM: 8
-- Setting option CMAKE_BUILD_TYPE: Release
-- Setting option ENABLE_XHOST: OFF
-- Setting (unspecified) option BUILD_FPIC: ON
-- Setting (unspecified) option BUILD_SHARED_LIBS: ON
-- Setting (unspecified) option ENABLE_GENERIC: OFF
-- Setting option CMAKE_INSTALL_LIBDIR: lib/x86_64-linux-gnu
-- Setting (unspecified) option PYMOD_INSTALL_LIBDIR: /
-- Setting (unspecified) option INSTALL_PYMOD: OFF
-- Setting (unspecified) option NATIVE_PYTHON_INSTALL: OFF
-- gau2grid install: /usr
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.3", 
minimum required is "2.7") 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.7m.so
-- Found Python 3.7: /usr/bin/python3 (found version 3.7.3)
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY


-- Build files have been written to: /<>/obj-x86_64-linux-gnu
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/c_wrapper.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/codegen.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/np_generator.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/docs_generator.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/python_reference.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/c_util_generator.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/RSH.py -> /<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/__init__.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/order.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/c_generator.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/c_pragma.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/_version.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/extras.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
copying gau2grid/utility.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid
creating /<>/.pybuild/cpython3_3.7/build/gau2grid/tests
copying gau2grid/tests/test_np_generator.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid/tests
copying gau2grid/tests/test_c_generator.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid/tests
copying gau2grid/tests/test_order.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid/tests
copying gau2grid/tests/test_c_code.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid/tests
copying gau2grid/tests/test_rsh.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid/tests
copying gau2grid/tests/__init__.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid/tests
copying gau2grid/tests/test_helper.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid/tests
copying gau2grid/tests/ref_basis.py -> 
/<>/.pybuild/cpython3_3.7/build/gau2grid/tests
running egg_info
creating gau2grid.egg-info
writing gau2grid.egg-info/PKG-INFO
writing dependency_links to gau2grid.egg-info/dependency_links.txt
writing requirements to gau2grid.egg-info/requires.txt
writing top-level names to gau2grid.egg-info/top_level.txt
writing manifest file 'gau2grid.egg-info/SOURCES.txt'
reading manifest file 

Bug#927329: Update Arduino from 1.8.2 to 1.8.9

[Kashif Shah]

>
> Absolutely, whatever is distributed must be built from source. I tried
> to reason why on this bug [1].
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922965#12


Understood - I do recall reading that before :)

So, it looks like there is a new dependency, ArduinoOTA (
https://github.com/esp8266/Arduino/tree/master/libraries/ArduinoOTA) that
would need to be built.  Should the ant script be modified to do this?

 I'm also no Java expert either, any help is welcome :)


The good news is that 1.8.9 (and the upcoming 1.8.10) builds from source
without issue after removing the pre-built gcc and avr binaries.  It still
uploaded a blink sketch, so hopefully I removed the pre-built binaries
correctly :D  Next step, I think, is to bring everything into the debian
package framework.  I'll let you know if I make any progress, there.

Best regards,
Kashif

On Wed, May 1, 2019 at 1:45 PM Rock Storm  wrote:

> On Wed, May 01, 2019 at 01:07:39PM -0500, Kashif Shah wrote:
> > @Rock Thanks for the update. My earlier attempt was with packaging the
> > binaries, which is a no-no, I take it?
>
> Absolutely, whatever is distributed must be built from source. I tried
> to reason why on this bug [1].
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922965#12
>
> > I made an attempt from scratch last
> > night, actually, after looking at the previous patches. I’ll continue
> with
> > it, but it will be slow going as I am not a Java dev by trade.
>
> I'm also no Java expert either, any help is welcome :)
>
> Cheers,
>
> --
> Rock Storm
> GPG KeyID: 4096R/C96832FD
> GPG Fingerprint:
>  C304 34B3 632C 464C 2FAF  C741 0439 CF52 C968 32FD
>

Bug#927317: Adding details to 927317

[JB]

Here is a screenshot of the screen right after login in.

For the record, I have a dual screen so the left part of the screenshot is the 
second monitor (not the primary) and I am using Nvidia proprietary driver 
(updating it does not change anything).

Bug#670585: "ok hat location is writable"

[Antoni Villalonga]

Hi,

I've found the message here:

/etc/rcS.d/S10checkfs.sh
124 log_success_msg "Done checking file systems. 
125 A log is being saved in ${FSCK_LOGFILE} if that location is writable."

I think the console width was 80 chars and it caused "if that location..."
message drop to next line. After that, "[ ok " message overwrited from the
beggining of the line, causing the anoying message.

If this problem is meant to be "fixed"?
Shorter messages (if any) may be the easy way.

Hope it helps,

-- 
Antoni Villalonga
http://friki.cat/

Bug#928362: Enable some kernel hardening by default

[john.pseudonym1]

Package: linux-image-amd64
Version: 4.19+104
Severity: important

Hi,

It would be great if Debian included some kernel hardening by default. These 
settings would offer great security benefits and no or very minimal performance 
decrease.

Setting “kernel.kptr_restrict=1” with sysctl makes kernel symbols in 
/proc/kallsyms only accessible to root which can make it more difficult for a 
kernel exploit to resolve addresses/symbols. Setting it to 2 hides the symbols 
regardless of privileges.

Setting “kernel.dmesg_restrict=1” with sysctl restricts access to the kernel 
logs which can give an attacker less information on what they can do.

Setting “kernel.unprivileged_bpf_disabled=1” and “net.core.bpf_jit_harden=2” 
with sysctl hardens the BPF JIT compiler and restricts it to root. It comes 
with a performance drop on systems that use the JIT compiler a lot but this 
should only really effect servers.

Setting “vm.mmap_rnd_bits=32” and “vm.mmap_rnd_compat_bits=16” with sysctl 
improves KASLR effectiveness for mmap. This might break some things but I 
haven't had anything break on me yet.

Adding “slab_nomerge” as a boot parameter may also be useful. slab_nomerge 
disables the merging of slabs of similar sizes. Sometimes a slab can be used in 
a vulnerable way which an attacker can exploit. This may have a slight increase 
in memory usage.

Mounting /proc with hidepid=2 in /etc/fstab will hide other users’ processes 
from unprivileged users. This makes it a lot harder for an attacker to get 
information about other running processes. Some processes (like systemd-logind) 
will break but you can add exceptions for them.

If Debian could include any of these by default then that would be great.

Best Regards.

Bug#928361: prometheus-bind-exporter: wrong package description

[Daniele Forsi]

Package: prometheus-bind-exporter
Severity: minor

Dear Maintainer,

the long package description for prometheus-bind-exporter is:
"Prometheus exporter for PostgreSQL server metrics, written in Go."
ie almost the same as prometheus-postgres-exporter.

Thanks,
Daniele

Bug#928360: performous: Parsing errors form second startup on

[Dominik George]

Package: performous
Version: 1.1+git20181118-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have a bunch of Singstar songs here, ripped with ss_extract.  Performous
works absolutely great with them, but only on first start.

 1. Start Performous
 2. Add the path with the SIngstar songs
 3. Play an arbitrary number of songs
 4. Exit Performous
 5. Start Performous again

After that, no osngs work, with the following error:

songparser/warning: /home/nik/performous-singstar/SingStar 80s/Modern Talking - 
Cheri Cheri Lady/notes.xml:
  Internal error: SongParser-xml vocalIt past the end

Removing ~/.config/performous and starting over again fixes the issue.

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages performous depends on:
ii  fonts-noto-mono 20181227-1
ii  libavcodec587:4.1.1-1
ii  libavformat58   7:4.1.1-1
ii  libavutil56 7:4.1.1-1
ii  libboost-filesystem1.67.0   1.67.0-13
ii  libboost-iostreams1.67.01.67.0-13
ii  libboost-locale1.67.0   1.67.0-13
ii  libboost-program-options1.67.0  1.67.0-13
ii  libboost-system1.67.0   1.67.0-13
ii  libc6   2.28-8
ii  libcairo2   1.16.0-4
ii  libcpprest2.10  2.10.13-1
ii  libepoxy0   1.5.3-0.1
ii  libfontconfig1  2.13.1-2
ii  libgcc1 1:8.3.0-6
ii  libglib2.0-02.58.3-1
ii  libglibmm-2.4-1v5   2.58.0-2
ii  libicu6363.1-6
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libpango-1.0-0  1.42.4-6
ii  libpangocairo-1.0-0 1.42.4-6
ii  libpng16-16 1.6.36-6
ii  libportaudio2   19.6.0-1
ii  libportmidi01:217-6
ii  librsvg2-2  2.44.10-2
ii  libsdl2-2.0-0   2.0.9+dfsg1-1
ii  libssl1.1   1.1.1b-2
ii  libstdc++6  8.3.0-6
ii  libswresample3  7:4.1.1-1
ii  libswscale5 7:4.1.1-1
ii  libxml++2.6-2v5 2.40.1-3

performous recommends no packages.

Versions of packages performous suggests:
pn  fretsonfire-songs-muldjord  
pn  fretsonfire-songs-sectoid   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKJBAEBCgBzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlzLXcAxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylt/DD/9rhYag
BnVMC58VMN5tY2eNZZI2ab//2jsdg+DGzZSmkbDD+/0QPZwLD8zj751Zxyp2lbLG
s0naT8L0CZ+AqTfJU6lFBfe0ypYswQDLmCFMk+dkw6FuDZDIVKhPvuwlXIgjbVm5
fXRqWxIZ6SOwgAsKbmh54hU0BEnjAsupVYKphXip+xv1xUsagj6l3lORAb+CpxMP
oAhR47N6Rh0vcw/asRPpMBhNWtHfQcMpeL+IhAgz0uYScyyOj47QXCczBqzjabzv
hRpLsRejw1FlqfzGkzbgAmVh/+iOBWQ4kFf9cmdXW5JQtfdfFBIom41R+m2RnKuO
jVWajf7eILkQyWZqBcw8Xm7QMF5otzYvTwwHrG/wqBnjWnq6qsIp+qQDfvDdGdlQ
OVy971EacU9jntYBVLbvQVTOdO9EbinZcv/OfqfVXtxbvEBqt7oEMrrsH6KseK+C
wamrt5tJSNLQCaKVNy2HW6vpbzcfBAnkGD+yD4wgSgFPm/yxE8NCG/5IMfXDHGX1
FmyN0CFp4fXRa8lkVnxMqPinnB1P5Qg/Z7YFk+vQCSM/tNcKLDNsKpVNKXWigo7v
uu4hZuM8yZrcDypkaKgDJwW8sEjzoNnjOLaY2yjqDU2GTMdvTnQWxxsDBdNECCgj
6SXP6oHkfyyVsFxzrtAbEjjQDgmZ/mRgMkyvOA==
=9qvX
-END PGP SIGNATURE-

Bug#925509: netbeans: Netbeans not usable with java in Buster

[Jochen Sprickerhof]

* Markus Koschany  [2019-05-02 21:08]:

I had a look into this was able to create new projects when I remove the
nb-javac.patch. @Markus do we really need it?


The nb-javac patch is necessary, otherwise the nb-javac module is not
properly detected at runtime. You should see an error message when you
start Netbeans for the first time then. Did you remove ~/.netbeans and
~/.cache/netbeans before you installed the version without the patch? I
believe you are on the right track though.


Yes I see the error as well. But from #920707 I didn't get what function 
will be missing with the error.


The other option is to fix the nb-javac-9-(api|impl).jar. Starting the 
upstream version of netbeans results in the same error for nb-javac and 
let's you download ~/.netbeans/10.0/modules/ext/nb-javac-(api|impl).jar. 
Placing those in /usr/share/netbeans/java5/modules/ext (and renaming 
them), results in a working Netbeans for me as well. There are some 
classes missing in the Debian jars, do you know how to get them compiled 
in? (I can have a look what exactly tomorrow).


Cheers Jochen


signature.asc
Description: PGP signature

Bug#928315: qtchooser: qdbus does not find qt5 qdbus

[Dmitry Shachnev]

Hi all,

On Thu, May 02, 2019 at 12:34:14AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Do you have qt4-default or qt5-default installed? In case you do: did you
> install it by hand or something else dragged it in? I have tried to reproduce
> the issue with and without qt5-default installed without success, so the issue
> might be somewhere else.

I would also like to know the version of qt5-default installed, and the
contents of /usr/lib/x86_64-linux-gnu/qtchooser/default.conf file.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#928359: unblock: atftp/0.7.git20120829-3.1

[Salvatore Bonaccorso]

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

Hi,

Please unblock package atftp

It fixes two set of vulnerabilities found by Denis Andzakovic[1],
CVE-2019-11365, CVE-2019-11366 and tracked in the BTS as #927553. The
upload to unstable cherry-picks the two upstream commits.

+atftp (0.7.git20120829-3.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix concurrency issue denial of service (CVE-2019-11366) (Closes: #927553)
+  * Fix error handler stack overflow (CVE-2019-11365) (Closes: #927553)
+
+ -- Salvatore Bonaccorso   Mon, 29 Apr 2019 19:37:52 +0200

Attached is the debdiff between the version in testing and the
uploaded version in unstable.

unblock atftp/0.7.git20120829-3.1

Regards,
Salvatore

 [1] https://pulsesecurity.co.nz/advisories/atftpd-multiple-vulnerabilities
diff -u atftp-0.7.git20120829/debian/changelog 
atftp-0.7.git20120829/debian/changelog
--- atftp-0.7.git20120829/debian/changelog
+++ atftp-0.7.git20120829/debian/changelog
@@ -1,3 +1,11 @@
+atftp (0.7.git20120829-3.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix concurrency issue denial of service (CVE-2019-11366) (Closes: #927553)
+  * Fix error handler stack overflow (CVE-2019-11365) (Closes: #927553)
+
+ -- Salvatore Bonaccorso   Mon, 29 Apr 2019 19:37:52 +0200
+
 atftp (0.7.git20120829-3) unstable; urgency=medium
 
   * Ack previous NMU
diff -u atftp-0.7.git20120829/tftpd_file.c atftp-0.7.git20120829/tftpd_file.c
--- atftp-0.7.git20120829/tftpd_file.c
+++ atftp-0.7.git20120829/tftpd_file.c
@@ -304,9 +304,7 @@
  else
   logger(LOG_WARNING, "source port mismatch, check 
bypassed");
 }
-Strncpy(string, tftphdr->th_msg,
-(((data_size - 4) > MAXLEN) ? MAXLEN :
- (data_size - 4)));
+Strncpy(string, tftphdr->th_msg, sizeof(string));
 if (data->trace)
  logger(LOG_DEBUG, "received ERROR ",
 ntohs(tftphdr->th_code), string);
@@ -954,9 +952,7 @@
  }
 }
 /* Got an ERROR from the current master client */
-Strncpy(string, tftphdr->th_msg,
-(((data_size - 4) > MAXLEN) ? MAXLEN :
- (data_size - 4)));
+Strncpy(string, tftphdr->th_msg, sizeof(string));
 if (data->trace)
  logger(LOG_DEBUG, "received ERROR ",
 ntohs(tftphdr->th_code), string);
diff -u atftp-0.7.git20120829/tftpd_list.c atftp-0.7.git20120829/tftpd_list.c
--- atftp-0.7.git20120829/tftpd_list.c
+++ atftp-0.7.git20120829/tftpd_list.c
@@ -49,11 +49,11 @@
  */
 int tftpd_list_add(struct thread_data *new)
 {
+ pthread_mutex_lock(_list_mutex);
+
  struct thread_data *current = thread_data;
  int ret;
 
- pthread_mutex_lock(_list_mutex);
-
  number_of_thread++;
  
  ret = number_of_thread;
@@ -81,11 +81,11 @@
  */
 int tftpd_list_remove(struct thread_data *old)
 {
+ pthread_mutex_lock(_list_mutex);
+
  struct thread_data *current = thread_data;
  int ret;
 
- pthread_mutex_lock(_list_mutex);
-
  number_of_thread--;
  ret = number_of_thread;
 
@@ -137,6 +137,9 @@
  struct thread_data *data,
  struct client_info *client)
 {
+ /* lock the whole list before walking it */
+ pthread_mutex_lock(_list_mutex);
+
  struct thread_data *current = thread_data; /* head of the list */
  struct tftp_opt *tftp_options = data->tftp_options;
  struct client_info *tmp;
@@ -152,7 +155,4 @@
  len = (int)((unsigned long)index - (unsigned long)options);
 
- /* lock the whole list before walking it */
- pthread_mutex_lock(_list_mutex);
-
  while (current)
  {
@@ -214,9 +214,9 @@
 void tftpd_clientlist_remove(struct thread_data *thread,
  struct client_info *client)
 {
+ pthread_mutex_lock(>client_mutex);
  struct client_info *tmp = thread->client_info;
 
- pthread_mutex_lock(>client_mutex);
  while ((tmp->next != client) && (tmp->next != NULL))
   tmp = tmp->next;
  if (tmp->next == NULL)
@@ -230,10 +230,11 @@
  */
 void tftpd_clientlist_free(struct thread_data *thread)
 {
+ pthread_mutex_lock(>client_mutex);
+
  struct client_info *tmp;
  struct client_info *head = thread->client_info;
 
- pthread_mutex_lock(>client_mutex);
  while (head)
  {
   tmp = head;
@@ -250,10 +251,10 @@
   struct client_info *client,
   struct sockaddr_storage *sock)
 {
- struct client_info *head = thread->client_info;
-
  

Bug#881771: Unclear which interface name will be used

[Paul Gevers]

Hi,

On 24-04-2019 12:18, Justin B Rye wrote:
>  
>This should give enough information to devise a migration plan.
>(If the udevadm output includes an
>onboard name, that takes priority; MAC-based names
>are normally treated as a fallback, but may be needed for USB
>network hardware.)
>  

Pushed in commit ed066ff.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

[Uwe Kleine-König]

Hello,

On Tue, Apr 30, 2019 at 10:12:27AM +0200, Uwe Kleine-König wrote:
> On Thu, Apr 25, 2019 at 09:17:32PM +0200, Aurelien Jarno wrote:
> > On 2019-04-25 14:50, Aurelien Jarno wrote:
> > > On 2019-04-23 22:16, Aurelien Jarno wrote:
> > > > Source: linux
> > > > Version: 4.19.28-2
> > > > Severity: important
> > > > 
> > > > After upgrading hartmann.debian.org (an armhf buildd using an Armada XP
> > > > GP board) from buster to stretch, the ethernet device is not working
> 
> "upgrading from buster to stretch" doesn't make sense. I think you meant
> from stretch to buster.
> 
> > > 
> > > More precisely the board is a "Marvell Armada XP Development Board
> > > DB-MV784MP-GP"
> > > 
> > > > anymore. Using tcpdump on both the buildd and a remote host, it appears
> > > > that the packets correctly leave the board and that the reception side
> > > > fails.
> 
> If you can send to a remote host at least ARP (or ND) must be working,
> so some reception still works, right?
> 
> > > > The module used for the ethernet device is mvneta. The corresponding DT
> > > > compatible entry is "marvell,armada-xp-neta".
> > > >
> > > 
> > > I have started a "bisection" with the kernels from snapshot. This is
> > > what I have found so far:
> > > 
> > > This one works:
> > > - linux-image-4.19.0-rc6-armmp-lpae_4.19~rc6-1~exp1_armhf.deb 
> > > 
> > > The following ones don't:
> > > - linux-image-4.19.0-rc7-armmp-lpae_4.19~rc7-1~exp1_armhf.deb
> > > - linux-image-5.0.0-trunk-armmp_5.0.2-1~exp1_armhf.deb
> > > 
> > > My guess (I don't have time to try more now) is that the issue is caused
> > > by the following change:
> > > 
> > > |  [ Uwe Kleine-König ]
> > > |  * [armhf] enable MVNETA_BM_ENABLE and CAN_FLEXCAN as a module
> > > 
> > 
> > I confirm this is the issue. Disabling MVNETA_BM_ENABLE on kernel 
> > 4.19.28-2 fixes the issue. Note that it breaks the ABI.
> 
> A colleague happens to work with an XP based machine with a (nearly)
> vanilla kernel based on 5.1.0-rc6 and there enabling MVNETA_BM_ENABLE
> doesn't render networking nonfunctional.
> 
> Looking through the changes to drivers/net/ethernet/marvell/mvneta*
> between 5.0 and 5.1-rc6 there isn't something that would explain a fix
> though. There doesn't seem to be a good explanation in the debian
> specific patches either.
> 
> So this problem is either machine specific or it works with the mvneta
> driver builtin. (I didn't double check, but guess that my colleague uses
> =y and the Debian kernel =m). Well, or I missed something.
> 
> Is it possible to test a few things on hartmann? I'd suggest:
> 
>  - try (vanilla) 5.1-rc6 with MVNETA=y
>  - try an older kernel (maybe 4.6 as the buffer manager stuff was
>introduced in dc35a10f68d3 ("net: mvneta: bm: add support for
>hardware buffer management") which made it into 4.6-rc1) with
>MVNETA_BM_ENABLE=[ym].

Thanks to Steve McIntyre I got access to a DB-MV784MP-GP and did the
second test. I used mvebu_v7_defconfig and enabled CGROUPS and AUTOFS4
(to please systemd) and MVNETA_BM_ENABLE=y on 4.6. The latter breaks
networking similar to newer kernel versions.

So I guess the buffer management never worked on that board.

I don't have the time to debug this issue further, but will disable
buffer management for the Debian kernel again.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#928231: unblock: python-sievelib/1.1.1-2

[Paul Gevers]

tags -1 moreinfo

Hi Michael,

On 30-04-2019 14:21, Michael Fladischer wrote:
> It had a missing dependency on python(3)-pkg-resources. 1.1.1-2 adds those
> missing packages to Depends, see attached debdiff.

This would be OK for an unblock, but... your debdiff only shows the
changes between 1.1.1-1 and 1.1.1-2. However, what counts is the delta
between unstable and testing. I believe the bug you are fixing here is
bug #922343, but that is marked as only affecting the version in
unstable, so it doesn't need to be fixed for buster. There are changes
in the previous upload that are not matching the freeze policy [1],
like: new upstream release and debhelper compat level bump. So, do you
still need to get this fix in, then please fix the meta data of the bug
you are trying to fix to have the right version information. Then we can
discuss how to improve the package to be eligible for an unblock.

[1] https://release.debian.org/buster/freeze_policy.html

Paul



signature.asc
Description: OpenPGP digital signature

Bug#914398: git-branchmove: does not respect insteadOf, pushInsteadOf git configuration keys

[Ian Jackson]

Sean Whitton writes ("Bug#914398: git-branchmove: does not respect insteadOf, 
pushInsteadOf git configuration keys"):
> On Thu 22 Nov 2018 at 09:39PM -07, Sean Whitton wrote:
> > git-branchmove ignores the git configuration keys insteadOf and
> > pushInsteadOf.
> 
> Beginnings of a fix (untested):

Hi.  I'm not sure why are are treating these two cases so differently.
The purpose the case statement is solely to try to avoid calling "git
config" on things which are not remote names.

But in both cases we want pushInsteadOf if there is one, I think ?
(Ie, even for the source branch and even when it's not a configured
remote.)  Is that possible DYK ?

Hrm.  I tried git-ls-remote and it doesn't seem to have a --push.  And
git-remote doesn't work on things that aren't configured remotes.

Is that what you meant by "Beginnings of" ?

Regards,
Ian.

Bug#925509: netbeans: Netbeans not usable with java in Buster

[Markus Koschany]

Hi,

Am 02.05.19 um 20:56 schrieb Jochen Sprickerhof:
[...]
> I had a look into this was able to create new projects when I remove the
> nb-javac.patch. @Markus do we really need it?

The nb-javac patch is necessary, otherwise the nb-javac module is not
properly detected at runtime. You should see an error message when you
start Netbeans for the first time then. Did you remove ~/.netbeans and
~/.cache/netbeans before you installed the version without the patch? I
believe you are on the right track though.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#927348: unblock: salt/2018.3.4+dfsg1-2

[Paul Gevers]

Control: tags -1 moreinfo

Hi Benjamin,

On Thu, 18 Apr 2019 13:01:31 +0200 Benjamin Drung
 wrote:
> This version fixes the test_xen_virtual test case (bug #922352) and
> exposes tornado4 as tornado for zmq.eventloop.ioloop (bug #924763). Our
> salt 2018.3.3+dfsg1-1 package introduced a big patch to use
> python3-tornado4 (instead of python3-tornado) due to missing support for
> tornado version 5. Without the fix for #924763, zmq.eventloop.ioloop
> will import tornado version 5 (if python3-tornado is installed).

Both bugs have severity normal. Do you really want to bother now or is
the severity not correct (then please fix that and elaborate)?

> I also included fix-various-spelling-mistakes.patch which fixes several
> spelling mistakes. Because this patch file is long, I excluded it from the
> attached debdiff.

Bugs can be introduced that way. I am not going to review that diff,
fixing spelling mistakes at this moment isn't appropriate unless these
mistakes are crucial somewhere.

> This version also switches from the a pre-release git snapshot to the
> official 2018.3.4 release. The only difference between this snapshot and
> the release are two commits ("Fix ssh on Windows" and "Update url to
> libsodium for mac builds") and that the release tarball ships less files
> than what can be found in git.

If that was all (salt/modules/ssh.py and
tests/integration/modules/test_ssh.py), I could except it. But with less
files, there is also a changes that ...

> For that reason, the attached debdiff is created with this command:
> 
> debdiff --exclude fix-various-spelling-mistakes.patch
> salt_2018.3.4~git20180207+dfsg1-1.dsc salt_2018.3.4+dfsg1-2.dsc |
> filterdiff -i '*/debian/*' -i '*/tests/*/test_ssh.py' -i
> '*/salt/modules/ssh.py' -i '*/pkg/osx/build_env.sh' >
> salt_2018.3.4+dfsg1-2.debdiff
> 
> Alternatively this more simple git diff command could be used:
> 
> git diff --diff-filter=ACM
> debian/2018.3.4_git20180207+dfsg1-1..debian/2018.3.4+dfsg1-2
> 
> You can also look at all the individual commits on salsa:
> https://salsa.debian.org/salt-team/salt/compare/debian%2F2018.3.4_git20180207+dfsg1-1...debian%2F2018.3.4+dfsg1-2
> 
> All 7575 unittest succeeded and I successfully tested this new salt
> version on Debian unstable with our production environment setup
> (running the highstate on a salt minion connected to the salt master).
> 
> unblock salt/2018.3.4+dfsg1-2

You didn't even elaborate on all the (at this phase of the release
inappropriate) changes to the packaging. There is even a newer version
than the one you already mention in a follow up in this bug.

I am not going to unblock this package, and seen the amount of time your
request stayed open and the proposed changes, I don't think my
colleagues are tempted either. I see that salt is marked for
autoremoval. I suggest you aim for a targeted fix.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#925509: netbeans: Netbeans not usable with java in Buster

[Jochen Sprickerhof]

Hi,

* Markus Koschany  [2019-04-02 22:43]:

Hello Jaroslav,

On Mon, 01 Apr 2019 09:03:31 +0200 Jaroslav Tulach
 wrote:
[...]

Hello Markus,
it would be better to have a whole NetBeans log file instead of just the stack
trace. Then we could see classpath, list of enabled modules and may be deduce
more.

Best regards.
-jt


I think it's easy to reproduce. Just try to create a new Java project
with the Debian package. I believe this could be related to the removal
of langtools-9.zip in Debian. This is yet another file which is
downloaded at build-time. As far as I understand it, it is required to
build certain classes of Netbeans with the older OpenJDK 9 API. If I
include this file and remove the Debian specific langtools-9.patch I get
more compile errors later on. The build log is attached. It looks like
an error in src:libnb-platform18-java too. Netbeans depends on the
platform packages built by this source package.


I had a look into this was able to create new projects when I remove the 
nb-javac.patch. @Markus do we really need it?


Cheers Jochen


signature.asc
Description: PGP signature

Bug#554444: Ping?

[Diederik de Haas]

I just tried to install a Buster system with cdebootstrap(-static) and that 
fails because this bug is not fixed.
According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904699#15, 
increasing READSIZE from 16384 to 65536 'fixes' it.

I agree that 65536 is also just a random number, but so late in the freeze it 
may be warranted to do it, so cdebootstrap becomes usable for Buster.

This seems RC to me, but I let it up to the maintainers to actually do that.

Cheers,
  Diederik

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

Bug#914398: git-branchmove: does not respect insteadOf, pushInsteadOf git configuration keys

[Sean Whitton]

Hello,

On Thu 22 Nov 2018 at 09:39PM -07, Sean Whitton wrote:

> git-branchmove ignores the git configuration keys insteadOf and
> pushInsteadOf.

Beginnings of a fix (untested):

diff --git a/scripts/git-branchmove b/scripts/git-branchmove
index 5751c38..e315884 100755
--- a/scripts/git-branchmove
+++ b/scripts/git-branchmove
@@ -27,12 +27,12 @@ remote="$1"; shift
 #  transfer and merge reflog(s) xxx todo
 #  delete src refs

+# call to git-ls-remote expands any user insteadOf git config
+# call to `git remote get-url` expands both insteadOf and pushInsteadOf
 case "$remote" in
-*:*)   remoteurl="$remote" ;;
+*:*)   remoteurl="$(git ls-remote --get-url "$remote")" ;;
 [/.]*) remoteurl="$remote" ;;
-*) remoteurl="$(
-   git config remote."$remote".pushurl ||
-   git config remote."$remote".url ||
+*) remoteurl="$(git remote get-url --push "$remote" ||
fail "no pushurl or url defined for remote $remote"
)"
remotename="$remote"

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#926500: freecad: FreeCad crashes when attemting to edit a existing sketch

[Kurt Kremitzki]

Hi Pere,

On 5/2/19 2:28 AM, Pere Nubiola Radigales wrote:
> It worked. 
> Pere Nubiola Radigales
> Telf: +34 656316974
> e-mail: p...@nubiola.cat 
>            pnubi...@fsfe.org 
>            pere.nubi...@gmail.com 
> 

If moving ~/.FreeCAD worked, would you consider zipping up that
directory and emailing it to me so I can try to reproduce the problem
and fix it? There are likely other people experiencing it so something
more than a workaround could benefit other users.

Bug#928358: vdr: VDR ist started before DVB device is ready

[Helmar Gerloni]

Package: vdr
Version: 2.4.0-1+b1
Severity: normal
Tags: patch

Dear Maintainer,

during system startup VDR is mostly started before the DVB device is ready (USB 
Hauppauge WinTV-dualHD DVB). VDR then exits with an error. You can see this in 
/var/log/messages:

Apr 30 20:51:21 cslbox vdr: [473] VDR version 2.4.0 started
Apr 30 20:51:21 cslbox vdr: [473] switched to user 'vdr'
Apr 30 20:51:21 cslbox vdr: [473] codeset is 'UTF-8' - known
Apr 30 20:51:21 cslbox vdr: [473] loading plugin: 
/usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.4.0
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/setup.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/sources.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/diseqc.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/scr.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/channels.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/commands.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/reccmds.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/svdrphosts.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/keymacros.conf
Apr 30 20:51:21 cslbox vdr: [473] no DVB device found
Apr 30 20:51:21 cslbox vdr: [473] initializing plugin: vnsiserver (1.6.0): 
VDR-Network-Streaming-Interface (VNSI) Server
Apr 30 20:51:21 cslbox vdr: [473] deleting plugin: vnsiserver
Apr 30 20:51:21 cslbox vdr: [473] exiting, exit code 2
Apr 30 20:51:22 cslbox kernel: [7.745194] em28xx 1-2:1.0: EEPROM ID = 26 00 
01 00, EEPROM hash = 0x36e7cbc8
Apr 30 20:51:22 cslbox kernel: [7.745199] em28xx 1-2:1.0: EEPROM info:
Apr 30 20:51:22 cslbox kernel: [7.745202] em28xx 1-2:1.0:   microcode start 
address = 0x0004, boot configuration = 0x01
Apr 30 20:51:22 cslbox kernel: [7.751972] em28xx 1-2:1.0:   AC97 audio (5 
sample rates)
Apr 30 20:51:22 cslbox kernel: [7.751978] em28xx 1-2:1.0:   500mA max power
Apr 30 20:51:22 cslbox kernel: [7.751983] em28xx 1-2:1.0:   Table at offset 
0x27, strings=0x0e6a, 0x1888, 0x087e
Apr 30 20:51:22 cslbox kernel: [7.810633] em28xx 1-2:1.0: Identified as 
Hauppauge WinTV-dualHD DVB (card=99)
Apr 30 20:51:22 cslbox kernel: [7.816201] tveeprom: Hauppauge model 204109, 
rev B3I6, serial# 13908624
Apr 30 20:51:22 cslbox kernel: [7.816208] tveeprom: tuner model is SiLabs 
Si2157 (idx 186, type 4)
Apr 30 20:51:22 cslbox kernel: [7.816212] tveeprom: TV standards PAL(B/G) 
NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
Apr 30 20:51:22 cslbox kernel: [7.816215] tveeprom: audio processor is None 
(idx 0)
Apr 30 20:51:22 cslbox kernel: [7.816217] tveeprom: has no radio, has IR 
receiver, has no IR transmitter
Apr 30 20:51:22 cslbox kernel: [7.816228] em28xx 1-2:1.0: dvb ts2 set to 
isoc mode.
Apr 30 20:51:22 cslbox kernel: [8.015316] usbcore: registered new interface 
driver em28xx
Apr 30 20:51:22 cslbox kernel: [8.175093] em28xx 1-2:1.0: Binding DVB 
extension
Apr 30 20:51:22 cslbox kernel: [8.185623] i2c i2c-7: Added multiplexed i2c 
bus 10
Apr 30 20:51:22 cslbox kernel: [8.185628] si2168 7-0064: Silicon Labs 
Si2168-B40 successfully identified
Apr 30 20:51:22 cslbox kernel: [8.185630] si2168 7-0064: firmware version: 
B 4.0.2
Apr 30 20:51:22 cslbox kernel: [8.194254] si2157 10-0060: Silicon Labs 
Si2147/2148/2157/2158 successfully attached
Apr 30 20:51:22 cslbox kernel: [8.194693] dvbdev: DVB: registering new 
adapter (1-2:1.0)
Apr 30 20:51:22 cslbox kernel: [8.194702] em28xx 1-2:1.0: DVB: registering 
adapter 0 frontend 0 (Silicon Labs Si2168)...
Apr 30 20:51:22 cslbox kernel: [8.198994] em28xx 1-2:1.0: DVB extension 
successfully initialized
Apr 30 20:51:22 cslbox kernel: [8.199000] em28xx 1-2:1.0: Binding DVB 
extension
Apr 30 20:51:22 cslbox kernel: [8.205710] i2c i2c-9: Added multiplexed i2c 
bus 11
Apr 30 20:51:22 cslbox kernel: [8.205716] si2168 9-0067: Silicon Labs 
Si2168-B40 successfully identified
Apr 30 20:51:22 cslbox kernel: [8.205718] si2168 9-0067: firmware version: 
B 4.0.2
Apr 30 20:51:22 cslbox kernel: [8.211156] si2157 11-0063: Silicon Labs 
Si2147/2148/2157/2158 successfully attached
Apr 30 20:51:22 cslbox kernel: [8.211201] dvbdev: DVB: registering new 
adapter (1-2:1.0)
Apr 30 20:51:22 cslbox kernel: [8.211214] em28xx 1-2:1.0: DVB: registering 
adapter 1 frontend 0 (Silicon Labs Si2168)...
Apr 30 20:51:22 cslbox kernel: [8.212526] em28xx 1-2:1.0: DVB extension 
successfully initialized
Apr 30 20:51:22 cslbox kernel: [8.212531] em28xx: Registered (Em28xx dvb 
Extension) extension
Apr 30 20:51:22 cslbox kernel: [8.225141] r8169 :01:00.0: firmware: 
direct-loading firmware rtl_nic/rtl8168g-2.fw
Apr 30 20:51:22 cslbox kernel: [8.225385] Generic PHY r8169-100:00: 
attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-100:00, irq=IGNORE)
Apr 30 20:51:22 cslbox kernel: [8.226573] em28xx 1-2:1.0: Registering input 
extension
Apr 

Bug#928357: vdr: VDR ist started before DVB device is ready

[Helmar Gerloni]

Package: vdr
Version: 2.4.0-1+b1
Severity: normal
Tags: patch

Dear Maintainer,

during system startup VDR is mostly started before the DVB device is ready (USB 
Hauppauge WinTV-dualHD DVB). VDR then exits with an error. You can see this in 
/var/log/messages:

Apr 30 20:51:21 cslbox vdr: [473] VDR version 2.4.0 started
Apr 30 20:51:21 cslbox vdr: [473] switched to user 'vdr'
Apr 30 20:51:21 cslbox vdr: [473] codeset is 'UTF-8' - known
Apr 30 20:51:21 cslbox vdr: [473] loading plugin: 
/usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.4.0
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/setup.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/sources.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/diseqc.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/scr.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/channels.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/commands.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/reccmds.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/svdrphosts.conf
Apr 30 20:51:21 cslbox vdr: [473] loading /var/lib/vdr/keymacros.conf
Apr 30 20:51:21 cslbox vdr: [473] no DVB device found
Apr 30 20:51:21 cslbox vdr: [473] initializing plugin: vnsiserver (1.6.0): 
VDR-Network-Streaming-Interface (VNSI) Server
Apr 30 20:51:21 cslbox vdr: [473] deleting plugin: vnsiserver
Apr 30 20:51:21 cslbox vdr: [473] exiting, exit code 2
Apr 30 20:51:22 cslbox kernel: [7.745194] em28xx 1-2:1.0: EEPROM ID = 26 00 
01 00, EEPROM hash = 0x36e7cbc8
Apr 30 20:51:22 cslbox kernel: [7.745199] em28xx 1-2:1.0: EEPROM info:
Apr 30 20:51:22 cslbox kernel: [7.745202] em28xx 1-2:1.0:   microcode start 
address = 0x0004, boot configuration = 0x01
Apr 30 20:51:22 cslbox kernel: [7.751972] em28xx 1-2:1.0:   AC97 audio (5 
sample rates)
Apr 30 20:51:22 cslbox kernel: [7.751978] em28xx 1-2:1.0:   500mA max power
Apr 30 20:51:22 cslbox kernel: [7.751983] em28xx 1-2:1.0:   Table at offset 
0x27, strings=0x0e6a, 0x1888, 0x087e
Apr 30 20:51:22 cslbox kernel: [7.810633] em28xx 1-2:1.0: Identified as 
Hauppauge WinTV-dualHD DVB (card=99)
Apr 30 20:51:22 cslbox kernel: [7.816201] tveeprom: Hauppauge model 204109, 
rev B3I6, serial# 13908624
Apr 30 20:51:22 cslbox kernel: [7.816208] tveeprom: tuner model is SiLabs 
Si2157 (idx 186, type 4)
Apr 30 20:51:22 cslbox kernel: [7.816212] tveeprom: TV standards PAL(B/G) 
NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
Apr 30 20:51:22 cslbox kernel: [7.816215] tveeprom: audio processor is None 
(idx 0)
Apr 30 20:51:22 cslbox kernel: [7.816217] tveeprom: has no radio, has IR 
receiver, has no IR transmitter
Apr 30 20:51:22 cslbox kernel: [7.816228] em28xx 1-2:1.0: dvb ts2 set to 
isoc mode.
Apr 30 20:51:22 cslbox kernel: [8.015316] usbcore: registered new interface 
driver em28xx
Apr 30 20:51:22 cslbox kernel: [8.175093] em28xx 1-2:1.0: Binding DVB 
extension
Apr 30 20:51:22 cslbox kernel: [8.185623] i2c i2c-7: Added multiplexed i2c 
bus 10
Apr 30 20:51:22 cslbox kernel: [8.185628] si2168 7-0064: Silicon Labs 
Si2168-B40 successfully identified
Apr 30 20:51:22 cslbox kernel: [8.185630] si2168 7-0064: firmware version: 
B 4.0.2
Apr 30 20:51:22 cslbox kernel: [8.194254] si2157 10-0060: Silicon Labs 
Si2147/2148/2157/2158 successfully attached
Apr 30 20:51:22 cslbox kernel: [8.194693] dvbdev: DVB: registering new 
adapter (1-2:1.0)
Apr 30 20:51:22 cslbox kernel: [8.194702] em28xx 1-2:1.0: DVB: registering 
adapter 0 frontend 0 (Silicon Labs Si2168)...
Apr 30 20:51:22 cslbox kernel: [8.198994] em28xx 1-2:1.0: DVB extension 
successfully initialized
Apr 30 20:51:22 cslbox kernel: [8.199000] em28xx 1-2:1.0: Binding DVB 
extension
Apr 30 20:51:22 cslbox kernel: [8.205710] i2c i2c-9: Added multiplexed i2c 
bus 11
Apr 30 20:51:22 cslbox kernel: [8.205716] si2168 9-0067: Silicon Labs 
Si2168-B40 successfully identified
Apr 30 20:51:22 cslbox kernel: [8.205718] si2168 9-0067: firmware version: 
B 4.0.2
Apr 30 20:51:22 cslbox kernel: [8.211156] si2157 11-0063: Silicon Labs 
Si2147/2148/2157/2158 successfully attached
Apr 30 20:51:22 cslbox kernel: [8.211201] dvbdev: DVB: registering new 
adapter (1-2:1.0)
Apr 30 20:51:22 cslbox kernel: [8.211214] em28xx 1-2:1.0: DVB: registering 
adapter 1 frontend 0 (Silicon Labs Si2168)...
Apr 30 20:51:22 cslbox kernel: [8.212526] em28xx 1-2:1.0: DVB extension 
successfully initialized
Apr 30 20:51:22 cslbox kernel: [8.212531] em28xx: Registered (Em28xx dvb 
Extension) extension
Apr 30 20:51:22 cslbox kernel: [8.225141] r8169 :01:00.0: firmware: 
direct-loading firmware rtl_nic/rtl8168g-2.fw
Apr 30 20:51:22 cslbox kernel: [8.225385] Generic PHY r8169-100:00: 
attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-100:00, irq=IGNORE)
Apr 30 20:51:22 cslbox kernel: [8.226573] em28xx 1-2:1.0: Registering input 
extension
Apr 

Bug#926555: unblock: yubico-piv-tool/1.7.0-1

[Paul Gevers]

Control: tags -1 moreinfo

On Sat, 06 Apr 2019 22:59:16 +0200 Nicolas Braud-Santoni
 wrote:
> The latest upstream release contains security-critical changes (see #926551).

Please be aware that without updates to that bug, your package will be
removed from buster soon. When that happens, your package will not be
allowed to migrate back in, so make sure you follow up, on that bug and
on this one.

> I apologise for the larger-than-necessary diff, which includes some packaging
> changes that were pending upload  :(

Those changes can be reverted. The worse problem here is that you're
bumping compat level here, that isn't allowed at this stage of the release.

However, the biggest part of the changes come from the new upstream
release. Not all changes by upstream in the changelog make sense to me
without further investigation. In bug 926551 you seem to know which
changes you want, how feasible is it to cherry-pick the security fixes
instead of pulling in the full new upstream? That would make reviewing
easier as your diff is big (the most likely reason why you didn't hear
from us earlier).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#799214: official Tarsnap binary packages available

[Graham Percival]

Greetings,

We now offer binary packages as well:
https://pkg.tarsnap.com/deb/
with instructions at:
https://www.tarsnap.com/pkg-deb.html

I'm happy to respond to bug reports.

Cheers,
- Graham Percival, Tarsnap employee

Bug#928356: elpa-magit: diff buffer when committing is often useless/wrong

[Robbie Harwood]

Package: elpa-magit
Version: 2.90.1-2
Severity: normal

Dear Maintainer,

When committing changes without using staging (i.e., with `git commit -a` or
`git commit explicit/path/to/files`), the magit-diff buffer which is spawned
shows the diff for the most recent commit to master - not the proposed action
of the current commit.  To reproduce:

git init test
cd test
echo "test file" > foo
git add foo
git commit -am 'Initial commit'
echo "something else" > foo
git commit -a # this will incorrectly show an empty diff buffer
echo "a third thing" > foo
git commit -a # this will incorrectly show the previous commit

Thanks,
--Robbie

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

Kernel: Linux 4.19.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_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 elpa-magit depends on:
ii  elpa-dash 2.14.1+dfsg-1
ii  elpa-ghub 3.2.0-1
ii  elpa-git-commit   2.90.1-2
ii  elpa-magit-popup  2.12.5-1
ii  elpa-with-editor  2.8.1-1
ii  emacsen-common3.0.4
ii  git   1:2.20.1-2

elpa-magit recommends no packages.

elpa-magit suggests no packages.

-- no debconf information

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Matthijs Kooijman]

Hi Adrian,

thanks again for your thorough review. I'm responding to both your
e-mails inline below.

> >>> 3) Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d)
> >>
> >> 3.1) Nice. I didn't know about those new syslinux architecture dependent
> >> files. As per the wiki you link (
> >> https://wiki.syslinux.org/wiki/index.php?title=Library_modules#All_Syslinux_variants_need_an_additional_ldlinux_module
> >> ) in the commit description I guess that even ldlinux.c32 wouldn't be
> >> used but ldlinux.e64 instead.
> > Actually, ldlinux.e64 is only for EFI. This commit only touches
> > BIOS-related stuff. I'm not sure how "architecture dependent files" are
> > relevant here, since this commit just removes some files which are
> > really superfluous (since the 'syslinux' and 'extlinux' commands used to
> > install the bootloader in binary_hdd make sure to copy their own version
> > of these files into the image).
> I'm revisiting this commit and I'm not sure this is right thing to do.
> If your pull request only affects syslinux-efi why do you even care
> about 32bit code?
True, this was just a cleanup I came across. It is sort of related due
to the next commit that moves all c32 modules into a subdirectory. I
wondered whether to also move ldlinux.c32 and whether leaving it would
cause problems with the CWD change in the EFI boot. I then concluded the
file was not used at all and just sidestepped the issue by removing it
entirely.

I did one more test and noted that the existence of these files do not
cause problems for syslinux-efi. I'm not sure it it makes sense to keep
them or not, but dropping this commit from this MR for now seems fine
with me.

> > Also, EFI supports 32 and 64 bit (hence modules32 and modules64), but
> > BIOS is (by definition, I think) only 32-bit, so I just used "modules".
> 
> Well, I think you should use something else.
> modules32 is 9 characters long (not 8.3 compatible). What about module32
> and module64? So that we can reuse the code in the iso side when
> isolinux is updated to support hybrid isos in efi mode ?
Good point, hadn't considered 8.3 compatibility. Singular "module32"
sounds a bit weird to me, but it is probably clearer than something like
"mods32" or even just "c32" (the latter seems reasonable, except that
the "c64" directory would then still contain ".c32" files since that's
what 64-bit syslinux-efi also uses...).

> >> 5.2) Anyway I don't think I like this code at all. I mean... you are
> >> supposed to create a new file named:
> >> scripts/build/binary_syslinux-efi
> >> and not hack around the existant one: binary_syslinux
> > 
> > That would make sense if I wanted syslinux-efi to be really indepenent,
> > but as I noted above, I wanted to make them share a single configuration
> > (and also allow syslinux-efi to be installed by itself). This seemed
> > like best way to achieve that, though alternative suggestions are
> > welcome :-)
> 
> Well, you could have a binary_syslinux_cfg file similar to the
> binary_loopback_cfg one or maybe binary_shared_cfg.
That would indeed make some sense. I had not really considered this
before, but did now. The problem with this approach is that both
binary_syslinux_cfg, binary_syslinux and binary_syslinux-efi would need
to duplicate code. At least they all need Install_Bootloader_Files,
which could be slightly generalized and moved into functions.

There is also a bunch of code which post-processes .cfg and splash.svg
files. This would be mostly needed in binary_syslinux_cfg only (since
the syslinux/syslinux-efi only contains a minimal config file that
includes the shared config file and needs minimal post-processing).

However, if binary_syslinux_cfg would install syslinux-shared and then
do all the post-processing, followed by binary_syslinux and/or
binary_syslinux-efi without any post-processing, you would:
 - lose the ability to override some the shared config files with
   bootloader-specific (e.g. syslinux/isolinux/extlinux)
 - lose backward-compatibility with existing live-build configs that do
   not have a syslinux-shared config directory but have all their config
   in the bootloader-specific directory (which is installed *after*
   configs are post-processed).

This can probably be fixed by further splitting the cfg step into an
install and post-processing step. You would then get:
 - binary_syslinux_cfg that installs config files verbatim (runs if any
   of syslinux/extlinux/isolinux/syslinux-efi is selected).
 - binary_syslinux that installs the modules and main config file for
   syslinux/isolinux/extlinux (runs if any of syslinux/extlinux/isolinux
   is selected, but not if only syslinux-efi is selected).
 - binary_syslinux-efi that installs the modules and main config file for
   syslinux-efi (runs if syslinux-efi is selected).
 - binary_syslinux_proces_cfg that post-processes all config files
   installed by previous steps (runs if any of
   syslinux/extlinux/isolinux/syslinux-efi is selected).

But I'm 

Bug#928355: Samba doesn't register the service connection when users access the shares

[Paulo Cesar]

Package: samba
Version: 2:4.2.14+dfsg-0+deb8u12
Severity: normal

Hello,

When searching for information about users who have connected to a certain 
share in our file sharing service, we realize that the Samba suite's 
"service.c" module no longer registers this connection in the service logs 
(/var/log/samba/log.smbd, in our configuration). In previous versions of 
Debian, as well as in the currently stable (stretch), the Samba daemon recorded 
the following message when a user connected to the share:
[2019/04/30 09:36:16.865504,  2] 
../source3/smbd/service.c:841(make_connection_snum)
  Computer_Name (Source IP Address:Port) connect to service share_name 
initially as user username (uid=65534, gid=65534) (pid 6804)

And when the user disconnects from the share:
[2019/04/30 09:36:20.817461,  2] ../source3/smbd/service.c:1120(close_cnum)
  Computer_Name (Source IP Address:Port) closed connection to service share_name

To reproduce the situation it is necessary to access a share, on the Samba file 
server, with a valid user, as in the following example:
smbclient //192.168.1.10/sharename -U username -W DOMAINNAME

The messages previously displayed are no longer registered in the log file even 
with the policy "log level = 2 auth:3".

Our Samba file service configuration in use is the following:
[global]
  workgroup = DOMAINNAME
  netbios name = SERVER
  netbios aliases = SERVEROLD
  passdb backend = ldapsam:"ldaps://ldap.server.name 
ldaps://other.ldap.server.name" 
  ldap admin dn = uid=bind-account,ou=organization,dc=mydcname1,dc=mydcname2
  ldap suffix = ou=organization,dc=mydcname1,dc=mydcname2
  ldap passwd sync = no
  ldap ssl = no
  ldap timeout = 5
  admin users = @smb-org-administrators
  dns proxy = no
  name resolve order = wins bcast
  server string =
  load printers = no
  unix charset = utf8
  nt acl support = yes
  unix extensions = no
  msdfs root = yes
  max log size = 0
  log level = 2 auth:3
  wins support  = yes
  preferred master = Yes
  local master = Yes
  domain master = Yes
  os level = 233
  domain logons = yes
  time server   = yes
  logon drive  = u:
  logon path   =
  logon home = \\archives\homes
  logon script = %U.bat
  guest account = nobody
  passwd program = /usr/bin/passwd %u
  passwd chat = *Enter\snew\sUNIX\spassword:* %n\n 
*Retype\snew\sUNIX\spassword:* %n\n .
  lanman auth = yes
  ntlm auth = yes
  client lanman auth = yes
  client ntlmv2 auth = yes
  security = user
  encrypt passwords = true
  guest account = nobody
  kernel oplocks = no
  case sensitive = no
  hide files = /lost+found/
  veto files = /.DS_Store/._.DS_Store/.Trash-*/
  load printers = No
  printing = bsd
  printcap name = /dev/null
  disable spoolss = yes
  socket options = TCP_NODELAY
  vfs objects = full_audit
    full_audit:facility = LOCAL5
    full_audit:priority = NOTICE
    full_audit:prefix = %u|%U|%I|%S
    full_audit:success = mkdir rmdir open pwrite rename unlink
    full_audit:failure = mkdir rmdir open pwrite rename unlink


[netlogon]
  path = /etc/samba/netlogon
  root preexec = /etc/samba/scripts/preset.sh %U
  writeable = no


I believe that previous versions available in GNU/Debian 8 (jessie) are also 
affected by this behavior. Since it brings a lot of relevant information to the 
service administration, used since the Samba beginning, I believe that it would 
be important to evaluate the problem and forward some correction, if possible.

Regards.

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

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

Versions of packages samba depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.17.27
ii  libbsd0  0.7.0-2
ii  libc6    2.19-18+deb8u10
ii  libhdb9-heimdal [heimdal-hdb-api-8]  1.6~rc2+dfsg-9+deb8u1
ii  libldb1  2:1.1.20-0+deb8u2
ii  libpam-modules   1.1.8-3.1+deb8u2+b1
ii  libpam-runtime   1.1.8-3.1+deb8u2
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.9-2+deb8u2
ii  libtalloc2   2.1.2-0+deb8u1
ii  libtdb1  1.3.6-0+deb8u1
ii  libtevent0   0.9.28-0+deb8u1
ii  lsb-base 4.1+Debian13+nmu1
ii  multiarch-support    2.19-18+deb8u10
ii  procps   2:3.3.9-9+deb8u1
ii  python   2.7.9-1
ii  python-dnspython 1.12.0-1
ii  python-ntdb  1.0-5
ii  python-samba 2:4.2.14+dfsg-0+deb8u12
ii  python2.7   

Bug#928354: matrix-synapse-ldap3: users can impersonate any other users

[Andrej Shadura]

Package: src:matrix-synapse-ldap3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Due to a bug, it is possible to log in as any user without proper
authentication:

> It turns out the bug was related to a change that was made in the
> unreleased “master” branch of the matrix-appservice-ldap3 plugin being
> used by Librem Chat to authenticate users over LDAP. The bug ultimately
> came down to a mistake in a single line of code in a function related
> to LDAP searches:
> 
> - result = yield self._ldap_simple_bind(
> + result, _ = yield self._ldap_simple_bind(

[1]: https://twitter.com/matrixdotorg/status/1123298776725303299
[2]: 
https://puri.sm/posts/underscoring-our-transparency-first-librem-one-bug-report/

-BEGIN PGP SIGNATURE-

iQJTBAEBCAA9FiEE47V74F4CWMP6ghzXtke0/0DsYwMFAlzLKJUfHGFuZHJldy5z
aGFkdXJhQGNvbGxhYm9yYS5jby51awAKCRC2R7T/QOxjAwScD/9BQ85xiRRhU8I3
q3wssfABOsV+Oc+LK+UESMNZZglYO5zfQTbzKNEk4gFD8FjR0JJ36QOd4wVNCHRZ
14I4HmdwuFcHTsFwU6NVOfl3Iz2j449t98Yuo61OcoxYhQC1ZLR7hxHSDn7QNKWc
412uug+CH15ieOQwcDbu37U6KJK2h54yHiu3Ty06GAUi9DNlWNTu9x6A1LFNkLNQ
d6C/wjhCVIQAdrNU28l24BG1meeXHnh0NKRwOR/tweMWESDwh8lCJC73t3OtVulD
5NxDvTVS+OkwTlj6fDgIzb0IjV/PVxi6K2RxU7V3bXpDu7DdEqTOAEf3d8rXPf9J
Xuu9lXqnNOdRmCETtzegfShfe9sv3Ad2XSRtm3HyOs1ygvA0nv/xIgAEmpicTIbp
6VxvIb+WOMlF0Ci+i2RWwJtv2e15obYNXQSZdjGHeYcGUQb/eVRIizDjhC/iB3DE
x4j2Cu2Frltq6Iube1GsDpBQEDNVyllG2nxJmLG6zU4LTz2RWj9Su2SZbPSuECmR
hX3wZAbkIfGCSUAIw8bDQInJg7ortpFqbBoI3YEqzNpxyhwaqdvqDw5VQtPn0W0J
hjjvSsJ5y1PhswfozywhCg/cL8BS2zyfGb6IXcyMQTl3Z3l52yWRtoS4A/2BLGmV
+335m1DEHEBTKHV5ETq4i3PrQ5a3ig==
=2uCt
-END PGP SIGNATURE-

Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever

[Romain Francoise]

Hi,

v4.9.172 is out with the offending commit reverted. Is there a stretch
update with the same revert planned soon to address this? And via which
suite?

Thanks.

Bug#928353: release-notes: document mutt vs neomutt in buster

[Paul Gevers]

Package: release-notes
X-Debbugs-CC: m...@packages.debian.org, j...@debian.org

Dear (neo|)mutt maintainers,

I recently learned about the mutt versus neomutt situation in buster via
the blog [1] of jmtd (in X-D-CC). I believe mutt and neomutt warrant a
note in the release notes, don't you agree?

As the maintainers of this software, you are in the best position to
write this. Are you willing and able to provide a piece of text? MR
against the release notes archive [2] are welcome, but otherwise just
sent to this bug is fine.

Paul

[1] https://jmtd.net/log/mutt_year_zero/
[2] https://salsa.debian.org/ddp-team/release-notes/



signature.asc
Description: OpenPGP digital signature

Bug#928352: nvidia-kernel-dkms: dkms did not automatically rebuild nvidia module for newly installed kernel

[guillaume raffy]

Package: nvidia-kernel-dkms
Version: 390.116-1
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

An upgrade from kernel 4.9.0-8 to kernel 4.9.0-9 broke nvidia-kernel-dkms on 
our server, which has 2 gpus for gpgpu computing: although nvidia-kernel-dkms 
was upgraded too in the process (as it was part of debian 9 upgrade 7 release), 
the modules weren't rebuilt, as shown with the following command :

root@physix58:~# lsmod | grep nvidia
root@physix58:~# find /lib/modules/ -name "nvidia*"
/lib/modules/4.9.0-9-amd64/kernel/drivers/net/ethernet/nvidia
/lib/modules/4.9.0-8-amd64/kernel/drivers/net/ethernet/nvidia
/lib/modules/4.9.0-8-amd64/updates/dkms/nvidia-current-modeset.ko
/lib/modules/4.9.0-8-amd64/updates/dkms/nvidia-current-uvm.ko
/lib/modules/4.9.0-8-amd64/updates/dkms/nvidia-current.ko
/lib/modules/4.9.0-8-amd64/updates/dkms/nvidia-current-drm.ko

I managed to get the nvidia modules rebuilt for kernel 4.9.0-9 by using 
"dpkg-reconfigure nvidia-kernel-dkms", but only after I installed 
linux-headers-4.9.0-9-all-amd64 (linux-headers-4.9.0-8-all-amd64 was installed 
but not linux-headers-4.9.0-9-all-amd64). I suspect that "dpkg-reconfigure 
nvidia-kernel-dkms" failed because of missing headers when invoked by "aptitude 
full-upgrade", but I can't be sure...

This problem seems to be the same as a very old bug report : 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585862

By looking at this issue on internet, it seems that this problem is quite 
common, and people usually get on with it just by rebuilding the modules as I 
did. However, I have the impression that the intended behaviour is that nvidia 
module be automatically rebuilt whenever there is a kernel upgrade, which is 
indeed what the user wants. So, I suspect that this automatic mechanism fails 
to work in some cases.

On 
https://www.reddit.com/r/linuxquestions/comments/6mqudq/ran_aptget_distupgrade_which_updated_kernel_now/,
 debian_miner says "I just did some testing with this, and I believe the reason 
some people are seeing this behavior is because they didn't install the 
linux-headers- metapackage"

Indeed, on our server, "linux-headers-4.9.0-8-all-amd64" was installed but not 
"linux-headers-amd64". I believe that if the package "linux-headers-amd64" was 
installed in the first place, then aptitude full-upgrade would have brought 
"linux-headers-4.9.0-9-all-amd64" along with the kernel, and the rebuild of the 
nvidia module would have then succeeded. But that's merely an hypothesis, as 
I'm not an expert.

Some things that might be worth noting :
1. the command that upgraded the kernel is "UCF_FORCE_CONFFNEW=1 
DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none yes '' | aptitude 
-y -o Dpkg::Options::="--force-confnew" -o 
Aptitude::Cmdline::ignore-trust-violations=true full-upgrade". It upgraded the 
following packages :

root@physix58:~# grep -B 1 linux-image 
/var/log/apt/history.log-20190501 
Start-Date: 2019-04-30  08:40:22
Install: linux-image-4.9.0-9-amd64:amd64 (4.9.168-1, automatic)
Upgrade: ca-certificates-java:amd64 (20170929~deb9u1, 20170929~deb9u3), 
postfix:amd64 (3.1.9-0+deb9u2, 3.1.12-0+deb9u1), libglx0-glvnd-nvidia:amd64 
(390.87-8~deb9u1, 390.116-1), postfix-pcre:amd64 (3.1.9-0+deb9u2, 
3.1.12-0+deb9u1), linux-libc-dev:amd64 (4.9.144-3.1, 4.9.168-1), 
libnvidia-ml1:amd64 (390.87-8~deb9u1, 390.116-1), nvidia-egl-icd:amd64 
(390.87-8~deb9u1, 390.116-1), nvidia-driver:amd64 (390.87-8~deb9u1, 390.116-1), 
libpng-dev:amd64 (1.6.28-1, 1.6.28-1+deb9u1), postfix-sqlite:amd64 
(3.1.9-0+deb9u2, 3.1.12-0+deb9u1), libmagickwand-6.q16-3:amd64 
(8:6.9.7.4+dfsg-11+deb9u6, 8:6.9.7.4+dfsg-11+deb9u7), python3-pip:amd64 
(9.0.1-2, 9.0.1-2+deb9u1), libjs-jquery:amd64 (3.1.1-2, 3.1.1-2+deb9u1), 
nvidia-vdpau-driver:amd64 (390.87-8~deb9u1, 390.116-1), 
libgl1-nvidia-glvnd-glx:amd64 (390.87-8~deb9u1, 390.116-1), 
libglx-nvidia0:amd64 (390.87-8~deb9u1, 390.116-1), 
linux-compiler-gcc-6-x86:amd64 (4.9.144-3.1, 4.9.168-1), libpq5:amd64 
(9.6.11-0+deb9u1, 9.6.12-0+deb9u1), nvidia-kern
 el-dkms:
 amd64 (390.87-8~deb9u1, 390.116-1), libegl-nvidia0:amd64 (390.87-8~deb9u1, 
390.116-1), nvidia-egl-common:amd64 (390.87-8~deb9u1, 390.116-1), 
python-cryptography:amd64 (1.7.1-3, 1.7.1-3+deb9u1), 
libnvidia-ptxjitcompiler1:amd64 (390.87-8~deb9u1, 390.116-1), 
nvidia-legacy-check:amd64 (390.87-8~deb9u1, 390.116-1), libzzip-0-13:amd64 
(0.13.62-3.1, 0.13.62-3.2~deb9u1), libnvidia-fatbinaryloader:amd64 
(390.87-8~deb9u1, 390.116-1), linux-image-amd64:amd64 (4.9+80+deb9u6, 
4.9+80+deb9u7), nvidia-kernel-support:amd64 (390.87-8~deb9u1, 390.116-1), 
libgstreamer-plugins-base1.0-0:amd64 (1.10.4-1, 1.10.4-1+deb9u1), 
linux-kbuild-4.9:amd64 (4.9.144-3.1, 4.9.168-1), nvidia-driver-libs:amd64 
(390.87-8~deb9u1, 390.116-1), nvidia-driver-bin:amd64 (390.87-8~deb9u1, 
390.116-1), libjs-bootstrap:amd64 (3.3.7+dfsg-2+deb9u1, 3.3.7+dfsg-2+deb9u2), 
libmagickcore-6.q16-3:amd64 (8:6.9.7.4+dfsg-11+deb9u6, 

Bug#928351: unblock advice for dhcpcd5/7.2.1-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Scott,

On 02-05-2019 18:08, Scott Leggett wrote:
> I need some advice on the best way to address a trio of security-related
> RC bugs in dhcpcd5 (#928056, #928104, #928105). These are fixed upstream
> in 7.2.1.
> 
> The version currently in testing is 7.1.0. I've packaged 7.2.1 but
> haven't yet uploaded to unstable. A debdiff is attached.
> 
> I'd much prefer to stick with upstream rather than try to cherry-pick
> fixes for these kinds of issues, as I'm concerned about introducing
> problems into code I'm not deeply familiar with. However as you can see
> the attached debdiff is rather large.

We very much prefer you to try and cherry-pick at this point of the
release cycle. I failed to (quickly) spot a changelog upstream, so we
can't even judge why all the changes are in this release.

> Would an unblock request for 7.2.1 be accepted at this stage?

No, and definitely not without much more explanation of what this
upstream changes actually encompass.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi

[Jamie Zawinski]

> but I think those are all using TrueType fonts via fontconfig/etc, not 
> "traditional" X11 fonts.

Ok but "traditional" X11 is perfectly capable of using TrueType fonts, 
server-side, XLoadFont-style. On my system (your paths will vary) --

% xlsfonts -ll -fn '-bitstream-bitstream vera 
serif-medium-r-normal--0-0-0-0-p-0-iso10646-1' | grep NAME
  FAMILY_NAME   bitstream vera serif
  WEIGHT_NAME   medium
  SETWIDTH_NAME normal
  ADD_STYLE_NAME
  FACE_NAME Bitstream Vera Serif
  _ADOBE_POSTSCRIPT_FONTNAME BitstreamVeraSerif-Roman
  RASTERIZER_NAME   FreeType

% find /opt/X11/share/fonts -type f | grep -i verase
/opt/X11/share/fonts/TTF/VeraSe.ttf
/opt/X11/share/fonts/TTF/VeraSeBd.ttf

% xterm -fn '-bitstream-bitstream vera 
serif-medium-r-normal--17-120-100-100-p-107-iso10646-1'

...works!


--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#928283: lintian: false positive pkg-js-tools-test-is-missing for openjk: assumes variables contain --with=nodejs

[Chris Lamb]

tags 928283 + moreinfo
thanks

Hi Simon,

> I believe this is because it uses a variable in the dh invocation, to
> disable one binary package (which is not considered ready by upstream)
> unless built for experimental or with some DEB_BUILD_OPTIONS:
> 
> dh_options =
> ifneq ($(with_jk2),ON)
> dh_options += -Nopenjk-outcast
> endif
> 
> ...
> 
> %:
> dh $@ --builddir=obj $(dh_options)
> 
> and checks/debhelper.pm assumes this might contain all possible addons:

That sounds about right. However, as alternative suggestion how would
you feel about simply not emitting these tags if notice the package
is using dynamic variables? This is an approach taken in quite a few
places already in Lintian so not only is there is prior art it
naturally prevents the codebase becoming too clever or special-cased.

Indeed, how common even is this false-positive? It might be even more
sensible to add a Lintian override until upstream accepts the package;
it's meant to be temporary until upstream reviews/accepts some change,
after all.


Best wishes,

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

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

On 4/30/19 11:38 AM, Patrick Schleizer wrote:
> On https://www.whonix.org/pipermail/whonix-devel/2019-April/001371.html
> its developer wrote:
>
>> [...]
>> - the in-kernel crypto API has an RNG framework that provides a DRBG.
> This
> DRBG is used for in-kernel crypto API purposes. It may be accessed from
> user
> space via AF_ALG [2]. Yet, this is not accessible from /dev/random, /dev/
> urandom or getrandom. The DRBG uses the in-kernel JitterRNG to seed itself.
>> [...]
> Better entropy for in-kernel crypto API purposes sounds good as a
> general security enhancement.
>
> Fedora enables this kernel module by default, too.
>
> Does this sound like a good idea to enable loading this kernel module by
> default in Debian?
>
Stephan confirms that the Kernel DRBG is also important for crypto
operations that don't use /dev/random like the ECC cipher and much more.
I think it is important to revisit this in that case and add the jitter
module to the initramfs:


Stephan:

"Always assume that a weak RNG is bad. The DRBG is used for kernel
crypto API

for generating keys and other data. For example, the ECC key generation uses 
the DRBG and NOT the get_random_bytes (the /dev/urandom in-kernel equivalent). 
There are quite a number of other use cases.

I know, it is unfortunate that we have 2 RNGs in the kernel. But a 
consolitation approach I offered at [1] was not considered."

"So, the jitterentropy kernel module is only used by the kernel DRBG. And it 
will load the jitterentropy kernel module automatically considering that the 
module name is the same as the cipher name "jitterentropy_rng". Of course, 
this only applies if the kernel module is available in the execution 
environment (like the initramfs) and the DRBG is initialized during that time."

Bug#927220: lintian: Please detect and warn about libs exporting common symbols

[Chris Lamb]

tags 927220 + moreinfo
thanks

Hi Niels,

> Packages should *not* export strlcpy (or other common symbols) simply
> because they happen to use an embedded compat version of the symbol.

How can we detect this incorrect export in Lintian?


Best wishes,


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

Bug#926823: executable-not-elf-or-script should consider PE binaries

[Chris Lamb]

tags 926823 + moreinfo
thanks

Hi Michael,

> Am 11.04.19 um 01:22 schrieb Felix Lechner:
> > It's just that the lintian tag is not triggered when
> > the [executable] bit is off.
> 
> That much I figured :-)

This begs the question; why cannot the systemd packaging remove the
executable bits from these files?

Indeed, they can't be "executed" in the usual way after all — the
long description of the tag even refers to this although admittedly
it mentions "Windows", not PE:

Tag: executable-not-elf-or-script
Severity: normal
Certainty: certain
Info: This executable file is not an ELF format binary, and does not start
 with the #! sequence that marks interpreted scripts. It might be a sh
 script that fails to name /bin/sh as its shell, or it may be incorrectly
 marked as executable. Sometimes upstream files developed on Windows are
 marked unnecessarily as executable on other systems.
 .
 If you are using debhelper to build your package, running dh_fixperms will
 often correct this problem for you.
Ref: policy 10.4


Best wishes,

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

Bug#928185: unblock: openjdk-11/11.0.3+7-4

[Rene Engelhard]

Hi,

On Thu, May 02, 2019 at 01:59:46PM +0200, Matthias Klose wrote:
> > From what I understand bug#926009 is a regression in that version.
> > There's no explanation that I can see for that change, no associated
^

> > bug, and it doesn't look appropriate.  Please revert it.
> 
> No. The issue is in the LibreOffice package, which already has this fixed in
> testing. The openjdk package also has an appropriate Breaks.

https://codesearch.debian.net/search?q=java.vendor.*Oracle

Not only LO.

(And there's many more but checking for "gcj" or "IBM", which do not
matter in this case, though)

And you forget eventual third-party stuff.

And as Julien says: there's no explanation on why this change is needed
after all.

Regards,

Rene
> 

Bug#862073: [rb-general] Uploading buildinfo files to buildinfo.debian.net

[Holger Levsen]

On Mon, Apr 29, 2019 at 10:43:11AM -0700, Vagrant Cascadian wrote:
> On 2019-04-29, Vagrant Cascadian wrote:
> > It seems to be missing the .buildinfo.N, which in some cases are the
> > actual .buildinfo files built by the buildd's and the corresponding .deb
> > files shipped in the archive.
> >
> > The .buildinfo without a numbered increment is frequently provided by
> > developers who follow best practices and do source-only uploads that
> > include a signed .buildinfo file. I'll take a look at the code and see
> > if I can't propose a simple fix.
> It seems like you did in fact catch these, and named them as
> ARCH-source.buildinfo. Nice!

in the pool structure the filenames are changed so that the original
filename $package_$version_$arch.buildinfo is replaced with one where
the $arch part is replaced like this:

ARCHITECTURE=$(grep ^Architecture: $FILE | cut -d ' ' -f2-|sed 's# #-#g')

or in plain English: with the Architecture: field from inside the file,
where the architectures are concated with hyphons, so that

Architecture: all source amd64

results in a $package_$version_all-source-amd64.buildinfo file.

And then strangely there are a few hundred cases of identically named
$package_$version_$arch.buildinfo files (out of allmost a million) in
the /mm/dd structure, these get a .0 suffix. And then there are 4
cases with 3 identically named files, which get a .1 suffix.
(This needs to be investigated why this happens...)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

we'll all die. make a difference while you can. disobey. smile.


signature.asc
Description: PGP signature

Bug#928178: apparmor: thunderbird fails to start, saying that is already running

[Simon Deziel]

Hello,

On 2019-05-02 10:58 a.m., Carsten Schoenert wrote:
> Hi,
> 
> Am 02.05.19 um 09:05 schrieb Ulrike Uhlig:
>>> Well, but who has enabled AA in PC? I'm sure that I have not worked on
>>> /etc in these days and I am the only one can access on it. In my opinion
>>> there is a bug in some package update that has enabled TB AA profile...
>>> but in effect I realize that to be believable someone else would find
>>> this unbelievable behaviour...
>>
>> Maybe you accidentally upgraded to Buster or you are using a kernel that
>> has AA enabled by default.
> 
> the starting email of this bugreport is showing an installed kernel from
> backports. So for me it's quite obvious *why* apparmor is installed and
> has activated all the profiles for the various packages that come along
> with AA profiles which should be also activated then.
> 
>> Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
> 
> I can remember we have such discussions again and again from time to
> time and users are surprised why Thunderbird isn't working any more as
> usual or expected after some random update. So far I remember it was
> always an active TB AA profile. And users are even more surprised if I
> tell them the TB packaging in Stretch did never had an automatically
> activated AA profile, in other words, they have it activated it by
> themselves.
> 
> In this report there are two things that have come together in my eyes.
> 
> 1.) An activated AA profile for Thunderbird.
> 
> 2.) An different path for ${HOME} because of an membership within a
> Windows domain.
> 
> The first one isn't a big problem anymore in newer days, the current AA
> profile is covering for sure about 95% of the use cases.

Agreed.

> The second point isn't covered nicely until now in the AppArmor
> installations within Debian at least. But I think also that Thunderbird
> isn't the only package that will suffer from this problem and we will
> need a more general solution for this. And this needs to go into
> Apparmor itself instead of every body tries to implement some super
> logic within their AA package profile.

Thunderbird is definitely not the only package affected. There already
is a way to deal with non-standard home path: local adjustment of the
'tunables' provided by Apparmor. Those will affect every profile using
the @{HOME} variable.

> Currently I've no idea how to detect a membership of a Windows domain
> nicely, for sure this is solvable by some PAM voodoo. I have simply no
> knowledge in this area. And I have no environment to test something. It
> seems we just need to trigger a dpkg-reconfigure of AA if the PC is
> within a domain membership.

I don't think it's specific to domain members as all it takes is to have
a home dir located somewhere non-standard (!= /home/$user) as the
default value for @{HOME} only permits what's common.

That said, having a dpkg-reconfigure trigger when $HOME non-standard
might be an idea, but that's a concern for Apparmor itself, not
Thunderbird :)

Regards,
Simon

Bug#921019: arm64: Please provide sound modules for Allwinner A64 based systems

[Harald Geyer]

Andrei POPESCU writes:
> On Jo, 31 ian 19, 17:21:54, Harald Geyer wrote:
>  
> > Please enable the following Kconfig symbols as modules:
> > 
> > CONFIG_SND_SUN50I_CODEC_ANALOG
> > CONFIG_SND_SUN8I_CODEC
> > CONFIG_SND_SUN4I_I2S
> > CONFIG_SND_SOC_SIMPLE_AMPLIFIER
> > CONFIG_SND_SIMPLE_CARD
> > 
> > These are necessary for sound support on pinebook, Olimex TERES-I, etc.
> > The drivers are available upstream since 4.20.
> > Pinebook has sound enabled in devicetree starting with 5.0
> 
> Would this enable also the S/PDIF or is something else needed 
> (CONFIG_SND_SUN4I_SPDIF maybe?)?

Indeed, for S/PDIF on A64 CONFIG_SND_SUN4I_SPDIF is needed.

However AFAICS debian ships no sun50i-a64 devicetrees where S/PDIF is
enabled. You would need a custom DT or an overlay, to make the
debian kernel actually load the module.

BTW there have been two uploads of linux 5.0 to experimental since this
bug was opened. Would be nice if somebody could address this for the
next upload.

Harald

Bug#862073: [rb-general] Uploading buildinfo files to buildinfo.debian.net

[Holger Levsen]

Hi,

please note that https://buildinfos.debian.net/buildinfo-pool/ is
currently being recreated and thus not have all data again yet...

(I've added support for 3 (and more) .buildinfo files with the same
name and noticed that the numbered links were created in the wrong
order, thus the recreation.)

On Mon, Apr 29, 2019 at 10:39:30AM -0700, Vagrant Cascadian wrote:
> I really like that it provides a view in a "pool" style, e.g.:
>   https://buildinfos.debian.net/buildinfo-pool/u/u-boot/

thanks. (and me too)

> I almost wonder if we shouldn't try to coordinate archiving this data
> with:
>   https://www.softwareheritage.org/

thats an interesting idea!

> It might be a slight stretch of their mission to call .buildinfo files
> "source code" ... but I wouldn't mind making the case that .buildinfo
> files should be considered source code.

indeed.

> > buildinfos.debian.net has all .buildinfo files since December 2016.
> Very cool! It is definitely a much simpler approach and catches many
> corner cases (unsigned, signatures, etc.) that my method doesn't!

yup. 

> It seems to be missing the .buildinfo.N, which in some cases are the
> actual .buildinfo files built by the buildd's and the corresponding .deb
> files shipped in the archive.

it has them. see eg dpkg (once the pool structure is back).

> The .buildinfo without a numbered increment is frequently provided by
> developers who follow best practices and do source-only uploads that
> include a signed .buildinfo file. I'll take a look at the code and see
> if I can't propose a simple fix.

please do.

> The presence of multiple .buildinfo* files does make it harder to know
> which .buildinfo to use to reproduce a build from the archive if they
> differ, unfortunately.

the one with the correct hash for the .deb

> Unsigned .buildinfo files are of limited usefulness, if we're really
> trying to establish a chain of verification... though perhaps it's still
> better than no .buildinfo at all, since the archive verifies the
> .changes file before including it... though obviously a compromised
> archive could inject malicious unsigned .buildinfo files more easily and
> requires some trust needed in specific parties.

yes. unsigned .buildinfo files should not exist. for this to happen, as
a first step, I plan to record this state in the db (in a new table...)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes...


signature.asc
Description: PGP signature

Bug#924270: O: keepassx -- Cross Platform Password Manager

[Darshaka Pathirana]

On 3/11/19 4:29 AM, Shengjing Zhu wrote:> On Mon, Mar 11, 2019 at
3:15 AM Reinhard Tartler  wrote:
>>
>> Package: wnpp
>> Severity: normal
>>
>> Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no
>> longer using this package and have personally switched to
>> 'password-store'.  Unfortunately, I've also failed to get a response
>> from upstream from
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which
>> recommends to replace keepassx with keepassxc, a community fork,
>> possibly because of unresponsive upstream.
>>
>> I am undecided whether or not this package should be included in Debian
>> 10 (aka buster). It clearly is useful to many people, but its long-term
>> maintenance is unclear.
>>
>> I'd encourage people interested in picking up this package to coordinate
>> with Julian Klode (CC'ed), the Debian keepassxc maintainer.
>>
> 
> I'm also long-time user of keepassx.
> 
> I checked the upstream. In surprise, I found the master version has
> switched to Qt-5. And the upstream author is Felix Geyer, who is DD as
> well.
> 
> Felix, could you have some inputs here?
> 
> In person, I hope keepassx is in buster. I can help uploading the
> master version(with Qt-5) if Qt-4 is really needed to be removed from
> buster. However I'm unsure if RT is fine with this big change(I assume
> it's not ok).

Whoever cares: I've been using keepassx for years now and switched
to keepassxc just because of this issue without any troubles. If
long-term maintenance is unclear we (Debian) maybe should avoid
going that way...

JM2C && HAND,
 - Darsha



signature.asc
Description: OpenPGP digital signature

Bug#928350: cdist: new upstream release

[Dmitry Bogatov]

--21189_ĵaŭ_Maj__2_15_03_59_UTC_2019
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Package: cdist
Severity: wishlist

Dear Maintainer,

new upstream release 4.11.1 is available on new upstream hosting:
http://code.ungleich.ch/ungleich-public/cdist.git
-- =

Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
   =
  --

--21189_ĵaŭ_Maj__2_15_03_59_UTC_2019
Content-Type: application/pgp-signature

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlzLBt8ACgkQSBLY3qgm
EeZLJxAAn7oZM/heftRovJjC0na6ji1AKKFC+8n4VlQXL5VLib+v7lB4kFD7v4bT
E69sQIn2tsIfQa12PCqLFQ53gp88wDN3MDlj+wl2fq8AO6a9iqbxPwbiEOYh2IQC
lcSMTVdHbIBKLTJPfgrprICeyc/E098ciY+McIpaX615iff5tG3O2/XQ64hvoLeR
JYT1ZIb7LcTS8WKcPf9y0bPIa6ZLvErIvEhBSSk4kCid6+KcnxpdTg7ZPd0t1dU6
vAbcc1Uc20sS6NEgwhkG2Y3NoAYYYPo4WbuxlguiWpjfMlWrpgp8e8goHjVV93d0
/XEwycl+ZDHmEx6Npv7l3j+EFGRd/RiibsMp2U3/pGN94F0j9M9KIDcVRe1XlMqJ
BbqlELFQuk/NTu/QEFPsIY/U0/sRQDpigRjbMeFKvsV09XVvPIoXiTDZNeLtXiUE
uqqiYAM2lkxZAIxIWcjrVoFhzsp5WbLAukFgLqGwP5ocTjgiyzs3X/0+M6jzUdFI
ml9UUL2EbN8t1LQfHrXkotDxlj8eIbR2t6qVSlxFJITMhWq3ofwN1NR84OWFr4P9
rLagQTg49JFDTL0nvB2VWFA02TDwUEQC8KWdgbHFFq4FnSFhSa8jxNejwP6WuoSq
T+UrOWz7HxIa4W5ocPlUBp33lXD5vWbAlLrv0g4yXa7K9qb4NkA=
=BazI
-END PGP SIGNATURE-

--21189_ĵaŭ_Maj__2_15_03_59_UTC_2019--

Bug#928348: initscripts use unsafe `: >` shell command to create files

[Dmitry Bogatov]

Package: initscripts
Severity: wishlist
Followup-For: Bug #923478

[ Moving discussion to separate bug ]
[ Please, drop #923478 on reply ]

[2019-04-29 02:44] Chris Hofstaedtler 
> part   text/plain 517
> * Dmitry Bogatov  [190429 01:14]:
> > [2019-04-26 13:17] Chris Hofstaedtler 
> > > > According my experiments, it will. Even if I remove this code, something
> > > > (login/getty, maybe?) still creates /var/run/utmp, root:root.
> > >
> > > Which init was used in your experiments?
> > 
> > sysvinit-core.
>
> https://sources.debian.org/src/sysvinit/2.93-8/src/init.c/?hl=2797#L2797
>
> Note that the comment citing the preconditions is not telling the
> entire story on modern systems.

Thank you very much, Chris. I should have found it myself.

Then creating /var/run/utmp is needed, since "runit-init" would not
create it itself: it relies on initscripts. Based on patch of Christian,
I propose following patch. Dear sysvinit folks, opinions?

From ce3417109303bafbc771f40428579e6691a436df Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 1 May 2019 23:43:13 +
Subject: [PATCH] Error handle redirection used to truncate /var/run/wtmp

Signed-off-by: Cristian Ionescu-Idbohrn 
Signed-off-by: Dmitry Bogatov 
---
 debian/src/initscripts/etc/init.d/bootmisc.sh | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/debian/src/initscripts/etc/init.d/bootmisc.sh 
b/debian/src/initscripts/etc/init.d/bootmisc.sh
index 06facc2f..461b7472 100755
--- a/debian/src/initscripts/etc/init.d/bootmisc.sh
+++ b/debian/src/initscripts/etc/init.d/bootmisc.sh
@@ -12,6 +12,7 @@
 
 PATH=/sbin:/usr/sbin:/bin:/usr/bin
 [ "$DELAYLOGIN" ] || DELAYLOGIN=yes
+. /lib/lsb/init-functions
 . /lib/init/vars.sh
 
 do_start () {
@@ -25,18 +26,20 @@ do_start () {
;;
esac
 
-   # Create /var/run/utmp so we can login.
-   true > /var/run/utmp
-   if grep -q ^utmp: /etc/group
-   then
-   chmod 664 /var/run/utmp
-   chgrp utmp /var/run/utmp
-   fi
-
# Remove bootclean's flag files.
# Don't run bootclean again after this!
rm -f /tmp/.clean /run/.clean /run/lock/.clean
rm -f /tmp/.tmpfs /run/.tmpfs /run/lock/.tmpfs
+
+   readonly utmp='/var/run/utmp'
+   if > "${utmp}" ; then
+   chmod 644  "${utmp}" || log_warning_msg "failed to chmod 
${utmp}"
+   chgrp utmp "${utmp}" || log_warning_msg "failed to chgrp 
${utmp}"
+   return 0
+   else
+   log_failure_msg "failed to truncate ${utmp}"
+   return 1
+   fi
 }
 
 case "$1" in


-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#928347: shellcheck: new upstream release 0.6

[Dmitry Bogatov]

--21081_ĵaŭ_Maj__2_15_03_52_UTC_2019
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Package: shellcheck
Version: 0.5.0-3
Severity: wishlist

Dear Maintainer,

upstream version 0.6 is released. Please consider packaging it.

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=3Deo.utf8, LC_CTYPE=3Deo.utf8 (charmap=3DUTF-8), LANGUAGE=3Deo=
=2Eutf8 (charmap=3DUTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages shellcheck depends on:
ii  libatomic1  8.3.0-6
ii  libc6   2.28-8
ii  libffi6 3.2.1-9
ii  libgmp102:6.1.2+dfsg-4

shellcheck recommends no packages.

shellcheck suggests no packages.

-- no debconf information

--21081_ĵaŭ_Maj__2_15_03_52_UTC_2019
Content-Type: application/pgp-signature

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlzLBtgACgkQSBLY3qgm
EeZr5Q//dTLXzh/skP3LGWBFdSyD3dHrbYvL9Mju2AxFoS+XsJvogKsEmO/Ld3XM
CjAGlF9AdplKvQ/+0QAhEP4HiLwN5OKdc5eZEp297LTQwR/rj7cUyHL4E04Cz8hh
sPgSh1ndM5Jx9+fMiri3ZfNVJgzT06/ui0wvH/ZGIpg53DPp6VgJUt6jcFRpE5lH
+800/xiV/GCHU3oBLKdd+1DcWuUHoQv0j3HhSmZ6SKhIVD1s2JlBbjYSt4NAdpGM
dR9VDzxurEyA/qRIWJbrrz/N8JVvT50Qv0GtDLyHq+mmyv/V6Xa7LDvgNrJhNTYq
2p3RQFE9cdgntnszlL2tifDflI6ohxa8BORQ6GSBtj8M4nMaXcVK7xGxjsqSxdKz
xlt2KWnG9UQT5uP9xAj96HqVwi4OQ4JUaAQ6MRlsk/w8bVa2V8+lOHDuqLj2yceV
HM7O9m4+rvhe15rbAB+PgqiZL4CARegqw+v4ZnF2fQftMPb/SZWyTXKCaopMtlD1
Fkkim6mBjSsVqV6LKKKp+S5LC9pkZkJykeEtgLCPbvC4Jm4WFUEXmKBdbAY0vRp3
xTARVmC0oMoFNOviWN77qYUbNjbG5Ozsz1vZ5TcQG7+C8b4f41En4ZVefdQt3Duv
CYTYovqo3YYlAts2bdSdCmgeewpnjY4OJGl1zmvzFIJ1gJ5rxJ8=
=/5Kv
-END PGP SIGNATURE-

--21081_ĵaŭ_Maj__2_15_03_52_UTC_2019--

Bug#928349: shellcheck: dubious diagnostics SC2188

[Dmitry Bogatov]

--21134_ĵaŭ_Maj__2_15_03_54_UTC_2019
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Package: shellcheck
Version: 0.5.0-3
Severity: normal

Dear Maintainer,

shellcheck complains on empty redirection:

$ cat /tmp/foo.sh
#!/bin/sh
> /tmp/foo
$ shellcheck /tmp/foo.sh

> /tmp/foo
^-- SC2188: This redirection doesn't have a command. Move to its 
command (=
or use 'true' as no-op).

As discussed in #923478, empty redirection is posix-complaint, more
concise way to say "true > /tmp/foo": create file if it does not exist
and make sure it have zero size. Futhermore, shellcheck complains on
such construction in bash mode, where it definitely works as intended.

I think this diagnostics is incorrect.
-- =

Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
   =
  --

--21134_ĵaŭ_Maj__2_15_03_54_UTC_2019
Content-Type: application/pgp-signature

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlzLBtoACgkQSBLY3qgm
EebuEw/9Ef8RAl3ocRaWY+iJMSoM3qzbsiNXLFqSOx6RhQSOUQnuiBjR9uQxhr56
E/W2AMVPEGPtsZ7X32QYZYQP2SCQUOlHXYLoqedA6WVsQcRzLg9KrKey8c5XTgi8
luLsL/z3IE6Z+qMJ9ebi+qEQoKMBts3Q8yUX4YSli/B1cUbtqOOFKyYwpOYrqWSM
2QHKc6kVwHckvwDp9EScX4vrZVQD2LYYfH3Zz+6zKbuBRqMfluUXLsG/Yrdn3XP9
nTDVH5MZkD+NRZ75s870jQtU6AD8fJCQcKkPHVtBN69rrSTxgCmgLzsxd117WKGH
cGa+ce0+Ss1pZfokEIe+CI9kaWT0BtqeYWh1ASZTlS/x9uaHmBrdJ2E5UK5zKbgj
v+xkvP8AUUx/BjU2/TP2NBfnCnQdFz2CpVW+p/YJ+exN/gqMbF0e5UslIi+3pDoz
2dlj3scZH8AZzMRgxH0iTY1IhagctVUEEGnN1FajYJKaVGtymSfoAL/oH90oUB67
RnMdfoJ0A/VQV2E4kLJIo0Hh/54G+/kpQxTAWpGSfa4Ks7Ppsw3r/hQpKvNaHwXy
K/tsz+2tkaVyqREOzSmjuZFnHG/ZZrG/rbaIBarK2czlnG1kO7e5NKeYoEgf9hsx
kf98aJzZQ2H26siod/exLGgE8xiOyM1ES5DIhCaRrHjCwCQyMv8=
=OOxU
-END PGP SIGNATURE-

--21134_ĵaŭ_Maj__2_15_03_54_UTC_2019--

Bug#928178: apparmor: thunderbird fails to start, saying that is already running

[Carsten Schoenert]

Hi,

Am 02.05.19 um 09:05 schrieb Ulrike Uhlig:
>> Well, but who has enabled AA in PC? I'm sure that I have not worked on
>> /etc in these days and I am the only one can access on it. In my opinion
>> there is a bug in some package update that has enabled TB AA profile...
>> but in effect I realize that to be believable someone else would find
>> this unbelievable behaviour...
> 
> Maybe you accidentally upgraded to Buster or you are using a kernel that
> has AA enabled by default.

the starting email of this bugreport is showing an installed kernel from
backports. So for me it's quite obvious *why* apparmor is installed and
has activated all the profiles for the various packages that come along
with AA profiles which should be also activated then.

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

I can remember we have such discussions again and again from time to
time and users are surprised why Thunderbird isn't working any more as
usual or expected after some random update. So far I remember it was
always an active TB AA profile. And users are even more surprised if I
tell them the TB packaging in Stretch did never had an automatically
activated AA profile, in other words, they have it activated it by
themselves.

In this report there are two things that have come together in my eyes.

1.) An activated AA profile for Thunderbird.

2.) An different path for ${HOME} because of an membership within a
Windows domain.

The first one isn't a big problem anymore in newer days, the current AA
profile is covering for sure about 95% of the use cases.
The second point isn't covered nicely until now in the AppArmor
installations within Debian at least. But I think also that Thunderbird
isn't the only package that will suffer from this problem and we will
need a more general solution for this. And this needs to go into
Apparmor itself instead of every body tries to implement some super
logic within their AA package profile.

Currently I've no idea how to detect a membership of a Windows domain
nicely, for sure this is solvable by some PAM voodoo. I have simply no
knowledge in this area. And I have no environment to test something. It
seems we just need to trigger a dpkg-reconfigure of AA if the PC is
within a domain membership.

-- 
Regards
Carsten Schoenert

Bug#928346: white_dune/wdune 0.30 can not display MovieTexture

[J. Scheurich]

Package: whitedune
Version: 0.30

white_dune/wdune 0.30 can not display MovieTexture,
white_dune/wdune 1.032 can.

Example to show the bug:

white_dune 0.30:

$ wget https://wdune.ourproject.org/examples/movietexture.wrl
$ wget https://wdune.ourproject.org/examples/movietexture.mpg
$ dune movietexture.wrl

shows a white box

The same with white_dune 1.032:

$ dune https://wdune.ourproject.org/examples/movietexture.wrl

if you press the play button, is shows the movie on the box.

white_dune 1.032 has a script to create a debian package under

wdune-1.032/packager/debian/mkdeb_stretch.sh

that worked for years

Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)

[Sergio Durigan Junior]

On Thursday, May 02 2019, Santiago Vila wrote:

>> >  export GEM2DEB_TEST_RUNNER = --check-dependencies
>> > +export MENTOS_TIMEOUT = 60
>> 
>> I like adding a comment explaining why this is needed; it can be just a
>> very brief phrase + a link to this bug.
>
> Ok, how about this?
>
> # The default is 8 seconds but it's not always enough for the test suite.
> # See #923986 for details.

Awesome!  Thanks.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)

[Santiago Vila]

> >  export GEM2DEB_TEST_RUNNER = --check-dependencies
> > +export MENTOS_TIMEOUT = 60
> 
> I like adding a comment explaining why this is needed; it can be just a
> very brief phrase + a link to this bug.

Ok, how about this?

# The default is 8 seconds but it's not always enough for the test suite.
# See #923986 for details.

Thanks.

Bug#927964: Fixed an exception that could occur

[Kristofer Hansson]

So I discovered that the previous patch wasn't exactly good in all
instances, It turns out that make can pass the jobserver-auth flag without
leaving the file-descriptors open.

I applied a check to see wether the file-descriptors was open before the
adding the descriptors fds to pass on. I opted to use os.stat() for this,
there may be a better way that I'm unaware of.

I've attached the patch this time instead
diff -Nru git-buildpackage-0.9.14/debian/changelog git-buildpackage-0.9.14+nmu1/debian/changelog
--- git-buildpackage-0.9.14/debian/changelog	2019-03-21 09:33:34.0 +
+++ git-buildpackage-0.9.14+nmu1/debian/changelog	2019-04-25 10:25:15.0 +
@@ -1,3 +1,11 @@
+git-buildpackage (0.9.14+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Made gbp buildpackage able to pass file-descriptors of an existing
+GNU Make job-server.
+
+ -- Kristofer Hansson   Thu, 25 Apr 2019 10:25:15 +
+
 git-buildpackage (0.9.14) unstable; urgency=medium
 
   [ Michael Prokop ]
diff -Nru git-buildpackage-0.9.14/gbp/command_wrappers.py git-buildpackage-0.9.14+nmu1/gbp/command_wrappers.py
--- git-buildpackage-0.9.14/gbp/command_wrappers.py	2019-01-08 19:15:13.0 +
+++ git-buildpackage-0.9.14+nmu1/gbp/command_wrappers.py	2019-04-25 10:25:15.0 +
@@ -75,7 +75,7 @@
 
 If cmd doesn't contain a path component it will be looked up in $PATH.
 """
-def __init__(self, cmd, args=[], shell=False, extra_env=None, cwd=None,
+def __init__(self, cmd, args=[], shell=False, extra_env=None, cwd=None, pass_fds=(),
  capture_stderr=False,
  capture_stdout=False):
 self.cmd = cmd
@@ -86,6 +86,7 @@
 self.capture_stdout = capture_stdout
 self.capture_stderr = capture_stderr
 self.cwd = cwd
+self.pass_fds = pass_fds
 if extra_env is not None:
 self.env = os.environ.copy()
 self.env.update(extra_env)
@@ -139,13 +140,15 @@
 stderr_arg = subprocess.PIPE if self.capture_stderr else stderr
 
 try:
+print(self.pass_fds)
 popen = subprocess.Popen(cmd,
  cwd=self.cwd,
  shell=self.shell,
  env=self.env,
  preexec_fn=default_sigpipe,
  stdout=stdout_arg,
- stderr=stderr_arg)
+ stderr=stderr_arg,
+ pass_fds=self.pass_fds)
 (self.stdout, self.stderr) = popen.communicate()
 if self.stdout is not None:
 self.stdout = self.stdout.decode()
diff -Nru git-buildpackage-0.9.14/gbp/scripts/buildpackage.py git-buildpackage-0.9.14+nmu1/gbp/scripts/buildpackage.py
--- git-buildpackage-0.9.14/gbp/scripts/buildpackage.py	2019-01-08 19:15:13.0 +
+++ git-buildpackage-0.9.14+nmu1/gbp/scripts/buildpackage.py	2019-04-25 10:25:15.0 +
@@ -335,6 +335,27 @@
 return branch
 
 
+def get_job_fds_from_env():
+makeflags = None
+try:
+makeflags = os.environ['MAKEFLAGS']
+except KeyError:
+return ()
+
+for flag in makeflags.split(' '):
+if flag.startswith('--jobserver-auth='):
+fds = flag.split('=')[1].split(',')
+# Verify that the file-descriptor is open.
+try:
+for fd in fds:
+os.stat(fd)
+except OSError:
+return ()
+return tuple(fds)
+else:
+return ()
+
+
 def build_parser(name, prefix=None):
 try:
 parser = GbpOptionParserDebian(command=os.path.basename(name), prefix=prefix)
@@ -510,6 +531,7 @@
 export_dir = os.path.join(output_dir, "%s-%s" % (source.sourcepkg, major))
 build_dir = export_dir if options.export_dir else repo.path
 changes_file = changes_file_name(source, build_dir, options.builder, dpkg_args)
+job_fds = get_job_fds_from_env()
 
 # Run preexport hook
 if options.export_dir and options.preexport:
@@ -563,6 +585,7 @@
 RunAtCommand(options.builder,
  [pipes.quote(arg) for arg in dpkg_args],
  shell=True,
+ pass_fds=job_fds,
  extra_env=Hook.md(build_env,
{'GBP_BUILD_DIR': build_dir})
  )(dir=build_dir)

Bug#928345: unblock: akonadi/4:18.08.3-5

[Sandro Knauß]

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

Please unblock package akonadi

Akonadi uses a working database to store all data. Mariadb moved
binaries between mariadb-server-10.3 and mariadb-server-core-10.3, that
made mariadb-server-core-10.3 unfit to be used from Akonadi. To solve
this temporarily Akonadi depends on default-mysql-server with
4:18.08.3-2.

Mariadb has now solved #910902 and 1:10.3.14-1 entered testing, now
mariadb-server-core-10.3 is good enough for Akonadi to start from a fresh
installation. When Akonadi still would depend on mariadb-server-10.3
a not needed database would spin up system wide.

unblock akonadi/4:18.08.3-5

diff -Nru akonadi-18.08.3/debian/changelog
akonadi-18.08.3/debian/changelog
--- akonadi-18.08.3/debian/changelog2019-02-14 21:07:51.0
+0100
+++ akonadi-18.08.3/debian/changelog2019-04-29 16:24:10.0
+0200
@@ -1,3 +1,13 @@
+akonadi (4:18.08.3-5) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Sandro Knauß ]
+  * Switch back to use default-mysql-server-core instead of default-
+mysql-server as dependency (see #910902).
+
+ -- Sandro Knauß   Mon, 29 Apr 2019 16:24:10 +0200
+
 akonadi (4:18.08.3-4) unstable; urgency=medium
  
 * Team upload.
 diff -Nru akonadi-18.08.3/debian/control
 akonadi-18.08.3/debian/control
 --- akonadi-18.08.3/debian/control  2019-02-05
 00:11:57.0 +0100
 +++ akonadi-18.08.3/debian/control  2019-04-29
 16:07:26.0 +0200
 @@ -47,7 +47,7 @@
  Section: misc
   Architecture: all
Depends: default-mysql-client-core | virtual-mysql-client-core,
- default-mysql-server | virtual-mysql-server,
+ default-mysql-server-core | virtual-mysql-server-core,
  libqt5sql5-mysql,
${misc:Depends},
 Recommends: akonadi-server

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

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

Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)

[Sergio Durigan Junior]

On Thursday, May 02 2019, Santiago Vila wrote:

> Hi. I finally found the reason for this build failure.

Great!

> This is from the README.md:
>
>   By default pygments.rb will timeout calls to pygments that take over 8
>   seconds. You can change this by setting the environmental variable
>   MENTOS_TIMEOUT to a different positive integer value.
>
> This is defined in line 257 in lib/pygments/popen.rb:
>
>   timeout_time = Integer(ENV["MENTOS_TIMEOUT"]) rescue 8
>
> Based on the above, this is what makes the build failure to be fully
> reproducible for me:
>
> export MENTOS_TIMEOUT=1
> dpkg-buildpackage
>
> (I'm going to give Sergio access to a system where the above works,
> just in case his computer is very fast).

Aha...  Good work!

BTW, I was able to reproduce the bug here by setting MENTOS_TIMEOUT=1,
so there's no need to give me access to the machine :-).

> Now, we can consider such low value (8) as a bug in itself, or we
> could just concentrate on the build failure.
>
> At the very minimum, and in my opinion, we should at least make the
> package to build ok for everybody, not just those having a "fast
> computer" (whatever that means). The end user must be able to modify
> and then rebuild the package without having to jump through hoops.
>
> I'm not talking about building on "very old computers" here, the
> failure happens on reproducible-builds.org, which is already a bad
> sign, and also on systems which are still in the VPS market right now
> (like the Scaleway instances).

Yeah, it seems like increasing the timeout is the most sensible thing to
do in our case.


> Proposed patch below.
>
> Thanks.
>
> --- a/debian/rules
> +++ b/debian/rules
> @@ -1,6 +1,7 @@
>  #!/usr/bin/make -f
>  
>  export GEM2DEB_TEST_RUNNER = --check-dependencies
> +export MENTOS_TIMEOUT = 60

I like adding a comment explaining why this is needed; it can be just a
very brief phrase + a link to this bug.

>  
>  %:
>   dh $@ --buildsystem=ruby --with ruby

Thanks for the patch.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#928340: Linux 4.9.0-9-686: Boot hangs on Geode LX.

[Ben Hutchings]

On Thu, 2019-05-02 at 14:44 +0200, Björn Persson wrote:
> Package: src:linux
> Version: 4.9.168-1
> Severity: critical
> File: /boot/vmlinuz-4.9.0-9-686
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> Debian 9 fails to boot on a Soekris net5501 with a Geode LX processor.
> Debian 8 worked fine. Running Debian 9 on Linux 3.16.0-8-586 from Debian
> 8 works. (That's what I'm running Reportbug on.) Linux 4.9.0-7-686,
> 4.9.0-8-686 and 4.9.0-9-686 appear to hang early in the boot process.
> The disk activity light remains lit when the system hangs. I'm attaching
> a boot log acquired over a serial console.
> 
> I'm reporting this against the kernel because replacing only the kernel
> works around the problem, but it looks like SystemD has been started
> when the hang occurs, so I suppose a userspace issue can't be completely
> ruled out.
> 
> Given that a kernel compiled for i586 works and one compiled for i686
> does not, one might suspect that the processor isn't i686-compatible.
> This seems to be rather unclear. According to the release notes this
> processor should still be supported. It has all of the flags that this
> script tests for:
> https://www.debian.org/releases/stretch/i386/release-notes/ch-information#i386-is-now-almost-i686
[...]

The Geode LX's CPUID has family=5 (586), but I agree with your
understanding that it has all the important features of a 686 and
should still be supported.  In fact, I've specifically enabled
continued support for it in the current (buster/sid) 686 kernel
configuration.

I'm afraid I don't have any immediate ideas for how to fix or debug
this.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.




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

Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)

[Santiago Vila]

severity 923986 serious
tags 923986 + patch
thanks

Hi. I finally found the reason for this build failure.

This is from the README.md:

  By default pygments.rb will timeout calls to pygments that take over 8
  seconds. You can change this by setting the environmental variable
  MENTOS_TIMEOUT to a different positive integer value.

This is defined in line 257 in lib/pygments/popen.rb:

  timeout_time = Integer(ENV["MENTOS_TIMEOUT"]) rescue 8

Based on the above, this is what makes the build failure to be fully
reproducible for me:

export MENTOS_TIMEOUT=1
dpkg-buildpackage

(I'm going to give Sergio access to a system where the above works,
just in case his computer is very fast).

Now, we can consider such low value (8) as a bug in itself, or we
could just concentrate on the build failure.

At the very minimum, and in my opinion, we should at least make the
package to build ok for everybody, not just those having a "fast
computer" (whatever that means). The end user must be able to modify
and then rebuild the package without having to jump through hoops.

I'm not talking about building on "very old computers" here, the
failure happens on reproducible-builds.org, which is already a bad
sign, and also on systems which are still in the VPS market right now
(like the Scaleway instances).

Proposed patch below.

Thanks.

--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export GEM2DEB_TEST_RUNNER = --check-dependencies
+export MENTOS_TIMEOUT = 60
 
 %:
dh $@ --buildsystem=ruby --with ruby

Bug#928344: qtchooser: Please build with -D_FILE_OFFSET_BITS=64

[John Paul Adrian Glaubitz]

Source: qtchooser
Version: 66-1
Severity: important
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

A change recently introduced to glibc with version 2.28 [1] has broken
some applications running in qemu-user when emulating 32-bit architectures
on 64-bit platforms [2].

As a result, any 32-bit application compiled without -D_FILE_OFFSET_BITS=64
will behave erratically when running on qemu-user on a 64-bit platform,
one affected package was dash [3] which has already been fixed although the
problem didn't show there in the context of qemu.

qtchooser suffers from this problem as well and the sympton is that running
qmake, for example, results in qtchooser unable to find the Qt5 installation:

(sid-sh4-sbuild)root@epyc:/# QT_SELECT=5 qmake
qmake: could not find a Qt installation of '5'
(sid-sh4-sbuild)root@epyc:/#

Luckily, there is a simply workaround which is adding the following to debian/
rules which results in qtchooser being built with -D_FILE_OFFSET_BITS=64:

export DEB_CXXFLAGS_MAINT_APPEND := -D_FILE_OFFSET_BITS=64

A locally built version of the package with the fix applied works correctly
again:

(sid-sh4-sbuild)root@epyc:/# dpkg -i qtchooser_66-1+qemu_sh4.deb
(Reading database ... 45935 files and directories currently installed.)
Preparing to unpack qtchooser_66-1+qemu_sh4.deb ...
Unpacking qtchooser (66-1+qemu) over (66-1) ...
Setting up qtchooser (66-1+qemu) ...
Processing triggers for man-db (2.8.5-2) ...
(sid-sh4-sbuild)root@epyc:/# QT_SELECT=5 qmake
Usage: /usr/lib/qt5/bin/qmake [mode] [options] [files]
(...)
  -nocache   Don't use a cache file  [makefile mode only]
  -nodepend  Don't generate dependencies [makefile mode only]
  -nomoc Don't generate moc targets  [makefile mode only]
  -nopwd Don't look for files in pwd [project mode only]
(sid-sh4-sbuild)root@epyc:/#

I would highly recommend to include this fix and even try to get it included
for Buster as otherwise anyone running Qt-related tools inside qemu-user
for 32-bit applications on 64-bit targets on Buster will run into this bug
(e.g., people running an armel chroot on x86_64).

Adrian

> [1] 
> https://sourceware.org/git/?p=glibc.git;a=commit;h=298d0e3129c0b5137f4989275b13fe30d0733c4d
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916255

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi

[Matthew Gabeler-Lee]

On Wed, 1 May 2019, Jamie Zawinski wrote:


-arabic-newspaper-medium-r-normal--19-140-100-100-p-0-iso10646-1


I'm gonna guess that this font, despite claiming to be 10646 (Unicode) does not 
actually contain Latin characters... So that's not ideal if your locale is set 
to one that requires those.


That sounds likely...


It looks like you've got a smattering of Arabic and Japanese fonts, but all of 
your Latin fonts are fixed-width! Is that intentional? By which I mean is, did 
you do this on purpose or is your distro doing this by default for some reason? 
Maybe you manually deleted some package that you shouldn't have?


It's certainly not intentinoal in the sense of uninstalling things.  But the
system in question _is_ an intentionally fairly minimal vm/container setup
for a specific build environment.  In particular, this container was setup
with APT::Install-Recommends (and Suggests) disabled.


Are any of your apps capable of displaying Latin letters in variable width? If 
so, my next question will be, what font are those apps finding and how?


Yep ...  Chrome, VS Code, all the basic LXDE apps, kdiff3, pgAdmin III,
LXTerminal's preferences screen, all render just fine.  but I think those
are all using TrueType fonts via fontconfig/etc, not "traditional" X11
fonts.

My list of installed packages providing files under /usr/share/fonts (i.e.
dpkg -S /usr/share/fonts passed through some cleanup) is:

fonts-cantarell
fonts-dejavu-core
fonts-dejavu-extra
fonts-droid-fallback:
fonts-freefont-ttf
fonts-hack
fonts-liberation
fonts-noto-cjk
fonts-noto-core
fonts-noto-mono
fonts-noto-ui-core
fonts-noto-unhinted
fonts-opensymbol
fonts-quicksand
fonts-roboto-unhinted
fonts-symbola
xfonts-base
xfonts-encodings
xfonts-scalable
xfonts-utils


The following patch might help: this will remove the wildcard font-family fallback, which 
should result in the xscreensaver dialogs being in "fixed" instead of that 
Arabic font. But I'd still like to understand how your machine got into this state, and 
how likely it is that others will also be dealing with similar configurations.


The patch works with precisely the expected effect, yes.

PS: Thanks for all your help following up on this :)

--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#928343: libs3: Update libs3 to the latest changes in the upstream repo

[online]

Source: libs3
Severity: wishlist

Dear Maintainer,

I would like to request that the libs3 package provided in debian be updated as 
it
currently prevents the bacula package from providing its cloud plugin[1].

Best,
bendem


[1] 
https://salsa.debian.org/bacula-team/bacula/commit/7dd8b63c3bbe5d9071cd22806de14510a266607b

Bug#927943: libxmlada: FTBFS with unicode-data >= 12.0.0

[Nicolas Boulenguez]

Package: src:libxmlada
Followup-For: Bug #927943

The attached patch builds libxmlada/18-3 against unicode-data/12.1.0.

According to a diff of generated sources, no existing symbol is
changed or removed, so it should be safe to keep the same SO version
for the binary library package.

I hope that no new ALI version is necessary for the -dev package. Each
recursive reverse dependency would then require trivial but manual
changes.
  gpr *
  dh-ada-library
  templates-parser *
  gnat-gps
  gnatcoll *
  gnatcoll-bindings *
  gnatcoll-db *
  asis *
  aws *
  adacontrol
  adabrowse
  log4ada *
Worst, the libraries (with a star) would require a passage through
NEW.  Such a transition is impossible so far in the freeze, so gpr
FTBFS in testing. Summary: buster would not support the Ada language.

I see no better option than uploading the fix with the same ALI,
and hope that all goes well.
* 
https://codesearch.debian.net/search?q=path%3A.*%5C.ad%5Bbs%5D+with%5C+Unicode%5C.Names%5C.=3
  seems to show that the generated packages are only directly referenced
  from libxmlada itself.
* The diff_alis.py script (once posted in debian-ada) says that no
  existing .ali checksum is modified between libxmlada/18-2 and 18-3
  (I fail to understand why most unicode-names-*.ads have no .ali file
  at all, but it is quite convenient right now).
* If some reverse dependencies FTBFS and must be removed, what do we
  loose compared to the current situation?

Of course, any better idea is welcome.
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libxmlada (18-4) unstable; urgency=medium
+
+  * Update to unicode version 12. Closes: #927943.
+
+ -- Nicolas Boulenguez   Thu, 02 May 2019 11:47:15 +0200
+
 libxmlada (18-3) unstable; urgency=medium
 
   * Update to unicode version 11, really closing #903380.
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@
 Build-Depends: debhelper (>= 11),
  gnat, gnat-8,
 # Note: the rules script parses this line to extract the gnat version.
- unicode-data (>= 11~), unicode-data (<< 12~),
+ unicode-data (>= 12~), unicode-data (<< 13~),
 # Used by debian/rules to generate unicode-names-*.ads.
 # When a new unicode standard is released, we most probably have to
 # increase the ALI version of xmlada-unicode and all reverse dependencies.
--- a/debian/patches/generate-unicode-9-names.diff
+++ b/debian/patches/generate-unicode-9-names.diff
@@ -14,7 +14,7 @@
  end Translators.Alias;
 --- a/unicode/importer/translators-block.adb
 +++ b/unicode/importer/translators-block.adb
-@@ -164,6 +164,10 @@
+@@ -164,6 +164,15 @@
 "Phags_Pa");
Add ("CJK Compatibility Forms",
 "Cjk_Compatibility_Forms");
@@ -22,6 +22,11 @@
 +  --  Unicode 9.
 +  Add ("Ideographic Symbols and Punctuation",
 +   "Ideograph_Symb_Punct");
++  --  Unicode 12.
++  Add ("Egyptian Hieroglyph Format Controls",
++   "Egypt_Hieroglyph_Fmt_Ctrl");
++  Add ("Symbols and Pictographs Extended-A",
++   "Symbols_Pictographs_Ext_A");
 end Set_Exceptions;
  
  end Translators.Block;

Bug#928342: libccid: ControlUSB Error

[Kyle Bentley]

Package: libccid
Version: 1.4.26-1
Severity: important

I am trying to use pcscd for the smart card reader on a lenovo thinkpad T550.  
I keep seeing errors in the
ControlUSB() function, citing LIBUSB_ERR (-7) in 'service status pcscd'.  The 
reader is identified as

Bus 001 Device 003: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader

The error in 'service status pcscd' is shown as

ccid_usb.c:1204:ControlUSB() control failed (1/3): -7 LIBUSB_ERROR_TIMEOUT

Thanks,

Kyle

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 libccid depends on:
ii  libc6 2.24-11+deb9u4
ii  libusb-1.0-0  2:1.0.21-1

libccid recommends no packages.

Versions of packages libccid suggests:
pn  pcmciautils  

-- no debconf information

Bug#928281: unblock: lemonldap-ng/2.0.2+ds-7 (pre-approval)

[Xavier]

Control: tags -1 - moreinfo

Le 01/05/2019 à 23:00, Niels Thykier a écrit :
> Control: tags -1 moreinfo confirmed
> 
> Xavier Guimard:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package lemonldap-ng
>>
>> Hi all,
>>
>> upstream authors of lemonldap-ng have updated language translations. I
>> imported updated translation files in a patch. Do you think it is
>> opportune to update lemonldap-ng package to have better l10n support in
>> Buster?
>>
>> Cheers,
>> Xavier
>>
>> unblock lemonldap-ng/2.0.2+ds-7
>>
>> [...]
> 
> Please go ahead with the upload and remove the moreinfo tag when it is
> in unstable and ready to be unblocked.
> 
> Thanks,
> ~Niels

Done, thanks a lot !

Bug#928341: ITP: golang-github-renekroon-ttlcache -- An in-memory string-interface{} map with various expiration options for golang

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-renekroon-ttlcache
  Version : 1.4.0+git20190429.e7780e9-1
  Upstream Author : Rene Kroon
* URL : https://github.com/ReneKroon/ttlcache
* License : MIT
  Programming Lang: Go
  Description : An in-memory string-interface{} map with various
expiration options for golang

TTLCache is a simple key/value cache in golang with the following functions:

  - Thread-safe
  - Individual expiring time or global expiring time, you can choose
  - Auto-Extending expiration on Get
  - DNS style TTL
  - Fast and memory efficient
  - Can trigger callback on key expiration

Project TTLCache was forked from wunderlist/ttlcache to add extra
functions not available in the original scope. The main differences are:

  - An item can store any kind of object, previously, only strings could
be saved
  - Optionally, you can add callbacks to: check if a value should
expire, be notified if a value expires, and be notified when new
values are added to the cache
  - The expiration can be either global or per item
  - Can exist items without expiration time
  - Expirations and callbacks are realtime

Bug#928328: Intel I350-NIC shuts down ports after loosing carrier

[Rene 'Renne' Bartsch, B.Sc. Informatics]

No, i210 and i219 detect the carrier correctly even when un-plugging and 
plugging back the cable.
Only the i350 fails to reconnect.

Regards,

Renne

Bug#926437: bsdmainutils: ncal week numbering for 2019 is off by one

[Pasi Savolainen]

Seems to be affected by `$LANG` (or derivative) as for example this
gives correct week number:

$ LANG=C ncal -w 01 2019
January 2019
Su 6 13 20 27
Mo 7 14 21 28
Tu  1  8 15 22 29
We  2  9 16 23 30
Th  3 10 17 24 31
Fr  4 11 18 25
Sa  5 12 19 26
1  2  3  4  5
$ echo $LANG
en_US.UTF-8
$ date +%V   # this works correctly regardless.
18


pasi

Bug#928340: Linux 4.9.0-9-686: Boot hangs on Geode LX.

[Björn Persson]

Package: src:linux
Version: 4.9.168-1
Severity: critical
File: /boot/vmlinuz-4.9.0-9-686
Justification: breaks the whole system

Dear Maintainer,

Debian 9 fails to boot on a Soekris net5501 with a Geode LX processor.
Debian 8 worked fine. Running Debian 9 on Linux 3.16.0-8-586 from Debian
8 works. (That's what I'm running Reportbug on.) Linux 4.9.0-7-686,
4.9.0-8-686 and 4.9.0-9-686 appear to hang early in the boot process.
The disk activity light remains lit when the system hangs. I'm attaching
a boot log acquired over a serial console.

I'm reporting this against the kernel because replacing only the kernel
works around the problem, but it looks like SystemD has been started
when the hang occurs, so I suppose a userspace issue can't be completely
ruled out.

Given that a kernel compiled for i586 works and one compiled for i686
does not, one might suspect that the processor isn't i686-compatible.
This seems to be rather unclear. According to the release notes this
processor should still be supported. It has all of the flags that this
script tests for:
https://www.debian.org/releases/stretch/i386/release-notes/ch-information#i386-is-now-almost-i686

On the debian-user mailing list, some people say that support for Geode
LX has been dropped. Others say it should work. If it is actually no
longer supported, then please reassign this bug report to the release
notes. In that case the release notes should be updated to document
this, and provide an accurate test.

As near as I can tell this processor is a Geode LX 800. The bios boot
screen calls it "Geode LX 500 MHz". It looks very much like this:
https://commons.wikimedia.org/wiki/File:AMD_Geode_LX_800_CPU.jpg

The text on the processor is:

AMD
Geode
ALXC800EETJCVC
0703CQA
2003-05 C1
TAIWAN

$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 10
model name  : Geode(TM) Integrated Processor by AMD PCS
stepping: 2
microcode   : 0x8b
cpu MHz : 499.900
cache size  : 128 KB
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 
3dnowext 3dnow vmmcall
bogomips: 999.80
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information

** PCI devices:
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode 
companion] Host Bridge [1022:2080] (rev 31)
Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] 
Host Bridge [1022:2080]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: via-rhine
Kernel modules: via_rhine

00:07.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] 
[1106:3053] (rev 96)
Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: via-rhine
Kernel modules: via_rhine

00:08.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] 
[1106:3053] (rev 96)
Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: via-rhine
Kernel modules: via_rhine

00:09.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] 
[1106:3053] (rev 96)
Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: via-rhine
Kernel modules: via_rhine

00:14.0 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode 
companion] ISA [1022:2090] (rev 03)
Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] 
ISA [1022:2090]
Control: I/O+ Mem- BusMaster- SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
ii  grub-pc 2.02~beta3-5+deb9u1
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-9-686 is related to:
pn  firmware-amd-graphics 

Bug#928339: libdw-dev doesn't install required liblzma-dev

[Eero Tamminen]

Package: libdw-dev
Version: 0.168-1

This is in Debian Stretch:
https://packages.debian.org/stretch/libdw-dev

# sudo apt install libdw-dev
$ /usr/bin/pkg-config --cflags libdw
Package liblzma was not found in the pkg-config search path.
Perhaps you should add the directory containing `liblzma.pc'
to the PKG_CONFIG_PATH environment variable
Package 'liblzma', required by 'libdw', not found

Package dependency seems to be fixed in Buster:
https://packages.debian.org/buster/libdw-dev

Bug#928254: gcc-8: -static-libasan does not work with GNU MPFR

[Vincent Lefevre]

Control: forcemerge 751161 928254

Bug 751161 concerns the same issue. It mentions the -fsanitizer= flags,
which had been fixed some time ago in libtool, but -static-libasan is
still stripped.

The gcc man page says:

  Linker Options
  object-file-name  -fuse-ld=linker  -llibrary -nostartfiles
  -nodefaultlibs  -nostdlib  -pie  -pthread  -rdynamic -s  -static
  -static-libgcc  -static-libstdc++ -static-libasan  -static-libtsan
  -static-liblsan  -static-libubsan -static-libmpx
  -static-libmpxwrappers -shared  -shared-libgcc  -symbolic -T script
  -Wl,option  -Xlinker option -u symbol  -z keyword

so that some other options may also be concerned (see below the
current list of flags that are passed through unchanged).

On 2019-05-02 14:06:03 +0200, Vincent Lefevre wrote:
> On 2019-05-02 10:10:33 +0200, Vincent Lefevre wrote:
> > On 2019-05-01 20:54:05 +0200, Matthias Klose wrote:
> > > the linker never sees your CFLAGS. At least -static-libasan needs to
> > > be added to LDFLAGS.

Actually adding it to LDFLAGS too does not solve the problem.
libtool strips -static-libasan even in this case.

> > Indeed, I can see -static-libasan in the "libtool --mode=link" line,
> > but libtool drops this option in the gcc call:
> > 
> > /bin/sh ../libtool  --tag=CC   --mode=link gcc  -O0 -march=native 
> > -fsanitize=address -static-libasan   -version-info 6:0:0 
> > -Wl,--disable-new-dtags -o libmpfr.la -rpath /usr/local/lib [.lo files]  
> > -lgmp
> > libtool: link: gcc -shared  -fPIC -DPIC  [.o files]  -lgmp  -O0 
> > -march=native -fsanitize=address -Wl,--disable-new-dtags   -Wl,-soname 
> > -Wl,libmpfr.so.6 -o .libs/libmpfr.so.6.0.0
> > 
> > Why does libtool do that, while it preserves
> > "-O0 -march=native -fsanitize=address"?
> 
> I can see that the libtool script contains:
> 
>   # Flags to be passed through unchanged, with rationale:
>   # -64, -mips[0-9]  enable 64-bit mode for the SGI compiler
>   # -r[0-9][0-9]*specify processor for the SGI compiler
>   # -xarch=*, -xtarget=* enable 64-bit mode for the Sun compiler
>   # +DA*, +DD*   enable 64-bit mode for the HP compiler
>   # -q*  compiler args for the IBM compiler
>   # -m*, -t[45]*, -txscale* architecture-specific flags for GCC
>   # -F/path  path to uninstalled frameworks, gcc on darwin
>   # -p, -pg, --coverage, -fprofile-*  profiling flags for GCC
>   # -fstack-protector*   stack protector flags for GCC
>   # @fileGCC response files
>   # -tp=*Portland pgcc target processor selection
>   # --sysroot=*  for sysroot support
>   # -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time 
> optimization
>   # -specs=* GCC specs files
>   # -stdlib=*select c++ std lib with clang
>   # -fsanitize=* Clang/GCC memory and address sanitizer
>   # -fuse-ld=*   Linker select flags for GCC
>   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
>   
> -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
>   
> -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
>   -specs=*|-fsanitize=*|-fuse-ld=*)
> func_quote_for_eval "$arg"
> arg=$func_quote_for_eval_result
> func_append compile_command " $arg"
> func_append finalize_command " $arg"
> func_append compiler_flags " $arg"
> continue
> ;;
> 
> i.e. it misses the -static-libasan flag.
> 
> Reassigning to libtool.

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

Bug#928338: unblock: mhc/1.2.1-2

[Tatsuya Kinoshita]

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

Please unblock the mhc package (priority: optional) to fix the
important bug #928305.  See also the attached debdiff.

Changes:
 mhc (1.2.1-2) unstable; urgency=medium
 .
   * New patch 030_reiwa.patch to support Japan's new era 令和 (Reiwa)
 and new holidays (closes: #928305)

unblock mhc/1.2.1-2

Thanks,
--
Tatsuya Kinoshita
diffstat for mhc-1.2.1 mhc-1.2.1

 changelog   |7 ++
 patches/030_reiwa.patch |  130 
 patches/series  |1 
 3 files changed, 138 insertions(+)

diff -Nru mhc-1.2.1/debian/changelog mhc-1.2.1/debian/changelog
--- mhc-1.2.1/debian/changelog  2019-01-26 16:57:13.0 +0900
+++ mhc-1.2.1/debian/changelog  2019-05-02 20:17:00.0 +0900
@@ -1,3 +1,10 @@
+mhc (1.2.1-2) unstable; urgency=medium
+
+  * New patch 030_reiwa.patch to support Japan's new era 令和 (Reiwa)
+and new holidays (closes: #928305)
+
+ -- Tatsuya Kinoshita   Thu, 02 May 2019 20:17:00 +0900
+
 mhc (1.2.1-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru mhc-1.2.1/debian/patches/030_reiwa.patch 
mhc-1.2.1/debian/patches/030_reiwa.patch
--- mhc-1.2.1/debian/patches/030_reiwa.patch1970-01-01 09:00:00.0 
+0900
+++ mhc-1.2.1/debian/patches/030_reiwa.patch2019-05-02 06:55:33.0 
+0900
@@ -0,0 +1,130 @@
+Subject: Support Japan's new era 令和 (Reiwa) and new holidays
+Author: KOIE Hidetaka 
+Bug: https://github.com/yoshinari-nomura/mhc/pull/49
+Bug: https://github.com/yoshinari-nomura/mhc/pull/50
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928305
+
+diff --git a/emacs/mhc-calendar.el b/emacs/mhc-calendar.el
+index d403ec3..5c0635c 100644
+--- a/emacs/mhc-calendar.el
 b/emacs/mhc-calendar.el
+@@ -1071,11 +1071,13 @@ The keys that are defined for mhc-calendar-mode are:
+   (format "%4d" yy))
+ 
+ (defun mhc-calendar/inserter-nengo ()
+-  (if (> yy 1987)
+-  (format "平成%2d年" (- yy 1988))
+-(if (> yy 1924)
+-(format "昭和%2d年" (- yy 1925))
+-  "昔々")))
++  (if (or (> yy 2019) (and (= yy 2019) (> mm 4)))
++  (format "令和%2d年" (- yy 2018))
++(if (> yy 1987)
++(format "平成%2d年" (- yy 1988))
++  (if (> yy 1924)
++  (format "昭和%2d年" (- yy 1925))
++"昔々"
+ 
+ (defun mhc-calendar/inserter-mm ()
+   (format "%d" mm))
+diff --git a/samples/japanese-holidays.mhcc b/samples/japanese-holidays.mhcc
+index b1083c0..93409df 100644
+--- a/samples/japanese-holidays.mhcc
 b/samples/japanese-holidays.mhcc
+@@ -72,12 +72,14 @@ X-SC-Record-Id: 5E03776A-4280-4337-85C0-F1322A3AAE6E
+ 
+ X-SC-Subject: 海の日
+ X-SC-Category: Holiday Japanese
++X-SC-Day: !20200720
+ X-SC-Cond: 3rd Mon Jul
+ X-SC-Duration: 20030701-
+ X-SC-Record-Id: BD4156C2-5546-4146-8297-09CF4210A346
+ 
+ X-SC-Subject: 山の日
+ X-SC-Category: Holiday Japanese
++X-SC-Day: !20200811
+ X-SC-Cond: 11 Aug
+ X-SC-Duration: 20160811-
+ X-SC-Record-Id: FC7C481B-7BF5-4639-B700-3B60CB99E05D
+@@ -103,9 +105,16 @@ X-SC-Record-Id: AFABC42C-2E9D-4093-A4AF-DA12D4D4B9D7
+ X-SC-Subject: 体育の日
+ X-SC-Category: Holiday Japanese
+ X-SC-Cond: 2nd Mon Oct
+-X-SC-Duration: 20001009-
++X-SC-Duration: 20001009-20191231
+ X-SC-Record-Id: C17D9CA5-28AF-4826-AD33-8B75473E5B52
+ 
++X-SC-Subject: スポーツの日
++X-SC-Category: Holiday Japanese
++X-SC-Day: !20201012
++X-SC-Cond: 2nd Mon Oct
++X-SC-Duration: 20200101-
++X-SC-Record-Id: F10B2B18-B0FB-477E-A7D3-A067B31F4736
++
+ X-SC-Subject: 文化の日
+ X-SC-Category: Holiday Japanese
+ X-SC-Cond: 3 Nov
+@@ -121,9 +130,15 @@ X-SC-Record-Id: 97E6F125-2625-44A9-8D43-A6FCA9670D8D
+ X-SC-Subject: 天皇誕生日
+ X-SC-Category: Holiday Japanese
+ X-SC-Cond: 23 Dec
+-X-SC-Duration: 19891223-
++X-SC-Duration: 19891223-20190430
+ X-SC-Record-Id: 51D42B0D-EF46-4D65-B62A-6ED2F0D1F0B5
+ 
++X-SC-Subject: 天皇誕生日
++X-SC-Category: Holiday Japanese
++X-SC-Cond: 23 Feb
++X-SC-Duration: 20190501-
++X-SC-Record-Id: 59B83B1E-6161-45F5-9DEC-95E3C1CCA4EE
++
+ ## 毎年変わる祝日と振替休日
+ 
+ X-SC-Subject: 即位の日
+@@ -131,6 +146,26 @@ X-SC-Day: 20190501
+ X-SC-Category: Holiday Japanese
+ X-SC-Record-Id: 25C73788-1104-42BE-85F6-570861B0020B
+ 
++X-SC-Subject: 即位礼正殿の儀
++X-SC-Category: Holiday Japanese
++X-SC-Day: 20191022
++X-SC-Record-Id: 76F9756D-C00F-47D0-9592-67E21909C39D
++
++X-SC-Subject: 海の日
++X-SC-Category: Holiday Japanese
++X-SC-Day: 20200723
++X-SC-Record-Id: B9B9AC80-9424-496D-933D-CFF9876ECA5A
++
++X-SC-Subject: スポーツの日
++X-SC-Category: Holiday Japanese
++X-SC-Day: 20200724
++X-SC-Record-Id: AA0F053E-6DD0-4207-A1D0-196567FD94D6
++
++X-SC-Subject: 山の日
++X-SC-Category: Holiday Japanese
++X-SC-Day: 20200810
++X-SC-Record-Id: 87152AA3-7AEE-4689-835F-B19399E694DE
++
+ X-SC-Subject: 春分の日
+ X-SC-Day: 19960320 19970320 19980321 19990321 2320 20010320 20020321
+   20030321 20040320 20050320 20060321 20070321 20080320 20090320
+@@ -163,14 +198,14 @@ X-SC-Day: 19730430 19730924 19740506 19740916 19741104 
19751124
+   20050321 

Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)

[Santiago Vila]

Simple question:

Given that this "heisenbug" has happened in my own autobuilders, using
sbuild, and also in reproducible-builds, using pbuilder:

https://tests.reproducible-builds.org/debian/logs/buster/armhf/ruby-pygments.rb_1.2.0-2.build2.log.gz

and the way it fails is the same, would it make sense to mark the test as XFAIL 
anyway?

Thanks.

Bug#928254: gcc-8: -static-libasan does not work with GNU MPFR

[Matthias Klose]

On 02.05.19 14:06, Vincent Lefevre wrote:
> Control: reassign -1 libtool 2.4.6-10
> Control: retitle -1 libtool: "Flags to be passed through unchanged" should 
> include -static-libasan
> Control: severity -1 normal
> 
> On 2019-05-02 10:10:33 +0200, Vincent Lefevre wrote:
>> On 2019-05-01 20:54:05 +0200, Matthias Klose wrote:
>>> the linker never sees your CFLAGS. At least -static-libasan needs to
>>> be added to LDFLAGS.
>>
>> Indeed, I can see -static-libasan in the "libtool --mode=link" line,
>> but libtool drops this option in the gcc call:
>>
>> /bin/sh ../libtool  --tag=CC   --mode=link gcc  -O0 -march=native 
>> -fsanitize=address -static-libasan   -version-info 6:0:0 
>> -Wl,--disable-new-dtags -o libmpfr.la -rpath /usr/local/lib [.lo files]  
>> -lgmp
>> libtool: link: gcc -shared  -fPIC -DPIC  [.o files]  -lgmp  -O0 
>> -march=native -fsanitize=address -Wl,--disable-new-dtags   -Wl,-soname 
>> -Wl,libmpfr.so.6 -o .libs/libmpfr.so.6.0.0
>>
>> Why does libtool do that, while it preserves
>> "-O0 -march=native -fsanitize=address"?
> 
> I can see that the libtool script contains:
> 
>   # Flags to be passed through unchanged, with rationale:
>   # -64, -mips[0-9]  enable 64-bit mode for the SGI compiler
>   # -r[0-9][0-9]*specify processor for the SGI compiler
>   # -xarch=*, -xtarget=* enable 64-bit mode for the Sun compiler
>   # +DA*, +DD*   enable 64-bit mode for the HP compiler
>   # -q*  compiler args for the IBM compiler
>   # -m*, -t[45]*, -txscale* architecture-specific flags for GCC
>   # -F/path  path to uninstalled frameworks, gcc on darwin
>   # -p, -pg, --coverage, -fprofile-*  profiling flags for GCC
>   # -fstack-protector*   stack protector flags for GCC
>   # @fileGCC response files
>   # -tp=*Portland pgcc target processor selection
>   # --sysroot=*  for sysroot support
>   # -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time 
> optimization
>   # -specs=* GCC specs files
>   # -stdlib=*select c++ std lib with clang
>   # -fsanitize=* Clang/GCC memory and address sanitizer
>   # -fuse-ld=*   Linker select flags for GCC
>   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
>   
> -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
>   
> -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
>   -specs=*|-fsanitize=*|-fuse-ld=*)
> func_quote_for_eval "$arg"
> arg=$func_quote_for_eval_result
> func_append compile_command " $arg"
> func_append finalize_command " $arg"
> func_append compiler_flags " $arg"
> continue
> ;;
> 
> i.e. it misses the -static-libasan flag.

apparently it's missing *any* -static-* flag.

Bug#928254: gcc-8: -static-libasan does not work with GNU MPFR

[Vincent Lefevre]

Control: reassign -1 libtool 2.4.6-10
Control: retitle -1 libtool: "Flags to be passed through unchanged" should 
include -static-libasan
Control: severity -1 normal

On 2019-05-02 10:10:33 +0200, Vincent Lefevre wrote:
> On 2019-05-01 20:54:05 +0200, Matthias Klose wrote:
> > the linker never sees your CFLAGS. At least -static-libasan needs to
> > be added to LDFLAGS.
> 
> Indeed, I can see -static-libasan in the "libtool --mode=link" line,
> but libtool drops this option in the gcc call:
> 
> /bin/sh ../libtool  --tag=CC   --mode=link gcc  -O0 -march=native 
> -fsanitize=address -static-libasan   -version-info 6:0:0 
> -Wl,--disable-new-dtags -o libmpfr.la -rpath /usr/local/lib [.lo files]  -lgmp
> libtool: link: gcc -shared  -fPIC -DPIC  [.o files]  -lgmp  -O0 -march=native 
> -fsanitize=address -Wl,--disable-new-dtags   -Wl,-soname -Wl,libmpfr.so.6 -o 
> .libs/libmpfr.so.6.0.0
> 
> Why does libtool do that, while it preserves
> "-O0 -march=native -fsanitize=address"?

I can see that the libtool script contains:

  # Flags to be passed through unchanged, with rationale:
  # -64, -mips[0-9]  enable 64-bit mode for the SGI compiler
  # -r[0-9][0-9]*specify processor for the SGI compiler
  # -xarch=*, -xtarget=* enable 64-bit mode for the Sun compiler
  # +DA*, +DD*   enable 64-bit mode for the HP compiler
  # -q*  compiler args for the IBM compiler
  # -m*, -t[45]*, -txscale* architecture-specific flags for GCC
  # -F/path  path to uninstalled frameworks, gcc on darwin
  # -p, -pg, --coverage, -fprofile-*  profiling flags for GCC
  # -fstack-protector*   stack protector flags for GCC
  # @fileGCC response files
  # -tp=*Portland pgcc target processor selection
  # --sysroot=*  for sysroot support
  # -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time 
optimization
  # -specs=* GCC specs files
  # -stdlib=*select c++ std lib with clang
  # -fsanitize=* Clang/GCC memory and address sanitizer
  # -fuse-ld=*   Linker select flags for GCC
  -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
  -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| 
\
  -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| 
\
  -specs=*|-fsanitize=*|-fuse-ld=*)
func_quote_for_eval "$arg"
arg=$func_quote_for_eval_result
func_append compile_command " $arg"
func_append finalize_command " $arg"
func_append compiler_flags " $arg"
continue
;;

i.e. it misses the -static-libasan flag.

Reassigning to libtool.

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

Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)

[Santiago Vila]

severity 923986 important
thanks

Sorry, I was able to reproduce this on five different autobuilders,
but when I try to reproduce it in manual mode, the bug does not want
to show. Unfortunately, this is a "heisenbug".

I still believe there is a problem somewhere, but given the circumstances,
downgrading is the only sensible thing to do, at least until I can
"reproduce the randomness", so to speak.

My feeling is that this may have something to do with filesystem
ordering (i.e. the kind of thing which sometimes make packages not to
build reproducibly), because of this message which is shown in the
failed build logs:

/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59: warning:
loading in progress, circular require considered harmful -
/usr/lib/ruby/2.5.0/pp.rb

Does this mean something to you? Could it be that this "circular" thing
makes the unit test to become unpredictable?

Do the build logs I provided give any hint about what could be the
problem?

Thanks.

Bug#928185: unblock: openjdk-11/11.0.3+7-4

[Matthias Klose]

Control: tags -1 - moreinfo
Control: tags -1 + wontfix

On 02.05.19 10:30, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> Hi Matthias,
> 
> On Mon, Apr 29, 2019 at 06:12:36PM +0200, Matthias Klose wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock openjdk-11/11.0.3+7-4. That's the quarterly security update 
>> and
>> should be released with buster.  No more updates planned until the next 
>> security
>> update in July.
> 
> From what I understand bug#926009 is a regression in that version.
> There's no explanation that I can see for that change, no associated
> bug, and it doesn't look appropriate.  Please revert it.

No. The issue is in the LibreOffice package, which already has this fixed in
testing. The openjdk package also has an appropriate Breaks.

Bug#927269: grubarm.efi crashes

[Leif Lindholm]

On Wed, Apr 17, 2019 at 07:32:34AM +0100, Colin Watson wrote:
> On Wed, Apr 17, 2019 at 08:04:57AM +0200, Heinrich Schuchardt wrote:
> > Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
> > boundary") grubarm.efi crashes.
> > 
> > Hence I suggest to revert this patch for when building packages
> > grub-efi-arm*.
> > 
> > According to the author of the problematic patch without the patch Qcom
> > ARM notebooks did not work. So we better do not revert it for aarch64
> > until a final solution is found.
> 
> I'm not going to revert a patch when building for one architecture but
> not for another.  I'm happy to apply follow-up patches if people with
> access to the right hardware point me to suitable ones (and preferably
> get them upstream first).
> 
> > The upstream report is here:
> > http://lists.gnu.org/archive/html/grub-devel/2019-04/msg00075.html
> 
> Alexander, Leif, any comment here?

This 2-patch series posted to grub-devel by Alex Tuesday evening
resolves this issue:
https://lists.gnu.org/archive/html/grub-devel/2019-04/msg00130.html

1/2 also satisfactorily explains why there was a difference in
behaviour between images generated by grub-mkimage and
grub-mkstandalone (trampolines spilling over into different sections).

>From code review as well as some (but not exhaustive) testing, this
seems like a no-op for all !armhf platforms.

Could these two patches be cherry-picked into Buster please?

/
Leif

Bug#928328: Intel I350-NIC shuts down ports after loosing carrier

[Harald Dunkel]

Are other Intel NICs affected by this problem as well?

Regards
Harri

Bug#928337: salt: salt-minion falls into endless loop after upgrade from stretch to buster and fills all the free space on disk with stacktraces into log files

[Tomas Lamr]

Package: salt-minion
Version: 2018.3.4~git20180207+dfsg1-1
Severity: important
File: salt

Dear Maintainer,

   * What led up to the situation?
   
   Just upgrade from stretch do buster. It happens when minion id has 16
   chars or if (in our case) any machine dns hostname is 16chars long
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   I patched the _compat.py directly as shown here 
https://github.com/saltstack/salt/pull/51931
   The upstream git project has the fix, but it is missing in debian
   package.

   * What was the outcome of this action?
   
   Applying the oneline fix made it work.
   
   * What outcome did you expect instead?

   I expected that upgrade from strech to buster won't broke my remote
   server. 

Thanks a lot for taking a look into this,
Tomas

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

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

Versions of packages salt-minion depends on:
ii  bsdmainutils 11.1.2+b1
ii  dctrl-tools  2.24-3
ii  lsb-base 10.2019031300
ii  python3  3.7.2-1
ii  python3-crypto   2.6.1-9+b1
ii  python3-systemd  234-2+b1
ii  python3-zmq  17.1.2-2
ii  salt-common  2018.3.4~git20180207+dfsg1-1

Versions of packages salt-minion recommends:
ii  debconf-utils  1.5.71
ii  dmidecode  3.2-1
ii  e2fsprogs  1.44.5-1
pn  sfdisk 

Versions of packages salt-minion suggests:
pn  python3-augeas  

-- Configuration Files:
/etc/salt/minion changed [not included]

-- no debconf information

Bug#928336: Suggestion: Separate client and server packages.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: shadowsocks-libev
Version: 3.2.5+ds-1

Please separate the package into "shadowsocks-libev-client" which only contains 
"ss-local",
and "shadowsocks-libev-server" which contains the rest of the suite like 
"ss-server" and the system service.
The reason is that most of the ShadowSocks users only need the client to access 
forbidden websites,
and there is no point to run both the client and the server on the same host.
-
Please limit your reply to 7-bit ASCII.
I refuse to see your idiotic emoji in a TTY.
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJcysXNAAoJENi1YDlFXXQfe58IALpRBSp91Llji9XbVcuF
UGHWM2lNSrFqaG7Tw+ScV8hxyfJFsqH5MBB83J/39CJvIYU6FlD3xlzDRgY6
XuZbQ0gUimi/CyvLPNGPJSgNkjFMWj2DGbtfQGARN+pg1xQz3iGIu+jkPq/O
5z7F1MtdhXuu5Zuymtmx7ZO4JH4GPTJbtU9MnedotMN1JagHAWQTd7wp94aQ
TdQMOQ3LUoMBYl9TGm49ZYa+nVxm0XW570K6jwUtw1g/4QPJa2IRp09bdBs4
NneIVYMMvW74uUzbOzu4Er16F+SWtam0dwa60zKtS0LqOfu92lXyNfHcHslT
JymkN1I7ksMcnnnMsYvvhlc=
=2I8E
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#926903: Installation-report addition

[Ben Hutchings]

On Thu, 2019-05-02 at 12:00 +1000, Tom Thekathyil wrote:
> Hi Ben,
> 
> I ran 'update-initramfs -u' and got several lines saying
> 
> 'W: Possible missing firmware /lib/firmware/amdgpu/vega20_ xxx for
> module a[off screen here]pu' where xxx refers to different items.
> 
> Regards, Tom Thekathyil

Yes, that's expected at the moment but those shouldn't be needed on
your system.  I should have said, you need to reboot after this.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.




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

Bug#928335: dfu-programmer: Unavailable packaging repo

[Lee Garrett]

Package: dfu-programmer
Version: 0.6.1-1+b1
Severity: normal

Hi, 

debian/control lists the following:

Vcs-Browser: https://gitorious.org/debian-packaging/dfu-programmer/trees/master
Vcs-Git: git://gitorious.org/debian-packaging/dfu-programmer.git

However, both URLs are unavailable, so it's unclear where to reach the VCS of
the debian packaging. It would be great if you could push the git history to a
new repo under the salsa umbrella, e.g. 
https://salsa.debian.org/debian/dfu-programmer

Thanks in advance!
~Lee

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

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

Versions of packages dfu-programmer depends on:
ii  libc6 2.28-8
ii  libusb-1.0-0  2:1.0.22-2

dfu-programmer recommends no packages.

dfu-programmer suggests no packages.

-- no debconf information

Bug#928299: installation-reports: network-console doesnt set password hash, ssh not possible

[Frank Gard]

Dear Cyril,

Am 02.05.19 um 10:32 schrieb Cyril Brulebois:
> Control: tag -1 patch pending

that sounds good…

> Control: reassign -1 network-console
>
> […]
>
> It seems crypt() is no longer declared as it used to, and we get
> implicit function declaration warnings from gcc, which later explains
> the segfault at runtime.
>
> The declaration is guarded by __USE_MISC but #define'ing it doesn't seem
> to be sufficient. I've decided to add a  include, which seems
> to do the trick: gen-crypt no longer segfaults, and seems to return
> suitable results on my amd64 machine:
>
> kibi@armor:~/debian-installer/packages/network-console$ ./gen-crypt foo
> $1$g.dM$EJhR11EsVD5jY1Smnomsc0A
>
> Source uploaded to the archive (1.81), then it'll get picked up by the
> buildds[1] and later made available in daily builds. It'd be nice if you
> could double check that the runtime within d-i is also fine.
>
>  1. https://buildd.debian.org/status/package.php?p=network-console=sid
>
> Thanks again for the report & follow-ups (und vielen Dank zu Marc for
> the initial forward from the user list).

Many, many thanks to all involved people for your immediate help. I'm looking 
very forward to one of the next of Buster's weekly-builds :) .

> Cheers,

Have a nice day,
Frank.

eXirius IT Dienstleistungen GmbH
Juchem-Straße 24 | 66571 Eppelborn
T +49 6881 5 0 | i...@exirius.de
http://www.exirius.de

Amtsgericht Saarbrücken HRB 12124
Geschäftsführer: Dipl.-Math. oec. Michael Royar

Bug#928334: iputils FTCBFS: Uses the build architecture compiler

[Nguyen Van. Hieu]

Source: iputils
Version: 3:20180629-2
Severity: normal
Tags: patch
User:helm...@debian.org
Usertags: rebootstrap

Hi,

iputils fails to cross build from source, because it uses the build
architecture compiler.
Using "dh_auto_build" instead of "$(MAKE)" can solve this problem.
Please consider applying the attached patch.

Hieu.

diff -Nru iputils-20180629/debian/rules iputils-20180629/debian/rules
--- iputils-20180629/debian/rules   2018-08-03 23:53:09.0 +0700
+++ iputils-20180629/debian/rules   2018-08-03 23:53:09.0 +0700
@@ -17,11 +17,11 @@
 
 build-arch: configure
dh_testdir
-   $(MAKE) $(TARGETS)
+   dh_auto_build -- $(TARGETS)
 
 build-indep: configure
dh_testdir
-   $(MAKE) -C doc man
+   dh_auto_build -- -C doc man
 
 build: build-arch build-indep
 
-- 
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com