Bug#909288: transition: kdepim 18.08

[Sandro Knauß]

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

KDE Pim 18.08 has updated ist API and ABI, that makes it nessasary to bump
some ABIs. Most of the packages, that needs to be rebuild are inside
KDE Pim itself so only following "external" packages are affected:

ktorrent
kio-gdrive
blogilo
kjots
zanshin
digikam
kraft
(calligraplan)

I build all rdepends and I have only two issues:
* blogilo has fallen out of KDE Pim can't be build anymore [#908869]
* calligraplan depend on the build packages, but the features that
  use KDE Pim are disabled, so no need to build them within the transition.

This transistion includes/replaces following auto detected transitions:
 auto-akonadi
 auto-kalarmcal
 auto-kcalcore
 auto-kdav
 auto-kf5-messagelib
 auto-kldap
 auto-kpimtextedit
 auto-ksmtp
 auto-libkf5eventviews
 auto-libkf5gravatar
 auto-libkf5mailcommon
 auto-libkf5pimcommon
 auto-libkgapi
 auto-syndication

These 15 transitions share nearly all rdepdens.

I don't see any blocker from my side, to wait.

hefee



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

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

Bug#909287: python-httpretty accesses the internet during the build

[Adrian Bunk]

Source: python-httpretty
Version: 0.9.5-1
Severity: serious
Tags: ftbfs

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

...
-
1) ERROR: fakesock.socket#getpeercert should return a hardcoded fake certificate

   Traceback (most recent call last):
/usr/lib/python2.7/dist-packages/nose/case.py line 197 in runTest
  self.test(*self.arg)
/usr/lib/python2.7/dist-packages/mock/mock.py line 1305 in patched
  return func(*args, **keywargs)
tests/unit/test_core.py line 201 in test_fakesock_socket_getpeercert
  socket.connect(('somewhere.com', 80))
httpretty/core.py line 404 in connect
  self.truesock.connect(self._address)
/usr/lib/python2.7/socket.py line 228 in meth
  return getattr(self._sock,name)(*args)
   gaierror: [Errno -3] Temporary failure in name resolution


-
12 tests run in 1.5 seconds. 
1 error (11 tests passed)
make[1]: *** [debian/rules:24: override_dh_auto_test] Error 1

Bug#908930: gnome-settings-daemon: new suspend-then-hibernate behaviour

[Leonardo Canducci]

Possible inconsistent behaviour: I noticed that suspend-then-hibernate
happens only with automatic suspend (i.e. after one hour). If I suspend
manually (ALT key then click on the top right menu) I get suspension to RAM
only.



2018-09-16 12:40 GMT+02:00 Simon McVittie :

> Control: tags -1 + upstream
> Control: forwarded -1 https://gitlab.gnome.org/
> GNOME/gnome-settings-daemon/issues/78
>
> On Sun, 16 Sep 2018 at 10:08:00 +0200, Leonardo Canducci wrote:
> > since a couple of days hibernation occurs after 3 hours of suspension to
> > RAM. This new behaviour (gnome 3.30 related I guess) happens without
> > changing settings and is not described in the dialogs.
>
> I opened an upstream bug for this while packaging 3.29.x; see URL above.
>
> > How do I disable suspent-then-hibernate and get back to suspend only?
>
> As far as I can tell, you can't, but disabling the swap partition
> and using a swap file (which makes systemd report that it is unable
> to hibernate) is one possible workaround.
>
> smcv
>



-- 
Leonardo Canducci

Bug#909281: Apparmor: allow access to ~/.mailcap

[Carsten Schoenert]

Hello Vincas,

one more AppArmor thing you could please have a look at.

Thanks!

Am 20.09.18 um 22:53 schrieb Anthony DeRobertis:
> Package: thunderbird
> Version: 1:60.0-3~deb9u1
> Severity: normal
> File: /etc/apparmor.d/usr.bin.thunderbird
> 
> I got these in my log:
> 
> Sep 19 20:02:42 Watt kernel: [9950821.734919] audit: type=1400 
> audit(1537401762.512:297): apparmor="DENIED" operation="open" 
> profile="thunderbird" name="/home/anthony/.mailcap" pid=9593 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> Sep 19 20:02:43 Watt kernel: [9950822.548807] audit: type=1400 
> audit(1537401763.328:298): apparmor="DENIED" operation="open" 
> profile="thunderbird" name="/home/anthony/.mailcap" pid=9593 
> comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
> 
> would make sense to allow a mail program to read ~/.mailcap (and execute
> the programs found there, no idea how that's done in apparmor)
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), 
> (130, 'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), 
> (120, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages thunderbird depends on:
> ii  debianutils   4.8.6
> ii  fontconfig2.13.0-5
> ii  libatk1.0-0   2.28.1-1
> ii  libc6 2.27-6
> ii  libcairo-gobject2 1.15.12-1
> ii  libcairo2 1.15.12-1
> ii  libdbus-1-3   1.12.10-1
> ii  libdbus-glib-1-2  0.110-3
> ii  libevent-2.0-52.0.21-stable-3
> ii  libffi6   3.2.1-8
> ii  libfontconfig12.13.0-5
> ii  libfreetype6  2.8.1-2
> ii  libgcc1   1:8.2.0-6
> ii  libgdk-pixbuf2.0-02.36.12-2
> ii  libglib2.0-0  2.56.1-2
> ii  libgtk-3-03.22.30-2
> ii  libgtk2.0-0   2.24.32-3
> ii  libjsoncpp1   1.7.4-3
> ii  libpango-1.0-01.42.4-1
> ii  libpangocairo-1.0-0   1.42.4-1
> ii  libpangoft2-1.0-0 1.42.4-1
> ii  libstartup-notification0  0.12-5
> ii  libstdc++68.2.0-6
> ii  libvpx4   1.6.1-3+deb9u1
> ii  libx11-6  2:1.6.6-1
> ii  libx11-xcb1   2:1.6.6-1
> ii  libxcb-shm0   1.13-3
> ii  libxcb1   1.13-3
> ii  libxext6  2:1.3.3-1+b2
> ii  libxrender1   1:0.9.10-1
> ii  libxt61:1.1.5-1
> ii  psmisc23.1-1+b1
> ii  x11-utils 7.7+4
> ii  zlib1g1:1.2.11.dfsg-1
> 
> Versions of packages thunderbird recommends:
> ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
> ii  lightning 1:60.0-3~deb9u1
> 
> Versions of packages thunderbird suggests:
> ii  apparmor  2.13-8
> ii  fonts-lyx 2.3.0-3
> ii  libgssapi-krb5-2  1.16-2
> 
> -- debconf information excluded

-- 
Regards
Carsten Schoenert

Bug#909272: Please provide checks for spotting wrong indentation of paragraph separator

[s3v]

o.0 superfast...

Thanks!

Bug#854643: fix for this bug

[navaneeth]

As per the instructions in the link below,

https://wiki.archlinux.org/index.php/Desktop_notifications#Libnotify

If we create "/usr/share/dbus-1/services/org.freedesktop.Notifications.service"
with the content below, this bug can be closed.

[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/lib/notification-daemon/notification-daemon

Bug#902238: lua5.3: arithemetic operations fail to give correct results if too many arrays are initialized

[Alan W. Irwin]

Thanks, Orion, for that comparison with the Fedora Lua 5.3.5 result.

Yes, that is the correct result that I also get for Debian Buster Lua-5.2.4, 
but for Debian Buster
Lua-5.3.3 I get the following:

irwin@merlin> /usr/bin/lua5.3 test.lua
nxcells[page] = 12, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00
nxcells[page] = 8, deltax = 1.00e+00
nycells[page] = 8, deltay = 1.00e+00

@Maintainer:
Please update the Debian package from 5.3.3 to 5.3.5 to see whether
that fixes the issue demonstrated by the script.

Alan


__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#908449: firefox-esr_60.2.0esr-1~deb9u2.1_i386.deb not working

[Tim Makarios]

On 18/09/18 21:45, Mike Hommey wrote:

Incidentally, since you're talking about Javascript, I thought it might be
relevant that I'm using the NoScript add-on, so I thought I'd try disabling
that (which worked), and setting javascript.options.baselinejit and
javascript.options.ion back to true. When I switched
javascript.options.baselinejit back to true, Firefox instantly crashed.
(But, of course, it's recoverable again via -safe-mode.)

Setting only javascript.options.ion back to true *doesn't* crash Firefox, or
prevent it from starting.


Can you restore all the prefs and addons you changed to what they were
before and try the following package?

https://people.debian.org/~glandium/firefox-esr_60.2.0esr-1~deb9u2.2_i386.deb
sha256: 4f092e11faf729316ea96be5b9f6ecca58ea1f001279c44406a8d505b021c17f


I re-enabled NoScript and set javascript.options.ion and 
javascript.options.baselinejit back to true; then I installed your 
latest package, and it seems to work fine!


Thanks for all your patient work on this.

Tim
<><

Bug#909223: libwxbase3.0-0v5: crash in wxFont::Create with gnuplot-qt: corrupted double-linked list

[Olly Betts]

Thanks for your bug report.

On Wed, Sep 19, 2018 at 11:47:08PM +0200, Vincent Lefevre wrote:
> gnuplot-qt crashed, see attached backtrace. I didn't get any error
> message, but the backtrace shows "corrupted double-linked list":
> 
> [...]
> #3  0x7f1f2a52ae0a in malloc_printerr (str=str@entry=0x7f1f2a62c3d6 
> "corrupted double-linked list") at malloc.c:5350
> #4  0x7f1f2a52e386 in _int_malloc (av=av@entry=0x7f1f2a663c40 
> , bytes=bytes@entry=32) at malloc.c:3926
> #5  0x7f1f2a52f7dd in __GI___libc_malloc (bytes=32) at malloc.c:3065
> #6  0x7f1f2a8ccfa8 in operator new(unsigned long) () at 
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #7  0x7f1f2c702944 in wxFont::Create(int, wxFontFamily, wxFontStyle, 
> wxFontWeight, bool, wxString const&, wxFontEncoding) 
> (this=this@entry=0x7fffe5eaf8f0, pointSize=10, 
> family=family@entry=wxFONTFAMILY_SWISS, style=style@entry=wxFONTSTYLE_NORMAL, 
> weight=weight@entry=wxFONTWEIGHT_NORMAL, underlined=underlined@entry=false, 
> face=..., encoding=wxFONTENCODING_SYSTEM) at ../src/gtk/font.cpp:304
> [...]

This is saying that glibc detected malloc heap corruption when
wxWidgets tried to allocate memory.  However that doesn't tell us
anything about what caused that corruption - it's likely due to
something writing off the end or start of an allocated block, or
writing to an block that's already been released.  That bad code
could be in wxWidgets but it could just as easily be in another
library that's in use, or in gnuplot itself.

> This is not reproducible. Perhaps a race condition or memory corruption
> that does not always produce a crash.

I'm afraid that makes it very hard for us to usefully do anything, since
we don't even know what software the bug is in.

If it's something that happens sporadically I'd suggest you try
habitually running gnuplot under a malloc debugger (e.g. valgrind if the
slowdown is tolerable), and hope that catches the corruption as it
happens.

Cheers,
Olly

Bug#905846: mbr FTCBFS: configures for the build architecture

[Helmut Grohne]

On Fri, Sep 21, 2018 at 01:13:24AM +0200, Santiago Garcia Mantinan wrote:
> When including the patch I found that you are removing this part of the
> Makefile:
> -ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
> -  INSTALL_PROGRAM += -s
> -endif
> 
> Which ends up with unstripped binaries, which make lintian unhappy, is there
> any reason to remove the strip flag there?

I'm sorry for not properly checking this. You are absolutely correct
that it is not that simple.

My changelog entry hints the intention: Defer stripping to dh_strip.
Unfortunately, I failed to notice that mbr does not call dh_strip, so in
effect no stripping is performed. Is there a reason for not calling
dh_strip?

Now you also asked why the -s flag needed to be removed. strip is an
architecture-dependent tool. If you run "strip" on a binary of a
different architecture, it loudly fails. Like the compiler, you must
call ${DEB_HOST_GNU_TYPE}-strip for this to work in a cross compilation
setting. The install program however just uses plain strip when given
the -s option. If you insist on not calling dh_strip (which would also
take care of generating a -dbgsym package), the way to fix this is:

INSTALL_PROGRAM += --strip-program=${DEB_HOST_GNU_TYPE}-strip

In my original patch, I considered this complexity not worth the effort
when dh_strip does the right thing.

Thank you for not blindly applying my patch but reviewing/testing it
instead.

Helmut

Bug#909286: firefox: "The bookmarks and history system will not be functional" message always

[Timur Sviridov]

Package: firefox
Version: 62.0-1
Severity: grave
Tags: newcomer
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
Upgraded firefox:amd64 (61.0.1-1, 62.0-1)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Start Firefox.

   * What was the outcome of this action?
The "The bookmarks and history system will not be functional" message is
displayed and history is not available.

   * What outcome did you expect instead?
No errors?.


Attempted the suggested troubleshooting steps:
 - Restart machine.
 - Move places.sqlite away so that FF creates a new one.
 - Create a new profile.

The error remained after each of those steps.


The solution:

Even though firefox does not appear to link to sqlite (ldd showed no link to
it), the solution was to upgrade sqlite:

Upgrade: libsqlite3-0:amd64 (3.16.2-5+deb9u1, 3.24.0-1), sqlite3:amd64
(3.16.2-5+deb9u1, 3.24.0-1)



-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (800, 'testing'), (700, 
'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firefox depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-6
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.39-1
ii  libpango-1.0-01.40.5-1
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3+deb9u1
ii  zlib1g1:1.2.11.dfsg-1

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

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libgtk2.0-02.24.31-2

-- no debconf information

Bug#864827: Please go ahead adding explanations to the wiki

[Benda Xu]

Hi Stefan,

> This bug basically makes the package unusable.  

Unfortunately that's true.

> I understand that adapting the packaging to the new structure of
> Zotero-5 will take some time, but in the mean time, could someone add
> a page to the Debian wiki outlining how to install Zotero-5 by hand on
> a Debian system

You are more than welcomed to do so.  Everyone can contribute to the
Debian wiki.

Yours,
Benda

Bug#902238: lua 5.3

[Orion Poplawski]

FWIW - On Fedora Rawhide:

Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio


# lua ./test.lua
nxcells[page] = 12, deltax = 8.33e-02
nycells[page] = 8, deltay = 1.25e-01
nxcells[page] = 8, deltax = 1.25e-01
nycells[page] = 8, deltay = 1.25e-01
nxcells[page] = 8, deltax = 1.25e-01
nycells[page] = 8, deltay = 1.25e-01
nxcells[page] = 8, deltax = 1.25e-01
nycells[page] = 8, deltay = 1.25e-01
nxcells[page] = 8, deltax = 1.25e-01
nycells[page] = 8, deltay = 1.25e-01
nxcells[page] = 8, deltax = 1.25e-01
nycells[page] = 8, deltay = 1.25e-01
nxcells[page] = 8, deltax = 1.25e-01
nycells[page] = 8, deltay = 1.25e-01
nxcells[page] = 8, deltax = 1.25e-01
nycells[page] = 8, deltay = 1.25e-01

Not sure if this is the correct output or not.

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/

Bug#909285: [freshplayerplugin] update to the latest version

[Alex Volkov]

Package: freshplayerplugin
Severity: wishlist

--- Please enter the report below this line. ---

The version 0.3.9 fixing the single reported bug is out almost a year ago, is 
the maintainer doing any job at all?


--- System information. ---
Architecture: 
Kernel:   Linux 4.17.17-bootes0-iommu-p-1000

Debian Release: 9.5
  990 stretch-backports ftp.debian.org 
  990 stable  security.debian.org 
  990 stable  ftp.fi.debian.org 
  500 stable  dl.google.com 
  500 stable  deb.torproject.org 
  500 newstable   deb.i2p2.no 
  101 stable-backports www.deb-multimedia.org 
  101 stable  www.deb-multimedia.org 
  100 testing ftp.fi.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#909284: minidlna: Minidlna needs libavcodec.so.57 which is not a dependancy

[Dean]

Package: minidlna
Version: 1.2.1+dfsg-1+b1
Severity: important

Dear Maintainer,

* What led up to the situation?
I think i may have removed libavcodec57 at some point.
Now when i start the service It starts with the following in the journal:
/usr/sbin/minidlnad: error while loading shared libraries:
libavcodec.so.57: cannot open shared object file: No such file or directory
raspberrypi systemd[1]: minidlna.service: About to execute:
/etc/init.d/minidlna start
raspberrypi systemd[1]: minidlna.service: Forked /etc/init.d/minidlna as
5123
raspberrypi systemd[1]: minidlna.service: Changed dead -> start
raspberrypi systemd[1]: Starting LSB: minidlna server...
raspberrypi systemd[5123]: minidlna.service: Executing:
/etc/init.d/minidlna start
raspberrypi systemd[1]: minidlna.service: Child 5123 belongs to
minidlna.service.
raspberrypi systemd[1]: minidlna.service: Control process exited,
code=exited status=0
raspberrypi systemd[1]: minidlna.service: Got final SIGCHLD for state start.
raspberrypi systemd[1]: minidlna.service: Changed start -> exited
raspberrypi systemd[1]: minidlna.service: Job minidlna.service/start
finished, result=done
raspberrypi systemd[1]: Started LSB: minidlna server.
raspberrypi systemd[1]: minidlna.service: Failed to send unit change
signal for minidlna.service: Connection reset by peer
* What exactly did you do (or not do) that was effective (or ineffective)?
I first tried linking libavcodec58 to 57 but then it looks for version
57 of the rest of its libraries
I then tried to link each of the successive so's it complained about
(libavformat, libavutils, ...) with no avail
I then tried to install libavcodec57 but it is no longer in the repo
* What was the outcome of this action?
ln -s /usr/lib/arm-linux-gnueabihf/libavcodec.so.58.18.100
/usr/lib/arm-linux-gnueabihf/libavcodec.so.57
systemctl start minidlna:
/usr/sbin/minidlnad: /usr/lib/arm-linux-gnueabihf/libavcodec.so.58: version
`LIBAVCODEC_57' not found (required by
/usr/lib/arm-linux-gnueabihf/libchromaprint.so.1)
* What outcome did you expect instead?
I was hoping minidlna would work with libav* version 58

-- System Information:
Distributor ID: Raspbian
Description: Raspbian GNU/Linux testing (buster)
Release: testing
Codename: buster
Architecture: armv7l

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

Versions of packages minidlna depends on:
ii adduser 3.117
ii libavformat58 7:4.0.2-1+b2
ii libavutil56 7:4.0.2-1+b2
ii libc6 2.27-6+rpi1
ii libexif12 0.6.21-5
ii libflac8 1.3.2-3
ii libid3tag0 0.15.1b-13
ii libjpeg62-turbo 1:1.5.2-2+b1
ii libogg0 1.3.2-1
ii libsqlite3-0 3.24.0-1
ii libvorbis0a 1.3.6-1
ii lsb-base 9.20170808+rpi1

minidlna recommends no packages.

minidlna suggests no packages.

-- Configuration Files:
/etc/minidlna.conf changed:
media_dir=V,/mnt/media/Movies
media_dir=V,/mnt/media/Kids
merge_media_dirs=no
db_dir=/var/cache/minidlna
log_dir=/var/log
root_container=V
network_interface=eth0
port=8200
friendly_name="redacted"
inotify=yes
album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg
album_art_names=AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg
album_art_names=Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg


-- no debconf information

Bug#909267: library-not-linked-against-libc: downgrade from error

[Russ Allbery]

Jeremy Bicha  writes:
> On Thu, Sep 20, 2018 at 6:18 PM Russ Allbery  wrote:

>> Maybe exclude shared libraries linked with glib (and whatever the Qt
>> equivalent is)?

> One package that triggers this tag a lot is samba and it doesn't use
> glib or qt.

> https://lintian.debian.org/maintainer/pkg-samba-ma...@lists.alioth.debian.org.html#samba

I wonder if we would get all of the utility out of the tag if instead it
looked for shared libraries with no NEEDED metadata.  I think it's only
catching libraries that aren't linked with anything else, so maybe just
check for that explicitly?

-- 
Russ Allbery (r...@debian.org)   

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

On Fri, 2018-09-21 at 01:13:31 +0200, Guillem Jover wrote:
> Hi!
> 
> On Wed, 2018-09-19 at 00:31:26 +0800, Yangfl wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Yangfl 
> > 
> > * Package name: libmd5-rfc
> >   Version : 0.0+20020413
> >   Upstream Author : Aladdin Enterprises
> > * URL : https://sourceforge.net/projects/libmd5-rfc/
> > * License : zlib
> >   Programming Lang: C
> >   Description : RFC1321-based (RSA-free) MD5 library
> >  This is a very small C library implementing RFC1321, the MD5 message digest
> >  function. Unlike the existing W3C libmd5, it was written from the
> >  specifications (not the sample code) in RFC1321, and therefore is not 
> > required
> >  to acknowledge RSA in any way.
> 
> There's already libmd in the archive which contains an RSA-free MD5
> implementation. I see the interface is not exactly the same, but I
> think a handful of macros would easily take care of that, and I'd be
> happy to include those in libmd's md5.h.
> 
> Also the current package provides /usr/include/md5.h which will
> conflict with libmd-dev.

Something like the attached patch would do I guess? I'm not sure if
I'd want to expose those unconditionally, as that might pollute the
namespace.

Thanks,
Guillem
diff --git i/include/md5.h w/include/md5.h
index dee2bf4..72912b5 100644
--- i/include/md5.h
+++ w/include/md5.h
@@ -47,4 +47,17 @@ char	*MD5Data(const uint8_t *, size_t, char *);
 }
 #endif
 
+/*
+ * Interface compatibility with Aladdin Enterprises independent
+ * implemntation from RFC 1321.
+ */
+
+typedef uint8_t md5_byte_t;
+typedef uint32_t md5_word_t;
+typedef MD5_CTX md5_state_t;
+
+#define md5_init(pms) MD5Init(pms)
+#define md5_append(pms, data, nbytes) MD5Update(pms, data, nbytes)
+#define md5_finish(pms, digest) MD5End(pms, digest)
+
 #endif /* _MD5_H_ */
diff --git i/test/md5.c w/test/md5.c
index 5dac6e1..2bf6cb4 100644
--- i/test/md5.c
+++ w/test/md5.c
@@ -34,8 +34,20 @@ void
 test_md5(const char *digest, const char *string)
 {
 	char result[MD5_DIGEST_STRING_LENGTH];
+	MD5_CTX ctx;
+	md5_state_t pms;
 
 	assert(strcmp(digest, MD5Data(string, strlen(string), result)) == 0);
+
+	MD5Init(&ctx);
+	MD5Update(&ctx, string, strlen(string));
+	MD5End(&ctx, result);
+	assert(strcmp(digest, result) == 0);
+
+	md5_init(&pms);
+	md5_append(&pms, string, strlen(string));
+	md5_finish(&pms, result);
+	assert(strcmp(digest, result) == 0);
 }
 
 int

Bug#905846: mbr FTCBFS: configures for the build architecture

[Santiago Garcia Mantinan]

> I'm getting a new version ready which will include this patch.

When including the patch I found that you are removing this part of the
Makefile:
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-  INSTALL_PROGRAM += -s
-endif

Which ends up with unstripped binaries, which make lintian unhappy, is there
any reason to remove the strip flag there?

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

Bug#909116: ITP: libmd5-rfc -- RFC1321-based (RSA-free) MD5 library

[Guillem Jover]

Hi!

On Wed, 2018-09-19 at 00:31:26 +0800, Yangfl wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Yangfl 
> 
> * Package name: libmd5-rfc
>   Version : 0.0+20020413
>   Upstream Author : Aladdin Enterprises
> * URL : https://sourceforge.net/projects/libmd5-rfc/
> * License : zlib
>   Programming Lang: C
>   Description : RFC1321-based (RSA-free) MD5 library
>  This is a very small C library implementing RFC1321, the MD5 message digest
>  function. Unlike the existing W3C libmd5, it was written from the
>  specifications (not the sample code) in RFC1321, and therefore is not 
> required
>  to acknowledge RSA in any way.

There's already libmd in the archive which contains an RSA-free MD5
implementation. I see the interface is not exactly the same, but I
think a handful of macros would easily take care of that, and I'd be
happy to include those in libmd's md5.h.

Also the current package provides /usr/include/md5.h which will
conflict with libmd-dev.

Thanks,
Guillem

Bug#909283: dokuwiki: Dependency on php-phpseclib to weak, also fulfilled by php-seclib which doesn't suffice

[Axel Beckert]

Package: dokuwiki
Version: 0.0.20180422.a-1
Severity: serious
Justification: missing (not strict enough) dependency 

dokuwiki depends unversioned on php-phpseclib which can currently be
fulfilled by either php-phpseclib/2.0.11-1 or by php-seclib/1.0.11-1
(which provides php-phpseclib).

But if only php-seclib/1.0.11-1 is installed, the webserver returns a
500 for dokuwiki with these messages in the error.log:

[Fri Sep 21 00:54:00.639686 2018] [php7:warn] [pid 2332] [client 
127.0.0.1:48614] PHP Warning:  require(/usr/share/php/phpseclib/bootstrap.php): 
failed to open stream: No such file or directory in 
/usr/share/dokuwiki/vendor/composer/autoload_real.php on line 66
[Fri Sep 21 00:54:00.639724 2018] [php7:error] [pid 2332] [client 
127.0.0.1:48614] PHP Fatal error:  require(): Failed opening required 
'/usr/share/php/phpseclib/bootstrap.php' (include_path='.:/usr/share/php') in 
/usr/share/dokuwiki/vendor/composer/autoload_real.php on line 66

The file /usr/share/php/phpseclib/bootstrap.php is only in
php-phpseclib.

As far as I can see this can be solved by depending versioned on
php-phpseclib, e.g. on "php-phpseclib (>= 2)".

(System information below is from after I've replaced php-seclib with
php-phpseclib.)

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (300, 'unstable'), 
(299, 'unstable-debug'), (210, 'experimental'), (209, 'experimental-debug'), 
(110, 'buildd-unstable'), (105, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dokuwiki depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  javascript-common  11
ii  libjs-jquery   3.2.1-1
ii  libjs-jquery-cookie12-1
ii  libjs-jquery-ui1.12.1+dfsg-5
ii  libphp-simplepie   1.3.1+dfsg-3.1
ii  php1:7.2+62
ii  php-geshi  1.0.8.11-3
ii  php-phpseclib  2.0.11-1
ii  php-random-compat  2.0.17-1
ii  php-xml1:7.2+62
ii  php7.2 [php]   7.2.9-1
ii  php7.2-xml [php-xml]   7.2.9-1
ii  ucf3.0038

Versions of packages dokuwiki recommends:
ii  imagemagick   8:6.9.10.8+dfsg-1
ii  imagemagick-6.q16 [imagemagick]   8:6.9.10.8+dfsg-1
ii  php-gd1:7.2+62
pn  php-ldap | php-mysql | php-pgsql  
ii  php7.2-cli [php-cli]  7.2.9-1
ii  php7.2-gd [php-gd]7.2.9-1
ii  wget  1.19.5-1

Versions of packages dokuwiki suggests:
ii  libapache2-mod-xsendfile  0.12-2

-- debconf information:
* dokuwiki/wiki/policy: public
* dokuwiki/wiki/superuser: admin
* dokuwiki/system/purgepages: false
* dokuwiki/wiki/title: Swiss Mechanical Keyboard Enthusiasts Community
* dokuwiki/system/restart-webserver: false
  dokuwiki/system/localnet: 10.0.0.0/24
* dokuwiki/wiki/fullname: DokuWiki Administrator
* dokuwiki/system/accessible: global
* dokuwiki/system/documentroot: /dokuwiki
* dokuwiki/wiki/email: abe+dokuwiki-some...@deuxchevaux.org
* dokuwiki/wiki/license: cc-by-sa
* dokuwiki/system/configure-webserver: apache2
* dokuwiki/system/writeplugins: false
* dokuwiki/wiki/acl: true
* dokuwiki/system/writeconf: true
  dokuwiki/wiki/failpass:

Bug#905846: mbr FTCBFS: configures for the build architecture

[Santiago Garcia Mantinan]

Hi!

I'm getting a new version ready which will include this patch.

Thanks for reporting the bug and a lot for the patch ;-)
-- 
Manty/BestiaTester -> http://manty.net

Bug#909267: library-not-linked-against-libc: downgrade from error

[Jeremy Bicha]

On Thu, Sep 20, 2018 at 6:18 PM Russ Allbery  wrote:
> Maybe exclude shared libraries linked with glib (and whatever the Qt
> equivalent is)?

One package that triggers this tag a lot is samba and it doesn't use glib or qt.

https://lintian.debian.org/maintainer/pkg-samba-ma...@lists.alioth.debian.org.html#samba

Thanks,
Jeremy Bicha

Bug#909126: ompl-plannerarena: missing Breaks+Replaces: ompl-demos (<< 1.4)

[Andreas Beckmann]

Followup-For: Bug #909126
Control: found -1 1.4.0+ds1-2

You used a creative syntax in e830506, but that doesn't work. You will
have to split in two lines. The tools will have emitted warnings about
the unknown field...


Andreas

Bug#875180: [scribus] Future Qt4 removal from Buster

[gregor herrmann]

On Mon, 09 Apr 2018 12:42:10 +0200, intrigeri wrote:

> Mattia Rizzolo:
> > It's already in experimental, under the name of 'scribus-ng'
> Thanks! It triggers sweet memories from the 1.3.x days :)

Heh :)

So, scribus-ng depends on libopenscenegraph100v5 which depends on --
tata! -- libqt4-opengl, libqtcore4, libqtgui4.

Close but not exactly qt4-free ...

Ah, there's #875075 ...

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Bob Dylan: Masters of War


signature.asc
Description: Digital Signature

Bug#909282: Eeschema triggers wx assertion when adding text to schematic

[Seth Hillbrand]

Package: kicad
Version: 5.0.0+dfsg1-2~bpo9+1
Severity: normal

Dear Maintainer,

Eeschema triggers an assertion.  Steps:

1) Run kicad
2) Start new project
3) Open Eeschema
4) Insert text
5) The following assertion is displayed:

ASSERT INFO:
../src/common/sizer.cpp(1961): assert "!IsRowGrowable( idx )" failed in
AddGrowableRow(): AddGrowableRow() called for growable row

BACKTRACE:
[1] wxFlexGridSizer::AddGrowableRow(unsigned long, int)
[2] wxDialog::Show(bool)
[3] wxDialog::ShowModal()
[4] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&,
wxEvent&) const
[5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&)
[6] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[7] wxEvtHandler::TryHereOnly(wxEvent&)
[8] wxEvtHandler::ProcessEventLocally(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[11] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[12] g_closure_invoke
[13] g_signal_emit_valist
[14] g_signal_emit
[15] gtk_propagate_event
[16] gtk_main_do_event
[17] g_main_context_dispatch
[18] g_main_loop_run
[19] gtk_main
[20] wxGUIEventLoop::DoRun()
[21] wxEventLoopBase::Run()
[22] wxAppConsoleBase::MainLoop()
[23] wxEntry(int&, wchar_t**)
[24] __libc_start_main
[25] _start


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

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

Versions of packages kicad depends on:
ii  libc6 2.24-11+deb9u3
ii  libcairo2 1.14.8-1
ii  libcurl3  7.52.1-5+deb9u7
ii  libfreeimage3 3.17.0+ds1-5
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglew2.02.0.0-3+b1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgomp1  6.3.0-18+deb9u1
ii  liboce-foundation10   0.17.2-2
ii  liboce-modeling10 0.17.2-2
ii  liboce-ocaf-lite100.17.2-2
ii  liboce-ocaf10 0.17.2-2
ii  liboce-visualization100.17.2-2
ii  libpixman-1-0 0.34.0-1
ii  libpython2.7  2.7.13-2+deb9u2
ii  libssl1.1 1.1.0f-3+deb9u2
ii  libstdc++66.3.0-18+deb9u1
ii  libwxbase3.0-0v5  3.0.2+dfsg-4
ii  libwxgtk3.0-0v5   3.0.2+dfsg-4
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  python2.7.13-2
ii  python-wxgtk3.0   3.0.2.0+dfsg-4

Versions of packages kicad recommends:
ii  kicad-demos  5.0.0+dfsg1-2~bpo9+1
ii  kicad-libraries  5.0.0+dfsg1-2~bpo9+1
ii  xsltproc 1.1.29-2.1

Versions of packages kicad suggests:
pn  extra-xdg-menus

pn  kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-doc-es | kicad-d

pn  kicad-packages3d
 

-- no debconf information

Bug#909267: library-not-linked-against-libc: downgrade from error

[Russ Allbery]

Chris Lamb  writes:

> Dear Simon et al.,

>> Was the goal of this tag to tell the difference between libraries that
>> are linked to their dependencies, and libraries that aren't, like the
>> difference between these?
>> 
>> $ gcc -shared -Wl,-soname,libbad.so.0 -olibbad.so.0 libhello.c `pkg-
>> config --cflags glib-2.0`
>> $ gcc -shared -Wl,-soname,libgood.so.0 -olibgood.so.0 libhello.c `pkg-
>> config --cflags --libs glib-2.0`

> I'm afraid I simply don't know and alas am simply not well-versed
> enough in shared library foo to make any kind of judgement or even
> comment; just playing the "triager" role. Can another lintian developer
> chime in here?

My recollection is that Simon is correct and we added this tag to try to
find shared libraries that weren't linked to any of their dependencies.
At the time, we made the assumption that nearly every shared library would
use *something* from libc and thus have to be linked to it.

> Random thought; if this just affects "gnome packages", can we just skip
> those? (If so, how?)

Maybe exclude shared libraries linked with glib (and whatever the Qt
equivalent is)?  I think it's still true that nearly every library is
going to require *some* implementation of basic string handling, memory
management, etc.; it's just that for a lot of GNOME stuff all of that is
done by glib wrappers instead of directly by libc, and presumably
something similar for Qt.

It's also possible that subsequent tooling changes have made the original
problem less likely and we don't need this tag at all.  The tag is
detecting something that's not technically wrong -- there's no reason why
a shared library needs to be linked to anything at all.  It's just
assuming the NEEDED metadata is erroneously missing even though the
library has undefined symbols, as opposed to a shared library that really
doesn't need other libraries.

-- 
Russ Allbery (r...@debian.org)   

Bug#909272: Please provide checks for spotting wrong indentation of paragraph separator

[Chris Lamb]

tags 909272 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/3a3999f888268508c49b1533e1eead320de0e32a

  checks/description.pm| 2 +-
  debian/changelog | 3 +++
  t/tests/description-general/debian/debian/control.in | 8 
  t/tests/description-general/tags | 1 +
  4 files changed, 13 insertions(+), 1 deletion(-)


Regards,

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

Bug#909270: lintian: missing-explanation-for-repacked-upstream-tarball check should look in Source:

[Chris Lamb]

tags 909270 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/6f3fd4d88f88e0994da1c3c06e60419aef9d45ab

  checks/source-copyright.pm | 2 +-
  debian/changelog   | 3 +++
  2 files changed, 4 insertions(+), 1 deletion(-)


Regards,

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

Bug#909267: library-not-linked-against-libc: downgrade from error

[Chris Lamb]

Dear Simon et al.,

> Was the goal of this tag to tell the difference between libraries that
> are linked to their dependencies, and libraries that aren't, like the
> difference between these?
> 
> $ gcc -shared -Wl,-soname,libbad.so.0 -olibbad.so.0 libhello.c `pkg-
> config --cflags glib-2.0`
> $ gcc -shared -Wl,-soname,libgood.so.0 -olibgood.so.0 libhello.c `pkg-
> config --cflags --libs glib-2.0`

I'm afraid I simply don't know and alas am simply not well-versed
enough in shared library foo to make any kind of judgement or even
comment; just playing the "triager" role. Can another lintian developer
chime in here?

Random thought; if this just affects "gnome packages", can we just skip
those? (If so, how?)

> One way to detect this problem if your libraries are native and you don't
> mind arbitrary code execution is to dlopen() them and see what happens

Quoting for posterity. *grin*


Regards,

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

Bug#875058: notification of mumble 1.3.x snapshot upload to experimental

[Chris Knadle]

Notifying this bug that Mumble 1.3.0~2868~g44b9004+dfsg-1 has been uploaded to
Debian Experimental.  (See #874683)

I'm leaving this bug open because this bug is specifically about uplcoming Qt4
removal.

  -- Chris

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

Bug#909239: lintian: ancient-python-version-field is wrong

[Chris Lamb]

Hi Thomas,

> I found these warning very misleading, and IMO, they should be removed,

To clarify, by "these warnings" you mean the one emitted by py{,3}versions and 
not the Lintian warnings?

> Now, why exactly is your autopkgtests failing? This isn't clear at all
> in your bug report.

Without the "allow-stderr" flag, autopkgtests will fail if they emit
anything to standard error. If possible, it is best to leave this at
the default as it catches various non-fatal errors that are worth
knowing about.

(I am guessing that the py{,3} versions warning emits to this output
stream and thus the apt (?) tests fail.)


Regards,

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

Bug#909281: Apparmor: allow access to ~/.mailcap

[Anthony DeRobertis]

Package: thunderbird
Version: 1:60.0-3~deb9u1
Severity: normal
File: /etc/apparmor.d/usr.bin.thunderbird

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I got these in my log:

Sep 19 20:02:42 Watt kernel: [9950821.734919] audit: type=1400 
audit(1537401762.512:297): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.mailcap" pid=9593 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Sep 19 20:02:43 Watt kernel: [9950822.548807] audit: type=1400 
audit(1537401763.328:298): apparmor="DENIED" operation="open" 
profile="thunderbird" name="/home/anthony/.mailcap" pid=9593 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

would make sense to allow a mail program to read ~/.mailcap (and execute
the programs found there, no idea how that's done in apparmor)

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-6
ii  libgdk-pixbuf2.0-02.36.12-2
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-2
ii  libgtk2.0-0   2.24.32-3
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.42.4-1
ii  libpangocairo-1.0-0   1.42.4-1
ii  libpangoft2-1.0-0 1.42.4-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-6
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  lightning 1:60.0-3~deb9u1

Versions of packages thunderbird suggests:
ii  apparmor  2.13-8
ii  fonts-lyx 2.3.0-3
ii  libgssapi-krb5-2  1.16-2

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCW6QItRUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf48vwCfXLjejfEz2GoDscwP2uaSlcxE8JoA
n0MMCFh2G4kIMxfwW3w8iSOGmGr8
=mDRk
-END PGP SIGNATURE-

Bug#909239: lintian: ancient-python-version-field is wrong

[Thomas Goirand]

On 09/20/2018 01:01 PM, Mattia Rizzolo wrote:
> Control: tag -1 moreinfo
> 
> On Thu, Sep 20, 2018 at 09:43:46AM +0200, Julian Andres Klode wrote:
>> lintian reports ancient-python-version-field for python-apt, but removing 
>> that
>> causes py{,3}versions to complain:
>>
>> pyversions: missing X(S)-Python-Version in control file, fall back to 
>> debian/pyversions
>> pyversions: missing debian/pyversions file, fall back to supported versions
>> py3versions: no X-Python3-Version in control file, using supported versions
>>
>> hence the autopkgtests fail because of stderr, so it is not possible to 
>> remove
>> those fields as lintian suggests.
>>
>> Lintian should not tell us to remove fields that then cause warnings in build
>> tools. Or those tools should be fixed.
> 
> CCing the dh-python maintainers, as it's dh_python{2,3} that deals with
> those fields...

I found these warning very misleading, and IMO, they should be removed,
as lintian is right that we shouldn't set X(S)-Python-Version or
debian/pyversions or even X-Python3-Version unless we want to remove
support for some Python version.

Now, why exactly is your autopkgtests failing? This isn't clear at all
in your bug report. What package, what test, etc... Could you expand on
this please?

Cheers,

Thomas Goirand (zigo)

Bug#909280: elastix: New upstream available

[Andreas Tille]

Package: elastix
Severity: wishlist

Hi,

there is a new upstream version of elastix available.  I've imported it
into Git and tried to adapt patches and d/rules but the build failed.  I
hope I did not messed up the patches too much - most patched files do
not exist any more.  May be they were moved around and you need to fetch
the diff from Git history.  I'll stop here and leave the issue for more
competent packagers.

Kind regards

   Andreas.

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

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

Versions of packages elastix depends on:
ii  libc6  2.24-11+deb9u3
ii  libgcc11:6.3.0-18+deb9u1
ii  libgomp1   6.3.0-18+deb9u1
pn  libinsighttoolkit4.10  
ii  libstdc++6 6.3.0-18+deb9u1
ii  zlib1g 1:1.2.8.dfsg-5

elastix recommends no packages.

Versions of packages elastix suggests:
pn  elastix-doc  

Bug#909267: library-not-linked-against-libc: downgrade from error

[Simon McVittie]

On Thu, 20 Sep 2018 at 17:42:30 +0100, Chris Lamb wrote:
> > "I think that tag is too high-priority tbh. In frameworks like GLib
> > and Qt it's far from unusual to do everything with higher-level
> > functions and not use libc directly at all, and -Wl,--as-needed turns
> > that into no dependency.
> 
> Before we downgrade it and/or suggest overriding, is there not a way of
> detecting such false-positives? That would be a better outcome overall,
> no?

Was the goal of this tag to tell the difference between libraries that
are linked to their dependencies, and libraries that aren't, like the
difference between these?

$ gcc -shared -Wl,-soname,libbad.so.0 -olibbad.so.0 libhello.c `pkg-config 
--cflags glib-2.0`
$ gcc -shared -Wl,-soname,libgood.so.0 -olibgood.so.0 libhello.c `pkg-config 
--cflags --libs glib-2.0`

(where libhello.c[1] calls a GLib function, in this example)

I'm not sure how effective this tag actually is in detecting libraries not
being linked to their dependencies, because both libraries above end up
with a DT_NEEDED tag for libc.so.6 anyway (unless I use -Wl,--as-needed,
which is what's causing GNOME to trigger this tag so often).

One way to detect this problem if your libraries are native and you don't
mind arbitrary code execution is to dlopen() them and see what happens,
but I assume that isn't acceptable for Lintian.

Another is to link a trivial program[2] to the library with -Wl,-z,defs
(and without -Wl,--as-needed):

$ gcc -Wl,-z,defs -ohello hello.c libgood.so.0; echo $?
0
$ gcc -Wl,-z,defs -ohello hello.c libbad.so.0; echo $?
/usr/bin/ld: libbad.so.0: undefined reference to `g_print'
1

but again that probably isn't acceptable for Lintian, because it needs
a linker of the same architecture as the library.

Checking that the library has at least one DT_NEEDED tag
(objdump -Tx libgood.so.0 | grep NEEDED is a crude version of this)
is probably as good as checking for libc specifically? But that's still
not very good - it would fail to detect my libbad.so.0 above, and so would
current Lintian.

Regards,
smcv

[1]
#include 

void
hello (void)
{
  g_print ("hello");
}

[2]
int
main (void)
{
  return 0;
}

Bug#909279: [epiphany-browser] BUG: In pixman_region32_init_rect: Invalid rectangle passed

[kardan]

Package: epiphany-browser
Version: 3.28.3.1-1
Severity: normal

--- Please enter the report below this line. ---

Found this is my log running epiphany-browser started by claws-mail:

(epiphany:29153): Gtk-WARNING **: 18:21:25.225: gtk_widget_size_allocate(): 
attempt to allocate widget with width -42 and height 46 
  
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

1   0xb3ae3d70 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x20) 
[0xb3ae3d70]
2   0xb44c780f /usr/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37(+0x5fd80f) 
[0xb44c780f]
3   0xb44c83b9 /usr/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37(+0x5fe3b9) 
[0xb44c83b9]
4   0xb44c85d7 /usr/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37(+0x5fe5d7) 
[0xb44c85d7]
5   0xb7b20a51 /usr/lib/i386-linux-gnu/libgio-2.0.so.0(+0x74a51) [0xb7b20a51]
6   0xb7cdad94 
/usr/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x154) 
[0xb7cdad94]
   
7   0xb7cdb1a9 /usr/lib/i386-linux-gnu/libglib-2.0.so.0(+0x491a9) [0xb7cdb1a9]
8   0xb7cdb559 /usr/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xf9) 
[0xb7cdb559]
9   0xb3b2bcc1 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3WTF7RunLoop3runEv+0x161)
 [0xb3b2bcc1]   

10  0xb3b2a74d 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(+0xb1774d) [0xb3b2a74d]
11  0xb3aff4a8 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3WTF6Thread10entryPointEPNS0_16NewThreadContextE+0x68)
 [0xb3aff4a8]  
12  0xb3b298d8 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(+0xb168d8) [0xb3b298d8]
13  0xb2a76f36 /lib/i386-linux-gnu/libpthread.so.0(+0x6f36) [0xb2a76f36]
14  0xb6fc3246 /lib/i386-linux-gnu/libc.so.6(clone+0x66) [0xb6fc3246]

Let me know if you need more info!

--- System information. ---
Architecture: 
Kernel:   Linux 4.17.0-3-686

Debian Release: buster/sid
  500 tor-nightly-master-buster sdscoq7snqtznauu.onion 
  500 testing-debug   ktqxbqrhg5ai2c7f.onion 
  500 testing vwakviie2ienjx6t.onion 
  500 testing sdscoq7snqtznauu.onion 

--- Package information. ---
Depends   (Version) | Installed
===-+-
epiphany-browser-data   (>= 3.28.3.1-1) | 3.28.3.1-1
libc6  (>= 2.7) | 2.27-6
libcairo2(>= 1.2.4) | 1.15.12-1
libgcr-base-3-1  (>= 3.8.0) | 3.28.0-1
libgcr-ui-3-1(>= 3.8.0) | 3.28.0-1
libgdk-pixbuf2.0-0  (>= 2.25.2) | 2.36.12-2
libglib2.0-0(>= 2.52.0) | 2.56.1-2
libgmp10| 2:6.1.2+dfsg-3
libgtk-3-0 (>= 3.22.13) | 3.22.30-2
libhogweed4   (>= 3.2~) | 3.4-1
libicu60   (>= 60.1-1~) | 60.2-6
libjavascriptcoregtk-4.0-18 | 2.20.5-1
libjson-glib-1.0-0   (>= 1.2.0) | 1.4.2-4
libnettle6(>= 3.4~) | 3.4-1
libnotify4   (>= 0.7.0) | 0.7.7-3
libpango-1.0-0  (>= 1.37.5) | 1.42.4-1
libsecret-1-0 (>= 0.18) | 0.18.6-2
libsoup2.4-1   (>= 2.41.90) | 2.64.0-2
libsqlite3-0 (>= 3.5.9) | 3.24.0-1
libwebkit2gtk-4.0-37(>= 2.19.2) | 2.20.5-1
libxml2  (>= 2.7.4) | 2.9.4+dfsg1-7+b1
default-dbus-session-bus| 
 OR dbus-session-bus| 
iso-codes   | 4.1-1
gsettings-desktop-schemas   | 3.28.0-1


Recommends (Version) | Installed
-+-===
yelp | 3.30.0-1
evince   | 3.30.0-2
browser-plugin-evince| 3.28.2-1
ca-certificates  | 20180409
libwebkit2gtk-4.0-37-gtk2| 2.20.5-1


Package's Suggests field is empty.

Bug#909278: mp4v2: CVE-2018-17235

[Salvatore Bonaccorso]

Source: mp4v2
Version: 2.0.0~dfsg0-5
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for mp4v2.

CVE-2018-17235[0]:
| The function mp4v2::impl::MP4Track::FinishSdtp() in mp4track.cpp in
| libmp4v2 2.1.0 mishandles compatibleBrand while processing a crafted
| mp4 file, which leads to a heap-based buffer over-read, causing denial
| of service.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-17235
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17235
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1629451

Regards,
Salvatore

Bug#909277: mp4v2: CVE-2018-17236

[Salvatore Bonaccorso]

Source: mp4v2
Version: 2.0.0~dfsg0-5
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for mp4v2.

CVE-2018-17236[0]:
| The function MP4Free() in mp4property.cpp in libmp4v2 2.1.0 internally
| calls free() on a invalid pointer, raising a SIGABRT signal.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-17236
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17236
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1629453

Regards,
Salvatore

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Geoff Levand]

Hi Ben,

Attached are the two kernel config patches rebased to the latest v4.18.6-1
Buster kernel. 

  0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
  0002-arm64-Updates-for-ACPI-servers.patch

Do you plan to merge these?  If there is anything I can do to make
things easier for you please let me know.

-Geoff

>From 63d1232a77b667090e2dd3fff0ac7868784850e9 Mon Sep 17 00:00:00 2001
From: Geoff Levand 
Date: Thu, 20 Sep 2018 12:23:55 -0700
Subject: [PATCH 1/8] [arm64] Use default of CONFIG_ACPI_NFIT=m

Commit ed497f3cb706d0e0f63844b064d9ebbf6f33b052 (Add server and 96boards options)
added an arm64 specific CONFIG_ACPI_NFIT=y, overriding the default of =m, but the
commit message mentions nothing about why this was done.

Remove the arm64 specific setting and use the default of module build.

Cc: Riku Voipio 
Signed-off-by: Geoff Levand 
---
 debian/config/arm64/config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index d14f3ff13174..0e0bf1b05db7 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -71,7 +71,7 @@ CONFIG_ACPI_NUMA=y
 ##
 ## file: drivers/acpi/nfit/Kconfig
 ##
-CONFIG_ACPI_NFIT=y
+CONFIG_ACPI_NFIT=m
 
 ##
 ## file: drivers/android/Kconfig
-- 
2.14.1

>From b1e30cf4155b5496234da7b1072f4c246cdfc9a1 Mon Sep 17 00:00:00 2001
From: Geoff Levand 
Date: Thu, 20 Sep 2018 12:23:55 -0700
Subject: [PATCH 2/8] [arm64] Updates for ACPI servers

o Enable CONFIG_SCHED_SMT for hyperthreading processors.
o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
o Enable a number of ACPI options likely to be available on servers.
o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.

Signed-off-by: Geoff Levand 
---
 debian/config/arm64/config | 29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index 0e0bf1b05db7..1a6c6a41d6e4 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -9,6 +9,7 @@ CONFIG_ARM64_ERRATUM_834220=y
 CONFIG_ARM64_VA_BITS_48=y
 ## end choice
 CONFIG_SCHED_MC=y
+CONFIG_SCHED_SMT=y
 CONFIG_NR_CPUS=256
 CONFIG_NUMA=y
 CONFIG_SECCOMP=y
@@ -24,6 +25,7 @@ CONFIG_RANDOMIZE_BASE=y
 CONFIG_RANDOMIZE_MODULE_REGION_FULL=y
 CONFIG_ARM64_ACPI_PARKING_PROTOCOL=y
 CONFIG_COMPAT=y
+CONFIG_ARM64_LSE_ATOMICS=y
 
 ##
 ## file: arch/arm64/crypto/Kconfig
@@ -67,6 +69,21 @@ CONFIG_ARCH_XGENE=y
 ##
 CONFIG_ACPI=y
 CONFIG_ACPI_NUMA=y
+CONFIG_ACPI_PCI_SLOT=y
+CONFIG_ACPI_HED=y
+CONFIG_ACPI_BGRT=y
+CONFIG_ACPI_WATCHDOG=y
+CONFIG_ACPI_CONFIGFS=m
+
+##
+## file: drivers/acpi/apei/Kconfig
+##
+CONFIG_ACPI_APEI=y
+CONFIG_ACPI_APEI_GHES=y
+CONFIG_ACPI_APEI_PCIEAER=y
+CONFIG_ACPI_APEI_SEA=y
+CONFIG_ACPI_APEI_MEMORY_FAILURE=y
+CONFIG_ACPI_APEI_EINJ=m
 
 ##
 ## file: drivers/acpi/nfit/Kconfig
@@ -222,6 +239,12 @@ CONFIG_EXTCON_USB_GPIO=m
 ##
 CONFIG_RASPBERRYPI_FIRMWARE=y
 
+##
+## file: drivers/firmware/efi/Kconfig
+##
+CONFIG_UEFI_CPER=y
+CONFIG_UEFI_CPER_ARM=y
+
 ##
 ## file: drivers/gpio/Kconfig
 ##
@@ -1097,6 +1120,7 @@ CONFIG_VIRTIO_MMIO=m
 ## file: drivers/watchdog/Kconfig
 ##
 CONFIG_GPIO_WATCHDOG=m
+CONFIG_WDAT_WDT=m
 CONFIG_ARM_SP805_WATCHDOG=m
 CONFIG_ARM_SBSA_WATCHDOG=m
 CONFIG_DW_WATCHDOG=m
@@ -1107,11 +1131,6 @@ CONFIG_MESON_GXBB_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=m
 CONFIG_BCM2835_WDT=m
 
-##
-## file: fs/pstore/Kconfig
-##
-CONFIG_PSTORE=y
-
 ##
 ## file: mm/Kconfig
 ##
-- 
2.14.1

Bug#909276: xorg-server breaks qbzr autopkgtest: AssertionError: Timeout!

[Paul Gevers]

Source: xorg-server, qbzr
Control: found -1 xorg-server/2:1.20.1-3
Control: found -1 qbzr/0.23.2-4
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of xorg-server the autopkgtest of qbzr fails in
testing when that autopkgtest is run with the binary packages of
xorg-server from unstable. Interesting data point, with 2:1.20.1-2 from
two days ago it passed. It passes when run with only packages from
testing. In tabular form:
   passpass   fail
xorg-serverfrom testing2:1.20.1-2 2:1.20.1-3
qbzr   from testing0.23.2-4   0.23.2-4
all others from testingfrom testing   from testing

I copied some of the output at the bottom of this report. Based on
reading the xorg-server changelog, I suspect these tests are trying to
activate something on screen and now they are missing the active area:
  * xvfb-run*: Update default resolution and bitdepth to match upstream
defaults.

Currently this regression is contributing to the delay of the migration
of xorg-server to testing [1]. Due to the nature of this issue, I filed
this bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=xorg-server

https://ci.debian.net/data/autopkgtest/testing/amd64/q/qbzr/1022641/log.gz

autopkgtest [17:06:38]: test testsuite: [---
bzr selftest: /usr/bin/bzr.bzr
   /usr/lib/python2.7/dist-packages/bzrlib
   bzr-2.8.0dev1 python-2.7.15
Linux-4.9.0-8-amd64-x86_64-with-debian-buster-sid

FAIL:
bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_annotate
log: {{{
5.800  creating repository in
file:///tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_annotate/work/tree/.bzr/.
5.802  creating branch  in
file:///tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_annotate/work/tree/
5.808  trying to create missing lock
'/tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_annotate/work/tree/.bzr/checkout/dirstate'
5.808  opening working tree
'/tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_annotate/work/tree'
5.817  preparing to commit
INFO  Committing to:
/tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_annotate/work/tree/
5.819  Selecting files for commit with filter None
INFO  added a
INFO  Committed revision 1.
5.827  Committed revid
jran...@example.com-20180920170644-z734bdevt58l1foo as revno 1.
5.832  preparing to commit
INFO  Committing to:
/tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_annotate/work/tree/
5.833  Selecting files for commit with filter None
INFO  modified a
INFO  Committed revision 2.
5.843  Committed revid
jran...@example.com-20180920170644-o4mh712krncuwlcm as revno 2.
6.521  creating config directory:
'/tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_annotate/home/.bazaar'
}}}

Traceback (most recent call last):
  File
"/usr/lib/python2.7/dist-packages/bzrlib/plugins/qbzr/lib/tests/test_guidebar.py",
line 246, in setUp
self.waitUntil(lambda:self.win.throbber.isVisible() == False, 500)
  File
"/usr/lib/python2.7/dist-packages/bzrlib/plugins/qbzr/lib/tests/__init__.py",
line 95, in waitUntil
self.fail(timeout_msg or 'Timeout!')
  File "/usr/lib/python2.7/dist-packages/unittest2/case.py", line 690,
in fail
raise self.failureException(msg)
AssertionError: Timeout!

FAIL: bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_find
log: {{{
6.529  creating repository in
file:///tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_find/work/tree/.bzr/.
6.531  creating branch  in
file:///tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_find/work/tree/
6.537  trying to create missing lock
'/tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_find/work/tree/.bzr/checkout/dirstate'
6.537  opening working tree
'/tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_find/work/tree'
6.546  preparing to commit
INFO  Committing to:
/tmp/testbzr-TKOGKm.tmp/bzrlib.plugins.qbzr.lib.tests.test_guidebar.TestQAnnotate.test_find/work/tree/
6.548  Selecting files for commit with filter None
INFO  added a
INFO  Committed revision 1.
6.556  Committed revid
jran...@example.com-20180920170645-2m2g5er848h0qdn7 as revno 1.
6.561  preparing to commit
INFO  Committing to:
/

Bug#909275: xorg-server breaks onioncircuits autopkgtest: expected string, NoneType found

[Paul Gevers]

Source: xorg-server, onioncircuits
Control: found -1 xorg-server/2:1.20.1-3
Control: found -1 onioncircuits/0.5-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of xorg-server the autopkgtest of onioncircuits
fails in testing when that autopkgtest is run with the binary packages
of xorg-server from unstable. Interesting data point, with 2:1.20.1-2
from two days ago it passed. It passes when run with only packages from
testing. In tabular form:
   passpass  fail
xorg-serverfrom testing2:1.20.1-22:1.20.1-3
onioncircuits  from testing0.5-2 0.5.2
all others from testingfrom testing  from testing

I copied some of the output at the bottom of this report. Based on
reading the xorg-server changelog, I suspect these tests are trying to
activate something on screen and now they are missing the active area:
  * xvfb-run*: Update default resolution and bitdepth to match upstream
defaults.

Currently this regression is contributing to the delay of the migration
of xorg-server to testing [1]. Due to the nature of this issue, I filed
this bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=xorg-server

https://ci.debian.net/data/autopkgtest/testing/amd64/o/onioncircuits/1022616/log.gz

autopkgtest [16:47:15]: test gui-test: [---
waiting for Tor to settle...
E
==
ERROR: test_has_correct_circuits (__main__.TestOnionCircuitsGUI)
--
Traceback (most recent call last):
  File "debian/tests/check-circuits", line 70, in test_has_correct_circuits
self.assertEqual(self._get_circuits(), mycircs)
  File "debian/tests/check-circuits", line 54, in _get_circuits
circs.add(", ".join(nicks))
TypeError: sequence item 0: expected string, NoneType found

--
Ran 1 test in 1.046s

FAILED (errors=1)
autopkgtest [16:47:37]: test gui-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#909274: jansson: Please consider building jansson with -fPIC

[Jean Baptiste Favre]

Source: jansson
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Next release of trafficserver provides a plugin depending on jansson.
Currently, jansson seems to be built staticaly:

checking jansson.h usability... yes
checking jansson.h presence... yes
checking for jansson.h... yes
checking whether jansson is dynamic... no

It also doen't use -fPIC, which prevent its use with trafficserver:

libtool: link:  cc -shared  -fPIC -DPIC
experimental/uri_signing/.libs/uri_signing.o
experimental/uri_signing/.libs/config.o
experimental/uri_signing/.libs/cookie.o
experimental/uri_signing/.libs/jwt.o
experimental/uri_signing/.libs/match.o
experimental/uri_signing/.libs/parse.o
experimental/uri_signing/.libs/timing.o   -l:libjansson.a -l:libcjose.a
- -lpcre -lm -lcrypto -lbrotlienc -lpthread -ldl  -g -mcx16 -g -O2
- -fstack-protector-strong -O3 -Wl,-z -Wl,relro -Wl,-z -Wl,now
- -Wl,-soname -Wl,uri_signing.so -Wl,-version-script
- -Wl,experimental/uri_signing/.libs/uri_signing.ver -o
experimental/uri_signing/.libs/uri_signing.so
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libjansson.a(load.o):
relocation R_X86_64_PC32 against symbol `stdin@@GLIBC_2.2.5' can not be
used when making a shared object; recompile with -fPIC

Could you please consider adding this flag ?

Cheers,
Jean Baptiste Favre

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

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

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEToRbojDLTUSJBphHtN1Tas99hzcFAluj8G1fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRF
ODQ1QkEyMzBDQjRENDQ4OTA2OTg0N0I0REQ1MzZBQ0Y3RDg3MzcACgkQtN1Tas99
hzd4bA//UOg5v5iLkMMlh7kCoz6NFkkhiSXSepc96R1u2dZm6ts+IPmfRfkRZKol
qM2odh2fIEQH1d4bouGc0AipcZV2ExYnZi0dA/4bEtsIQZE5SwjjJIipLP579++6
WU9EpG32vYI3Mtt/+fRI/3roDxJ9o7dPXjEpKrTnIhARLPZynE9R+nNiBg/bfX8P
/y6wpYyAltniTcfN+aWpY3w8Oo/Sng/g3fcIk+up8hX9er7kIVGZUS2IudTyeAWn
MeGX8CPfYzx7WNc/LzU+fGwTYC/PFUiBKnxzWEhP992cVxd4CbOCDdQ5vE/ZXBDJ
zhavf5P8yoDciCsVGAuRHhk20yMB1z7Tu6G7Hth3a9BUB3vwhUtrHwPk+DPqjlj9
tshBdHANCDm+28Ocf1uEpKNlVvMMJ36DHJkEhBYl3DpPgqF1JCHVV4vsD5MrrhOm
d3EOFHGJdUE1YaBDxUIWd6j/zYMipdGcYhDf3yBJktl4cryN4gmKkZC0C9MfvEm2
lBWP7VZdB/kgQH241HpEEKrIJCJgZSM4AupAJkJghA+Yr73IPRc8aK47fri9bYyM
bdEjh0iwkagpMw72yAtJJDYu1juRZPnFBSI15ZTf8M2TOn1RQQtMLUsqRbAG2NS3
R4hoI/1bNCtavElnqs5S/cPiXkr7aysxMch90YCBuWx7qUi7H6U=
=ox8h
-END PGP SIGNATURE-

Bug#909273: nmu: ros-rosconsole_1.13.7-1

[Jochen Sprickerhof]

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

nmu ros-rosconsole_1.13.7-1 . amd64 . unstable . -m "clean rebuild"

Hi release team,

look like my build setup wasn't clean when I build this (or something
else changed while this was sitting in new). It was reported to be
broken in

https://lists.debian.org/debian-science/2018/09/msg00045.html

And I confirmed it on my local amd64 machine. I tested it on armhf
(buildd build) as well and it was working there. So I assume only amd64
is affected.

Thanks

Jochen

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

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

Bug#909208: ippusbxd: The purpose of recommending system-config-printer-udev?

[Brian Potkin]

On Thu 20 Sep 2018 at 08:44:48 +0200, Till Kamppeter wrote:

> On 19/09/18 20:07, Brian Potkin wrote:
> > When hplip is not installed, my ENVY 4500 gets set up as an IPP-over-USB
> > printer very nicely. With hplip installed, plugging the USB cable into
> > the machine before starting ippusbxd gets me a non-driverless queue. Why
> > should I want that?
> > 
> 
> This is done to assure that the scanners in HP's multi-function devices
> work. With a driverless setup the scanner would not work. This is also why
> ippusbxd recommends system-config-printer-udev.

Thanks. I probably would never have deduced that.

> In one or two years we will probably have devices with IPP driverless
> scanning though (the standard is already defined by the PWG, only there is
> no appropriate device on the market yet).

I had noticed that, although 'scanimage -L' returned a URI, 'scanimage >
image.pnm' could not open the scanner device. What extra is required on
the device before it can be marketed as "scanner-capable" with IPP-over-
USB?

> > Furthermore, the non-driverless queue is shared. It seems a little
> > unusual to provide access to the printer when the ippusbxd queue doesn't
> > specifically allow it.
> 
> It seems that CUPS shares a new printer by default and that
> system-config-printer-udev does not explicitly set them not shared.

I too think that is the case if 'cupsctl --share-printers' is set.

Regards,

Brian.

Bug#906284: lintian: check for incomplete-creative-commons-license gives false positives: the "not a law firm" is a preamble, not a license

[Chris Lamb]

tags 906284 + pending
thanks

This is now fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/b0ee727b5f3abe977e5c5f57eedecfd4486cf127


Regards,

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

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

[Andreas Tille]

Control: tags -1 upstream

Hi Bernhard,

thanks a lot for your investigation.  Emmanuel Promayon is Uploader and
Upstream and I think he will come back to you and hopefully will
implement the fix soon.

Kind regards

   Andreas.

On Thu, Sep 20, 2018 at 06:01:38PM +0200, Bernhard Übelacker wrote:
> Hello all,
> I tried to reproduce this issue.
> 
> Unfortunately I never get the "(SEGFAULT)" output for all tests,
> just "(Failed)" for most. But some do really segfault in my amd64 VM.
> 
> I think the segfaults are caused by the line "delete component;", that
> invalidates the iterator by removing its element from the components vector.
> 
> For some reason the iterator contains still the previous pointer
> and therefore we try to delete the same pointer twice.
> 
> 
> Attached patch tries to change the loop assuming that the
> deleted element will always be removed inside the delete operation.
> 
> With that patch I do not get any segfault, but still tests
> fail for some reason.
> 
> 
> Kind regards,
> Bernhard
> 
> 
> 
> 
> # Here we crash:
> 
> (gdb) bt
> #0  0x0061 in ?? ()
> #1  0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents 
> (this=this@entry=0x56d98330) at 
> ./modeling/libraries/pml/MultiComponent.cpp:50
> #2  0x7fffeb32c11f in MultiComponent::~MultiComponent 
> (this=0x56d98330, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:41
> #3  0x7fffeb32c149 in MultiComponent::~MultiComponent 
> (this=0x56d98330, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:38
> #4  0x7fffeb32ce3a in PhysicalModel::clear 
> (this=this@entry=0x55705ef0) at 
> ./modeling/libraries/pml/PhysicalModel.cpp:99
> #5  0x7fffeb32cf17 in PhysicalModel::~PhysicalModel (this=0x55705ef0, 
> __in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:68
> #6  0x7fffeb32cf59 in PhysicalModel::~PhysicalModel (this=0x55705ef0, 
> __in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:67
> #7  0x7fffeb317a3d in PMLComponent::~PMLComponent (this=0x55660a00, 
> __in_chrg=) at 
> ./modeling/components/pmlcomponent/PMLComponent.cpp:96
> #8  0x7fffeb3185a9 in PMLComponent::~PMLComponent (this=0x55660a00, 
> __in_chrg=) at 
> ./modeling/components/pmlcomponent/PMLComponent.cpp:93
> #9  0x77ec4ad7 in camitk::Application::close(camitk::Component*) () 
> at ./sdk/libraries/core/application/Application.cpp:623
> #10 0xbc5c in main () at 
> ./sdk/applications/testcomponents/main.cpp:204
> #11 0x76e99b17 in __libc_start_main (main=0xb080 , 
> argc=9, argv=0x7fffe398, init=, fini=, 
> rtld_fini=, stack_end=0x7fffe388) at 
> ../csu/libc-start.c:310
> #12 0xc35a in _start () at 
> ./sdk/applications/testcomponents/main.cpp:136
> 
> (gdb) list -
> 46
> 47  // -- deleteAllSubComponents -
> 48  void MultiComponent::deleteAllSubComponents() {
> 49  for (auto& component : components) {
> 50  delete component;
> 51  }
> 52  components.clear();
> 53  }
> 
> 
> 
> 
> # Here the pointer being deleted is removed from the components vector
> # and that way invalidating the iterator.
> 
> (gdb) bt
> #0  MultiComponent::removeSubComponent (c=0x579d70f0, 
> this=0x56d98330) at ./modeling/libraries/pml/MultiComponent.h:134
> #1  Component::removeFromParents() () at 
> ./modeling/libraries/pml/Component.cpp:60
> #2  0x7fffeb32c127 in MultiComponent::~MultiComponent 
> (this=0x579d70f0, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:44
> #3  0x7fffeb32c149 in MultiComponent::~MultiComponent 
> (this=0x579d70f0, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:38
> #4  0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents 
> (this=this@entry=0x56d98330) at 
> ./modeling/libraries/pml/MultiComponent.cpp:50
> #5  0x7fffeb32c11f in MultiComponent::~MultiComponent 
> (this=0x56d98330, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:41
> #6  0x7fffeb32c149 in MultiComponent::~MultiComponent 
> (this=0x56d98330, __in_chrg=) at 
> ./modeling/libraries/pml/MultiComponent.cpp:38
> #7  0x7fffeb32ce3a in PhysicalModel::clear 
> (this=this@entry=0x55705ef0) at 
> ./modeling/libraries/pml/PhysicalModel.cpp:99
> ...
> 
> (gdb) list modeling/libraries/pml/MultiComponent.h:134
> 129 }
> 130 inline void MultiComponent::removeSubComponent(Component* c) {
> 131 auto it = std::find(components.begin(), components.end(), c);
> 132 if (it != components.end()) {
> 133 components.erase(it);
> 134 c->removeParentMultiComponent(this);
> 135 }
> 136 }

> From 52f172e553ebddf068b8e35601da5eefd295cf3d Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
> Date: Thu, 20 Sep 2018 17:42:14 +0200
> Subject: [PATCH] Make loop safe for removal of elements.
> 
> Bug-Debian: ht

Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment

[Mike Gabriel]

Hi Ian,

On  Do 20 Sep 2018 16:45:41 CEST, Ian Jackson wrote:

Mike Gabriel writes ("Re: Bug#909192: mate-desktop-environment:  
Installing sysvinit-core removes mate-desktop-environment"):

many thanks for all this background info. I might have a potential
contract to get this solved in the loop, so, I may probably return to
it soon (or not so soon). Let's see...


Can you let us know when you will know whether this is going to
transpire ?


This is not going to be a paid project, unfortunately, as I hoped.


Also, we had an IRC conversation on #debian-devel about pam_systemd
and the dbus user service.  I think it contains a lot of useful
information particularly from smcv.  See below.

This is a transcript of #debian-devel manually edited to remove other
conversations, and also to remove unconstructive comments (of which
unfortunately there were some).


Thanks for the transcript.

I'll have this on my radar as an RC-like bug on the MATE side and take  
a look later in October / November (when back from VAC). If noone else  
has addressed it by then.


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp4bZqsibH_z.pgp
Description: Digitale PGP-Signatur

Bug#909272: Please provide checks for spotting wrong indentation of paragraph separator

[s3v]

Package: lintian
Severity: wishlist


Dear Maintainer,

 I would like to ask you to provide some checks for spotting wrong indentations
of paragraph separators into long descriptions.

E.g.

Package: python3-ghost
Description-md5: c97396987883115e33c12a7995af18f6
Description-en: webkit web client library
 Ghost.py is a scriptable web browser as Python library, based on
 WebKit. It support JavaScript and can be used e.g. for testing,
 web scraping, and automation.
  .
 This package provides the Python 3.x module.

As you see, the paragraph separator, i.e. a single dot, is wrongly indentated
(two spaces from the beginning of the line rather than only one as per Debian
Policy [1]).

Side effects:
[a] package descriptions at packages.d.o look pretty ugly [2]
[b] "misindentated" dot is not recognized by DDTP as a valid separator and
this issue leads into more work for translators since identical paragraphs
are automatically translated by the system but in this case they are not
(e.g. the sentence "This package provides the Python 3.x module." for the
package above).

Occurrences currently involved:

 $ sed -nr '/^  +\. *$/p' Translation-en | wc -l
 91
 $ sed -nr '/^  +\.$/p' Translation-en | wc -l
 91


Thanks for reading and kind regards.


[1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#description
[2] https://packages.debian.org/en/sid/ike-scan

Bug#909271: surfraw: Maintainance status

[Dmitry Bogatov]

Package: surfraw
Version: 2.2.9-1
Severity: normal

Dear uploaders, what is the status of Debian package surfraw?

Surfraw as upstream project moved on gitlab[1] and released version 2.3.0,
that resolve some of bugs. On other hand, debian package 2.2.9 was not
updated since 2013, and, since April 2018 (decommission of Alioth), have
invalid metadata, in particular, Maintainer field.

I updated package quite a bit [2]; changes are too big for NMU. Please,
consider using my work and upload surfraw-2.3.0. As I mentioned, current
Maintainer field is invalid, so I added Uploaders in CC.

If nothing will happen, I plan to make QA upload in a month or so.

[1] https://gitlab.com/Surfraw/surfraw
[2] https://salsa.debian.org/debian/surfraw

Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload

[Markus Koschany]

Hey,

just wanted to chime in here. I successfully backported the Buster
version of enigmail to Stretch by removing the versioned dependency on
gnupg. So far I haven't experienced any difficulties. Of course this
isn't a solution for the OpenPGP.js problem but at least to me it seems
that the gnupg version in Stretch works well with enigmail.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#909270: lintian: missing-explanation-for-repacked-upstream-tarball check should look in Source:

[Paul Gevers]

Package: lintian
Version: 2.5.103

Dear lintian maintainers,

According to the policy [1], the Source fields should be used:
"""If the upstream source has been modified to remove non-free parts,
that should be explained in this field."""

That is what I do in the lazarus package. However, lintian complains
with the missing-explanation-for-repacked-upstream-tarball tag, because
it isn't in the Comments or Files-Excluded field.

Paul

[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/



signature.asc
Description: OpenPGP digital signature

Bug#909269: shutter: Edit button disabled

[Christian Weiske]

Package: shutter
Version: 0.94-1
Severity: important

Dear Maintainer,

After taking a screenshot with shutter, I cannot edit the image anymore
because the edit button is greyed out.

This severely limits the usefulness of shutter, because I cannot highlight
important things in the screenshot or blur out sensitive information anymore.

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

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

Versions of packages shutter depends on:
ii  imagemagick  8:6.9.10.8+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.8+dfsg-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-copy-recursive-perl  0.44-1
ii  libfile-which-perl   1.22-1
ii  libglib-perl 3:1.327-1
ii  libgnome2-canvas-perl1.002-4+b2
ii  libgnome2-gconf-perl 1.044-6+b2
ii  libgnome2-perl   1.046-3+b2
ii  libgnome2-vfs-perl   1.082-1+b4
ii  libgnome2-wnck-perl  0.16-3+b4
ii  libgtk2-imageview-perl   0.05-2+b4
ii  libgtk2-perl 2:1.24992-1+b1
ii  libgtk2-unique-perl  0.05-3+b2
ii  libimage-magick-perl 8:6.9.10.8+dfsg-1
ii  libjson-perl 2.97001-1
ii  libjson-xs-perl  3.040-1
ii  liblocale-gettext-perl   1.07-3+b3
ii  libnet-dbus-perl 1.1.0-4+b3
ii  libnet-dropbox-api-perl  1.9-1
ii  libpath-class-perl   0.37-1
ii  libproc-processtable-perl0.55-1
ii  libproc-simple-perl  1.32-1
ii  librsvg2-common  2.40.20-3
ii  libsort-naturally-perl   1.03-2
ii  libwww-mechanize-perl1.88-1
ii  libwww-perl  6.35-2
ii  libx11-protocol-other-perl   30-1
ii  libx11-protocol-perl 0.56-7
ii  libxml-simple-perl   2.25-1
ii  procps   2:3.3.15-2
ii  xdg-utils1.1.3-1

Versions of packages shutter recommends:
pn  libgoo-canvas-perl 
pn  libgtk2-appindicator-perl  
ii  libnet-oauth-perl  0.28-3

Versions of packages shutter suggests:
pn  gnome-web-photo 
pn  libimage-exiftool-perl  
pn  libnet-dbus-glib-perl   
pn  nautilus-sendto 

-- no debconf information

Bug#909268: Scan from automatic document feeder inside the gimp

[bugrepor...@free.fr]

I add that I have noticed the same symptoms in the same configuration
(Debian Stretch Stable, via usb 2.0, same version of Xsane, same version
of the Gimp, …) excepted they were on an MP510 Canon AIO printer.

I’m here if you need more information or for test purpose.

Be well

Bug#908116: firewalld: blocks multicast dns resolution for home zone

[Sergio Villar Senin]

O Xov, 20-09-2018 ás 17:22 +0200, Michael Biebl escribiu:
> On Thu, 06 Sep 2018 11:20:41 +0200 Sergio Villar Senin
>  wrote:
> > Package: firewalld
> > Version: 0.6.1-2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > 
> >Upgrading to sid's 0.6.1-2
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> >Multicast DNS (avahi) does not work at all with the new
> > firewalld
> >release. I haven't changed the configuration and it was working
> >fine before the update. Actually downgrading to 0.4.4.5-2 makes
> > it
> >work again.
> > 
> 
> Please test again with firewalld 0.6.2-1 and Linux kernel 4.18.

Yes, it does work now!

Bug#909264: [PATCH] Fix test for need to use qemu

[Antonio Terceiro]

The output of arch-test needs to have its trailing newline removed
before comparing with the expected string.

Found this while trying to use mmdebstrap without having qemu-user
installed.
---
 mmdebstrap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mmdebstrap b/mmdebstrap
index 32881e7..d7532f4 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -956,6 +956,7 @@ sub main() {
 };
 open my $fh, '-|', 'arch-test', '-n', $nativearch // die "failed to 
fork(): $!";
 my $content = do { local $/; <$fh> };
+chomp($content);
 close $fh;
 if ($? != 0 or $content ne "$nativearch: ok") {
if (!exists $deb2qemu->{$nativearch}) {
-- 
2.19.0

Bug#909236: listadmin: resolve_redirects breaks logging

[Gunnar Wolf]

Oh, great.

I messed up when cleaning for this patch, and ended up uploading a
really-b0rken one (i.e. nasty syntax error)

Here goes the fix for the fix for the fix... :-þ
Description: Make listadmin properly follow redirects to HTTPS-using mailmans
Author: Gunnar Wolf 
Bug: https://bugs.debian.org/873287
Forwarded: No
Last-Update: 2018-09-20

Index: listadmin-2.42/listadmin.pl
===
--- listadmin-2.42.orig/listadmin.pl
+++ listadmin-2.42/listadmin.pl
@@ -643,6 +643,9 @@ sub uio_adminurl {
 sub mailman_url {
 my ($list, $pattern, $params, $action) = @_;
 
+# Calling mailman_url with $pattern often requires the redirects
+# _NOT_ to be resolved (i.e. for logging)
+my $nopattern = !( defined($pattern) or $pattern );
 my ($lp, $domain) = split ('@', $list);
 
 $pattern ||= uio_adminurl ($domain);
@@ -659,9 +662,30 @@ sub mailman_url {
 	$url .= "/$action";
 }
 $url .= "?$params" if $params;
+
+$url = resolve_redirects($url) if $nopattern;
 return $url;
 }
 
+sub resolve_redirects {
+# Test whether the URL is a redirect and, if so, replace it with
+# the destination one.
+my ($url, $resp, $req);
+$url = shift;
+$resp = $ua->get($url);
+# If the URL could not get to the requested URL, there's no point
+# in trying any further
+if (! $resp->is_success) {
+	print STDERR "Error: Fetching $url\n";
+	print STDERR $resp->status_line, "\n";
+	return undef;
+}
+
+# $req will have the final URI, even if redirects were followed.
+$req = $resp->request->uri;
+return $req;
+}
+
 # Returns a ref to a hash with all the information about pending messages
 sub get_list {
 my ($list, $config, $pw) = @_;


signature.asc
Description: PGP signature

Bug#908658: marked as done (systemd: apt-get upgrade from 239-7 to 239-8 failed)

[kochtopf]

> installed 239-9 directly from the Debian buster repository.

apt-cache policy systemd
systemd:
  Installed: 239-9
  Candidate: 239-9
  Version table:
 *** 239-9 100
 50 http://ftp.us.debian.org/debian unstable/main armhf Packages
100 /var/lib/dpkg/status
 239-8 500
500 http://mirrordirector.raspbian.org/raspbian testing/main armhf
Packages

Yes exactly. And this is working great (even if it's like a Frankenbuild
now).


> Our current guess is, that you had 238-8 installed from raspbian and
> it's the raspbian toolchain (compiler, linker, etc) which introduced
> this bug.

Yes TRUE. Im on mirrordirector.raspbian.org/raspbian testing for the
everyday stuff but
ftp.us.debian.org/debian unstable for packages they don't provide.
Again many thanks for your help.

PS: I've opened a short question over at the Raspberry forum
(https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=222508)
but nobody cared so far.

Bug#891414: enable qt5 front-end

[Alf Gaida]

Thanks. And waiting is the best thing one could do for now (fingers
crossed).



signature.asc
Description: OpenPGP digital signature

Bug#909236: listadmin: resolve_redirects breaks logging

[Gunnar Wolf]

I have patched my previous patch, logging now works (at least, works
for me)™.

I am building a package with the following fix incorporated and
reuploading (NOT going via DELAYED).

The logic for this? AFAICT, mailman_url() is only called with a value
for $pattern when it has to resolve logging. I am thus only calling
resolve_redirects when $pattern is undef or empty.
Description: Make listadmin properly follow redirects to HTTPS-using mailmans
Author: Gunnar Wolf 
Bug: https://bugs.debian.org/873287
Forwarded: No
Last-Update: 2018-09-20

Index: listadmin-2.42/listadmin.pl
===
--- listadmin-2.42.orig/listadmin.pl
+++ listadmin-2.42/listadmin.pl
@@ -643,6 +643,9 @@ sub uio_adminurl {
 sub mailman_url {
 my ($list, $pattern, $params, $action) = @_;
 
+# Calling mailman_url with $pattern often requires the redirects
+# _NOT_ to be resolved (i.e. for logging)
+my $nopattern = !( defined($pattern) or $pattern )
 my ($lp, $domain) = split ('@', $list);
 
 $pattern ||= uio_adminurl ($domain);
@@ -659,9 +662,30 @@ sub mailman_url {
 	$url .= "/$action";
 }
 $url .= "?$params" if $params;
+
+$url = resolve_redirects($url) unless $nopattern;
 return $url;
 }
 
+sub resolve_redirects {
+# Test whether the URL is a redirect and, if so, replace it with
+# the destination one.
+my ($url, $resp, $req);
+$url = shift;
+$resp = $ua->get($url);
+# If the URL could not get to the requested URL, there's no point
+# in trying any further
+if (! $resp->is_success) {
+	print STDERR "Error: Fetching $url\n";
+	print STDERR $resp->status_line, "\n";
+	return undef;
+}
+
+# $req will have the final URI, even if redirects were followed.
+$req = $resp->request->uri;
+return $req;
+}
+
 # Returns a ref to a hash with all the information about pending messages
 sub get_list {
 my ($list, $config, $pw) = @_;


signature.asc
Description: PGP signature

Bug#783485: hplip: hp-levels, hp-info don't report the PSC-2175 color cartridge levels

[Brian Potkin]

On Thu 20 Sep 2018 at 00:31:21 +0200, Francois Gouget wrote:

> On Wed, 19 Sep 2018, Brian Potkin wrote:
> [...]
> > Prodding upstream might produce a response. But I wouldn't hold my 
> > breath.
> 
> How does one prod upstream? Is upstream Launchpad or is there some other 
> place?
> 
> I actually have patches for hplip (not fixing this issue unfortunately), 
> but I don't know where to send them. I attached a couple to Launchpad 
> bugs to no effect so far.
> 
> https://github.com/fgouget/hplip/commits/fixes

The Lanchpad URL is the only contact point for upstream known to me.

-- 
Brian.

Bug#909267: library-not-linked-against-libc: downgrade from error

[Chris Lamb]

tags 909267 + moreinfo
severity 909267 wishlist
thanks

Dear Jeremy et al.,

> "I think that tag is too high-priority tbh. In frameworks like GLib
> and Qt it's far from unusual to do everything with higher-level
> functions and not use libc directly at all, and -Wl,--as-needed turns
> that into no dependency.

Before we downgrade it and/or suggest overriding, is there not a way of
detecting such false-positives? That would be a better outcome overall,
no?

(I am not well-versed enough shared library magic to know, alas.)


Regards,

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

Bug#891414: enable qt5 front-end

[Philip Rinn]

Hi Alf,

On 19.09.18 at 23:04, Alf Gaida wrote:
> QtSpell is in Debian now - so this is not a problem any longer. If you
> accept merge requests i would be able to write the missed things for Qt5
> and maintain it long term. (I'm selfish, i want gimagereader-qt5 for LXQt)

thanks, I have already everything in place for that, I saw that QtSpell entered
Debian.
I'd just want to wait until the transition of sane-backends is over (as I fear I
need to do a rebuild again) before I upload that change as the package has to go
through NEW and that might be a lengthy process.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#909268: Scan from automatic document feeder inside the gimp

[bugrepor...@free.fr]

Package: xsane
Version: 0.999-5
Severity: normal

Subject: Scan from automatic document feeder inside the gimp

Dear Maintainer,

I had a hp scanjet 3300C plugged via usb2.0.
I launched Xsane by the Gimp.
Today, I have pluggged a hp officejet g510g-m via usb2.0 in place of the
scanjet 3300c in order to use the automatic document feeder of this
officejet.

Xsane in stand-alone mode produces a image file per each scanned pages.
= proper functionning

When I launch Xsane via the Gimp (plug-in) and I select automatic
document feeder and the number of pages to scan, Xsane scans only the
first page that appears in the Gimp and next pages are not scanned.

It I select 4 pages in Xsane via the Gimp, I see «Scan... 1/4» when I
press scan but only the first page is effectively scanned.

I was thinking getting one image or layer in the Gimp per scanned page.

Thanks and be well

Severity : normal

Linux  4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64
GNU/Linux

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

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

Versions of packages xsane depends on:
ii  libc62.24-11+deb9u3
ii  libgimp2.0   2.8.18-1+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libjpeg62-turbo  1:1.5.1-2
ii  liblcms2-2   2.8-4+deb9u1
ii  libpng16-16  1.6.28-1
ii  libsane  1.0.25-4.1
ii  libtiff5 4.0.8-2+deb9u2
ii  xsane-common 0.999-5
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages xsane recommends:
ii  cups-client2.2.1-8+deb9u2
ii  firefox-esr [www-browser]  60.2.0esr-1~deb9u2
ii  w3m [www-browser]  0.5.3-34+deb9u1

Versions of packages xsane suggests:
ii  gimp  2.8.18-1+deb9u1
pn  gocr | cuneiform | tesseract-ocr | ocrad  
pn  gv
pn  hylafax-client | mgetty-fax   

-- no debconf information

Bug#909267: library-not-linked-against-libc: downgrade from error

[Jeremy Bicha]

Source: lintian
Version: 2.5.103
X-Debbugs-CC: naes...@gmail.com, s...@debian.org

We noticed that library-not-linked-against-libc is triggered for
several GNOME packages. [1]

smcv had these comments
--
"I think that tag is too high-priority tbh. In frameworks like GLib
and Qt it's far from unusual to do everything with higher-level
functions and not use libc directly at all, and -Wl,--as-needed turns
that into no dependency.

In the parts of Debian that are not GNOME the tag triggers a lot less
often, because -Wl,--as-needed seems to be mostly a GNOME meme?

if someone is upset about that tag, I think it's fine to objdump -Tx
the offending object, say 'look, it has all the DT_NEEDED it needs'
and override the tag. Bonus penguin points if you write an autopkgtest
that dlopens it to prove that it's possible, I suppose."

-
So I'm requesting that the tag be downgraded from error. Please also
downgrade the description where it claims a library to not use libc is
only theoretical and not very likely.

[1] 
https://lintian.debian.org/maintainer/pkg-gnome-maintain...@lists.alioth.debian.org.html

Thanks,
Jeremy Bicha

Bug#908658: marked as done (systemd: apt-get upgrade from 239-7 to 239-8 failed)

[biebl]

Am 14.09.18 um 14:21 schrieb Debian Bug Tracking System:
> 239-9 fixed this. All back to normal. Many thanks for whatever magic you
> guys did.

Since raspbian does not ship 239-9 yet, we suppose that you have
installed 239-9 directly from the Debian buster repository. 238-8 is
available via raspbian and get's rebuilt there.
Our current guess is, that you had 238-8 installed from raspbian and
it's the raspbian toolchain (compiler, linker, etc) which introduced
this bug.

Michael

Bug#909266: git-buildpackage: support %(version)s substitution in tarball-dir; preexport hooks

[Andreas Beckmann]

Package: git-buildpackage
Version: 0.9.10
Severity: wishlist
Tags: patch

Hi,

in https://salsa.debian.org/anbe/git-buildpackage
you can find two branches: features and fixes

In 'features' I've implemented two things:
* %(version)s substitution for tarball-dir
* preexport hooks that run before the tarballs get selected from the
  tarball-dir (the hook can so some magic to bring the tarballs into
  existence)
These are at least proof-of-concept implementations, they may lack
proper documentation etc.
In 'fixes' are some issues fixed that I noticed while doing and testing
the above ...

Luca and I have tested this a bit on the nvidia-graphics-drivers
repository (which has large blobs in the tarballs and one component
tarball per arch, for 3 supported architectures), and it seems to fit
our wishes.

(We plan to have a git-lfs backed repository to archive all the
tarballs, with one subdirectory per upstream version. Since this will
get insanely large over time, we plan to have a sparsely checked out
repository where only the upstream versions ever needed locally will be
available locally. This needs the preexport hook to run a script (or
just a special target in debian/rules) to fetch missing tarballs for the
current version.)


There is another branch 'anbe' that primarily contains the feature "use
hardlinks instead of symlinks", which maybe should get a configuration
option ... and a wishlist buf of its own.  (Since I tend to move around
stuff, absolute symlinks frequently break ... and I usually keep my
uploads for quite some time ... in an archive location.)


Andreas

Bug#909265: pyside2: FTBFS on ppc64el and maybe others

[Frédéric Bonnard]

Package: src:pyside2
Version: 5.11.0-4

--

Dear maintainer,
I saw that pyside2 fails to build on ppc64el due to a test failing.

https://buildd.debian.org/status/fetch.php?pkg=pyside2&arch=ppc64el&ver=5.11.0-4&stamp=1535454641&raw=0

I also found that the bug has been forwarded upstream :
https://bugreports.qt.io/browse/PYSIDE-765

This was version in 5.11.0-2. But in both case, the patch
update-patchelf.patch hardcodes PAGESIZE which is not 4k on ppc64el.
This was mentionned here btw :
https://bugreports.qt.io/browse/PYSIDE-740

I tried compiling pyside2 after dropping update-patchelf.patch and
pulling
https://codereview.qt-project.org/gitweb?p=pyside/pyside-setup.git;a=patch;h=0479cbd6abc8fffb9ba8b5f94de067e1670a
so that the correct PAGESIZE gets defined and it builds fine with the system 
patchelf.

Upstream 5.11.1 has the latter patch, so I guess, upgrading to the
latest 5.11.1 and removing update-patchelf.patch should be enough to get
rid of the FTBFS.

Thanks,

Regards.
F.


pgpyUYFY0c3B4.pgp
Description: PGP signature


pgpTDUfFAfwdT.pgp
Description: PGP signature

Bug#901460: libmail-java: dependency mismatch

[Emmanuel Bourg]

Control: tags -1 + wontfix
Control: close -1

Le 13/06/2018 à 17:49, raphael.jo...@free.fr a écrit :

> In unstable, libmail-java depends on libactivation-java version 1.2.0-1, 
> which includes com.sun.activation#javax.activation;1.2.0 .
> 
> However, in Maven com.sun.mail#javax.mail;1.6.1 depends on 
> javax.activation#activation;1.1 , see:
> 
> http://repo.maven.apache.org/maven2/com/sun/mail/javax.mail/1.6.1/javax.mail-1.6.1.pom
> 
> If not fixed, this will cause problems when one uses /usr/share/maven-repo 
> for dependency resolution.

In Debian the poms installed under /usr/share/maven-repo are rewritten
to point to the right dependency versions. For example the pom for
com.sun.mail:javax.mail
(/usr/share/maven-repo/com/sun/mail/javax.mail/1.6.1/javax.mail-1.6.1.pom)
declares this dependency:

  
javax.activation
activation
debian
  

The version 'debian' here stands for the latest version available (i.e.
1.2.0 currently).

So the poms in /usr/share/maven-repo are consistent and safe using.

Emmanuel Bourg

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

[Bernhard Übelacker]

Hello all,
I tried to reproduce this issue.

Unfortunately I never get the "(SEGFAULT)" output for all tests,
just "(Failed)" for most. But some do really segfault in my amd64 VM.

I think the segfaults are caused by the line "delete component;", that
invalidates the iterator by removing its element from the components vector.

For some reason the iterator contains still the previous pointer
and therefore we try to delete the same pointer twice.


Attached patch tries to change the loop assuming that the
deleted element will always be removed inside the delete operation.

With that patch I do not get any segfault, but still tests
fail for some reason.


Kind regards,
Bernhard




# Here we crash:

(gdb) bt
#0  0x0061 in ?? ()
#1  0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents 
(this=this@entry=0x56d98330) at 
./modeling/libraries/pml/MultiComponent.cpp:50
#2  0x7fffeb32c11f in MultiComponent::~MultiComponent (this=0x56d98330, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:41
#3  0x7fffeb32c149 in MultiComponent::~MultiComponent (this=0x56d98330, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:38
#4  0x7fffeb32ce3a in PhysicalModel::clear (this=this@entry=0x55705ef0) 
at ./modeling/libraries/pml/PhysicalModel.cpp:99
#5  0x7fffeb32cf17 in PhysicalModel::~PhysicalModel (this=0x55705ef0, 
__in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:68
#6  0x7fffeb32cf59 in PhysicalModel::~PhysicalModel (this=0x55705ef0, 
__in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:67
#7  0x7fffeb317a3d in PMLComponent::~PMLComponent (this=0x55660a00, 
__in_chrg=) at 
./modeling/components/pmlcomponent/PMLComponent.cpp:96
#8  0x7fffeb3185a9 in PMLComponent::~PMLComponent (this=0x55660a00, 
__in_chrg=) at 
./modeling/components/pmlcomponent/PMLComponent.cpp:93
#9  0x77ec4ad7 in camitk::Application::close(camitk::Component*) () at 
./sdk/libraries/core/application/Application.cpp:623
#10 0xbc5c in main () at 
./sdk/applications/testcomponents/main.cpp:204
#11 0x76e99b17 in __libc_start_main (main=0xb080 , 
argc=9, argv=0x7fffe398, init=, fini=, 
rtld_fini=, stack_end=0x7fffe388) at ../csu/libc-start.c:310
#12 0xc35a in _start () at 
./sdk/applications/testcomponents/main.cpp:136

(gdb) list -
46
47  // -- deleteAllSubComponents -
48  void MultiComponent::deleteAllSubComponents() {
49  for (auto& component : components) {
50  delete component;
51  }
52  components.clear();
53  }




# Here the pointer being deleted is removed from the components vector
# and that way invalidating the iterator.

(gdb) bt
#0  MultiComponent::removeSubComponent (c=0x579d70f0, this=0x56d98330) 
at ./modeling/libraries/pml/MultiComponent.h:134
#1  Component::removeFromParents() () at 
./modeling/libraries/pml/Component.cpp:60
#2  0x7fffeb32c127 in MultiComponent::~MultiComponent (this=0x579d70f0, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:44
#3  0x7fffeb32c149 in MultiComponent::~MultiComponent (this=0x579d70f0, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:38
#4  0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents 
(this=this@entry=0x56d98330) at 
./modeling/libraries/pml/MultiComponent.cpp:50
#5  0x7fffeb32c11f in MultiComponent::~MultiComponent (this=0x56d98330, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:41
#6  0x7fffeb32c149 in MultiComponent::~MultiComponent (this=0x56d98330, 
__in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:38
#7  0x7fffeb32ce3a in PhysicalModel::clear (this=this@entry=0x55705ef0) 
at ./modeling/libraries/pml/PhysicalModel.cpp:99
...

(gdb) list modeling/libraries/pml/MultiComponent.h:134
129 }
130 inline void MultiComponent::removeSubComponent(Component* c) {
131 auto it = std::find(components.begin(), components.end(), c);
132 if (it != components.end()) {
133 components.erase(it);
134 c->removeParentMultiComponent(this);
135 }
136 }
From 52f172e553ebddf068b8e35601da5eefd295cf3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Thu, 20 Sep 2018 17:42:14 +0200
Subject: [PATCH] Make loop safe for removal of elements.

Bug-Debian: https://bugs.debian.org/909120
Forwarded: no
Last-Update: 2018-09-20

---
 modeling/libraries/pml/MultiComponent.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/modeling/libraries/pml/MultiComponent.cpp b/modeling/libraries/pml/MultiComponent.cpp
index 5a3a9ab..3f32d7b 100644
--- a/modeling/libraries/pml/MultiComponent.cpp
+++ b/modeling/libraries/pml/MultiComponent.cpp
@@ -46,8 +46,10 @@ MultiComponent::~MultiComponent() {
 
 // -- deleteAllSubComponents -
 void MultiComponent::de

Bug#909264: ITP: mmdebstrap -- creates a Debian chroot directory or tarball

[Johannes 'josch' Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes 'josch' Schauer 

* Package name: mmdebstrap
  Version : 0.1.0
  Upstream Author : Johannes 'josch' Schauer 
* URL : https://gitlab.mister-muffin.de/josch/mmdebstrap
* License : Expat
  Programming Lang: Perl
  Description : creates a Debian chroot directory or tarball

An alternative to debootstrap which uses apt internally and is thus able to use
more than one mirror and resolve more complex dependencies.

A list of advantages in contrast to debootstrap:

 - more than one mirror possible (or really anything that is a legal apt
   sources.list entry)
 - security and updates mirror included for Debian stable chroots (a
   wontfix for debootstrap)
 - 2-3 times faster (for debootstrap variants)
 - chroot with apt in 11 seconds (if only installing `Essential: yes`
   and apt)
 - gzipped tarball with apt is 27M small
 - bit-by-bit reproducible output (if `$SOURCE_DATE_EPOCH` is set)
 - unprivileged operation using Linux user namespaces, fakechroot or
   proot (mode is chosen automatically)
 - can operate on filesystems mounted with nodev
 - foreign architecture chroots with qemu-user (without manually
   invoking `--second-stage`)

Bug#907663: subdownloader: diff for NMU version 2.0.19-0.1

[Mattia Rizzolo]

Control: tag -1 - pending

On Wed, Sep 12, 2018 at 05:03:01PM +0300, Adrian Bunk wrote:
> I've prepared an NMU for subdownloader (versioned as 2.0.19-0.1) and 
> uploaded it to DELAYED/15. Please feel free to tell me if I should 
> cancel it.

I'm adopting subdownloader, so I'm doing a full rewamp of the package.

I've cancelled the NMU for now, but thanks for doing it! :)

I forsee an upload soon, if I manage even today, but given that it's not
yet ready I'm removing the pending tag.


signature.asc
Description: PGP signature

Bug#908116: firewalld: blocks multicast dns resolution for home zone

[Michael Biebl]

On Thu, 06 Sep 2018 11:20:41 +0200 Sergio Villar Senin
 wrote:
> Package: firewalld
> Version: 0.6.1-2
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>Upgrading to sid's 0.6.1-2
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>Multicast DNS (avahi) does not work at all with the new firewalld
>release. I haven't changed the configuration and it was working
>fine before the update. Actually downgrading to 0.4.4.5-2 makes it
>work again.
> 

Please test again with firewalld 0.6.2-1 and Linux kernel 4.18.

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



signature.asc
Description: OpenPGP digital signature

Bug#909218: nvidia-xconfig: Files section missing ModulePath entries break GLX upon installing libgl1-nvidia-glx (required by Steam)

[Andreas Beckmann]

Control: severity -1 serious
Control: tag -1 sid buster

Maybe it's time to phase nvidia-xconfig out for buster ...

On 2018-09-19 22:26, miguev wrote:

> 2. System freezes after locking screen with xflock4, can't even get to tty.
> https://unix.stackexchange.com/questions/411900/after-installing-nvidia-
> drivers-computer-freezes-after-locking-cant-even-get

Can we try to analyze and fix this bug instead of fixing nvidia-xconfig?

Does the following minimal Xorg.conf work for you?

Section "Files"
ModulePath "/usr/lib/xorg/modules/linux"
ModulePath "/usr/lib/xorg/modules"
EndSection

Section "Device"
Identifier "My GPU"
Driver "nvidia"
EndSection

Since X seems to work without xorg.conf (unless you lock your screen)
please get Xorg logs from both no xorg.conf and a working minimal xorg.conf


> Workaround is to generate /etc/X11/xorg.conf by running nvidia-xconfig
> # nvidia-xconfig
> # /etc/init.d/lightdm restart

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Adding NVidia’s drivers path in /etc/X11/xorg.conf in the otherwise empty
> “Files” section:
> Section "Files"
> ModulePath "/usr/lib/nvidia"

NEVER EVER add "/usr/lib/nvidia" as a search path.
This tree will also contain incompatible legacy modules.
Use /usr/lib/xorg/modules/linux instead. There will be a symlink to the
correct module.

> ModulePath "/usr/lib/xorg/modules"
> EndSection
> 
> The paths are those that contain libglx.so
> # find /usr/ -name libglx.so
> /usr/lib/nvidia/libglx.so
> /usr/lib/nvidia/current/libglx.so
> /usr/lib/xorg/modules/extensions/libglx.so
> /usr/lib/xorg/modules/linux/libglx.so
> 
> Found this idea in the NVidia Dveloper forum:
> https://devtalk.nvidia.com/default/topic/800059/linux/glxinfo-command-
> returning-quot-badwindow-invalid-window-parameter-quot-error/


Andreas

Bug#907197: thunderbird 60 - although thunderbird-l10n-it is installed, the language is always English

[Carsten Schoenert]

Am 20.09.18 um 10:25 schrieb Tapio Lehtonen:
> I compared newly created profile pref.js and my default profile, could 
> not see language related differences (I used meld to see files side by 
> side).
> 
> Then I took a look at Add-ons manager. It claims finnish language pack 
> is not compatible with TB 60.0. See attatched screenshot.
> 
> This is wonky. The language pack installed is version 60.0:
> 
> $ dpkg --list | grep -i thunder
> ii  lightning 1:60.0-3~deb9u1  all  
> Calendar Extension for Thunderbird
> ii  thunderbird   1:60.0-3~deb9u1  amd64
> mail/news client with RSS, chat and integrated spam filter support
> ii  thunderbird-l10n-fi   1:60.0-3~deb9u1  all  
> Finnish language package for Thunderbird
> 
> I removed the language pack in Add-ons Manager, exited TB and started 
> TB. Now Thunderbird is in Finnish. And now Add-ons Manager shows 
> language pack is version 60.0buildid... .

If you really can remove (not only deactivate) a AddOn or language pack
here it is installed locally and not in control by the package manager
of Debian!

> The lightning calendar is also in Finnish.
> 
> Looks like TB was stuck with the old version language pack, the upgrade 
> from v52 to v60 I believe left the old language pack in place.

Of course, but we can't deal with local installed AddOns or Extensions
within pre- or postinst. This is really up to the user.

-- 
Regards
Carsten Schoenert

Bug#909236: Bug#909255: listadmin: the log feature is now completely broken

[Gunnar Wolf]

merge 909255 909236
thanks

Both bugs report the same issue.

Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Carsten Schoenert]

[Reduced the CC list]

Hello Roger,

Am 20.09.18 um 02:53 schrieb Roger Shimizu:
> And I'm not the maintainer of src:gnupg2. I just want to help
> Bug#906545, and upstream maintainer says patching stable version may
> be hard and backport may be easier.
> 
> backports should be no harm since it uses ~bpo in version.
> So it's still feasible if pkg maintainer and release team decide to
> include a new major version into point release.

yes and no.
Technically it's no problem to provide gnupg2 through backports, the
downside is that users need to act here proactively and install this
package with some extra knowledge.

It's not that I'm against this, providing a package by backports is in
my eyes even better than providing nothing and pushing people to use
usptream releases directly (like enigmail e.g. for now).

...
> Did you report this situation to release team?
> I think if it's necessary and release team agree, gnupg2 maintainer
> can certainly help.

No, I haven't talked to the release team, I'm mostly in contact with the
security team by my involvement due the thunderbird package. And we did
have some conversation together with dkg as one of the maintainers of
enigmail and gnupg2. dkg has summarized the current problem with
enigmail and gnupg2 in #909000.

I'm the wrong person to make a judgment for doing a backport of gnupg2,
if ever one can something to this than this is Daniel or Eric. So in my
eyes it's better to ask the original package maintainer, maybe Daniel is
fine with an upload of gnupg2 to backports? And if yes it's probably
also o.k. then to upload a recent enigmail version to backports
afterwards. In the future it's later always possible to provide a newer
version through stable-security.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909000#15

-- 
Regards
Carsten Schoenert

Bug#909192: mate-desktop-environment: Installing sysvinit-core removes mate-desktop-environment

[Ian Jackson]

Mike Gabriel writes ("Re: Bug#909192: mate-desktop-environment: Installing 
sysvinit-core removes mate-desktop-environment"):
> many thanks for all this background info. I might have a potential  
> contract to get this solved in the loop, so, I may probably return to  
> it soon (or not so soon). Let's see...

Can you let us know when you will know whether this is going to
transpire ?

Also, we had an IRC conversation on #debian-devel about pam_systemd
and the dbus user service.  I think it contains a lot of useful
information particularly from smcv.  See below.

This is a transcript of #debian-devel manually edited to remove other
conversations, and also to remove unconstructive comments (of which
unfortunately there were some).

Ian.

15:40  is it so that desktop envs that depend on DBus user sessions, 
can't run on SysV systems anymore?
15:40  see #909192
15:40 -zwiebelbot:#debian-devel- Debian#909192: mate-desktop-environment: 
Installing sysvinit-core removes mate-desktop-environment - 
https://bugs.debian.org/909192
15:40  if people can contribute to finding a solution, I'd be happy 
for posts sent directly to the bug. Thanks.
15:41  sunweaver: This seems like some kind of mistake.
15:41  What is `dbus-user-session' ?  It sounds like a thing that could 
be provided without trouble on sysvinit systems.
15:41  I mean, I probably have one right here (although stretch, not 
buster)
15:42  sunweaver: "It has a dependency on systemd's userspace part, but 
not on systemd as   PID one."
15:42  I think that is possibly a reference to systemd-logind ?
15:42  I don't see why a dbus user session would depend on that.
15:42  I guess so, too.
15:43  Also "systemd" is not the pid 1 part.
15:43  Diziet: Because they didn't want to implement their own session 
management?
15:43  So I don't see why "systemd" and "sysvinit-core" aren't 
coinstallable.
15:43  I have them both here on my laptop which is using systemd-logind 
(stretch, again).
15:43  ansgar: I'm not sure what you mean by session management.  This 
all works in stretch.
15:44  sunweaver: It depends on libpam-systemd which depends on 
systemd-sysv
15:44  yes, "systemd" is not the pid 1 part
15:44  so the problem is not the chain in the last email
15:44  Diziet: I assume we aren't talking about stretch.
15:44  ansgar: Indeed I think that bug isn't.
15:44  Depends: libc6 (>= 2.26), libpam0g (>= 0.99.7.1), systemd (= 
239-9), libpam-runtime (>= 1.0.1-6), dbus, systemd-shim (>= 10-4~) | 
systemd-sysv
15:45  But knowing how this all works in at least one stretch system is 
probably helpful because then one can see what has changed and try to make it 
work like it did in stretch.
15:45  Oh the problem is that systemd-shim is broken.
15:46  TBH I don't really see why dbus-user-session needs libpam-systemd
15:46  wRAR: notice the (>= 10-4~), see #903295 and #901405
15:46 -zwiebelbot:#debian-devel- Debian#903295: libpam-systemd: Depends: 
systemd-shim (>= 10-4~) but it is not going to be installed - 
https://bugs.debian.org/903295
15:46  systemd : Breaks: systemd-shim (< 10-4~)
15:46  yup
15:46 -zwiebelbot:#debian-devel- Debian#901405: systemd-shim: Please add a 
sysvinit service to create directories on /run at boot - 
https://bugs.debian.org/901405
15:46  "systemd-shim is broken" is not something surprising of course
15:46  sunweaver: Do you have time to look at this ?
15:46  wRAR: Indeed but I guess it is fixable.
15:47  sunweaver: I think the most obvious fix is to fix the 3 bugs 
listed here  https://tracker.debian.org/pkg/systemd-shim
15:47  sunweaver: If someone would prepare a fix I would be happy to 
sponsor it.
15:50  I think a long term solution is probably to replace the 
automatic session authorisation stuff with something more simple like 
membership of a suitable unix group.
15:50  sunweaver: AYT?
15:55  oO(systemd-shim should be RM from debian)
15:57  bigon: It should not, but due to noone (including me) being 
willing to spend time on maintaining it that's what will happen in practice (it 
already got removed from buster).
15:57  it's broken
15:57  if you want to be able to use login1 D-Bus API without systemd, 
people should go for elogin IMVHO
15:59  bigon: What is elogin ?
15:59  gentoo people have extracted logind from systemd source
15:59  Diziet: given that it starts with "e", I suspect something from 
gentoo
15:59  well, there
15:59  elogind is systemd-logind with the cgroup manager merged back in.
15:59  (same with eudev where they have extracted udev from systemd)
15:59  And some questionable patches...
16:00  bigon: OK, so can we have that in Debian ?
16:00  If so it could be an alternative dependency to systemd-shim
16:00  I've created a pkg to give it some test (yeah to insomnia)
16:00  bigon: Great.
16:00  #905388
16:00  we can also have xdg-menu in Debian, it seems a lot of people want 
it
16:00  but I've absolutely have 0 plans to mantain it
16:00 -zwiebelbot:#debian-devel- Debian#905388: RFP: elogind -- The systemd 
project's "login

Bug#909263: Postfixadmin 3.0 to 3.2 upgrade: SQLite upgrade fails

[Christian Schrötter]

Package: postfixadmin
Version: 3.2-3
Severity: important
Tags: patch fixed-upstream

Dear Maintainer,

please take a look at issue 177 [1]. Currently it's impossible to use
the upgrade.php script with SQLite! I've tested the commits ceb2610 [2]
and 31c5e6d [3], they are included in patch [4]. Now the upgrade works
like a charm at Debian Buster. I've NOT tested MySQL or pgSQL upgrade!

I don't know if the next Postfixadmin release will be ready before the
Buster freeze, so please consider adding a patch to solve this problem.

Thanks!

-- 
Regards,
Christian

[1]: https://github.com/postfixadmin/postfixadmin/issues/177
[2]:
https://github.com/postfixadmin/postfixadmin/commit/ceb261036a1758e96b1879c298343d2702ab531c
[3]:
https://github.com/postfixadmin/postfixadmin/commit/31c5e6dd2e74678b8c12791538e7212bbf8ee543
[4]:
https://github.com/froonix/postfixadmin/blob/debian-buster-20180920/diff_postfixadmin-3.2..debian-buster-20180920.patch

Bug#864987: newer FF

[Matija Nalis]

for newer firefox 60.2.0esr see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908349
for possible workarounds (like apulse wrapper for using ALSA instead of 
pulseaudio)

On Wed, Sep 12, 2018 at 04:51:10AM +, 908349-subh...@bugs.debian.org wrote:
> You have been successfully subscribed to 908...@bugs.debian.org.
> 
> If you wish to unsubscribe, send mail to 
> 908349-unsubscr...@bugs.debian.org .
> 
> For instructions on using the bug subscription software, send
> mail to 908349-h...@bugs.debian.org .
> 
> If you have problems with this subscription, please contact the Debian
> Listmaster Team at listmas...@lists.debian.org.
> 
> Thank you.

-- 
Opinions above are GNU-copylefted.

Bug#909262: ITP: node-cache-loader -- Caches the result of following loaders on disk

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-cache-loader
  Version : 1.2.2
  Upstream Author : Tobias Koppers @sokra
* URL : https://github.com/webpack-contrib/cache-loader
* License : Expat
  Programming Lang: JavaScript
  Description : Caches the result of following loaders on disk

This is a loader for webpack.
 .
 Webpack packs (combines) CommonJs/AMD modules for the browser.
 .
 Node.js is an event-based server-side JavaScript engine.

This is a dependency of gitlab 10.x and since its source is ES6 and
needs babel to build to ES5, it is not suitable for embedding.



signature.asc
Description: OpenPGP digital signature

Bug#827059: newer firefoxes

[Matija Nalis]

for newer firefox 60.2.0esr see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908349
for possible workarounds

Bug#909247: devscripts: grub-excuses: be interactive and colourful

[Mattia Rizzolo]

On Thu, Sep 20, 2018 at 03:40:36PM +0200, Mathieu Trudel-Lapierre wrote:
> Well, my thought as I wrote the tool was to make it work with Debian
> too,

:)

> but I haven't had much luck doing some things outside of using the
> Launchpad API... but there's also that I'm more familiar with that, so
> maybe people have some tricks up their sleeve that I'm not aware of,
> aside from using madison...

there is an api.ftp-master.debian.org nowadays that *could* help with
getting information about packages' availability, besides madison (which
is also provided by said api since a few years).

> I couldn't figure a way to grab Debian build
> logs and results (which are useful when considering migration of
> packages in Ubuntu anyway) aside from putting together the URLs, and
> then you're at the mercy of these things changing.

there is a getbuildlog(1) in devscripts which does exactly that.  It
worked for more a decade now as buildd.d.o never changed, but yes, there
is no real stable API to access a build log URL.

> To improve on this, we should also make it easier to parse excuses and
> update_output.txt. I started a discussion about this at
> https://github.com/Debian/britney2/issues/3.

Interesting indeed.  Thanks for the pointer!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#907926: debrelease should offer to run debsign if the .changes is unsigned

[Mattia Rizzolo]

On Tue, Sep 04, 2018 at 09:37:50AM +0200, Raphaël Hertzog wrote:
> debrelease just fails when the .changes is unsigned:
> 
> $ debrelease -S
> Trying to upload package to ftp-master (ftp.upload.debian.org)
> Checking signature on .changes
> gpg: ../build-area/gnome-shell-pomodoro_0.13.4-3_source.changes: error 
> 58: gpgme_op_verify
> gpgme_op_verify: GPGME: No data
> 
> It would be much more helpful if it detected this situation

FWIW, dput-ng recently learnt to run debsign itself if the .changes is

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#909243: gnome-shell segfaults on start: meta_logical_monitor_get_layout (logical_monitor=0x0)

[Simon McVittie]

Control: reassign -1 libmutter-3-0
Control: affects -1 gnome-shell
Control: retitle -1 gnome-shell segfaults on start: 
meta_logical_monitor_get_layout (logical_monitor=0x0)

On Thu, 20 Sep 2018 at 13:37:05 +0200, Henry Schwanbeck wrote:
> thanks for your answer. I attached what I think is the backtrace you
> requested

Unfortunately the Xwayland backtrace is not very interesting: it responds
to a gnome-shell crash by crashing itself, so it's a symptom rather than
a cause.

This gnome-shell segfault looks like the root cause:

> Sep 20 13:17:05 telesto kernel: [  545.551837] gnome-shell[2252]: segfault at 
> 1c ip 7f74aaa86050 sp 7fffbc66a8a8 error 4 in 
> libmutter-3.so.0.0.0[7f74aaa6f000+c4000]

On Thu, 20 Sep 2018 at 14:00:40 +0200, Henry Schwanbeck wrote:
> root@telesto:/home/henry# coredumpctl debug --debugger=gdb gnome-shell

Thanks, this is the backtrace we needed. I think this indicates a
libmutter bug.

smcv

Bug#905138: 905138: Please update cmake with the upstream commit for kfreebsd as you promised.

[Svante Signell]

Hello,

Please cherry-pick the upstream commit for kfreebsd in 3.12.1 as promised:

https://gitlab.kitware.com/cmake/cmake/commit/6b7b54d476a297b32f8f1521f3255052b9dda1b6

The corresponding Debian patch is inlined below for your convenience:

--- a/debian/control2018-05-19 10:51:17.0 +0200
+++ b/debian_control2018-07-29 17:38:11.272777000 +0200
@@ -15,6 +15,7 @@
librhash-dev,
libuv1-dev (>= 1.10),
procps [!hurd-any],
+   freebsd-glue [kfreebsd-any],
python3-sphinx,
qtbase5-dev ,
zlib1g-dev

Thanks!

Bug#896436: gradle FTBFS: error fetching java api url when building with openjdk-10

[Emmanuel Bourg]

Le 16/09/2018 à 12:44, 殷啟聰 | Kai-Chung Yan a écrit :

> Shouldn't this be fixed at the `java-common` side instead of here? Switching 
> back to `default-jdk` seems like a step back to me.

It's indeed a step back but unless java-common is changed (which isn't
trivial) I see no other solution. This bug was blocking the more
important Java transition. Let's pick the fights one by one. We can
still work on this later.

Emmanuel Bourg

Bug#877992: Urgent Response.

[Dr. Sean Kim.]

Hello,

We are a US company based in the UK.

Please confirm if you received the email we sent to you concerning the supply 
of an industrial raw material to our company. These raw materials can only be 
purchased from India and Fiji Island but cheaper in India. Our Company is 
desperatley in need of this product of which we hope you could help us source 
for it since our previous supplier in India died a few months back.

Note that you will be fully compensated and paid for your services to our 
Company upon confirmation of the product.

Kindly view our website for further information.

Further details will be emailed to you upon receipt of your response as I await 
for your reply via my personal email: 

Thanks,


Dr. Sean Kim.
US No/Whatsapp: +1-651-927-4361.
UK No: +44-748-053-3470

Bug#905350: dosent work for me

[Markus Raps]

Hi Peter,

thank you for the reply but that dosent work for me.
have you reproduce it with the steps above?

shows still to much memory and can use to much

tested with stress inside the container
stress --vm-bytes $(awk '/MemFree/{printf "%d\n", $2 * 0.9;}' < 
/proc/meminfo)k --vm-keep -m 1


i think something is broken in the cgroups association and the processes 
because there are some pids missing


cat /sys/fs/cgroup/memory/machine/lxc-1674-ct1.libvirt-lxc/cgroup.procs
1674

ps auxf
root  1674  0.0  0.3 210720  7200 ?Sl   14:34   0:00 
/usr/lib/libvirt/libvirt_lxc --name ct1 --console 22 --security=none 
--handshake 25 --veth vnet1
root  1676  0.0  0.2  56724  5236 ?Ss   14:34   0:00  \_ 
/sbin/init
root  1695  0.0  0.1  46092  2248 ?Ss   14:34   0:00  \_ 
/lib/systemd/systemd-journald
root  1727  0.0  0.0  27992  1064 ?Ss   14:34   0:00  \_ 
/usr/sbin/cron -f
root  1728  0.0  0.0 254332  1892 ?Ssl  14:34   0:00  \_ 
/usr/sbin/rsyslogd -n
root  2299  0.0  0.0  12668  1728 pts/0Ss+  14:56   0:00  \_ 
/sbin/agetty --noclear --keep-baud console 115200,38400,9600 linux



--
Mit freundlichen Grüßen / best regards
Markus Raps

Bug#896192: Fix proposal3: #896192: cloudcompare FTBFS on architectures where char is unsigned

[Frédéric Bonnard]

Hi,
there was actually already a fix provided upstream but the Debian
FTBFS issue 708 was not closed accordingly.
Here is the patch that can be used :
https://github.com/CloudCompare/CloudCompare/commit/58d41947966ad73e1a846e723d4712fddf758aab.patch

F.


pgpbjZGi7SVaT.pgp
Description: PGP signature

Bug#909247: devscripts: grub-excuses: be interactive and colourful

[Mathieu Trudel-Lapierre]

On Thu, 20 Sep 2018 12:15:21 +0200 Mattia Rizzolo wrote:
> Package: devscripts
> Version: 2.18.4
> Severity: wishlist
> User: devscri...@packages.debian.org
> Usertags: grep-excuses
>
> Mathieu here [0] announced a new tool in ubuntu-dev-tools to parse
> ubuntu's update_excuses.yaml.
> The goal is extremily similar to devscripts' grep-excuses, but it
> accomplishes the work in a *much* nicer way.
>
> I dare to propose to rewrite our grep-excuses to use the functionalities
> provided by the python3 module ubuntu_archive_assistant that they wrote.
>

Well, my thought as I wrote the tool was to make it work with Debian
too, but I haven't had much luck doing some things outside of using the
Launchpad API... but there's also that I'm more familiar with that, so
maybe people have some tricks up their sleeve that I'm not aware of,
aside from using madison... I couldn't figure a way to grab Debian build
logs and results (which are useful when considering migration of
packages in Ubuntu anyway) aside from putting together the URLs, and
then you're at the mercy of these things changing.

To improve on this, we should also make it easier to parse excuses and
update_output.txt. I started a discussion about this at
https://github.com/Debian/britney2/issues/3.

I'll get started on a PR for the code changes I was thinking off on that
related aspect of things.

-- 
Mathieu Trudel-Lapierre 
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2  CF89 C67B B4D6 65B5 8DA1




signature.asc
Description: OpenPGP digital signature

Bug#909261: ITP: puppet-module-rodjek-logrotate -- Logrotate module for Puppet

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-rodjek-logrotate
  Version : 1.1.1+ds1
  Upstream Author : Tim Sharpe
* URL : https://github.com/rodjek/puppet-logrotate
* License : Expat
  Programming Lang: Ruby
  Description : Logrotate module for Puppet

 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 puppet module provides a way of managing logrotate configs.

Note: This is a dependency of puppet-module-icann-quagga

Bug#908541: inkscape: DXF r14 export contains far too many entities

[Mattia Rizzolo]

Control: forwarded -1 https://bugs.launchpad.net/inkscape/+bug/1793530
Control: tag -1 upstream

Hi Paul,

On Mon, Sep 10, 2018 at 11:29:06PM +0100, Paul "LeoNerd" Evans wrote:
> I have a simple SVG file containing only a few circular shapes, which I
> am attempting to export as DXF as part of a CNC milling process.
> Inkscape creates a DXF file containing many thousands of tiny entities
> for this, far more than would be required to actually represent the
> shapes. This causes dxf2gcode to get upset trying to load it.
>   (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895865 ) 
> 
> I suspect what may be happening is it has far too small a tolerance for
> how to cut paths up.

I forwarded your bug to upstream, see link above.
Please follow up there with any updates, etc.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#890034: Backport of Perc 740/840 for Stretch

[Moritz Muehlenhoff]

On Thu, Sep 20, 2018 at 02:11:10PM +0200, Bernhard Schmidt wrote:
> On Fri, Sep 14, 2018 at 12:37:40PM +0200, Moritz Muehlenhoff wrote:
> 
> > I've pulled a number of upstream commits for the megaraid_sas driver which 
> > add
> > support for the Perc 740/840 RAID controllers to the Stretch kernel.
> > 
> > Successfully tested with a H840 on a current Dell PowerEdge R440 and I've 
> > also tested
> > the built kernel on a system which was previously supported by the 
> > megaraid_sas
> > driver (LSI MegaRAID SAS 2008 (Perc H310 Mini)) and that continues to work 
> > fine
> > as well.
> > 
> > Test debs (I'd appreciate more tests on MegaRAID controllers, the 740 
> > should be
> > identical to the 840 except that it allows for less drives) are at
> > https://people.debian.org/~jmm/perc/
> 
> I've tried your kernel on a R740 with Buster userland (I did not find
> an easy way to build a new Stretch debian-installer image with the
> updated kernel) and it works just fine.

Thanks.

> > Merge request at 
> > https://salsa.debian.org/kernel-team/linux/merge_requests/61
> 
> There have been a few style comments by Ben Hutchings. 

Yep, I hope to find some time for that tomorrow.

Cheers,
Moritz

Bug#859010: sympa@domain alias doesn't work

[Goulven Guillard]

On Wed, 29 Mar 2017 17:00:28 +0300 Ander Punnar  wrote:> 
since there's no sympa@domain alias in /etc/mail/sympa/aliases,

I wrote alias into /etc/aliases as hinted in upstream documentation:

> sympa: "| /usr/lib/sympa/bin/queue sympa@domain"

ran newaliases and sent mail with subject "help" to sympa@domain.


I had a similar issue.  Adding this alias to /etc/mail/sympa/aliases 
instead of /etc/aliases seemed to solve it (after having configured a 
sympa_aliases router as in the first section of 
).


Regards,

Goulven.

Bug#908318: RFS: fcitx-dbus-status/2016062301-1

[Kentaro Hayashi]

X-Debbugs-CC: debian-input-met...@lists.debian.org haya...@clear-code.com

On Wed, 19 Sep 2018 11:30:36 -0400 Boyuan Yang  wrote:
> I believe there's still several issues that needs to be solved before pushing 
> it into Debian official repository:
> 
> * The copyright header in source code said that the file was released under 
> GPL-2+. However, you only mentioned GPL-2 in debian/copyright file. Please 
> make those statements consistent; if you are not sure about the exact 
> license, 
> please ask the upstream for sure.

Thanks!
As you pointed out, it should be GPL-2+ instead of GPL-2. I've fixed.

> * Obviously this package needs runtime dependency on dbus and fcitx. However, 
> that relationship was not reflected in the binary dependency list. Please 
> consider manually add such requirement in debian/control.
> 

I've forgot to specify it. It has been also fixed.

https://mentors.debian.net/debian/pool/main/f/fcitx-dbus-status/fcitx-dbus-status_2016062301-1.dsc

Regards,


pgpya84LWeJHl.pgp
Description: PGP signature

Bug#909259: procyon: FTBFS with Java 11 due to sun.misc.Unsafe.defineClass() removal

[Emmanuel Bourg]

Source: procyon
Version: 0.5.32-4
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

procyon fails to build with Java 11 due to the removal of the defineClass()
method in sun.misc.Unsafe:

  
/procyon/Procyon.Reflection/src/main/java/com/strobel/reflection/emit/TypeBuilder.java:1234:
 error: cannot find symbol
  _generatedClass = (Class) getUnsafeInstance().defineClasss(
  ^
symbol:   method 
defineClasss(String,byte[],int,int,ClassLoader,ProtectionDomain)
location: class Unsafe


Note that gradle/4.4-2 doesn't run on Java 11 and can't build procyon yet,
but that's a different issue.

Bug#903112: [Pkg-zfsonlinux-devel] Bug#903112: Waits for spl build directory

[Yuri D'Elia]

On Thu, Sep 20 2018, Aron Xu wrote:
> It's still possible to happen when upgrading both of the packages,
> pre-depends only avoids the problem on fresh installation. Let's think
> about an alternative way to solve incompatible kernel problem.

Do the dkms triggers actually run concurrently?
I never experienced this.

On the contrary, running two builds of zfs for two different kernel
versions seem to break the build process.

I also have 4 kernels versions installed. I'd like to avoid zfs/spl
having some dkms build-exclusive rules like aufs does, since I cannot
easily test the module on kernel from experimental. I'd rather have the
build fail because the build truly failed.

Waiting in configure looks ridiculous to me. The headers might simply
not be there. The build of spl could have failed. There are not cases to
wait for.

Bug#909258: objenesis: FTBFS with Java 11 due to sun.misc.Unsafe.defineClass() removal

[Emmanuel Bourg]

Source: objenesis
Version: 2.6-2
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

objenesis fails to build with Java 11 due to the removal of the defineClass()
method in sun.misc.Unsafe:

  [ERROR] 
/objenesis/main/src/main/java/org/objenesis/instantiator/util/ClassDefinitionUtils.java:[100,54]
 cannot find symbol
symbol:   method 
defineClass(java.lang.String,byte[],int,int,java.lang.ClassLoader,java.security.ProtectionDomain)
location: class sun.misc.Unsafe

Bug#690097: Bug #690097 - dynamips: Please enable buildd support

[Andrej Shadura]

On 12 August 2018 at 20:51, Philipp Kern  wrote:
> Hi,
>
> On 20.07.2018 20:26, Andrej Shadura wrote:
>> On 26 June 2018 at 17:25, Andrej Shadura  wrote:
>>> On 26 June 2018 at 17:12, Philipp Kern  wrote:
>> I suppose
>>
>> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd
>> might help you?
>
> I think we did all of that?


 I don't see (3) satisfied in this case.

 Kind regards
 Philipp Kern
>>>
>>> Is https://bugs.debian.org/690097#15 not meeting some requirements?
>
> so I dug up that old mail. How do we know that those microcode blobs are
> distributable? We seem to assume that they are GPL-2+ without source?
> How so?

According to https://github.com/GNS3/dynamips/issues/7, the source of
it is missing, but apparently:

1) it was developed specifically for dynamips
2) it hasn’t got much code in it and TBH I’m not sure that code is
really copyrightable

-- 
Cheers,
  Andrej

Bug#909257: gmbal-pfl: FTBFS with Java 11 due to sun.misc.Unsafe.defineClass() removal

[Emmanuel Bourg]

Source: gmbal-pfl
Version: 4.0.1-b003-1
Severity: important
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java11

gmbal-pfl fails to build with Java 11 due to the removal of the defineClass()
method in sun.misc.Unsafe:

  [ERROR] 
/gmbal-pfl/pfl-basic/src/main/java/org/glassfish/pfl/basic/reflection/BridgeBase.java:[267,22]
 cannot find symbol
symbol:   method 
defineClass(java.lang.String,byte[],int,int,java.lang.ClassLoader,)
location: variable unsafe of type sun.misc.Unsafe