Bug#927268: Subject: nestopia: Can't map input to some keys on keyboard.

[master]

Subject: nestopia: Can't map Nes input to some keys on keyboard.
Package: nestopia
Version: 1.49-2
Severity: normal

Dear Maintainer,

I was playing Zelda using nestopia and I wanted to map the attack
button(The a button on the nes controller) to the j key on my keyboard.
I wasn't able to, when I tried to attack with the sword it wouldn't let
me. The movement input could be mapped to different keys but only some
of them would work such as the wasd keys. The attack button works on the 
z key and the movement


keys work with the arrows keys.

-- 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/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

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

Versions of packages nestopia depends on:
ii  libao4    1.2.2+20180113-1
ii  libarchive13  3.3.3-4
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-8
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libepoxy0 1.5.3-0.1
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-0    2.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-0    3.24.5-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libpango-1.0-0    1.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libsdl2-2.0-0 2.0.9+dfsg1-1
ii  libstdc++6    8.3.0-6
ii  zlib1g    1:1.2.11.dfsg-1

nestopia recommends no packages.

nestopia suggests no packages.

-- no debconf information

Bug#927267: nitroshare: Nitroshare on pc is undiscoverable by nitroshare on mobile, and vice versa, due to old version

[jim_p]

Package: nitroshare
Version: 0.3.3-1.1
Severity: important

Dear Maintainer,

As described in the title, nitroshare on the pc is not visible from the
nitroshare app on the (android) phone.

Steps to reproduce
- install nitroshare from the repo (apt-get install nitroshare), which installs
version 0.33
- install nitroshare from the play store on the android phone, which installs
version 0.4.0.37
- launch both and try sending a file from one to the other
- notice neither of the 2 can detect the other, so the transfer can not be
made.

However, the transfer can be made between my 2 phones (android 4.3 and android
9), because they use the same version of the app probably.
On top of that, the transfer can also be made with nitroshare 0.34, because I
tested it with a friend running arch and both my phones.

So please update the app.
Version 0.34 has been out since mid October 2017, ~1.5 years ago, so I assume
there is no excuse that the reupload on the repo (made on early March 2019) was
on 0.33.



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

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

Versions of packages nitroshare depends on:
ii  libappindicator1 0.4.92-7
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-8
ii  libcairo21.16.0-4
ii  libdbusmenu-glib418.10.20180917~bzr490+repack1-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libqhttpengine0  0.1.0+dfsg1-1+b2
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5svg5   5.11.3-2
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-6

nitroshare recommends no packages.

Versions of packages nitroshare suggests:
pn  nitroshare-nautilus  

-- no debconf information

Bug#926199: stretch-pu: package libreoffice/1:5.2.7-1+deb9u6

[Rene Engelhard]

Hi,

On Tue, Apr 16, 2019 at 10:05:30AM +0100, Adam D. Barratt wrote:
> OK, thanks. Please go ahead.

Uploaded, thanks.

Regards,

Rene

Bug#927263: riece: error on (wrong-number-of-arguments (1 . 1) 2)

[Kenshi Muto]

On Wed, 17 Apr 2019 12:14:22 +0900,
Kenshi Muto wrote:
> 4. wrote down below and M-x eval-region
>(setq debug-on-error t)
>(riece)
> 
> Debugger entered--Lisp error: (wrong-number-of-arguments (1 . 1) 2)
>   make-face(riece-modeline-current-face "Face used for displaying the current 
> channel in modeline.")

OK, error message told a reason.

I replaced:
riece-highlight.el:
197  (make-face 'riece-modeline-current-face)
198 ;; "Face used for displaying the current channel in modeline.")

riece-history.el:
68   (make-face 'riece-modeline-history-face)
69  ;; "Face used for displaying history channels in modeline.")

riece-unread.el:
63   (make-face 'riece-modeline-unread-face)
64  ;; "Face used for displaying unread channels in modeline.")

Now I succeeded to call M-x riece.
But things goes worse.

Though I specified correct server for Riece asking, Emacs displayed
just only 'Saving /home/kmuto/.riece/save... Done'.
IRC process seems be running but no connection isn't established.

Thanks,
-- 
Kenshi Muto
kmuto at kmuto.jp

Bug#927105: [pkg-gnupg-maint] Bug#927105: pinentry-gnome3: No proper curses fallback.

[Zephaniah E. Loss-Cutler-Hull]

Control: tags 927105 - moreinfo

Hi Daniel,

On 4/15/19 9:17 PM, Daniel Kahn Gillmor wrote:

On Sun 2019-04-14 23:25:14 -0700, Zephaniah E. Loss-Cutler-Hull wrote:


Looking at the code, it sure looks like it tries to handle this, by
checking to see if there is a DBUS_SESSION_BUS_ADDRESS (which there is,
inherited from the gpg-agent), if a gcr system prompt is available, and
trying to see if the screen is locked, however in my testing none of
these actually seem to work to detect that, indeed, the screen is locked
and the user isn't at the desktop any more.

To me the obvious solution is to also check and see if there is a
display set, using the same logic as pinentry-gtk-2, I have some fear
that this will break a pure wayland environment (one with no xwayland
involved), however I don't actually have one of those handy to test
with.  If someone with a wayland environment could test this that would
be appreciated.


As far as i'm aware, the current state is a deliberate choice by
upstream (and it's also one that i think is the right answer) -- GNOME3
is not X11-only, and pinentry-gnome3 doesn't bother communicating with
the X11 session via $DISPLAY at all.  As you point out, your proposed
patch seems likely to fail in environments like Wayland.


I need to try and find the time to spin up a Wayland native VM and do 
some testing to see if DISPLAY is getting set in all reasonable cases.


I say reasonable because no X11 programs could be run in that 
environment, and that doesn't seem like a horribly likely configuration.


If you don't want to talk to a GNOME3 session, you can change your
pinentry explicitly to be something other than pinentry-gnome3 :)


But that's _way_ uglier! :)


That said, are you certain that GNOME desktop is is locked when you
conduct your test?  What screenlocking mechanism are you using?  If the
screen is *unlocked* then i think there's a decent argument for wanting
the prompt to happen on the screen anyway.  But if the screen is locked,
and it can fall back to curses maybe i can agree with you that it
should?


So for the sake of immediate convenience, I'm doing some of the testing 
while I write this email on a Ubuntu 18.04 box, but the behaviour 
appears to be the same.


System was locked with the lock screen hot key, password is required to 
unlock, and monitors were powered down by the system.  So definitely locked.


ssh to the system, attempt to use 'pass' to access a password fails with:
gpg: decryption failed: No secret key

More interestingly calling pinentry-gnome3 directly fails with an 
'Operation Cancelled' error:
(Doing this without the echo so there is a real TTY doesn't have any 
impact on the results.)


~$ echo 'GETPIN' | pinentry-gnome3
OK Pleased to meet you
ERR 83886179 Operation cancelled 

Doing the same thing on an unlocked desktop brings up the pin prompt, 
and returns the results:


~$ echo GETPIN | pinentry-gnome3
OK Pleased to meet you
D 1234
OK

Now, with all of that said...


If you have any patch that you want to propose that falls back to curses
if both:

  * gcr fails because the screen is locked, and
  * a tty is available

Then i would be happy to help you convince upstream (e.g. via
https://dev.gnupg.org/) that this should be adopted.  I've suggested
this approach before in #842015, but i haven't had the time (or the
experience with using dbus to monitor a GNOME session lock, e.g. [0]) to
implement it myself.

There may also be a race condition here -- between testing for the
screen lock and using gcr, or vice versa.  Perhaps gcr itself is what
needs to be able to fail cleanly (thereby triggering the fallback) if
the screen is locked?  that seems less likely to have a race.  I'm open
to different implementation ideas, anyway, but testing for $DISPLAY
seems like the wrong choice.


(This may be a little disjointed, I'm writing as I debug.)

I think that there is a bug in how it is detecting the screen lock, 
because pe_gnome_screen_locked has a comment that the check it is doing 
is intended to be equivalent of:


dbus-send --print-reply=literal --session --dest=org.gnome.ScreenSaver 
/org/gnome/ScreenSaver org.gnome.ScreenSaver.GetActive


Except that this command when run from the command line is correctly 
detecting that the screen is locked.


Which means that either pe_gnome_screen_locked isn't working correctly, 
or it somehow isn't getting called.


So, a few minutes of debugging later, in looks like 
g_dbus_connection_call_sync is returning NULL, instead of a correct value.


Which, as long as there is no error, fails silently.  But there is an 
error, a timeout.  Timeouts are explicitly getting ignored, but why is 
there a timeout?


So, referencing:

https://developer.gnome.org/gio//2.50/GDBusConnection.html#g-dbus-connection-call-sync

The third to the last argument is timeout_msec:

the timeout in milliseconds, -1 to use the default timeout or G_MAXINT 
for no timeout


Except that the code is passing in a 0, not -1, not some 

Bug#925464: new upstream release (1.3rc1)

[Chris Knadle]

Antoine Beaupré:
> On 2019-04-17 01:31:49, Chris Knadle wrote:
> 
> [...]
> 
> Wow, that must have all been a lot of work, thanks! :)

You're welcome.

>> I doubt this package is going to get accepted by the Release Team, because
>> upload after the freeze is meant for only small targeted fixes.  I'll make 
>> the
>> request to see if it's possible, but I expect that the chances of this being
>> accepted to be very low.
> 
> I agree. In fact, I think it might even be better to *remove* mumble
> from buster at this point, and maintain it through backports. We
> *definitely* do not want a RC in buster that we'll have to maintain for
> years... Much easier to do through backports!

Mmm... no, I don't agree there.  Backports are a separate repository that users
have to find and specifically configure to use, and -- more importantly -- the
only backports that can exist are for packages that have been uploaded to Debian
and transitioned to Testing.  i.e. the package *must* exist in Debian Testing
already for an upload to be allowed to Backports.

The Debian backport for mumble is done by another maintainer, not me, and
backports are also messy because bugs to backports should go to the backports
mailing list, *not* the BTS.  It's possible to set the package up to cause that
to happen by setting a Bugs: line with a 'mailto:', but not all of the
bug reporting software comply with that.  (reportbug does, reportbug-ng does
not, at least last I checked.)

There's always a running 'diff' between the package in Testing and the backport,
and the 'diff' slowly gets bigger as there are changes in libraries, newer
versions of debhelper, and so on.  And in the case of Mumble the backport is in
a separate offline Git repository away from the one used for the main package.

Backports may be easier for (some) users, but they're harder for maintainers --
or at least that's my experience with them so far.

> I can change the severity of this bug, if you agree, which should
> eventually kick the package out of testing...

Heh...  :-p  Please don't.
I understand the sentiment but it makes a bigger mess rather than easing one.

> I'm sorry, but I think it's just "partie remise" as we say in french:
> we'll get it in bullseye! And this time it will be awesome. ;)

Dude I did my best to try to get upstream to release a viable snapshot of some
kind before the soft freeze -- I mean really, I pleaded with them -- but it
didn't happen.  It didn't make sense to release the old Mumble 1.2 to Buster,
the upstream snapshots for Mumble 1.3 that were available were broken, upstream
asked me to release directly from Git instead, and the upstream repo uses
submodules such that making a tarball required creating a script to do it which
breaks the debian/watch stuff.  I did the best that could be done, and there's
no opportunity to re-do it.  *shrug*  C'est la vie!!  ;-)

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#926984: [pkg-gnupg-maint] Bug#926984: Bug#926984: gnupg2 FTBFS with gcc-9: dirmngr/dns.h:1058:24: error: lvalue required as unary '&' operand

[Daniel Kahn Gillmor]

Control: fixed 926984 2.2.14-1

On Wed 2019-04-17 10:13:24 +0900, NIIBE Yutaka wrote:
> Control: tags 926984 fixed-upstream
>
> It was fixed in GnuPG 2.2.14.

Annotating this properly in the BTS, accordingly.

thanks for following up, gniibe!

   --dkg

Bug#927265: dpkg-dev: dpkg-buildpackage -F does not generate a source.changes files

[Drew Parsons]

Package: dpkg-dev
Version: 1.19.6
Severity: normal

dpkg-buildpackage -F is supposed to be equivalent to
dpkg-buildpackage --build=source,binary

The dpkg-buildpackage manpage tells us that if --build=source is used,
then a source.changes file will be generated.

But dpkg-buildpackage -F does not generate source.changes, it only
generates the binary changes file.

The expected behaviour is that it will generate both, just as pdebuild
does.

The same applies to dpkg-buildpackage -g and -G (--build=source,all
and --build=source,any)


-- Package-specific info:

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.31.1-16
ii  bzip2 1.0.6-9
ii  libdpkg-perl  1.19.6
ii  make  4.2.1-1.2
ii  patch 2.7.6-3
ii  perl  5.28.1-6
ii  tar   1.30+dfsg-5
ii  xz-utils  5.2.4-1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.6
ii  fakeroot 1.23-1
ii  gcc  4:8.3.0-1
ii  gcc-7 [c-compiler]   7.4.0-8
ii  gcc-8 [c-compiler]   8.3.0-6
ii  gnupg2.2.13-1
ii  gpgv 2.2.13-1
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2019.03.24

-- no debconf information

Bug#927264: tar: do not set default rsh-command

[Christoph Anton Mitterer]

Package: tar
Version: 1.30+dfsg-5
Severity: normal


Hi.

Please do not set a default for --rsh-command, at all.
And if this let's tar use some hardcoded default, set
something that will fail like /bin/false.


The rationale is that most users will typicall not expect
tar to be a networking program (which itself isn't) and one
has to read rather "deep" into the docs to find out that
arguments to --file with a ":" get a ssh like meaning of a
remote archive.

Take e.g. tar --usage, which just talks about [-f ARCHIVE]
but not something that would make it clearer like
[-f [REMOTE_HOST:]ARCHIVE]

Now you may say scp/ssh does the same,... but I guess it's clear
that everyone expects this and the manpage even titles as:
 scp — secure copy (remote file copy program)
so it's clear from the beginning: this may be remote




So which bad things can happen with the default?

Simple example is an information leak on creating archive.
I think it's not so uncommon to use ":" in file names, take
the following made up example of a user wanting to create
a backup tar (locally) of his private keys to put it later
on some USB stick or whatever:
 tar -c -f 19.04.17.01:keys.tar ~/.ssh ~/.gnupg

The user may take this as the first (01) backup made on the
17th of April 2019.
Yeah, I know, it's a stupid example but you get the point.


Even solving #653044 which suggests replacing rsh with ssh
doesn't really help here:
ssh just means that the transport is secured, not that the
remote end is in any way trusted.
So a user could run:
 tar -c -f backup:keys.tar ~/.ssh ~/.gnupg
expecting a local file of that name to be creating, and at
the same time he could have an alias for a remote host
named backup, maybe from his employee, but clearly he
wouldn't want his files to end up there.



Obviously the downside of fixing this is possible breakage
of existing setups which expect the default set as it is.
But a NEWS.Debian + release notes entry could help here and
setups depending on the dangerous default would quickly notice
the changed default and adapt by setting manually whatever
fits... while on the other hand most users will likely never
notice that they could easily leak confidential information
just by using a ":" in the filename.

Bug#926928: fetchmail: Server CommonName mismatch

[Jochen Hein]

Source: fetchmail
Followup-For: Bug #926928

I've checked the manpage for fetchmail. There was the following in the
stretch package:

   --sslcommonname 
  (Keyword: sslcommonname; since v6.3.9)
  Use of this option is discouraged. Before using it,
  contact the administrator of your upstream server and
  ask for a proper SSL certificate to be used. If that
  cannot be attained, this option can be used to specify
  the name (CommonName) that fetchmail expects on the
  server certificate.  A correctly configured server will
  have this set to the hostname by which it is reached,
  and by default fetchmail will expect as much. Use this
  option when the CommonName is set to some other value,
  to avoid the "Server CommonName mismatch" warning, and
  only if the upstream server can't be made to use proper
  certificates.

Beside that I think that the bug should be downgraded...

Jochen

Bug#927263: riece: error on (wrong-number-of-arguments (1 . 1) 2)

[Kenshi Muto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: riece
Version: 9.0.0-8
Severity: normal

Dear Maintainer,

I upgraded my environment from Stretch to Buster, and noticed riece
won't boot up. (so the severity may be 'grave')

1. remove .riece folder

2. Run emacs26 by 'emacs -no-init-file -nw'

3. wrote down below and M-x eval-region
   (emacs-version)
   '26.1' was returned.

4. wrote down below and M-x eval-region
   (setq debug-on-error t)
   (riece)

Debugger entered--Lisp error: (wrong-number-of-arguments (1 . 1) 2)
  make-face(riece-modeline-current-face "Face used for displaying the current 
channel in modeline.")
  
byte-code("\300\301\302\303\304DD\305\306\307\310\311&\007\210\300\312\302\303\313DD\314\306\315\310\311&\007\210\316\317!\2040\0\320\317\321\"\210\322\317\323\324!\"\210\300\207"
 [custom-declare-variable riece-channel-list-mark-face-alist funcall function 
#f(compiled-function () #) "An alist mapping marks on 
riece-channel-list-buffer to faces." :type (repeat (cons character symbol)) 
:group riece-highlight riece-channel-list-font-lock-keywords 
#f(compiled-function () #) "Default expressions to highlight 
in riece-channel-list-mode." (repeat (list string)) riece-facep 
riece-modeline-current-face make-face "Face used for displaying the current 
channel in modeline." set-face-foreground face-foreground 
riece-channel-list-current-face] 8)
  require(riece-highlight)
  eval-buffer(# nil 
"/usr/share/emacs/site-lisp/riece/riece-ctcp.el" nil t)  ; Reading at buffer 
position 1122
  load-with-code-conversion("/usr/share/emacs/site-lisp/riece/riece-ctcp.el" 
"/usr/share/emacs/site-lisp/riece/riece-ctcp.el" nil t)
  require(riece-ctcp)
  riece-load-and-build-addon-dependencies((riece-alias riece-button riece-ctcp 
riece-ctlseq riece-guess riece-highlight riece-history riece-icon riece-ignore 
riece-keyword riece-log riece-mcat riece-menu riece-shrink-buffer riece-toolbar 
riece-unread riece-url))
  riece-resolve-addons((riece-highlight riece-history riece-icon riece-ignore 
riece-keyword riece-log riece-mcat riece-menu riece-shrink-buffer riece-toolbar 
riece-unread riece-url))
  riece(nil)
  funcall-interactively(riece nil)
  call-interactively(riece record nil)
  command-execute(riece record)
  execute-extended-command(nil "riece" "rie")
  funcall-interactively(execute-extended-command nil "riece" "rie")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

- -- 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/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages riece depends on:
ii  debconf  1.5.71
ii  emacs1:26.1+1-3.2
ii  emacs-gtk [emacsen]  1:26.1+1-3.2
ii  emacsen-common   3.0.4

riece recommends no packages.

Versions of packages riece suggests:
ii  dictionaries-common  1.28.1
pn  kakasi   
pn  lsdb 
ii  ruby-gettext 3.2.9-1

- -- no debconf information
-BEGIN PGP SIGNATURE-
Comment: Processed by Mailcrypt 3.5.9 

iQIzBAEBCgAdFiEEnMxcIsEJVbWPVaUbHSHIPcRS4PwFAly2mgUACgkQHSHIPcRS
4PxjlhAAlLIZ+5bXXb/xlNU0HN1e1+wEgrDCnswm0W2fpga0Jl68RxtcFRcBR40s
V6HAsH/ThGZzEMAPbN3f4qAg36OAxBXpn6ul49niUX2JVm2dwJj3wWXanHZEYapk
ectGfpTMJMQop0DgrZISNxCW33bPKzigUaYwOaKMlTgY/C41h+C54dSwHy/mEe6H
pwWOZeYx696z4V4T4YKO+cyz7MDxwcWfeBpCyEE9i2iAnguxMQYpTLfTS3GZySBh
oX3WiDqYUhKtRnvhIg/6R1s+3rCgkGbLOX1IChCxfye4MBurt6FymfD6eHqbv710
fiqItohPAjmkuuxDSBj4d1PBivFm54M/qWww4vsEWk03RguX5ZszH57+t/zujhtN
D49NSC7UGwcKrKhe4MbtL3mG+AeNaf5NUZiOF9FDhXpJXz/mX2eOMtGocuyr4bjD
u+MMO6tQSMNklncW74nZzaQ6lwBJcsIzLx+Iu9LVhxwdhXH+1vlrcRdId5CJayW6
KKAdXcgDVljekNZ/unQvoI/GnYxk4mCUEVAGXkot3pkE00aAPeZyHEqt5YejrYgE
W3qqpKSIOe8XA20viW3oXV7Nf5XLRScNrPPzqQ0WqGijOIw8CCsslcKwUbFgG9my
0gJelaTBPWkLydGl96MbRSNCcAoEtjIFgcYlUQwG1JkTvvrsMRY=
=ROsn
-END PGP SIGNATURE-

Bug#927262: dracut: reboot delayed 2 minutes for stop job running for user manager for UID 0 after new kernel installation

[Felix Miata]

Package: dracut
Version: update-initramfs
Severity: normal

This has happened on multiple x86 installations, both 32 bit and 64 bit. It 
only happens on first
shutdown after new a kernel installation. Searching internet finds similar 
complaints, but no
solutions, or existing bug reports that specify UID 0, or 120 seconds instead 
of 90 seconds of
delay, and they are all stale, e.g. 2 years old.

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

Versions of packages dracut depends on:
pn  dracut-core  

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

Bug#927261: tar: file capabilities lost upon extraction

[Christoph Anton Mitterer]

Package: tar
Version: 1.30+dfsg-5
Severity: normal


Hi.

The tar info page says:
'--xattrs'
 Enable extended attributes support.  When used with '--create',
 this option instructs GNU 'tar' to store extended file attribute in
 the created archive.  This implies POSIX.1-2001 archive format
 ('--format=pax').

 When used with '--extract', this option tells 'tar', for each file
 extracted, to read stored attributes from the archive and to apply
 them to the file.

'--no-xattrs'
 Disable extended attributes support.  This is the default.

   Attribute names are strings prefixed by a "namespace" name and a dot.
Currently, four namespaces exist: 'user', 'trusted', 'security' and
'system'.  By default, when '--xattr' is used, all names are stored in
the archive (or extracted, if using '--extract').  This can be
controlled using the following options:



But unlike described, when just --xattr is used, NOT all xattrs seem to
be set upon extracted members, at least any file capabilities get lost.

One needs to add e.g. "--xattrs-include=*" to get them extracted as well.

They do seem to be stored in the archive even if "--xattrs-include=*"
wasn't used, just as described above in the documentation.


I guess either tar's behaviour need to be fixed or the documentation.


Cheers,
Chris.

PS: Obviously I did all that as root ;-)

Bug#927260: libutf8proc-dev:2.2.0-1: missing pkg-config support.

[Wang Gary]

Package: libutf8proc-dev:2.2.0-1
Version: libutf8proc-dev:2.2.0
Severity: normal

Not sure if this should be treat as a bug, current version
of libutf8proc-dev are missing pkg-config support, which
introduced in
https://github.com/JuliaStrings/utf8proc/commit/5dcd382
and included in their 2.3.0 release. The current
libqtermwidget5-0-dev package got it's pkg-config support,
but inside the 'qtermwidget5.pc' file there is a line requires
libutf8proc's pkg-config file:

'Requires: Qt5Widgets, libutf8proc'

The missing pkg-config support file breaks libqtermwidget5-0-dev's
pkg-config support.

Maybe we can backport the libutf8proc-dev pkg-config file
or upgrade the package?

Thanks

Bug#927259: release.debian.org: unblock request: nheko

[Hubert Chathi]

Package: release.debian.org
Severity: normal

Hello release team.

I would like to upload a new version of nheko to fix #926671.  It is an
"important" bug (though in reality, it could be argued that it is
"serious", as Matrix will be bumping the default room version soon,
which will cause the bug to manifest much more commonly, making the
program less usable).

The fix is to apply a small patch from upstream.  Attached is a debdiff.

In addition to the above issue, I would like to also include fixes for
the following bugs, which are not included in the attached debdiff, but
are fairly trivial:

- #926659 - incorrectly named file (debian/README.sources instead of
  debian/README.source) -- has an obvious fix
- #926680 - a working directory is not properly cleaned up if the build
  fails -- I would just add the working directory to the list of files
  that are "rm -rf"-ed in override_dh_auto_clean.

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

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

diff -Nru nheko-0.6.3/debian/changelog nheko-0.6.3/debian/changelog
--- nheko-0.6.3/debian/changelog	2019-02-08 15:35:59.0 -0500
+++ nheko-0.6.3/debian/changelog	2019-04-08 18:00:01.0 -0400
@@ -1,3 +1,9 @@
+nheko (0.6.3-2) unstable; urgency=medium
+
+  * Support v3 rooms (Closes: #926671)
+
+ -- Hubert Chathi   Mon, 08 Apr 2019 18:00:01 -0400
+
 nheko (0.6.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru nheko-0.6.3/debian/patches/series nheko-0.6.3/debian/patches/series
--- nheko-0.6.3/debian/patches/series	2019-02-08 15:35:01.0 -0500
+++ nheko-0.6.3/debian/patches/series	2019-04-08 17:57:30.0 -0400
@@ -1,2 +1,3 @@
 no_rpath
 nlohmann-json
+v3_support
diff -Nru nheko-0.6.3/debian/patches/v3_support nheko-0.6.3/debian/patches/v3_support
--- nheko-0.6.3/debian/patches/v3_support	1969-12-31 19:00:00.0 -0500
+++ nheko-0.6.3/debian/patches/v3_support	2019-04-08 17:56:34.0 -0400
@@ -0,0 +1,27 @@
+Author: redsky17 
+Bug: https://github.com/Nheko-Reborn/mtxclient/issues/3
+Bug-Debian: https://bugs.debian.org/926671
+Description: Fix Room v3 Issue
+ This at least partially addresses #3.  I have a feeling that
+ additional updates will be needed at some point, but this
+ fixes the issue where mtxclient would throw an exception for
+ unrecognized event id formats, which caused nheko to crash.
+Origin: backport, https://github.com/Nheko-Reborn/mtxclient/commit/67d39691666bcdf3cc660db19ccc0d9941df13fd
+Last-Update: 2019-04-08
+
+diff --git a/mtxclient/include/mtx/identifiers.hpp b/mtxclient/include/mtx/identifiers.hpp
+index 87acc43..7885885 100644
+--- a/mtxclient/include/mtx/identifiers.hpp
 b/mtxclient/include/mtx/identifiers.hpp
+@@ -90,7 +90,10 @@ parse(const std::string )
+ identifier.hostname_  = id.substr(parts + 1);
+ identifier.id_= id;
+ } else {
+-throw std::invalid_argument(id + ": invalid format\n");
++// V3 event ids don't use ':' at all, don't parse them the same way.
++identifier.localpart_ = id;
++identifier.hostname_ = id;
++identifier.id_ = id;
+ }
+ 
+ return identifier;

Bug#927221: Comparisons to Other Distros

[Ron Lovell]

Correction: On Tumbleweed, pkg fuse3 supplies mount.fuse3, not mount.fuse.
On Tue, Apr 16, 2019 at 9:14 PM Ron Lovell  wrote:

> Wow, that was quick.
>
> As a sanity check, I took a look at my Arch Linux and openSUSE Tumbleweed
> installations.  Each has both fuse[2] and fuse3 installed, each has the
> corresponding library installed.
>
> For Arch, a fuse-common pkg supplies /usr/bin/mount.fuse, which happens to
> be dyn linked to libfuse 3 (per ldd(1)).  Pkg fuse2 supplies
> /usr/bin/fusermount, not dyn linked to libfuse per ldd. Pkg fuse3 supplies
> /usr/bin/fusermount3, again not linked.
> gvfsd-fuse requires fuse2 and is linked to libfuse 2. sshfs requires fuse3
> and is linked to libfuse 3.
>
> For Tumbleweed, pkg fuse supplies /usr/sbin/mount.fuse, not linked to
> libfuse per ldd. Pkg fuse3 supplies /usr/sbin/mount.fuse which links to
> libfuse 3. Pkg fuse supplies /usr/bin/fusermount, not linked. Pkg fuse3
> supplies /usr/bin/fusermount3, not linked.
>
> On both systems I was able to use the fuse2 fusermount to unmount an sshfs
> (fuse3) mount, but that doesn't mean much.
>
> So I'm a wee bit worried that not having BOTH fuse and fuse co-installed
> might uncover problems in Debian. Time for lots of testing when the bits
> are available. I'll try to help out there.
>
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>
>

-- 
James Ronald Lovell 
Huntsville, AL, USA
A distributed system is one in which the failure of a computer you
didn't even know existed can render your own computer unusable.
-Leslie Lamport

Bug#927221: Comparisons to Other Distros

[Ron Lovell]

Wow, that was quick.

As a sanity check, I took a look at my Arch Linux and openSUSE Tumbleweed
installations.  Each has both fuse[2] and fuse3 installed, each has the
corresponding library installed.

For Arch, a fuse-common pkg supplies /usr/bin/mount.fuse, which happens to
be dyn linked to libfuse 3 (per ldd(1)).  Pkg fuse2 supplies
/usr/bin/fusermount, not dyn linked to libfuse per ldd. Pkg fuse3 supplies
/usr/bin/fusermount3, again not linked.
gvfsd-fuse requires fuse2 and is linked to libfuse 2. sshfs requires fuse3
and is linked to libfuse 3.

For Tumbleweed, pkg fuse supplies /usr/sbin/mount.fuse, not linked to
libfuse per ldd. Pkg fuse3 supplies /usr/sbin/mount.fuse which links to
libfuse 3. Pkg fuse supplies /usr/bin/fusermount, not linked. Pkg fuse3
supplies /usr/bin/fusermount3, not linked.

On both systems I was able to use the fuse2 fusermount to unmount an sshfs
(fuse3) mount, but that doesn't mean much.

So I'm a wee bit worried that not having BOTH fuse and fuse co-installed
might uncover problems in Debian. Time for lots of testing when the bits
are available. I'll try to help out there.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#926984: [pkg-gnupg-maint] Bug#926984: Bug#926984: gnupg2 FTBFS with gcc-9: dirmngr/dns.h:1058:24: error: lvalue required as unary '&' operand

[NIIBE Yutaka]

Control: tags 926984 fixed-upstream

It was fixed in GnuPG 2.2.14.
-- 

Bug#925464: new upstream release (1.3rc1)

[Antoine Beaupré]

On 2019-04-17 01:31:49, Chris Knadle wrote:

[...]

Wow, that must have all been a lot of work, thanks! :)

> I doubt this package is going to get accepted by the Release Team, because
> upload after the freeze is meant for only small targeted fixes.  I'll make the
> request to see if it's possible, but I expect that the chances of this being
> accepted to be very low.

I agree. In fact, I think it might even be better to *remove* mumble
from buster at this point, and maintain it through backports. We
*definitely* do not want a RC in buster that we'll have to maintain for
years... Much easier to do through backports!

I can change the severity of this bug, if you agree, which should
eventually kick the package out of testing...

I'm sorry, but I think it's just "partie remise" as we say in french:
we'll get it in bullseye! And this time it will be awesome. ;)

Cheers,

A.
-- 
Nature hides her secret because of her essential loftiness, but not by
means of ruse.
   - Albert Einstein

Bug#925464: new upstream release (1.3rc1)

[Chris Knadle]

Here's an update on this bug:

I've completed the packaging for 1.3.0-rc1 -- that took a lot more work than it
should have because there are still unreleasable codec documentation files in
the upstream tarball (and new unreleasable files too, argh!).  [Each time I find
new unreleasable files it means starting the work over, in order to keep the
unreleasable files out of the Git history.]

Unfortunately the resulting debdiff between the package before the Buster freeze
and 1.3.0~rc1+dfsg-1 is about 10 MB in size.  And it looks like it's a lot of
real "sprinkled" changes throughout the code, not just the result of file
re-ordering or repack file removal.  It's a large amount of actual change.

I doubt this package is going to get accepted by the Release Team, because
upload after the freeze is meant for only small targeted fixes.  I'll make the
request to see if it's possible, but I expect that the chances of this being
accepted to be very low.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#925505: closed by Adam Borowski (Re: Bug#925505: RFS: dhcpoptinj/0.4.4-1 [ITP])

[Adam Borowski]

On Tue, Apr 16, 2019 at 11:38:40AM +, Andreas Misje wrote:
> Out of curiosity, why did you upload one of the older revisions
> uploaded to https://mentors.debian.net/package/dhcpoptinj and not the
> newest, in which I have fixed a few issues, like outdated standards
> version and debian-compat, and updated the VCS URIs?

I had grabbed the package earlier, and did not suspect there might be
updates since the last post.

> If you are considering uploading another version, would you mind if I
> package 0.5.0 first?

While I'm obviously willing to upload new versions in the future, it's
usually harmful to have multiple versions in NEW -- the ftpmasters would
have to review them all, and failure in just one means rejection of
everything.

Thus, I'd recommend waiting for 0.4.4-1 to get ACCEPTed or REJECTed, and
only then updating it.


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

Bug#925934: RM: golang-gopkg-data-dog-go-sqlmock.v1/1.3.0-1

[rajudev]

Paul Gevers writes:

> Hi rajudev,
>
> On Sat, 30 Mar 2019 16:55:26 +0100 Paul Gevers  wrote:
>> On 28-03-2019 21:36, rajudev wrote:
>> > Shengjing pointed it out that golang-github-data-dog-go-sqlmock-dev can be
>> > used for package which imports gopkg.in/DATA-DOG/go-sqlmock.v1
>> > 
>> > Hence I want this package to be removed.
>> 
>> Do you want it removed from Debian, or *only* from testing? In the
>> former case, please clone this bug to the ftp.debian.org pseudo package.
>> 
>> However, it can't be removed yet, as there are multiple packages (build)
>> depending on it, which need to be fixed first (see below). Did you
>> coordinate this removal request with the maintainers of those packages?
>
> Ping...


Please keep the  package as it is  for now.
I was concerned about my particular packages which do not require it
now.
But seems there are more packages which might get affected.
>
> Paul


Thanks

Bug#927257: clementine: massive number of tagreader processes

[Adam Borowski]

Package: clementine
Version: 1.3.1+git609-g623a53681+dfsg-1
Severity: normal

Hi!
Clementine spawns a large number (64 on this machine) of
"clementine-tagreader" processes.  And besides spamming admin tools such
as "ps" or "htop", they're not even idle -- every once a short while, each
of them wakes up and does something that takes >2% of htop's time slice.

Shouldn't the processes get spawned once there's actually some work to do?


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

Kernel: Linux 5.1.0-rc5-00061-gb1169b5699ff (SMP w/64 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C.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: sysvinit (via /sbin/init)

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.14.4-1
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-plugins-ugly   1.14.4-1
ii  libc6   2.28-8
ii  libcdio18   2.0.0-2
ii  libchromaprint1 1.4.3-3
ii  libcrypto++65.6.4-8
ii  libfftw3-double33.3.8-2
ii  libgcc1 1:8.3.0-6
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-1
ii  libgpod40.8.3-13
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libimobiledevice6   1.2.1~git20181030.92c5462-1
ii  liblastfm5-11.0.9-1+b11
ii  libmtp9 1.1.16-2
ii  libmygpo-qt5-1  1.1.0-3
ii  libplist3   2.0.1~git20190104.3f96731-1
ii  libprojectm2v5  2.1.0+dfsg-4+b4
ii  libprotobuf17   3.6.1.3-1
ii  libpulse0   12.2-4.0.kb1
ii  libqt5concurrent5   5.11.3+dfsg1-1
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5dbus5 5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5network5  5.11.3+dfsg1-1
ii  libqt5opengl5   5.11.3+dfsg1-1
ii  libqt5sql5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libqt5x11extras55.11.3-2
ii  libqt5xml5  5.11.3+dfsg1-1
ii  libsqlite3-03.27.2-2
ii  libstdc++6  8.3.0-6
ii  libtag1v5   1.11.1+dfsg.1-0.3
ii  libx11-62:1.6.7-1
ii  projectm-data   2.1.0+dfsg-4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages clementine recommends:
ii  gstreamer1.0-pulseaudio  1.14.4-1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.14.4-1+b1

-- no debconf information

Bug#927256: add a monitor database to the default configuration

[Ryan Tandy]

Below is an example config from Quanah that demonstrates a monitor setup 
as well as his suggestion of using an authz-regexp for the cn=config 
root.


dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: sync
olcLogLevel: stats
olcPidFile: /var/run/slapd/slapd.pid
olcArgsFile: /var/run/slapd/slapd.args
olcToolThreads: 2
olcAuthzRegexp: {0}gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth cn
=config

dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

include: file:///etc/ldap/schema/core.ldif
include: file:///etc/ldap/schema/cosine.ldif
include: file:///etc/ldap/schema/inetorgperson.ldif

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}back_monitor

dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn=""  by * read
olcAccess: {1}to *  by self write  by users read  by anonymous auth

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to *  by * none

dn: olcDatabase={1}monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcAccess: {0}to dn.subtree="cn=monitor"  by dn.exact=cn=config read  by dn.ex
act=cn=manager,dc=example,dc=com read

dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcmdbConfig
olcDatabase: {2}mdb
olcSuffix: dc=example,dc=com
olcRootDN: cn=manager,dc=example,dc=com
olcRootPW: secret
olcSizeLimit: unlimited
olcTimeLimit: unlimited
olcMirrorMode: TRUE
olcDbCheckpoint: 512 30
olcDbDirectory: /var/lib/ldap
olcDbIndex: default eq
olcDbIndex: objectClass
olcDbIndex: entryUUID
olcDbIndex: entryCSN
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: description pres,eq,sub
olcDbIndex: title pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbMaxSize: 85899345920
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * non
e
olcAccess: {1}to * by * read

Bug#927256: add a monitor database to the default configuration

[Ryan Tandy]

Package: slapd
Severity: wishlist
Control: submitter -1 qua...@openldap.org

In IRC, Quanah suggested that we add a monitor instance to the default 
configuration.


The monitor DB should not be world readable. Granting access to 
cn=admin,... and the cn=config owner would be a good start.

Bug#910964: libprotobuf17 might need Breaks: libprotobuf10

[GCS]

On Sat, Apr 13, 2019 at 12:02 PM Niels Thykier  wrote:
> From a release team PoV, we would very much like to see this be fixed
> with a Breaks as well.
 I've prepared the change and attached to this email. This will make
libarcus3 and cura-engine need to be upgraded in the same time to
package versions which was built with libprotobuf17.

> On the flip side, having libprotobuf10 remain on some systems during
> upgrades will spell trouble for us later.  Each release, we see a number
> of upgrade issues related to old, long obsolete packages that were
> removed releases ago.  Lets ensure libprotobuf10 does not become one of
> them for bullseye or later.
 In the last five years (I can remember about protobuf) upstream only
increased the soname - I don't think it will change. But I'll try to
remember and with the new upstream release (targeting Bullseye) add a
break to libprotobuf10.

Regards,
Laszlo/GCS
diff -Nru protobuf-3.6.1.3/debian/control protobuf-3.6.1.3/debian/control
--- protobuf-3.6.1.3/debian/control	2018-12-09 12:45:11.0 +
+++ protobuf-3.6.1.3/debian/control	2019-04-16 22:12:03.0 +
@@ -66,6 +66,7 @@
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: libarcus3 (<< 3.3.0-2), cura-engine (<< 1:3.3.0-2.1+b1)
 Description: protocol buffers C++ library
  Protocol buffers are a flexible, efficient, automated mechanism for
  serializing structured data - similar to XML, but smaller, faster, and

Bug#926212: gnome-shell crashed: segfault in libgnome-shell.so after printing email from evolution

[Bernhard Übelacker]

On Tue, 16 Apr 2019 22:47:14 +0100 Simon McVittie  wrote:
> How sure are you that the virtual memory area starting at 0x7fd4fa6a6000
> starts with .init and not .text?

Unfortunately I am not completely sure, but I caused a crash while
knowing the memory layout and found there also the dmesg line
containing start of .init.
At least this calculation worked later in 927142 too.

Kind regards,
Bernhard

Bug#927183: [pre-approval] unblock: debiancontributors/0.7.8-1

[Daniele Tricoli]

tag 927183 - moreinfo
thanks

Hello Niels,

On 16/04/2019 07:40, Niels Thykier wrote:
> Please go ahead with the upload and remove the moreinfo tag when the
> upload is ready to be unblocked.

Many thanks for your quick review!

> For future reference: Please avoid generic code-style
> rewrite/refactoring during freezes (and instead deploy it after the
> freeze).  In the particular instance, it was manageable to review but
> most of the was "noise" due to that refactoring - this in turn increases
> the risk that the proposal is rejected.

Thanks for the suggestion, and sorry for the added "noise". I will

coordinate better next time: the code-style/refactoring was done several months

ago, but we (me and Enrico) did not make a release of debiancontributors before

the freeze.

Next time I will remember that it's better to release before the freeze because

it can happen to need to push a new release during the freeze for some important

fixes.

Thanks again and kind regards,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org




signature.asc
Description: OpenPGP digital signature

Bug#927162: gnome-shell segfaults in libst-1.0.so

[Simon McVittie]

On Tue, 16 Apr 2019 at 15:13:56 -0700, Eloston wrote:
> After looking at the TopIcons code at the line indicated in journalctl, I am
> able to reproduce the crash with the following:
> 
> 1. Open Looking Glass (lg)
> 2. Run the following:
> 
>   a = new St.Widget();
>   a.destroy();
>   a.get_theme_node();
> 
> After running the third line, gnome-shell will crash.

This is undefined behaviour (i.e. incorrect code): nothing should be
calling methods on a widget that has been destroyed. Ideally, it
would just log a warning and carry on, instead of crashing (and that's
what the upstream patch that I'm testing does), but nothing is going to
make this correct.

Looking at line 121 in the top-icons-plus extension, what I would expect
should happen is that in response to the destroy signal emitted by the
icon's destroy() method, everything else stops trying to do anything with
the icon (in particular, stops trying to draw it, which would involve
calling get_theme_node() on it). I'm not sure yet why that doesn't happen.
It might be a bug in the top-icons-plus extension, or a bug elsewhere in
GNOME Shell.

smcv

Bug#927255: powerpc-utils is uninstallable

[Daniel Kahn Gillmor]

Package: powerpc-utils
Version: 1.3.2-1.1
Severity: grave
Justification: renders package unusable
Control: affects -1 grub-ieee1275

powerpc-utils Depends: pmac-utils, but pmac-utils is no longer in
debian.

This makes powerpc-utils uninstallable, which in turn makes
grub-ieee1275 uninstallatble.

--dkg

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

Kernel: Linux 5.0.0-trunk-powerpc-smp (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages powerpc-utils depends on:
ii  pmac-utils 1.1.3-27
ii  powerpc-ibm-utils  1.3.2-1.1

powerpc-utils recommends no packages.

powerpc-utils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#926212: gnome-shell crashed (segfault)

[Simon McVittie]

Control: forwarded -1 
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/497

On Sun, 07 Apr 2019 at 20:00:23 +0200, Bernhard Übelacker wrote:
> PS.: My untested change in message 10 might not crash, but lead to an
> infinitive loop, as app->running_state might not change anymore...

Yeah, let's not do that.

If line 1485 of shell_app_dispose() is indeed what's crashing,
then that would mean that app->running_state is non-NULL but
app->running_state->windows is NULL. This doesn't seem to be meant to
happen: we can see that in window_backed_app_get_window(), there's an
assertion that if app->running_state is non-NULL, then
app->running_state->windows is meant to be non-NULL too.

A common feature of upstream bugs 750 and 822 is that
_shell_app_remove_window() line 1110 is in the stack trace: this means
the ShellApp is being disposed while shell_app_sync_running_state() is
still running. At this point in _shell_app_remove_window(), window has
already been removed from app->running_state->windows, but
app->running_state has not yet been cleared: so the invariant that
app->running_state is only non-NULL if app->running_state->windows is also
non-NULL does not hold, and indeed in both those upstream bugs we seem
to have a violation of that invariant, causing a crash when user code
disposes the ShellApp in response to one of its signals.

I think the solution is probably to stop believing that
app->running_state != NULL implies app->running_state->windows != NULL,
and check for the latter whenever we need it; but the refcounting of the
ShellApp still seems suspicious, so I'm hoping for input from upstream
before uploading anything for this.

smcv

Bug#927254: libjs-vue-router: ships node module instead of browser one

[Dmitry Bogatov]

Package: libjs-vue-router
Version: 3.0.2+ds-1
Severity: normal

Dear Maintainer,

I am working on packaging Laminar CI system, and libjs-vue-router is one
of its dependencies. Upstream build system of Laminar downloads its
dependencies from web, but to comply with Policy, I patched it to use
local files. Unfortunately, it did not work.

Upstream author of Laminar (in CC) kindly provided following information:

  OK this is a problem. It looks like the libjs-vue-router package is not
  really a pure javascript package but actually a node.js one (probably
  should be named node-vue-router). It even lists nodejs in its dependencies:
  https://packages.debian.org/sid/libjs-vue-router

  I tried all the variations under /usr/share/javascript/vue-router, all fail
  in some variation of the same issue. I don't know how it worked for me last
  time, probably I made a mistake and accidentally used the "browser"
  vue-router js file.

  If you use the latest "browser" version of vue-router, available here:
  https://unpkg.com/vue-router@3.0.3/dist/vue-router.js and linked from their
  installation page:
  https://router.vuejs.org/installation.html#direct-download-cdn then it
  works. So I think what should happen, at least ideally, is that the
  existing libjs-vue-router package should be renamed node-vue-router (and it
  should not symlink from /usr/share/javascript/vue-router to
  ../../lib/nodejs/vue-router/dist, and it should depend on node-vue not
  libjs-vue), and a new package named libjs-vue-router should be created
  containing the "browser" version. This would seem to be consistent with
  Debian Javascript packaging as I understand it

I have no expertise to comment on this, but can you please consider this
argument?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpf7qHlYY1XP.pgp
Description: PGP signature

Bug#924050: poppler-utils: pdfsig segfaults on signed PDF

[Bernhard Übelacker]

Dear Maintainer,
tried to have another look with the original input file.

In my minimal test VM I came again across the segfault I
described in message #10, which is not the
problem Wesley hit and got sumitted in #926404 too.
So I had to start firefox once to have a profile
in the home directory.

Then I could successfully reproduce the crash, see the
backtrace below with debug information.

For this I could not find a upstream bug report.
But upstream commit [1] changed method SignatureInfo::setSubjectDN
to avoid it.

Therefore tried to build with this patch and found that it
touches the same area as [2] from message #10, therefore
included that too before.

With both applied pdfsig gives information for this file
without crashing, with or without a .mozilla directory.

Kind regards,
Bernhard


#926404 https://bugs.debian.org/926404
[1] 
https://gitlab.freedesktop.org/poppler/poppler/commit/7486e4995d66f1a8676f3e65e408e8cdab049f6b
[2] 
https://gitlab.freedesktop.org/poppler/poppler/commit/a85c2ed8f4359341adb94887c4b551a761244fdb


(gdb) bt
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x77a1bfee in __GI___strdup (s=s@entry=0x0) at strdup.c:41
#2  0x77e8340d in SignatureInfo::setSubjectDN 
(this=this@entry=0x555a3e80, subjectDN=0x0) at 
./poppler/SignatureInfo.cc:127
#3  0x77df3e19 in FormFieldSignature::validateSignature 
(forceRevalidation=, validationTime=-1, doVerifyCert=true, 
this=0x555a07f0) at ./poppler/Form.cc:1749
#4  FormFieldSignature::validateSignature (this=0x555a07f0, 
doVerifyCert=, forceRevalidation=, 
validationTime=-1) at ./poppler/Form.cc:1689
#5  0x6a5d in main (argc=, argv=) at 
/usr/include/c++/8/bits/stl_vector.h:979


(gdb) list SignatureInfo.cc:124,128
124 void SignatureInfo::setSubjectDN(const char *subjectDN)
125 {
126   free(subject_dn);
127   subject_dn = strdup(subjectDN);
128 }
>From a85c2ed8f4359341adb94887c4b551a761244fdb Mon Sep 17 00:00:00 2001
From: Albert Astals Cid 
Date: Sat, 17 Nov 2018 19:29:16 +0100
Subject: [PATCH] Be more stubborn looking for a nssdb

Fixes issue #669
(Bernhard Übelacker: Adapted to match debian package 0.71.0, https://bugs.debian.org/924050 )
---
 poppler/SignatureHandler.cc | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/poppler/SignatureHandler.cc b/poppler/SignatureHandler.cc
index a98e3f7..a49d34a 100644
--- a/poppler/SignatureHandler.cc
+++ b/poppler/SignatureHandler.cc
@@ -114,10 +114,19 @@ GooString *SignatureHandler::getDefaultFirefoxCertDB_Linux()
 void SignatureHandler::init_nss() 
 {
   GooString *certDBPath = getDefaultFirefoxCertDB_Linux();
+  bool initSuccess = false;
   if (certDBPath == nullptr) {
-NSS_Init("sql:/etc/pki/nssdb");
+initSuccess = (NSS_Init("sql:/etc/pki/nssdb") == SECSuccess);
   } else {
-NSS_Init(certDBPath->getCString());
+initSuccess = (NSS_Init(certDBPath->getCString()) == SECSuccess);
+  }
+  if (!initSuccess) {
+GooString homeNssDb(getenv("HOME"));
+homeNssDb.append("/.pki/nssdb");
+initSuccess = (NSS_Init(homeNssDb.getCString()) == SECSuccess);
+if (!initSuccess) {
+  NSS_NoDB_Init(nullptr);
+}
   }
   //Make sure NSS root certificates module is loaded
   SECMOD_AddNewModule("Root Certs", "libnssckbi.so", 0, 0);
-- 
2.20.1

>From 7486e4995d66f1a8676f3e65e408e8cdab049f6b Mon Sep 17 00:00:00 2001
From: Albert Astals Cid 
Date: Wed, 16 Jan 2019 22:56:42 +0100
Subject: [PATCH] pdfsig: add -nssdir option
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Contains code inspired in code by Hans-Ulrich Jüttner and Adrian Johnson
(Bernhard Übelacker: Adapted to match debian package 0.71.0, https://bugs.debian.org/924050 )
---
 poppler/SignatureHandler.cc | 56 +
 poppler/SignatureHandler.h  |  9 --
 poppler/SignatureInfo.cc|  4 +--
 utils/pdfsig.1  | 15 --
 utils/pdfsig.cc | 12 ++--
 5 files changed, 68 insertions(+), 28 deletions(-)

diff --git a/poppler/SignatureHandler.cc b/poppler/SignatureHandler.cc
index a57e9c3..49f91bd 100644
--- a/poppler/SignatureHandler.cc
+++ b/poppler/SignatureHandler.cc
@@ -41,7 +41,7 @@ unsigned int SignatureHandler::digestLength(SECOidTag digestAlgId)
 
 char *SignatureHandler::getSignerName()
 {
-  if (!CMSSignerInfo)
+  if (!CMSSignerInfo || !NSS_IsInitialized())
   return nullptr;
 
   CERTCertificate *cert = NSS_CMSSignerInfo_GetSigningCertificate(CMSSignerInfo, CERT_GetDefaultCertDB());
@@ -78,8 +78,7 @@ time_t SignatureHandler::getSigningTime()
   return static_cast(sTime/100);
 }
 
-
-GooString *SignatureHandler::getDefaultFirefoxCertDB_Linux()
+static GooString *getDefaultFirefoxCertDB_Linux()
 {
   GooString * finalPath = nullptr;
   DIR *toSearchIn;
@@ -111,27 +110,45 @@ GooString *SignatureHandler::getDefaultFirefoxCertDB_Linux()
 /**
  * Initialise NSS
  */
-void 

Bug#926306: RFS: socklog/2.1.0-9

[Dmitry Bogatov]

[2019-04-13 11:11] Mathieu Mirmont 
> On Fri, Apr 12, 2019 at 05:22:35PM +, Dmitry Bogatov wrote:
> > [2019-04-10 23:48] Mathieu Mirmont 
> > >
> > > part 1 text/plain 434
> > > On Wed, Apr 10, 2019 at 08:20:30AM +, Dmitry Bogatov wrote:
> > > > You can repack it as new upstream version. New version would be
> > > > something like `2.1.0+repack-1'. Do not forget add clarification into
> > > > Debian.source.
> > >
> > > I've updated the package and uploaded to mentors:
> > >
> > > https://mentors.debian.net/package/socklog
> > > https://mentors.debian.net/debian/pool/main/s/socklog/socklog_2.1.0+repack-1.dsc
> > 
> > Lintian (2.11.0) warnings:
> > 
> > W: socklog: missing-versioned-depends-on-init-system-helpers 
> > postinst:152 "update-rc.d defaults
> -disabled" needs i
> > nit-system-helpers >= 1.50
>
> Embarassingly I don't know how to get rid of this one. I've added a
> depencency on init-system-helpers (>= 1.50) naturally but the warning
> remains.
>
> Since ${misc:Pre-Depends} already includes init-system-helpers (>=
> 1.54~) I added lintian overrides. It's a bit dirty though, and the
> line number makes it a moving target. I'll fix the line numbers in the
> lintian overrides but if you know how to fix this in a better way I'm
> all ears.

I see. I suggest you to submit bug aganist Lintian, but in mean time I
am fine uploading with overrides. It may be useful to add reference to
that bug in override comment.

> > Oh, and extremely minor notice: in `debian/control' you align fields
> > with tabs. It does not look pretty, if tabstop is not 8. What about
> > expand(1)?
>
> Ah yeah sorry, I'll untabify this.

Thank you. By the way, you know about wrap-and-sort(1)?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#913027: ITP: hblock -- Improve your security and privacy by blocking ads, tracking and malware domains

[Dmitry Bogatov]

[ Kun-Hung Tsai ]
> > Hi Héctor, I am intending to package this good work.
> > Is it OK to reference files you create for debian package
> > under resources/deb?

[2019-01-20 14:05] Héctor Molinero Fernández 
> Hi, I created those files as an experiment to package hBlock. The generated
> package works correctly, however, I don't know the best practices for
> creating an official package for Debian.
>
> I would be happy to help in any way I can.

Kun-Hung Tsai, are you still working on it? I probably have some free
cycles to help/review/sponsor upload, if you wish.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

[Dmitry Bogatov]

[2019-04-15 09:14] Alessandro Vesely 
> I get this:
> insserv: There is a loop between service umountnfs and rsyslog if stopped
> insserv:  loop involving service rpcbind at depth 3
> insserv:  loop involving service umountnfs at depth 2
> insserv:  loop involving service gdm3 at depth 1
> insserv:  loop involving service sendsigs at depth 2
> insserv:  loop involving service networking at depth 7
> insserv: exiting now without changing boot order!
>
> I run fixinit instead
> http://www.tana.it/sw/fix-init/
> >> Now, as to whether this should be considered a bug or a desired effect
> >> is open to debate. On the one hand it is understandable people might not
> >> want insserv to overwrite their changes. On the other hand, in my case
> >> insserv is fixing a mistake in my symlinks, and adjusting them to match
> >> their LSB headers.
>
> Running interactively in some cases may make sense.  Instead, insserv is run
> every time one installs a package which includes a daemon, automatically.
>
> Nowadays, stable sort algorithms are really widespread.  Adjusting links
> without subverting their existing order is not that hard.

I am not going to implement it, but even as user I fail to understand
your proposal.

Right now insserv implements little more than topological sort. You can
modify relations between scripts by editing LSB headers. What do you
mean 'adjusting links without subvering existing order'? Mind to provide
example?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

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

[Dmitry Bogatov]

[2019-04-14 13:35] Cristian Ionescu-Idbohrn 
> On Sun, 14 Apr 2019, Dmitry Bogatov wrote:
> > 
> > Definitely. But default one is from bin:util-linux.
>
> On my sid/unstable:
>
> # dpkg -S /bin/login
> login: /bin/login

You are right, it is from src:shadow.

> > So I question, how much of this code is actually necessary:
> > 
> >  * group 'utmp' exists on bare system, so conditional is not needed.
> >  * if /var/run/utmp is missing, nothing bad seems to happen, so does
> >this code is needed at all?
> > 
> > Opinions?
>
> IMO, less code is better.  I didn't loog at the source.  But I can 
> see this:
>
> # strings /bin/login | egrep 'utmp|faillog|/'
> /lib64/ld-linux-x86-64.so.2
> /usr/share/locale
> No utmp entry.  You must exec "login" from the lowest level "sh"
> [...]

I took a look at source. It seems that this error may only happen if UID != 0.
I'd better add login maintainers into thread.

Dear login maintainers, currently we have following core executed during
boot:

# 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

It seems that system boots and works just fine without it. Are there any
subtle reasons to keep creating /var/run/utmp in initscripts?

> > PS. Cristian, it seems I did not enough research prior asking you to
> > make patch and caused labour wasted. I am sorry.
>
> No worries.  Still, I would be cautious.  That redirection (with or 
> without a command prefix) is still questionable, as it _truncates_ the 
> file (as opposed to just touching it).

It is under /var/run, which is tmpfs, so it is okay.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#927253: libgnuradio-iqbalance3.7.11: truncated package description and broken home page link

[Daniele Forsi]

Package: libgnuradio-iqbalance3.7.11
Version: 0.37.2-11+b3
Severity: wishlist

Dear Maintainer,

the description says "It's composed of two subblocks:" but the list of the 
blocks is missing.

The https://cgit.osmocom.org/gr-iqbal/tree/MANIFEST.md file from upstream has 
this text:
It's composed of two main block:
 - *fix* : Given a phase and amplitude error, it will correct a complex signal
 - *optimize*: Attempts to auto-detect the phase and amplitude error to feed to
   the fix block above


The homepage link in the .dsc file isn't working, the current address seems to 
be https://cgit.osmocom.org/gr-iqbal/ without /cgit/ in the path.


thanks,
Daniele

Bug#923675: debian-installer: consider using haveged to gather entropy

[Steve McIntyre]

On Tue, Apr 16, 2019 at 11:45:08PM +0200, Cyril Brulebois wrote:
>Cyril Brulebois  (2019-04-16):
>> The former was on my list of things to try; thanks for mentioning the
>> latter.

...

>My initial thought would be to launch it on demand when one is about to
>get to wget calls that needs HTTPS; but we could probably benefit from
>it in case HTTP is requested but redirections to HTTPS happens… There
>are also the obvious keypair generations mentioned above. But then over
>time maybe some other operations could be needing entropy (the
>cryptsetup case is discussed in a separate thread[1]).
>
> 1. https://lists.debian.org/debian-boot/2019/04/msg00153.html
>
>So it might be best to start it unconditionally at start-up?

I'd go with that, yes. What's the down-side?

I'm also pondering doing something similar with "udevadm monitor" -
start it unconditionally, logging to the installer syslog. It'd be a
good extra bit of debug to have.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#927162: gnome-shell segfaults in libst-1.0.so

[Eloston]

After looking at the TopIcons code at the line indicated in journalctl, I am
able to reproduce the crash with the following:

1. Open Looking Glass (lg)
2. Run the following:

a = new St.Widget();
a.destroy();
a.get_theme_node();

After running the third line, gnome-shell will crash.

The second line was borrowed from the TopIcons code at line 121 of
/usr/share/gnome-shell/extensions/topic...@phocean.net/extension.js

On Tue, 2019-04-16 at 22:00 +0100, Simon McVittie wrote:
> Control: retitle -1 gnome-shell: intermittent segfault in
> st_widget_get_theme_node() at st-widget.c:603
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-shell/issues/1018
>
> On Mon, 15 Apr 2019 at 12:12:36 -0700, Eloston wrote:
> > Just using GNOME normally causes the crash to happen.
>
> This is probably going to make it hard to fix the crash or know whether
> it's been fixed, unfortunately. Is there anything you can do that seems
> to make it more likely to happen?
>
> Roughly how often is this happening, in how much use of GNOME?
>
> Is there anything (for instance an upgrade of a package or some packages)
> that coincides with this starting to happen?
>
> > It seems to happen randomly, more so on Wayland. I haven't been able
> > to
> > pinpoint any specific application, extension, or setting.
>
> Does this still happen if you disable all Shell extensions?
>
> What extensions are you normally using?
>
> > I have had this crash happen multiple times on Wayland and X11; this is the
> > first crash where I was able to get a coredump.
>
> Are you using a core-dump-capturing service like systemd-coredump? If
> not, please install systemd-coredump, gdb, gnome-shell-dbgsym (see
> ;) and debug symbols for any
> libraries that appear in the stack trace after you get one. After a crash,
> you should be able to use "coredumpctl gdb" to inspect the core dump,
> and "bt" to get a C-level backtrace (not the same as the Javascript
> backtrace that was logged).
>
> > different each time the crash occurs, e.g. this is the first time I've
> > seen TopIcons show up in the trace. Everything else looks the same.
>
> Please could you quote a few of these things that look the same so that
> we have an overview of what's happening, how the crashes are similar and
> how they're different?
>
> There's a limit to how much information I can extract from the core
> dump, because I'm not running the same versions of everything that you
> are, but this is a start:
>
> (gdb) bt
> #0  0x7f1af86f5ae8 in st_widget_get_theme_node (widget=) at
> ../src/st/st-widget.c:603
> #1  0x7ffdf9b077e0 in  ()
> #2  0x7ffdf9b07908 in  ()
> #3  0x7ffdf9b077e0 in  ()
> #4  0x in  ()
>
> Line 603 is this:
>
> StThemeNode *
> st_widget_get_theme_node (StWidget *widget)
> {
>   StWidgetPrivate *priv = st_widget_get_instance_private (widget);
>
>   if (priv->theme_node == NULL)<--- 603
> {
>   StThemeContext *context;
>
> so presumably something is calling st_widget_get_theme_node() on a widget
> that has been freed or is an invalid pointer - but gdb couldn't decode the
> rest of the stack, so I can't tell what called it.
>
> There's an upstream patch
>  that
> should make this less likely to crash, although it isn't really a full
> solution (something somewhere is still wrong, but we can't tell what).
>
> smcv

Bug#918648: watcher: FTBFS (autobuilder hangs)

[Santiago Vila]

Dear Thomas:

I'm offering two different machines where you can reproduce this hang.

One of them is a START1-S instance from Scaleway. The other is a
n1-standard-1 instance from Google Compute Engine. The package FTBFS
in both of them because sbuild hangs.

You should have already received access details in your private email.

Please let us not release buster with this package in this sorry state
where it only builds for you.

[ Note: It would help if you could make an upload to fix the timezone
  issue by explicitly setting TZ in debian/rules as suggested by
  Adrian Bunk. That way we could see if reproducible-builds autobuilders
  can get past that point or not ].

Thanks.

Bug#927252: linux-4.19.0-4-arm64: Enable SPI CAN drivers for ARM/AARCH64

[Gregor Riepl]

Package: src:linux
Version: 4.19.28-2
Severity: wishlist
Tags: patch

Dear Maintainer,

Please consider enabling the SPI-attached CAN bus drivers in the Debian kernel.
They are useful on ARM SoCs with an SPI bus, such as the Raspberry Pi.

The Raspbian kernel package already includes these drivers, and they do no
harm on platforms that don't use them. To load these drivers, a suitable
DeviceTree config is required.

Thank you!

Here's a patch for .config:

--- a/.config 2019-03-15 02:16:04.0 +
+++ b/.config 2019-04-16 21:46:33.124431597 +
@@ -1696,8 +1699,8 @@
 #
 # CAN SPI interfaces
 #
-# CONFIG_CAN_HI311X is not set
-# CONFIG_CAN_MCP251X is not set
+CONFIG_CAN_HI311X=m
+CONFIG_CAN_MCP251X=m
 
 #
 # CAN USB interfaces


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

** Command line:
bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 
dma.dmachans=0x7f35 bcm2709.boardrev=0xa020d3 bcm2709.serial=0xffbcac2c 
bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=29 
bcm2709.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:BC:AC:2C 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  console=tty0  
root=/dev/mmcblk0p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 cma=256M 
rootwait

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

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

** Model information
Device Tree model: Raspberry Pi 3 Model B Plus Rev 1.3

** Loaded modules:
at24
i2c_dev
ip6t_REJECT
nf_reject_ipv6
nft_counter
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
xt_comment
nft_compat
nf_tables
nfnetlink
nls_ascii
nls_cp437
vfat
fat
btsdio
bluetooth
vc4
drbg
snd_soc_core
ansi_cprng
ecdh_generic
snd_pcm_dmaengine
snd_pcm
microchip
brcmfmac
snd_timer
snd
soundcore
brcmutil
lan78xx
cec
cfg80211
drm_kms_helper
of_mdio
fixed_phy
drm
libphy
rfkill
vchiq(C)
pwm_bcm2835
bcm2835_thermal
bcm2835_rng
rng_core
bcm2835_wdt
leds_gpio
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
aes_arm64
dwc2
udc_core
usbcore
sdhci_iproc
sdhci_pltfm
sdhci
usb_common
bcm2835
i2c_bcm2835
phy_generic

** PCI devices:
not available

** USB devices:
not available


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

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

Versions of packages linux-image-4.19.0-4-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-4.19.0-4-arm64 recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4
ii  irqbalance   1.5.0-3

Versions of packages linux-image-4.19.0-4-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-4-arm64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120190114-1
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#927251: golang-github-getlantern-hidden: FTBFS in sid (missing build-depends)

[Santiago Vila]

Package: src:golang-github-getlantern-hidden
Version: 0.0~git20190325.f02dbb0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_autoreconf -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/golang-github-getlantern-hidden-0.0\~git20190325.f02dbb0/obj-x86_64-linux-gnu/src\"
 
-asmflags=all=\"-trimpath=/<>/golang-github-getlantern-hidden-0.0\~git20190325.f02dbb0/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/getlantern/hidden
src/github.com/getlantern/hidden/hidden.go:11:2: cannot find package 
"github.com/getlantern/hex" in any of:
/usr/lib/go-1.11/src/github.com/getlantern/hex (from $GOROOT)
/<>/obj-x86_64-linux-gnu/src/github.com/getlantern/hex 
(from $GOPATH)
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/golang-github-getlantern-hidden-0.0\~git20190325.f02dbb0/obj-x86_64-linux-gnu/src\"
 
-asmflags=all=\"-trimpath=/<>/golang-github-getlantern-hidden-0.0\~git20190325.f02dbb0/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/getlantern/hidden returned exit code 1
make: *** [debian/rules:4: build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


Looks like a missing build-depends to me.

Thanks.

Bug#927250: golang-github-getlantern-errors: FTBFS in sid (missing build-depends)

[Santiago Vila]

Package: src:golang-github-getlantern-errors
Version: 0.0~git20190325.abdb3e3-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_autoreconf -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/golang-github-getlantern-errors-0.0\~git20190325.abdb3e3/obj-x86_64-linux-gnu/src\"
 
-asmflags=all=\"-trimpath=/<>/golang-github-getlantern-errors-0.0\~git20190325.abdb3e3/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/getlantern/errors
src/github.com/getlantern/hidden/hidden.go:11:2: cannot find package 
"github.com/getlantern/hex" in any of:
/usr/lib/go-1.11/src/github.com/getlantern/hex (from $GOROOT)
/<>/obj-x86_64-linux-gnu/src/github.com/getlantern/hex 
(from $GOPATH)
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/golang-github-getlantern-errors-0.0\~git20190325.abdb3e3/obj-x86_64-linux-gnu/src\"
 
-asmflags=all=\"-trimpath=/<>/golang-github-getlantern-errors-0.0\~git20190325.abdb3e3/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/getlantern/errors returned exit code 1
make: *** [debian/rules:4: build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


Looks like a missing build-depends to me.

Thanks.

Bug#926212: gnome-shell crashed: segfault in libgnome-shell.so after printing email from evolution

[Simon McVittie]

Control: retitle -1 gnome-shell crashed: segfault in libgnome-shell.so after 
printing email from evolution
Control: tags -1 + moreinfo
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-shell/issues/750

I'm retitling this bug to try to stop other people using it to represent
different segfaults, because after someone starts doing that it becomes
really difficult to disentangle who has which bug and which bugs have
been solved.

Upstream bug 750 seems particularly similar.

On Tue, 02 Apr 2019 at 08:11:23 +0200, Guenter Grodotzki wrote:
> [39719.061358] gnome-shell[1279]: segfault at 0 ip 7fd4fa6ae3bf sp
> 7ffcf4dbaea0 error 4 in libgnome-shell.so[7fd4fa6a6000+1f000]

How often has this happened? Is it reproducible, or is it something
that happened once and has not recurred?

On Fri, 05 Apr 2019 at 22:01:58 +0200, Bernhard Übelacker wrote:
> As this information is still kind of small, you might consider
> to install a coredump collector like systemd-coredump.
> That way you could list crashes of the current boot by:
> coredumpctl list
> And some more information is entered into journal that would
> help a lot to triage such crashes ("Stack trace of thread...".
> journalctl --no-pager
> 
> Even better would be if you could install the debug symbol
> packages e.g. gnome-shell-dbgsym like described in [1].
> Then following commands should print a backtrace
> with source line information.

This would be very useful information.

> Nevertheless, I tried if that little information brings
> us somewhere and I think it leads into function
> shell_app_dispose. There, I assume, we reach line 1485,
> unfortunately dereferencing a null pointer
> in app->running_state->windows.
>
> crash instruction  - start .init== diff
> 0x7fd4fa6ae3bf - 0x7fd4fa6a6000 == 0x83BF

How sure are you that the virtual memory area starting at 0x7fd4fa6a6000
starts with .init and not .text?

smcv

Bug#923675: debian-installer: consider using haveged to gather entropy

[Cyril Brulebois]

Control: retitle -1 debian-installer: consider using haveged to gather entropy

Cyril Brulebois  (2019-04-16):
> The former was on my list of things to try; thanks for mentioning the
> latter.

I'm no cryptographer so I cannot judge haveged from that angle.

But from a /proc/sys/kernel/random/entropy_avail standpoint, starting
the haveged daemon inside d-i, a couple of screens after the graphical
installer start-up, I'm getting a bump from ~150 to ~2500.

This needs to be polished before submitting the addition of haveged-udeb
and of course proper integration needs to happen, with real tests… For
wget, we're hitting #926315, but it was luckily closed a couple hours
ago; arm devices that need so much time to generate a keypair should get
a nice improvement…


My initial thought would be to launch it on demand when one is about to
get to wget calls that needs HTTPS; but we could probably benefit from
it in case HTTP is requested but redirections to HTTPS happens… There
are also the obvious keypair generations mentioned above. But then over
time maybe some other operations could be needing entropy (the
cryptsetup case is discussed in a separate thread[1]).

 1. https://lists.debian.org/debian-boot/2019/04/msg00153.html

So it might be best to start it unconditionally at start-up?


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


signature.asc
Description: PGP signature

Bug#923675: Add related bug #916690 info

[Petter Reinholdtsen]

[Ben Hutchings]
> haveged or jitterentropy-rngd are likely to be better.

Is there any hope to run them within d-i in Buster before /target/ is
set up?

-- 
Happy hacking
Petter Reinholdtsen

Bug#661863: Bug#661764: dangling symlink /usr/share/ghostscript/9.05/Resource/CIDFSubst/DroidSansFallback.ttf

[Michael Prokop]

* Manuel A. Fernandez Montecelo [Mon Nov 20, 2017 at 05:25:49PM +0100]:
> 2012-05-17 03:49 Jonas Smedegaard:
> >On 12-05-16 at 09:59am, Ian Zimmerman wrote:

[...]

> >>WTH is really going on here?

> >Oh. You are right!

> >Fixed in git now.  Unfortunately doesn't make Ghostscript use that Font
> >:-(

> Still broken in Stretch, and in unstable:

>  $ echo /usr/share/ghostscript/*/Resource/CIDFSubst/
>  /usr/share/ghostscript/9.22/Resource/CIDFSubst/

>  $ file /usr/share/ghostscript/9.22/Resource/CIDFSubst/DroidSansFallback.ttf
>  /usr/share/ghostscript/9.22/Resource/CIDFSubst/DroidSansFallback.ttf: broken 
> symbolic link to ../../../../fonts/truetype/droid/DroidSansFallbackFull.ttf

And this issue is still present in (current) buster:

$ ls -la /usr/share/ghostscript/9.27/Resource/CIDFSubst/DroidSansFallback.ttf
lrwxrwxrwx 1 root root 58 Apr  4 20:17 
/usr/share/ghostscript/9.27/Resource/CIDFSubst/DroidSansFallback.ttf -> 
../../../../fonts/truetype/droid/DroidSansFallbackFull.ttf
$ realpath /usr/share/ghostscript/9.27/Resource/CIDFSubst/DroidSansFallback.ttf
realpath: /usr/share/ghostscript/9.27/Resource/CIDFSubst/DroidSansFallback.ttf: 
No such file or directory
$ file /usr/share/ghostscript/9.27/Resource/CIDFSubst/DroidSansFallback.ttf
/usr/share/ghostscript/9.27/Resource/CIDFSubst/DroidSansFallback.ttf: broken 
symbolic link to ../../../../fonts/truetype/droid/DroidSansFallbackFull.ttf

So what needs to be done about this to finally get rid of this bug? :)

regards
-mika-


signature.asc
Description: Digital signature

Bug#927249: unblock: tasksel/3.52

[Holger Wansing]

Package: release.debian.org
Usertags: unblock


I would like to request an unblock for version 3.52 of tasksel.
Currently, we have 3.50 in buster.


The changings contain:

- Translation update for Czech, Danish and Norwegian Bokmål
- Revert a change from 3.49 (which removed anacron from some tasks)
- Move from myspell-* to hunspell-* for some languages
- Update packages to new situations in Buster (add some new packages, remove 
  no-longer-existing packages, replace some transitional packages by 
  their Depends, remove outdated documentation packages)


A corresponding debdiff is attached.



Thanks
Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff -Nru tasksel-3.50/debian/changelog tasksel-3.52/debian/changelog
--- tasksel-3.50/debian/changelog	2019-02-08 22:28:45.0 +0100
+++ tasksel-3.52/debian/changelog	2019-04-02 22:48:50.0 +0200
@@ -1,3 +1,36 @@
+tasksel (3.52) unstable; urgency=medium
+  * Team upload.
+
+  [ Updated translations ]
+  * Czech (cs.po) by Miroslav Kure
+
+ -- Holger Wansing   Tue, 02 Apr 2019 22:48:50 +0200
+
+tasksel (3.51) unstable; urgency=medium
+  * Team upload.
+
+  * Add firefox-l10n-ne-np to task-nepali-desktop. Closes: #922123
+  * Re-add anacron to task-desktop and task-laptop (removed in 3.49).
+Closes: #924037, #915370
+  * task-catalan-desktop: replace removed myspell-ca by hunspell-ca.
+Closes: #910615
+  * task-greek-desktop: remove no longer existing fonts-mgopen. Closes: #823150
+  * Some clean-up: (Closes: #923975)
+  * Remove several no longer existing packages.
+  * Remove some badly outdated documentation packages.
+  * Replace some transitional packages by their Depends.
+  * Correct name inconsistency in tasks/uyghur-desktop.
+  * Replace transitional package myspell-bg by its Depends hunspell-bg.
+Closes: #824729
+  * Replace some more myspell-* transitional packages by their Depends
+(hunspell-*).
+
+  [ Updated debconf translations ]
+  * Danish (da.po) by Joe Dalton.
+  * Norwegian Bokmål (nb.po) by Petter Reinholdtsen.
+
+ -- Holger Wansing   Sun, 10 Mar 2019 23:12:54 +0100
+
 tasksel (3.50) unstable; urgency=medium
   * Team upload.
 
diff -Nru tasksel-3.50/debian/control tasksel-3.52/debian/control
--- tasksel-3.50/debian/control	2019-02-01 00:40:45.0 +0100
+++ tasksel-3.52/debian/control	2019-03-10 23:11:31.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Install System Team 
 Uploaders: Christian Perrier ,
-   Nicolas Braud-Santoni 
+   Nicolas Braud-Santoni 
 Standards-Version: 4.1.4
 Build-Depends: po-debconf, debhelper (>= 9), gettext, dpkg-dev (>= 1.9.0)
 Vcs-Browser: https://salsa.debian.org/installer-team/tasksel
@@ -51,6 +51,8 @@
 # mdns/zeroconf stuff
 	avahi-daemon,
 	libnss-mdns,
+# desktop machines might not be up 24/7
+	anacron,
 # Make sure that CDs etc can be ejected. May not be installed by d-i.
 	eject,
 # wireless networking tools (they're more and more used on desktops too)
@@ -300,6 +302,7 @@
 Description: laptop
  This task package installs software useful for a laptop.
 Depends: ${misc:Depends},
+	anacron,
 Recommends:
 	avahi-autoipd,
 	bluetooth,
@@ -535,7 +538,7 @@
 Recommends:
 	libreoffice-l10n-bs,
 	firefox-esr-l10n-bs | firefox-l10n-bs,
-	myspell-hr
+	hunspell-hr
 
 Package: task-bosnian-kde-desktop
 Architecture: all
@@ -571,7 +574,7 @@
 Recommends:
 	libreoffice-l10n-pt-br,
 	firefox-esr-l10n-pt-br | firefox-l10n-pt-br,
-	myspell-pt-br
+	hunspell-pt-br
 
 Package: task-brazilian-portuguese-kde-desktop
 Architecture: all
@@ -623,7 +626,7 @@
 	libreoffice-l10n-bg,
 	firefox-esr-l10n-bg | firefox-l10n-bg,
 	fonts-dejavu,
-	myspell-bg
+	hunspell-bg
 
 Package: task-bulgarian-kde-desktop
 Architecture: all
@@ -656,7 +659,7 @@
 	firefox-esr-l10n-ca | firefox-l10n-ca,
 	libreoffice-l10n-ca,
 	libreoffice-help-ca,
-	myspell-ca
+	hunspell-ca
 
 Package: task-catalan-kde-desktop
 Architecture: all
@@ -677,7 +680,6 @@
 	opencc,
 	zhcon,
 	manpages-zh,
-	fortune-zh
 
 Package: task-chinese-s-desktop
 Architecture: all
@@ -778,7 +780,7 @@
 Recommends:
 	hyphen-hr,
 	libreoffice-l10n-hr,
-	myspell-hr,
+	hunspell-hr,
 	firefox-esr-l10n-hr | firefox-l10n-hr,
 
 Package: task-croatian-kde-desktop
@@ -872,7 +874,7 @@
 	firefox-esr-l10n-nl | firefox-l10n-nl,
 	libreoffice-l10n-nl,
 	libreoffice-help-nl,
-	myspell-nl
+	hunspell-nl
 
 Package: task-dutch-kde-desktop
 Architecture: all
@@ -985,7 +987,6 @@
 	libreoffice-l10n-fi,
 	libreoffice-voikko,
 	firefox-esr-l10n-fi | firefox-l10n-fi,
-	xul-ext-mozvoikko
 
 Package: task-finnish-kde-desktop
 Architecture: all
@@ -1002,8 +1003,6 @@
  to help French speaking people use Debian.
 Depends: ${misc:Depends},
 Recommends:
-	doc-linux-fr-text,
-	doc-debian-fr,
 	ifrench-gut,
 	wfrench,
 	aspell-fr,
@@ -1123,7 +1122,6 @@
 Depends: ${misc:Depends},
 Recommends:
 	fonts-freefont-ttf,
-	fonts-mgopen,
 	libreoffice-l10n-el,
 	firefox-esr-l10n-el | 

Bug#926231: [debian-mysql] Bug#926231: mariadb-server-10.3: dpkg configure error - upgrade from mysql

[Brad Rogers]

On Tue, 16 Apr 2019 11:33:23 +0300
Otto Kekäläinen  wrote:

Hello Otto,

>I am sorry but I am not able to replicate this bug. So it cannot at
>least be common, thus downgrading severity.
>
>Please figure out a way for me to replicate it so I can debug what is
>happening. Also, check out if there is any output at /var/log/mysql/*

I'm not the original bug submitter, but I hope I can offer some help, as
I have successfully worked around the problem;

Here, the mysql server was not running, and the mariadb-server-10.3
upgrade failed.

I couldn't restart the server, but after some searching the internet I
found that doing the following:

root# rm /var/lib/mysql/ib*
user$ /etc/init.d/mysql start

got the server running.  Then, I tried:

#dpkg --configure mariadb-server-10.3

which, after a few minutes, succeeded.

I have no idea how, when or why the problem (i.e. server stopped running)
occurred, but I'm now back on track.

I hope this of help to the original submitter, as well as yourself.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
I can't do a thing 'cause I can't relax
Independence Day - Comsat Angels


pgpsewCMvWK5C.pgp
Description: OpenPGP digital signature

Bug#925506: stretch-pu: package java-common/0.58+deb9u1

[Moritz Mühlenhoff]

On Tue, Apr 16, 2019 at 10:04:20AM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2019-04-15 at 22:49 +0200, Moritz Mühlenhoff wrote:
> > On Sun, Apr 14, 2019 at 09:20:13PM +0100, Adam D. Barratt wrote:
> > > Control: tags -1 + moreinfo
> > > 
> > > On Mon, 2019-03-25 at 22:35 +0100, Moritz Muehlenhoff wrote:
> > > > How about the following debdiff to address the fallout of
> > > > the Xul deprecation in icedtea-web (#921748) for the next
> > > > point update?
> > > > 
> > > > default-jre is the only reverse dependency of
> > > > default-java-plugin, so the patch also removes default-java-
> > > > plugin
> > > > along.
> > > 
> > > I assume the upgrade path from systems with the packages already
> > > installed has been tested without issue?
> > 
> > I think so:
> > I've upgraded my stretch desktop with java-common and the various
> > default-foo packages from the previous version to the new release
> > for about two weeks now, given that the only in-archive reverse
> > dep of default-java-plugin was in java-common, I can't think of
> > another upgrade path to test.
> 
> OK, thanks; please go ahead.

Ack, uploaded.
 
> Based on experience from the previous attempt at fixing this, I imagine
>  #debian will tell us if there is still a problem. :-)

Best CI in the world!

Cheers,
Moritz

Bug#927162: gnome-shell segfaults in libst-1.0.so

[Simon McVittie]

Control: retitle -1 gnome-shell: intermittent segfault in 
st_widget_get_theme_node() at st-widget.c:603
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-shell/issues/1018

On Mon, 15 Apr 2019 at 12:12:36 -0700, Eloston wrote:
> Just using GNOME normally causes the crash to happen.

This is probably going to make it hard to fix the crash or know whether
it's been fixed, unfortunately. Is there anything you can do that seems
to make it more likely to happen?

Roughly how often is this happening, in how much use of GNOME?

Is there anything (for instance an upgrade of a package or some packages)
that coincides with this starting to happen?

> It seems to happen randomly, more so on Wayland. I haven't been able 
> to
> pinpoint any specific application, extension, or setting.

Does this still happen if you disable all Shell extensions?

What extensions are you normally using?

> I have had this crash happen multiple times on Wayland and X11; this is the
> first crash where I was able to get a coredump.

Are you using a core-dump-capturing service like systemd-coredump? If
not, please install systemd-coredump, gdb, gnome-shell-dbgsym (see
) and debug symbols for any
libraries that appear in the stack trace after you get one. After a crash,
you should be able to use "coredumpctl gdb" to inspect the core dump,
and "bt" to get a C-level backtrace (not the same as the Javascript
backtrace that was logged).

> different each time the crash occurs, e.g. this is the first time I've
> seen TopIcons show up in the trace. Everything else looks the same.

Please could you quote a few of these things that look the same so that
we have an overview of what's happening, how the crashes are similar and
how they're different?

There's a limit to how much information I can extract from the core
dump, because I'm not running the same versions of everything that you
are, but this is a start:

(gdb) bt
#0  0x7f1af86f5ae8 in st_widget_get_theme_node (widget=) at 
../src/st/st-widget.c:603
#1  0x7ffdf9b077e0 in  ()
#2  0x7ffdf9b07908 in  ()
#3  0x7ffdf9b077e0 in  ()
#4  0x in  ()

Line 603 is this:

StThemeNode *
st_widget_get_theme_node (StWidget *widget)
{
  StWidgetPrivate *priv = st_widget_get_instance_private (widget);

  if (priv->theme_node == NULL)<--- 603
{
  StThemeContext *context;

so presumably something is calling st_widget_get_theme_node() on a widget
that has been freed or is an invalid pointer - but gdb couldn't decode the
rest of the stack, so I can't tell what called it.

There's an upstream patch
 that
should make this less likely to crash, although it isn't really a full
solution (something somewhere is still wrong, but we can't tell what).

smcv

Bug#927184: SATA SSD affected as well

[Yury Vidineev]

Looks like SATA SSD affected as well. Another example:


Device    r/s w/s rMB/s wMB/s   rrqm/s wrqm/s  
%rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm  %util
sda  0.47    8.94  0.01  0.48 0.00 8.05   0.10  
47.39    0.25    1.29   0.97    11.60    54.71 101.89  95.93



cat /proc/diskstats
   8   0 sda 491891 492 11411048 123425 9276833 8357440 1015034844 
11962746 0 995354116 1004716180 196878 0 1461959742 168844
   8   1 sda1 626 12 9590 187 77 249 56356 333 0 340 616 161 0 
269038 137
   8   2 sda2 4500 182 41464 1101 20884 15531 348440 2415 0 2604 
3184 0 0 0 0
   8   3 sda3 486635 298 11353698 122074 9222603 8341660 1014630048 
11958045 0 2035580 9165808 196717 0 1461690704 168706



Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sda: 480GB

Bug#927248: ITP: redfishtool -- redfish command-line client

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: redfishtool
  Version : 1.0.8
  Upstream Author : DMTF, https://www.dmtf.org/standards/feedback
* URL : https://github.com/DMTF/Redfishtool
* License : BSD-3-clause
  Programming Lang: Python
  Description : redfish command-line client

 Redfishtool is a commandline tool that implements the client side of the
 Redfish RESTful API for Data Center Hardware Management.
 .
 Redfish is the new RESTful API for hardware management defined by the DMTF
 Scalable Platform Management Forum (SPMF). It provides a modern, secure,
 multi-node, extendable interface for doing hardware management. The initial
 release included hardware inventory, server power-on/off/reset, reading power
 draw, setting power limits, reading sensors such as fans, read/write of ID
 LEDs, asset tags, and went beyond IPMI in functionality to include inventory
 of processors, storage, Ethernet controllers, and total memory. New Redfish
 extensions have now been added to the spec and include firmware update, BIOS
 config, memory inventory, direct attached storage control, and the list grows.
 .
 redfishtool makes it simple to use the Redfish API from a BASH script or
 interactively from a client command shell.
 .
 While other generic HTTP clients such as Linux curl can send and receive
 Redfish requests, redfishtool goes well beyond these generic HTTP clients by
 automatically handling many of the hypermedia and Redfish-specific protocol
 aspects of the Redfish API that require a client to often execute multiple
 queries to a redfish service to walk the hypermedia links from the redfish
 root down to the detailed URI of a specific resource (eg Processor-2 of
 Blade-4 in a computer blade system). Specifically, redfishtool provides the
 following functions over curl:
 .
  * implements Redfish Session Authentication as well as HTTP Basic Auth
  * walks the Redfish schema following strict interoperpbility processors...]
to find find the targeted instance based on Id, UUID, URL or other
attributes
  * handles GETs for collections that are returned in multiple pieces-requiring
client to read in a loop until the full collection is returned
  * handles ETag and If-Match headers when PATCHing a resource to write
properties
  * implements many common set or action operations with simple commandline
syntax (eg server reset, setting LEDs, assetTag, powerLimits, etc)
  * negotiates the latest redfish protocol version between client and service
(demonstrating the proper way to do this)
  * can read specific properties of a resource, or expand collections to
include all members of the collection expanded
  * supports adding and deleting users, and common Redfish account service
operations
  * For debug, provides multiple levels of verbose output to add descriptive
headers, and show what HTTP requests are being executed
  * For debug, includes multiple levels of status display showing HTTP status
codes and headers returned and sent
  * For easy parsing, outputs all responses in JSON format unless verbose or
status debug options were specified

Bug#923675: Add related bug #916690 info

[Cyril Brulebois]

Ben Hutchings  (2019-04-16):
> On Tue, 2019-04-16 at 13:57 +0200, Petter Reinholdtsen wrote:
> > [Ben Hutchings]
> > > This is a pretty terrible approach.  Especially as the world has moved
> > > on to SSDs and they provide very little entropy from interrupts.
> > 
> > Absolutely.  But it has solved the  problem with too little entropy since 
> > 2011.
> > Do you have any better ways to force the kernel to add some entropy when 
> > running
> > low?
> 
> haveged or jitterentropy-rngd are likely to be better.

The former was on my list of things to try; thanks for mentioning the latter.


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


signature.asc
Description: PGP signature

Bug#927199: unblock: gnome-shell/3.30.2-6

[Simon McVittie]

On Tue, 16 Apr 2019 at 11:37:31 +0200, Ivo De Decker wrote:
> Also, are you aware of these bugs:
> 
> https://bugs.debian.org/926212 gnome-shell crashed (segfault)
> https://bugs.debian.org/927162 gnome-shell segfaults in libst-1.0.so
> 
> It would probably be good to have a fix for that.

If I knew how to fix them, I would, but fixing crashes that I've never
seen myself is not something that I can do instantly.

smcv

Bug#926404: /usr/bin/pdfsig: pdfsig: segfaults with "couldn't find default Firefox Folder"

[Bernhard Übelacker]

Am 16.04.19 um 12:04 schrieb Bernhard Reiter:
>> there was neither /etc/pki/nssdb nor a firefox profile in the
>> home directory.
> 
> Can you post the signature information?
> My guess from the code is that you saw the info,
> but no certification validation.

benutzer@debian:~$ /usr/bin/pdfsig SampleSignedPDFDocument.pdf
Digital Signature Info of: SampleSignedPDFDocument.pdf
Internal Error (0): couldn't find default Firefox Folder
Signature #1:
  - Signer Certificate Common Name: John B Harris
  - Signer full Distinguished Name: E=jbhar...@adobe.com,CN=John B 
Harris,O=Adobe Systems Incorporated,L=San Jose,ST=CA,C=US
  - Signing Time: Jul 16 2009 16:47:47
  - Signing Hash Algorithm: SHA1
  - Signature Type: adbe.pkcs7.detached
  - Signed Ranges: [0 - 227012], [248956 - 272318]
  - Total document signed
  - Signature Validation: Signature is Valid.
  - Certificate Validation: Certificate has Expired

With the patch applied and the file from here:
https://blogs.adobe.com/security/SampleSignedPDFDocument.pdf

Bug#921952: [Pkg-sass-devel] Bug#921952: Don't include in buster without proper commitment to update in stable

[Aljoscha Lautenbach]

Hi,

> @Aljoscha: Thanks for your initial work and - more so - for
> committing to help generally looking after these security issues in
> libsaass.

> Due to the expansion of the libsass team with Aljoscha, I am
> lowering severity of this bugreport.

Just in case that was not clear in my initial message, that is indeed
the intention. On any given week I can spend 0.5 to 4 hours on this,
so this will not be an instantaneous change, but a slow and steady
effort.

I have continued to update the little CVE table I sent earlier, and I
will start to update and file bugs accordingly soon (where
"soon" ~= 3 weeks, due to upcoming vacation).

Kind regards,
Aljoscha

On Tue, 16 Apr 2019 at 16:51, Jonas Smedegaard  wrote:
>
> control: severity -1 important
>
> Quoting Aljoscha Lautenbach (2019-04-09 23:03:06)
> > during the BSP in Gothenburg last weekend I discussed with Jonas how I
> > could help to put libsass back on track regarding its security status.
> > We agreed that the best move is to start with triaging the existing
> > Debian bugs and by identifying the CVE status in upstream's issue
> > tracker. [0]
>
> @Aljoscha: Thanks for your initial work and - more so - for committing
> to help generally looking after these security issues in libsaass.
>
> Due to the expansion of the libsass team with Aljoscha, I am lowering
> severity of this bugreport.
>
> If the security team or others disagree, then please elaborate what you
> consider is needed.
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#927247: usbip: qemu destructively resets usbip device

[sg]

Package: usbip
Version: 2.0+4.9.144-3.1
Severity: important

Dear Maintainer,

When passing a usbip device to qemu, qemu appears to reenumerate the
device which causes the connection to the usbipd to become upset. The
device is then unavailable for use in the VM or on the usbip client.

The device in question is an HID device and works when passed through on
what is intended to the be the server computer to a VM. Modules were
blacklisted to ensure they did not upset qemu's capture of the device
fds.

Once the VM starts dmesg logs failure to enumerate messages, and
admonishes the user to check the cable.

I apologize for marking the bug as important but it makes the package
useless for my purposes.

Cheers,
   sg

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

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

Versions of packages usbip depends on:
ii  libc6 2.24-11+deb9u4
ii  libudev1  232-25+deb9u11
ii  libwrap0  7.6.q-26
ii  usbutils  1:007-4+b1

usbip recommends no packages.

usbip suggests no packages.

-- no debconf information

Bug#927246: usbip: QEMU destructively resets USBIP devices

[powerpaper]

Package: usbip
Version: 2.0+4.9.144-3.1
Severity: normal
Tags: upstream

Dear Maintainer,

Attempting to pass a usbip device to qemu fails. Qemu resets the device
and it does not reappear. Dmesg prompts warn of checking the cable
connection and that the device does not enumerate.

It is suspected qemu reenumerates the device and this causes usbip to
drop the connection but I can not be sure.

The device passes to a VM when done directly.

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

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

Versions of packages usbip depends on:
ii  libc6 2.24-11+deb9u4
ii  libudev1  232-25+deb9u11
ii  libwrap0  7.6.q-26
ii  usbutils  1:007-4+b1

usbip recommends no packages.

usbip suggests no packages.

-- no debconf information

Bug#927245: caveconverter: FTBFS (jh_build: Cannot find "caveconverter")

[Santiago Vila]

Package: src:caveconverter
Version: 0~20170114-4
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules binary-indep
dh --with javahelper binary-indep
dh: Compatibility levels before 9 are deprecated (level 7 in use)
   dh_update_autotools_config -i
   dh_auto_configure -i
dh_auto_configure: Compatibility levels before 9 are deprecated (level 7 in use)
   jh_linkjars -i
   dh_auto_build -i
dh_auto_build: Compatibility levels before 9 are deprecated (level 7 in use)
ant -Duser.name debian
Buildfile: /<>/build.xml

clean.tests:

clean:

init:
 [echo] JAVA_HOME = /usr/lib/jvm/default-java
[mkdir] Created dir: /<>/build/classes
[mkdir] Created dir: /<>/dist
[mkdir] Created dir: /<>/build/test/data/private

compile:
[javac] Compiling 24 source files to /<>/build/classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 6
[javac] warning: [options] source value 6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] Note: 
/<>/src/footleg/cavesurvey/data/reader/PocketTopoParser.java uses 
or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 4 warnings
 [copy] Copying 9 files to 
/<>/build/classes/footleg/cavesurvey/gui/swing/images
 [copy] Copying 1 file to 
/<>/build/classes/footleg/cavesurvey/gui

jar:

makejar:
  [jar] Building jar: /<>/build/CaveConverter.jar

guijar:

makejar:
  [jar] Building jar: /<>/build/CaveConverterGUI.jar

zip:
  [zip] Building zip: /<>/dist/CaveConverter.zip

zipsrc:
  [zip] Building zip: /<>/dist/CaveConverter-src.zip

instrument.java:
[cobertura-instrument] 00:15:17,186 |-INFO in 
ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource 
[logback-test.xml]
[cobertura-instrument] 00:15:17,187 |-INFO in 
ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource 
[logback.groovy]
[cobertura-instrument] 00:15:17,187 |-INFO in 
ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at 
[jar:file:/usr/share/java/cobertura-2.1.1.jar!/logback.xml]
[cobertura-instrument] 00:15:17,189 |-WARN in 
ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs 
multiple times on the classpath.
[cobertura-instrument] 00:15:17,189 |-WARN in 
ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs 
at [jar:file:/usr/share/java/cobertura-2.1.1.jar!/logback.xml]
[cobertura-instrument] 00:15:17,189 |-WARN in 
ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs 
at [jar:file:/usr/share/java/cobertura.jar!/logback.xml]
[cobertura-instrument] 00:15:17,221 |-INFO in 
ch.qos.logback.core.joran.spi.ConfigurationWatchList@6393bf8b - URL 
[jar:file:/usr/share/java/cobertura-2.1.1.jar!/logback.xml] is not of type file
[cobertura-instrument] 00:15:17,274 |-INFO in 
ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not 
set
[cobertura-instrument] 00:15:17,276 |-INFO in 
ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender 
of type [ch.qos.logback.core.ConsoleAppender]
[cobertura-instrument] 00:15:17,292 |-INFO in 
ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
[cobertura-instrument] 00:15:17,302 |-INFO in 
ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default 
type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] 
property
[cobertura-instrument] 00:15:17,381 |-INFO in 
ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger 
[net.sourceforge.cobertura] to INFO
[cobertura-instrument] 00:15:17,381 |-INFO in 
ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT 
logger to DEBUG
[cobertura-instrument] 00:15:17,381 |-INFO in 
ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named 
[STDOUT] to Logger[ROOT]
[cobertura-instrument] 00:15:17,385 |-INFO in 
ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
[cobertura-instrument] 00:15:17,387 |-INFO in 
ch.qos.logback.classic.joran.JoranConfigurator@76d7881e - Registering current 
configuration as safe fallback point
[cobertura-instrument] 
[cobertura-instrument] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See 
COPYRIGHT file
[cobertura-instrument] [INFO] Cobertura: Saved information on 55 classes.
[cobertura-instrument] [INFO] Cobertura: Saved information on 55 classes.

init.tests:
[mkdir] Created dir: /<>/build/test_classes
[mkdir] Created dir: /<>/build/reports

compile.test:
[javac] Compiling 18 source files to 

Bug#927244: mina: FTBFS (Unknown option: source 1.7 -target 1.7)

[Santiago Vila]

Package: src:mina
Version: 1.1.7.dfsg-12
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with javahelper
   dh_update_autotools_config -i
   dh_autoreconf -i
   jh_linkjars -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
# Build the packages
( CLASSPATH=/usr/share/java/slf4j-api.jar jh_build -J -o"-source 1.7 -target 
1.7" mina-core.jar core/src/main/java/  )
Unknown option: source 1.7 -target 1.7
jh_build: unknown option or error during option parsing; aborting
make[1]: *** [debian/rules:43: override_dh_auto_build] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:39: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mina.html

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#921232: Tracking it down

[Jo Shields]

Seems fixed in cd70e9cf2adc03681dbb919d97063d8ad84b0a4c, will apply this
against Debian packaging & upload

On 15/04/2019 22:55, Joseph Shields wrote:
> This is fine in master, but I can repro it with an otherwise clean upstream 
> git tag w/ our 4 s390x backports. Bisecting.

Bug#927243: jtb: FTBFS (jh_build: Cannot find "EDU")

[Santiago Vila]

Package: src:jtb
Version: 1.4.12-1.1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with javahelper
   dh_update_autotools_config -i
   dh_auto_configure -i
   jh_linkjars -i
   dh_auto_build -i
ant -Duser.name debian
Buildfile: /<>/build.xml

echo_jtb_props:
 [echo] jtb_proj_dir=/<>
 [echo] jtb_last_version=1.4.11
 [echo] jtb_curr_version=1.4.12
 [echo] jtb_bs_jar=/<>/lib/jtb132.jar
 [echo] jtblv=/<>/lib/jtb-1.4.11.jar
 [echo] jtb_last_jar=/<>/lib/jtb-1.4.11.jar
 [echo] jtb_new_jar=/<>/lib/new_jtb-1.4.12.jar
 [echo] jtb_prev_jar=/<>/lib/jtb-1.4.12.jar
 [echo] jtb_ok_jar=/<>/lib/jtb-1.4.12.jar

echo_javacc_props:
 [echo] 
javacc_imp_dir=/usr/share/maven-repo/net/java/dev/javacc/javacc/debian
 [echo] 
javacc_ok_jar=/usr/share/maven-repo/net/java/dev/javacc/javacc/debian/javacc-debian.jar
 [echo] javacc_main=org.javacc.parser.Main

echo_all_props:

clean_javacc_gen_files:

clean_jtb_gen_files:

clean_all_gen_files:

process_jtbgram.jtb:
 [java] JTB version 1.4.12
 [java] JTB:  Reading jtb input file 
/<>/src/EDU/purdue/jtb/jtbgram.jtb...
 [java] JTB:  jtb input file parsed successfully.
 [java] JTB:  jj output file 
"/<>/src/EDU/purdue/jtb/jtb.out.jj" generated.
 [java] JTB:  base node class files generated into directory 
"/<>/src/EDU/purdue/jtb/syntaxtree".
 [java] JTB:  134 syntax tree node class files generated into directory 
"/<>/src/EDU/purdue/jtb/syntaxtree".
 [java] 
 [java] JTB:  Visitor interface "IRetArguVisitor.java" generated into 
directory "/<>/src/EDU/purdue/jtb/visitor".
 [java] JTB:  Visitor interface "IVoidVisitor.java" generated into 
directory "/<>/src/EDU/purdue/jtb/visitor".
 [java] JTB:  Visitor interface "IRetVisitor.java" generated into directory 
"/<>/src/EDU/purdue/jtb/visitor".
 [java] JTB:  Visitor interface "IVoidArguVisitor.java" generated into 
directory "/<>/src/EDU/purdue/jtb/visitor".
 [java] JTB:  Visitor class "DepthFirstRetArguVisitor.java" generated into 
directory "/<>/src/EDU/purdue/jtb/visitor".
 [java] JTB:  Visitor class "DepthFirstRetVisitor.java" generated into 
directory "/<>/src/EDU/purdue/jtb/visitor".
 [java] JTB:  Visitor class "DepthFirstVoidArguVisitor.java" generated into 
directory "/<>/src/EDU/purdue/jtb/visitor".
 [java] JTB:  Visitor class "DepthFirstVoidVisitor.java" generated into 
directory "/<>/src/EDU/purdue/jtb/visitor".
 [java] 

process_jtb.out.jj:
 [java] Java Compiler Compiler Version 5.0 (Parser Generator)
 [java] (type "javacc" with no arguments for help)
 [java] Reading from file /<>/src/EDU/purdue/jtb/jtb.out.jj . 
. .
 [java] Warning: Line 119, Column 1: Command line setting of 
"OUTPUT_DIRECTORY" modifies option value in file.
 [java] File "TokenMgrError.java" does not exist.  Will create one.
 [java] File "ParseException.java" does not exist.  Will create one.
 [java] File "Token.java" does not exist.  Will create one.
 [java] File "JavaCharStream.java" does not exist.  Will create one.
 [java] Parser generated with 0 errors and 1 warnings.

copy_specific_token_for_jtb:
 [copy] Copying 1 file to /<>/src/EDU/purdue/jtb/parser

generate_all:

generate_all+compile_java:

compile_java:
[javac] Compiling 234 source files to /<>/bin
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 7
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 warning

build_new_jtb_jar:

check_jtb_jar:

make_new_jtb_jar:
  [jar] Building jar: /<>/lib/new_jtb-1.4.12.jar

test_process_jtbgram.jtb:
 [java] JTB version 1.4.12
 [java] JTB:  Reading jtb input file 
/<>/src/EDU/purdue/jtb/jtbgram.jtb...
 [java] java.lang.NullPointerException
 [java] at 
EDU.purdue.jtb.parser.JTBToolkit.makeNodeToken(JTBParser.java:12271)
 [java] at 
EDU.purdue.jtb.parser.JTBParser.JavaCCOptions(JTBParser.java:288)
 [java] at 
EDU.purdue.jtb.parser.JTBParser.JavaCCInput(JTBParser.java:206)
 [java] at EDU.purdue.jtb.JTB.do_main(JTB.java:168)
 [java] at EDU.purdue.jtb.JTB.main(JTB.java:136)
 [java] 
 [java] /<>/src/EDU/purdue/jtb/jtbgram.jtb:  unexpected 
program error:  null
 [java] Please report this to JTB support 
(https://github.com/jtb-javacc/JTB)
 [java] 
 [java] java.lang.NullPointerException
 [java] at 
EDU.purdue.jtb.parser.JTBToolkit.makeNodeToken(JTBParser.java:12271)
 [java] at 
EDU.purdue.jtb.parser.JTBParser.JavaCCOptions(JTBParser.java:288)
 [java] at 
EDU.purdue.jtb.parser.JTBParser.JavaCCInput(JTBParser.java:206)
 [java] at EDU.purdue.jtb.JTB.do_main(JTB.java:168)
 [java] at 

Bug#922315: "set " pulls in -o/+o names too

[積丹尼 Dan Jacobson]

GFTG> while this is broken, you could use Alt+/ to complete with filenames.

Ah, (or ESC /). Good to know.

Bug#923675: Add related bug #916690 info

[Ben Hutchings]

On Tue, 2019-04-16 at 13:57 +0200, Petter Reinholdtsen wrote:
> [Ben Hutchings]
> > This is a pretty terrible approach.  Especially as the world has moved
> > on to SSDs and they provide very little entropy from interrupts.
> 
> Absolutely.  But it has solved the  problem with too little entropy since 
> 2011.
> Do you have any better ways to force the kernel to add some entropy when 
> running
> low?

haveged or jitterentropy-rngd are likely to be better.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.



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

Bug#926896: sysvinit-utils: pidof is unreliable

[Witold Baryluk]

Package: sysvinit-utils
Version: 2.93-8
Followup-For: Bug #926896

Hi Dmitry,

I tested 'dd if=/dev/urandom of=/dev/null' and it works.
Both when dd is running under normal user and as root.
And when pidof is running as normal user and as root.
(it also works when dd is run as root, and pidof as normal user,
because relevant data is still in procfs and in ps aux).

It also works fine with 'bs=64k'

Weird.

I will try to test it again with different if/of.

Thanks for checking.


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

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

Versions of packages sysvinit-utils depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-8
ii  util-linux   2.33.1-0.1

sysvinit-utils recommends no packages.

sysvinit-utils suggests no packages.

-- no debconf information

Bug#927224: u-boot-sunxi: orangepi_zero_plus2 board support is not in the package

[Vagrant Cascadian]

On 2019-04-16, Frédéric Danis wrote:
> This board is supported upstream in this version but not embedded in the 
> package.
> Please find attached a patch to add it.
>
> Tested with Debian sid and latest unstable arm64 kernel
> 4.19.0-4-arm64.

Thanks for the patch!

It also appears to have a configuration available in u-boot
2019.01. Would you be able to also test that version, so we can add
support in the buster release?

live well,
  vagrant

> From 5ac8cddedb108991095d40cd8a7d863fd455983f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Danis?= 
> Date: Tue, 16 Apr 2019 14:26:14 +0200
> Subject: [PATCH] Enable orangepi_zero_plus2 target in u-boot-sunxi
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
>
> ---
>  debian/bin/u-boot-install-sunxi64 | 1 +
>  debian/targets| 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/debian/bin/u-boot-install-sunxi64 
> b/debian/bin/u-boot-install-sunxi64
> index 3612edab51..5c48ab9c53 100755
> --- a/debian/bin/u-boot-install-sunxi64
> +++ b/debian/bin/u-boot-install-sunxi64
> @@ -8,6 +8,7 @@ if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
>   Pine64+) TARGET="/usr/lib/u-boot/pine64_plus" ;;
>   "Olimex A64-Olinuxino") TARGET="/usr/lib/u-boot/a64-olinuxino/" 
> ;;
>   "Olimex A64 Teres-I") TARGET="/usr/lib/u-boot/teres_i/" ;;
> + "OrangePi Zero Plus2") 
> TARGET="/usr/lib/u-boot/orangepi_zero_plus2/" ;;
>   esac
>  fi
>  
> diff --git a/debian/targets b/debian/targets
> index 7d6d98c5f4..777b29677d 100644
> --- a/debian/targets
> +++ b/debian/targets
> @@ -201,6 +201,9 @@ arm64 rpi rpi_3   u-boot.bin
>  # Rodrigo Exterckötter Tjäder 
>  arm64sunxi   a64-olinuxino   u-boot.bin spl/sunxi-spl.bin 
> u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino.dtb
>  
> +# Frederic Danis 
> +arm64sunxi   orangepi_zero_plus2 u-boot.bin 
> spl/sunxi-spl.bin u-boot-nodtb.bin 
> arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dtb
> +
>  # Vagrant Cascadian 
>  arm64sunxi   pine64_plus u-boot.bin spl/sunxi-spl.bin 
> u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-plus.dtb 
> arch/arm/dts/sun50i-a64-pine64.dtb
>  
> -- 
> 2.18.0


signature.asc
Description: PGP signature

Bug#927242: linphone: Assistent does not save SIP account data

[Clemens Patschke]

Package: linphone
Version: 3.12.0-3
Severity: important

Dear Maintainer,

it is not possible to create a SIP account with assistent. After fill out the 
username, password, domain and proxy fields, the assistent does not create an 
account. 


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

Versions of packages linphone depends on:
ii  libatk1.0-0  2.30.0-2
ii  libbctoolbox10.6.0-2+b2
ii  libbelcard1  1.0.2-1
ii  libbellesip0 1.6.3-4
ii  libbzrtp01.0.6-3
ii  libc62.28-8
ii  libcairo21.16.0-4
ii  libgcc1  1:8.3.0-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libmediastreamer-base10  1:2.16.1-4+b1
ii  libmediastreamer-voip10  1:2.16.1-4+b1
ii  libnotify4   0.7.7-4
ii  libortp131:1.0.2-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libpangoxft-1.0-01.42.4-6
ii  libsqlite3-0 3.27.2-2
ii  libstdc++6   8.3.0-4
ii  libudev1 241-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  linphone-nogtk   3.12.0-3
ii  zlib1g   1:1.2.11.dfsg-1

linphone recommends no packages.

Versions of packages linphone suggests:
ii  yelp  3.31.90-1

-- no debconf information

Bug#927241: unblock: ruby-concurrent/1.0.5-3

[Antonio Terceiro]

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

Please unblock package ruby-concurrent

This fixes an autopkgtest failure (this is useful if we want to test
stable updates after buster is out). the change is trivial and has no
effect on the binaries produced.

8<8<8<-
diff --git a/debian/changelog b/debian/changelog
index bc70f4c..ee87263 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+ruby-concurrent (1.0.5-3) unstable; urgency=medium
+
+  * Team upload.
+  * debian/control: drop `Testsuite: autopkgtest-pkg-ruby` to let autopkgtest
+run only the explicit debian/tests/control in this package, and not also
+run the default test produced by autodep8 (Closes: #926782)
+
+ -- Antonio Terceiro   Mon, 15 Apr 2019 12:52:29 -0300
+
 ruby-concurrent (1.0.5-2) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index 5629f73..2f274b3 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,6 @@ Standards-Version: 4.0.0
 Vcs-Git: https://salsa.debian.org/ruby-team/ruby-concurrent.git
 Vcs-Browser: https://salsa.debian.org/ruby-team/ruby-concurrent
 Homepage: http://www.concurrent-ruby.com
-Testsuite: autopkgtest-pkg-ruby
 XS-Ruby-Versions: all
 
 Package: ruby-concurrent
8<8<8<-

unblock ruby-concurrent/1.0.5-3

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

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


signature.asc
Description: PGP signature

Bug#927240: gammu: --debug is broken

[Jakub Wilk]

Package: gammu
Version: 1.40.0-1

This command doesn't print any debugging information:

  gammu --debug textall identify

This sort-of works:

  gammu --debug-file log --debug textall identify

It creates the log file, but then it leaves in empty and prints the 
debugging information on stderr. Huh?



-- System Information:
Architecture: i386

Versions of packages gammu depends on:
ii  libbluetooth35.50-1
ii  libc62.28-8
ii  libcurl3-gnutls  7.64.0-2
ii  libgammu81.40.0-1
ii  libglib2.0-0 2.58.3-1
ii  libgudev-1.0-0   232-2

--
Jakub Wilk

Bug#922987: stretch-pu: package cernlib/20061220+dfsg3-4.3

[Gilles Filippini]

Adam D. Barratt a écrit le 14/04/2019 à 22:48 :
> Control: tags -1 + confirmed
> 
> On Fri, 2019-02-22 at 17:29 +0100, Gilles Filippini wrote:
>> Because RC bug #922453 affects Stretch as well, I propose a stable
>> update
>> for cernlib. Debdiff attached.
> 
> cernlib (20061220+dfsg3-4.3+deb9u1) stable-proposed-updates; urgency=medium
> 
> Please use "stretch" rather than "stable-proposed-updates" and go
> ahead.

Done.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

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

[Matthijs Kooijman]

Hi Adrian,

thanks for your extensive review. I'll respond inline.

> I might take a look into your notes to implement grub-efi + secure boot
> in hdd img but... this might be in 2021 XD . Too busy at the moment.
Familiar sentiment. Would be nice to have it, though.

> What's your use case? What do you need to build live-build based hdd
> imgs? I'm curious.
I'm using live-build to build Webconverger (a kiosk OS booting into a
full-screen browser) and an image derived for that for Bizplay (a
digital signage system).

We need hdd images rather than isohybrid images, so the resulting
USB-disk can be written to. This is needed firstly to update the
bootloader configuration to change the kernel commandline (we use this
to customize the image, e.g. change the default homepage shown).
Secondly, the image uses git to manage the root filesystem and a running
image can update itself, but that again needs a writable filesystem.


> > As predicted by others in this bug report, my work does not enable
> > secure boot (which syslinux simply does not support), nor enable
> > syslinux-efi support in iso/isohybrid images (since syslinux-efi does
> > not support this, or at least it apparently does not work).
> 
> Nice. What you need to make sure is that you cannot choose syslinux-efi
> when trying to build iso/isohybrid images.
Yeah, that's checked by the "Improve bootloader configuration checks"
commit.

> > 0) backward incompatible change
> In the pull request there is a mention about a backward incompatible
> change. Can you please describe in what that change consists?
I've added one commit with a NEWS file that describes this issue in a
bit more detail. Does that clarify sufficiently?

Note that while writing the NEWS entry, it seemed more confusing to have
a bootloaders/syslinux-common directory as well as a syslinux-common
Debian package, so I ended up modifying my commits to use
"syslinux-shared" rather than "syslinux-common" (I'll also use the
former below).

> > 1) Refactor some bootloader scripts (969cdf4e)
> 
> 1.1) Nice idea the Get_Bootloader_Config_Dir function.
> Have you made sure that $BOOTLOADER variable is not used anywhere else
> in the code?
> Maybe you should make that variable local.
Good point. I guess I was following the style of other functions (that
dod not use local variables either), but that's no reason not to do it
here. I updated the PR with this change.

> 1.2) The function Install_Bootloader_Files does not seem to be right.
> If you are not going to reuse that function in more than one place (I'll
> check your other commits later) you might consider not having that
> function in the first place.
I am indeed planning to reuse the function. I've clarified this in the
commit message.


> Even if the Install_Bootloader_Files function was a good idea it's not
> well implemented commit-wise. You are performing two changes. One about
> moving the functionality to a function. Another one is chaning the
> comment about "two steps" to "three steps". It's hard to notice if you
> changed something other than that comment on that commit.
>
> I mean... this part should be splitted in two commits.
I'm usually a nitpick in this area, but here I decided for a bit more
simplicity. You're right, though. I ended up splitting this into three
commits, one for Get_Bootloader_Config_Dir, one for
Install_Bootloader_Files and one for the comment.

> > 2) Reduce config duplication in syslinux variants (bccd127b)
> 
> I know it's better the way you merge files there but I think the
> original idea was about having independent configuration files for each
> different media.
> 
> I mean there were not meant to be merged together in the first place.
The reason to do this, is that I want configuration files to be shared
between syslinux and syslinux-efi (which can co-exist in the same
image). If these would be duplicated everywhere, modifying the
bootloader config after an image is written to disk requires modifying
it in two places.

Note that syslinux-efi could still not have its own config files, but
refer to files contained in bootloaders/syslinux (without the need for
bootloaders/syslinux-shared), but then you can never have an image that
*only* contains syslinux-efi (which you can with the syslinux-shared
approach, since then you use syslinux-shared for the config and
syslinux-efi for the efi images).

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

Bug#927239: pbcopper: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:pbcopper
Version: 0.4.1+dfsg-2
Severity: important
Tags: ftbfs patch

Dear maintainer:

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


[...]
 debian/rules build-arch
dh build-arch --builddirectory=build
   dh_update_autotools_config -a -O--builddirectory=build
   dh_autoreconf -a -O--builddirectory=build
   dh_auto_configure -a -O--builddirectory=build
cd build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
-- The CXX compiler identification is GNU 8.3.0
-- The C compiler identification is GNU 8.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done

[... snipped ...]

1: [ RUN  ] 
Data_RSReadName.constructed_from_name_parts_prints_expected_value_to_output_operator
1: [   OK ] 
Data_RSReadName.constructed_from_name_parts_prints_expected_value_to_output_operator
 (0 ms)
1: [ RUN  ] 
Data_RSReadName.constructed_from_ccs_name_parts_prints_expected_value_to_output_operator
1: [   OK ] 
Data_RSReadName.constructed_from_ccs_name_parts_prints_expected_value_to_output_operator
 (0 ms)
1: [ RUN  ] Data_RSReadName.constructed_properly_from_input_operator
1: [   OK ] Data_RSReadName.constructed_properly_from_input_operator (0 ms)
1: [ RUN  ] Data_RSReadName.ccs_constructed_properly_from_input_operator
1: [   OK ] Data_RSReadName.ccs_constructed_properly_from_input_operator (0 
ms)
1: [--] 11 tests from Data_RSReadName (0 ms total)
1: 
1: [--] 1 test from JSON_Json
1: [ RUN  ] JSON_Json.default_constructed_object_is_null
1: [   OK ] JSON_Json.default_constructed_object_is_null (0 ms)
1: [--] 1 test from JSON_Json (0 ms total)
1: 
1: [--] 2 tests from Logging_Logger
1: [ RUN  ] Logging_Logger.info_message_logged_to_stream
1: [   OK ] Logging_Logger.info_message_logged_to_stream (14 ms)
1: [ RUN  ] Logging_Logger.custom_logging_sinks_receive_expected_messages
1: [   OK ] Logging_Logger.custom_logging_sinks_receive_expected_messages 
(0 ms)
1: [--] 2 tests from Logging_Logger (14 ms total)
1: 
1: [--] 1 test from Parallel_WorkQueue
1: [ RUN  ] Parallel_WorkQueue.strings
1: [   OK ] Parallel_WorkQueue.strings (299 ms)
1: [--] 1 test from Parallel_WorkQueue (299 ms total)
1: 
1: [--] 11 tests from QGram_Index
1: [ RUN  ] QGram_Index.shape_throws_on_invalid_qgram_sizes
1: [   OK ] QGram_Index.shape_throws_on_invalid_qgram_sizes (0 ms)
1: [ RUN  ] QGram_Index.shape_hash_factors
1: [   OK ] QGram_Index.shape_hash_factors (0 ms)
1: [ RUN  ] QGram_Index.shape_hashing
1: [   OK ] QGram_Index.shape_hashing (0 ms)
1: [ RUN  ] QGram_Index.homopolymer_hasher
1: [   OK ] QGram_Index.homopolymer_hasher (0 ms)
1: [ RUN  ] QGram_Index.shape_hash_iteration
1: [   OK ] QGram_Index.shape_hash_iteration (0 ms)
1: [ RUN  ] QGram_Index.index_construct
1: [   OK ] QGram_Index.index_construct (0 ms)
1: [ RUN  ] QGram_Index.index_copy
1: [   OK ] QGram_Index.index_copy (0 ms)
1: [ RUN  ] QGram_Index.index_hits_INTERNAL_from_shape_short_seq
1: [   OK ] QGram_Index.index_hits_INTERNAL_from_shape_short_seq (0 ms)
1: [ RUN  ] QGram_Index.index_hits_INTERNAL_from_shape_longer_seq
1: [   OK ] QGram_Index.index_hits_INTERNAL_from_shape_longer_seq (0 ms)
1: [ RUN  ] QGram_Index.index_hits_PUBLIC_API_from_seq
1: [   OK ] QGram_Index.index_hits_PUBLIC_API_from_seq (0 ms)
1: [ RUN  ] 
QGram_Index.index_hits_PUBLIC_API_empty_hits_result_when_query_seq_is_too_short
1: [   OK ] 
QGram_Index.index_hits_PUBLIC_API_empty_hits_result_when_query_seq_is_too_short 
(0 ms)
1: [--] 11 tests from QGram_Index (4 ms total)
1: 
1: [--] 13 tests from Stream_Stream
1: [ RUN  ] Stream_Stream.input_to_console
1: [   OK ] Stream_Stream.input_to_console (0 ms)
1: [ RUN  ] Stream_Stream.char_input_to_all_caps
1: [   OK ] Stream_Stream.char_input_to_all_caps (0 ms)
1: [ RUN  ] Stream_Stream.stringlist_to_chars
1: [   OK ] Stream_Stream.stringlist_to_chars (0 ms)
1: [ RUN  ] Stream_Stream.char_input_split_into_words_and_printed_to_console
1: [   OK ] 
Stream_Stream.char_input_split_into_words_and_printed_to_console (0 ms)
1: [ RUN  ] Stream_Stream.newlined_input_printed_to_console
1: [   OK ] Stream_Stream.newlined_input_printed_to_console (0 ms)
1: [ RUN  ] Stream_Stream.composing_transform_chains
1: [   

Bug#926631:

[Eduard Bloch]

Hallo,
* Dan Rozinsky [Tue, Apr 16 2019, 09:59:41AM]:
>Hi all,
>We were able to overcome the problem,
>We had to configure UserAgent as suggested here:
>
> [1]https://stackoverflow.com/questions/55570531/apt-cacher-ng-403-forbidden-on-specific-package
>The question that we had in mine is why the apt-cacher-ng doesn't use this
>parser as default?

I am sorry, this does not make sense. What do you mean with "parser"?

This recommendation there only fakes the identity of your client to
disguise it as APT's http client. Which means that the remote server is
influenced by user-agent information. Why? Does the remote need to apply
some extra workarounds for a buggy client?

Regards,
Eduard.

Bug#927238: ITP: dte -- Small and easy to use console text editor

[Mirek Kratochvil]

Package: wnpp
Severity: wishlist
Owner: Mirek Kratochvil 

* Package name: dte
  Version : 1.7
  Upstream Author : Craig Barnes 
* URL : https://craigbarnes.gitlab.io/dte/
* License : GPL
  Programming Lang: C
  Description : Small and easy to use console text editor

dte is a very small console text editor that supports Unicode, multiple tabs
and buffers, syntax highlighting, regex search and replace, encodings, ctags
and various other features.

dte is extremely useful as a minimalistic but still fast, highly tweakable and
friendly system editor. Notably, installed size is smaller than of `nano'.

I will be looking for a sponsor for the package.

Bug#874191: Correction

[Patrick Grant]

On Thu, 4 Jan 2018 15:19:51 +0100 =?UTF-8?B?UmFtw7NuIEdhcmPDrWE=?= wrote:
> The fix was, edit /etc/selinux/[selinux 
config]/contexts/default_contexts.

> Copy the line for system_r:sshd_t and change it by sshd_t by init_t.
>
> pam_selinux can't find a correct context because there is no context
> available, coming from from init_t to the new user.

I have run into this and came to the same conclusion -- however when I 
make the change you describe it doesn't seem to be picked up. Is there a 
missing step beyond editing the file?

Bug#927237: coinor-cbc: Please update coinor-cbc to 2.10.1

[Thierry Moisan]

Package: coinor-cbc
Version: 2.8.12-1+b2
Severity: wishlist

Dear Maintainer,

coinor-cbc is outdated. This bug is here to track progress on updating
it and its dependencies.

Thanks !

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

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

Versions of packages coinor-cbc depends on:
ii  coinor-libcbc3   2.8.12-1+b2
ii  coinor-libcgl1   0.58.9-1+b1
ii  coinor-libclp1   1.15.10-3+b1
ii  coinor-libcoinutils3v5   2.9.15-4
ii  coinor-libosi1v5 0.106.9-2+b1
ii  libblas3 [libblas.so.3]  3.7.0-2
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-11+deb9u4
ii  libgcc1  1:6.3.0-18+deb9u1
ii  liblapack3 [liblapack.so.3]  3.7.0-2
ii  libstdc++6   6.3.0-18+deb9u1
ii  zlib1g   1:1.2.8.dfsg-5

coinor-cbc recommends no packages.

coinor-cbc suggests no packages.


 8,7   Top

Bug#927236: mkvtoolnix: please switch to nlohmann-json3

[Gianfranco Costamagna]

Package: mkvtoolnix
Version: 31.0.0-1
Severity: important
Tags: patch


Hello, as said, please switch to nlohmann-json3, it seems supported according 
to my build on DOM:
http://debomatic-amd64.debian.net/distribution#experimental/mkvtoolnix/31.0.0-1exp1/buildlog
trivial patch:

+mkvtoolnix (31.0.0-1exp1) experimental; urgency=medium
+
+  * Switch to nlohmann-json3 (Closes: #-1)
+
+ -- Gianfranco Costamagna   Tue, 16 Apr 2019 
19:13:57 +0200
+
 mkvtoolnix (31.0.0-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru mkvtoolnix-31.0.0/debian/control mkvtoolnix-31.0.0/debian/control
--- mkvtoolnix-31.0.0/debian/control2019-02-09 17:15:09.0 +0100
+++ mkvtoolnix-31.0.0/debian/control2019-04-16 19:13:56.0 +0200
@@ -9,7 +9,7 @@
  libogg-dev, libpcre3-dev, libvorbis-dev, ruby, liblzo2-dev, zlib1g-dev,
  libcurl4-gnutls-dev, pkg-config, libboost-date-time-dev, libpugixml-dev,
  qt5-default (>= 5.4~), libboost-filesystem1.67-dev, rake, po4a,
- nlohmann-json-dev, xsltproc, docbook-xsl, qtmultimedia5-dev, libfmt-dev,
+ nlohmann-json3-dev, xsltproc, docbook-xsl, qtmultimedia5-dev, libfmt-dev,
  libebml-dev (>= 1.3.5~), libcmark-dev (>= 0.28.3~)
 
 Package: mkvtoolnix

Bug#927235: bali-phy: please switch to nlohmann-json3

[Gianfranco Costamagna]

Package: bali-phy
Version: 3.4.1+dfsg-1
Severity: important
Tags: patch


Hello, as said, please switch to nlohmann-json3, it seems supported according 
to my build on DOM:
http://debomatic-amd64.debian.net/distribution#experimental/bali-phy/3.4.1+dfsg-1exp1/buildlog

trivial patch:

+bali-phy (3.4.1+dfsg-1exp1) experimental; urgency=medium
+
+  * Switch to nlohmann-json3 (Closes: -1)
+
+ -- Gianfranco Costamagna   Tue, 16 Apr 2019 
19:15:52 +0200
+
 bali-phy (3.4.1+dfsg-1) unstable; urgency=medium
 
   * New upstream version 3.4.1+dfsg
diff -Nru bali-phy-3.4.1+dfsg/debian/control bali-phy-3.4.1+dfsg/debian/control
--- bali-phy-3.4.1+dfsg/debian/control  2019-01-22 20:04:09.0 +0100
+++ bali-phy-3.4.1+dfsg/debian/control  2019-04-16 19:15:51.0 +0200
@@ -7,7 +7,7 @@
meson (>=0.45),
libcairo2-dev,
libeigen3-dev,
-   nlohmann-json-dev,
+   nlohmann-json3-dev,
pandoc,
libboost-dev,
libboost-program-options-dev,

Bug#927234: hobbit-plugins: Installs server-side plugins into wrong directory: /etc/xymon/xymonlaunch.d/ vs /etc/xymon/tasks.d/

[Axel Beckert]

Package: hobbit-plugins
Version: 20141006
Severity: important
Control: affects -1 + xymon
Control: found -1 20170219
Control: found -1 20190129

The commit
https://salsa.debian.org/debian/xymon/commit/3a46f42062b22ba31bfe9b629fad9173caa1ed1f
in xymon changed the path for server-side tasks and plugins from
/etc/xymon/xymonlaunch.d/ to /etc/xymon/tasks.d/, but hobbit-plugins
never followed that change.

Result: Since xymon/4.3.17-3 (in which this commit is included) and
hence since Debian 8 Jessie (which initially shipped with
xymon/4.3.17-6) none of the server-side plugins shipped with
hobbit-plugins was started if it was configured to be started. (By
default none of the server-side plugins is configured to be started.)

Acoording to upload dates, 20141006 should have been the first
hobbit-plugins version which should have had this fix.

(I partially have to blame myself, because I didn't manage to upgrade
one my production monitoring server from Debian 7 Wheezy to Debian 8
Jessie or later for quite a while. Unfortunately that was the only
server where I needed server-side plugins, mostly conn6, until very
recently when I discovered this issue on a freshly setup Xymon server
where I needed the conn6 plugin, too.)

Fixing this properly involves quite some effort with moving conffiles
around and possibly dealing with a very easy workaround:

# rmdir /etc/xymon/tasks.d
# ln -vis xymonlaunch.d /etc/xymon/tasks.d
# service xymon restart

So IMHO fixing this issue should cope with the following obvious
workarounds:

* /etc/xymon/tasks.d is a symlink to xymonlaunch.d, as suggested above.
  (the easy solution)

* /etc/xymon/xymonlaunch.d has been renamed to tasks.d and
  /etc/xymon/xymonlaunch.d is a symlink to tasks.d. (the more correct
  solution)

I don't think we should try fix this kind of breakage for Buster anymore
as this looks non-trivial to handle properly, and a very easy manual fix
is available for those few who need server-side plugins.

Bug#927233: XCA: Outdated, please provide newer XCA

[Thomas Ward]

Source: xca
Severity: wishlist

Hello.

The XCA package in the Repository is a little bit out of date, as we are
on 2.1.2 which was released in November 2018.

Can you please update the packages to 2.1.2 from upstream?


Thomas

Bug#926306: RFS: socklog/2.1.0-9

[Mathieu Mirmont]

On Fri, Apr 12, 2019 at 05:22:35PM +, Dmitry Bogatov wrote:
> [2019-04-10 23:48] Mathieu Mirmont 
> >
> > part 1 text/plain 434
> > On Wed, Apr 10, 2019 at 08:20:30AM +, Dmitry Bogatov wrote:
> > > You can repack it as new upstream version. New version would be
> > > something like `2.1.0+repack-1'. Do not forget add clarification into
> > > Debian.source.
> >
> > I've updated the package and uploaded to mentors:
> >
> > https://mentors.debian.net/package/socklog
> > https://mentors.debian.net/debian/pool/main/s/socklog/socklog_2.1.0+repack-1.dsc
> 
> Lintian (2.11.0) warnings:
> 
>   W: socklog: missing-versioned-depends-on-init-system-helpers 
> postinst:152 "update-rc.d defaults-disabled" needs i
>   nit-system-helpers >= 1.50
>   W: socklog: missing-versioned-depends-on-init-system-helpers 
> postinst:165 "update-rc.d defaults-disabled" needs i
>   nit-system-helpers >= 1.50
>   W: socklog: missing-versioned-depends-on-init-system-helpers 
> postinst:178 "update-rc.d defaults-disabled" needs i
>   nit-system-helpers >= 1.50
> 
> Oh, and extremely minor notice: in `debian/control' you align fields
> with tabs. It does not look pretty, if tabstop is not 8. What about
> expand(1)?

Both issues fixed, I re-uploaded the package to mentors (same links).

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#927221: gvfs-fuse version-specific depend on fuse (>= 2.8.4) blocks trans to fuse3

[Simon McVittie]

On Tue, 16 Apr 2019 at 09:22:53 -0500, Ron Lovell wrote:
> Building a modified package locally is something I certainly need to
> learn how to do, so I'll work on that. Then I know I can test fuse-
> exfat, the existing sshfs 2, and set up a Samba server.

For what it's worth, after patching gvfs-fuse to just have "Depends: fuse"
instead of "Depends: fuse (>= 2.8.4)", then removing fuse and installing
fuse3, it still seems to work here.

However, it isn't the only FUSE filesystem in this situation: I had to
remove archivemount before I could replace fuse with fuse3, and zfs-fuse
has the same problem.

So if fuse3 is meant to be usable as a drop-in replacement for fuse,
it might be better if the fuse3 maintainer (in Cc) changed fuse3 to have
Provides: fuse (= ${binary:Version}).

smcv

Bug#927154: aborts on window size change

[Antoine Beaupré]

On 2019-04-16 15:03:54, Paul Wise wrote:
> On Tue, 2019-04-16 at 00:26 -0400, Antoine Beaupré wrote:
>
>> Ouch? Any practical way to do that?
>
> I think a normal `git bisect` but running `git cherry-pick` before
> doing tests should work, untested though.
>
>> And how would i reliable backport that patch systematically within
>> bisect anyways?
>
> Looks like it applies fine with `git cherry-pick` after checking out
> 1.20160123 so I suspect it will work fine with all the intermediary
> commits anyway. To determine if the commit is included in the current
> commit during the bisect, you can just `git grep is_active` or ask git
> with the `git merge-base --is-ancestor 15e7a50 HEAD` exit code. If the
> commit is already included, don't run `git cherry-pick`.

Okay, so here's an interesting data point. On Debian stretch, I can't
reproduce the bug, even when running from git, using on current master
(1.20180726-30-g6cf8003).

So maybe something else is going on here, outside of myrepos itself...

I'll try to reproduce with the cherry-picking when I get back home on
that buster machine later.

A.
-- 
Sous un gouvernement qui emprisonne injustement, la place de l’homme
juste est aussi en prison.
- La désobéissance civile, Henry David Thoreau

Bug#927221: gvfs dep on fuse

[Simon McVittie]

On Tue, 16 Apr 2019 at 08:48:52 -0500, Ron Lovell wrote:
> I should have mentioned that I've sidestepped the whole topic of
> co-installability of pkgs fuse and fuse3. Despite closure of # 912528, on my
> Sid system fuse3 3.4.1-1 has an explicit "breaks" on pkg fuse.

Yes, and it has to. fuse and fuse3 both contain /sbin/mount.fuse,
/usr/bin/fusermount and /etc/fuse.conf. Two packages can't contain the
same file unless they declare Breaks/Replaces or Conflicts/Replaces
relationships.

smcv

Bug#927232: find -path does not complete

[積丹尼 Dan Jacobson]

Package: bash-completion
Version: 1:2.8-6
File: /usr/share/bash-completion/completions/find

$ find /tmp -path /tmp/ssh-dEu does not complete.

Bug#927231: ITS: pastebinit -- command-line pastebin client

[Simon Quigley]

Package: pastebinit
Severity: important
X-Debbugs-CC: f...@rolf.leggewie.biz, m...@qa.debian.org

Dear Maintainer,

I have noticed that no work has been done on pastebinit in the past
year; there are seven bugs open at the time of writing, not including
the one that is fixed in DELAYED.

I intend to salvage this package as laid forth in the Debian Developers
Reference[1]. If you disagree with this and either want to continue
maintaining this package or add me as a co-maintainer, please respond to
this bug before Tuesday, May 7, 2019, at which point I will upload a
package to DELAYED/7 making myself the maintainer (if you do not
respond). If you would like me to go ahead and just do it, please
respond as well.

Thank you for your work on this package!

[1]
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#ps-guidelines

-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#925546: How to reproduce?

[Joonas Kylmälä]

Hi,

you can reproduce the issue by creating a file main.go with the content:


package main

import (
"html/template"
"net/http"
)


and then running in the same directory:

$ gocode -f=json --in=main.go autocomplete 12

Then to see the error log first kill the running gocode server and run

$ nohup gocode -s debug &

The error will be printed then to nohup.out file when you run "gocode
-f=json --in=main.go autocomplete 12"

I remember reading somewhere on the online that this issue is caused
because the library dependencies are compiled with a different golang
version than this binary. So yeah, I have not yet tried but maybe this
is fixed by just uploading a new compilation of the binary.

Joonas

Hilko Bengen:
> control: tag -1 moreinfo
> 
> Hi Joonas,
> 
> could you describe in more detail how I might be able to reproduce the
> error? Does it happen with any file?
> 
> Cheers,
> -Hilko
> 

Bug#926952: sa-exim: Unbuildable/uninstallable in sid

[Andreas Metzler]

On 2019-04-15 Magnus Holmgren  wrote:
> måndag 15 april 2019 kl. 19:46:14 CEST skrev  Andreas Metzler:
[l...]
> > I have not tested it but I suspect it might break even more when
> > spool_wireformat is set.

> Isn't it the case that if CHUNKING has been offered AND spool_wireformat is 
> set, then the body files are in an alternate format?

Yes that is true.

[...]
> So it seems that everything should work unless spool_wireformat=true
> *and* SARewriteBody: 1. How do I detect in sa-exim whether wire format
> is used for a given body file though?

-spool_file_wireformat in the -H file?

I just do not think the reports of breakage where with
spool_wireformat=true, true though. - Nobody mentioned it and it is not
something one set accidentaly.

I have just uploaded exim 4.92-6 to exoerimental which /should/
work with sa-exim, allowing you to debug properly.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#927158: [Pkg-swan-devel] Bug#927158: strongswan-nm: charon-nm reports no usable smartcard found despite the smartcard working with charon as called by swanctl

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2019-04-16 at 09:15 -0400, robert.grizz...@quoininc.com wrote:
> >Configure the plugin's settings directly in
> > strongswan.conf in the charon-nm.plugins.pkcs11 section (or set them in
> > the libstrongswan section so they apply to both daemons).
> 
> Copying the pkcs11 configuration from /etc/strongswan.d/charon/pkcs11.conf to 
> the libstrongswan.plugins.pkcs11 section in strongswan.conf solved the 
> problem.

Thanks Tobias for providing the help.

Robert, since it doesn't seems to be a bug in strongSwan in the end, I'm
closing the bug.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAly2AvYACgkQ3rYcyPpX
RFsaygf8DhBrzeyPiXgsKt6oFjuUB46eeV7lChaM93jLTVubuSvbWMO9BQ+izHxG
rt2AFO3H0i+YpZAgO4rjWpeK5iaK6gCwxgMx36To4HRBNZ/k3pnUTW70m+VtNz5b
Hsme+4dqeccEIUNSZSsIy4vecFZS9eRUuklwIaDV0hJK1JzcqgGwgp9/vEzaXusE
J+SJli3e/nIKZg5KE0J0jn2++JNbcHKJy/3HR7JiUN9UvU34WmwnBFTBqok7zo4G
mCO2AoJSggBjxy0BNgDQHok6svgwLL73FhI48sejvX75xIDez8Ujcll50sP8N+sV
/HQjQfGZNkiYT78ghyJftnCxE0dOJQ==
=J2Ve
-END PGP SIGNATURE-

Bug#927219: xorg log

[Jonathan Carter]

Here is my my xorg log file on my AMD Radeon HD 8570D:

[18.183]
X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
[18.183] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[18.183] Current Operating System: Linux debian 4.19.0-4-amd64 #1
SMP Debian 4.19.28-2 (2019-03-15) x86_64
[18.183] Kernel command line:
BOOT_IMAGE=/live/vmlinuz-4.19.0-4-amd64 boot=live components splash
quiet findiso= nomodeset
[18.183] Build Date: 25 October 2018  06:15:23PM
[18.183] xorg-server 2:1.20.3-1 (https://www.debian.org/support)
[18.183] Current version of pixman: 0.36.0
[18.183]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[18.183] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[18.183] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Apr 16
16:10:58 2019
[18.184] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[18.184] (==) No Layout section.  Using the first Screen section.
[18.184] (==) No screen section available. Using defaults.
[18.184] (**) |-->Screen "Default Screen Section" (0)
[18.184] (**) |   |-->Monitor ""
[18.184] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[18.184] (==) Automatically adding devices
[18.184] (==) Automatically enabling devices
[18.184] (==) Automatically adding GPU devices
[18.184] (==) Max clients allowed: 256, resource mask: 0x1f
[18.184] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[18.184]Entry deleted from font path.
[18.184] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[18.184] (==) ModulePath set to "/usr/lib/xorg/modules"
[18.184] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[18.184] (II) Loader magic: 0x563c1cb76e20
[18.184] (II) Module ABI versions:
[18.184]X.Org ANSI C Emulation: 0.4
[18.184]X.Org Video Driver: 24.0
[18.184]X.Org XInput driver : 24.1
[18.184]X.Org Server Extension : 10.0
[18.185] (++) using VT number 7

[18.185] (II) systemd-logind: logind integration requires -keeptty
and -keeptty was not provided, disabling logind integration
[18.188] (--) PCI:*(0@0:1:0) 1002:990e:1462:7721 rev 0, Mem @
0xc000/268435456, 0xfeb0/262144, I/O @ 0xf000/256, BIOS @
0x/131072
[18.188] (II) LoadModule: "glx"
[18.189] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[18.190] (II) Module glx: vendor="X.Org Foundation"
[18.190]compiled for 1.20.3, module version = 1.0.0
[18.190]ABI class: X.Org Server Extension, version 10.0
[18.190] (==) Matched ati as autoconfigured driver 0
[18.190] (==) Matched modesetting as autoconfigured driver 1
[18.190] (==) Matched fbdev as autoconfigured driver 2
[18.190] (==) Matched vesa as autoconfigured driver 3
[18.190] (==) Assigned the driver to the xf86ConfigLayout
[18.190] (II) LoadModule: "ati"
[18.190] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[18.191] (II) Module ati: vendor="X.Org Foundation"
[18.191]compiled for 1.20.3, module version = 18.1.99
[18.191]Module class: X.Org Video Driver
[18.191]ABI class: X.Org Video Driver, version 24.0
[18.257] (II) LoadModule: "radeon"
[18.257] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[18.258] (II) Module radeon: vendor="X.Org Foundation"
[18.258]compiled for 1.20.3, module version = 18.1.99
[18.258]Module class: X.Org Video Driver
[18.258]ABI class: X.Org Video Driver, version 24.0
[18.258] (II) LoadModule: "modesetting"
[18.258] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[18.258] (II) Module modesetting: vendor="X.Org Foundation"
[18.258]compiled for 1.20.3, module version = 1.20.3
[18.258]Module class: X.Org Video Driver
[18.258]ABI class: X.Org Video Driver, version 24.0
[18.258] (II) LoadModule: "fbdev"
[18.258] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[18.258] (II) Module fbdev: vendor="X.Org Foundation"
[18.258]compiled for 1.20.0, module version = 0.5.0
[18.258]Module class: X.Org Video Driver
[18.258]ABI class: X.Org Video Driver, version 24.0
[18.258] (II) LoadModule: "vesa"
[18.258] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[18.258] (II) Module vesa: vendor="X.Org Foundation"
[

Bug#925546: How to reproduce?

[Hilko Bengen]

control: tag -1 moreinfo

Hi Joonas,

could you describe in more detail how I might be able to reproduce the
error? Does it happen with any file?

Cheers,
-Hilko

Bug#921952: [Pkg-sass-devel] Bug#921952: Don't include in buster without proper commitment to update in stable

[Jonas Smedegaard]

control: severity -1 important

Quoting Aljoscha Lautenbach (2019-04-09 23:03:06)
> during the BSP in Gothenburg last weekend I discussed with Jonas how I 
> could help to put libsass back on track regarding its security status. 
> We agreed that the best move is to start with triaging the existing 
> Debian bugs and by identifying the CVE status in upstream's issue 
> tracker. [0]

@Aljoscha: Thanks for your initial work and - more so - for committing 
to help generally looking after these security issues in libsaass.

Due to the expansion of the libsass team with Aljoscha, I am lowering 
severity of this bugreport.

If the security team or others disagree, then please elaborate what you 
consider is needed.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#921952: [Pkg-sass-devel] Bug#921952: Don't include in buster without proper commitment to update in stable

[Jonas Smedegaard]

Quoting Xavier (2019-04-16 15:52:53)
> Hi all,
> 
> Some fixes proposed in
> https://salsa.debian.org/sass-team/libsass/merge_requests/1 :
> CVE-2018-19827, CVE-2019-6283, CVE-2019-6284 and CVE-2019-6286

Thanks for your help, Xavier.

This bugreport is however not to track specific bugs in libsass but to 
track the meta-issue of the general "health" of the maintenance.

Therefore, it is more helpful if you post concrete bugfixes not here but 
at bugreports for the concrete bugs (i.e. locate existing bugreports or 
file new bugreports for CVEs without a bugreport in Debian yet).

If you are interested in stepping up to help generally maintain libsass, 
then that wold be great - and we can talk about that in this bugreport.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#921600: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Ritesh Raj Sarraf]

Package: docker.io
Version: 18.09.1+dfsg1-5+b10
Followup-For: Bug #921600

Bugs like these are very very disappointing. Our users are going to be
left out scratching heads and pulling hairs.

I'm not sure who to vent out the frustration on. docker has its own
iptables setup, the legacy one. So, for docker, they'd simply recommend
to stick to it.

iptables, by itself, has switched to the new nftables. And thus has
Debian. And thus has users like us, who migrated to the new setup. So,
here the recommendation would be to stick with nftables.

Mix and match of legacy and current nft tables are highly discouraged in
the kernel.

I think the best bare minimal recommended solution is to have an
external interface (without the Docker networking bling) and tell docker
just to use it as its path.

In my case, my custom bridge (sysbr0), is the interface to which
everyone has to talk to: VBox, Libvirt, nspawn and now docker. That way
I can consolidate policies, fixes and what not at just a single
location.

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

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

Versions of packages docker.io depends on:
ii  adduser 3.118
ii  iptables1.8.2-4
ii  libc6   2.28-8
ii  libdevmapper1.02.1  2:1.02.155-2
ii  libltdl72.4.6-9
ii  libnspr42:4.20-1
ii  libnss3 2:3.42.1-1
ii  libseccomp2 2.3.3-4
ii  libsystemd0 241-3
ii  lsb-base10.2019031300
ii  runc1.0.0~rc6+dfsg1-3
ii  tini0.18.0-1

Versions of packages docker.io recommends:
ii  ca-certificates  20190110
ii  cgroupfs-mount   1.4
ii  git  1:2.20.1-2
ii  needrestart  3.4-1
ii  xz-utils 5.2.4-1

Versions of packages docker.io suggests:
pn  aufs-tools   
ii  btrfs-progs  4.20.1-2
ii  debootstrap  1.0.114
ii  docker-doc   18.09.1+dfsg1-5
ii  e2fsprogs1.44.5-1
pn  rinse
ii  xfsprogs 4.20.0-1
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#923980: claws-mail-gdata-plugin: gdata plugin crashes after update to 3.17.3-1

[Ricardo Mones]

control: reopen -1
control: notfixed -1 claws-mail/3.17.3-2
control: tags -1 help

Hi Christian,

On Wed, Apr 10, 2019 at 06:31:49PM +0200, Christian Beier wrote:
> 
> Hi Ricardo,
> 
> I just upgraded to 3.17.3-2, but unfortunately still get the segfault:
[…]
> I checked with 3.17.3-2's source package and there is a de.gmo file in
> there which still contains the %s. Might this be the reason?

Yes, the added patch fixes the source file, but does not fix the
binaries already there, which come from upstream.

I hadn't time to do much tests, just tried to remove the gmo files from
master and rebuild, but the result is still the same.

The only idea left is to repackage upstream tarball, but since that's an
idea I don't like much I'm Cc-ing the release list for advice on how to
deal with this (thanks in advance! :)

best regards,
-- 
  Ricardo Mones 
  ~
  Absence of evidence is not evidence of absence.  Carl Sagan



signature.asc
Description: PGP signature

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

[Matthijs Kooijman]

Hey Thierry,

> Is there a chance that this work will be part of buster live-build
> package, or is it too late already ?
I'm not the maintainer of live-build, but given the freeze state that
buster is in, I highly doubt this will make it into buster.

Gr.

Matthijs


signature.asc
Description: PGP signature

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

[Matthijs Kooijman]

Hey Adrian,

[ About removing --templates from the manpage ]
> In that case IMO that commit should be in its own pull request and not
> the current one.
Done: https://salsa.debian.org/live-team/live-build/merge_requests/21

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#927221: gvfs-fuse version-specific depend on fuse (>= 2.8.4) blocks trans to fuse3

[Ron Lovell]

On Tue, 16 Apr 2019 14:24:21 +0100 Simon McVittie 
wrote:

> Does fuse3 provide everything that's needed to mount and unmount
older
> FUSE filesystems that are still linked to libfuse2, like gvfs-fuse?
> 
> If it does, then gvfs-fuse can depend on fuse (>= 2.8.4) | fuse3, or
> just depend on plain "fuse" which is provided by fuse3 (since 2.8.4
is

Hello, Simon,

Thanks for your quick reply. Clearly I've been focused on library deps
only and didn't understand the importance of the utility commands. Let
me dig down and understand this better. BTW, I posted the message #15
about co-installability of fuse and fuse3 before I saw your message.
Did #912528 only solve part of the problem? There appears to be a
disconnect between the Bugs database and reality.

Building a modified package locally is something I certainly need to
learn how to do, so I'll work on that. Then I know I can test fuse-
exfat, the existing sshfs 2, and set up a Samba server.

Thanks for your very informative replay.
Best regards,
Ron