Bug#894662: vlc: nvlc does not play youtube videos after update to v3.0.1-3, vlc and cvlc play the same url normally

[Elizabeth Bodaneze]

Update: also happens when trying to play .cue and .m3u files, again while rvlc, 
cvlc, etc, play the same files normally; the log is interrupted after killing 
nvlc with "killall -2 vlc", which takes several tries, and after which the 
terminal emulator has to be reset to work properly, since the cursor disappears.


-- logger module started --
main debug: VLC media player - 3.0.1 Vetinari
main debug: Copyright © 1996-2018 the VideoLAN team
main debug: revision 3.0.1-0-gec0f700fcc
main debug: configured with ./configure  '--build=x86_64-linux-gnu' 
'--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' 
'--disable-maintainer-mode' '--disable-dependency-tracking' '--config-cache' 
'--disable-update-check' '--enable-fast-install' '--docdir=/usr/share/doc/vlc' 
'--with-binary-version=3.0.1-3' '--enable-a52' '--enable-aa' '--enable-aribsub' 
'--enable-bluray' '--enable-avahi' '--enable-caca' '--enable-chromaprint' 
'--enable-chromecast' '--enable-dbus' '--enable-dca' '--enable-dvbpsi' 
'--enable-dvdnav' '--enable-faad' '--enable-flac' '--enable-fluidsynth' 
'--enable-freetype' '--enable-fribidi' '--enable-gles2' '--enable-gnutls' 
'--enable-harfbuzz' '--enable-jack' '--enable-kate' '--enable-libass' 
'--enable-libmpeg2' '--enable-libxml2' '--enable-lirc' '--enable-live555' 
'--enable-mad' '--enable-matroska' '--enable-mod' '--enable-mpc' 
'--enable-mpg123' '--enable-mtp' '--enable-ncurses' '--enable-notify' 
'--enable-ogg' '--enable-opus' '--enable-pulse' '--enable-qt' 
'--enable-realrtsp' '--enable-samplerate' '--enable-sdl-image' '--enable-sftp' 
'--enable-shine' '--enable-shout' '--enable-skins2' '--enable-sndio' 
'--enable-soxr' '--enable-speex' '--enable-svg' '--enable-svgdec' 
'--enable-taglib' '--enable-theora' '--enable-twolame' '--enable-upnp' 
'--enable-vdpau' '--enable-vnc' '--enable-vorbis' '--enable-x264' 
'--enable-x265' '--enable-zvbi' '--with-kde-solid=/usr/share/solid/actions/' 
'--disable-d3d11va' '--disable-decklink' '--disable-directx' '--disable-dsm' 
'--disable-dxva2' '--disable-fdkaac' '--disable-fluidlite' '--disable-freerdp' 
'--disable-goom' '--disable-gst-decode' '--disable-libtar' '--disable-macosx' 
'--disable-macosx-avfoundation' '--disable-macosx-qtkit' '--disable-mfx' 
'--disable-opencv' '--disable-projectm' '--disable-schroedinger' 
'--disable-sparkle' '--disable-srt' '--disable-telx' '--disable-vpx' 
'--disable-vsxu' '--disable-wasapi' '--enable-alsa' '--enable-dc1394' 
'--enable-dv1394' '--enable-libplacebo' '--enable-linsys' '--enable-nfs' 
'--enable-omxil' '--enable-udev' '--enable-v4l2' '--enable-wayland' 
'--enable-libva' '--enable-vcd' '--enable-smbclient' '--disable-oss' 
'--enable-crystalhd' '--enable-mmx' '--enable-sse' '--disable-neon' 
'--disable-altivec' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/vlc-4oVPq9/vlc-3.0.1=. -fstack-protector-strong 
-Wformat -Werror=format-security ' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now 
-Wl,--as-needed' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 
-fdebug-prefix-map=/build/vlc-4oVPq9/vlc-3.0.1=. -fstack-protector-strong 
-Wformat -Werror=format-security ' 'OBJCFLAGS=-g -O2 
-fdebug-prefix-map=/build/vlc-4oVPq9/vlc-3.0.1=. -fstack-protector-strong 
-Wformat -Werror=format-security'
main debug: searching plug-in modules
main debug: loading plugins cache file 
/usr/lib/x86_64-linux-gnu/vlc/plugins/plugins.dat
main debug: recursively browsing `/usr/lib/x86_64-linux-gnu/vlc/plugins'
main debug: plug-ins loaded: 518 modules
main debug: opening config file (/home/liz/.config/vlc/vlcrc)
main debug: looking for logger module matching "any": 4 candidates
file debug: opening logfile `/tmp/vlc_log'
main debug: using logger module "file"
main debug: translation test: code is "C"
main debug: looking for keystore module matching "memory": 4 candidates
main debug: using keystore module "memory"
main debug: CPU has capabilities MMX MMXEXT SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 
FPU
main debug: Creating an input for 'Media Library'
main debug: Input is a meta file: disabling unneeded options
main debug: using timeshift granularity of 50 MiB
main debug: using default timeshift path
main debug: `file/directory:///home/liz/.local/share/vlc/ml.xspf' gives access 
`file' demux `directory' path `/home/liz/.local/share/vlc/ml.xspf'
main debug: creating demux: access='file' demux='directory' 
location='/home/liz/.local/share/vlc/ml.xspf' 
file='/home/liz/.local/share/vlc/ml.xspf'
main debug: looking for access_demux module matching "file": 17 candidates
main debug: no access_demux modules matched
main debug: creating access: file:///home/liz/.local/share/vlc/ml.xspf
main debug:  (path: /home/liz/.local/share/vlc/ml.xspf)
main debug: looking for access module matching "file": 28 candidates

Bug#876675: snapper: Avoid filling up btrfs, as it break the system?

[Sunil Mohan Adapa]

severity 876675 important
tags 876675 + patch
thanks

The biggest reason why snapper fills up disk with snapshots is because
the number algorithm does not cleanup automatically.  When apt snapshots
are taken by this package's apt hooks, number algorithm is used.
However, unlike timeline algorithms that are periodically cleaned up by
snapperd, numeric snapshots are not (even after saying number cleanup to
'yes'). Even after configuring snapperd to keep very few apt snapshots,
this still fills up the disk eventually.

The solution to this part is to trigger a number cleanup after every
snapshot. The fix is available as part of patch in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880144 . Hence, adding
patch tag. Please consider accepting the simple patch to fix both bugs.

Bumping priority as this as it effects all FreedomBox machines that use
snapper.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#894666: [debhelper-devel] Bug#894666: Simplify backports - manpage should suggest >=11~ not >=11

[Niels Thykier]

Trent W. Buck:
> Mattia Rizzolo wrote:
>> On Tue, Apr 03, 2018 at 02:30:02PM +1000, Trent W. Buck wrote:
>>> When backporting libpam-mount from experimental to stable, the only change 
>>> I needed was
>>>
>>> -Build-Depends: debhelper (>= 11), …
>>> +Build-Depends: debhelper (>= 11~), …
>>>
>>> The tilde allows ~bpo versions of debhelper to satisfy the constraint.
>>>
>>> The debhelper(5) manpage suggestion has no tilde.
>>> Can it have a tilde?
>>
>> There is going to be no need in a few days once debhelper 11.1.6 will
>> finally be backported (it couldn't be done before).
> 
> Won't a similar problem happen if debhelper 12 ships around the time buster 
> becomes stable, and so on?
> 
> I have vague memories of this biting me back when wheezy was stable, but 
> maybe I misremember.
> 
> If you're confident this situation is rare enough to be ignorable, I'll defer 
> to you :-)
> 
> [...]
> 

Depends on whether this alternative method for selecting compat levels
turns out to work:
https://nthykier.wordpress.com/2018/03/04/prototyping-a-new-packaging-papercut-fix-dry-debhelper-compat-level/

That said, adding a ~ in the manpage is a trivial matter and I will
probably do that regardless.

Thanks,
~Niels

Bug#894696: ITP: nagios4 -- A host/service/network monitoring and management system

[Sebastiaan Couwenberg]

On 04/04/2018 12:56 AM, Russell Stuart wrote:
> On Tue, 2018-04-03 at 13:51 +0200, Bas Couwenberg wrote:
>> My point is that you maintain the package within the team, not that 
>> other members in the team maintain the package instead.
> 
> Firstly I prefer to work on my own.

Then you shouldn't be part of any team, indeed.

Kind Regards,

Bas

Bug#894772: RFS: deepin-system-monitor/1.4.3-1 [ITP]

[Yanhao Mo]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "deepin-system-monitor"

* Package name: deepin-system-monitor
  Version : 1.4.3-1
  Upstream Author : Deepin Technology Co., Ltd
* URL : https://github.com/linuxdeepin/deepin-system-monitor
* License : GPL-3+
  Section : utils

It builds those binary packages:

  deepin-system-monitor - System monitor for Deepin Desktop Environment

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

  https://mentors.debian.net/package/deepin-system-monitor

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/deepin-system-monitor/deepin-system-monitor_1.4.3-1.dsc

More information about hello can be obtained from 
https://salsa.debian.org/pkg-deepin-team/deepin-system-monitor

Changes since the last upload:

 * Initial release.
 * Add a patch to prevent /usr/share/dman/* from being installed, more
   info can be found at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883379#33
   and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883379#45

-- 
Yanhao Mo


signature.asc
Description: PGP signature

Bug#894724: ncmpc: Crash in chat screen when another client sends a long line

[Salvatore Bonaccorso]

Control: retitle -1 ncmpc: CVE-2018-9240: Crash in chat screen when another 
client sends a long line

Hi Jonathan,

On Tue, Apr 03, 2018 at 04:48:23PM +0200, Jonathan Neusch??fer wrote:
> I tagged this report as "security"-related, because the client can be
> crashed by the actions of another client, but I don't think this allows
> anything more serious than a NULL pointer derefence (probably no RCE).

MITRE has assigned CVE-2018-9240 for this issue.

Regards,
Salvatore

Bug#871993: fail2ban.system PartOf is broken causing firewalld to fail

[Yaroslav Halchenko]

On Wed, 04 Apr 2018, Sunil Mohan Adapa wrote:

> Every system that is using firewalld and fail2ban fails upgrading from
> stable to testing (or next stable eventually) because this issue.

> Please consider releasing a fix with priority by taking Fedora's
> workaround in the posted patch.

thanks for the reminder, on it now

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#894771: python3-testtools: Missing runtime dependency on python3-distutils

[Free Ekanayaka]

Source: python-testtools
Version: 2.3.0-3
Severity: important

I get an import error on debian/unstable when trying to import the
testtools package:

free@debian:~$ python3 -c "import testtools"
python3 -c "import testtools"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/testtools/__init__.py", line 113, in 

from testtools.distutilscmd import (
  File "/usr/lib/python3/dist-packages/testtools/distutilscmd.py", line 7, in 

from distutils.core import Command
ModuleNotFoundError: No module named 'distutils.core'

Installing python3-distutils fixes the issue.

Bug#894050: Reopening

[Bill Blough]

While this is fixed for unstable/testing, the security team has informed
me that there will be no DSA for this issue for stable/oldstable.

As such, I'm reopening this until stable/oldstable can be updated via a
point release.

Bug#894770: arduino: serial communication/uploader not working

[kie]

Package: arduino
Version: 2:1.0.5+dfsg2-4.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

normal use of arduino program
however at the moment the serial connection selection is greyed out

connect to arduino via serial port not working, cannot upload code to arduino

get the following error
java.lang.NullPointerException thrown while loading gnu.io.RXTXCommDriver

this is the same on two different machines running buster
where serial upload was previously working without a problem

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

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

Versions of packages arduino depends on:
ii  arduino-core   2:1.0.5+dfsg2-4.1
ii  default-jre [java6-runtime]2:1.9-62
ii  libjna-java4.5.1-1
ii  librxtx-java   2.2pre2+dfsg1-1
ii  openjdk-8-jre [java6-runtime]  8u162-b12-1
ii  openjdk-9-jre [java6-runtime]  9.0.4+12-3

Versions of packages arduino recommends:
ii  extra-xdg-menus  1.0-4
ii  policykit-1  0.105-20

arduino suggests no packages.

-- no debconf information


- End forwarded message -

Bug#871993: fail2ban.system PartOf is broken causing firewalld to fail

[Sunil Mohan Adapa]

Every system that is using firewalld and fail2ban fails upgrading from
stable to testing (or next stable eventually) because this issue.

Please consider releasing a fix with priority by taking Fedora's
workaround in the posted patch.

Thanks,

-- 
Sunil

Bug#894011: Pending fixes for bugs in the java-common package

[pkg-java-maintainers]

tag 894011 + pending
thanks

Some bugs in the java-common package are closed in revision
9c88efb17a04da62f77e9fb328c8fa92e8196572 in branch 'master' by tony
mancill

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/java-common.git/commit/?id=9c88efb

Commit message:

Move ia64 from Java 5 to Java 9 architectures (Closes: #894011)

Bug#894769: arduino: serial communication/uploader not working

[kie]

Package: arduino
Version: 2:1.0.5+dfsg2-4.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

normal use of arduino program
however at the moment the serial connection selection is greyed out

connect to arduino via serial port not working, cannot upload code to arduino

get the following error
java.lang.NullPointerException thrown while loading gnu.io.RXTXCommDriver

this is the same on two different machines running buster
where serial upload was previously working without a problem

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

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

Versions of packages arduino depends on:
ii  arduino-core   2:1.0.5+dfsg2-4.1
ii  default-jre [java6-runtime]2:1.9-62
ii  libjna-java4.5.1-1
ii  librxtx-java   2.2pre2+dfsg1-1
ii  openjdk-8-jre [java6-runtime]  8u162-b12-1
ii  openjdk-9-jre [java6-runtime]  9.0.4+12-3

Versions of packages arduino recommends:
ii  extra-xdg-menus  1.0-4
ii  policykit-1  0.105-20

arduino suggests no packages.

-- no debconf information

Bug#807862: Same issue here

[Josh Triplett]

I ran into the same issue:

/tmp/blog.rust-lang.org$ git hub pull new
Pushing nonnull-size to nonnull-size in fork
Creating pull request from branch nonnull-size to 
rust-lang/blog.rust-lang.org:master
Error: GitHub error: Validation Failed
Error: HTTP Error 422: Unprocessable Entity
Error: https://api.github.com/repos/rust-lang/blog.rust-lang.org/pulls
Error: 
Error: {"message":"Validation 
Failed","errors":[{"resource":"PullRequest","field":"base","code":"invalid"}],"documentation_url":"https://developer.github.com/v3/pulls/#create-a-pull-request"}

The mention of needing to specify the branch helped, because it turned
out I needed to create the pull request against the gh-pages branch. It
would definitely have helped if the error message explained that the
"master" branch didn't exist.

Bug#858294: Unreproducible, moreinfo needed

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 29 de marzo de 2018 14:07:02 -03 Vladimir Berezenko escribió:
> > Hi! I definitely can't reproduce this bug. Can you still reproduce it?
> > Which Qt version are you currently using?
> 
> This is definitely reproducible. The current Qt5 version is 5.9.2-2 on my
> quad G5, and 5.8.4 on G4 powerbook. Both machines are not reacting on
> mousewheel events at all. I've tried KDE, LXQt. GTK2/3 apps are not
> affected at all.

Well, this is totally strange, as the only report we have heard so far is from 
you.

I understand that you tried on two machines. Just to be clear: have you tried 
with a new user?

There is the chance that you might have configured something in the same way 
in both machines. If you still can reproduce this bug with a new user then we 
can file a bug upstream.

Actually you should do it yourself, as I don't have any ways of reproducing 
this bug. Please file the upstream bug at https://bugreports.qt.io and then 
please send the bug number here. I'll happily subscribe to the bug to follow 
it and, if possible at all, help.

Thanks, Lisandro.

-- 
“If you want to finish university, you should take care about getting on
with the teachers. The result are submissive citizens that won’t face
authority even if they know they’re right, in order to avoid problems“
  Miriam Ruiz, http://www.miriamruiz.es/weblog/?p=187

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


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

Bug#894768: project: in debian 9, using mate, had crashes during the execution of videos in vlc. I have a core2duo

[Maximiliano Bevilaqua Esper]

Package: project
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

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

Bug#894767: Please package version 1.3.0

[Matti Palmström]

Package: python3-logbook
Version: 0.12.3-1
Severity: wishlist

Please package version 1.3.0, the version in Debian is getting a bit old.

Bug#844432: fixed in python-click 6.7-3.1

[Alexandre Viau]

Hello!

It looks like you have nmu-ed python-click.

Did you send me the patch anywhere? Maybe I missed it?

Cheers,

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



signature.asc
Description: OpenPGP digital signature

Bug#894666: Simplify backports - manpage should suggest >=11~ not >=11

[Trent W. Buck]

Mattia Rizzolo wrote:
> On Tue, Apr 03, 2018 at 02:30:02PM +1000, Trent W. Buck wrote:
> > When backporting libpam-mount from experimental to stable, the only change 
> > I needed was
> > 
> > -Build-Depends: debhelper (>= 11), …
> > +Build-Depends: debhelper (>= 11~), …
> > 
> > The tilde allows ~bpo versions of debhelper to satisfy the constraint.
> > 
> > The debhelper(5) manpage suggestion has no tilde.
> > Can it have a tilde?
> 
> There is going to be no need in a few days once debhelper 11.1.6 will
> finally be backported (it couldn't be done before).

Won't a similar problem happen if debhelper 12 ships around the time buster 
becomes stable, and so on?

I have vague memories of this biting me back when wheezy was stable, but maybe 
I misremember.

If you're confident this situation is rare enough to be ignorable, I'll defer 
to you :-)

Bug#894758: maildir-utils: Incomplete debian/copyright?

[Norbert Preining]

tag 894758 + moreinfo
thanks

> I just ACCEPTed maildir-utils from NEW but noticed it was missing 

Thanks.

> attribution/licenses in debian/copyright for at least some of the
> utilities under lib (eg. mu-flags.c) and perhaps some of the tests

Hmm, I am not completely convinced what you mean. in mu-flags.c the
*name* is missing:
  Copyright (C) 2011-2012  
while in most other files the author's name is there:
  Copyright (C) 2010-2013 Dirk-Jan C. Binnema 
But I consider this a plain oversight.

Do you want me to add
* all the different years for each file?
* add extra lines for those where the name is missing?
* both of the above?

I really don't see a *missing* licence statement, all of them are
copyright by djcb, as clearly stated in d/copyright.

Please explain what you expect.

Thanks

Norbert

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

Bug#894711: RFS: qtmpris/0.0.8-1 [ITP]

[Yanhao Mo]

On Tue 04/03 22:43, Adam Borowski wrote:
> On Tue, Apr 03, 2018 at 08:25:32PM +0800, Yanhao Mo wrote:
> > Package: sponsorship-requests
> > Severity: wishlist
> > 
> >  * Package name: qtmpris
> >Version : 0.0.801
> >Upstream Author : Andres Gomez 
> >  * URL : https://github.com/nemomobile/qtmpris
> >  * License : GPL-2.1+
> >Section : misc
> > 
> > It builds those binary packages:
> > 
> >   libmpris-qt5-1 - Qt MPRIS interface and adaptor (development files)
> >   libmpris-qt5-dev - Qt MPRIS interface and adaptor
> >   qml-module-org-nemomobile-mpris - Qt 5 MPRIS interface and adaptor QML 
> > module
> 
> Hi!
> The license of all files is LGPL 2+ rather than GPL; the difference is
> important as LGPL allows using this library without imposing GPL on the
> resultant binary.
> 
> As of packaging itself, it looks good so far otherwise.

Sorry for my carelessness. I have fixed it and re-uploaded.

-- 
Yanhao Mo


signature.asc
Description: PGP signature

Bug#894740: acpi-call-dkms: Bad return status for module build on kernel: 4.14.0-0.bpo.2-amd64

[Raphaël Halimi]

Le 04/04/2018 à 01:26, Lorenzo Ancora a écrit :
> I was not able to find bug #868110 in reportbug:
> As you can see the list is blank, except for this and another bug
> report. Probably due to the version mismatch.
> Next time I will make the archaeologist directly on the website,
> ignoring the official app. :-)

Hi Lorenzo,

Sorry if I've been a bit harsh. I rarely use reportbug, I do prefer
relying on the good old BTS, with its web and mail interfaces. I didn't
even know that there was no way in reportbug to search for closed and/or
archived bugs.

Also, similarly to what you did, I received half a dozen reports from
Launchpad for the very same bug around the time the HWE kernel (which is
some kind of backport if I understand correctly) hit Xenial, whereas the
fix was already available in Artful. I hate that both BTSs default to
hide closed bugs, but on the other hand, bugs are supposed to be
reported against unstable, not stable. Kernel modules are peculiar in
this regard, because people often need to run backported kernels due to
hardware support needs.

>> [...] a backport for Stretch is available since August 28th, 2017.
> We are in 2018 and it dates back to 8 months ago. Why is not part of
> Stable after so much time?
> Good to know there is a quick solution. :-)

Simple, that's because the mainline kernel in Stretch is still 4.9, and
1.1.0-3 does compile correctly with it. If you use a backported kernel,
you should also use backported versions of many packages needed by the
kernel, among them are the kernel modules like acpi-call.

> Thank you, the experimental version compiles correctly.

Backports and experimental are two totally different things in Debian ;)

Regards,

-- 
Raphaël Halimi

Bug#894766: Make a build without kwallet support

[Matti Palmström]

Package: falkon

Version: 3.0.0-3

Severity: wishlist

Can you please put the support for kwallet in a package of it own as
you did earlier with qupzilla?

Bug#894765: Prompt for password for encrypted PDFs

[martin f krafft]

Package: pdfmod
Version: 0.9.1-8
Severity: wishlist

Please prompt for a password required to open encrypted PDFs, and
decrypt them for modification.

Thanks,

-- 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.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pdfmod depends on:
ii  libc6  2.27-2
ii  libcairo2  1.15.10-2
ii  libgconf2.0-cil2.24.2-4
ii  libglib2.0-0   2.56.0-4
ii  libglib2.0-cil 2.12.40-2
ii  libgtk2.0-02.24.32-1
ii  libgtk2.0-cil  2.12.40-2
ii  libmono-cairo4.0-cil   4.6.2.7+dfsg-1
ii  libmono-corlib4.5-cil  4.6.2.7+dfsg-1
ii  libmono-i18n-west4.0-cil   4.6.2.7+dfsg-1
ii  libmono-posix4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil 4.6.2.7+dfsg-1
ii  libmono-system-drawing4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system4.0-cil  4.6.2.7+dfsg-1
ii  libpangocairo-1.0-01.40.14-1
ii  libpoppler-glib8   0.62.0-2
ii  mono-runtime   4.6.2.7+dfsg-1

pdfmod recommends no packages.

pdfmod suggests no packages.

-- debconf-show failed


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#894764: Please prompt for password on import of encrypted file

[martin f krafft]

Package: gscan2pdf
Version: 1.8.11-1
Severity: wishlist

If I --import a file with PDF encryption, it'd be nice if gscan2pdf
could prompt me for a password to unlock the file. Would this be
doable without too much trouble?

At this stage, on import, I get errors:

  1. "Error extracting text layer from PDF"
  2. "Error extracting images from PDF"

Thanks for your consideration!

-- 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.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.9.39+dfsg-1
ii  imagemagick-6.q16 [imagemagick]8:6.9.9.39+dfsg-1
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1
ii  libfilesys-df-perl 0.92-6+b3
ii  libgoo-canvas-perl 0.06-2+b4
ii  libgtk2-ex-simple-list-perl0.50-2
ii  libgtk2-imageview-perl 0.05-2+b4
ii  libhtml-parser-perl3.72-3+b2
ii  libimage-magick-perl   8:6.9.9.39+dfsg-1
ii  libimage-sane-perl 0.14-1+b1
ii  liblist-moreutils-perl 0.416-1+b3
ii  liblocale-gettext-perl 1.07-3+b3
ii  liblog-log4perl-perl   1.49-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b6
ii  libpdf-api2-perl   2.033-1
ii  libproc-processtable-perl  0.55-1
ii  libreadonly-perl   2.050-1
ii  librsvg2-common2.40.20-2
ii  libset-intspan-perl1.19-1
ii  libtiff-tools  4.0.9-4
ii  libtry-tiny-perl   0.30-1
ii  sane-utils 1.0.26~git20151121-1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin  3.5.27.1-8
ii  gocr   0.49-2+b1
pn  libgtk2-ex-podviewer-perl  
ii  sane   1.0.14-12
ii  tesseract-ocr  4.00~git2219-40f43111-1.2
ii  unpaper6.1-2+b1
ii  xdg-utils  1.1.2-2

gscan2pdf suggests no packages.

-- debconf-show failed


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#894740: (no subject)

[Lorenzo Ancora]

close 894740 1.1.0-4~bpo9+1

# btw this BTS is old and difficult to use. :-)

Bug#879619: Autopkgtest for ncbi-tools6

[Aaron M. Ucko]

Liubov Chuprikova  writes:

> Sorry for the delay in continuing the work!

No problem.

> Last two days I have been figuring out how to test *tbl2asn* and
> *asnmacro*. Please, take a look at the last commits
> .

These all look OK offhand, apart from one purely cosmetic consideration:
Sc_16.sbt has a lot of trailing whitespace that would be best to clean up.

> I could not understand where a macro file for *asnmacro* can be taken
> from. Is it possible to generate such a file by any program?

Just by a generic text editor, sorry.  However, this package does
already ship a macro file you may be able to test with:
/usr/share/ncbi/data/autofix.prt.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#894740: acpi-call-dkms: Bad return status for module build on kernel: 4.14.0-0.bpo.2-amd64

[Lorenzo Ancora]

Hello Raphaël,

> Please double check the archived bugs next time you report a bug.
I was not able to find bug #868110 in reportbug:
https://s18.postimg.org/gy26kqqmx/Istantanea_2018-04-03_22-56-45.png
As you can see the list is blank, except for this and another bug
report. Probably due to the version mismatch.
Next time I will make the archaeologist directly on the website,
ignoring the official app. :-)
> [...] a backport for Stretch is available since August 28th, 2017.
We are in 2018 and it dates back to 8 months ago. Why is not part of
Stable after so much time?
Good to know there is a quick solution. :-)

Thank you, the experimental version compiles correctly.

Regards,
Lorenzo

Il 03/04/2018 22:54, Raphaël Halimi ha scritto:
> Control: forcemerge 868110 -1
>
> This bug is a duplicate of #868110, which was fixed in 1.1.0-4, and a
> backport for Stretch is available since August 28th, 2017.
>
> Please double check the archived bugs next time you report a bug.
>
> Regards,
>

Bug#540294: closed by Niels Thykier <ni...@thykier.net> (Bug#540294: fixed in lintian 2.5.51)

[Simon McVittie]

Control: reopen -1

On Sun, 18 Jun 2017 at 09:21:14 +, Debian Bug Tracking System wrote:
> #540294: [new check] Check if Vcs-* and changelog distribution match
...
>* checks/changes-file.{desc,pm}:
>  + [BR] Apply patch by Simon McVittie to detect unreleased package
>uploaded to unstable and  mismatched .changes and
>Changes: distribution.  (Closes: #540294).

That was a different feature request, #542747 aka #647028 (which I
have now closed). It's sufficiently closely related to be confusing,
but not actually the same. I think I used the wrong bug number in my
git branch name when proposing that patch.

The feature request in #540294 has not been implemented, although I'm
not sure how feasible it really is.

smcv

Bug#882308: http-parser 2.7 breaks ruby-em-http-request's tests

[Christoph Biedl]

forwarded 882308 https://github.com/igrigorik/em-http-request/issues/316
thanks

Jérémy Lal wrote...

> Control: reassign -1 ruby-em-http-request
> I took the liberty to reassign it to it. Feel free to reassign to
> whichever you see it would be better assigned.

Good question where to put it, you already figured this, see below.

> Please try this patch on ruby-em-http-request.
> 
> --- a/lib/em-http/http_connection.rb
> +++ b/lib/em-http/http_connection.rb
> @@ -131,7 +131,7 @@
>end
> 
>@p.on_message_complete = proc do
> -if !client.continue?
> +if client and !client.continue?
>c = @clients.shift
>c.state = :finished
>c.on_request_complete

This does the trick. I was pretty close back in December but not
close enough.

> Bug or feature ? nodejs is using http-parser and has a thorough test suite,
> so i suppose we're on the safe side fixing this package (but my experience
> tells me i'm 80% wrong when i suppose things like that).

It looks a lot like a behaviour change in http-parser. Then
ruby-em-http-request cannot deal with an another on_message callback,
and fails. But I'd like to see that in the sources. Good question who is
to blame for this, the documentation for on_message is rather terse.
Hardening ruby-em-http-request using your patch is certainly a good
thing to do.

To increase the noise, I've also opened an issue at
ruby-em-http-request's upstream.

Christoph


signature.asc
Description: PGP signature

Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

[Simon McVittie]

On Wed, 04 Apr 2018 at 00:51:04 +0200, Axel Beckert wrote:
> since very recently, emacs25 on armhf (but not on amd64) crashes for
> me as follows:
> 
> emacs25: symbol lookup error: 
> /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: 
> g_date_copy

I would normally ask: if you run `ldd emacs25`, what does it
say? But this is emacs, so the answer is quite possibly "too much".
`ldd /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules` might give
a more concise answer that still contains the information I'm looking for.

In fact, running

LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules

and seeing whether it fails might also give interesting information.
(If successful, it should just print a usage message saying it requires
at least one  parameter.)

> Since emacs25 itself was last uploaded in 2017, i.e. over three months
> ago, I assumed the culprit is hidden in the very recently updated
> libglib2.0-0 package. And indeed, downgrading libglib2.0-0 to 2.56.0-4
> causes the issue to vanish.

There were no source code changes in upgrading libglib2.0-0 from 2.56.0-4
to 2.56.0-5, so it really shouldn't have lost any symbols; and if it did,
that should have caused FTBFS when it didn't match its .symbols file.

One major change in 2.56.0-5 is that libglib2.0.so.0 moved from
/lib/MULTIARCH to /usr/lib/MULTIARCH, which makes me wonder whether you
have an outdated version of GLib elsewhere in your library search path
or elsewhere in emacs25's RPATH or RUNPATH, such that the outdated version
was found after /lib/MULTIARCH but before /usr/lib/MULTIARCH?

Another possibility is that emacs25 might do something horrible during
its startup that makes it rely on absolute paths to libraries (I don't
use emacs myself, but I dimly remember rumours of it using a core dump
to optimize its own startup). But if it does that, then I would have
expected it to break equally badly whenever a library moves to the
multiarch directory?

smcv

Bug#882308: http-parser 2.7 breaks ruby-em-http-request's tests

[Jérémy Lal]

Control: reassign -1 ruby-em-http-request
I took the liberty to reassign it to it. Feel free to reassign to
whichever you see it would be better assigned.

Please try this patch on ruby-em-http-request.

--- a/lib/em-http/http_connection.rb
+++ b/lib/em-http/http_connection.rb
@@ -131,7 +131,7 @@
   end

   @p.on_message_complete = proc do
-if !client.continue?
+if client and !client.continue?
   c = @clients.shift
   c.state = :finished
   c.on_request_complete




Also i tried this but if fails:

--- a/lib/em-http/http_connection.rb
+++ b/lib/em-http/http_connection.rb
@@ -131,7 +131,7 @@
   end

   @p.on_message_complete = proc do
-if !client.continue?
+if !client or !client.continue?
   c = @clients.shift
   c.state = :finished
   c.on_request_complete

"c" is Nil here: the change with http-parser 2.7 makes
"on_message_complete" called in a case when it wasn't before.

Bug or feature ? nodejs is using http-parser and has a thorough test suite,
so i suppose we're on the safe side fixing this package (but my experience
tells me i'm 80% wrong when i suppose things like that).

Jérémy




2018-04-04 0:16 GMT+02:00 Jérémy Lal :

>
>
> 2018-04-03 23:22 GMT+02:00 Christoph Biedl  >:
>
>> Jérémy Lal wrote...
>>
>> > Control: reassign -1 ruby-http-parser.rb
>>
>> Thanks for taking care of that one. However ...
>>
>> > it seems ruby-em-http-request uses a fork of http_parser.rb that has not
>> > been updated for a while. However, upstream seems to have fixed some
>> > issues with more recents http-parser developments:
>> >
>> > https://github.com/tmm1/http_parser.rb/commit/7ef407e3524775
>> 0e369746dec4ed4ed6c2265f73
>> >
>> > So it'd rather be ruby-http-parser.rb debian package that needs a patch
>> here.
>>
>> The *ruby-http-parser.rb* package has been fixed in #881627 (yes, that
>> was me). The failing package however is *ruby-em-http-request*, and
>> while you state it's is fork of the first, I cannot quite see a lot of
>> common code.
>>
>> Are you sure the assignment to ruby-http-parser.rb is correct?
>>
>> Christoph, still trying to understand why the tests fail
>>
>
> I'm looking at it more thoroughly. Sorry for the thoughtless decision to
> move the bug,
> i'll put it back to where it belongs if necesssary.
>
> Jérémy
>
>

Bug#894696: ITP: nagios4 -- A host/service/network monitoring and management system

[Russell Stuart]

On Tue, 2018-04-03 at 13:51 +0200, Bas Couwenberg wrote:
> My point is that you maintain the package within the team, not that 
> other members in the team maintain the package instead.

Firstly I prefer to work on my own.

And secondly as I said I did email the team.  The response I got made
it _very_ plain they (or at least the one responder, who seemed to be
the only active member of the team at the end) was not interested in
packaging nagios4 for debian.  If the response had been "it's great to
see someone else stepping up to do the work, please join us", then
despite my preference for working alone, that is what I would have
done.  But that isn't the response I got.

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

Bug#894123: RM: nvidia-graphics-modules/oldstable -- RoQA; license problem; incompatible with current kernel ABI

[Andreas Beckmann]

On 2018-03-26 17:51, Ben Hutchings wrote:
> See #815060 for the license issue.

from the previous jessie RM request: https://bugs.debian.org/815525
>On Mon, 22 Feb 2016 10:02:56 +0100 Julien Cristau 
>wrote:
>> I'd rather we left (old)stable well alone.

> The Linux kernel ABI in jessie was changed in January as a result of
> the mitigation of the Meltdown security issue.  This package would
> need to be updated to build new compatible modules, but that should
> not be done due to the license issue.

OPU request: https://bugs.debian.org/888561

> For the same reasons, this package should also be removed from wheezy
> - though I don't think that's practical no since there won't be any
> further point releases.

Unfortunately the non-free bits cannot be updated via LTS :-(
Let's hope this changes for jessie-lts.

There have been inquiries about updated nvidia-graphics-modules for
(old)oldstable on the mailing list ...


Andreas

Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

[Axel Beckert]

Package: libglib2.0-0
Version: 2.56.0-5
Severity: grave
Control: affects -1 + emacs25

Dear Maintainers,

since very recently, emacs25 on armhf (but not on amd64) crashes for
me as follows:

emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy

Since emacs25 itself was last uploaded in 2017, i.e. over three months
ago, I assumed the culprit is hidden in the very recently updated
libglib2.0-0 package. And indeed, downgrading libglib2.0-0 to 2.56.0-4
causes the issue to vanish.

Due to emacs crashing, this issue also causes the postinst of every
elpa-* package and probably also every *-mode package to fail.

Actually this is where I noticed the issue first:

Setting up mmm-mode (0.5.5-2) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package mmm-mode (--configure):
 installed mmm-mode package post-installation script subprocess returned error 
exit status 1
Setting up elpa-gitattributes-mode (1.2.7-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-gitattributes-mode (--configure):
 installed elpa-gitattributes-mode package post-installation script subprocess 
returned error exit status 1
Setting up elpa-no-littering (0.5.13-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-no-littering (--configure):
 installed elpa-no-littering package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of elpa-git-modes:
 elpa-git-modes depends on elpa-gitattributes-mode (= 1.2.7-1); however:
  Package elpa-gitattributes-mode is not configured yet.

dpkg: error processing package elpa-git-modes (--configure):
 dependency problems - leaving unconfigured
Setting up elpa-ps-ccrypt (1.10-6) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-ps-ccrypt (--configure):
 installed elpa-ps-ccrypt package post-installation script subprocess returned 
error exit status 1
Setting up elpa-hl-todo (1.8.1-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-hl-todo (--configure):
 installed elpa-hl-todo package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 mmm-mode
 elpa-gitattributes-mode
 elpa-no-littering
 elpa-git-modes
 elpa-ps-ccrypt
 elpa-hl-todo

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 
'buildd-experimental'), (1, 'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libglib2.0-0 depends on:
ii  libc62.27-3
ii  libffi6  3.2.1-8
ii  libmount12.31.1-0.5
ii  libpcre3 2:8.39-9
ii  libselinux1  2.7-2+b2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.56.0-5
ii  shared-mime-info  1.9-2
pn  xdg-user-dirs 

libglib2.0-0 suggests no packages.

-- no debconf information

Bug#881491: lintian: update gir checks for gobject-introspection/1.54.1-3 mini-policy

[Simon McVittie]

On Sun, 12 Nov 2017 at 12:35:40 +, Simon McVittie wrote:
> gobject-introspection/1.54.1-3 [contains] GIR mini-policy
> updates aimed at reducing false positives from Lintian.
...
> This gives Lintian enough information to avoid some unnecessary warnings
> when the attached patches are applied.

On Sun, 12 Nov 2017 at 13:29:05 +, Simon McVittie wrote:
> Looking at the archive's Lintian warnings, we also need to specify what
> to do about the rare typelibs that contain underscores (like v_sim)

I've rebased these patches (no changes) and pushed them to:

https://salsa.debian.org/smcv/lintian.git -b gir-881491

Reviews welcome. They still pass tests against current Lintian, after I
re-wrap an (unrelated) over-long line in d/changelog that trips a coding
style check.

The mini-policy change that mandates the same thing checked by the last
commit was released in gobject-introspection/1.54.1-4 and has been in
buster since late December.

Most (all?) GNOME packages already comply with the new mini-policy, so
applying these patches would fix many of their false-positives.

Thanks,
smcv

Bug#894762: cups-daemon: with IdleExitTimeout 60, correctly exits when idle for 60 s, but immediately respawns [regression]

[Francesco Poli (wintermute)]

Package: cups-daemon
Version: 2.2.7-1
Severity: normal

Dear Debian Printing Team,
I noticed a weird misbehavior of cupsd, which seems to be a regression.

I had configured /etc/cups/cupsd.conf with the directive

  IdleExitTimeout 60

in order to let cupsd exit when idle for 60 s: the feature (with
systemd socket activation) was working correctly.

However, after upgrading

  [UPGRADE] cups:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-bsd:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-client:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-common:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-core-drivers:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-daemon:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-ipp-utils:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-ppdc:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-server-common:amd64 2.2.6-5 -> 2.2.7-1

cupsd exits after 60 s of inactivity, but is mysteriously respawned
immediately.
The net result of all this is that cupsd gets restarted once every
60 s, which is annoying (especially because of colord verbosity,
see bug #750533).

The fact is that I cannot understand why cupsd gets respawned,
when nobody is attempting to print anything or to use the web
interface.
And I am pretty sure that cups-daemon/2.2.6-5 did not exhibit
this misbehavior.

Could you please investigate this issue?

Thanks for your time and helpfulness!
Bye.



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

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

Versions of packages cups-daemon depends on:
ii  adduser   3.117
ii  bc1.07.1-2
ii  dpkg  1.19.0.5
ii  libavahi-client3  0.7-3.1
ii  libavahi-common3  0.7-3.1
ii  libc6 2.27-2
ii  libcups2  2.2.7-1
ii  libcupsmime1  2.2.7-1
ii  libdbus-1-3   1.12.6-2
ii  libgssapi-krb5-2  1.16-2
ii  libpam0g  1.1.8-3.7
ii  libpaper1 1.1.24+nmu5
ii  libsystemd0   238-3
ii  lsb-base  9.20170808
ii  procps2:3.3.12-4
ii  ssl-cert  1.0.39

Versions of packages cups-daemon recommends:
pn  avahi-daemon  
ii  colord1.3.3-2
ii  cups-browsed  1.20.1-1+b1

Versions of packages cups-daemon suggests:
ii  cups 2.2.7-1
ii  cups-bsd 2.2.7-1
ii  cups-client  2.2.7-1
ii  cups-common  2.2.7-1
ii  cups-filters [foomatic-filters]  1.20.1-1+b1
pn  cups-pdf 
ii  cups-ppdc2.2.7-1
ii  cups-server-common   2.2.7-1
ii  foomatic-db  20180210-1
ii  ghostscript  9.22~dfsg-2
pn  hplip
ii  poppler-utils0.62.0-2
ii  printer-driver-gutenprint5.2.13-2
ii  printer-driver-hpcups3.17.10+repack0-5
pn  smbclient
ii  udev 238-3

-- no debconf information

Bug#881773: ruby2.5: FTBFS on hppa: recursive once test fails

[John David Anglin]

On 2018-04-01 10:17 AM, Antonio Terceiro wrote:

I don't think working around this in the tests is the correct solution
to the issue. There was a similar problem on ppc64el recently, maybe you
can find a similar solution for hppa:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881772
I played around with modifying the limits in vm_core.h but this doesn't 
seem to be the problem.
If I run x=once(128) first, I get the stack overflow and it happens 
every time.  If I run x=once(7) first,
the overflow doesn't happen even with values much larger than 128. It's 
like something isn't

initialized properly.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#893041: libvirt-daemon: Update of libvirt fails due to dependency issues

[Lucio Crusca]

Package: libvirt-daemon-system
Version: 4.1.0-2
Followup-For: Bug #893041

Still present for me in 4.1.0-2

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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.117
ii  debconf [debconf-2.0]  1.5.66
ii  gettext-base   0.19.8.1-6
ii  iptables   1.6.2-1
ii  libacl12.2.52-3+b1
ii  libapparmor1   2.12-4
ii  libaudit1  1:2.8.2-1
ii  libblkid1  2.31.1-0.5
ii  libc6  2.27-3
ii  libcap-ng0 0.7.7-3.1+b1
ii  libdbus-1-31.12.6-2
ii  libdevmapper1.02.1 2:1.02.145-4.1
ii  libgnutls303.5.18-1
ii  libnl-3-2003.2.27-2
ii  libnl-route-3-200  3.2.27-2
ii  libnuma1   2.0.11-2.1
ii  libselinux12.7-2+b2
ii  libvirt-clients4.1.0-2
ii  libvirt-daemon 4.1.0-2
ii  libvirt0   4.1.0-2
ii  libxml22.9.4+dfsg1-6.1
ii  libyajl2   2.1.0-2+b3
ii  logrotate  3.11.0-0.1
ii  lsb-base   9.20170808
ii  policykit-10.105-20

Versions of packages libvirt-daemon-system recommends:
ii  bridge-utils 1.5-15
ii  dmidecode3.1-1
ii  dnsmasq-base [dnsmasq-base]  2.79-1
ii  ebtables 2.0.10.4-3.5+b1
ii  iproute2 4.15.0-3
ii  parted   3.2-20

Versions of packages libvirt-daemon-system suggests:
ii  apparmor   2.12-4
pn  auditd 
pn  nfs-common 
pn  pm-utils   
pn  radvd  
ii  systemd238-4
pn  systemtap  
ii  zfsutils-linux [zfsutils]  0.7.6-1

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/allow-ipv4.xml'
/etc/libvirt/nwfilter/clean-traffic.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/clean-traffic.xml'
/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-spoofing.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-arp-spoofing.xml'
/etc/libvirt/nwfilter/no-ip-multicast.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-ip-multicast.xml'
/etc/libvirt/nwfilter/no-ip-spoofing.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-mac-broadcast.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-mac-broadcast.xml'
/etc/libvirt/nwfilter/no-mac-spoofing.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-other-l2-traffic.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-other-l2-traffic.xml'
/etc/libvirt/nwfilter/no-other-rarp-traffic.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/no-other-rarp-traffic.xml'
/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml'
/etc/libvirt/nwfilter/qemu-announce-self.xml [Errno 13] Permesso negato: 
'/etc/libvirt/nwfilter/qemu-announce-self.xml'
/etc/libvirt/qemu.conf [Errno 13] Permesso negato: '/etc/libvirt/qemu.conf'
/etc/libvirt/qemu/networks/default.xml [Errno 13] Permesso negato: 
'/etc/libvirt/qemu/networks/default.xml'

-- debconf information:
  libvirt-daemon-system/id_warning: true

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Dear Andreas, dear Aaron,

On Thu, 29 Mar 2018 at 18:14 Andreas Tille  wrote:

> On Thu, Mar 29, 2018 at 02:35:01PM +, Liubov Chuprikova wrote:
> >
> > Thanks a lot for your attention to my work on the project!
>
> I'd like to confirm that this is because of your pretty good work. ;-)


Thanks again!

On Thu, 29 Mar 2018 at 19:30 Aaron M. Ucko  wrote:

> Liubov Chuprikova  writes:
>
> > Please, have an eye on my last commits
> > ! I'd
> like to
> > ask one question (most likely it is to Aaron): Are there tools that I
> > didn't include, but you would strongly recommend for testing? Then I will
> > concentrate on them to finish.
>
> These tests are shaping up nicely; thanks again for putting them
> together.  Of the remaining tools, I would prioritize testing tbl2asn
> and perhaps asnmacro.  (Also, please fix the typo in the asn2gb test's
> leading echo statement.)
>

Sorry for the delay in continuing the work! Last two days I have been
figuring out how to test *tbl2asn* and *asnmacro*. Please, take a look at
the last commits
. I could not
understand where a macro file for *asnmacro* can be taken from. Is it
possible to generate such a file by any program? I have included one as an
example, containing only a simple action (it is generated during
*run-unit-test* script execution).

Спасибо!
>

Oops! I have not paid attention to the fact that the date and time
headlines are written on my native language. Fixed it! ;-)

Regards,
Liubov

Bug#894338: nvidia-graphics-drivers: CVE-2018-6249, CVE-2018-6253: null pointer dereference and infinite recursion due to malformed shader

[Andreas Beckmann]

On 2018-04-03 22:17, Luca Boccassi wrote:
> Shouldn't this be reverted too:
> 
> https://salsa.debian.org/nvidia-team/glx-alternatives/commit/30014d629d71ae2400a0aae8533089daec23d8c9

No, this should do the right thing on stretch, too.
The old code in stretch is broken in some corner cases.


Andreas

Bug#750533: 'SystemdIdleExit off' stops respawns

[Francesco Poli]

On Wed, 4 Apr 2018 00:14:28 +0200 Francesco Poli wrote:

> I had to set
> 
>   SystemdIdleExit off
>   IdleExitTimeout 0
> 
> in /etc/cups/cupsd.conf in order to prevent cupsd from exiting when
> idle.

Sorry, the correct setting is just

  IdleExitTimeout 0

The other directive is no longer supported...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpcPm77FNadl.pgp
Description: PGP signature

Bug#894338: nvidia-graphics-drivers: CVE-2018-6249, CVE-2018-6253: null pointer dereference and infinite recursion due to malformed shader

[Andreas Beckmann]

On 2018-03-30 16:20, Luca Boccassi wrote:
> It's due to the updated glx-alternative-foo sets the libGL.so.1 symlink
> to Mesa, even when update-glx --glx nvidia is used:
> 
> lrwxrwxrwx 1 root root 48 Mar 30 15:02 
> /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
> lrwxrwxrwx 1 root root 50 Mar 30 15:02 
> /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1

Is this with the libglvnd libgl1 from stretch-backports installed? Then
this is intentional.
If backports breaks after updating stable, let's fix backports, not stable,

> I guess that was done for glvnd? But this happens with the stretch-
> backports version too, is that right?

I'm not sure what the problem is here exactly ...  and how to reproduce
it in a minimal stretch chroot ...

> Changing those symlinks manually to the nvidia version fixes the
> problem.

Pointing to what?



Andreas

BTW, is 390.48 compatible with libglvnd in testing?

Bug#882308: http-parser 2.7 breaks ruby-em-http-request's tests

[Jérémy Lal]

2018-04-03 23:22 GMT+02:00 Christoph Biedl :

> Jérémy Lal wrote...
>
> > Control: reassign -1 ruby-http-parser.rb
>
> Thanks for taking care of that one. However ...
>
> > it seems ruby-em-http-request uses a fork of http_parser.rb that has not
> > been updated for a while. However, upstream seems to have fixed some
> > issues with more recents http-parser developments:
> >
> > https://github.com/tmm1/http_parser.rb/commit/
> 7ef407e35247750e369746dec4ed4ed6c2265f73
> >
> > So it'd rather be ruby-http-parser.rb debian package that needs a patch
> here.
>
> The *ruby-http-parser.rb* package has been fixed in #881627 (yes, that
> was me). The failing package however is *ruby-em-http-request*, and
> while you state it's is fork of the first, I cannot quite see a lot of
> common code.
>
> Are you sure the assignment to ruby-http-parser.rb is correct?
>
> Christoph, still trying to understand why the tests fail
>

I'm looking at it more thoroughly. Sorry for the thoughtless decision to
move the bug,
i'll put it back to where it belongs if necesssary.

Jérémy

Bug#750533: 'SystemdIdleExit off' stops respawns

[Francesco Poli]

On Sun, 10 Aug 2014 11:19:57 -0400 Dominique Brazziel wrote:

>   No cups respawns or the attendant 
> colord messages since putting 'SystemdIdleExit off'
> in 'cupsd.conf'. I remain perplexed as to why cups kept waking up
> (on socket activation I reckon) when no jobs were printing 
> and no web interface was active.  I guess I could
> look into the cups scheduler code, but the main thing
> for me was to shut colord up.

Hi,
I am another user bitten by this bug.

I had to set

  SystemdIdleExit off
  IdleExitTimeout 0

in /etc/cups/cupsd.conf in order to prevent cupsd from exiting when
idle.

This is unfortunate, since letting cupsd exit when idle looks like a
good idea to reduce system activity until cupsd is needed again.

If colord were more quiet, I could enable cupsd IdleExitTimeout again...


Dear colord Debian package maintainer(s), is there any progress in
fixing this colord flaw?
Please let me know.

Thanks for your time and helpfulness!
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpRz650WoCj4.pgp
Description: PGP signature

Bug#893523: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 27 de marzo de 2018 19:09:52 -03 Emilio Pozuelo Monfort escribió:
> On 19/03/18 20:22, Lisandro Damián Nicanor Pérez Meyer wrote:
> > In order to know what we are facing:
> > 
> > - #893535 deepin-qt5dxcb-plugin: FTBFS with Qt 5.10.1 in experimental
> > - #876934 openorienteering-mapper FTBFS: test failures ← not really
> > our bug, compiles with qt 5.10.1 but tests keep failing
> > - #893540 telegram-desktop maybe a bug in my chroot?

I've rebuilt the rdeps successfully. The above bugs seems to have been solved, 
so from our side we are ready to go.

I understand that the akonadi transition is currently going on, so we will 
need to wait for it to complete.

Cheers, Lisandro.


-- 
Gabardinas "Windows 95". Se cuelgan solas.

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


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

Bug#592159: ITP: poezio -- XMPP terminal-based client

[W. Martin Borgert]

A preliminary package, mainly the work of Tanguy, with only very
minor updates by me, is here:

https://salsa.debian.org/debacle/poezio

If nobody objects, I will move this to

https://salsa.debian.org/xmpp-team/poezio

Note, that this needs the latest slixmpp snapshot, e.g. from

https://salsa.debian.org/debacle/slixmpp

Bug#887470: slixmpp: please package new version 1.3.0

[W. Martin Borgert]

Preliminary new snapshot package here:

https://salsa.debian.org/debacle/slixmpp

If nobody objects, I will move this to

https://salsa.debian.org/xmpp-team/slixmpp

Bug#894760: apache2-bin: trying to overwrite '/usr/lib/apache2/modules/mod_md.so', which is also in package libapache2-mod-md 1.1.0-1

[Axel Beckert]

Package: apache2-bin
Version: 2.4.33-1
Severity: serious
Control: clone -1 -2
Control: retitle -2 apache2: trying to overwrite 
'/etc/apache2/mods-available/md.load', which is also in package 
libapache2-mod-md 1.1.0-1
Control: reassign -2 apache2 2.4.33-1

Hi,

Apache upstream now includes mod_md, but neither the apache2 nor the
apache2-bin package contain the according Breaks and Replaces fields
against libapache2-mod-md, hence the upgrade of apache2 and apache2-bin
fails as follows if libapache2-mod-md is already installed:

Preparing to unpack .../apache2_2.4.33-1_armhf.deb ...
[ ok ] Stopping Apache httpd web server: apache2.
Unpacking apache2 (2.4.33-1) over (2.4.29-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/apache2_2.4.33-1_armhf.deb (--unpack):
 trying to overwrite '/etc/apache2/mods-available/md.load', which is also in 
package libapache2-mod-md 1.1.0-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
[…]
Preparing to unpack .../apache2-bin_2.4.33-1_armhf.deb ...
Unpacking apache2-bin (2.4.33-1) over (2.4.29-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/apache2-bin_2.4.33-1_armhf.deb (--unpack):
 trying to overwrite '/usr/lib/apache2/modules/mod_md.so', which is also in 
package libapache2-mod-md 1.1.0-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../libp11-kit0_0.23.10-2_armhf.deb ...
Unpacking libp11-kit0:armhf (0.23.10-2) over (0.23.9-2) ...
Errors were encountered while processing:
 /var/cache/apt/archives/apache2_2.4.33-1_armhf.deb
 /var/cache/apt/archives/apache2-bin_2.4.33-1_armhf.deb

Uninstalling libapache2-mod-md beforehand (or even in the same aptitude
run) solves the issue.

(JFTR: Bug report written on a different machine and architecture
(amd64) than I ran into the bug (armhf).)

-- Package-specific info:

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages apache2-bin depends on:
ii  libapr1  1.6.3-2
ii  libaprutil1  1.6.1-2
ii  libaprutil1-dbd-sqlite3  1.6.1-2
ii  libaprutil1-ldap 1.6.1-2
ii  libbrotli1   1.0.3-1
ii  libc62.27-3
ii  libcurl3 7.58.0-2
ii  libjansson4  2.11-1
ii  libldap-2.4-22.4.45+dfsg-1
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libnghttp2-141.31.0-1
ii  libpcre3 2:8.39-9
ii  libssl1.11.1.0h-2
ii  libxml2  2.9.4+dfsg1-6.1
ii  perl 5.26.1-5
ii  zlib1g   1:1.2.8.dfsg-5

apache2-bin recommends no packages.

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   64.0.3282.119-2+b2
ii  conkeror [www-browser]   1.0.4-1
ii  dillo [www-browser]  3.0.5-4
ii  edbrowse [www-browser]   3.7.2-1
ii  elinks [www-browser] 0.12~pre6-13
ii  falkon [www-browser] 3.0.0-3
ii  firefox [www-browser]59.0.2-1
ii  firefox-esr [www-browser]52.7.3esr-1
ii  hv3 [www-browser]3.0~fossil20110109-6
ii  konqueror [www-browser]  4:17.08.3-2
ii  links [www-browser]  2.15-1
ii  links2 [www-browser] 2.15-1
ii  lynx [www-browser]   2.8.9dev17-1
ii  netrik [www-browser] 1.16.1-2+b1
ii  netsurf [www-browser]3.6-3.1
ii  netsurf-fb [www-browser] 3.6-3.1
ii  netsurf-gtk [www-browser]3.6-3.1
ii  opera-beta [www-browser] 52.0.2871.27
ii  opera-developer [www-browser]54.0.2913.0
ii  opera-stable [www-browser]   52.0.2871.40
ii  surf [www-browser]   2.0-5
ii  w3m [www-browser]0.5.3-36

Versions of packages apache2-bin is related to:
pn  apache2  
ii  apache2-bin  2.4.33-1

-- no debconf information

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Chris Lamb]

Hi Thomas,

> Maybe the solution is then not in rcc but in whatever generate the files 
> that the qrc that rcc processes refer to. For instance in the case of 
> ultracopier lrelease could have a mean if generating .qm files with the 
> same modified timestamp as the .ts file it processes

That sounds workable..


Regards,

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

Bug#892276: [Pkg-openssl-devel] Bug#892276: marked as done (libssl-dev: typo in usr/include/openssl/lhash.h)

[Kurt Roeckx]

On Tue, Apr 03, 2018 at 11:54:39PM +0200, Sebastian Andrzej Siewior wrote:
> I have just no idea what to do here regarding stable. Do we have plans
> to do s-p-u of the last 1.1.0 release?

We probably should.


Kurt

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Thomas Preud'homme]

On April 3, 2018 10:15:42 PM GMT+01:00, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>El mar., 3 de abr. de 2018 16:42, Sune Vuorela 
>escribió:
>
>> On Tuesday, April 3, 2018 9:24:58 PM CEST Chris Lamb wrote:
>> > I'm not /entirely/ sure what the difference is as I'm not in the
>> > Qt/RCC world too often these days (alas !), but why just not use
>> > SOURCE_DATE_EPOCH *iff* it is exported?
>> >
>> > Normal systems simply do not have this envvar set, so there is
>really
>> > no danger of it leaking elsewhere or causing unintended
>side-effects.
>>
>> We don't know how application users are using this.
>>
>> The following is some theoretical example, that I'm quite sure could
>be
>> used
>> in some real world applications:
>>
>> QFileInfo embeddedFile(":/foo/data.xml"); // fallback downloaded in
>the
>> ancient past
>> QFileInfo systemfile("/usr/share/foo/data.xml");
>>
>> if (systemfile.lastModified() > embeddedFile.lastModified())
>> {
>>data = readFromFile(systemFile);
>> }
>> else
>> {
>>data = readFromFile(embeddedFile);
>> }
>>
>> If S_D_E gets used, rather than the data.xml modified date in the
>source,
>> this
>> will end up using the wrong file if S_D_E is newer than the system
>copy of
>> the
>> file.
>>
>> This is not a unused databit, but a fully available piece of metadata
>for
>> the
>> files.
>
>
>I'm afraid Sune is right here, it might be used that way. Questionable?
>Sure thing, but still valid code.
>
>But after all the same can be said from embedding translations into the
>binary itself.
>
>So yes, we will need help from upstream with this one.
>
>>
>>

Maybe the solution is then not in rcc but in whatever generate the files that 
the qrc that rcc processes refer to. For instance in the case of ultracopier 
lrelease could have a mean if generating .qm files with the same modified 
timestamp as the .ts file it processes. This would guarantee stable output for 
a stable source and this later on rcc would also generate stable output.

Thoughts?

Best regards,

Thomas

Bug#892548: dhelp: /usr/sbin/dhelp_parse broken with ruby 2.5

[Коля Гурьев]

Control: tag -1 unreproducible

Unfortunately, I can't reproduce this error. However, I've faced the
other error related to dhelp's cron script. It fails to build a document
index, and so search doesn't work. But at least the dhelp_parse utility
can rebuild its documentation directory, and a home page is still
available. It seems some of the next warnings aren't linked to dhelp.

But these issues are already reported, see Bug#803342 and Bug#889651.

(dhelp)root@barberry:/# sh -x /etc/cron.weekly/dhelp
+ [ -d /var/lib/dhelp ]
+ [ -x /usr/sbin/dhelp_parse ]
+ [ -x /usr/bin/index++ ]
+ rm --force /var/lib/dhelp/documents.index
+ /usr/sbin/dhelp_parse -r
/usr/lib/ruby/vendor_ruby/debian.rb:223: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:224: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:227: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:230: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:233: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:236: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:348: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:557: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:577: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:578: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:743: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:753: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:763: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:772: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:799: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:1004: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
+ /usr/sbin/dhelp_parse -i
/usr/lib/ruby/vendor_ruby/debian.rb:223: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:224: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:227: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:230: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:233: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:236: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:348: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:557: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:577: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:578: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:743: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:753: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:763: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:772: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:799: warning: 

Bug#892276: [Pkg-openssl-devel] Bug#892276: marked as done (libssl-dev: typo in usr/include/openssl/lhash.h)

[Sebastian Andrzej Siewior]

On 2018-04-03 23:34:15 [+0200], Kurt Roeckx wrote:
> > -#  define lh_new OPENSSL_lh_new
> > +#  define lh_new OPENSSL_LH_new
> [...]
> 
> >* Update to 1.1.1-pre4 (Closes: #892276, #894282).
> 
> This was fixed like a year ago in the master branch (and so 1.1.1)
> already, it just wasn't in the stable branch. It should get closed
> for the next upstream version of the 1.1.0 branch instead unless
> you want to fix it earlier.

Ah. I wasn't aware about 1.1.1. I just saw it fixed in pre4 so I assumed
it was fixed in the last release. I added it here so that the bugtracker
is aware that it is still fixed once we move exp to unstable.

As far as unstable is concerned, I cherry-picked it to the 1.1.0 branch
before the last (-1) upload. So we are good there, too.

I have just no idea what to do here regarding stable. Do we have plans
to do s-p-u of the last 1.1.0 release?

> Kurt

Sebastian

Bug#890672: fixed in x42-plugins 20170428-1.1

[Robin Gareus]

Hi,

Why don't you update to x42-plugins-20180320 which was released about
two weeks ago and also fixes this issue?

see https://tracker.debian.org/pkg/x42-plugins it has an "action
needed", high-prio item for it.

Cheers!
robin

PS. As opposed to what tracker.debian.org says, the package does not
depend on libpugl-dev, feel free to remove the build-dep while you're at it.



signature.asc
Description: OpenPGP digital signature

Bug#892276: [Pkg-openssl-devel] Bug#892276: marked as done (libssl-dev: typo in usr/include/openssl/lhash.h)

[Kurt Roeckx]

> -#  define lh_new OPENSSL_lh_new
> +#  define lh_new OPENSSL_LH_new
[...]

>* Update to 1.1.1-pre4 (Closes: #892276, #894282).

This was fixed like a year ago in the master branch (and so 1.1.1)
already, it just wasn't in the stable branch. It should get closed
for the next upstream version of the 1.1.0 branch instead unless
you want to fix it earlier.


Kurt

Bug#894758: maildir-utils: Incomplete debian/copyright?

[Chris Lamb]

Source: maildir-utils
Version: 1.0-2
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Norbert Preining 

Hi,

I just ACCEPTed maildir-utils from NEW but noticed it was missing 
attribution/licenses in debian/copyright for at least some of the
utilities under lib (eg. mu-flags.c) and perhaps some of the tests
under perl/t.

This is not at all exhaustive so please check over the entire
package  carefully and address these on your next upload :)


Regards,

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

Bug#894757: libmypaint-common: file conflict with mypaint-data

[Jeremy Bicha]

Package: libmypaint-common
Version: 1.3.0-1
Severity: serious
Forwarded: https://github.com/mypaint/mypaint/issues/918

libmypaint-common ships some of the same file names as mypaint-data
(the libmypaint.mo files).

I'm going to go ahead and add "Conflicts: mypaint-data" now. The way
forward is to have mypaint use libmypaint. When that happens, we can
add "Replaces: mypaint-data" too and close this bug.

I guess we're waiting for mypaint to do its 1.3 release then.

Thanks,
Jeremy Bicha

Bug#894756: systemfixtures: autopkgtest fails since python3.6 dropped depends on python3-distutils

[Paul Gevers]

Argg, sorry for the stupid report, wrong use of reportbug.

Since the upload of python3.6 version 3.6.5~rc1-2, it doesn't depend on
python3-distutils anymore. Your autopkgtest¹ fails since than with the
following error:

===
[ERROR]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/trial/runner.py", line
781, in loadByName
return self.suiteFactory([self.findByName(name, recurse=recurse)])
  File "/usr/lib/python3/dist-packages/twisted/trial/runner.py", line
710, in findByName
obj = reflect.namedAny(name)
  File "/usr/lib/python3/dist-packages/twisted/python/reflect.py", line
308, in namedAny
topLevelPackage = _importAndCheckStack(trialname)
  File "/usr/lib/python3/dist-packages/twisted/python/reflect.py", line
255, in _importAndCheckStack
reraise(excValue, excTraceback)
  File "/usr/lib/python3/dist-packages/systemfixtures/__init__.py", line
5, in 
from .users import FakeUsers
  File "/usr/lib/python3/dist-packages/systemfixtures/users.py", line 3,
in 
from fixtures import Fixture
  File "/usr/lib/python3/dist-packages/fixtures/__init__.py", line 89,
in 
from fixtures._fixtures import (
  File "/usr/lib/python3/dist-packages/fixtures/_fixtures/__init__.py",
line 50, in 
from fixtures._fixtures.logger import (
  File "/usr/lib/python3/dist-packages/fixtures/_fixtures/logger.py",
line 23, in 
from fixtures._fixtures.streams import StringStream
  File "/usr/lib/python3/dist-packages/fixtures/_fixtures/streams.py",
line 26, in 
import testtools
  File "/usr/lib/python3/dist-packages/testtools/__init__.py", line 113,
in 
from testtools.distutilscmd import (
  File "/usr/lib/python3/dist-packages/testtools/distutilscmd.py", line
7, in 
from distutils.core import Command
builtins.ModuleNotFoundError: No module named 'distutils'

I don't know if this is an issue of the test (adding the dependency
there can fix the issue) or if systemfixtures's dependencies need updating.

There are rumors that one shouldn't use distutils as a runtime
dependency and one should use sysconfig instead.

Paul

¹ https://ci.debian.net/packages/s/systemfixtures/unstable/amd64/



signature.asc
Description: OpenPGP digital signature

Bug#847937: Project moved

[Cédric Bellegarde]

New home page:
https://wiki.gnome.org/Apps/Lollypop

Debian is the last distribution not providing this package (with 
Ubuntu).


regards,
--
Cédric Bellegarde

Bug#894756: systemfixtures: autopkgtest fails since python3.6 dropped depends on python3-distutils

[Paul Gevers]

Source: systemfixtures
Version: 0.6.4-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: Paul Gevers 
To: Debian Bug Tracking System 
Subject: sunpy: autopkgtest fails since python3.6 dropped depends on 
python3-distutils
Usertag: regression
Message-ID: 
<152279115990.16641.13199119597255221062.report...@testavoira.marsaxlokk.dhcp.io>
X-Mailer: reportbug 7.1.10
Date: Tue, 03 Apr 2018 23:32:39 +0200
X-Debbugs-Cc: elb...@debian.org

U291cmNlOiBzdW5weQpWZXJzaW9uOiAwLjguMy0xClNldmVyaXR5OiBub3JtYWwKVXNlcjogY2kt
dGVhbUB0cmFja2VyLmRlYmlhbi5vcmcKCi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0t
LS0KSGFzaDogU0hBMjU2CgpTaW5jZSB0aGUgdXBsb2FkIG9mIHB5dGhvbjMuNiB2ZXJzaW9uIDMu
Ni41fnJjMS0yLCBpdCBkb2Vzbid0IGRlcGVuZCBvbgpweXRob24zLWRpc3R1dGlscyBhbnltb3Jl
LiBZb3VyIGF1dG9wa2d0ZXN0wrkgZmFpbHMgc2luY2UgdGhhbiB3aXRoIHRoZQpmb2xsb3dpbmcg
ZXJyb3I6CgphdXRvcGtndGVzdCBbMTA6NTM6MjZdOiB0ZXN0IGNvbW1hbmQyOiBjZCAkQURUVE1Q
ICYmIHB5dGhvbjMgLWMgImltcG9ydCBzdW5weTsgZXhpdChzdW5weS5zZWxmX3Rlc3QoYXJncz1c
Ii1rIG5vdCBmaWd1cmUgYW5kIG5vdCBvbmxpbmVcIikpIgphdXRvcGtndGVzdCBbMTA6NTM6MjZd
OiB0ZXN0IGNvbW1hbmQyOiBbLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVHJhY2ViYWNrIChtb3N0
IHJlY2VudCBjYWxsIGxhc3QpOgogIEZpbGUgIjxzdHJpbmc+IiwgbGluZSAxLCBpbiA8bW9kdWxl
PgogIEZpbGUgIi91c3IvbGliL3B5dGhvbjMvZGlzdC1wYWNrYWdlcy9zdW5weS9fX2luaXRfXy5w
eSIsIGxpbmUgMjQsIGluIDxtb2R1bGU+CiAgICBmcm9tIHN1bnB5LnV0aWwuY29uZmlnIGltcG9y
dCBsb2FkX2NvbmZpZywgcHJpbnRfY29uZmlnCiAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMy9kaXN0
LXBhY2thZ2VzL3N1bnB5L3V0aWwvX19pbml0X18ucHkiLCBsaW5lIDYsIGluIDxtb2R1bGU+CiAg
ICBmcm9tIHN1bnB5LnV0aWwudXRpbCBpbXBvcnQgKgogIEZpbGUgIi91c3IvbGliL3B5dGhvbjMv
ZGlzdC1wYWNrYWdlcy9zdW5weS91dGlsL3V0aWwucHkiLCBsaW5lIDEyLCBpbiA8bW9kdWxlPgog
ICAgZnJvbSBzdW5weS5leHRlcm4gaW1wb3J0IHNpeAogIEZpbGUgIi91c3IvbGliL3B5dGhvbjMv
ZGlzdC1wYWNrYWdlcy9zdW5weS9leHRlcm4vc2l4LnB5IiwgbGluZSA4LCBpbiA8bW9kdWxlPgog
ICAgZnJvbSBkaXN0dXRpbHMudmVyc2lvbiBpbXBvcnQgU3RyaWN0VmVyc2lvbgpNb2R1bGVOb3RG
b3VuZEVycm9yOiBObyBtb2R1bGUgbmFtZWQgJ2Rpc3R1dGlscycKCkkgZG9uJ3Qga25vdyBpZiB0
aGlzIGlzIGFuIGlzc3VlIG9mIHRoZSB0ZXN0IChhZGRpbmcgdGhlIGRlcGVuZGVuY3kgdGhlcmUg
Y2FuCmZpeCB0aGUgaXNzdWUpIG9yIGlmIHN1bnB5J3MgZGVwZW5kZW5jaWVzIG5lZWQgdXBkYXRp
bmcuCgpUaGVyZSBhcmUgcnVtb3JzIHRoYXQgb25lIHNob3VsZG4ndCB1c2UgZGlzdHV0aWxzIGFz
IGEgcnVudGltZSBkZXBlbmRlbmN5IGFuZApvbmUgc2hvdWxkIHVzZSBzeXNjb25maWcgaW5zdGVh
ZC4KClBhdWwKCsK5IGh0dHBzOi8vY2kuZGViaWFuLm5ldC9wYWNrYWdlcy9zL3N1bnB5L3Vuc3Rh
YmxlL2FtZDY0LwoKLSAtLSBTeXN0ZW0gSW5mb3JtYXRpb246CkRlYmlhbiBSZWxlYXNlOiBidXN0
ZXIvc2lkCiAgQVBUIHByZWZlcnMgdGVzdGluZy1kZWJ1ZwogIEFQVCBwb2xpY3k6ICg1MDAsICd0
ZXN0aW5nLWRlYnVnJyksICg1MDAsICd0ZXN0aW5nJyksICgyMDAsICd0ZXN0aW5nJyksICg1MCwg
J3Rlc3RpbmcnKQpBcmNoaXRlY3R1cmU6IGFtZDY0ICh4ODZfNjQpCgpLZXJuZWw6IExpbnV4IDQu
MTUuMC0yLWFtZDY0IChTTVAgdy8yIENQVSBjb3JlcykKTG9jYWxlOiBMQU5HPWVuX1VTLlVURi04
LCBMQ19DVFlQRT1lbl9VUy5VVEYtOCAoY2hhcm1hcD1VVEYtOCksIExBTkdVQUdFPWVuX1VTOmVu
IChjaGFybWFwPVVURi04KQpTaGVsbDogL2Jpbi9zaCBsaW5rZWQgdG8gL2Jpbi9kYXNoCkluaXQ6
IHN5c3RlbWQgKHZpYSAvcnVuL3N5c3RlbWQvc3lzdGVtKQpMU006IEFwcEFybW9yOiBlbmFibGVk
CgotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQoKaVFFekJBRUJDQUFkRmlFRVdMWnRTSE5y
NlRzRkxlWnluRnlaNndXOWRRb0ZBbHJEOHZJQUNna1FuRnlaNndXOQpkUW9WeEFmL2FBcUhINWY5
OVYrNWtvci9sNVRCQStQU1Q4YVNsS28xU3FwaHY2NnNnM1RQeG5aTDdkbVR1UW1uCkFLVFprRVpy
d0QyUlpXWk15emJjWmRMZTJsOUQzc242M3BuMTlpRkJkb0lGUk5idkVpa2ZmSGxudjluRDdQZTEK
M3JlbXF5b21yS29GZXRsOXB5V21PT2dqc1UxcXdkV1crWG9jdmloQk1WSW03ZEhhbnZXSEVTRXVJ
aDQ5SU8regp4bHB6ZldFMHlMdUc1b29aZk9nOTNXUDVPcC82cUdLNWpJeEtOSFdacjdXMlFlb3pD
VTNqeDFyeDJSQjVwR1JkCmdFa0swRTlGUGsrWW5BbzVic2FxVEpHc3RGQmZMU1ZxdUViK2RGWFZH
V3phcGd6VEpEVTBYN2haQkxacktoT2cKcUhpUkdiZ3ZTK2ordkk1K2NKK1V4R016NmNkK1NBPT0K
PWlkK2gKLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tCg==

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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlrD8+QACgkQnFyZ6wW9
dQqZCwf/WeQ+5/66o/ls7f63gn/C45OpqLonE0GV319/+pXPbLr4v13hrkpc6Pdl
91Y64uqLiLLY9vhhpJdnZScFN1u8X6WUoVT6OlXVXe7FCV2q85lN1FrRzct+dbNA
0QIJNP4RKP5JkHX64h/FyThBdpQxJAlI3TltGwUJ/xbo0HjBFb6ohJKDsTJVhAfM
RjHR0V9PKzZIiCX3jVOG4LzqsVExkFYq22XRpV1WrzUl00yNE0W0q6HCNsMN90d2
u92BIoSxJv9H63wE8y/cKrYMSl7nvhqS2EXblRsC34dBy98fFrLM5u28uxPhNYok
Qj/OtWvidhmkVhxYZTcvDz8kQLQn1A==
=URvj
-END PGP SIGNATURE-

Bug#894755: sunpy: autopkgtest fails since python3.6 dropped depends on python3-distutils

[Paul Gevers]

Source: sunpy
Version: 0.8.3-1
Severity: normal
User: ci-t...@tracker.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since the upload of python3.6 version 3.6.5~rc1-2, it doesn't depend on
python3-distutils anymore. Your autopkgtest¹ fails since than with the
following error:

autopkgtest [10:53:26]: test command2: cd $ADTTMP && python3 -c "import sunpy; 
exit(sunpy.self_test(args=\"-k not figure and not online\"))"
autopkgtest [10:53:26]: test command2: [---
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/sunpy/__init__.py", line 24, in 
from sunpy.util.config import load_config, print_config
  File "/usr/lib/python3/dist-packages/sunpy/util/__init__.py", line 6, in 

from sunpy.util.util import *
  File "/usr/lib/python3/dist-packages/sunpy/util/util.py", line 12, in 
from sunpy.extern import six
  File "/usr/lib/python3/dist-packages/sunpy/extern/six.py", line 8, in 
from distutils.version import StrictVersion
ModuleNotFoundError: No module named 'distutils'

I don't know if this is an issue of the test (adding the dependency there can
fix the issue) or if sunpy's dependencies need updating.

There are rumors that one shouldn't use distutils as a runtime dependency and
one should use sysconfig instead.

Paul

¹ https://ci.debian.net/packages/s/sunpy/unstable/amd64/

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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlrD8vIACgkQnFyZ6wW9
dQoVxAf/aAqHH5f99V+5kor/l5TBA+PST8aSlKo1Sqphv66sg3TPxnZL7dmTuQmn
AKTZkEZrwD2RZWZMyzbcZdLe2l9D3sn63pn19iFBdoIFRNbvEikffHlnv9nD7Pe1
3remqyomrKoFetl9pyWmOOgjsU1qwdWW+XocvihBMVIm7dHanvWHESEuIh49IO+z
xlpzfWE0yLuG5ooZfOg93WP5Op/6qGK5jIxKNHWZr7W2QeozCU3jx1rx2RB5pGRd
gEkK0E9FPk+YnAo5bsaqTJGstFBfLSVquEb+dFXVGWzapgzTJDU0X7hZBLZrKhOg
qHiRGbgvS+j+vI5+cJ+UxGMz6cd+SA==
=id+h
-END PGP SIGNATURE-

Bug#894747: lintian: Re-enable YAML parsing for d/upstream/metadata files

[Chris Lamb]

tags 894747 + pending
thanks

Thanks Dylan — fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=fd55f0d4df464b05446573768ac7826530d3c308


Regards,

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

Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[François Mazen]

Hi Lumin,

upload to mentors done, please check:
https://mentors.debian.net/package/taptempo

Regards,

François



Le mardi 03 avril 2018 à 06:17 +, Lumin a écrit :
> Hi François,
> 
> On 31 March 2018 at 21:59, François Mazen  wrote:
> > 
> > This program is useful to quickly find the tempo of a song.
> > The idea is to type "taptempo" in a terminal, then hit enter key at
> > each beat while hearing a song, and display the tempo.
> > 
> > The targeted people are mainly musicians who need to transcribe
> > music
> > or play the song at the exact original tempo. The typical situation
> > to
> > use this software is when you are in a hurry and you don't have
> > time to
> > launch a big workstation like Ardour or Lmms in order to find the
> > tempo.
> 
> Got it. Thank you for this explanation.
> 
> > 
> > > 8. When you have built the latest version of the modified
> > > package,
> > > you could run lintian against it:
> > > 
> > > lintian -EviI --pedantic .changes
> > > 
> > > There generally shouldn't be any Error or Warning.
> > 
> > I've fixed all the error and the lintian output should be clean.
> 
> You have done quite a good job making the package in a good shape,
> and making the upstream very standard.
> 
> By the way I'm surprised that you have fixed all lintian outputs,
> including the pedantic stuff. The pedantic items are only optional,
> not what must be fixed. Errors and Warnings should be dealt with,
> and some lintian Info can even pass if the maintainer has a good
> reason.
> 
> In return everything's shining and in good shape :-)
> 
> > Let me know if it still require more work.
> 
> Nitpicking:
> 
> 1. Please collapse the two lines in changelog into one. They refer to
> the same thing.
> 
> -  * Initial debian package.
> -  * Closes: #893306
> +  * Initial debian package. (Closes: #893306)
> 
> 2. there is still an autpkgtest problem:
> 
> autopkgtest [07:01:02]: test version: [---
> spawn taptempo --version
> couldn't execute "taptempo": no such file or directory
> while executing
> "spawn taptempo --version"
> (file
> "/tmp/autopkgtest.C3pEq9/build.uWo/src/debian/tests/version" line 6)
> autopkgtest [07:01:03]: test version: ---]
> autopkgtest [07:01:03]: test version:  - - - - - - - - - - results -
> -
> - - - - - - - -
> version  FAIL non-zero exit status 1
> autopkgtest [07:01:03]: test version:  - - - - - - - - - - stderr - -
> - - - - - - - -
> couldn't execute "taptempo": no such file or directory
> while executing
> "spawn taptempo --version"
> (file
> "/tmp/autopkgtest.C3pEq9/build.uWo/src/debian/tests/version" line 6)
> 
> this can be fixed by the patch. It looks somewhat wired but we need
> it.
> 
> --- a/debian/tests/control
> +++ b/debian/tests/control
> @@ -1,2 +1,2 @@
>  Tests: version, help, tempo
> -Depends: expect
> +Depends: expect, taptempo
> 
> The autopkgtest result after patched:
> 
> http://debomatic-amd64.debian.net/distribution#unstable/taptempo/1.3.
> 0-1/autopkgtest
> 
> build result:
> 
> http://debomatic-amd64.debian.net/distribution#unstable/taptempo/1.3.
> 0-1/buildlog
> 
> > Should I update this new package to the mentors website?
> 
> Yes, please fix the two problem mentioned above, and upload to
> mentors.
> 
> Thank you for you contribution to Debian, and have a good day.

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

Bug#894690: lintian: false positives for privacy-breach-generic when Mallard docs have a

[Chris Lamb]

tags 894690 + pending
thanks

Hi Simon,

Thanks for the report. I've fixed in Git with a testcase, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b3fd60aa18eebbe9db8455e4a31dbdb3e64541d6


Regards,

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

Bug#882308: http-parser 2.7 breaks ruby-em-http-request's tests

[Christoph Biedl]

Jérémy Lal wrote...

> Control: reassign -1 ruby-http-parser.rb

Thanks for taking care of that one. However ...

> it seems ruby-em-http-request uses a fork of http_parser.rb that has not
> been updated for a while. However, upstream seems to have fixed some
> issues with more recents http-parser developments:
> 
> https://github.com/tmm1/http_parser.rb/commit/7ef407e35247750e369746dec4ed4ed6c2265f73
> 
> So it'd rather be ruby-http-parser.rb debian package that needs a patch here.

The *ruby-http-parser.rb* package has been fixed in #881627 (yes, that
was me). The failing package however is *ruby-em-http-request*, and
while you state it's is fork of the first, I cannot quite see a lot of
common code.

Are you sure the assignment to ruby-http-parser.rb is correct?

Christoph, still trying to understand why the tests fail


signature.asc
Description: PGP signature

Bug#894754: vagrant: Invalid gemspec in rbnacl-libsodium stack level too deep

[Nicholas Capo]

Package: vagrant
Version: 2.0.2+dfsg-3
Severity: normal

Dear Maintainer,

When running any `vagrant` command the following is error appears and the
command seems to never complete.

```
$ vagrant status
Invalid gemspec in [/usr/share/rubygems-integration/all/specifications/rbnacl-
libsodium.gemspec]: stack level too deep
```

At one point I typed Ctrl+C quickly and got this (possibly related) stack
trace:

```
$ vagrant status
Invalid gemspec in [/usr/share/rubygems-integration/all/specifications/rbnacl-
libsodium.gemspec]: stack level too deep
^CTraceback (most recent call last):
998: from /usr/bin/vagrant:23:in `'
997: from /usr/lib/ruby/2.5.0/rubygems.rb:309:in `activate_bin_path'
996: from /usr/lib/ruby/2.5.0/rubygems.rb:309:in `synchronize'
995: from /usr/lib/ruby/2.5.0/rubygems.rb:311:in `block in
activate_bin_path'
994: from /usr/lib/ruby/2.5.0/rubygems.rb:239:in `finish_resolve'
993: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:68:in
`require'
992: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1084:in
`find_active_stub_by_path'
991: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:850:in `stubs'
990: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:782:in
`installed_stubs'
989: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in
`map_stubs'
988: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in
`flat_map'
987: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in `each'
986: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:793:in `block
in map_stubs'
985: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:768:in
`gemspec_stubs_in'
984: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:768:in `select'
983: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:208:in
`valid?'
982: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:139:in
`data'
981: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:197:in
`to_spec'
980: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1194:in `load'
979: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1194:in `eval'
[ elided many copies of the same stack]
 34: from /usr/share/rubygems-integration/all/specifications/rbnacl-
libsodium.gemspec:2:in `load'
 33: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:68:in
`require'
 32: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1084:in
`find_active_stub_by_path'
 31: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:850:in `stubs'
 30: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:782:in
`installed_stubs'
 29: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in
`map_stubs'
 28: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in
`flat_map'
 27: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in `each'
 26: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:793:in `block
in map_stubs'
 25: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:768:in
`gemspec_stubs_in'
 24: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:768:in `select'
 23: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:208:in
`valid?'
 22: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:139:in
`data'
 21: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:197:in
`to_spec'
 20: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1194:in `load'
 19: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1194:in `eval'
 18: from /usr/share/rubygems-integration/all/specifications/rbnacl-
libsodium.gemspec:2:in `load'
 17: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:68:in
`require'
 16: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1084:in
`find_active_stub_by_path'
 15: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:850:in `stubs'
 14: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:782:in
`installed_stubs'
 13: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in
`map_stubs'
 12: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in
`flat_map'
 11: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:790:in `each'
 10: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:793:in `block
in map_stubs'
  9: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:768:in
`gemspec_stubs_in'
  8: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:768:in `select'
  7: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:208:in
`valid?'
  6: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:118:in
`data'
  5: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:118:in
`open'
  4: from /usr/lib/ruby/2.5.0/rubygems/stub_specification.rb:129:in
`block in data'
  3: from 

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Lisandro Damián Nicanor Pérez Meyer]

El mar., 3 de abr. de 2018 16:42, Sune Vuorela  escribió:

> On Tuesday, April 3, 2018 9:24:58 PM CEST Chris Lamb wrote:
> > I'm not /entirely/ sure what the difference is as I'm not in the
> > Qt/RCC world too often these days (alas !), but why just not use
> > SOURCE_DATE_EPOCH *iff* it is exported?
> >
> > Normal systems simply do not have this envvar set, so there is really
> > no danger of it leaking elsewhere or causing unintended side-effects.
>
> We don't know how application users are using this.
>
> The following is some theoretical example, that I'm quite sure could be
> used
> in some real world applications:
>
> QFileInfo embeddedFile(":/foo/data.xml"); // fallback downloaded in the
> ancient past
> QFileInfo systemfile("/usr/share/foo/data.xml");
>
> if (systemfile.lastModified() > embeddedFile.lastModified())
> {
>data = readFromFile(systemFile);
> }
> else
> {
>data = readFromFile(embeddedFile);
> }
>
> If S_D_E gets used, rather than the data.xml modified date in the source,
> this
> will end up using the wrong file if S_D_E is newer than the system copy of
> the
> file.
>
> This is not a unused databit, but a fully available piece of metadata for
> the
> files.


I'm afraid Sune is right here, it might be used that way. Questionable?
Sure thing, but still valid code.

But after all the same can be said from embedding translations into the
binary itself.

So yes, we will need help from upstream with this one.

>
>

Bug#894753: ITP: node-asmcrypto -- JavaScript Cryptographic Library

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: node-asmcrypto
  Version : 0.22.0
  Upstream Author : Adam Lippai 
* URL : https://github.com/asmcrypto/asmcrypto.js
* License : MIT
  Programming Lang: JavaScript
  Description : JavaScript Cryptographic Library

asmCrypto is an implementation of popular cryptographic utilities with
performance in mind.

This is a dependency for OpenPGP.js.

Bug#894752: ITP: node-rusha -- high-performance pure-javascript SHA1 implementation

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: node-rusha
  Version : 0.8.13
  Upstream Author : Sam Rijs 
* URL : https://github.com/srijs/rusha
* License : MIT
  Programming Lang: JavaScript
  Description : high-performance pure-javascript SHA1 implementation

Rusha is an MIT-licensed, high-performance pure-javascript SHA1
implementation.

This is a dependency for OpenPGP.js.

Bug#891956:

[majster]

I have the same problem on my debian, reinstalling don't help.

Bug#894750: Checking compatibility of add-ons takes forever

[W. Martin Borgert]

Package: firefox-esr
Version: 52.7.3esr-1

This happens with every new Firefox version since a long time:

A window "Firefox Update" appears saying:

Checking Compatibility of Add-ons

Checking your add-ons for compatibility with this version of
Firefox.
[ animation of underground train ]
[ circle animation] This may take a few minutes...

Cancel (active) | Next (greyed out)

This goes on until I click on "Cancel", and then everything is
fine, no matter how much time I wait before clicking the
"Cancel" button.

Not a big deal, but still a little bit annoying and confusing.
Why does Firefox check things, that are hopefully already done
by dpkg? I don't have non-Debian plugins installed.


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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.4
ii  fontconfig2.12.6-0.1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-2
ii  libcairo-gobject2 1.15.10-1
ii  libcairo2 1.15.10-1
ii  libdbus-1-3   1.12.6-2
ii  libdbus-glib-1-2  0.110-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.12.6-0.1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8-20180321-1
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.0-4
ii  libgtk-3-03.22.29-2
ii  libgtk2.0-0   2.24.32-1
ii  libhunspell-1.6-0 1.6.2-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.18-1
ii  libnss3   2:3.35-2
ii  libpango-1.0-01.42.0-1
ii  libsqlite3-0  3.22.0-2
ii  libstartup-notification0  0.12-5
ii  libstdc++68-20180321-1
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-1
ii  libxcb1   1.13-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-4
ii  zlib1g1:1.2.8.dfsg-5

firefox-esr recommends no packages.

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16-2
pn  mozplugger 

-- no debconf information

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.4
ii  fontconfig2.12.6-0.1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-2
ii  libcairo-gobject2 1.15.10-1
ii  libcairo2 1.15.10-1
ii  libdbus-1-3   1.12.6-2
ii  libdbus-glib-1-2  0.110-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.12.6-0.1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8-20180321-1
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.0-4
ii  libgtk-3-03.22.29-2
ii  libgtk2.0-0   2.24.32-1
ii  libhunspell-1.6-0 1.6.2-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.18-1
ii  libnss3   2:3.35-2
ii  libpango-1.0-01.42.0-1
ii  libsqlite3-0  3.22.0-2
ii  libstartup-notification0  0.12-5
ii  libstdc++68-20180321-1
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-1
ii  libxcb1   1.13-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   

Bug#894751: license missing

[Thorsten Alteholz]

Package: libbpp-core
Version: 2.4.0-1
Severity: serious
thanks

Dear Maintainer,

as the CeCILL license is not part of /usr/share/common-licenses/, please 
add the full license text to your debian/copyright


Thanks!
  Thorsten

Bug#894740: acpi-call-dkms: Bad return status for module build on kernel: 4.14.0-0.bpo.2-amd64

[Raphaël Halimi]

Control: forcemerge 868110 -1

This bug is a duplicate of #868110, which was fixed in 1.1.0-4, and a
backport for Stretch is available since August 28th, 2017.

Please double check the archived bugs next time you report a bug.

Regards,

-- 
Raphaël Halimi

Bug#894715: netbeans doesn't start (and exits with error code 2)

[Markus Koschany]

Am 03.04.2018 um 22:29 schrieb Pierre Thierry:
> Scribit Markus Koschany dies 03/04/2018 hora 14:56:
>> For now I guess the only way to make it work in testing/unstable is
>> to revert back to OpenJDK 8 via update-alternatives --config java
>> and to install libequinox-osgi-java 3.8.1 from snapshots.debian.org.
> 
> If netbeans 8.1 depends on libequinox-osgi-java 3.8.1, shouldn't that
> be reflected in the package?
> 
> Curiously,
> Pierre

Netbeans would work with the latest version of libequinox-osgi-java but
a patch must be updated and it is not possible to build the package from
source at the moment. See the other bug report that I mentioned before
for more details.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#894749: ruby-grpc: FTBFS on ppc64el: cannot open shared object file: No such file or directory

[Emilio Pozuelo Monfort]

Source: ruby-grpc
Version: 1.3.2+debian-4
Severity: serious

Your package fails to build on ppc64el (where it built before):

An error occurred while loading 
/<>/ruby-grpc-1.3.2+debian/src/ruby/spec/server_spec.rb.
Failure/Error: require_relative 'grpc_c'

LoadError:
  libprofiler.so.0: cannot open shared object file: No such file or directory - 
/<>/ruby-grpc-1.3.2+debian/debian/ruby-grpc/usr/lib/powerpc64le-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.3.2/src/ruby/lib/grpc/grpc_c.so
# 
/<>/ruby-grpc-1.3.2+debian/debian/ruby-grpc/usr/lib/powerpc64le-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.3.2/src/ruby/lib/grpc/grpc.rb:37:in
 `require_relative'
# 
/<>/ruby-grpc-1.3.2+debian/debian/ruby-grpc/usr/lib/powerpc64le-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.3.2/src/ruby/lib/grpc/grpc.rb:37:in
 `'
# 
/<>/ruby-grpc-1.3.2+debian/debian/ruby-grpc/usr/lib/powerpc64le-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.3.2/src/ruby/lib/grpc/errors.rb:30:in
 `require_relative'
# 
/<>/ruby-grpc-1.3.2+debian/debian/ruby-grpc/usr/lib/powerpc64le-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.3.2/src/ruby/lib/grpc/errors.rb:30:in
 `'
# 
/<>/ruby-grpc-1.3.2+debian/debian/ruby-grpc/usr/lib/powerpc64le-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.3.2/src/ruby/lib/grpc.rb:32:in
 `require_relative'
# 
/<>/ruby-grpc-1.3.2+debian/debian/ruby-grpc/usr/lib/powerpc64le-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.3.2/src/ruby/lib/grpc.rb:32:in
 `'
# /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
# /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
# /<>/ruby-grpc-1.3.2+debian/src/ruby/spec/server_spec.rb:30:in `'
# /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1954:in `load'
# /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1954:in 
`load_spec_file_handling_errors'
# /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1496:in `block in 
load_spec_files'
# /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1494:in `each'
# /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1494:in 
`load_spec_files'
# /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:100:in `setup'
# /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:86:in `run'
# /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:71:in `run'
# /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:45:in `invoke'
# /usr/bin/rspec:4:in `'

An error occurred while loading 
/<>/ruby-grpc-1.3.2+debian/src/ruby/spec/time_consts_spec.rb.
Failure/Error: require_relative 'grpc_c'

Full log: 
https://buildd.debian.org/status/fetch.php?pkg=ruby-grpc=ppc64el=1.3.2%2Bdebian-4%2Bb1=1522784711=0

Emilio

Bug#894748: plasma-workspace: Plasmashell crashes when notification shown

[Tom Wa]

Package: plasma-workspace
Version: 4:5.12.4-1
Severity: important
Tags: upstream

Dear Maintainer,

Plasmashell freezes when showing a notification. I can use everything else like 
the menu, tooltips and tray apps but if any app, like plasma-nm, pops up a 
notification the notification starts to draw before hanging while using 100% 
cpu. I then have to kill and restart plasmashell.

This may have something to do with the compsitor but I have no idea how I might 
fix this - Intel gfx so nothing exotic. No error message is written to the 
console or xsession-errors.



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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.12.6-2
ii  drkonqi  5.12.3-1
ii  frameworkintegration 5.44.0-1
ii  gdb-minimal [gdb]7.12-6+b1
ii  iso-codes3.79-1
ii  kactivitymanagerd5.12.1-1
ii  kde-cli-tools4:5.12.4-1
ii  kded55.44.0-1
ii  kinit5.44.0-1
ii  kio  5.44.0-1
ii  kpackagetool55.44.0-1
ii  kwin-common  4:5.12.4-1
ii  libappstreamqt2  0.11.8-3
ii  libc62.27-2
ii  libcln6  1.3.4-3
ii  libcolorcorrect5 4:5.12.4-1
ii  libgcc1  1:8-20180321-1
ii  libgps23 3.17-5
ii  libice6  2:1.0.9-2
ii  libkf5activities55.44.0-1
ii  libkf5auth5  5.44.0-1
ii  libkf5baloo5 5.44.0-1
ii  libkf5bookmarks5 5.44.0-1
ii  libkf5calendarevents55.44.0-1
ii  libkf5completion55.44.0-1
ii  libkf5configcore55.44.0-1
ii  libkf5configgui5 5.44.0-1
ii  libkf5configwidgets5 5.44.0-1
ii  libkf5coreaddons55.44.0-1
ii  libkf5crash5 5.44.0-1
ii  libkf5dbusaddons55.44.0-1
ii  libkf5declarative5   5.44.0-1
ii  libkf5globalaccel-bin5.44.0-1
ii  libkf5globalaccel5   5.44.0-1
ii  libkf5guiaddons5 5.44.0-1
ii  libkf5holidays5  1:5.44.0-1
ii  libkf5i18n5  5.44.0-1
ii  libkf5iconthemes55.44.0-1
ii  libkf5idletime5  5.44.0-1
ii  libkf5itemviews5 5.44.0-1
ii  libkf5jobwidgets55.44.0-1
ii  libkf5js55.44.0-1
ii  libkf5jsembed5   5.44.0-1
ii  libkf5kdelibs4support5   5.44.0-2
ii  libkf5kiocore5   5.44.0-1
ii  libkf5kiofilewidgets55.44.0-1
ii  libkf5kiogui55.44.0-1
ii  libkf5kiowidgets55.44.0-1
ii  libkf5networkmanagerqt6  5.44.0-1
ii  libkf5newstuff5  5.44.0-1
ii  libkf5notifications5 5.44.0-1
ii  libkf5notifyconfig5  5.44.0-1
ii  libkf5package5   5.44.0-1
ii  libkf5plasma55.44.0-1
ii  libkf5plasmaquick5   5.44.0-1
ii  libkf5prison55.44.0-1
ii  libkf5quickaddons5   5.44.0-1
ii  libkf5runner55.44.0-1
ii  libkf5service-bin5.44.0-1
ii  libkf5service5   5.44.0-1
ii  libkf5solid5 5.44.0-1
ii  libkf5texteditor55.44.0-1
ii  libkf5textwidgets5   5.44.0-1
ii  libkf5wallet-bin 5.44.0-1
ii  libkf5wallet55.44.0-1
ii  libkf5waylandclient5 4:5.44.0-1
ii  libkf5widgetsaddons5 5.44.0-1
ii  libkf5windowsystem5  5.44.0-1
ii  libkf5xmlgui55.44.0-2
ii  libkscreenlocker55.12.2-1
ii  libksgrd74:5.12.1-1
ii  libkworkspace5-5 4:5.12.4-1
ii  libphonon4qt5-4  

Bug#894715: netbeans doesn't start (and exits with error code 2)

[Pierre Thierry]

Scribit Markus Koschany dies 03/04/2018 hora 14:56:
> For now I guess the only way to make it work in testing/unstable is
> to revert back to OpenJDK 8 via update-alternatives --config java
> and to install libequinox-osgi-java 3.8.1 from snapshots.debian.org.

If netbeans 8.1 depends on libequinox-osgi-java 3.8.1, shouldn't that
be reflected in the package?

Curiously,
Pierre
-- 
pie...@nothos.net
OpenPGP 0xD9D50D8A


signature.asc
Description: PGP signature

Bug#894711: RFS: qtmpris/0.0.8-1 [ITP]

[Adam Borowski]

On Tue, Apr 03, 2018 at 08:25:32PM +0800, Yanhao Mo wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
>  * Package name: qtmpris
>Version : 0.0.801
>Upstream Author : Andres Gomez 
>  * URL : https://github.com/nemomobile/qtmpris
>  * License : GPL-2.1+
>Section : misc
> 
> It builds those binary packages:
> 
>   libmpris-qt5-1 - Qt MPRIS interface and adaptor (development files)
>   libmpris-qt5-dev - Qt MPRIS interface and adaptor
>   qml-module-org-nemomobile-mpris - Qt 5 MPRIS interface and adaptor QML 
> module

Hi!
The license of all files is LGPL 2+ rather than GPL; the difference is
important as LGPL allows using this library without imposing GPL on the
resultant binary.

As of packaging itself, it looks good so far otherwise.


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄

Bug#891799: [Pkg-openssl-devel] Bug#891799: fixed in openssl1.0 1.0.2o-1

[Aurelien Jarno]

On 2018-04-03 22:17, Sebastian Andrzej Siewior wrote:
> On 2018-03-28 18:41:50 [+0200], Aurelien Jarno wrote:
> > >* Add riscv64 (Closes: #891799).
> > 
> > Thanks for merging the patch. Unfortunately it doesn't work as there is
> > a small typo in debian-targets.patch, causing the package to FTBFS [1].
> > The patch below should fix that. Note the extra space between
> > "$(SHLIB_MAJOR)" and ".\$(SHLIB_MINOR)".
> 
> sorry for that.

No problem.

> > Could you please apply this patch in the next upload?
> 
> I added it to the git tree. The space is gone.

Great thanks.

> What do you mean by "next upload"? Is it "do it now please" or more
> "when upstream does 1.0.2p"?

Just next time you do an upload to the debian archive, ie new upstream
or new debian specific version. No need to do an upload specifically for
that.

Thanks,
Aurelien

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

Bug#894619: sdcc FTBFS with lyx 2.3.0-2

[Dr. Tobias Quathamer]

control: tag -1 patch
control: affects -1 =
control: reassign -1 src:sdcc 3.5.0+dfsg-2

Am 02.04.2018 um 17:01 schrieb Adrian Bunk:
> Package: lyx
> Version: 2.3.0-2
> Severity: serious
> Control: affects -1 src:sdcc
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sdcc.html
> 
> ...
> This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) 
> (preloaded format=latex)
>  restricted \write18 enabled.
> entering extended mode
> (./sdccman.tex
> LaTeX2e <2017-04-15>
> Babel <3.18> and hyphenation patterns for 3 language(s) loaded.
> 
> support/Systemcall.cpp (294): Systemcall: 'latex "sdccman.tex"' finished with 
> exit code 1
> This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) 
> (preloaded format=latex)
>  restricted \write18 enabled.
> entering extended mode
> (./sdccman.tex
> LaTeX2e <2017-04-15>
> Babel <3.18> and hyphenation patterns for 3 language(s) loaded.
> 
> support/Systemcall.cpp (294): Systemcall: 'latex "sdccman.tex"' finished with 
> exit code 1
> make: *** [debian/rules:71: build-indep-stamp] Error 1

Hi,

thanks a lot for filing this bug. However, I'm not convinced that this
is really a bug in lyx. The file leading to the FTBFS is rather old
(created with lyx 2.1) and uses some syntax no longer supported by
lyx 2.3.

Therefore, I think the correct course of action would be to fix the file
in question in the sdcc package. I've attached a minimal patch which
accomplishes just that. With the patch, sdcc builds fine in an unstable
chroot on my machine. It can be dropped into d/patches and added to
d/series.

The latest upstream version (3.7.0) also builds fine, as the
documentation file has been created with lyx 2.3. So this bug could also
be solved by packaging the new upstream version, also requested here:

https://bugs.debian.org/892869

Regards,
Tobias
--- a/doc/sdccman.lyx
+++ b/doc/sdccman.lyx
@@ -13,14 +13,6 @@
   \mbox{\ifx\def@pt\pas@pt\cite@rig{#2}\else\cite@rig[#1]{#2}\fi}}
 \renewcommand{\underbar}[1]{{\let\cite\b@xcite\uline{#1}}}
 \pdfoptionpdfminorversion=3
-\usepackage[
-  pdftitle={SDCC Compiler User Guide},
-  pdfauthor={SDCC development team},
-  pdfsubject={installation, user manual},
-  pdfkeywords={68hc08 8032 8051 ansi iso c compiler assembler CPU DS390 embedded development free Floating Point Arithmetic Freescale GPL HC08 S08 inline Intel ISO/IEC 9899:1990 Linux MAC OS X manual Maxim mcs51 Microchip microcontroller open source PIC Unix Windows Z80 Z180 Zilog Rabbit},
-  pdfpagemode=UseOutlines,
-  colorlinks=true,
-  linkcolor=blue] {hyperref}
 %
 \sloppy
 \tolerance=500  
@@ -51,7 +43,20 @@
 \index_command default
 \paperfontsize default
 \spacing single
-\use_hyperref false
+\use_hyperref true
+\pdf_title "SDCC Compiler User Guide"
+\pdf_author "SDCC development team"
+\pdf_subject "installation, user manual"
+\pdf_keywords "68hc08 8032 8051 ansi iso c compiler assembler CPU DS390 embedded development free Floating Point Arithmetic Freescale GPL HC08 S08 inline Intel ISO/IEC 9899:1990 Linux MAC OS X manual Maxim mcs51 Microchip microcontroller open source PIC Unix Windows Z80 Z180 Zilog Rabbit"
+\pdf_bookmarks true
+\pdf_bookmarksnumbered false
+\pdf_bookmarksopen false
+\pdf_bookmarksopenlevel 1
+\pdf_breaklinks false
+\pdf_pdfborder false
+\pdf_colorlinks true
+\pdf_backref false
+\pdf_pdfusetitle true
 \papersize letterpaper
 \use_geometry true
 \use_package amsmath 1


signature.asc
Description: OpenPGP digital signature

Bug#894747: lintian: Re-enable YAML parsing for d/upstream/metadata files

[Dylan Aïssi]

Package: lintian
Version: 2.5.80
Severity: wishlist
Control: block 731340 by -1

Hi,

Currently, the lintian checks for validity of d/u/metadata are
disabled since 2.5.50.4 [1] due to a security problem [2]
(CVE-2017-8829), but now we can safety use YAML::XS with the
$LoadBlessed option [3]. I wondering if we can re-enable the
d/u/metadata checks in lintian using the safety method?

Best,
Dylan

[1] 
https://anonscm.debian.org/git/lintian/lintian.git/commit/checks/upstream-metadata.pm?id=6119d49c3b
[2] https://bugs.debian.org/861958
[3] https://bugs.debian.org/862373#59

Bug#894338: nvidia-graphics-drivers: CVE-2018-6249, CVE-2018-6253: null pointer dereference and infinite recursion due to malformed shader

[Luca Boccassi]

On Tue, 2018-04-03 at 21:33 +0200, Andreas Beckmann wrote:
> On 2018-03-30 16:20, Luca Boccassi wrote:
> > Andreas, what should we do here for Stretch? If we update stretch
> > to
> > 384.130 we'll need the new glx-alternative too as they updated the
> > SONAMEs (a bit strange for an LTS branch), but as-is it will be
> > borken,
> > unless I'm missing something.
> 
> I prepared a stretch update for glx-alternatives in branch stretch.
> 
> 
> Andreas

Shouldn't this be reverted too:

https://salsa.debian.org/nvidia-team/glx-alternatives/commit/30014d629d71ae2400a0aae8533089daec23d8c9

Or another solution found? As it is right now, it won't work in stretch
as mentioned in my previous mail

-- 
Kind regards,
Luca Boccassi

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

Bug#891799: [Pkg-openssl-devel] Bug#891799: fixed in openssl1.0 1.0.2o-1

[Sebastian Andrzej Siewior]

On 2018-03-28 18:41:50 [+0200], Aurelien Jarno wrote:
> >* Add riscv64 (Closes: #891799).
> 
> Thanks for merging the patch. Unfortunately it doesn't work as there is
> a small typo in debian-targets.patch, causing the package to FTBFS [1].
> The patch below should fix that. Note the extra space between
> "$(SHLIB_MAJOR)" and ".\$(SHLIB_MINOR)".

sorry for that.

> Could you please apply this patch in the next upload?

I added it to the git tree. The space is gone.
What do you mean by "next upload"? Is it "do it now please" or more
"when upstream does 1.0.2p"?

> Thanks,
> Aurelien

Sebastian

Bug#894610: FTBFS: error: module cstream is in file 'std/cstream.d' which cannot be read

[Juhani Numminen]

Hi,

On Mon, 02 Apr 2018 11:48:34 +0200 Adam Borowski  wrote:> 
I'm afraid your package fails to build (tried on armhf amd64), with:
...
> src/abagames/util/Logger.d:8:8: error: module cstream is in file 
> 'std/cstream.d' which cannot be read
>  import std.cstream;
> ^

It seems that the cstream module was removed from the D standard library.[1]
It's still available in libundead.[2]

[1] https://github.com/dlang/phobos/commit/1ecc4d6
[2] https://sources.debian.org/src/libundead/1.0.9-2/src/undead/cstream.d/


Regards,
Juhani

Bug#894746: lxpolkit: Wrong exit code when login is cancelled

[Michael Lange]

Package: lxpolkit
Version: 0.5.3-2
Severity: normal

Dear Maintainer,

when lxpolkit is used for root login and the user hits the "Cancel" button, it
exits with code 127.
According to the pkexec man page, the exit code in such a situation should
rather be 126.

The exit code 127 is used by the pkexec command if no polkit user-agent is
running and thus root-login is not possible (if called with the --disable-
internal-agent option). This could be used by an application to present the
user an informative error message, like "Login not possible, please make sure a
polkit user-agent is running".
However with lxpolkit using the same exit code when login is cancelled, there
is no way of telling if no user agent is there or the user just hit "Cancel",
which makes a similar error message seem at least a bit awkward.

I checked with other user-agents (all on Stretch); the mate- and gnome
counterparts actually exit with 126 if login is cancelled, as one might expect
from man pkexec. lxqt-policykit and polkit-kde-agent-1 seem to also use 127
however.
Still I believe this is a bug (admittedly a small one) and should be changed if
possible.

Best regards

Michael



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

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

Versions of packages lxpolkit depends on:
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-11+deb9u3
ii  libcairo2  1.14.8-1
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgdk-pixbuf2.0-0 2.36.5-2+deb9u2
ii  libglib2.0-0   2.50.3-2
ii  libgtk2.0-02.24.31-2
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpangoft2-1.0-0  1.40.5-1
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libunique-1.0-01.1.6-5
ii  libx11-6   2:1.6.4-3
ii  lxsession-data 0.5.3-2
ii  policykit-10.105-18

lxpolkit recommends no packages.

lxpolkit suggests no packages.

-- no debconf information

Bug#894745: cross-gcc-dev patches misapply for recent gcc-7 and gcc-8

[Helmut Grohne]

Package: cross-gcc-dev
Version: 184
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

The recent gcc-7 and gcc-8 uploads add a feature called
FORCE_CROSS_LAYOUT. After these uploads, the cross-gcc-dev patches still
apply, but they apply in a useless way. Part of their effect is moved
from the cross compiler branch to the new FORCE_CROSS_LAYOUT branch and
thus rendered ineffective. The attached patch fixes that.

Helmut
--- cross-gcc-184/debian/changelog
+++ cross-gcc-184+nmu1/debian/changelog
@@ -1,3 +1,10 @@
+cross-gcc (184+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update for FORCE_CROSS_LAYOUT. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 03 Apr 2018 21:34:54 +0200
+
 cross-gcc (184) unstable; urgency=medium
 
   * rebuild for 8-20180331-1
--- 
cross-gcc-184/patches/gcc-7/0005-setting-all-the-various-paths-options-for-with_deps_.patch
+++ 
cross-gcc-184+nmu1/patches/gcc-7/0005-setting-all-the-various-paths-options-for-with_deps_.patch
@@ -83,11 +83,18 @@
 index caa8b5e..e9eaf0f 100644
 --- a/debian/rules.defs
 +++ b/debian/rules.defs
-@@ -209,6 +209,9 @@ else
+@@ -209,10 +209,16 @@ else
  # cross compiler, sets WITH_SYSROOT on it's own
  DEB_CROSS = yes
  build_type = build-cross
 +ifeq ($(with_deps_on_target_arch_pkgs),yes)
++  with_sysroot = /
++endif
+   else ifeq ($(FORCE_CROSS_LAYOUT),yes)
+ # a native build with a cross layout
+ DEB_CROSS = yes
+ build_type = build-cross
++ifeq ($(with_deps_on_target_arch_pkgs),yes)
 +  with_sysroot = /
 +endif
else
--- 
cross-gcc-184/patches/gcc-8/0005-setting-all-the-various-paths-options-for-with_deps_.patch
+++ 
cross-gcc-184+nmu1/patches/gcc-8/0005-setting-all-the-various-paths-options-for-with_deps_.patch
@@ -83,11 +83,18 @@
 index c63af56..3690f1b 100644
 --- a/debian/rules.defs
 +++ b/debian/rules.defs
-@@ -209,6 +209,9 @@ else
+@@ -209,10 +209,16 @@ else
  # cross compiler, sets WITH_SYSROOT on it's own
  DEB_CROSS = yes
  build_type = build-cross
 +ifeq ($(with_deps_on_target_arch_pkgs),yes)
++  with_sysroot = /
++endif
+   else ifeq ($(FORCE_CROSS_LAYOUT),yes)
+ # a native build with a cross layout
+ DEB_CROSS = yes
+ build_type = build-cross
++ifeq ($(with_deps_on_target_arch_pkgs),yes)
 +  with_sysroot = /
 +endif
else

Bug#836747: radioclk: Add ENABLED option to /etc/default/radioclk

[Paride Legovini]

On Mon, 05 Sep 2016 13:43:11 +0100 Colin Tuckley  wrote:
> Package: radioclk
> Version: 1.0.ds1-12
> Severity: wishlist
> 
> It would be useful if there was a way to stop the radioclk daemon being 
> started.

Hello Colin,

I'm in the process of adopting radioclk (see #889311).

Would shipping with a systemd unit file fix the issue for you?
You would be able to enable and disable the service with systemctl.

Paride

Bug#894744: ITP: puppet-module-cloudkitty -- Puppet module for OpenStack CloudKitty

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-cloudkitty
  Version : 1.0.0
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/puppet-cloudkitty
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for OpenStack CloudKitty

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of OpenStack
 CloudKitty rating engine.

Bug#894743: ibus-client-clutter FTCBFS: configures for the build architecture from ./autogen.sh

[Helmut Grohne]

Source: ibus-client-clutter
Version: 0.0+git20090728.a936bacf-5.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

ibus-client-clutter fails to cross build from source, because it
configures for the build architecture. It actually tries to configure
twice. Once for the build architecture (via autogen.sh) and then for the
host architecture (via cdbs). Unfortunately, the first configuration
makes the whole build fail. After removing it, ibus-client-clutter cross
builds successfully. Please consider applying the attached patch.

Helmut
Index: ibus-client-clutter-0.0+git20090728.a936bacf/autogen.sh
===
--- ibus-client-clutter-0.0+git20090728.a936bacf.orig/autogen.sh
+++ ibus-client-clutter-0.0+git20090728.a936bacf/autogen.sh
@@ -6,5 +6,4 @@
 autoconf
 autoheader
 automake -a
-./configure $@
 exit

Bug#894742: libguestfs: build-depends on linux-image-marvell on armel

[Emilio Pozuelo Monfort]

Source: libguestfs
Version: 1:1.36.13-2
Severity: serious

Hi,

libguestfs build-depends on linux-image-marvell on armel, but that package
is gone. Thus libguestfs is currently unbuildable:

https://buildd.debian.org/status/package.php?p=libguestfs

Emilio

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Sune Vuorela]

On Tuesday, April 3, 2018 9:24:58 PM CEST Chris Lamb wrote:
> I'm not /entirely/ sure what the difference is as I'm not in the
> Qt/RCC world too often these days (alas !), but why just not use
> SOURCE_DATE_EPOCH *iff* it is exported?
> 
> Normal systems simply do not have this envvar set, so there is really
> no danger of it leaking elsewhere or causing unintended side-effects.

We don't know how application users are using this.

The following is some theoretical example, that I'm quite sure could be used 
in some real world applications:

QFileInfo embeddedFile(":/foo/data.xml"); // fallback downloaded in the 
ancient past
QFileInfo systemfile("/usr/share/foo/data.xml");

if (systemfile.lastModified() > embeddedFile.lastModified())
{
   data = readFromFile(systemFile);
}
else
{
   data = readFromFile(embeddedFile);
}

If S_D_E gets used, rather than the data.xml modified date in the source, this 
will end up using the wrong file if S_D_E is newer than the system copy of the 
file.

This is not a unused databit, but a fully available piece of metadata for the 
files.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Thomas Preud'homme]

On April 3, 2018 8:20:22 PM GMT+01:00, Sune Vuorela  wrote:
>On Tuesday, April 3, 2018 9:14:23 PM CEST Chris Lamb wrote:
>> Hi Sune!
>> 
>> > I don't think honouring SOURCE_DATE_EPOCH is the right idea under
>normal
>> > circumstances
>> 
>> Can you elaborate on what you mean by "normal circumstances"? :)
>
>"normal circumstances" is rcc on a source file, as opposed to an
>autogenerated 
>file.
>
>> How about e use S_D_E if it is setup/exported, otherwise use the
>mtime
>> of the file as before?
>
>I think that using S_D_E only makes sense if rcc is run on an
>autogenerated 
>file, but I do think that most rcc runs is run on existing source
>files.
>
>
>I don't have a good idea to differentiate those.
>
>/Sune
>-- 
>I didn’t stop pretending when I became an adult, it’s just that when I
>was a 
>kid I was pretending that I fit into the rules and structures of this
>world. 
>And now that I’m an adult, I pretend that those rules and structures
>exist.
>   - zefrank

One small clarification: in my case rcc *is* run on a nongenerated resource 
file. It's some of the files that the resource file list that are generated and 
whose timestamp end up in the cpp file generated by rcc.

In other hand:

foo.qrc mentions bar.qm which is generated from bar.ts.

rcc foo.qrc generates resource_bar.cpp which contains constant data that 
encodes bar.qm timestamp and this create different resource_bar.o at every 
build.

Best regards,

Thomas

Bug#894338: nvidia-graphics-drivers: CVE-2018-6249, CVE-2018-6253: null pointer dereference and infinite recursion due to malformed shader

[Andreas Beckmann]

On 2018-03-30 16:20, Luca Boccassi wrote:
> Andreas, what should we do here for Stretch? If we update stretch to
> 384.130 we'll need the new glx-alternative too as they updated the
> SONAMEs (a bit strange for an LTS branch), but as-is it will be borken,
> unless I'm missing something.

I prepared a stretch update for glx-alternatives in branch stretch.


Andreas

Bug#894741: kcharselect crash when going to "Mathematical Symbols > Mathematical Operators" characters block

[Alexander Kernozhitsky]

Package: kcharselect
Version: 4:16.08.0-1+b1
Severity: important

Dear Maintainer,

Going to "Mathematical Symbols > Mathematical Operators" character block 
crashes the application. The crash happens only when a specific font is set 
(tested on Noto Sans, on many other fonts this bug is not reproducible).

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

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

Versions of packages kcharselect depends on:
ii  libc6 2.24-11+deb9u3
ii  libkf5configcore5 5.28.0-2
ii  libkf5configgui5  5.28.0-2
ii  libkf5configwidgets5  5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5i18n5   5.28.0-2
ii  libkf5widgetsaddons5  5.28.0-3
ii  libkf5xmlgui5 5.28.0-1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18+deb9u1

kcharselect recommends no packages.

kcharselect suggests no packages.

-- no debconf information

Bug#894740: acpi-call-dkms: Bad return status for module build on kernel: 4.14.0-0.bpo.2-amd64

[Lorenzo Ancora]

Package: acpi-call-dkms
Version: 1.1.0-3
Severity: serious
Justification: fails to build from source

Hello,
I'm trying to upgrade from Linux 4.9 to Linux 4.14, but I can not continue
because of acpi-call which fails to compile (via apt / aptitude to install the
header package).
There seems to be some incompatibility between the functions required by the
driver and those provided by the headers.

Failed compilation log: https://paste.debian.net/1018392

Until now I have always used the latest versions of the Linux kernel without
problems, because you have done a great job. This module is not critical but
may prevent other packages from working properly, so before updating, I would
like it to work.

Thanks for support,
Lorenzo



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

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

Versions of packages acpi-call-dkms depends on:
ii  dkms  2.3-2

acpi-call-dkms recommends no packages.

acpi-call-dkms suggests no packages.

-- no debconf information

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Chris Lamb]

Hi Sune,

> "normal circumstances" is rcc on a source file, as opposed
> to an autogenerated file

I'm not /entirely/ sure what the difference is as I'm not in the
Qt/RCC world too often these days (alas !), but why just not use
SOURCE_DATE_EPOCH *iff* it is exported?

Normal systems simply do not have this envvar set, so there is really
no danger of it leaking elsewhere or causing unintended side-effects.

It would also have the benefit of not having to differentiate between
the two... :)


Best wishes,

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

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Felix Natter]

Salvatore Bonaccorso  writes:

> Hi Felix,

hello Salvatore,

> On Sun, Apr 01, 2018 at 06:04:27PM +0200, Markus Koschany wrote:
>> 
>> 
>> Am 01.04.2018 um 17:57 schrieb Felix Natter:
>> [...]
>> > Thanks, done.
>> > BTW: Is it ok to close the bug with the stretch-security upload even if
>> > the jessie-security upload is still pending?
>> 
>> Yes, that's ok. You can close the bug with both uploads.
>> 
>> > What is there to do next?
>> 
>> As soon as the security team has approved the changes, I can upload your
>> packages to security-master.
>
> Thanks for working on it, the issue is severe enought that it warrants
> a DSA. Could you send the security team alias
> (t...@security.debian.org) debdiffs resulting from the build and
> tested packages for a short review + ack?

The stretch update is here (branch stretch-CVE-2018-169):
https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=stretch-CVE-2018-169=1

This is tested:
- activation log message is seen
- Save and Load XML works

In what format would you like the "tested packages"? *.deb?

Here is the upstream commit:
https://github.com/freeplane/freeplane/commit/a5dce7f9f

The debdiff (for stretch-security) is attached.

I am still working on the jessie update, this could take until Saturday
(sorry for the delay).

Best Regards,
-- 
Felix Natter
debian/rules!


stretch-CVE-2018-16.debdiff
Description: Binary data

Bug#894739: dh_octave_check tests installed package instead of source tree when called from debian/rules

[Sébastien Villemot]

Package: dh-octave-autopkgtest
Version: 0.3.2

On Tue, Mar 27, 2018 at 09:40:49PM +0200, Sébastien Villemot wrote:
> On Mon, Mar 26, 2018 at 07:42:09AM +0200, Rafael Laboissière wrote:
> > I messed up a little bit with the Git repo for octave-control because I did
> > my changes, uploaded version 3.1.0-1 to unstable and pushed my commits
> > without noticing that Sébastien had already done some commits. This is the
> > reason I uploaded version 3.1.0-2 also.
> 
> Sorry for having left the repo in a semi-finished state.
> 
> The reason is that I stumbled across a bug in dh_octave_check when updating 
> the
> package, and stopped there.
> 
> Essentially, dh_octave_check will check the version installed under
> /usr/share/octave/packages, if there is one, instead of the version currently
> built.
> 
> You can reproduce it easily by installing octave-control 3.0.0-5 in a chroot,
> and then built octave-control 3.1.0-2 in the same chroot. You will get a build
> failure.
> 
> The reason is that it does the addpath *before* doing "pkg load all" (two
> times, for the .m files, then the .cc).
> 
> Swapping the order of the two seems to fix the issue. However I did not test
> that it does not break the autopkgtest functionality.
> 
> Right now I don't have the time to work on a proper fix. I can open a bug
> report if you want, please let me know.

Thereby opening a bug.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Sune Vuorela]

On Tuesday, April 3, 2018 9:14:23 PM CEST Chris Lamb wrote:
> Hi Sune!
> 
> > I don't think honouring SOURCE_DATE_EPOCH is the right idea under normal
> > circumstances
> 
> Can you elaborate on what you mean by "normal circumstances"? :)

"normal circumstances" is rcc on a source file, as opposed to an autogenerated 
file.

> How about e use S_D_E if it is setup/exported, otherwise use the mtime
> of the file as before?

I think that using S_D_E only makes sense if rcc is run on an autogenerated 
file, but I do think that most rcc runs is run on existing source files.


I don't have a good idea to differentiate those.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank