Bug#908723: RFP: django-auto-one-to-one -- Django module to automatically connect child model instances to parent class

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist
X-Debbugs-cc: Chris Lamb 

Cc to the upstream developer.

* Package name: django-auto-one-to-one
  Version : 3.0.0
  Upstream Author : Chris Lamb 
* URL : https://chris-lamb.co.uk/projects/django-auto-one-to-one
* License : BSD-3-clause
  Description : Django module to automatically connect child model 
instances to parent class

This is very useful when associating more information with one of the
Django internal models like User.

I've created draft packaging in the debian branch on
https://github.com/petterreinholdtsen/django-auto-one-to-one > for
my own use.  It still need more work, and someone with the spare time
required to maintain the package in Debian.

-- 
Happy hacking
Petter Reinholdtsen

Bug#908699: gitolite3: prevent access to repos which are in the process of bring migrated

[Salvatore Bonaccorso]

Control: retitle -1 gitolite3: CVE-2018-16976: prevent access to repos which 
are in the process of being migrated

Hi,

On Wed, Sep 12, 2018 at 10:22:35PM +0200, Salvatore Bonaccorso wrote:
> hi David,
> 
> On Wed, Sep 12, 2018 at 05:03:40PM -0300, David Bremner wrote:
> > Salvatore Bonaccorso  writes:
> > 
> > > Source: gitolite3
> > > Version: 3.6.6-1
> > > Severity: important
> > > Tags: security upstream
> > >
> > > Hi
> > >
> > > Filling this for tracking, David did you or upstream requested
> > > accordingly a CVE?
> > >
> > > Announce: 
> > > https://groups.google.com/forum/#!topic/gitolite-announce/WrwDTYdbfRg
> > > Fix: 
> > > https://github.com/sitaramc/gitolite/commit/dc13dfca8fdae5634bb0865f7e9822d2a268ed59
> > >
> > 
> > I'm not aware of a related CVE.
> 
> Okay, I just have requested one.

CVE-2018-16976 has been assigned for this issue.

Regards,
Salvatore

Bug#725408: org-mode 8 info does not show up in info index

[Nicholas D Steeves]

Hi Sébastien,

On Fri, Aug 24, 2018 at 08:35:53AM +0200, Sébastien Delafond wrote:
> On Aug/23, Nicholas D Steeves wrote:
> > Is that wrong info page bug still valid?  It just occured to me that
> > it should be possible to add a few lines to the elpa-org-mode that
> > rebinds infopath to put org-mode-doc ahead of emacs' built-in when
> > elpa-org-mode is loaded.
> > 
> > If the non emacs bin/info is the issue, then there might be some kind
> > of dh hook that could be used.
> 
> That bug was still valid last time I checked, yes: re-reading the bug
> history[0], the problem is indeed only with info(1), and emacs's own
> info mode seem to always do the right thing. I unfortunately don't have
> much time these days to try and investigate this some more...

Thank you for forwarding that email to this bug :-)

Bremner, rlb, and I discussed this on #debian-emacs sometime in the
last two weeks.  I investigated using the Debian alternatives system
to provide /usr/share/info/org.gz, while simultaneously installing
org.gz to the path used by elpa-org-mode--the intent of this second
point was to guard against cases where an emacs* package installs to
/usr/share/info/org.gz vs the new /usr/share/info/emacs*/org.gz.

This was a concern because it's an RC bug for two packages to install
a file to the same path.

Debian alternatives has emacs as a master group, and org.gz is a
slave.  Org-mode-doc cannot takeover the slave, so that's a no go.

It's possible that this bug, #725408, is an RC Policy violation,
because it clobbers the Debian alternatives managed path of
/usr/share/info/emacs*/org.gz, but I'm not sure so am not bumping
priority.  Additionally, I'm not sure what will happen when emacs is
updated on top of this package, eg: will the alternative-managed link
clobber org-mode-doc's copy?

But I found a possible solution that could be used for other packages
that provide updated submodules of a big package!
##
INFOPATH="/usr/share/doc/org-mode-doc:"
export INFOPATH
##

From
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Other-Info-Directories.html

The syntax might need to be modified, but the idea is to provide a
file that a user can copy from /u/s/d/org-mode-doc to /etc/profile.d
that will prepend an elpa-package's infopath to the system one that
Emacs controls.  The final ":" is replaced by the compiled-in standard
INFOPATH.

I believe it was bremner who said that we should make this opt-in,
rather than automatically modifying a user's environment.  Personally
I see that automatic stuff as one of Debian's strengths, like how any
package can add something to /etc/bash_completion.d.

Maybe an extra layer of abstraction/safety would be appreciated between
/etc/profile.d and INFOPATH?  Something like
/etc/profile.d/infopath.sh runs schema and safety checks on all files
in /etc/infopath.d/{bunch,of,package,names}?

Oh, and the best thing?  INFOPATH works for both /usr/bin/info and
Emacs' info-mode :-D

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#908720: seahorse: does not list passwords for the login keyring

[Jeremy Bicha]

Control: tags -1 -moreinfo

On Wed, Sep 12, 2018 at 8:06 PM Sergio Villar Senin  wrote:
> What extra info would you need?

In the View menu, try clicking Show Any.

This looks like a regression from the previous release. Would you be
interested in reporting this issue to
https://gitlab.gnome.org/GNOME/seahorse/issues ?

Thanks,
Jeremy Bicha

Bug#386417: closed by David Bremner (seems fixed)

[Nicholas D Steeves]

On Wed, Sep 12, 2018 at 11:24:05AM +, Debian Bug Tracking System wrote:
>
> Date: Wed, 12 Sep 2018 08:22:27 -0300
> From: David Bremner 
> To: 386417-d...@bugs.debian.org
> Subject: seems fixed
> 
> 
> I downloaded the latest upstream version of folding.el, and could not
> reproduce the problem with the attached (modified) test file. A lot has
> changed in the intervening decade, so it may be that some change in
> emacs has fixed the problem.
> 

Awesome, thank you for confirming and closing :-)  #639221 is still
stalled waiting for upstream to reply to copyright issue, and I've
asked #debian-ftp if they believe its grounds for rejection (given the
issue also exists in goodies, which is present in the archive
already...)


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#908721: [Pkg-utopia-maintainers] Bug#908721: firewalld: blocks mdns traffic on home zone (with mdns enabled)

[Michael Biebl]

You already filed the same issue as #908116
No need to file a duplicate.

-- 
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#908708: networking-l2gw: FTBFS (ImportError: cannot import name 'topics')

[Santiago Vila]

reopen 908708
thanks

On Thu, 13 Sep 2018, Thomas Goirand wrote:

> Feel free to open a new bug for the Sid
> version, that would help a way more.

Ok, here it is the bug for the sid version.

I reported against 1:12.0.1-1 which is already the sid version.
When built under sid it fails in exactly the same way it failed
for me under buster.

However:

$ rmadison networking-l2gw
networking-l2gw | 1:1.0.0+git20160927.29cb4fe3-1 | stable   | source
networking-l2gw | 1:12.0.1-1 | testing  | source
networking-l2gw | 1:12.0.1-1 | unstable | source
networking-l2gw | 1:13.0.0-1 | experimental | source

Maybe you forgot to upload 1:13.0.0-1 for unstable?

For the record, I only report bugs against packages having the same
version in buster and sid (as in this case), and only when the package
fails in sid according to reproducible builds (as in this case).

Sometimes the package fails in buster and sid for completely different
reasons and that would be a false positive, but that's not what it
happened here.

(And no, I'm not going to build packages in experimental, I'm not a
cyborg either :-).

Thanks.

Bug#908720: seahorse: does not list passwords for the login keyring

[Sergio Villar Senin]

O Mér, 12-09-2018 ás 19:58 -0400, Jeremy Bicha escribiu:
> Control: tags -1 moreinfo
> 
> I can't reproduce this bug with the information you have provided.
> 
> Note that seahorse continues to run in the background as a system
> service. I recommend logging out and logging back after upgrading
> seahorse.

I did it and even rebooted the machine. The passwords are not shown.
The only thing I can see is the ssh and gpg keys.

I've tried in 2 different computers, one in sid and the other in
testing and the bug is reproducible in both of them (both with 3.30
version).

What extra info would you need?

BR

Bug#908721: Acknowledgement (firewalld: blocks mdns traffic on home zone (with mdns enabled))

[Sergio Villar Senin]

Actually I think the problem is worst than I thought as I cannot access
any of the enabled services in the machine with updated firewalld. I've
tried several, ssh, rdp, mdns... All of them are enabled in the active
zone and none of them is opened in the firewall.

I'd advice increasing the severity of the issue.

Bug#908722: invesalius: Fails to upgrade: SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Comecei")?

[Axel Beckert]

Package: invesalius
Version: 3.1.2-1
Severity: serious

Hi,

when tying to upgrade invesalius from 3.1.1-1 to 3.1.2-1, it
failed for me as follows:

[…]
Preparing to unpack .../5-invesalius_3.1.2-1_all.deb ...
Unpacking invesalius (3.1.2-1) over (3.1.1-1) ...
[…]
Preparing to unpack .../6-invesalius-bin_3.1.2-1_amd64.deb ...
Unpacking invesalius-bin (3.1.2-1) over (3.1.1-1) ...
[…]
Setting up invesalius-bin (3.1.2-1) ...
[…]
Setting up invesalius (3.1.2-1) ...
  File "/usr/share/invesalius/invesalius/data/editor.py", line 120
print "Comecei"
  ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean 
print("Comecei")?

  File "/usr/share/invesalius/invesalius/data/orientation.py", line 37
print "AXIAL"
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean 
print("AXIAL")?

  File "/usr/share/invesalius/invesalius/data/volume_widgets.py", line 68
print "send signal - update slice info in panel and in 2d"
 ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("send 
signal - update slice info in panel and in 2d")?

dpkg: error processing package invesalius (--configure):
 installed invesalius package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 invesalius

This can also be seen in this piuparts log:
https://piuparts.debian.org/sid/fail/invesalius_3.1.2-1.log

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

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

Versions of packages invesalius depends on:
ii  invesalius-bin3.1.2-1
ii  python3   3.6.6-1
ii  python3-gdcm  2.8.7-2
ii  python3-nibabel   2.3.0-1
ii  python3-numpy 1:1.14.5-1+b1
ii  python3-pil   5.2.0-2
ii  python3-psutil5.4.6-1+b1
ii  python3-scipy 1.1.0-1+b1
ii  python3-serial3.4-4
ii  python3-skimage   0.14.0-1
ii  python3-vtk7  7.1.1+dfsg1-5
ii  python3-vtkgdcm   2.8.7-2
ii  python3-wxgtk4.0  4.0.1+dfsg-6

invesalius recommends no packages.

invesalius suggests no packages.

-- no debconf information

Bug#908720: seahorse: does not list passwords for the login keyring

[Jeremy Bicha]

Control: tags -1 moreinfo

I can't reproduce this bug with the information you have provided.

Note that seahorse continues to run in the background as a system
service. I recommend logging out and logging back after upgrading
seahorse.

Thanks,
Jeremy Bicha

Bug#908588: Some more observations

[Paul Boddie]

Evidently, the "fix" doesn't seem to have the intended effect. Launching 
Akregator just now spawned three "HTTP Cache Cleaner" instances and the 
animated cursor, with the plasma-desktop process increasing its activity.

I suppose it is possible that the referenced .desktop file is not involved, 
but the /usr/lib/kde4/libexec/kio_http_cache_cleaner program does seem to be 
invoked.

Paul

Bug#908705: g_icon_to_string output includes some garbage prefix

[Jeremy Bicha]

Control: severity -1 serious
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/issues/1513

Ok, let's bump the severity to keep the new glib version from
migrating to Testing.

Thanks,
Jeremy Bicha

Bug#908721: firewalld: blocks mdns traffic on home zone (with mdns enabled)

[Sergio Villar Senin]

Package: firewalld
Version: 0.4.4.6-2
Severity: important

Dear Maintainer,

   * What led up to the situation?

   Upgrade to 0.6.1

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

   Using avahi-discover to list discoverable services in my LAN

   * What was the outcome of this action?

   Nothing was shown

   * What outcome did you expect instead?

   Available discoverable services are shown

I've activated mdns for home zone. The home zone is active but the mdns
traffic is blocked. I confirm that downgrading to 0.4.4.6 fixes the issue
with zero configuration changes.

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

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

Versions of packages firewalld depends on:
ii  dbus   1.12.10-1
ii  gir1.2-glib-2.01.58.0-1
ii  iptables   1.6.2-1.1
ii  policykit-10.105-21
ii  python33.6.6-1
ii  python3-dbus   1.2.8-2+b1
ii  python3-gi 3.28.3-1
ii  python3-slip-dbus  0.6.5-2

Versions of packages firewalld recommends:
ii  ebtables  2.0.10.4-5
ii  ipset 6.34-1

firewalld suggests no packages.

-- Configuration Files:
/etc/firewalld/firewalld.conf [Errno 13] Permiso denegado: 
'/etc/firewalld/firewalld.conf'
/etc/firewalld/lockdown-whitelist.xml [Errno 13] Permiso denegado: 
'/etc/firewalld/lockdown-whitelist.xml'

-- no debconf information

Bug#908720: seahorse: does not list passwords for the login keyring

[Sergio Villar Senin]

Package: seahorse
Version: 3.30-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

   Upgrading to 3.30

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

   Open seahorse. Click on the login keyring.

   * What was the outcome of this action?

   No password is shown

   * What outcome did you expect instead?

   Passwords are shown

However I didn't report this as data loss because the passwords are
there as services like email, browser etc... are working fine and I
can retrieve passwords with utilities like gkeyring for example.


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

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

Versions of packages seahorse depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  gcr  3.28.0-1
ii  gnome-keyring3.28.2-1
ii  gnupg2.2.10-1
ii  libatk1.0-0  2.28.1-1
ii  libavahi-client3 0.7-4
ii  libavahi-common3 0.7-4
ii  libavahi-glib1   0.7-4
ii  libc62.27-6
ii  libgck-1-0   3.28.0-1
ii  libgcr-base-3-1  3.28.0-1
ii  libgcr-ui-3-13.28.0-1
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libglib2.0-0 2.58.0-2
ii  libgpgme11   1.11.1-1
ii  libgtk-3-0   3.24.0-1
ii  libldap-2.4-22.4.46+dfsg-5
ii  libsecret-1-00.18.6-2
ii  libsoup2.4-1 2.64.0-2

Versions of packages seahorse recommends:
ii  openssh-client  1:7.8p1-1

seahorse suggests no packages.

-- no debconf information


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

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

Versions of packages seahorse depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  gcr  3.28.0-1
ii  gnome-keyring3.28.2-1
ii  gnupg2.2.10-1
ii  libatk1.0-0  2.28.1-1
ii  libavahi-client3 0.7-4
ii  libavahi-common3 0.7-4
ii  libavahi-glib1   0.7-4
ii  libc62.27-6
ii  libgck-1-0   3.28.0-1
ii  libgcr-base-3-1  3.28.0-1
ii  libgcr-ui-3-13.28.0-1
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libglib2.0-0 2.58.0-2
ii  libgpgme11   1.11.1-1
ii  libgtk-3-0   3.24.0-1
ii  libldap-2.4-22.4.46+dfsg-5
ii  libsecret-1-00.18.6-2
ii  libsoup2.4-1 2.64.0-2

Versions of packages seahorse recommends:
ii  openssh-client  1:7.8p1-1

seahorse suggests no packages.

-- no debconf information

Bug#908719: gtk: cursor indicator lost in gnome-terminal when switching applications

[Sergio Villar Senin]

Package: libgtk-3-0
Version: 3.24.0-1
Severity: important
File: gtk

Dear Maintainer,

When you open a gnome-terminal and then switch to another window then the
blinking cursor is lost. You can recover it by switching tabs in
gnome-terminal. Apparently only Wayland sessions are affected.

Reported upstream here: https://gitlab.gnome.org/GNOME/gtk/issues/1316

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

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

Versions of packages libgtk-3-0:amd64 depends on:
ii  adwaita-icon-theme   3.28.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.26.2-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-6
ii  libcairo-gobject21.15.12-1
ii  libcairo21.15.12-1
ii  libcolord2   1.3.3-2
ii  libcups2 2.2.8-5
ii  libepoxy01.4.3-1
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libglib2.0-0 2.58.0-2
ii  libgtk-3-common  3.24.0-1
ii  libharfbuzz0b1.8.8-2
ii  libjson-glib-1.0-0   1.4.2-4
ii  libpango-1.0-0   1.42.4-2
ii  libpangocairo-1.0-0  1.42.4-2
ii  libpangoft2-1.0-01.42.4-2
ii  librest-0.7-00.8.0-2
ii  libsoup2.4-1 2.64.0-2
ii  libwayland-client0   1.16.0-1
ii  libwayland-cursor0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.6-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-1
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-1
ii  libxkbcommon00.8.2-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 1.9-2

Versions of packages libgtk-3-0:amd64 recommends:
ii  libgtk-3-bin  3.24.0-1

Versions of packages libgtk-3-0:amd64 suggests:
ii  gvfs 1.38.0-2
ii  librsvg2-common  2.40.20-3

-- no debconf information

Bug#908718: O: mysql-utilities -- collection of scripts for managing MySQL servers

[Dmitry Smirnov]

Package: wnpp
Severity: normal
X-Debbugs-CC: mo...@debian.org
Control: affects -1 mysql-utilities mysql-workbench

I have no capacity left to maintain "mysql-utilities"...

Maintaining this package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see [1] for detailed 
instructions how to adopt a package properly.

[1]: https://www.debian.org/devel/wnpp/index.html#howto-o

-- 
Regards,
 Dmitry Smirnov.


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

Bug#908717: O: skydns -- DNS service discovery for etcd

[Dmitry Smirnov]

Package: wnpp
Severity: normal
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 skydns

Not sure if this package is still useful...

-- 
Regards,
 Dmitry Smirnov.


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

Bug#908716: RM: https-finder -- ROM; obsolete

[Dmitry Smirnov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 https-finder

Please remove "https-finder" from "unstable".

Once useful this package stopped working a while ago, has been abandoned 
upstream and finally lost compatibility with current Firefox.

Some alternatives available as per

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827174#8

-- 
Regards,
 Dmitry Smirnov.


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

Bug#908705: g_icon_to_string output includes some garbage prefix

[Philip Withnall]

On Wed, 2018-09-12 at 22:32 +0200, Eduard Bloch wrote:
> Package: libglib2.0-0
> Version: 2.58.0-3
> Severity: important
> 
> Hi,
> 
> one of the last releases in the last couple of weeks has broken the
> g_icon_to_string function. Previously, it did exactly what
> https://developer.gnome.org/gio/stable/GIcon.html#g-icon-to-string
> said
> and returned a proper short name or absolute path.
> 
> Now, it returns some nonsense, after this pattern:
> . GThemedIcon mpv mpv-symbolic
> 
> That's crap. For the example above,
> /usr/share/applications/mpv.desktop
> contains:
> Icon=mpv
> 
> And mpv is what I expect (following documentation)
> 
> Repro:
> 
> Run icewm-menu-fdo (from icewm-common package) and see a lot of those
> strings there except of the plain icon name.

See https://gitlab.gnome.org/GNOME/glib/issues/1513.

Philip

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

Bug#908715: RM: video-without-flash -- ROM; obsolete

[Dmitry Smirnov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: pkg-mozext-maintain...@lists.alioth.debian.org

Please remove "video-without-flash" from "unstable".

Once useful this package is progressively needless for the modern web which 
is leaving Flash to the past. 

This extension to Firefox has become obsolete when Firefox moved on to 
WebExtensions.

-- 
Regards,
 Dmitry Smirnov.


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

Bug#881564: A64-OLinuXino

[Rodrigo Exterckötter Tjäder]

On Wed, Sep 12, 2018 at 6:26 PM, Vagrant Cascadian  wrote:
> It's more than just a one-time test needed; someone needs to be willing
> to test new versions periodically, so we don't end up with an unusable
> u-boot installed on someone's machine in a stable release.
>
> For more information about being a tester, please see:
>
>   https://wiki.debian.org/U-boot
>   https://wiki.debian.org/U-boot/Status
>
> Most important is to run the tests with the default u-boot environment,
> otherwise you can end up with bugs leftover from older versions. For
> this reason, I avoid using saveenv from the u-boot prompt. Ideally also
> testing both a cold boot as well as reboot, and if possible various boot
> methods. You would also kind of serve as a point of contact to help
> troubleshoot issues with u-boot.

I don't have much experience with u-boot, but I'm willing to learn and
test new versions.

> If you're up for doing that and having your name and email in the
> debian/targets file listed with whatever board(s) you're willing to
> test, reply to the bug and I'll add it to the next upload!

Sure, no problem.

Bug#908714: RM: systemd-docker -- ROM; obsolete

[Dmitry Smirnov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org

Please remove "systemd-docker" from "unstable".

Upstream seems to abandon it and it was less useful than I thought it 
would...

-- 
Regards,
 Dmitry Smirnov.



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

Bug#908713: ITP: golang-github-knqyf263-go-cpe -- golang-github-knqyf263-go-cpe

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-go-cpe
  Version : 0.0~git20180327.659663f6
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-cpe
* License : Expat
  Programming Lang: golang
  Description: golang library for CPE(A Common Platform Enumeration 2.3)

go-cpe is a implementation of the CPE Naming and Matching algorithms, as
described in NIST IRs 7695 and 7696.

Bug#908711: pkgsel does not install updates with ABI changes (by default)

[Ben Hutchings]

Package: pkgsel
Version: 0.45
Tags: security
Severity: important

Security updates (and point releases) may include ABI bumps and new
binary packages for some source packages that don't have a stable ABI. 
In particular, linux has done this several times this year; KiBi
suggested that bind9 might sometimes do this.

Normally the installer will install a metapackage such as linux-image-
amd64, and a subsequent "apt upgrade" or "apt-get dist-upgrade" will
update this package and pull in the new kernel package.  Similarly
upgrades to bind9 will pull in the new library packages.

However, pkgsel by default runs "apt-get upgrade" which does *not* pull
in new packages as dependencies.  There is a debconf question
(pkgsel/upgrade) for what type of upgrade to do, but it's low priority,
and this is surely the wrong default behaviour.

I think that either the default for this question should be changed to
"full-upgrade", or the implementation of "safe-upgrade" should be
changed to "apt upgrade".  This installs new packages as dependencies
but doesn't remove anything.  I don't know if it's possible to get the
same behaviour through options to "apt-get".

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.



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

Bug#905906: RFS: hinawa-utils/0.1.0-1 [ITP]

[Hideki Yamane]

Hi,

>  - CUI tool for functionalities of Digidesign Digi 00x family

 CUI, maybe CLI? Perhaps we don't need it.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#908603: docker.io: consider backporting to stable

[Dmitry Smirnov]

Thank you for your kind words, Héctor.

On Thursday, 13 September 2018 2:55:52 AM AEST Héctor Orón Martínez wrote:
> The whole point to bring back `docker.io` package to Debian was to
> provide something usable in stable.

It is usable in stable, when installed from "testing" or "unstable".
Usually Golang-compiled static binaries are safe to use in "stable" because 
they have very few dependencies.

My point is that backporting all Docker's dependency tree is unjustifiable.
IMHO this time and effort would be better spent to address other outstanding 
problems...


> If we embedded in the package most of the vendoring, would that help
> on its future maintenance?

Not really... Besides security team would rightfully complain.
Un-vendoring is actually superior because unlike upstream we test the whole 
dependency tree. It would be regretful to lose that advantage.


> I know that might be a bit controversial however I think it might be
> the only way to keep docker.io in the distribution going further
> ahead.

Why would that be? We have dependencies under control now, aren't we?


> > Besides just keeping Docker in testing is a challenge due to build/test
> > failures routinely exposed by CI. Docker dependency tree is very big and
> > surface for problems is enormous.
> 
> Are you using Gitlab provided CI/CD features to track that? I'd need
> to get up to speed with those.

No, it is usually bugs filed for failures in Debian CI and reproducible build 
infrastructure. See recent #907764, #907432. Because of bugs like this 
docker.io is regularly targeted for removal from "testing".

-- 
Best wishes,
 Dmitry Smirnov.

---


The more false we destroy the more room there will be for the true.
 -- Robert G. Ingersoll, 1902


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

Bug#891392: Successfully compiled ad

[sergio]

I've just successfully compiled (and started) 0.22.3-2 with the patch above.

It works, but not suitable for daily usage (no screen rotation, multiple 
glitches and artefacts, slow response for some apps)




it broke X11 support for my own setup.


But it doesn't break X11 support for me


--
sergio.

Bug#907737: liblucy-perl: Project Lucy has retired

[Jonas Smedegaard]

control: reassign 907737 ftp.debian.org
control: retitle 907737 RM: liblucy-perl -- ROM; dead upstream

Hi Ftpmasters,

Please drop liblucy and libcatmandu-store-lucy-perl from sid.

Quoting Xavier (2018-09-12 23:35:34)
> Le 10/09/2018 à 00:54, Dominic Hargreaves a écrit :
> > On Sat, Sep 01, 2018 at 05:48:22PM +0100, Dominic Hargreaves wrote:
> >> On Sat, Sep 01, 2018 at 04:42:36PM +0200, Jonas Smedegaard wrote:
> >>> Quoting Xavier Guimard (2018-09-01 08:46:22)
>  Package: liblucy-perl
>  Version: Project Lucy has retired
>  Severity: important
> 
>  As announced in http://lucy.apache.org/, project Lucy has retired. I
>  think we should remove it from buster
> >>>
> >>> liblucy-perl has two reverse dependencies:
> >>>
> >>>   * openguides
> >>>   * libcatmandu-store-lucy-perl
> >>>
> >>> It is fine by me to drop libcatmandu-store-lucy-perl with liblucy-perl: 
> >>> Other Catmandu search backends exist but need to be packaged, but 
> >>> shipping no Catmandu search backend is better than shipping a backend 
> >>> dead upstream!
> >>>
> >>> @Dominique: Is it ok to drop openguides, or can it be made to not depend 
> >>> on liblucy-perl?
> >>
> >> I am still interested in OpenGuides (I run several instances using
> >> the Debian package).
> >>
> >> I suspect not that many users use Lucy, so I'm fine with dropping that
> >> dependency. Please ping me in a couple of weeks if I haven't got around
> >> to that.
> > 
> > That's now done in openguides 0.82-2.
> > 
> > Thanks,
> > Dominic.
> 
> Hello Jonas,
> 
> let's start removing libcatmandu-store-lucy-perl and liblucy-perl ?

Hereby done.  Thanks for nudging, Xavier!

 - Jonas

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

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


signature.asc
Description: signature

Bug#908323: libgtk3-perl: FTBFS: t/overrides.t failure

[gregor herrmann]

On Wed, 12 Sep 2018 13:42:16 +0100, Iain Lane wrote:

> > I tried with
> > 
> > #v+
> > --- a/lib/Gtk3.pm
> > +++ b/lib/Gtk3.pm
> > [...]
> > #v-
> 
> This diff looks correct to me - I think it could be forwarded upstream
> and/or uploaded.

Thanks!
Uploading right now is a bit difficult as the tests still fail due to
the next issue :) But I'll prepare it as a proper patch.
 
> > but then the tests failed differently, with:
> > 
> > Gtk3::Gdk::Pixbuf::new_from_inline: passed too few parameters (expected 4, 
> > got 3) at t/overrides.t line 762.
> > # Looks like your test exited with 255 just after 162.
> 
> ...and this one is a real bug in gdk-pixbuf. I forwarded a potential fix
> to upstream - will wait a little while to see what they say. I've
> confirmed that after applying the patch already in this bug and that
> proposed patch libgtk3-perl's autopkgtests pass again. Once it gets an
> ack or if there is no reply then I'll upload to Debian.

That's great news, thanks.
Please give us a short ping once the fixed package is available.


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: Donovan: Celia Of The Seals


signature.asc
Description: Digital Signature

Bug#908365: Package fails to build reproducibly

[Vagrant Cascadian]

On 2018-09-10, Michael Biebl wrote:
> Am 10.09.18 um 19:22 schrieb Chris Lamb:
>>> Now, I could try and convince upstream to not embed ABS_BUILD_DIR into
>>> the binary and maybe let the build system pass the build dir as env var.
>>> This would make those test-binaries a bit more cumbersome to use though,
>>> because you'd have to manually set the env var if you directly execute
>>> the test by hand.
>> 
>> Hm, could you not install the test data to /usr/systemd/private/path>
>> whatever and then make the tests default to this,
>
> The binaries have a builtin check, which tests if they are executed from
> the build directory, and if so, use the data files from the build
> directory. Otherwise they use the datafiles from
> /usr/lib/systemd/tests/testdata/
>
>>  overiddable by the
>> said env var? That would avoid the ugly requirement to set it manually
>> at the very least.
>
> If you run the test directly from the build directory, it's reasonable
> to assume that you actually want to use the data files from the build
> directory as well and not the ones from the installed system.
> Atm the binaries auto-detect that by encoding the build directory into
> the binary.

Is it plausible to strip the embedded build directory information out of
the test binaries with the binaries shipped in the package, since they
will almost certainly not have access to the original build directory,
and it interferes with the reproducibility of the test package...

Alternately, run two builds of the test binaries, one during the build
which contain the embedded build dir, and a second time setting the
value to match the shipped package.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#907737: liblucy-perl: Project Lucy has retired

[Xavier]

Le 10/09/2018 à 00:54, Dominic Hargreaves a écrit :
> On Sat, Sep 01, 2018 at 05:48:22PM +0100, Dominic Hargreaves wrote:
>> On Sat, Sep 01, 2018 at 04:42:36PM +0200, Jonas Smedegaard wrote:
>>> Quoting Xavier Guimard (2018-09-01 08:46:22)
 Package: liblucy-perl
 Version: Project Lucy has retired
 Severity: important

 As announced in http://lucy.apache.org/, project Lucy has retired. I
 think we should remove it from buster
>>>
>>> liblucy-perl has two reverse dependencies:
>>>
>>>   * openguides
>>>   * libcatmandu-store-lucy-perl
>>>
>>> It is fine by me to drop libcatmandu-store-lucy-perl with liblucy-perl: 
>>> Other Catmandu search backends exist but need to be packaged, but 
>>> shipping no Catmandu search backend is better than shipping a backend 
>>> dead upstream!
>>>
>>> @Dominique: Is it ok to drop openguides, or can it be made to not depend 
>>> on liblucy-perl?
>>
>> I am still interested in OpenGuides (I run several instances using
>> the Debian package).
>>
>> I suspect not that many users use Lucy, so I'm fine with dropping that
>> dependency. Please ping me in a couple of weeks if I haven't got around
>> to that.
> 
> That's now done in openguides 0.82-2.
> 
> Thanks,
> Dominic.

Hello Jonas,

let's start removing libcatmandu-store-lucy-perl and liblucy-perl ?

Cheers,
Xavier

Bug#908709: linux: please enable module sch_cake

[Jonas Smedegaard]

Source: linux
Version: 4.19~rc2-1~exp1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Linux 4.19 introduces an exciting new network queueing algorithm,
sch_cake.

More about Cake at  and upstream at
.

Corresponding config option is CONFIG_NET_SCH_CAKE.

Please enable CONFIG_NET_SCH_CAKE for all architectures: Cake is useful
also on tiny systems used for routing traffic for home networks.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAluZheMACgkQLHwxRsGg
ASEGgBAAkSnMKM6WDN0aDRkuZPG7mf+AbzkyscJ3Ei7Z0695DMVYSITsWfcf/OdK
UN1GPaWbM4Id+wrk+PhsvBDDfzZMWneyCem+qT2kvDhiQV1zQ+H2bpMCJLSMOidS
8Efe4y2T8DAeO/Eu7p93VVM/2MDhDwrXQ909fPdd12UCAgInTMhL5IKe2Vb6tEll
eOZ5EnIjnNPO2F970Cw3NwL7tX4QDnd3C4khfpdGu6fdWiOrps+hKPRwGSOHk1Ul
ryJXVgddrQ03PGgM8C/f5Or35It1rtq7zndMLG/fCfNY97q5QvP50dTjvmuPLJoh
IM8Y6Zng1o8LcyKDxqxt3r2GUHSjrMSYbSrPLAoauKel2mMwz0acZOXwz4JzyLVv
KFNsXrY3MVVft9shzrvKKSSNeMHT9eloaSIJb1El9HLkd2K0sD1UxfPZNrTA9SCd
g2x47Qzzd7GAVo9PkF1JMoFVKnzYcEE62HzuNzh958l1tfCat4AfsLGTboDg82pw
iN8mzO2VcfFaZ3QU83t575AR5XSiVKCJ0ueaxyPab9N939YrSSsIxRY2HkPTNiPT
UBFajxDZFWzfkkolvuCsrb5W7Q7JeK9vXsSC4OSwrglWkzGPBVqSvE2MhOIaeWrN
d1IbdzaN5Gy8NUGG1xdyjcsSF7JJMdtS3Rz8vACj+KMsw+2CA7s=
=Txb8
-END PGP SIGNATURE-

Bug#908710: Documentation for asciicast format not provided

[Josh Triplett]

Package: asciinema
Version: 2.0.1-1
Severity: normal

The manpage for asciinema references a "doc/asciicast-v2.md" describing
the format, but doesn't provide a full URL for that document, and the
package has no local copy. (Personally, I would prefer a URL rather than
a local copy.)

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

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

Versions of packages asciinema depends on:
ii  python33.6.6-1
ii  python3-pkg-resources  40.2.0-1

asciinema recommends no packages.

asciinema suggests no packages.

-- no debconf information

Bug#881564: A64-OLinuXino

[Vagrant Cascadian]

On 2018-09-12, Rodrigo Exterckötter Tjäder wrote:
> I just got an A64-OLinuXino and would like to get Debian working on
> it. It seems to be that getting u-boot-sunxi to ship a version for
> this board is the first step.

Thanks for taking an interest!


> It seems this bug is on hold because there is no one available to test
> it. Is there anything I can do to help with that?

It's more than just a one-time test needed; someone needs to be willing
to test new versions periodically, so we don't end up with an unusable
u-boot installed on someone's machine in a stable release.

For more information about being a tester, please see:

  https://wiki.debian.org/U-boot
  https://wiki.debian.org/U-boot/Status

Most important is to run the tests with the default u-boot environment,
otherwise you can end up with bugs leftover from older versions. For
this reason, I avoid using saveenv from the u-boot prompt. Ideally also
testing both a cold boot as well as reboot, and if possible various boot
methods. You would also kind of serve as a point of contact to help
troubleshoot issues with u-boot.

I test quite a few boards myself, but I can't test all boards, and it's
nice to share the work with others.

I should probably add some of this to the wiki...

If you're up for doing that and having your name and email in the
debian/targets file listed with whatever board(s) you're willing to
test, reply to the bug and I'll add it to the next upload!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#908708: networking-l2gw: FTBFS (ImportError: cannot import name 'topics')

[Santiago Vila]

Package: src:networking-l2gw
Version: 1:12.0.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
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
dh build-indep --buildsystem=python_distutils --with python3
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_autoreconf -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions

[... snipped ...]

from neutron.common import topics as neutron_topics
ImportError: cannot import name 'topics'

Failed to import test module: 
networking_l2gw.tests.unit.services.l2gateway.service_drivers.test_rpc_l2gw
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File 
"/<>/networking_l2gw/tests/unit/services/l2gateway/service_drivers/test_rpc_l2gw.py",
 line 26, in 
from networking_l2gw.services.l2gateway.ovsdb import data
  File "/<>/networking_l2gw/services/l2gateway/ovsdb/data.py", 
line 21, in 
from networking_l2gw.services.l2gateway.common import tunnel_calls
  File 
"/<>/networking_l2gw/services/l2gateway/common/tunnel_calls.py", 
line 16, in 
from neutron.common import topics as neutron_topics
ImportError: cannot import name 'topics'

Failed to import test module: 
networking_l2gw.tests.unit.services.l2gateway.test_agent_scheduler
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File 
"/<>/networking_l2gw/tests/unit/services/l2gateway/test_agent_scheduler.py",
 line 26, in 
from neutron.common import topics
ImportError: cannot import name 'topics'

--
Ran 0 tests in 2.641s

OK
+ subunit-stats
+ subunit-filter -s --no-passthrough
+ cat /tmp/tmp.p2QwnkCvrS
Total tests:   0
Passed tests:  0
Failed tests:  0
Skipped tests: 0
Seen tags: 
+ rm -f /tmp/tmp.p2QwnkCvrS
+ testr-python3 slowest
make[1]: *** [debian/rules:26: override_dh_install] Error 3
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


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

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

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

Unfortunately, I can't compare build logs with the official ones at
buildd.debian.org because they do not exist:

https://buildd.debian.org/status/package.php?p=networking%2dl2gw

Please reconsider uploading in source-only form.

Thanks.

Bug#906215: foolscap autopkgtest needs update for new version of twisted

[Santiago Vila]

severity 906215 serious
tags 906215 + ftbfs
thanks

On Wed, 15 Aug 2018, Paul Gevers wrote:

> ===
> [FAIL]
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py",
> line 1418, in _inlineCallbacks
> result = g.send(result)
>   File "/usr/lib/python2.7/dist-packages/foolscap/test/test_info.py",
> line 151, in testListener
> % self._portnum)
>   File "/usr/lib/python2.7/dist-packages/twisted/trial/_synctest.py",
> line 432, in assertEqual
> super(_Assertions, self).assertEqual(first, second, msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> twisted.trial.unittest.FailTest: "Listener on IPv4Address(type='TCP',
> host='127.0.0.1', port=40243)" != "Listener on IPv4Address(TCP,
> '127.0.0.1', 40243)"
> 
> foolscap.test.test_info.Connect.testListener

This is the same error I see in my autobuilder, and also the same
error which happens in reproducible builds, see for example the recent
i386 build:

https://tests.reproducible-builds.org/debian/rbuild/buster/i386/foolscap_0.13.1-1.rbuild.log.gz

Raising severity because this is also a FTBFS bug.

Thanks.

Bug#908707: llvm-toolchain-7: Enable -DLLVM_USE_PERF=yes when building for linux

[Andres Freund]

Source: llvm-toolchain-7
Severity: wishlist

Hi,

Since 7 llvm has support for generating perf profiling data for JITed
code. That's useful, in my case, to be able to profile postgres 11+
when it uses JIT.

Thanks,

Andres

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

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

Bug#908290: [zfs-linux] Please package 0.7.10

[Holger Schröder]

Am 12.09.18 um 20:48 schrieb Antonio Russo:

If you're interested in 0.8.0, you can check out [1], which references [2],
which is sufficient to build your own (git master) zfs. Notice that spl
is merged into zfs, so that massively simplifies packaging.  Just download
0.8.0-rc1, copy that debian directory from [2] into the source, update
the changelog (dch), and then compile with

debuild -b -us -uc

I'm committed to keeping that packaging suited for building both git-master
and the 0.8.* release branch. I'd recommend building this yourself instead
of waiting for it to get uploaded to experimental, given how little interest
there was in this git packaging for the last 6 months [3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900862
[2] https://salsa.debian.org/aerusso-guest/zfs/commits/debian/git
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891890


Thanks ... done

Bug#900042: evince: AppArmor profile denies access to temporary directory

[John Scott]

> does this break functionality for you or is it "merely" causing noise
> in the logs / apparmor-notify?

I can't reproduce the issue, and I don't recall it breaking
functionality. In hindsight, this bug was frivolous, and I'll have more
discretion in the future.


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

Bug#881564: A64-OLinuXino

[Rodrigo Exterckötter Tjäder]

Hello,

I just got an A64-OLinuXino and would like to get Debian working on
it. It seems to be that getting u-boot-sunxi to ship a version for
this board is the first step.

It seems this bug is on hold because there is no one available to test
it. Is there anything I can do to help with that?

Bug#908516: Apparmor profile breaks print preview

[Simon McVittie]

On Mon, 10 Sep 2018 at 13:58:41 -0400, Ryan Kavanagh wrote:
> Adding the
> following line to /etc/apparmor.d/usr.bin.evince seems to fix the issue,
> though you should probably consult apparmor.d(5) and pick something more
> sensible that "uxr" as a permission:
> 
>   /usr/lib/@{multiarch}/glib-2.0/gio-launch-desktop uxr,

rmix seems more appropriate - that would allow gio-launch-desktop to
execute anything that evince itself would have been allowed to execute
directly, with evince's own privileges.

gio-launch-desktop is an implementation detail of GIO and should be
executed with the same privileges that library code in its caller would
have: it replaces a direct fork-and-exec code path in older GIO, as a
way to allow use of posix_spawn(), which has a smaller virtual memory
footprint. It is definitely not designed to be a security boundary. It
executes whatever is in argv[1, 2...] with GIO_LAUNCHED_DESKTOP_FILE_PID
added to the environment, so if you are allowed to execute it unconfined,
you are allowed to execute anything else unconfined too. That would
be bad.

smcv

Bug#891994: epigrass: Depends on Qt4-only python-qwt5-qt4

[Gudjon I. Gudjonsson]

Hi

On Wednesday, 12 September 2018 21:01:16 CEST Flavio Coelho wrote:
> This error seems to be due to missing "dbfread" package which is available
> on Debian as "python3-dbfread"

You are right but epigrass is built with python2 on Debian but dbfread is only 
built 
with python3 even if it is documented to work with python2.7.

Does epigrass work with pyhton3?

I tried to find the upstream sources for epigrass but the newest version I 
could find is 2.4.5 
but version 2.4.7 is in Debian.

Regards
Gudjon

Bug#908704:

[Ricardo Ribalda Delgado]

Propossed patch

-- 
Ricardo Ribalda
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 3fcaa98..50a7c93 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -318,14 +318,23 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
 DP_TRAINING_PATTERN_DISABLE);
 }
 
+#define N_TRIES 20
 void
 intel_dp_start_link_train(struct intel_dp *intel_dp)
 {
 	struct intel_connector *intel_connector = intel_dp->attached_connector;
+	int tries;
 
-	if (!intel_dp_link_training_clock_recovery(intel_dp))
-		goto failure_handling;
-	if (!intel_dp_link_training_channel_equalization(intel_dp))
+	for (tries = 0; tries < N_TRIES; tries++) {
+		if (!intel_dp_link_training_clock_recovery(intel_dp)){
+			msleep(10);
+			continue;
+		}
+		if (intel_dp_link_training_channel_equalization(intel_dp))
+			break;
+	}
+
+	if (tries == N_TRIES)
 		goto failure_handling;
 
 	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate = %d, Lane count = %d",

Bug#908706: torbrowser-launcher: error on torbrowser-launcher first install: exceptions.AttributeError: 'NoneType' object has no attribute 'bio_read'

[stefan esterer]

Package: torbrowser-launcher
Version: 0.2.9-3
Severity: important

Hi!

After installing the torbrowser-launcher package on my system I tried to
run it as a user it tries to download the tor browser but if fails with
an python exception:

Downloading and installing Tor Browser for the first time.
Downloading
https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US
Latest version: 8.0
Downloading
https://dist.torproject.org/torbrowser/8.0/tor-browser-linux64-8.0_de.tar.xz.asc
Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line
103, in callWithLogger
return callWithContext({"system": lp}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line
86, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py",
line 122, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py",
line 85, in callWithContext
return func(*args,**kw)
---  ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py",
line 614, in _doReadOrWrite
why = selectable.doRead()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line
243, in doRead
return self._dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line
249, in _dataReceived
rval = self.protocol.dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/endpoints.py",
line 125, in dataReceived
return self._wrappedProtocol.dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/tls.py", line
330, in dataReceived
self._flushReceiveBIO()
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/tls.py", line
300, in _flushReceiveBIO
self._flushSendBIO()
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/tls.py", line
252, in _flushSendBIO
bytes = self._tlsConnection.bio_read(2 ** 15)
exceptions.AttributeError: 'NoneType' object has no attribute 'bio_read'

Downloading
https://dist.torproject.org/torbrowser/8.0/tor-browser-linux64-8.0_de.tar.xz
Verifying Signature
Extracting tor-browser-linux64-8.0_de.tar.xz
Running
/home/stefan/.local/share/torbrowser/tbb/x86_64/tor-browser_de/start-tor-browser.desktop
Launching './Browser/start-tor-browser --detach'...
Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line
103, in callWithLogger
return callWithContext({"system": lp}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line
86, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py",
line 122, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py",
line 85, in callWithContext
return func(*args,**kw)
---  ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py",
line 614, in _doReadOrWrite
why = selectable.doRead()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line
243, in doRead
return self._dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line
249, in _dataReceived
rval = self.protocol.dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/endpoints.py",
line 125, in dataReceived
return self._wrappedProtocol.dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/tls.py", line
330, in dataReceived
self._flushReceiveBIO()
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/tls.py", line
300, in _flushReceiveBIO
self._flushSendBIO()
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/tls.py", line
252, in _flushSendBIO
bytes = self._tlsConnection.bio_read(2 ** 15)
exceptions.AttributeError: 'NoneType' object has no attribute 'bio_read'

Is there any other information I can provider? Am I am making a mistake?

thx

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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20170717
ii  gnupg 2.2.10-1
ii  libdbus-glib-1-2  0.110-3
ii  python2.7.15-3
ii  python-gtk2   2.24.0-5.1+b1
ii  python-lzma   0.5.3-3.1
ii  python-parsley1.2-1
ii  python-psutil 5.4.6-1+b1
ii  python-twisted

Bug#908704: linux-image-4.18.0-1-amd64: Fix downgraded resolutions for Display Port

[Ricardo Ribalda Delgado]

Package: src:linux
Version: 4.18.6-1
Severity: normal

Dear Maintainer,

Some High Resolution Screens are downgraded to full HD due to DP link
training failures.This problem can be easily solved by allowing retries 
during DP link training. 

If the hardware is capable of running at high resolution the
link will be properly calibrated after 2 o 3 attempts. If the hardware
cannot run at that resolution the link will be downgraded in less than a
second.

The proposed patch is self contained and has been tested successfuly on
4 different kernels (4.15 - 4.18).

This bug has been replicated on multiple devices and screens and
notified to upstream: https://bugs.freedesktop.org/show_bug.cgi?id=106223

Unfortunately it is considered low-priority for Intel (but high-annoying
by the users).

Hopefully this patch will allow users to make full use of their screens
and I will spend less time rebuilding my kernel.

-- Package-specific info:
** Version:
Linux version 4.18.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.6-1 (2018-09-06)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.18.0-1-amd64 
root=UUID=4ac4c7fd-7b0a-4fc0-a4aa-e063d18bfe9f ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[3.828853] usb 1-3.1.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[3.828854] usb 1-3.1.1: Product: Lenovo USB Optical Mouse
[3.828855] usb 1-3.1.1: Manufacturer: PixArt
[3.956542] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC255: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[3.956546] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[3.956549] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[3.956550] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[3.956552] snd_hda_codec_realtek hdaudioC0D0:inputs:
[3.956554] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x12
[3.964026] usb 1-3.1.2: new low-speed USB device number 9 using xhci_hcd
[4.122473] usb 1-3.1.2: New USB device found, idVendor=04b3, 
idProduct=3025, bcdDevice= 1.02
[4.122480] usb 1-3.1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[4.122484] usb 1-3.1.2: Product: USB NetVista Full Width Keyboard
[4.122488] usb 1-3.1.2: Manufacturer: CHICONY
[4.233894] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[4.234952] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[4.235066] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input17
[4.235176] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input18
[4.235283] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input19
[4.235389] input: HDA Intel PCH HDMI/DP,pcm=9 as 
/devices/pci:00/:00:1f.3/sound/card0/input20
[4.235493] input: HDA Intel PCH HDMI/DP,pcm=10 as 
/devices/pci:00/:00:1f.3/sound/card0/input21
[4.436110] media: Linux media interface: v0.10
[4.446085] videodev: Linux video capture interface: v2.00
[4.453678] uvcvideo: Found UVC 1.00 device XiaoMi USB 2.0 Webcam (05c8:03a2)
[4.462195] Bluetooth: Core ver 2.22
[4.462204] NET: Registered protocol family 31
[4.462205] Bluetooth: HCI device and connection manager initialized
[4.462208] Bluetooth: HCI socket layer initialized
[4.462209] Bluetooth: L2CAP socket layer initialized
[4.462213] Bluetooth: SCO socket layer initialized
[4.465409] usbcore: registered new interface driver btusb
[4.466339] Bluetooth: hci0: Bootloader revision 0.0 build 26 week 38 2015
[4.467345] Bluetooth: hci0: Device revision is 16
[4.467346] Bluetooth: hci0: Secure boot is enabled
[4.467347] Bluetooth: hci0: OTP lock is enabled
[4.467347] Bluetooth: hci0: API lock is enabled
[4.467348] Bluetooth: hci0: Debug lock is disabled
[4.467349] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[4.468378] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-12-16.sfi
[4.468381] Bluetooth: hci0: Found device firmware: intel/ibt-12-16.sfi
[4.471474] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not 
initialized!
[4.471475] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not 
initialized!
[4.471476] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not 
initialized!
[4.471477] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not 
initialized!
[4.471530] input: XiaoMi USB 2.0 Webcam: XiaoMi U as 
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input22
[4.471579] usbcore: registered new interface driver uvcvideo
[4.471579] USB Video Class driver (1.1.1)
[4.485825] ln0_1:0x0 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0xcc 
adj_req2_3:0x0
[4.485827] Clock recovery check failed, cannot continue 

Bug#908705: g_icon_to_string output includes some garbage prefix

[Eduard Bloch]

Package: libglib2.0-0
Version: 2.58.0-3
Severity: important

Hi,

one of the last releases in the last couple of weeks has broken the
g_icon_to_string function. Previously, it did exactly what
https://developer.gnome.org/gio/stable/GIcon.html#g-icon-to-string said
and returned a proper short name or absolute path.

Now, it returns some nonsense, after this pattern:
. GThemedIcon mpv mpv-symbolic

That's crap. For the example above, /usr/share/applications/mpv.desktop
contains:
Icon=mpv

And mpv is what I expect (following documentation)

Repro:

Run icewm-menu-fdo (from icewm-common package) and see a lot of those
strings there except of the plain icon name.

Regards,
Eduard.


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

Kernel: Linux 4.18.5 (SMP w/4 CPU cores; PREEMPT)
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/bash
Init: systemd (via /run/systemd/system)

-- 
Die Zeit ist schlecht? Wohlan! Du bist da, sie besser zu machen.
-- Thomas Carlyle

Bug#907704: choose-mirror: default to deb.debian.org

[Julien Cristau]

On Wed, Sep 12, 2018 at 21:57:41 +0200, Philipp Kern wrote:

> On 10.09.2018 09:20, Philipp Kern wrote:
> > [+mirrors@]
> > 
> > On 07.09.2018 14:42, Julien Cristau wrote:
> >> Control: retitle -1 choose-mirror: hide mirror selection by default
> >>
> >> On 09/04/2018 11:07 AM, Julien Cristau wrote:
> >>> If switching the mirror question from high to medium priority proves
> >>> controversial I guess I could separate that to its own bug too, to at
> >>> least get the default changed.
> >> Since there still seems to be some discussion around that, I'm going to
> >> use bug#797340 to make deb.debian.org the default, and repurpose this
> >> bug to stop asking the mirror country + hostname questions by default.
> > 
> > What's mirroradm's take on this?
> 
> For the record, this change just landed in unstable.
> 
"This change" being "select deb.d.o as the default mirror".  The
country and mirror questions are still "high" priority so shown by
default, for now.

Cheers,
Julien

Bug#908699: gitolite3: prevent access to repos which are in the process of bring migrated

[Salvatore Bonaccorso]

hi David,

On Wed, Sep 12, 2018 at 05:03:40PM -0300, David Bremner wrote:
> Salvatore Bonaccorso  writes:
> 
> > Source: gitolite3
> > Version: 3.6.6-1
> > Severity: important
> > Tags: security upstream
> >
> > Hi
> >
> > Filling this for tracking, David did you or upstream requested
> > accordingly a CVE?
> >
> > Announce: 
> > https://groups.google.com/forum/#!topic/gitolite-announce/WrwDTYdbfRg
> > Fix: 
> > https://github.com/sitaramc/gitolite/commit/dc13dfca8fdae5634bb0865f7e9822d2a268ed59
> >
> 
> I'm not aware of a related CVE.

Okay, I just have requested one.

Regards,
Salvatore

Bug#908702: linux-image-4.18.0-1-amd64 prevents use of internet (more or less)

[ghpy]

Package: linux-image-4.18.0-1-amd64
Version: 4.18.6-1
Severity: Grave


Dear maintainer,

after today's upgrade from 4.17.0-3 to 4.18.0-1 internet access is hardly 
possible anymore. Speed is less than 5 % of what is used to be and for that 
reason the browser frequently shows "No internet connection" instead of a 
webpage.

Checking with another system at the same time shows that the internet 
connection as such is working fine. Booting the system with the old kernel 
4.17.0-3 the problem does not arise, so the problem most probably is caused by 
4.18.0-1 (or a package used by 4.18.0-1 but not by 4.17.0-3) and not by jointly 
used packages or hardware. Log files are identical as far as I can see and my 
system is up to date (tracking testing, just missing the most recent updates of 
irrelevant packages like libreoffice and vlc). Connection to the internet is by 
LAN to a Huawei LTE router.

Due to bug #908578 I could not use reportbug to file this bug. Sorry if this 
means that some information is missing.

Best regards
G. Heine

Bug#908703: ITP: r-cran-purrrlyr -- GNU R Tools at the Intersection of 'purrr' and 'dplyr'

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-purrrlyr
  Version : 0.0.3
  Upstream Author : Lionel Henry, Hadley Wickham, RStudio
* URL : https://cran.r-project.org/package=purrrlyr
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R Tools at the Intersection of 'purrr' and 'dplyr'
 This GNU R package provides some functions at the intersection of
 r-cran-dplyr and and r-cran-purrr that formerly lived in the
 package r-cran-purrr.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-purrrlyr
This package is needed to run the autopkgtest of r-cran-snakecase.

Bug#908688: flask FTBFS with sphinx 1.7.9-1

[Dmitry Shachnev]

Hi,

On Wed, Sep 12, 2018 at 06:08:56PM +0300, Adrian Bunk wrote:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/flask.html
>
> ...
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/sphinx/config.py", line 161, in 
> __init__
> execfile_(filename, config)
>   File "/usr/lib/python3/dist-packages/sphinx/util/pycompat.py", line 150, in 
> execfile_
> exec_(code, _globals)
>   File "conf.py", line 7, in 
> from pallets_sphinx_themes import DocVersion, ProjectLink, get_version
> ImportError: cannot import name 'DocVersion'

This is caused not by sphinx update, but by python-pallets-sphinx-themes.

In this commit DocVersion import has been removed from __init__.py:
https://github.com/pallets/pallets-sphinx-themes/commit/ddc96f76d61238af

It now needs to be explicitly imported from pallets_sphinx_themes.versions.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#908701: smcroute: debian/copyright is inaccurate

[Micha Lenk]

Source: smcroute
Version: 2.0.0-1
Severity: normal

The debian/copyright file is inaccurate for the smcroute package. It
claims that smcroute is consistently licensed under GNU GPL (v2 or
later), but in fact some files are licensed under different licenses.

parse-conf.c: ISC
pidfile.c: BSD (2 clause)

Please update the debian/copyright so that it is more accurate.

Thanks!

Bug#908699: gitolite3: prevent access to repos which are in the process of bring migrated

[David Bremner]

Salvatore Bonaccorso  writes:

> Source: gitolite3
> Version: 3.6.6-1
> Severity: important
> Tags: security upstream
>
> Hi
>
> Filling this for tracking, David did you or upstream requested
> accordingly a CVE?
>
> Announce: 
> https://groups.google.com/forum/#!topic/gitolite-announce/WrwDTYdbfRg
> Fix: 
> https://github.com/sitaramc/gitolite/commit/dc13dfca8fdae5634bb0865f7e9822d2a268ed59
>

I'm not aware of a related CVE.

Bug#908689: python-click: updated

[Alexandre Viau]

Hello,

On 2018-09-12 11:33 AM, Félix Sipma wrote:
> Why didn't you wait 7.0 to be released before uploading
> 6.7+git20180829-1?

The new version of Sphinx broke the build for click 6.7's documentation.

See bug #906550

Since then, Click's documentation build system has evolved upstream,
getting 6.7 to build with the current version of Sphinx would require
fixing a lot of code. I eventually gave up on it and uploaded a newer
version of click instead.

Should you be interested in fixing 6.7 to build in unstable, I would be
willing to accept the patch and upload via it a +really suffix.

What do you suggest?

-- 
Alexandre Viau
alexan...@alexandreviau.net



signature.asc
Description: OpenPGP digital signature

Bug#908700: pep8: FTBFS (test_checkers_testsuite fails)

[Santiago Vila]

Package: src:pep8
Version: 1.7.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
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
dh  build-indep --buildsystem=python_distutils --with python2,python3
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   dh_auto_build -i -O--buildsystem=python_distutils
dh_auto_build: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_build: This feature will be removed in compat 12.
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
python setup.py build --force
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
copying pep8.py -> build/lib.linux-x86_64-2.7
running egg_info
writing pep8.egg-info/PKG-INFO
writing namespace_packages to pep8.egg-info/namespace_packages.txt
writing top-level names to pep8.egg-info/top_level.txt
writing dependency_links to pep8.egg-info/dependency_links.txt
writing entry points to pep8.egg-info/entry_points.txt
reading manifest file 'pep8.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files matching '*.pyc' found under directory 
'docs'
warning: no previously-included files matching '*.pyo' found under directory 
'docs'
warning: no previously-included files matching '*.pyc' found under directory 
'testsuite'
warning: no previously-included files matching '*.pyo' found under directory 
'testsuite'
no previously-included directories found matching 'docs/_build'
writing manifest file 'pep8.egg-info/SOURCES.txt'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
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
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
set -xe; \
for py in python2.7 python3.6; do \
$py setup.py test; \
done
+ python2.7 setup.py test
running test
running egg_info
writing pep8.egg-info/PKG-INFO
writing namespace_packages to pep8.egg-info/namespace_packages.txt
writing top-level names to pep8.egg-info/top_level.txt
writing dependency_links to pep8.egg-info/dependency_links.txt
writing entry points to pep8.egg-info/entry_points.txt
reading manifest file 'pep8.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files matching '*.pyc' found under directory 
'docs'
warning: no previously-included files matching '*.pyo' found under directory 
'docs'
warning: no previously-included files matching '*.pyc' found under directory 
'testsuite'
warning: no previously-included files matching '*.pyo' found under directory 
'testsuite'
no previously-included directories found matching 'docs/_build'
writing manifest file 'pep8.egg-info/SOURCES.txt'
running build_ext
test_checkers_testsuite (testsuite.test_all.Pep8TestCase) ... 
/<>/testsuite/W29.py:13:1: W391:1:1 blank line at end of file
/<>/testsuite/W29.py:14:1: error W292:1:5 not found
/<>/testsuite/W29.py:15:1: W391:1:1 blank line at end of file
/<>/testsuite/W29.py:16:1: error W292:1:27 not found
/<>/testsuite/W29.py:17:1: W391:1:1 blank line at end of file
/<>/testsuite/W29.py:18:1: error W292:3:22 not found
/<>/testsuite/W29.py:21:1: W391:3:1 blank line at end of file
FAIL
test_doctest (testsuite.test_all.Pep8TestCase) ... ok
test_own_dog_food (testsuite.test_all.Pep8TestCase) ... ok
test_selftest (testsuite.test_all.Pep8TestCase) ... ok
test_check_nullbytes (testsuite.test_api.APITestCase) ... ok
test_check_unicode (testsuite.test_api.APITestCase) ... ok
test_register_ast_check (testsuite.test_api.APITestCase) ... ok
test_register_invalid_check (testsuite.test_api.APITestCase) ... ok
test_register_logical_check (testsuite.test_api.APITestCase) ... ok
test_register_physical_check (testsuite.test_api.APITestCase) ... ok
test_styleguide (testsuite.test_api.APITestCase) ... ok
test_styleguide_check_files (testsuite.test_api.APITestCase) ... ok
test_styleguide_checks (testsuite.test_api.APITestCase) ... ok

Bug#907704: choose-mirror: default to deb.debian.org

[Philipp Kern]

On 10.09.2018 09:20, Philipp Kern wrote:
> [+mirrors@]
> 
> On 07.09.2018 14:42, Julien Cristau wrote:
>> Control: retitle -1 choose-mirror: hide mirror selection by default
>>
>> On 09/04/2018 11:07 AM, Julien Cristau wrote:
>>> If switching the mirror question from high to medium priority proves
>>> controversial I guess I could separate that to its own bug too, to at
>>> least get the default changed.
>> Since there still seems to be some discussion around that, I'm going to
>> use bug#797340 to make deb.debian.org the default, and repurpose this
>> bug to stop asking the mirror country + hostname questions by default.
> 
> What's mirroradm's take on this?

For the record, this change just landed in unstable.

Kind regards
Philipp Kern

Bug#908699: gitolite3: prevent access to repos which are in the process of bring migrated

[Salvatore Bonaccorso]

Source: gitolite3
Version: 3.6.6-1
Severity: important
Tags: security upstream

Hi

Filling this for tracking, David did you or upstream requested
accordingly a CVE?

Announce: https://groups.google.com/forum/#!topic/gitolite-announce/WrwDTYdbfRg
Fix: 
https://github.com/sitaramc/gitolite/commit/dc13dfca8fdae5634bb0865f7e9822d2a268ed59

Regards,
Salvatore

Bug#907493: Timeout in autopkgtest also in Ubuntu Cosmic with Ghostscript 9.24

[Till Kamppeter]

I have updated Ubuntu's Ghostscript from 9.23 to 9.24 as upstream 
recommended it highly for security reasons.


The autopkgtests all passed without problems for Ghostscript 9.23 on 
Ubuntu. On 9.24 I get a timeout on drv:///sample.drv/generic.ppd:


--
* Driver drv:///sample.drv/generic.ppd
 - Create test printer: done.
 - Print test job with /usr/share/cups/data/classified.pdf: 
...

[...]
...
utopkgtest [00:21:30]: ERROR: timed out on command "su -s /bin/bash root 
-c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; 
 . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest.RrEJnT/build.lFx/src"; mkdir -p -m 1777 -- 
"/tmp/autopkgtest.RrEJnT/cups-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest.RrEJnT/cups-artifacts"; export 
ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest.RrEJnT/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest.RrEJnT/autopkgtest_tmp"; export 
ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export 
LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=1; unset LANGUAGE 
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES 
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT 
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo 
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f 
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export 
AUTOPKGTEST_NORMAL_USER=ubuntu; export ADT_NORMAL_USER=ubuntu; export 
'ADT_TEST_TRIGGERS=ghostscript/9.24~dfsg+1-0ubuntu1'; chmod +x 
/tmp/autopkgtest.RrEJnT/build.lFx/src/debian/tests/cups; touch 
/tmp/autopkgtest.RrEJnT/cups-stdout /tmp/autopkgtest.RrEJnT/cups-stderr; 
/tmp/autopkgtest.RrEJnT/build.lFx/src/debian/tests/cups 2> >(tee -a 
/tmp/autopkgtest.RrEJnT/cups-stderr >&2) > >(tee -a 
/tmp/autopkgtest.RrEJnT/cups-stdout);" (kind: test)

--

Was there already found a solution for Debian?

If yes, what has been done?

Upstream commit 150c8f69646 (Bug 699658(related): Move recording of temp 
file names into C) is the very last upstream commit which made it into 
the 9.24 release.


http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=150c8f69646b8

   Till

Bug#908698: smarty3: CVE-2018-16831

[Salvatore Bonaccorso]

Source: smarty3
Version: 3.1.32+20180424.1.ac9d4b58+selfpack1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/smarty-php/smarty/issues/486

Hi,

The following vulnerability was published for smarty3.

CVE-2018-16831[0]:
| Smarty before 3.1.33-dev-4 allows attackers to bypass the trusted_dir
| protection mechanism via a file:./../ substring in an include
| statement.

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-16831
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16831
[1] https://github.com/smarty-php/smarty/issues/486

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#905944: [Pkg-javascript-devel] Bug#905944: Broken rdepends command

[Jonas Smedegaard]

Quoting Julien Puydt (2018-08-12 07:23:50)
> The 'rdepends' command is broken ; the reason is that the api to do 
> the request wasn't official and has been removed, see:
>https://github.com/npm/registry/issues/231
> 
> Currently the best way to get it back might be to parse the pages 
>like: https://www.npmjs.com/browse/depended/MODULE_NAME

Thanks to 
https://stackoverflow.com/questions/18796890/how-do-you-find-out-which-npm-modules-depend-on-yours
 
I found that this minimal hack is a temporary workaround:

--- helper.py   2018-08-17 13:53:04.0 +0200
+++ helper.py   2018-09-12 21:30:39.978795567 +0200
@@ -81,7 +81,7 @@
 def search_for_reverse_dependencies(module):
 if isinstance(module, _Npm2Deb):
 module = module.name
-url = "http://registry.npmjs.org/-/_view/dependedUpon?startkey=; \
+url = 
"https://skimdb.npmjs.com/registry/_design/app/_view/dependedUpon?startkey=; \
 + "[%%22%(name)s%%22]=[%%22%(name)s%%22,%%7B%%7D]_level=2"
 url = url % {'name': module}
 _debug(1, "opening url %s" % url)


 - Jonas

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

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


signature.asc
Description: signature

Bug#907585: Backport also needs fixing

[Florian Weimer]

found 907585 20180518-1~bpo9+1
thanks

firmware-cavium_20180518-1~bpo9+1_all.deb is still in the package pool
and contains the offending binary.

Bug#908697: ITP: argparse-manpage

[Timo Aaltonen]

Package: wnpp
Severity: wishlist

Package name: argparse-manpage
Version : 1.1
Upstream Author : Pavel Raiskup 
URL : https://github.com/praiskup/argparse-manpage
License : Apache-2.0
Programming Lang: python
Description : Automatically build a manpage from argparse

Bug#908696: civicrm-common: please remove dependency on libjs-swfobject, which is going away

[Ivo De Decker]

package: civicrm-common
version: 5.4.1+dfsg-1
severity: serious
Control: block 900106 by -1

Hi,

Please remove the dependency on libjs-swfobject, which is scheduled to be
removed from buster. See https://bugs.debian.org/900106 for more info.

Cheers,

Ivo

Bug#908695: autoradio: please remove dependency on libjs-swfobject, which is going away

[Ivo De Decker]

package: autoradio
version: 3.1-4
severity: serious
Control: block 900106 by -1

Hi,

Please remove the dependency on libjs-swfobject, which is scheduled to be
removed from buster. See https://bugs.debian.org/900106 for more info.

Cheers,

Ivo

Bug#908694: album-data: please remove dependency on libjs-swfobject, which is going away

[Ivo De Decker]

package: album-data
version: 4.05-7
severity: serious
Control: block 900106 by -1

Hi,

Please remove the dependency on libjs-swfobject, which is scheduled to be
removed from buster. See https://bugs.debian.org/900106 for more info.

Cheers,

Ivo

Bug#891994: epigrass: Depends on Qt4-only python-qwt5-qt4

[Flavio Coelho]

This error seems to be due to missing "dbfread" package which is available
on Debian as "python3-dbfread"

On Tue, Sep 11, 2018 at 2:57 AM Andreas Tille  wrote:

> On Tue, Sep 11, 2018 at 06:58:03AM +0200, Gudjon I. Gudjonsson wrote:
> > Hi Andreas
> > >
> > > I would love if people would test this.  Since it is not a
> Build-Depends
> > > where I could see whether the build breaks or not and there is no test
> > > suite to verify whether things work as expected I'm hesitating to just
> > > change the dependencies.
> > >
> > > > Since Python2 is also becoming obsolete in Debian, PyQt-Qwt is
> > > > only compiled for Python3 in Debian
> > >
> > > I'm aware of this and I contacted upstream about this long ago ...
> > >
> > I did try to run the program but I get
> >
> > Traceback (most recent call last):
> >   File "/usr/bin/epigrass", line 6, in 
> > from pkg_resources import load_entry_point
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 3105, in 
> > @_call_aside
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 3089, in _call_aside
> > f(*args, **kwargs)
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 3118, in _initialize_master_working_set
> > working_set = WorkingSet._build_master()
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 578, in _build_master
> > ws.require(__requires__)
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 895, in require
> > needed = self.resolve(parse_requirements(requirements))
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 781, in resolve
> > raise DistributionNotFound(req, requirers)
> > pkg_resources.DistributionNotFound: The 'dbfread' distribution was not
> found and is required by epigrass
> >
> > If you can tell me how to get it running, I can take a look at the
> migration to pyqt-qwt.
>
> Thanks a lot for having a look - but I can not tell more as that there
> should be a graphical interface.  I've added upstream in CC - may be
> they can give some hints.
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
>

Bug#908693: novnc: please remove dependency on libjs-swfobject, which is going away

[Ivo De Decker]

package: novnc
version: 1:0.4+dfsg+1+20131010+gitf68af8af3d-7
severity: serious
Control: block 900106 -1

Hi,

Please remove the dependency on libjs-swfobject, which is scheduled to be
removed from buster. See https://bugs.debian.org/900106 for more info.

Cheers,

Ivo

Bug#905734: Unable to backport package hplip on stretch : /usr/bin/ld: cannot find -lhpipp

[Uwe Kleine-König]

On Wed, Aug 08, 2018 at 09:06:24PM +0200, Nicolas DEFFAYET wrote:
> Package: hplip
> Severity: normal
> 
> Unable to backport package hplip on stretch using newer version from
> unstable or experimental: /usr/bin/ld: cannot find -lhpipp
> 
> 
> hplip_3.17.10+repack0-5 from unstable:
> 
> libtool: relink: gcc -shared  -fPIC -DPIC  .libs/cupsext_la-
> cupsext.o   -Wl,--as-needed -lcups -L/build/hplip-
> 3.17.10+repack0/debian/tmp/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-
> linux-gnu -lhpipp -lcrypto  -g -O2 -fstack-protector-strong -Wl,-z
> -Wl,relro -Wl,-z -Wl,now   -Wl,-soname -Wl,cupsext.so -o
> .libs/cupsext.so
> /usr/bin/ld: cannot find -lhpipp
> collect2: error: ld returned 1 exit status
> 
> 
> hplip_3.18.6+dfsg0-1 from experimental:
> 
>  /bin/mkdir -p '/build/hplip-
> 3.18.6+dfsg0/debian/tmp/usr/share/hplip/prnt'
>  /usr/bin/install -c -m 644 prnt/cups.py prnt/__init__.py prnt/ldl.py
> prnt/pcl.py prnt/colorcal.py '/build/hplip-
> 3.18.6+dfsg0/debian/tmp/usr/share/hplip/prnt'
> /usr/bin/ld: cannot find -lhpipp
> collect2: error: ld returned 1 exit status

The same happens when I try building hplip in a stable chroot. When not
building in parallel it builds fine though.

libhpipp is built in the same source package. My guess is it's a
dependency problem that is fixed by newer autotools as building in
unstable works fine for me.

And to make the result actually installable I had to weaken the
breaks/replaces introduced in the last release as can be seen at
https://salsa.debian.org/printing-team/hplip/merge_requests/1 .

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#908290: [zfs-linux] Please package 0.7.10

[Antonio Russo]

If you're interested in 0.8.0, you can check out [1], which references [2],
which is sufficient to build your own (git master) zfs. Notice that spl
is merged into zfs, so that massively simplifies packaging.  Just download
0.8.0-rc1, copy that debian directory from [2] into the source, update
the changelog (dch), and then compile with

debuild -b -us -uc

I'm committed to keeping that packaging suited for building both git-master
and the 0.8.* release branch. I'd recommend building this yourself instead
of waiting for it to get uploaded to experimental, given how little interest
there was in this git packaging for the last 6 months [3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900862
[2] https://salsa.debian.org/aerusso-guest/zfs/commits/debian/git
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891890

Bug#908692: linuxinfo: [INTL:nl] Dutch po file for the linuxinfo package's documentation

[Frans Spiesschaert]

 
 
Package: linuxinfo 
Severity: wishlist 
Tags: l10n patch 
 
 
 
 
Hi Helge, 
 
 
Please find attached the Dutch po file for the linuxinfo man page. 
It should be put as "po4a/nl.po" in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#908453: xen-utils-common: README.comet seems to no longer apply to the current Xen packages

[Hans van Kranenburg]

Hi Keith,

Thanks for your elaborate report. I'll context-quote to try answer a few
things below.

Summary of the info below:
* PVH is not supposed to work with Xen 4.8.
* The documentation in README.comet is wrong for the recent Xen
4.8-stable that we ship now, we should fix that.
* For 4.8 and PV guests, XPTI is also available now (and enabled by
default).
* Silently ignoring invalid configuration is bad.

On 09/10/2018 05:51 AM, Keith Bare wrote:
> Package: xen-utils-common
> Version: 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> I needed to build a new Xen DomU.  Since I had seen that Debian had picked
> up the 4.8 "comet" changes and pvshim, I wanted to experiment with Xen's PVH
> mode and have the DomU run the Linux 4.17 kernel in stretch-backports, which
> should be new enough to support PVH.

Parts of the PVH code have been backported. Running PVH guests yourself
is still not supported or recommended with Xen 4.8. If it was
temporarily, in the shim-branch, it was still not recommended.

> It seemed like this should work, given instructions in
> /usr/share/doc/xen-utils-common/README.comet
>  
> * Converting a PV config to a PVH config
> 
> If you have a kernel capable of booting PVH, then PVH mode is both
> faster and more secure than PV or PVH-shim mode.
> 
> - Remove any reference to 'builder' (e.g., `builder="generic"`)
> - Add the following line:
>   type="pvh"
> 

We just had a little conversation about this in #debian-xen on oftc irc,
and the latest info is that the documentation is (probably) wrong. The
README.comet is not present in upstream 4.8, but was copied from the
security advisory into our packaging.

XSA-254 mentions "PVH is supported in Xen 4.8 only with the 4.8 "Comet"
security release branch."

https://xenbits.xen.org/xsa/advisory-254.html

However...

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I ran xen-create-image (from the xen-tools package) with --dist=stretch to
> build the DomU and its configuration.  I also used --pygrub so Xen would
> boot the kernel installed in the DomU's filesystem.
> 
> I temporarily edited the DomU's Xen/xl configuration to use the pvshim, per
> the instructions in README.comet (type = 'pvh' / pvshim = 1), started the
> DomU, added the stretch-backports repository, and installed
> linux-image-amd64 from backports.  I then shut down the DomU, edited the
> DomU's configuration to remove the pvshim = 1 line, and re-started the DomU.
> 
> 
>* What was the outcome of this action?
> 
> It appeared the DomU was running in PV mode, despite my having added type =
> 'pvh' to its Xen/xl configuration.
> 
> It was difficult to tell, but I believed the DomU was running in PV mode as
> its kernel printed:
> 
>  - [0.00] Hypervisor detected: Xen PV
>  - [0.00] Kernel/User page tables isolation: disabled on XEN PV.

Yes, that's PV.

> Some Internet searching also seemed to indicate that "xl list -l "
> should mention "pvh" if the DomU is running in PVH mode.  However, I only
> saw:
> 
>  - "type": "pv",
> 
> There was no mention of "pvh" in the output.
> 
> 
>* What outcome did you expect instead?
> 
> I expected the DomU to run in PVH mode.  I wasn't sure what this was
> supposed to look like, but I did some experiments (installed the old
> 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 packages and worked around
> bootloader being broken for PVH) and saw that in fact, with that version of
> the Xen packages, the DomU kernel prints:
> 
>  - [0.00] Hypervisor detected: Xen HVM
>  - [0.00] Booting paravirtualized kernel on Xen PVH
>  - [0.00] Kernel/User page tables isolation: enabled
> 
> And xl list -l  shows:
> 
>  - "type": "pvh",
> 
> 
>* More thoughts/discussion.
> 
> It looks like the Debian packages lost support for booting DomUs in PVH mode
> with version 4.8.3+xsa262+shim4.10.0+comet3-1+deb9u6.  Probably because:
> 
> Update to new upstream version 4.8.3+xsa262+shim4.10.0+comet3.
> (This is the upstream staging-4.8 branch, which is ahead of the
> upstream CI-tested stable-4.8 branch by precisely the three
> most recent XSA fixes.  We are switching away from the special
> upstream 4.8 comet branch.)

...yes, that would be the missing puzzle piece which explains it. So in
that case, the README.comet which is still in our package is misleading
and incorrect.

> And maybe that's fine... if the mitigation comet and the pvshim provided is
> also effectively provided by XPTI changes that were present in the
> stable-4.8 branch, then I guess it isn't really necessary for anybody to use
> (and thus PVH-mode boot) the shim anymore. 

Yes, using XPTI for PV would be the least bad thing now for 4.8 I guess.
It's enabled by default by the way, so if you didn't see huge
performance problems in your dom0, you might as well try to run PV
guests just like before 

Bug#908601: patch

[Robo]

Dear Maintainer,

I can confirm that the upstream patch from
https://bugs.freedesktop.org/show_bug.cgi?id=103699
fixes both issues (plasma and firefox). Attaching a patch for debian.

Thank you,
Robert

diff -u xorg-server-1.19.2/debian/changelog xorg-server-1.19.2/debian/changelog
--- xorg-server-1.19.2/debian/changelog
+++ xorg-server-1.19.2/debian/changelog
@@ -1,3 +1,10 @@
+xorg-server (2:1.19.2-1+deb9u2.1) UNRELEASED; urgency=medium
+
+  * glx: do not pick sRGB config for 32-bit RGBA visual
+  * upstream patch 2954b16c8730c7ed8441fd8dba25900f3aed265
+
+ -- Robert T.   Wed, 12 Sep 2018 18:50:34 +0200
+
 xorg-server (2:1.19.2-1+deb9u2) stretch-security; urgency=high
 
   * Unvalidated extra length in ProcEstablishConnection (CVE-2017-12176)
diff -u xorg-server-1.19.2/debian/patches/series xorg-server-1.19.2/debian/patches/series
--- xorg-server-1.19.2/debian/patches/series
+++ xorg-server-1.19.2/debian/patches/series
@@ -11,0 +12 @@
+12_glx-Do-not-pick-sRGB-config-for-32b-RGBA-visual.diff
only in patch2:
unchanged:
--- xorg-server-1.19.2.orig/debian/patches/12_glx-Do-not-pick-sRGB-config-for-32b-RGBA-visual.diff
+++ xorg-server-1.19.2/debian/patches/12_glx-Do-not-pick-sRGB-config-for-32b-RGBA-visual.diff
@@ -0,0 +1,16 @@
+Index: xorg-server-1.19.2/glx/glxscreens.c
+===
+--- xorg-server-1.19.2.orig/glx/glxscreens.c
 xorg-server-1.19.2/glx/glxscreens.c
+@@ -274,6 +274,11 @@ pickFBConfig(__GLXscreen * pGlxScreen, V
+ /* If it's the 32-bit RGBA visual, demand a 32-bit fbconfig. */
+ if (visual->nplanes == 32 && config->rgbBits != 32)
+ continue;
++	/* If it's the 32-bit RGBA visual, do not pick sRGB capable config.
++	 * This can cause issues with compositors that are not sRGB aware.
++	 */
++	if (visual->nplanes == 32 && config->sRGBCapable == GL_TRUE)
++	continue;
+ /* Can't use the same FBconfig for multiple X visuals.  I think. */
+ if (config->visualID != 0)
+ continue;

Bug#907919: duplicate bug report

[John Comeau]

Please close as it is a duplicate of #907018.
-- 
John Comeau KE5TFZ j...@unternet.net http://jc.unternet.net/
"A place for everything, and everything all over the place"

Bug#907918: coreutils: chroot from 64 bits segfaults on older debootstrapped 64-bit distributions

[John Comeau]

Thank you Bernhard. That explains it perfectly, and no, I only
intended to file the bug once but was having problems. For me the
workaround of using 32-bit kernels serves the purpose but it's good to
know there's another for 64 bits.
On Wed, Sep 12, 2018 at 9:31 AM Bernhard Übelacker
 wrote:
>
> Hello John Comeau,
> I just tried to reproduce this crash and could
> get it just for a wheezy chroot:
>
>
> warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
> Core was generated by `/bin/bash -i'.
> Program terminated with signal 11, Segmentation fault.
> #0  0xff600400 in ?? ()
> (gdb) bt
> #0  0xff600400 in ?? ()
> #1  0x7fbd6eacefed in time () at 
> ../sysdeps/unix/sysv/linux/x86_64/time.S:36
> #2  0x00420086 in main (argc=2, argv=0x7ffefa085978, 
> env=0x7ffefa085990) at ../bash/shell.c:450
>
>
> In kernel log that access is also logged:
> kernel: bash[472] vsyscall attempted with vsyscall=none ip:ff600400 
> cs:33 sp:7ffefa085818 ax:ff600400 si:7ffefa086f20 di:0
>
>
> As far as I read this is a result of changing a special syscall
> interface that got used for performance reasons
> because of security concerns. (More details [1])
>
> At least as far as I have tested, all Debian kernels after
> Stretch release ( >= 4.10 ) behave that way, when using
> a libc that relies on the old interface.
>
> A workaround would be to boot linux with the kernel
> parameter vsyscall=emulate.
>
>
> Kind regards,
> Bernhard
>
> PS.: Was creating the same bug #907919 intentional or could that be closed?
>
>
> [1] https://sysdig.com/blog/troubleshooting-containers/



-- 
John Comeau KE5TFZ j...@unternet.net http://jc.unternet.net/
"A place for everything, and everything all over the place"

Bug#902942: systemd: please ship man/*.xml files

[Michael Biebl]

Am 09.09.18 um 16:56 schrieb Felipe Sateler:
> We have had this reaction a number of times. Shipping systemd.pc in a
> separate package comes to mind. Perhaps we have a number of such "extra"
> files that could be bundled into this extra package?

You mean, introducing a systemd-dev package? Hm...
TBH, I can only think of systemd.pc which could be reasonably moved into
this package. Did you have other files in mind?
There is udev.pc inside the udev package, but moving that into a
systemd-dev package would feel strange.
Also, moving systemd.pc might be tricky, as we have quite a few packages
build-depending on systemd, and it's likely they do that because of
systemd.pc and would be broken by this move.

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



signature.asc
Description: OpenPGP digital signature

Bug#908606: Unsure about copyright attribution to author of included source snippet

[Miroslav Kravec]

Hello Emmanuel,

could you help me with fixing debian/copyright?

In file CommandLine.java, I have found Burt Beckwith, in javadoc of
subclass CosineSimilarity. I managed to find blog post sources
https://github.com/altamiracorp/blogs.nearinfinity.com/blob/master/seth_schroeder/_posts/2007-12-01-groovy-cosine-similarity-in-grails.html
.

In blog post sources is standing: ... All code on this page is licensed
under the http://www.apache.org/licenses/LICENSE-2.0;>Apache 2
license ...

Should I include Burt Beckwith in debian/copyright? Debian policy
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information,
says following:

In addition, the copyright file must say where the upstream sources (if
any) were obtained, and should include a name or contact address for the
upstream authors. This can be the name of an individual or an organization,
an email address, a web forum or bugtracker, or any other means to
unambiguously identify who to contact to participate in the development of
the upstream source code.

Burt Beckwith is not directly responsible for picocli. His code was
included in picocli sources. And, was also licensed under Apache-2.0.

Besides, Burt Beckwith, I have found so far:

Copyright: 2017-2018, Remko Popma 
Copyright: 2017, Jim White
Copyright: 2017, Robert Zenz

Kind regards,
Miroslav Kravec

Bug#867235: avr-libc: Fails to find iom328pb.h

[Paul "LeoNerd" Evans]

On Sat, 5 Aug 2017 11:17:52 +0200
Hakan Ardo  wrote:

> Hi,
> thanx for the repport, but iom328pb.h is not provided by avr-libc as
> far as I can tell? So it would have to be added to the patch for it
> to be usefull. Can I also suggest that you report this upstream
> aswell:
> 
> http://savannah.nongnu.org/bugs/?group=avr-libc

Took me a while to get around to it, but now reported at

  https://savannah.nongnu.org/bugs/index.php?54652

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Bug#907778: [Pkg-freeipa-devel] Bug#907778: 389-ds-base: CVE-2018-14624: server crash through modify command with large DN

[Timo Aaltonen]

On 01.09.2018 23:41, Salvatore Bonaccorso wrote:
> Source: 389-ds-base
> Severity: important
> Tags: security upstream
> 
> Hi
> 
> This bug is to start tracking the issue in the BTS, at the moment
> there is not much informtation available. Reference to the CVE is at
> https://bugzilla.redhat.com/show_bug.cgi?id=1619450 .
> 
> Have you more information on the issue/fix?

Fixed in upstream git, waiting for 1.4.0.17.

https://pagure.io/389-ds-base/c/8ff8cb850

-- 
t

Bug#908296: burn: Fails immediately with ImportError

[gregor herrmann]

On Mon, 10 Sep 2018 09:44:05 +1000, Ben Finney wrote:

> I think this means the package is no longer suitable for Debian until
> a major re-write of the upstream package is performed.

The patch in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879540#30
doesn't look that invasive and quite reasonable at first sight. 


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: Rolling Stones


signature.asc
Description: Digital Signature

Bug#908603: docker.io: consider backporting to stable

[Héctor Orón Martínez]

Hello,

Missatge de Dmitry Smirnov  del dia dc., 12 de
set. 2018 a les 2:29:
>
> On Wednesday, 12 September 2018 4:01:24 AM AEST Héctor Orón Martínez wrote:
> >   Since `docker.io` reached testing, could you please consider backporting
> > it to stable?

> No, please... Maintaining Docker is an enormous time sink. I doubt backports
> will ever happen and certainly I don't want to be involved.

The whole point to bring back `docker.io` package to Debian was to
provide something usable in stable.

> I'm contemplating orphaning Docker and the only reason I'm still looking
> after it is because I think it is strategically important for Debian success.

I think so too, please keep up the good work, I am willing to help
(note I collaborated with Arnaud Rebillout) for docker.io to be back
again in Debian.

> I don't like Docker. It is very sloppy, bloated, over engineered with
> selfish, uncooperative fork-obsessed upstream who refuses to adopt good
> versioning practices making our work very difficult.

I agree, but it is key package for Debian and it's users.

> Recently I've switched all my containers to _rkt_ and I'm very happy about
> that.

I have never used rkt

> Whoever needs Docker can install it straight from "testing" since Docker is
> statically linked. I can't justify the effort required to maintain the
> official backport.

Hopefully we (Arnaud and I, and maybe other people can join a
docker-team) can help on that.

> >   What kind of work would be needed to ease the path to provide such
> > backport?
>
> Man time required to backport hundreds of dependency libraries and even more
> time to maintain all those, resolve complicated transitions, build/test
> failures and tight versioning. Team of several people working full time for
> months - that's what it will take.

If we embedded in the package most of the vendoring, would that help
on its future maintenance?
I know that might be a bit controversial however I think it might be
the only way to keep docker.io in the distribution going further
ahead.

> We are nowhere near the point where it would be safe to backport a monster
> package like Docker. First, I'd like to suggest having a real team
> maintaining Docker, not just myself. I've already invested too much time into
> Docker at the great personal cost and expense of other worthy projects/
> packages. I'm not going to stick much longer...

Your involvement has been key to give latest push and unblock latest
issues, it was great to find you managed to actually get docker.io
uploaded back to Debian. Thanks for that and all the hard work. I am
also pretty short time, however I'll try to be helpful going forward.

> Besides just keeping Docker in testing is a challenge due to build/test
> failures routinely exposed by CI. Docker dependency tree is very big and
> surface for problems is enormous.

Are you using Gitlab provided CI/CD features to track that? I'd need
to get up to speed with those.

> I wholeheartedly recommend using _rkt_ instead and it looks like rkt would be
> actually possible to backport.

I would need to look at that, however, that's a different package.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#908691: auctex: depends on emacs-gtk, cannot be installed with emacs-lucid

[Francesco Potortì]

Package: auctex
Version: 11.91-1
Severity: normal

I suppose that auctex can be used with emacs-lucid, but its dependencies
makes it impossible to install it without emacs-gtk

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

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

Versions of packages auctex depends on:
ii  debconf [debconf-2.0]   1.5.69
pn  emacs25 | emacs24 | emacs-snapshot  
ii  emacsen-common  2.0.8
ii  preview-latex-style 11.91-1

Versions of packages auctex recommends:
ii  evince 3.30.0-2
ii  ghostscript9.22~dfsg-2.1
ii  okular 4:17.12.2-2
ii  texlive-latex-recommended  2018.20180824-1
ii  xpdf   3.04-7+b1

Versions of packages auctex suggests:
ii  catdvi   0.14-12.1+b1
ii  dvipng   1.15-1
ii  lacheck  1.26-17

Bug#908656: debhelper: Please include note about third-party tool dh-golang changes in the compatibility notes

[Niels Thykier]

Clément Hermann:
> 
> On 12/09/2018 11:13, Clément Hermann wrote:
>> Package: debhelper
>> Version: 11.3.5
>> Severity: wishlist
>> Tags: patch
>>
>> Hi,
>>
>> as discussed in #904261, we'd like to have an item in the
>> compatibility notes about a non-backward compatible change in dh-golang.
>>
>> A merge request will be done on salsa with a proposed text as soon as I have
>> a bug number. I'll include the link in a follow-up e-mail.
> 
> Actually, I forgot that I'm not a DD and I can't push anything in the
> repo... I created a branch on a fork in my personal namespace on salsa:
> 
> https://salsa.debian.org/nodens-guest/debhelper/tree/document_dh_golang_changes_compat12
> 
> 
> Cheers,
> 

Hi,

Could you please open a MR request for this in salsa? :)


Thanks,
~Niels

Bug#908290: [zfs-linux] Please package 0.7.10

[Holger Schröder]

Is it possible that anyone can load 0.8.0-rc1 to experimental? I would 
like to try this (native crypt).



Regards

    Holger...

Bug#908516: Apparmor profile breaks print preview

[Vincas Dargis]

On 9/12/18 9:10 AM, intrigeri wrote:

Worst case I'll look into it within a month but help is welcome.
Vincas, maybe? :)


Yeah I'll try. I have already agreed to check similar Thunderbird issue [0] but haven't got into 
these yet :( .


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908206

Bug#907918: coreutils: chroot from 64 bits segfaults on older debootstrapped 64-bit distributions

[Bernhard Übelacker]

Hello John Comeau,
I just tried to reproduce this crash and could
get it just for a wheezy chroot:


warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
Core was generated by `/bin/bash -i'.
Program terminated with signal 11, Segmentation fault.
#0  0xff600400 in ?? ()
(gdb) bt
#0  0xff600400 in ?? ()
#1  0x7fbd6eacefed in time () at ../sysdeps/unix/sysv/linux/x86_64/time.S:36
#2  0x00420086 in main (argc=2, argv=0x7ffefa085978, 
env=0x7ffefa085990) at ../bash/shell.c:450


In kernel log that access is also logged:
kernel: bash[472] vsyscall attempted with vsyscall=none ip:ff600400 
cs:33 sp:7ffefa085818 ax:ff600400 si:7ffefa086f20 di:0


As far as I read this is a result of changing a special syscall
interface that got used for performance reasons
because of security concerns. (More details [1])

At least as far as I have tested, all Debian kernels after
Stretch release ( >= 4.10 ) behave that way, when using
a libc that relies on the old interface.

A workaround would be to boot linux with the kernel
parameter vsyscall=emulate.


Kind regards,
Bernhard

PS.: Was creating the same bug #907919 intentional or could that be closed?


[1] https://sysdig.com/blog/troubleshooting-containers/

apt install mc htop lz4 systemd-coredump gdb debootstrap



wget 
http://192.168.178.25:/debian-9-stretch-deb.debian.org/pool/main/l/linux/linux-image-4.9.0-8-amd64_4.9.110-3+deb9u4_amd64.deb
dpkg -i linux-image-4.9.0-8-amd64_4.9.110-3+deb9u4_amd64.deb
wget 
http://snapshot.debian.org/archive/debian/20170203T152214Z/pool/main/l/linux-signed/linux-image-4.10.0-rc6-amd64_4.10%7Erc6-1%7Eexp2_amd64.deb
dpkg -i linux-image-4.10.0-rc6-amd64_4.10~rc6-1~exp2_amd64.deb
wget 
http://192.168.178.25:/debian-10-buster-deb.debian.org/pool/main/l/linux/linux-image-4.11.0-1-amd64_4.11.6-1_amd64.deb
dpkg -i linux-image-4.11.0-1-amd64_4.11.6-1_amd64.deb




debootstrap --arch=amd64 jessie /opt/jessie 
http://192.168.178.25:/debian-8-jessie-deb.debian.org/
chroot /opt/jessie
# no crash


##


debootstrap --arch=amd64 wheezy /opt/wheezy 
http://192.168.178.25:/debian-7-wheezy-deb.debian.org/
I: Installing core packages...
W: Failure trying to run: chroot "/opt/wheezy" dpkg --force-depends --install 
/var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /opt/wheezy/debootstrap/debootstrap.log for details

dmesg -w -T
[Mi Sep 12 15:44:57 2018] dpkg[21278] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7fff4d8e6588 ax:ff600400 si:428720 
di:7fff4d8e65a0
[Mi Sep 12 15:44:57 2018] dpkg[21278]: segfault at ff600400 ip 
ff600400 sp 7fff4d8e6588 error 15
[Mi Sep 12 15:44:57 2018] Code: Bad RIP value.

/opt/wheezy/debootstrap/debootstrap.log
2018-09-12 15:44:56 
URL:http://192.168.178.25:/debian-7-wheezy-deb.debian.org/pool/main/z/zlib/zlib1g_1.2.7.dfsg-13_amd64.deb
 [87392/87392] -> 
"/opt/wheezy//var/cache/apt/archives/partial/zlib1g_1%3a1.2.7.dfsg-13_amd64.deb"
 [1]
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing architecture
Segmentation fault (core dumped)


root@debian:~# chroot /opt/wheezy
Speicherzugriffsfehler (Speicherabzug geschrieben)

dmesg -w -T
[Mi Sep 12 15:47:39 2018] bash[21519] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffe4c83ef68 ax:ff600400 si:7ffe4c83ff20 
di:0
[Mi Sep 12 15:47:39 2018] bash[21519]: segfault at ff600400 ip 
ff600400 sp 7ffe4c83ef68 error 15
[Mi Sep 12 15:47:39 2018] Code: Bad RIP value.


##


reboot # into 4.9.0


rm /opt/wheezy -rf
debootstrap --arch=amd64 wheezy /opt/wheezy 
http://192.168.178.25:/debian-7-wheezy-deb.debian.org/
mount -t proc proc /opt/wheezy/proc
chroot /opt/wheezy

# inside:
nano /etc/apt/sources.list
#deb-src http://192.168.178.25:/debian-7-wheezy-deb.debian.org wheezy 
main
apt-get update
apt-get install gdb strace libc6-dbg
apt-get build-dep bash
dpkg-reconfigure locales

mkdir /root/libc6/orig -p
cd/root/libc6/orig
apt-get source libc6

mkdir /root/bash/orig -p
cd/root/bash/orig
apt-get source bash
cd ..
cp -a orig try1
cd try1/bash-4.2+dfsg/
DEB_BUILD_OPTIONS="noopt nostrip" dpkg-buildpackage -b
cd ..
dpkg -i bash_4.2+dfsg-0.1+deb7u3_amd64.deb


##


root@debian:~# uname -a
Linux debian 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64 GNU/Linux

root@debian:~# chroot /opt/wheezy /usr/bin/strace /bin/bash -i 
execve("/bin/bash", ["/bin/bash", "-i"], [/* 11 vars */]) = 0
brk(0)  = 0x1894000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7efea8656000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3

Bug#894262: closed by Adrian Bunk (gconf has been adopted)

[Adrian Bunk]

On Wed, Sep 05, 2018 at 11:33:51AM -0400, Jeremy Bicha wrote:
>...
> Anyway, there are
> https://salsa.debian.org/gnome-team/gconf
> https://salsa.debian.org/gnome-team/gconf-editor
> 
> Let me know where you want those repos to be moved to.
> 
> Because of issues with the svn-to-gconf conversion, tagged releases
> might not exactly match what was actually uploaded for that version
> number.
>...

I am not currently using git for maintaining packages.

I have made personal copies of these git trees, but won't use them in 
the forseeable future.

> Thanks,
> Jeremy Bicha

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#908690: rabbitmq-server: output of `rabbitmqadmin --version` is broken

[Michael Prokop]

Package: rabbitmq-server
Version: 3.6.10-1
Severity: normal

When running `rabbitmqadmin --version` it shows `%%VSN%%` as the
version information, instead of the actual version:

| % apt-cache policy rabbitmq-server
| rabbitmq-server:
|   Installed: 3.6.10-1
|   Candidate: 3.6.10-1
|   Version table:
|  *** 3.6.10-1 500
| 500 http://deb.debian.org/debian buster/main amd64 Packages
| 100 /var/lib/dpkg/status
| % rabbitmqadmin --version
| rabbitmqadmin %%VSN%%

Also see
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1773324
for a proposed solution/workaround/fix.

regards,
-mika-

Bug#906127: pysimplesoap: diff for NMU version 1.16-2.1

[Adrian Bunk]

On Wed, Sep 12, 2018 at 11:37:40AM -0400, Sandro Tosi wrote:
> Did you upload it to delayed/10?

No.

reportbug in unstable and testing is broken for many users and there
are bug reports for that coming in all the time (httplib2 migrated to 
testing 2 days ago).

At that point I considered this an emergency that requires immediate
fixing.

Feel free to overwrite my NMU with a maintainer upload,
and I don't care whether that includes my changelog entry.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#902132: [Debian-med-packaging] Bug#902132: falcon: FTBFS since python-networkx version 2.1-1; fails in test suite

[Afif Elghraoui]

Hello,

On September 12, 2018 5:30:59 AM EDT, Andreas Tille  wrote:
>Hi Alex,
>
>On Wed, Sep 12, 2018 at 10:55:20AM +0200, Alex Mestiashvili wrote:
>> Well, according upstream, current repository is not active anymore:
>> 
>> 
>> Oh, sorry. We are no longer mirroring our internal FALCON repo here.
>In
>> fact, I think this Issues board will disappear soon too, in favor of
>> pbbioconda. So I think your source-code is way out of date.
>> Unfortunately, my hands are tied.
>> 
>> https://github.com/PacificBiosciences/FALCON/issues/672
>
>Thanks for your research on this issue.
> 
>> I am not sure how to get the source from pbbioconda and if this
>source
>> is suitable for packaging at all.
>
>I added a comment to the issue above where I've found a link inside the
>bioconda metadata[1] (assuming this is what upstream was refereing to).
>We can surely package where those meta.yaml files are pointing to but
>see my comments.
>
>It would be extremely helpful if we would find somebody at PacBio who
>can explain the situation (Afif?  I know you said you are not using the
>pb* software any more, but can you possibly help out?).  As I wrote on
>Monday[2] I have another issue with a lib from there.
>

The pbbioconda being referred to looks like 
https://github.com/PacificBiosciences/pbbioconda
and the README there lists all their packages and links to their main bioconda 
pages.

Andreas, I think the pb-falcon you found is the right one as far as I can tell.

regards
Afif


> 
>
>[1]
>https://github.com/bioconda/bioconda-recipes/blob/master/recipes/pb-falcon/meta.yaml
>[2] https://lists.debian.org/debian-mentors/2018/09/msg00152.html
>
>-- 
>http://fam-tille.de

Bug#906524: man page for muttdown

[Stephen Gelman]

On Fri, Aug 17, 2018 at 11:02 PM gustavo panizzo  wrote:
> I'll wait to see if upstream merges it otherwise I'll just ship it.

Looks like the upstream PR was merged, FYI

Stephen

Bug#906127: pysimplesoap: diff for NMU version 1.16-2.1

[Sandro Tosi]

Did you upload it to delayed/10?

On Wed, Sep 12, 2018, 11:27 Adrian Bunk  wrote:

> Control: tags 906127 + patch
>
> Dear maintainer,
>
> I've prepared an NMU for pysimplesoap (versioned as 1.16-2.1).
> The diff is attached to this message.
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
>

Bug#908689: python-click: updated

[Félix Sipma]

Package: python-click
Version: 6.7+git20180829-1
Severity: normal

The updated 6.7+git20180829-1 makes todoman FTBFS (see #908686). This does not
seem to be a new release from upstream, so I'm hesitant to report the bug
upstream. Why didn't you wait 7.0 to be released before uploading
6.7+git20180829-1?

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

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

Versions of packages python-click depends on:
ii  python   2.7.15-3
ii  python-colorama  0.3.7-1

python-click recommends no packages.

python-click suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#906127: pysimplesoap: diff for NMU version 1.16-2.1

[Adrian Bunk]

Control: tags 906127 + patch

Dear maintainer,

I've prepared an NMU for pysimplesoap (versioned as 1.16-2.1).
The diff is attached to this message.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru pysimplesoap-1.16/debian/changelog pysimplesoap-1.16/debian/changelog
--- pysimplesoap-1.16/debian/changelog	2017-01-08 06:51:39.0 +0200
+++ pysimplesoap-1.16/debian/changelog	2018-09-12 18:19:58.0 +0300
@@ -1,3 +1,11 @@
+pysimplesoap (1.16-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Add patch from Aiden Woodruff to fix the version check
+with httplib2 0.11. (Closes: #906127)
+
+ -- Adrian Bunk   Wed, 12 Sep 2018 18:19:58 +0300
+
 pysimplesoap (1.16-2) unstable; urgency=medium
 
   [ Sandro Tosi ]
diff -Nru pysimplesoap-1.16/debian/patches/fix-httplib2-version-check.patch pysimplesoap-1.16/debian/patches/fix-httplib2-version-check.patch
--- pysimplesoap-1.16/debian/patches/fix-httplib2-version-check.patch	1970-01-01 02:00:00.0 +0200
+++ pysimplesoap-1.16/debian/patches/fix-httplib2-version-check.patch	2018-09-12 18:14:52.0 +0300
@@ -0,0 +1,32 @@
+--- pysimplesoap-1.16.orig/pysimplesoap/transport.py
 pysimplesoap-1.16/pysimplesoap/transport.py
+@@ -15,6 +15,8 @@
+ 
+ import logging
+ import sys
++from distutils.version import LooseVersion
++
+ try:
+ import urllib2
+ from cookielib import CookieJar
+@@ -61,7 +63,7 @@ class TransportBase:
+ #
+ try:
+ import httplib2
+-if sys.version > '3' and httplib2.__version__ <= "0.7.7":
++if sys.version > '3' and LooseVersion(httplib2.__version__) <= LooseVersion("0.7.7"):
+ import http.client
+ # httplib2 workaround: check_hostname needs a SSL context with either 
+ #  CERT_OPTIONAL or CERT_REQUIRED
+@@ -91,9 +93,9 @@ else:
+ log.info("using proxy %s" % proxy)
+ 
+ # set optional parameters according supported httplib2 version
+-if httplib2.__version__ >= '0.3.0':
++if LooseVersion(httplib2.__version__) >= LooseVersion('0.3.0'):
+ kwargs['timeout'] = timeout
+-if httplib2.__version__ >= '0.7.0':
++if LooseVersion(httplib2.__version__) >= LooseVersion('0.7.0'):
+ kwargs['disable_ssl_certificate_validation'] = cacert is None
+ kwargs['ca_certs'] = cacert
+ httplib2.Http.__init__(self, **kwargs)
diff -Nru pysimplesoap-1.16/debian/patches/series pysimplesoap-1.16/debian/patches/series
--- pysimplesoap-1.16/debian/patches/series	2017-01-08 06:51:39.0 +0200
+++ pysimplesoap-1.16/debian/patches/series	2018-09-12 18:15:03.0 +0300
@@ -1 +1,2 @@
 9c062558f14f7045a0ee1d232cee434d917b0d5b.patch
+fix-httplib2-version-check.patch

Bug#908688: flask FTBFS with sphinx 1.7.9-1

[Adrian Bunk]

Source: flask
Version: 1.0.2-1
Severity: serious
Tags: ftbfs

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

...
   debian/rules override_dh_install
make[1]: Entering directory '/build/1st/flask-1.0.2'
dh_install
rm /build/1st/flask-1.0.2/debian/python-flask/usr/bin/flask
make[1]: Leaving directory '/build/1st/flask-1.0.2'
   dh_installdocs -O--buildsystem=pybuild
   debian/rules override_dh_sphinxdoc
make[1]: Entering directory '/build/1st/flask-1.0.2'
http_proxy='http://127.0.0.1:9/' PYTHONPATH=. sphinx-build -N -q -E -b html 
docs/ debian/python-flask-doc/usr/share/doc/python-flask-doc/html/

Configuration error:
There is a programable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/config.py", line 161, in __init__
execfile_(filename, config)
  File "/usr/lib/python3/dist-packages/sphinx/util/pycompat.py", line 150, in 
execfile_
exec_(code, _globals)
  File "conf.py", line 7, in 
from pallets_sphinx_themes import DocVersion, ProjectLink, get_version
ImportError: cannot import name 'DocVersion'

make[1]: *** [debian/rules:19: override_dh_sphinxdoc] Error 2

Bug#908687: cookiecutter FTBFS with python-click 6.7+git20180829-1

[Adrian Bunk]

Source: cookiecutter
Version: 1.6.0-2
Severity: serious
Tags: ftbfs

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

...
=== FAILURES ===
 test_cli_extra_context_invalid_format _

cli_runner = 

@pytest.mark.usefixtures('remove_fake_project_dir')
def test_cli_extra_context_invalid_format(cli_runner):
result = cli_runner(
'tests/fake-repo-pre/',
'--no-input',
'-v',
'ExtraContextWithNoEqualsSoInvalid',
)
assert result.exit_code == 2
>   assert 'Error: Invalid value for "extra_context"' in result.output
E   assert 'Error: Invalid value for "extra_context"' in 'Usage: main 
[OPTIONS] TEMPLATE [EXTRA_CONTEXT]...\n\nError: Invalid value for 
"[EXTRA_CONTEXT]...": EXTRA_CONTEXT should contain items of the form key=value; 
\'ExtraContextWithNoEqualsSoInvalid\' doesn\'t match that form\n'
E+  where 'Usage: main [OPTIONS] TEMPLATE [EXTRA_CONTEXT]...\n\nError: 
Invalid value for "[EXTRA_CONTEXT]...": EXTRA_CONTEXT should contain items of 
the form key=value; \'ExtraContextWithNoEqualsSoInvalid\' doesn\'t match that 
form\n' = .output

tests/test_cli.py:390: AssertionError
_ test_should_raise_error_without_template_arg _

capfd = <_pytest.capture.CaptureFixture object at 0x7f55fbf7f250>

def test_should_raise_error_without_template_arg(capfd):
with pytest.raises(subprocess.CalledProcessError):
subprocess.check_call(['python', '-m', 'cookiecutter.cli'])

_, err = capfd.readouterr()
exp_message = 'Error: Missing argument "template".'
>   assert exp_message in err
E   assert 'Error: Missing argument "template".' in 'Usage: cli.py 
[OPTIONS] TEMPLATE [EXTRA_CONTEXT]...\nTry "cli.py -h" for help.\n\nError: 
Missing argument "TEMPLATE".\n'

tests/test_cookiecutter_invocation.py:25: AssertionError

-- coverage: platform linux2, python 2.7.15-final-0 --
Name  Stmts   Miss  Cover
-
cookiecutter/__init__.py  2  0   100%
cookiecutter/__main__.py  3  0   100%
cookiecutter/cli.py  49  0   100%
cookiecutter/config.py   51  0   100%
cookiecutter/environment.py  21  0   100%
cookiecutter/exceptions.py   24  0   100%
cookiecutter/extensions.py9  0   100%
cookiecutter/find.py 18  0   100%
cookiecutter/generate.py166  0   100%
cookiecutter/hooks.py61  0   100%
cookiecutter/log.py  21  0   100%
cookiecutter/main.py 31  0   100%
cookiecutter/prompt.py   90  0   100%
cookiecutter/replay.py   30  0   100%
cookiecutter/repository.py   39  0   100%
cookiecutter/utils.py50  296%
cookiecutter/vcs.py  54  0   100%
cookiecutter/zipfile.py  61  0   100%
-
TOTAL   780  299%

=== 2 failed, 258 passed, 1 skipped in 8.75 seconds 
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/build/1st/cookiecutter-1.6.0/.pybuild/cpython2_2.7_cookiecutter/build; 
python2.7 -m pytest tests
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
make: *** [debian/rules:10: build] Error 25

Bug#908483: #908483 - spl-dkms: spl-dmks fails to build on Linux 4.18.0-1 - Debian Bug report logs

[Hank Barta]

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

Same issue on Debian/Testing with upgrade from 4.17 to 4.18.

Build log at https://pastebin.com/na94rwt8

Bug#908686: todoman FTBFS with python-click 6.7+git20180829-1

[Adrian Bunk]

Source: todoman
Version: 3.4.0-2
Severity: serious
Tags: ftbfs

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

...
I: pybuild base:217: cd /build/1st/todoman-3.4.0/.pybuild/cpython3_3.7/build; 
python3.7 -m pytest tests
= test session starts ==
platform linux -- Python 3.7.0+, pytest-3.6.4, py-1.6.0, pluggy-0.6.0
rootdir: /build/1st/todoman-3.4.0, inifile: setup.cfg
plugins: cov-2.5.1, hypothesis-3.44.1
collected 176 items

tests/test_backend.py .  [  5%]
tests/test_cli.py FxFFs. [ 35%]
..F  [ 42%]
tests/test_config.py F.FxxFFF... [ 50%]
tests/test_filtering.py F..F.[ 55%]
tests/test_formatter.py F..  [ 64%]
tests/test_main.py . [ 64%]
tests/test_model.py ss..ss   [ 84%]
tests/test_porcelain.py  [ 88%]
tests/test_ui.py ... [ 94%]
tests/test_widgets.py .  [100%]

=== FAILURES ===
__ test_list ___

tmpdir = local('/tmp/pytest-of-pbuilder1/pytest-0/test_list0')
runner = .SleepyCliRunner object at 0x7f4bb2307160>
create = .inner at 0x7f4bb1f8d488>

def test_list(tmpdir, runner, create):
>   result = runner.invoke(cli, ['list'], catch_exceptions=False)

tests/test_cli.py:22: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tests/conftest.py:47: in invoke
return super().invoke(*args, **kwargs)
/usr/lib/python3/dist-packages/click/testing.py:326: in invoke
cli.main(args=args or (), prog_name=prog_name, **extra)
/usr/lib/python3/dist-packages/click/core.py:714: in main
rv = self.invoke(ctx)
/usr/lib/python3/dist-packages/click/core.py:1129: in invoke
Command.invoke(self, ctx)
/usr/lib/python3/dist-packages/click/core.py:951: in invoke
return ctx.invoke(self.callback, **ctx.params)
/usr/lib/python3/dist-packages/click/core.py:552: in invoke
return callback(*args, **kwargs)
/usr/lib/python3/dist-packages/click/decorators.py:17: in new_func
return f(get_current_context(), *args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

a = (,)
kw = {'colour': None, 'humanize': None, 'porcelain': False}

@functools.wraps(f)
def wrapper(*a, **kw):
with handle_error():
>   return f(*a, **kw)
E   TypeError: cli() got an unexpected keyword argument 'colour'

todoman/cli.py:34: TypeError
...
= 84 failed, 84 passed, 5 skipped, 3 xfailed in 13.47 seconds ==
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/build/1st/todoman-3.4.0/.pybuild/cpython3_3.7/build; python3.7 -m pytest tests
dh_auto_test: pybuild --test --test-pytest -i python{version} -p "3.7 3.6" 
returned exit code 13
make: *** [debian/rules:28: build] Error 25

Bug#904261: [pkg-go] Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Martín Ferrari]

On 12/09/18 10:37, Clément Hermann wrote:

>> So, if no one objects, I'll merge the branch, add the relevant changelog
>> entries and upload^Wask for someone to upload. ;)
>>
>> (and I'll take care of the bug creation on debhelper meanwhile).
> 
> And it has been merged.

THanks for your work!!

> I'm not sure it warrants an upload right away, but it would be nice to
> have it before debhelper is updated.
> 
> Could anyone sponsor that ?

I would be happy to, but I have not been following dh-golang devel much
to decide if we sHould upload now.. Any other opinion?


-- 
Martín Ferrari (Tincho)

Bug#908685: sdl-ball FTCBFS: uses CC to store a C++ compiler

[Helmut Grohne]

Source: sdl-ball
Version: 1.02-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

sdl-ball fails to cross build from source, because the upstream Makefile
uses CC to store a C++ compiler. dh_auto_build substitutes a C compiler
and that fails. After making it use CXX, sdl-ball cross builds
successfully. Please consider applying the attached patch.

Helmut
--- sdl-ball-1.02.orig/Makefile
+++ sdl-ball-1.02/Makefile
@@ -2,7 +2,8 @@
 
 #append -DWITH_WIIUSE to compile with WIIUSE support!
 #append -DNOSOUND to compile WITHOUT sound support
-CC=g++ -DDATADIR="\"$(DATADIR)\""
+CXX=g++
+CFLAGS+=-DDATADIR="\"$(DATADIR)\""
 
 CFLAGS+=-c -Wall `sdl-config --cflags`
 
@@ -18,10 +19,10 @@
 all: $(SOURCES) $(EXECUTABLE)
 	
 $(EXECUTABLE): $(OBJECTS)
-	$(CC) $(LDFLAGS) $(OBJECTS) $(LIBS) -o $@
+	$(CXX) $(LDFLAGS) $(OBJECTS) $(LIBS) -o $@
 
 .cpp.o:
-	$(CC) $(CPPFLAGS) $(CFLAGS) $< -o $@
+	$(CXX) $(CPPFLAGS) $(CFLAGS) $< -o $@
 
 clean:
 	rm -f *.o sdl-ball