Bug#911697: at-spi2-core: causes SIGSEGV because of improper quoting of G_LOG_DOMAIN

[Samuel Thibault]

Control: retitle -1 meson: varying levels of quote interpretation make it 
impossible to define G_LOG_DOMAIN
Control: reassign -1 meson
Control: fixed 0.47.2-1
Control: found 0.48.1-1

Hello,

Jan Nordholz, le mer. 24 oct. 2018 02:01:56 +0200, a ecrit:
> your build fix actually made it worse: now G_LOG_DOMAIN works properly for
> the gtkdoc-scangobj stuff, but the extra quotes cause literal integer values
> to be inserted wherever you expected a string pointer in the library proper:

Yeeech...

So the issue is in meson itself: it seems one can't get 

compile_args: [ '-DG_LOG_DOMAIN="dbind"' ],

to be correctly interpreted as making G_LOG_DOMAIN #defined to "dbind"
both for the binary compilation and for the documentation generation.

FTR, this was working with meson 0.47.2-1 (see
https://buildd.debian.org/status/fetch.php?pkg=at-spi2-core&arch=amd64&ver=2.30.0-2&stamp=1536983011&raw=0
), so I guess it's 0.48.0 which broke this.

Samuel

Bug#911582: emacspeak does'nt work after upgrading emacs

[Michelangelo Rodriguez]

On Tue, 23 Oct 2018, Samuel Thibault wrote:


Hello,

Michelangelo Rodriguez, le mar. 23 oct. 2018 10:21:09 +0200, a ecrit:

On Tue, 23 Oct 2018, Samuel Thibault wrote:

Michelangelo Rodriguez, le mar. 23 oct. 2018 08:47:03 +0200, a ecrit:

this is the output of dpkg -l \*emacs\*:


I'm still not geting the issue with that list of package.

Could you send the actual output you are getting during package
configuration?

Samuel


Hi, this is the output when i run dpkg-reconfigure emacspeak:
Install emacspeak for emacs
/usr/lib/emacsen-common/packages/install/emacspeak running in /
And that's all.
when i open the script i read that if flavour is emacs it has to exit.
And i think that it happens.


Ah, ok.

Could you try the package at
https://people.debian.org/~sthibault/tmp/emacspeak_47.0+dfsg-2~0_all.deb
?

Samuel


Hi,
Yes, your package installs fine!
Regards,
Michelangelo

Bug#911680: xserver-xorg-core: X server crashes when loading libglamorgl.so module (Bug #911680)

[Dan Zhou]

Hi, I had the same crash with xorg-server 2:1.20.1-5 on Virtualbox. I worked 
around it by turning off  the “3D accelaration” option for my VM from 
VirtualBox.

Bug#911743: enabling orange-fs in linux

[Alois Schlögl]

Package: linux 
Version: unstable 
Severity: wishlist 
Source: linux


We are looking into distributed, parallel filesystems like beegfs and
orangefs. I'd prefer orangefs (mainly because of its license terms).

We'd like to use Debian/stable for this set up, unfortunately, the
current debian kernel has orange-fs support disabled.

Based on an initial response from 
  https://lists.debian.org/debian-kernel/2018/10/msg00181.html
I'm asking to enable orange-fs support in the linux kernel



Thanks for considering, 
   Alois 







 

Bug#911334: Create /dev/ptmx like debootstrap does

[Andreas Beckmann]

So the underlying problem is

# mkdir foo
# touch foo/file
# mknod foo/null c 1 3
# touch foo/bindmntoverfile
# mount --bind foo/null foo/bindmntoverfile
# ls -lis foo
total 0
3857271640 0 crw-r--r-- 1 root root 1, 3 Oct 24 07:50 bindmntoverfile
3857120264 0 -rw-r--r-- 1 root root0 Oct 24 07:49 file
3857271640 0 crw-r--r-- 1 root root 1, 3 Oct 24 07:50 null
# find foo -type f -ls
3857271640  0 crw-r--r--   1 root root   1,   3 Oct 24 07:50 
foo/bindmntoverfile
3857120264  0 -rw-r--r--   1 root root0 Oct 24 07:49 
foo/file

please find/file a bug against findutils

and the commit message should not mention debootstrap but
something like
"""
p: use mknod instead of touch to create missing /dev/ptmx mountpoint

working around findutils bug #xx

mkdir foo
mknod foo/null c 1 3
touch foo/bindmntoverfile
mount --bind foo/null foo/bindmntoverfile
find foo -type f -ls
3857271640  0 crw-r--r--   1 root root   1,   3 Oct 24 07:50 
foo/bindmntoverfile
"""

Andreas

Bug#911744: thermald: conffiles not removed

[Paul Wise]

Package: thermald
Version: 1.8.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=thermald ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
thermald: obsolete-conffile /etc/thermald/thermal-conf.xml
 /etc/thermald/thermal-conf.xml 44437e985216ab918a6d2362c8dd1905 obsolete

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages thermald depends on:
ii  libc6 2.27-6
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libgcc1   1:8.2.0-8
ii  libglib2.0-0  2.58.1-2
ii  libstdc++68.2.0-8
ii  libxml2   2.9.4+dfsg1-7+b1
ii  lsb-base  9.20170808

thermald recommends no packages.

thermald suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#911745: apparmor: conffile not removed: /etc/apparmor.d/abstractions/launchpad-integration

[Paul Wise]

Package: apparmor
Version: 2.13.1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=adequate ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
apparmor: obsolete-conffile /etc/apparmor.d/abstractions/launchpad-integration
 /etc/apparmor.d/abstractions/launchpad-integration 
08239d10ba383041e97bc7f3962eb788 obsolete

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.27-6
ii  lsb-base   9.20170808
ii  python33.6.6-1

apparmor recommends no packages.

Versions of packages apparmor suggests:
ii  apparmor-profiles-extra  1.21
ii  apparmor-utils   2.13.1-1

-- debconf information excluded

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#911738: libapache2-mod-php: libapache2-mod-php7.2 is still the active PHP module even after upgrade to PHP 7.3

[Joseph Nuthalapati]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: libapache2-mod-php
Version: 1:7.3+66
Severity: important

I also observed that if `apt autoremove` is run,
libapache2-mod-php7.2 gets removed and disabled as an Apache
module. Since the installation of libapache2-mod-php7.3 didn't
enable it, the system ends up with no active Apache PHP mod.

Another observation which I cannot explain is, when I install the
package mediawiki (on unstable), libapache2-mod-php7.3 gets
enabled automatically and everything seems to work just fine.

- -- 
Regards,
Joseph Nuthalapati

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE4rQIdbX3Xc6j+BCYU5jwCi+kPDUFAlvQM7kACgkQU5jwCi+k
PDVPjQ/9EtULbHuV/MWADoZ4zJOkAW5InzwdK/VG0bKDVuojLtbShtWkZ/nFs9vQ
+AOEFeRWlpFIEnSDBjxRXdeHshbfWA6t3sTM6195eerQP0QKPJ6VdjuU0CacS/4b
A+WvK0dIz9dfbGG3iPVgCcP5XEGZz1LxGsyq+1tJu5ZLGqQCdVXKQWcrhMIdqlXs
SRNpt5Kvn/75X9Mguh4B+L39pCr5J/kkgKV4dQIsNKFF6J6M/v1bOf+hj8EB6QHu
2h5b1+TPG1YtiPCBuPlZ3iWRgOowH5Xnps0ecIdH4o7qzlBbY//G1MheIkKHThkC
Myug9gUEgmsOurkh7BkN8lwe7t0XoMu5c/i3i44UleoAlKY3YkznWvWPD6/zUM34
Mi/M3WKhPEmwGQDMyxBIEsja/K61JUwd+TnFyKOHgw+Ll1eR2NX3nSmCEr8k0f+X
ua3zEhMvkqIiiqfeKsAE/dTv1m5W1+NGqL4i/EwlZCCoNfNiAsxVHIaXN79C5Jxd
p6uWnt6El+aUHgC4TX+uEf2Kn6qNPbe2MsGctSD3Sjn/x4PFhu2klFV8a+cZ/OTa
hlDr6ka2gb8qregufyFlFI3NGgNHR4RXD26g7YLoiyXmvbrsLxUeOOaXUW+czlgR
oFg4xD07POK91v8BlR+rN++7oTMWSC7LOgP9q/lKsnWR+n5F8aM=
=UVBB
-END PGP SIGNATURE-

Bug#911746: zram-tools: Processor count is incorrect on some ARM boards

[Julian Calaby]

Package: zram-tools
Version: 0.3.2-1
Severity: important

Dear Maintainer,

On some ARM boards, zramswap miscounts the processors due to not anchoring
the regex it uses to count processors.

For example /proc/cpuinfo on a Raspberry Pi looks like:

---

processor   : 0
model name  : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS: 897.37
Features: half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xb76
CPU revision: 7

Hardware: BCM2835
Revision: 0002
Serial  : 3ec63cb3

---

contains the word "processor" twice when there's only one processor.

To fix this, the regex used by grep on line 23 of zramswap needs to be
"^processor" instead of just "processor".

Alternatively replacing that line with some lscpu invocation punts the problem
of parsing /proc/cpuinfo to another package.

(Note that this was reported on my laptop as reportbug isn't available on the
affected board)

Thanks,

Julian Calaby


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

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

Versions of packages zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- no debconf information

Bug#911748: zram-tools: Stopping zramswap service doesn't remove swaps

[Julian Calaby]

Package: zram-tools
Version: 0.3.2-1
Severity: minor

Dear Maintainer,

The systemd unit used to start zramswap on boot doesn't clean up the zram swap
partitions when stopped.

zramswap isn't prepared for the partitions it creates to already exist when it
starts so it prduces errors when stopped and started through service or
systemctl.

Thanks,

Julian Calaby

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

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

Versions of packages zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- no debconf information

Bug#911747: zram-tools: CORES option in /etc/default/zramswap is ignored

[Julian Calaby]

Package: zram-tools
Version: 0.3.2-1
Severity: normal

Dear Maintainer,

/etc/default/zramswap specifies that the number of cores to use can be
overridden using the "CORES" environment variable and provides an example
using that variable.

---

# Specifies amount of zram devices to create.
# By default, zramswap-start will use all available cores.
#CORES=1

---

However uncommenting the line has no effect as /usr/sbin/zramswap uses "cores"
in lower-case to define the number of swap areas to allocate.

This can be trivially worked around by overriding the correct variable.

Thanks,

Julian Calaby


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

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

Versions of packages zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- no debconf information

Bug#911749: zram-tools: Restarting or reloading zramswap service doesn't do anything

[Julian Calaby]

Package: zram-tools
Version: 0.3.2-1
Severity: normal

Dear Maintainer,

Restarting or reloading the zramswap service doesn't do anything.

Specifically:

Restarting the service causes it to fail due to the swap partitions not being
cleaned up, as discussed in a separate bug.

Reloading the service does nothing as this calls "zramswap restart" which
silently does nothing as "restart" isn't a command supported by zramswap.

This makes tweaking the configuration annoying as you have to invoke zramswap
directly to make changes.

Thanks,

Julian Calaby


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

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

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


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

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

Versions of packages zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- no debconf information

Bug#910852: libqt5webengine5: Akregator crashes very often, WebEngine related

[Martin Steigerwald]

Dmitry Shachnev - 19.10.18, 17:48:
> Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=400028
> 
> On Fri, Oct 19, 2018 at 11:49:45AM +0200, Martin Steigerwald wrote:
> > Unfortunately Akregator still crashes with Qt 5.11.2 packages.
> > 
> > Maybe heise.de is a quite good way to reproduce it, in case that
> > tracking script stuff is somehow related:
> > 
> > http://www.heise.de/open/news/news-atom.xml
> 
> I have reported this bug to Qt upstream, but they say it is not their
> bug, but a thread safety issue in libkf5webengineviewer5. So I have
> now filed a bug to KDE.

Here further links to upstream bug reports.

Bug which the bug 400028 you marked a duplicate of:

[Bug 371511] kontact/akregator crashes while trying to open a link from 
the
list (middle click)
https://bugs.kde.org/371511

Another upstream bug report:
[akregator] [Bug 397866] akregator crashes when closing the rightmost 
tab
https://bugs.kde.org/397866

Thanks
-- 
Martin

Bug#911750: Race condition in d-i leading to kernel from security.debian.org to be kept back

[Raphaël Halimi]

Package: debian-installer
Version: 20170615+deb9u4

Hi,

I just noticed a race condition in d-i, which may lead to a mild
security risk.

When the kernel metapackage (linux-image-) is initially installed,
APT doesn't install recommended packages, and security.debian.org
repository is not configured yet, so the installer naturally fetches the
latest kernel from the core suite. After APT configuration, and other
repositories and suites are available, debian-installer runs an upgrade;
but if a newer version of linux-image- is found in one of those
newly available repositories (security.debian.org in this case), it's
not installed because APT refuses to install the recommended packages
(firware-linux-free, irqbalance) to satisfy dependencies, so the kernel
metapackage is kept back.

It won't be installed until the admin runs an upgrade manually, once the
system is booted. This may put it at risk during a certain period of
time between the first boot, and the first upgrade (and reboot).

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#911751: apt-show-versions: --nohold option does not work as expected

[Cem Aydin]

Package: apt-show-versions
Version: 0.22.7
Severity: normal

Dear Maintainer,

# apt-mark hold neo4j
# apt-mark showhold
neo4j
# apt-show-versions -nh| grep upgradeable
cypher-shell:all/stable 1.1.5 upgradeable to 1.1.6
neo4j:all/stable 1:3.4.7 upgradeable to 1:3.4.9

Same with --nohold.
Unless I misunderstand the usage of --nohold this shouldn't show neo4j.
Thx.

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_CH.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt-show-versions depends on:
ii  apt 1.4.8
ii  libapt-pkg-perl 0.1.32
ii  libperl5.24 [libstorable-perl]  5.24.1-3+deb9u4
ii  perl    5.24.1-3+deb9u4

apt-show-versions recommends no packages.

apt-show-versions suggests no packages.

-- no debconf information

Bug#901015: transition: protobuf

[Pirate Praveen]

Hi Emilio,

I think these regressions should not add a delay to testing migration as
autopkgtests are passing in unstable and a rebuild is required to make
them compatible with new protobuf version.

autopkgtest for gazebo/9.0.0+dfsg5-4.2: amd64: Regression ♻
autopkgtest for ignition-msgs/1.0.0+dfsg1-5: amd64: Regression ♻
autopkgtest for ignition-transport/4.0.0+dfsg-4: amd64: Regression ♻
autopkgtest for ola/0.10.7.nojsmin-1: amd64: Regression ♻
Required age increased by 18 days because of autopkgtest



signature.asc
Description: OpenPGP digital signature

Bug#911752: yapps2: half of examples in source package broken with Python 3 port

[Colin Watson]

Source: yapps2
Version: 2.2.1-1
Severity: normal

I know the examples in the source package aren't actually shipped, but
it still seems like pretty bad form that two out of four of them are
completely broken with the Python 3 port.

  $ yapps2 calc.g
  $ python calc.py
File "calc.py", line 48
  print '=', expr
  ^
  SyntaxError: invalid syntax
  $ python3 calc.py
File "calc.py", line 6
  if not globalvars.has_key(name): print 'Undefined (defaulting to 0):', 
name
  ^
  SyntaxError: invalid syntax
  $ yapps2 xml.g
  $ python xml.py
File "xml.py", line 147
  print 'Running tests___'
 ^
  SyntaxError: invalid syntax
  $ python3 xml.py
File "xml.py", line 147
  print 'Running tests___'
 ^
  SyntaxError: Missing parentheses in call to 'print'. Did you mean 
print('Running tests___')?

This is hopefully just a matter of converting the print statements in
examples/calc.g and examples/xml.g to Python 3 syntax (since yapps2
itself now inserts "from __future__ import print_function" and thus
requires parsers to use the new syntax).

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

Bug#901015: transition: protobuf

[Mattia Rizzolo]

On Wed, Oct 24, 2018 at 03:47:47PM +0530, Pirate Praveen wrote:
> I think these regressions should not add a delay to testing migration as
> autopkgtests are passing in unstable and a rebuild is required to make
> them compatible with new protobuf version.
> 
> autopkgtest for gazebo/9.0.0+dfsg5-4.2: amd64: Regression ♻
> autopkgtest for ignition-msgs/1.0.0+dfsg1-5: amd64: Regression ♻
> autopkgtest for ignition-transport/4.0.0+dfsg-4: amd64: Regression ♻
> autopkgtest for ola/0.10.7.nojsmin-1: amd64: Regression ♻
> Required age increased by 18 days because of autopkgtest

If "a rebuild is required to make them compatible", you should add
Breaks against those versions, as it maeans the new protobuf is not
compatible to them and coinstallation should be prevented.
That would also hint britney to trigger autopkgtest with both the new
rebuilt rdep and the new protobuf, and migrate them in lockstep.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#901015: transition: protobuf

[Pirate Praveen]

On 10/24/18 3:54 PM, Mattia Rizzolo wrote:
> If "a rebuild is required to make them compatible", you should add
> Breaks against those versions, as it maeans the new protobuf is not
> compatible to them and coinstallation should be prevented.
> That would also hint britney to trigger autopkgtest with both the new
> rebuilt rdep and the new protobuf, and migrate them in lockstep.
> 

This was suggested earlier but rejected by protobuf maintainer.

"1) Can libprotobuf10 and libprotobuf17 installed together and
independent packages working correctly with these libraries? Yes,
these are possible. I don't see the need to break the old
libprotobuf10 package.

2) Packages that depend on each other, need to be compiled with the
same ProtoBuf version. This should be expressed in those package
dependencies."

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910964#29

Though the suggestion by protobuf maintainer was not acceptable to
ignition-msgs maintainer

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900429#36



signature.asc
Description: OpenPGP digital signature

Bug#911161: Patch is not correct

[Matijs van Zuijlen]

Dear maintainer,

I'm afraid the given patch is not correct. To fix thumbnail generation
in Gnome/Nautilus, I had to add the following line instead:

owner /tmp/gnome-desktop-thumbnailer.* w,


-- 
Kind regards,
Matijs van Zuijlen



signature.asc
Description: OpenPGP digital signature

Bug#894359: Now we have antlr 4.6 - any chance to get 4.7 soon (Was: beast-mcmc2: Cannot find symbol CharStreams.fromString(newick))

[Emmanuel Bourg]

Control: tags 911286 + pending
Control: tags 911302 + pending

Le 19/10/2018 à 16:42, Andrius Merkys a écrit :

> updating antlr4 to 4.7 requires two new Debian packages, 
> libmojo-executor-java (ITP #911286) and libstring-template-maven-plugin-java 
> (ITP #911302). I have pushed their packaging to Salsa:
> 
> * https://salsa.debian.org/merkys-guest/mojo-executor
> * https://salsa.debian.org/merkys-guest/string-template-maven-plugin 
> (build-depends on libmojo-executor-java)
> 
> It would be great if you could review and, if possible, sponsor them.

I've uploaded mojo-executor and string-template-maven-plugin, they are
awaiting in the NEW queue for the FTP masters approval. Thanks a lot
Andrius.

Emmanuel Bourg

Bug#911753: python3-yapps: error reporting completely broken in Python 3 port

[Colin Watson]

Package: python3-yapps
Version: 2.2.1-1
Severity: important

While trying to port keymapper to the current version of yapps2, and
after attempting to work around https://bugs.debian.org/911730 by moving
the pre-parser code to the post-parser position, I got this:

  yapps2 x11.g
  x11.g:90:1: Trying to find one of "parser"
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/yapps/runtime.py", line 438, in 
wrap_error_reporter
  return getattr(parser, rule)(*args,**kw)
File "/usr/lib/python3/dist-packages/yapps/grammar.py", line 80, in Parser
  self._scan('"parser"', context=_context)
File "/usr/lib/python3/dist-packages/yapps/runtime.py", line 376, in _scan
  return self._scanner.scan(type, **kw)
File "/usr/lib/python3/dist-packages/yapps/runtime.py", line 344, in scan
  tok = self.token([type],context)
File "/usr/lib/python3/dist-packages/yapps/runtime.py", line 297, in token
  raise SyntaxError(self.get_pos(), msg, context=context)
  yapps.runtime.SyntaxError: SyntaxError@('x11.g', 90, 1)(Trying to find one of 
"parser")
  
  During handling of the above exception, another exception occurred:
  
  Traceback (most recent call last):
File "/usr/bin/yapps2", line 11, in 
  load_entry_point('Yapps2==2.2.1', 'console_scripts', 'yapps2')()
File "/usr/lib/python3/dist-packages/yapps/cli_tool.py", line 111, in main
  sys.exit(generate(optz.grammar_path, outputfile, **parser_flags))
File "/usr/lib/python3/dist-packages/yapps/cli_tool.py", line 64, in 
generate
  t = runtime.wrap_error_reporter(parser, 'Parser')
File "/usr/lib/python3/dist-packages/yapps/runtime.py", line 440, in 
wrap_error_reporter
  print_error(e, parser._scanner)
File "/usr/lib/python3/dist-packages/yapps/runtime.py", line 420, in 
print_error
  scanner.print_line_with_pointer(pos)
File "/usr/lib/python3/dist-packages/yapps/runtime.py", line 230, in 
print_line_with_pointer
  print >>out, '> ',text
  TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method' 
and '_io.TextIOWrapper'. Did you mean "print(, file=)"?

The first exception is probably my fault somehow; I'm doing this in
spare moments so haven't worked out the details.  However, the second
exception is because there is code in a Python 3 module that's using the
Python 2 print syntax.

Please could you fix the port by converting
Scanner.print_line_with_pointer to Python 3 print syntax?

Thanks,

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

Bug#911754: undefined symbol: _D7gobject7ObjectGQi5dorefMFZCQBcQxQz

[Andrey Rahmatullin]

Package: appstream-generator
Version: 0.7.4-1
Severity: grave

I've just installed appstream-generator and ran it:

$ appstream-generator
appstream-generator: symbol lookup error: appstream-generator: undefined
symbol: _D7gobject7ObjectGQi5dorefMFZCQBcQxQz

So it's either underlinked or some dependency dropped that symbol without
bumping the soname, in which case please reassign the bug accordingly.



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

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

Versions of packages appstream-generator depends on:
ii  libappstream40.12.3-1
ii  libarchive13 3.2.2-5
ii  libc62.27-6
ii  libcairo21.16.0-1
ii  libcurl3-gnutls  7.61.0-1
ii  libdcontainers0  0.8.0~alpha.9-1
ii  libfontconfig1   2.13.1-1
ii  libfreetype6 2.8.1-2
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libglibd-2.0-0   2.0.0-1+b1
ii  libjs-highlight.js   9.12.0+dfsg1-4
ii  libjs-jquery-flot0.8.3+dfsg-1
ii  liblmdb0 0.9.22-1
ii  libmustache-d0   0.1.3-3+b1
ii  libpango-1.0-0   1.42.4-3
ii  libphobos2-ldc-shared78  1:1.8.0-3
ii  librsvg2-2   2.40.20-3
ii  libstdx-allocator0   2.77.2-1

Versions of packages appstream-generator recommends:
ii  optipng  0.7.6-1.1

appstream-generator suggests no packages.

-- no debconf information

Bug#911755: nnn: Missing manpage for nlay(1)

[Dmitry Bogatov]

Package: nnn
Version: 2.0-1
Severity: normal

Dear Maintainer, please install nlay.1 manual page.

Bug#911754: undefined symbol: _D7gobject7ObjectGQi5dorefMFZCQBcQxQz

[Matthias Klumpp]

Am Mi., 24. Okt. 2018 um 12:45 Uhr schrieb Andrey Rahmatullin :
>
> Package: appstream-generator
> Version: 0.7.4-1
> Severity: grave
>
> I've just installed appstream-generator and ran it:
>
> $ appstream-generator
> appstream-generator: symbol lookup error: appstream-generator: undefined
> symbol: _D7gobject7ObjectGQi5dorefMFZCQBcQxQz
>
> So it's either underlinked or some dependency dropped that symbol without
> bumping the soname, in which case please reassign the bug accordingly.

This is because the package wasn't properly rebuilt with the latest
LDC release in the last LDC transition.
A simple package rebuild should fix this issue.

There is another LDC transition pending, which starts when LDC clears
NEW, I'll merge this issue with the transition bug then.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#911741: nnn: hardcoded dependency on libncursesw5

[Dmitry Bogatov]

[2018-10-24 10:46] Dmitry Bogatov 
> Patch attached.

Oops, sorry, non `patch -p1' conformant. Please, use this one.


diff -rU3 old/nnn-2.0/debian/control new/nnn-2.0/debian/control
--- old/nnn-2.0/debian/control  2018-10-22 03:33:24.0 +
+++ new/nnn-2.0/debian/control  2018-10-24 10:13:09.281319066 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: SZ Lin (林上智) 
 Build-Depends: debhelper (>= 11),
-   libncursesw5-dev,
+   libncurses-dev,
pkg-config
 Standards-Version: 4.2.1
 Homepage: https://github.com/jarun/nnn
@@ -12,7 +12,7 @@
 
 Package: nnn
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libncursesw5
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Free, fast, friendly file manager
  nnn is a fork of noice, a blazing-fast lightweight terminal file manager
  with easy keyboard shortcuts for navigation, opening files and running tasks.

Bug#881845: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

[John Paul Adrian Glaubitz]

Hi!

On 10/19/18 10:56 AM, Dragan Mladjenovic wrote:
> @YunQiang Su  Are you referring to failures shown 
> in [1] ?
> 
> 
> If so, here is the overview : 
> 
>>test [ui] ui/asm-out-assign-imm.rs
>>test [ui] ui/target-feature-gate.rs
>>test [ui] ui/target-feature-wrong.rs
> 
> Fix:[2]. Should be ignored. 
> 
> 
>>test [run-pass] run-pass/invalid_const_promotion.rs
> 
> Needs SIGTRAP added to the list at [3]. 
> 
> 
>>test [run-make] run-make-fulldeps/relocation-model
> 
> Bug:[4]. Should be ignored on both mips64 and mips [5]. 

I'll create Debian patches for those.

> Quick comment on the mips. Except of the OOM problems other problems 
> (including the atomics one) on mips are usually 
> 
> caused by its usage of llvm's FastISel in unoptimized builds. You could try 
> disabling it or even try optimized build.
> 
> I believe that for 1.28 we could finish the native bootstrapping in optimized 
> build while unoptimized one would OOM.   
Upstream does that for arm64 as well, see: 
https://github.com/rust-lang/rust/commit/ea50bf8850304e8afefa9089792fc077fb54aef4

I can try whether the combination of above all gets me a working rustc
on mips*.

Adrian

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

Bug#911708: scikit-learn breaks astroml autopkgtest: ImportError: cannot import name 'GMM'

[Ole Streicher]

Control: reassign -1 src:astroml
Control: notfound -1 scikit-learn/0.20.0+dfsg-1
Control: forwarded -1 https://github.com/astroML/astroML/issues/123

sklearn.mixture.GMM was deprecated in 0.18 and removed in 0.20, so this
is clearly a problem of astroML. I forwarded to upstream; however the
solution is probably a simple replacement in
astroML/astroML/density_estimation/xdeconv.py:17.

Cheers

Ole

Bug#911756: libconfig-model-dpkg-perl: cannot handle foo:any Build-Depends

[Felipe Sateler]

Package: libconfig-model-dpkg-perl
Version: 2.116
Severity: normal
Tags: upstream

Hi,

I tried to run `cme fix dpkg` on init-system-helpers, and got the
following error:

Configuration item 'source Build-Depends:1' has a wrong value:
bad package name: 'perl:any'

However, such annotations are valid, and in fact needed to allow
cross-compilation. Please handle foo:any annotations.

init-system-helpers in unstable can be used to reproduce the issue.

Saludos

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

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

Versions of packages libconfig-model-dpkg-perl depends on:
ii  libapt-pkg-perl0.1.34
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-perl   2.127-1
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.6-1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.002-1
ii  libtext-autoformat-perl1.74-2
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.74-1
ii  libwww-perl6.36-1
ii  libyaml-perl   1.26-1
ii  licensecheck   3.0.31-2
ii  lintian2.5.110
ii  perl [libmodule-corelist-perl] 5.26.2-7+b1

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.367-1

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#845269: patch to make backspace to 'undo' last move

[Bill Allombert]

On Sat, Oct 20, 2018 at 07:17:16PM +0200, Markus Koschany wrote:
> Hi Bill,
> 
> > that causes backspace to undo the last move. This makes this program
> > much more enjoyable.
> 
> I just tried your "undo" patch for brutalchess. I don't think it is
> complete yet. I have to press backspace twice to undo a move. But if
> this is done, I can't play another move with the same player. In case
> the second player is the computer, no other moves are possible then.

Thanks to have taken the time to try my patch.
As you can see it only add a keystroke for a feature that was already
in the original code (unlimited undo).

I agree the behavior is a bit odd (you have to press backspace 3 times
to undo a move) but I am used to it so "it works for me" :)
The only serious bug is if you try to undo the first move, then it
freezes.

I will look whether I can improve it.

Cheers
-- 
Bill. 

Imagine a large red swirl here. 

Bug#911444: python-flask-httpauth-doc: missing Breaks+Replaces: python-flask-httpauth (<< 3.2.4)

[Andreas Beckmann]

Followup-For: Bug #911444
Control: found -1 3.2.4-2

Hi,

you added the B+R to python3-flask-httpauth instead of
python-flask-httpauth-doc


Andreas

Bug#805100: x11vnc new stable release upstream (0.9.14)

[marjan cinober]

Attaching a script to automatically build latest published commit on x11vnc
(today 0.9.15) or any latter.

Attempted no-, minimal changes. Works on unstable sid, might need to tweak
on testing and stable.

I hope somebody moves it into NMU or official repository.

Regards

On Sat, 14 Nov 2015 20:24:09 +0200 Ben Browitt 
wrote:
> Package: x11vnc
> Version: 0.9.14
>
> Version 0.9.14 stable was released upstream
> https://github.com/LibVNC/x11vnc/releases/tag/0.9.14
>
> Thanks


build-x11vnc.sh
Description: application/shellscript

Bug#911750: Race condition in d-i leading to kernel from security.debian.org to be kept back

[Ben Hutchings]

On Wed, 2018-10-24 at 12:05 +0200, Raphaël Halimi wrote:
> Package: debian-installer
> Version: 20170615+deb9u4
> 
> Hi,
> 
> I just noticed a race condition in d-i, which may lead to a mild
> security risk.
> 
> When the kernel metapackage (linux-image-) is initially installed,
> APT doesn't install recommended packages, and security.debian.org
> repository is not configured yet, so the installer naturally fetches the
> latest kernel from the core suite. After APT configuration, and other
> repositories and suites are available, debian-installer runs an upgrade;
> but if a newer version of linux-image- is found in one of those
> newly available repositories (security.debian.org in this case), it's
> not installed because APT refuses to install the recommended packages
> (firware-linux-free, irqbalance) to satisfy dependencies, so the kernel
> metapackage is kept back.

I'm fairly sure it's the ABI bump in the kernel that prevents
upgrading, not the recommended packages.  This is tracked as #908711.

Ben.

> It won't be installed until the admin runs an upgrade manually, once the
> system is booted. This may put it at risk during a certain period of
> time between the first boot, and the first upgrade (and reboot).
> 
> Regards,
> 
-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.



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

Bug#911758: ssh-add doesn't recognize PKCS#11 URL

[Karen Arutyunov]

Package: openssh-client
Version: 1:7.8p1-1
Severity: important

When I specify PKCS#11 URL as a key file for ssh-add, it fails:

$ ssh-agent -s >~/ssh-agent.env
$ source ~/ssh-agent.env
Agent pid 579
$ ssh-add "pkcs11:token=auth;object=PIV%20AUTH%20pubkey"
pkcs11:token=auth;object=PIV%20AUTH%20pubkey: No such file or directory

I would expect it to work as on Fedora:

$ ssh-agent -s >~/ssh-agent.env
$ source ~/ssh-agent.env
Agent pid 31676
$ ssh-add "pkcs11:token=auth;object=PIV%20AUTH%20pubkey"
Enter passphrase for PKCS#11: **
Card added: pkcs11:token=auth;object=PIV%20AUTH%20pubkey

On Debian it behaves as if the source package is compiled with 
ENABLE_PKCS11 macro undefined, and so the PKCS#11-related code in the 
do_file() function is out (see ssh-add.c file for details).


Also note that running the following command instead works correctly:

$ ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

I am using Debian GNU/Linux buster/sid, kernel 4.18.0-2-amd64 and libc6 
2.27.

Bug#911757: zsh-antigen: please make the build reproducible

[Chris Lamb]

Source: zsh-antigen
Version: 2.2.3-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that zsh-antigen could not be built reproducibly.

This is because it uses a timezone-varying date in ANTIGEN_REVISION_DATE.

Patch-to-a-patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
+--- zsh-antigen-2.2.3.orig/Makefile.in
 zsh-antigen-2.2.3/Makefile.in
 @@ -91,8 +91,8 @@ build:
@echo "-antigen-env-setup" >> ${TARGET}
@echo "${VERSION}" > ${VERSION_FILE}
@@ -17,7 +15,7 @@
 -  @$(call ised,"s/{{ANTIGEN_REVISION}}/$$(git log -n1 --format=%h -- 
src)/",${TARGET})
 -  @$(call ised,"s/{{ANTIGEN_REVISION_DATE}}/$$(git log -n1 --format='%ai' 
-- src)/",${TARGET})
 +  @$(call ised,"s/{{ANTIGEN_REVISION}}/Debian/",${TARGET})
-+  @$(call ised,"s/{{ANTIGEN_REVISION_DATE}}/$$(date --date 
@$$(dpkg-parsechangelog -STimestamp) --rfc-3339=seconds)/",${TARGET})
++  @$(call ised,"s/{{ANTIGEN_REVISION_DATE}}/$$(date --date --utc 
@$$(dpkg-parsechangelog -STimestamp) --rfc-3339=seconds)/",${TARGET})
  ifeq (${WITH_DEBUG}, no)
@$(call isede,"s/ (WARN|LOG|ERR|TRACE) .*&//",${TARGET})
@$(call isede,"/ (WARN|LOG|ERR|TRACE) .*/d",${TARGET})

Bug#911759: manpage typo: s/"ame"/"name"/

[Josh Triplett]

Package: gawk
Version: 1:4.2.1+dfsg-1
Severity: minor

>From the gawk manpage:

   PROCINFO["ame", "NONFATAL"]
  Make I/O errors for name be nonfatal.


s/"ame"/"name"/

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

Kernel: Linux 4.18.0-2-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 gawk depends on:
ii  libc6 2.27-6
ii  libgmp10  2:6.1.2+dfsg-3
ii  libmpfr6  4.0.1-1
ii  libreadline7  7.0-5
ii  libsigsegv2   2.12-2

gawk recommends no packages.

Versions of packages gawk suggests:
pn  gawk-doc  

-- no debconf information

Bug#911756: libconfig-model-dpkg-perl: cannot handle foo:any Build-Depends

[Dominique Dumont]

On Wed, 2018-10-24 at 08:29 -0300, Felipe Sateler wrote:
> However, such annotations are valid, and in fact needed to allow
> cross-compilation. Please handle foo:any annotations.

I've never heard of this annotation. Where is it documented ?

All the best

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson]

Tollef Fog Heen writes ("Bug#904302: Whether vendor-specific patch series 
should be permitted in the archive"):
> Second draft:
...
> The Committee recognises that there is a need for packages to behave
> differently when built on different distributions, but this should be
> done by using different source packages, or as part of the build
> process, using current and future practices such as patches with
> conditional behaviour, patching of files during the build, rather than
> at source unpacking time.

This is all good but can I suggest using the phrase `differing source
packages' rather than `different' ?  `Different' might mean source
packages with different source package name.  `Differing' more clearly
refers to source packages of the same name but which are different to
each other.

Thanks,
Ian.

Bug#872089: courier-mta: TLS_TRUSTCERTS default value

[Markus Wanner]

Control: found -1 0.76.3-5
Control: severity -1 normal

Hello Viktor,

please excuse my late reply to this issue.

On 08/14/2017 02:40 PM, Viktor Szépe wrote:
> We have a typo - maybe - in four config files: 
> TLS_TRUSTCERTS=/etc/ssl/cert.pem
> The value should be /etc/ssl/certs

I can reproduce this.  On a fresh install, a grep for TLS_TRUSTCERTS in
/etc/courier yields:

courierd:TLS_TRUSTCERTS=/etc/ssl/cert.pem
esmtpd:TLS_TRUSTCERTS=/etc/ssl/cert.pem
esmtpd-ssl:TLS_TRUSTCERTS=/etc/ssl/cert.pem

Version 0.78.0-2 shipped in unstable does not show this issue, though.
And for a stable release, a change in configuration files certainly
doesn't warrant an upload.  So I'm going to close this issue.

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#911760: lightdm-gtk-greeter segfault, lightdm restart too fast, can't login to desktop

[Alex Andreotti]

Package: lightdm
Version: 1.26.0-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

A system upgrade, a list of the packages upgraded should be attached, I don't 
see any relation with lightdm but I could be missing something

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

apt update
apt upgrade
reboot

   * What was the outcome of this action?

lightdm doesn't start, segfault and restart until systemd stop it

   * What outcome did you expect instead?

the usual login dialog

Attached there should be the `journal -xe` segfault, the list of the packages 
installed by the upgrade, the backtrace of a `gdb lighdm --debug` session.
Please let me know how/if I can help with more logs.


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

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.10-1
ii  debconf [debconf-2.0]  1.5.69
ii  libaudit1  1:2.8.4-2
ii  libc6  2.27-6
ii  libgcrypt201.8.3-1
ii  libglib2.0-0   2.58.1-2
ii  libpam-systemd 239-10
ii  libpam0g   1.1.8-3.8
ii  libxcb11.13.1-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.5-1
ii  lsb-base   9.20170808

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.8-2
ii  xserver-xephyr   2:1.20.1-5

-- Configuration Files:
/etc/lightdm/lightdm.conf changed:
[LightDM]
[Seat:*]
[XDMCPServer]
[VNCServer]


-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm
Starting program: /usr/sbin/lightdm --debug --test-mode
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.03s] DEBUG: Starting Light Display Manager 1.26.0, UID=0 PID=2132
[+0.05s] DEBUG: Loading configuration dirs from 
/usr/share/lightdm/lightdm.conf.d
[+0.07s] DEBUG: Loading configuration from 
/usr/share/lightdm/lightdm.conf.d/01_debian.conf
[+0.10s] DEBUG: Loading configuration dirs from 
/usr/local/share/lightdm/lightdm.conf.d
[+0.12s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.14s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.16s] DEBUG: Registered seat module local
[+0.19s] DEBUG: Registered seat module xremote
[+0.21s] DEBUG: Registered seat module unity
[+0.23s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[New Thread 0x76714700 (LWP 2136)]
[New Thread 0x75f13700 (LWP 2137)]
[New Thread 0x756cc700 (LWP 2138)]
[+0.36s] DEBUG: Monitoring logind for seats
[+0.38s] DEBUG: New seat added from logind: seat0
[+0.40s] DEBUG: Seat seat0: Loading properties from config section Seat:*
[+0.42s] DEBUG: Seat seat0: Starting
[+0.44s] DEBUG: Seat seat0: Creating greeter session
[+0.46s] DEBUG: Seat seat0: Creating display server of type x
[+0.48s] DEBUG: posix_spawn avoided (fd close requested)
[+0.49s] DEBUG: Could not run plymouth --ping: Failed to execute child process 
?plymouth? (No such file or directory)
[+0.51s] DEBUG: Using VT 7
[+0.53s] DEBUG: Seat seat0: Starting local X display on VT 7
[+0.55s] DEBUG: XServer 0: Logging to /var/log/lightdm/x-0.log
[+0.57s] DEBUG: XServer 0: Writing X server authority to 
/var/run/lightdm/root/:0
[+0.59s] DEBUG: XServer 0: Launching X Server
[+0.61s] DEBUG: Launching process 2140: /usr/bin/X :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
[+0.63s] DEBUG: XServer 0: Waiting for ready signal from X server :0
[+0.65s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.67s] DEBUG: Registering seat with bus path 
/org/freedesktop/DisplayManager/Seat0
[+0.69s] WARNING: Error getting user list from org.freedesktop.Accounts: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Accounts was not provided by any .service files
[+0.73s] DEBUG: Loading user config from /etc/lightdm/users.conf
[+0.76s] WARNING: Failed to read password database: No such file or directory
[+0.78s] DEBUG: User alex added
[+0.80s] DEBUG: posix_spawn avoided (automatic reaping requested) (fd close 
requested)
[+0.91s] DEBUG: Seat seat0 chang

Bug#911444: python-flask-httpauth-doc: missing Breaks+Replaces: python-flask-httpauth (<< 3.2.4)

[Martín Ferrari]

On 24/10/18 13:04, Andreas Beckmann wrote:
> Followup-For: Bug #911444
> Control: found -1 3.2.4-2
> 
> Hi,
> 
> you added the B+R to python3-flask-httpauth instead of
> python-flask-httpauth-doc

Oh, ffs. Sorry, I will reupload now


-- 
Martín Ferrari (Tincho)

Bug#911605: remove addresses of retired DDs from cdvendors@d.o alias

[Mattia Rizzolo]

On Wed, Oct 24, 2018 at 03:19:42PM +0200, Laura Arjona Reina wrote:
> I have removed atte...@debian.org from the CDVENDORS entry in 
> www-master.debian.org
> I didn't find spaill...@debian.org there, but it was present in the
> WEBMASTER entry, and since it's a retired address that won't work anymore, I
> have removed it from there.

thanks!

> FTR, these "aliases" are maintained in /srv/www.debian.org/mail/.mailfilter
> in www-master.debian.org machine.

TTBOMK/AFAICT www-master (i.e. host=wolkenstein) is a restricted machine
that only people with these gids can access:
allowedGroups: d-i
allowedGroups: debvote
allowedGroups: debwww
allowedGroups: mirroradm
allowedGroups: portforwarder
allowedGroups: publicity
allowedGroups: search
allowedGroups: staticsync
allowedGroups: weblogsync
so neither me nor holger can access that file (besides, I find odd those
are configured in a .mailfilter file and not in the usual "alias" file;
I suppose that your alias file just point to procmail and that
.mailfilter file is actually a procmail filter which takes care of
forwarding?   I can't imagine anything else).  Is that right that your
whole mail setup is not in any public git or something?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#911761: sphinxsearch: New upstream releases 3.1.x

[Patrick Matthäi]

Package: sphinxsearch
Version: 2.2.11-2
Severity: normal

Hello,

please package sphinxsearch 3.1.x. 2.2.1 is quite outdated.

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

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

Versions of packages sphinxsearch depends on:
ii  adduser 3.115
ii  libc6   2.24-11+deb9u3
ii  libexpat1   2.2.0-2+deb9u1
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libmariadbclient18  10.1.26-0+deb9u1
pn  libpq5  
ii  libstdc++6  6.3.0-18+deb9u1
ii  libstemmer0d0+svn585-1+b2
ii  zlib1g  1:1.2.8.dfsg-5

sphinxsearch recommends no packages.

sphinxsearch suggests no packages.

Bug#891410: upstream work is already in progress

[Michael Barkdoll]

On Sun, 07 Oct 2018 15:07:32 +0200 "Hein, Jochen" wrote:
> Hello again,
>
> Am 2018-07-02 21:05, schrieb Christoph Biedl:
> > Thanks for reminding me, it's on radar - but given the discussion
> > hasn't
> > been finished yet I'd prefer to wait until this is part of another
> > clevis release. If you'd like to have it cherry-picked so people can
> > start playing with it, let me know.
>
> Hm, the usptream discussion seems to have stalled. Since the
> freeze for buster is nearing I'd like to see it cherry-picked.
> What do you think?
>
> Jochen
>
> --
> The only problem with troubleshooting is that the trouble shoots back.
>
>

I'd also love to see this cherry-picked.


Michael Allen Barkdoll
Computer Systems Architecture Specialist
Office: 618-453-6051 | Email: mbarkd...@cs.siu.edu
**
Department of Computer Science, Southern Illinois University of Carbondale
Engineering A0311C, Mail Code 4511, 1230 Lincoln Drive, Carbondale, IL 62901
Main Office: 618-536-2327 | Fax: 618-453-6044 | Lab Assistants: 618-453-6052
**

Bug#879530: courier: contains code related to gnutls pgp supprt

[Markus Wanner]

Control: tags +1 pending

On 10/22/2017 06:30 PM, Andreas Metzler wrote:
> GnuTLS stopped enabling OPENPGP certificates by default in 3.0.2 (Sept
> 2011). OpenPGP support in gnutls was removed in 3.6.0. (Noop stub
> functions are still shipped to avoid ABI breakage.)
> 
> Therefore imho it makes sense to drop the pgp/gnutls code from courier.

thanks a lot for your patch.  The next upload will include it.

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#911762: trash-cli: FTBFS - segmentation fault during test phase

[Jonathan Dowland]

Source: trash-cli
Version: 0.12.9.14-2.1
Severity: serious

FTBFS as per attached. sbuild fails too

I'm hoping this is cured by the new upstream version and/or
tightening a python version, and I'm going to attempt to fix
it.

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

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

-- no debconf information
$ gbp buildpackage -rfakeroot -us -uc
 dpkg-buildpackage -rfakeroot -us -uc -i -I
dpkg-buildpackage: info: source package trash-cli
dpkg-buildpackage: info: source version 0.12.9.14-3
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Javi Merino 
 dpkg-source -i -I --before-build trash-cli
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --with python2
   debian/rules override_dh_clean
make[1]: Entering directory '/home/jon/git/debian/trash/trash-cli'
rm -rf trash_cli.egg-info/
make[1]: Leaving directory '/home/jon/git/debian/trash/trash-cli'
 dpkg-source -i -I -b trash-cli
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building trash-cli using existing 
./trash-cli_0.12.9.14.orig.tar.gz
dpkg-source: info: building trash-cli in trash-cli_0.12.9.14-3.debian.tar.xz
dpkg-source: info: building trash-cli in trash-cli_0.12.9.14-3.dsc
 debian/rules build
dh build --with python2
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
python setup.py build --force
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/trashcli
copying trashcli/fs.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/rm.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/cmds.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/list_mount_points.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/trash.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/__init__.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/fstab.py -> build/lib.linux-x86_64-2.7/trashcli
running build_scripts
creating build/scripts-2.7
copying and adjusting bin/trash-list -> build/scripts-2.7
copying and adjusting bin/trash -> build/scripts-2.7
copying and adjusting bin/trash-put -> build/scripts-2.7
copying and adjusting bin/restore-trash -> build/scripts-2.7
copying and adjusting bin/trash-empty -> build/scripts-2.7
copying and adjusting bin/trash-rm -> build/scripts-2.7
changing mode of build/scripts-2.7/trash-list from 644 to 755
changing mode of build/scripts-2.7/trash from 644 to 755
changing mode of build/scripts-2.7/trash-put from 644 to 755
changing mode of build/scripts-2.7/restore-trash from 644 to 755
changing mode of build/scripts-2.7/trash-empty from 644 to 755
changing mode of build/scripts-2.7/trash-rm from 644 to 755
   debian/rules override_dh_auto_test
make[1]: Entering directory '/home/jon/git/debian/trash/trash-cli'
nosetests
.SS...debian/rules:12: recipe for target 
'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Segmentation fault
make[1]: Leaving directory '/home/jon/git/debian/trash/trash-cli'
debian/rules:4: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1116:
dpkg-buildpackage -rfakeroot -us -uc -i -I failed
gbp:error: 'debuild -i -I -rfakeroot -us -uc' failed: it exited with 29

Bug#907680: pass: encrypting a password spend minutes in gpg2

[Brice Goglin]

It looks there's an issue with my gpg doing a checkdb way too often,
I don't know why. Passing PASSWORD_STORE_GPG_OPTS=--no-auto-check-trustdb
to pass makes the issue disappear.

Brice

Bug#904248: Beginnings of a patch to add netbase to build-essential

[Sean Whitton]

Hello Mattia,

On Fri 12 Oct 2018 at 01:45PM +0200, Mattia Rizzolo wrote:

> I hereby disagree with this approach.
> I think that if we were going this way, build-essential should just
> start depending on netbase instead.
>
> Changing the Policy wording to say that build-essential should also
> provide networking base stuff it's probably fine though.

Sorry, what exactly is it you are fine with?

> I think we also need a wider request for /etc/services and
> /etc/protocols.  Till now I only heard Ian asking for it, so I believe
> there needs to be a wider request.

Fair enough.

> Talking about the proposed wording: the text within parenthesis mentions
> "versioned build-dependency", but the package it's talking about
> (netbase, I suspect) it's only mentioned in the footnote, which is an
> issue in my book.

What it means is that you need a versioned b-d on netbase if you need a
really new service.  Just like you might need a versioned b-d on
something else in build-essential if you need particular new features.

> On the note of /etc/hosts, I'm fixing the original bug rised by Simon
> McVittie (that was triggered by tests.reproducible-builds.org not
> resolving localhost) within pbuilder (#905307) btw.

Cool, thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#911758: ssh-add doesn't recognize PKCS#11 URL

[Colin Watson]

Control: tag -1 wishlist
Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=2817

On Wed, Oct 24, 2018 at 03:29:32PM +0300, Karen Arutyunov wrote:
> When I specify PKCS#11 URL as a key file for ssh-add, it fails:
> 
> $ ssh-agent -s >~/ssh-agent.env
> $ source ~/ssh-agent.env
> Agent pid 579
> $ ssh-add "pkcs11:token=auth;object=PIV%20AUTH%20pubkey"
> pkcs11:token=auth;object=PIV%20AUTH%20pubkey: No such file or directory
> 
> I would expect it to work as on Fedora:

It looks like support for this is only in a (rather large)
Fedora-specific patch:

  
https://src.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.6p1-pkcs11-uri.patch

I don't understand this well enough to incorporate it, especially as it
would be larger than any of the individual patches we're currently
carrying (even larger than the GSSAPI key exchange patch, which is
already a significant maintenance headache).

The author of this patch set sent it upstream here:

  https://bugzilla.mindrot.org/show_bug.cgi?id=2817

I'd very much rather wait for it to be accepted there.

Thanks,

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

Bug#911605: remove addresses of retired DDs from cdvendors@d.o alias

[Laura Arjona Reina]

Hi again

El 24/10/18 a las 15:25, Mattia Rizzolo escribió:

On Wed, Oct 24, 2018 at 03:19:42PM +0200, Laura Arjona Reina wrote:

I have removed atte...@debian.org from the CDVENDORS entry in 
www-master.debian.org
I didn't find spaill...@debian.org there, but it was present in the
WEBMASTER entry, and since it's a retired address that won't work anymore, I
have removed it from there.


thanks!


FTR, these "aliases" are maintained in /srv/www.debian.org/mail/.mailfilter
in www-master.debian.org machine.


TTBOMK/AFAICT www-master (i.e. host=wolkenstein) is a restricted machine
that only people with these gids can access:
allowedGroups: d-i
allowedGroups: debvote
allowedGroups: debwww
allowedGroups: mirroradm
allowedGroups: portforwarder
allowedGroups: publicity
allowedGroups: search
allowedGroups: staticsync
allowedGroups: weblogsync
so neither me nor holger can access that file 


The "FTR" was mainly to document what I've done, so I can remember more easily 
next time, if needed.



(besides, I find odd those

are configured in a .mailfilter file and not in the usual "alias" file;
I suppose that your alias file just point to procmail and that
.mailfilter file is actually a procmail filter which takes care of
forwarding?   


The file contains some definitions for the different addresses that are shown 
(or have a webform) in www.debian.org and then some parsing of the incoming mail 
to drop or send to spam, or log and deliver to the correct places.


I can't imagine anything else).  Is that right that your

whole mail setup is not in any public git or something?



Probably not. I will file a separate bug about reviewing, updating and 
documenting the mail setup of www.debian.org-related addresses.


Kind regards

--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#896165: linux: request packaging of bpftool

[Robert Haist]

Source: linux
Version: 4.16.5-1
Followup-For: Bug #896165

control: severity -1 important

Dear Maintainers,

I would like to add the packaging of a direct dependency to the list: libbpf.
This library is most useful for using currently ongoing extensions of the linux
kernel towards a new high-speed packet processing layer called XDP which uses
eBPF.

One software currently in Debian that might directly benefit from this library
is suricata (https://suricata.readthedocs.io/en/latest/capture-hardware/ebpf-
xdp.html).
Please consider to maybe include this library in your current endeavors to
allow us supporting this feature in the suricata package and future software to
come.

Thank you,
Robert Haist

Bug#911680: xserver-xorg-core: X server crashes when loading libglamorgl.so module (Bug #911680)

[Massimo MANGHI]

Hello Bernhard

thank you for taking care of the problem so quickly

On 10/23/18 9:24 PM, Bernhard Übelacker wrote:
> Hello Massimo Manghi,
> just tried to reproduce the issue inside a debian buster amd64 qemu VM.
> I never hit the crash and found you were probably running inside a VirtualBox.
> 

you got it

> Nevertheless with installed debug informations I think the crash shown
> in the Xorg.log points to that location:
> 
> 
> [...]
> 
> glamor/glamor_egl.c:
> 990
> 991 renderer = glGetString(GL_RENDERER);
> 992 if (strstr((const char *)renderer, "llvmpipe")) {
> 993 xf86DrvMsg(scrn->scrnIndex, X_INFO,
> 994"Refusing to try glamor on llvmpipe\n");
> 
> 
> Therefore my guess would be that "glGetString(GL_RENDERER)" returns
> in VirtualBox (or at least that installation) something odd.
> 
> 
> That line originates from this patch that is applied upstream and
> I assume is cherry picked [1] for that debian package version:
> ./debian/patches/08_dont-init-glamor-on-llvmpipe.diff
> 
> Upstream added on top of that another patch [2] to
> avoid a crash that is probably exact that one we see here.
> 

very good, I guess this clarifies the issue and the new patch will be 
included in the next upload, is it correct? Am I supposed to take any 
further action? Something like changing the bug status or applying some 
extra tag to the bug in order to specify the environment (VirtualBox) 
where the problem occurs?

  thank you a lot

  regards

  -- Massimo

Bug#911760: lightdm: more info

[Alex Andreotti]

Package: lightdm
Version: 1.26.0-3
Followup-For: Bug #911760

Could have something to do with the systemd/libpam upgrade? 
I have another issue with a password prompter (see attachment)
Oct 24 15:42:45 hellspawn gpg-agent[1931]: failed to unprotect the secret key: 
Inappropriate ioctl for device
Oct 24 15:42:45 hellspawn gpg-agent[1931]: failed to read the secret key
Oct 24 15:42:45 hellspawn gpg-agent[1931]: command 'PKDECRYPT' failed: 
Inappropriate ioctl for device 
Oct 24 15:42:45 hellspawn dbus-daemon[1485]: [session uid=1000 pid=1485] 
Activating service name='org.gnome.keyring.SystemPrompter' requested by ':1.22' 
(uid=1000 pid=1986 comm="pinentry --display :0 ")
Oct 24 15:42:45 hellspawn dbus-daemon[1485]: [session uid=1000 pid=1485] 
Activated service 'org.gnome.keyring.SystemPrompter' failed: Process 
org.gnome.keyring.SystemPrompter received signal 11
Oct 24 15:42:45 hellspawn gpg-agent[1931]: No Gcr System Prompter available, 
falling back to curses
Oct 24 15:42:45 hellspawn kernel: gcr-prompter[1991]: segfault at 696e6420 ip 
7ff4696c5907 sp 7fff5a80b198 error 4 in 
libc-2.27.so[7ff46958d000+146000]
Oct 24 15:42:45 hellspawn kernel: Code: f9 20 77 1f c5 fd 74 0f c5 fd d7 c1 85 
c0 0f 85 df 00 00 00 48 83 c7 20 83 e1 1f 48 83 e7 e0 eb 36 66 90 83 e1 1f 48 
83 e7 e0  fd 74 0f c5 fd d7 c1 d3 f8 85 c0 74 1b f3 0f bc c0 48 01 f8 48 

Bug#911763: espresso: FTBFS on ppc64el, armhf, riscv64

[Frédéric Bonnard]

Package: src:espresso
Version: 6.3-3

--

Dear maintainer,
I saw that espresso fails to build on ppc64el, armhf, riscv64 due to
config.guess being outdated in an embedded source tarball (fox library)

https://buildd.debian.org/status/fetch.php?pkg=espresso&arch=ppc64el&ver=6.3-3&stamp=1539285659&raw=0

I tried bringing some updated config.guess etc and use dh_autoreconf but
fall into that issue : https://github.com/andreww/fox/issues/4

So I fallback to a quick patch to copy config.sub and config.guess on
the fly with fox source directory.

I'll send a merge request.

F.


pgpu_R0QPOahE.pgp
Description: PGP signature


pgpzkP4U8iOEa.pgp
Description: PGP signature

Bug#911764: nautilus-wipe should confirm that it is cancelling the wipe process as soon as the user cancels

[Ulrike Uhlig]

Package: nautilus-wipe
Severity: wishlist

Dear Maintainer,

The current user flow for cancelling a Wipe Available Disk Space process
needs some UX love.

Current situation:

When using the "Wipe Available Disk Space" feature on a 4GB FAT
formatted drive, the process seemed to be taking to long so a user
cancelled, after which a confirmation dialog appears and "Cancel
operation" is pressed. When that happens, the confirmation dialog
disappears but the Wipe Available Disk Space dialog is still there,
unchanged, and seems like it's ignoring the cancel request for a period
of time close to a minute before a cryptic message finally appears to
confirm it was cancelled.

How should the software behave:

Ideally, this flow should change so that when a user confirms the
cancellation, the Wipe Available Disk Space dialog should change to
indicate that the cancellation is being processed. This can be as simple
as changing the "Wiping available disk space..." copy to "Cancelling..."
Instead of seeing a cryptic message when the cancellation kicks in, the
displayed cancellation confirmation should just say that the wipe was
cancelled.

This was reported here: https://labs.riseup.net/code/issues/16066

I have contacted the upstream author by email, as indicated here:
https://wipetools.tuxfamily.org/nautilus-wipe.html

Bug#911765: unattended-upgrades can be very slow with needrestart and apt-listbugs

[Antoine Beaupre]

Package: unattended-upgrades
Version: 1.6
Severity: normal

Extra features like apt-listbugs or needrestart can make
unattended-upgrades needlessly slow, especially in case of poor
network conditions (in the case of apt-listbugs).

This morning, my IPv6 connexion was down and this meant that
apt-listbugs would hang for a few minutes every time it would be
called. In a normal `apt upgrade` run, this wouldn't be much of a
problem: just take the hit once and we go along with the rest of the
upgrade.

But now my daily `testing` updates have been running for 45
minutes. During that time, it managed to upgrade only a dozen
packages, and nothing fancy:

$ sed -n '/2018-10-24/,$p' < 
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log | grep Dépaquetage
 Dépaquetage de debhelper (11.4.1) sur (11.3.5) ...
Dépaquetage de geoclue-2.0 (2.5.1-1) sur (2.5.0-2) ...
Dépaquetage de gir1.2-geoclue-2.0:amd64 (2.5.1-1) sur (2.5.0-2) ...
Dépaquetage de gir1.2-rest-0.7 (0.8.1-1) sur (0.8.0-2) ...
Dépaquetage de hdparm (9.57+ds-1) sur (9.56+ds-2) ...
Dépaquetage de libgeoclue-2-0:amd64 (2.5.1-1) sur (2.5.0-2) ...
Dépaquetage de libllvm6.0:amd64 (1:6.0.1-9.1) sur (1:6.0.1-9) ...
Dépaquetage de libmail-message-perl (3.007-1) sur (3.006-1) ...
Dépaquetage de libmail-transport-perl (3.003-1) sur (3.002-1) ...
Dépaquetage de libopenmpt-modplug1:amd64 (0.3.13-1) sur (0.3.12-1) ...
Dépaquetage de libopenmpt0:amd64 (0.3.13-1) sur (0.3.12-1) ...
Dépaquetage de librest-0.7-0:amd64 (0.8.1-1) sur (0.8.0-2) ...
Dépaquetage de libsocket6-perl (0.29-1) sur (0.28-1) ...

We could argue this is a bug in apt-listbugs - it should give us
"happy eyeballs" and fallback correctly to IPv4 in case of network
outages. But this is still slower than it should be. And then there's
`needrestart`, which can also take a significant amount of CPU,as it
inspects the whole process trees and forests of Perl libraries, which
is ran after each invocation, when it could be ran only once.

Shouldn't we run all those hooks only once? One time before
unattended-upgrade starts, and one time when it finishes, for all
packages?

I mean even now than I fixed the network, the upgrade seems
excruciatingly slow. Now the culprit is needrestart which adds a good
30 seconds to each package upgrade.

I do not, as far as I can tell, run in "minimal steps" mode:

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "false";

Although it's a little unclear to me if the above documents the
value, so I'm unsure if MinimalSteps is enabled here.

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

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  gir1.2-glib-2.01.58.0-1
ii  lsb-base   9.20170808
ii  lsb-release9.20170808
ii  powermgmt-base 1.33
ii  python33.6.6-1
ii  python3-apt1.7.0
ii  python3-gi 3.30.1-1
ii  ucf3.0038
ii  xz-utils   5.2.2-1.3

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-24
ii  cron [cron-daemon]  3.0pl1-130

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx   8.1.2-0.20180807cvs-1
ii  needrestart 3.3-1
ii  postfix [mail-transport-agent]  3.3.0-1+b1

-- debconf-show failed

Bug#799295: Bug 799295 - lvm2 - Errors about lvmetad on boot

[bakhelit]

I can also see the mentioned warnings about lvmetad on all my Debian 
Stretch systems. Messages seems to be indeed caused by lvm "vgscan", 
"vgchange" and may be also "lvchange" commands in "cryptroot" and "lvm2" 
initramfs scripts in "/usr/share/initramfs-tools/scripts/local-*".


Because I wanted to achieve the silent boot with just the password 
prompt from cryptsetup I modified the workaround mentioned by Matti 
Kurkela (as it seemed not to work for my systems). Instead of adding " 
--config 'global{use_lvmetad=0}'" to the lvm commands I now redirect 
their output to a log file by adding " >>/run/log/initrd-lvm 2>&1". 
(Note that the "/run/log" directory must exist when the output is 
redirected. Also the modified initramfs scripts should be in 
"/etc/initramfs-tools/scripts/local-*" and you need to rebuild your 
initramfs as described by Matti Kurkela above.)


It would be nice to have a "--quiet" option for lvm commands, maybe?

Regards
Bakhelit

Bug#812380: apt warns about /apt/apt.conf.d/50unattended-upgrades.ucf-dist

[Antoine Beaupre]

Not sure when/if that was fixed, but I have a
50unattended-upgrades.ucf-old file here and it's not generating any
warnings anymore, in Debian buster. I guess there was a change in APT
that made this less verbose and did not fix this bug per se...

On Fri, Jan 22, 2016 at 08:56:43PM -0400, Joey Hess wrote:
> Package: unattended-upgrades
> Version: 0.86.5+build1
> Severity: normal
> 
> Since I have the config file modified, every upgrade of
> unattended-upgrades drops a .ucf-dist copy, which causes every run of
> apt to warn about the file being ignored.

-- 
Be yourself. Everyone else is already taken!
- Oscar Wilde


signature.asc
Description: PGP signature

Bug#907835: newer version in stable

[Antoine Beaupré]

On 2018-10-24 13:43:34, Hans van Kranenburg wrote:
> Control: fixed 907835 4.11.1~pre.20180911.5acdd26fdc+dfsg-5
>
> On 9/26/18 4:22 PM, Ian Jackson wrote:
>> Antoine Beaupré writes ("Re: [Pkg-xen-devel] Bug#907835: newer version in 
>> stable"):
>>> It's been two weeks and stable still has a newer version than unstable,
>>> which suffers from four security issues fixed in stable.
>>>
>>> I understand you might have other plans in the long term, but in the
>>> meantime, why not just upload deb9u10 to unstable?
>> 
>> I went to do this but sadly, it no longer builds due to gcc8.  There
>> are upstream patches that could be cherry-picked but it's certainly no
>> longer simply a matter of importing the security update.
>> 
>> I am going to look at these failures since they are blocking my
>> package refactoring work and I expect that as an output I will produce
>> a list of upstream commits to cherry pick, which I will send to this
>> bug.
>
> Xen 4.11 has now transitioned to testing! \o/
>
> So, the weird situation has been resolved.

Great! Thanks everyone! :)

a.

-- 
During times of universal deceit, telling the truth becomes a
revolutionary act.   - Georges Orwell

Bug#911765: unattended-upgrades can be very slow with needrestart and apt-listbugs

[Antoine Beaupré]

On 2018-10-24 10:20:47, Antoine Beaupre wrote:
> // Split the upgrade into the smallest possible chunks so that
> // they can be interrupted with SIGTERM. This makes the upgrade
> // a bit slower but it has the benefit that shutdown while a upgrade
> // is running is possible (with a small delay)
> //Unattended-Upgrade::MinimalSteps "false";

As it turns out, the config file documents the *opposite* of the
default, not the default. So I *do* have minimal steps enabled, as is by
default. Of course I assume that commenting out that line will resolve
my issue but I haven't tested that scenario just yet.

A.

-- 
I worry about my child and the Internet all the time, even though
she's too young to have logged on yet. Here's what I worry about. I
worry that 10 or 15 years from now, she will come to me and say
'Daddy, where were you when they took freedom of the press away from
the Internet?'   - Mike Godwin, Electronic Frontier Foundation

Bug#911757: zsh-antigen: please make the build reproducible

[Daniel Shahaf]

Chris Lamb wrote on Wed, Oct 24, 2018 at 08:38:36 -0400:
> @@ -17,7 +15,7 @@
> -+@$(call ised,"s/{{ANTIGEN_REVISION_DATE}}/$$(date --date 
> @$$(dpkg-parsechangelog -STimestamp) --rfc-3339=seconds)/",${TARGET})
> ++@$(call ised,"s/{{ANTIGEN_REVISION_DATE}}/$$(date --date --utc 
> @$$(dpkg-parsechangelog -STimestamp) --rfc-3339=seconds)/",${TARGET})

Chris, are you sure that's right?  According to date(1), the --date
option takes an argument, so that would seem to take "--utc" as the date
to parse:

% date --date --utc @1 
date: the argument ‘@1’ lacks a leading '+';
when using an option to specify date(s), any non-option
argument must be a format string beginning with '+'
Try 'date --help' for more information.
zsh: exit 1 date --date --utc @1
% date --utc --date @1
Thu Jan  1 00:00:01 UTC 1970
% 

>  -@$(call ised,"s/{{ANTIGEN_REVISION}}/$$(git log -n1 --format=%h -- 
> src)/",${TARGET})
>  -@$(call ised,"s/{{ANTIGEN_REVISION_DATE}}/$$(git log -n1 --format='%ai' 
> -- src)/",${TARGET})
>  +@$(call ised,"s/{{ANTIGEN_REVISION}}/Debian/",${TARGET})

Tangentially, Michael, here you might consider changing the hardcoded
"Debian" to the package version, $$(dpkg-parsechangelog -SVersion).  The
zsh and zsh-syntax-highlighting packages do this, too.

Cheers,

Daniel
(not subscribed to the bug, please Cc)

Bug#911750: Race condition in d-i leading to kernel from security.debian.org to be kept back

[Raphaël Halimi]

Le 24/10/2018 à 14:15, Ben Hutchings a écrit :
>> When the kernel metapackage (linux-image-) is initially installed,
>> APT doesn't install recommended packages, and security.debian.org
>> repository is not configured yet, so the installer naturally fetches the
>> latest kernel from the core suite. After APT configuration, and other
>> repositories and suites are available, debian-installer runs an upgrade;
>> but if a newer version of linux-image- is found in one of those
>> newly available repositories (security.debian.org in this case), it's
>> not installed because APT refuses to install the recommended packages
>> (firware-linux-free, irqbalance) to satisfy dependencies, so the kernel
>> metapackage is kept back.
> 
> I'm fairly sure it's the ABI bump in the kernel that prevents
> upgrading, not the recommended packages.  This is tracked as #908711.

You're right, it seems so obvious now.

Sorry for the duplicate, I did search the web for "bugs debian-installer
kernel not upgraded during installation" but the title of this bug was
too different, and I missed it.

Do you want me to close this one, or to merge it ?

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#911766: libatspi2.0-0: All GTK+ applications segfault unless exporting NO_AT_BRIDGE=1

[Daniel Dehennin]

Package: libatspi2.0-0
Version: 2.30.0-3
Severity: important

Dear Maintainer,

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

Hello.

I just got the upgrade of the libatspi2.0-0 from Unstable and I'm not
able to use GTK applications.

- I can't connect with lightdm-gtk-greeter, but slick-greeter works fine
- I can't run emacs-gtk

After installing several -dbgsym I finally got the following backtrace
for Emacs:

gdb emacs
GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from emacs...Reading symbols from 
/usr/lib/debug/.build-id/3c/737718fa7c1b4dfcd5201b9e40af46f36d9222.debug...done.
done.
(gdb) run
Starting program: /usr/bin/emacs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffedb9f700 (LWP 5346)]

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:32
32  ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or 
directory.
(gdb) backtrace
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:32
#1  0x76bb2974 in g_log_find_domain_L 
(log_domain=log_domain@entry=0x696e6422 ) at ../../../../glib/gmessages.c:618
#2  0x76bb3c21 in g_logv (log_domain=0x696e6422 , log_level=G_LOG_LEVEL_WARNING, format=, args=args@entry=0x7fffc260) at ../../../../glib/gmessages.c:1334
#3  0x76bb3edf in g_log (log_domain=log_domain@entry=0x696e6422 , log_level=log_l
at ../../../../glib/gmessages.c:1413
#4  0x7fffee89a342 in get_accessibility_bus_address_dbus () at 
../atspi/atspi-misc.c:1533
#5  atspi_get_a11y_bus () at ../atspi/atspi-misc.c:1597
#6  0x734e760a in atk_bridge_adaptor_init () from 
/usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0
#7  0x771d5664 in _gtk_accessibility_init () at 
../../../../gtk/a11y/gtkaccessibility.c:992
#8  0x7737fd39 in default_display_notify_cb (dm=) at 
../../../../gtk/gtkmain.c:712
#9  0x76c8cb6d in g_closure_invoke (closure=0xb42ca0, return_value=0x0, 
n_param_values=2, param_values=0x7fffc610, invocation_hi
#10 0x76c9f8f3 in signal_emit_unlocked_R (node=node@entry=0xb3c200, 
detail=detail@entry=62, instance=instance@entry=0x13aa200, emiss
#11 0x76ca8882 in g_signal_emit_valist (instance=, 
signal_id=, detail=, var_args=var_ar
#12 0x76ca8ecf in g_signal_emit (instance=instance@entry=0x13aa200, 
signal_id=, detail=) at ../../../.
#13 0x76c911d4 in g_object_dispatch_properties_changed 
(object=0x13aa200, n_pspecs=, pspecs=) at ../..
#14 0x76c93651 in g_object_notify_by_spec_internal (pspec=, object=0x13aa200) at ../../../../gobject/gobject.c:1181
#15 g_object_notify (object=object@entry=0x13aa200, 
property_name=property_name@entry=0x770ec76f "default-display") at 
../../../../gobje
#16 0x7707f629 in gdk_display_manager_set_default_display 
(manager=manager@entry=0x13aa200, display=) at ../../../../
#17 0x7707f9b8 in _gdk_display_manager_add_display (manager=0x13aa200, 
display=0xb58100) at ../../../../gdk/gdkdisplaymanager.c:489
#18 0x76c8cb6d in g_closure_invoke (closure=0xb413e0, return_value=0x0, 
n_param_values=1, param_values=0x7fffcb00, invocation_hi
#19 0x76c9f124 in signal_emit_unlocked_R (node=node@entry=0xb42800, 
detail=detail@entry=0, instance=instance@entry=0xb58100, emissio
#20 0x76ca8882 in g_signal_emit_valist 
(instance=instance@entry=0xb58100, signal_id=signal_id@entry=3, 
detail=detail@entry=0, var_ar
#21 0x76ca93a4 in g_signal_emit_by_name 
(instance=instance@entry=0xb58100, 
detailed_signal=detailed_signal@entry=0x770ec73c "ope
#22 0x770aaf5a in _gdk_x11_display_open (display_name=) 
at ../../../../../gdk/x11/gdkdisplay-x11.c:1799
#23 0x7707f82d in gdk_display_manager_open_display (manager=, name=0xab3260 ":0") at ../../../../gdk/gdkdisplaymanage
#24 0x77380f1a in gtk_init_check (argc=, argv=) at ../../../../gtk/gtkmain.c:1104
#25 0x77380f49 in gtk_init (argc=argc@entry=0x7fffd060, 
argv=argv@entry=0x7fffd080) at ../../../../gtk/gtkmain.c:1161
#26 0x004cdd55 in x_term_init 
(display_name=display_name@entry=11740228, xrm

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

[Sebastian Meyer]

Yesterday I updated

elpa-ess:amd64 (17.11-4~ubuntu16.04.1~ppa1, 18.10-1xenial0)

from the package repository at

https://cran.wu.ac.at/bin/linux/ubuntu/xenial

I now have the same symptoms as described by Zack previosly.

Running emacs -q, evaluating (require 'ess-site), and checking the value
of the variable ess-etc-directory gives me

/usr/share/ess/etc/

However, there is no /usr/share/ess directory on my system.

ess-etc-directory is defined in ess-site.el at

/usr/share/emacs24/site-lisp/elpa/ess-18.10/ess-site.el
-> /usr/share/emacs/site-lisp/elpa-src/ess-18.10//ess-site.el

which contains

> (defvar ess-etc-directory "/usr/share/ess/etc/"
>   "Location of the ESS etc/ directory.
> The ESS etc directory stores various auxillary files that are useful
> for ESS, such as icons.")

This differs from the upstream file, which defines the value as nil, see
https://github.com/emacs-ess/ESS/blob/v18.10/lisp/ess-site.el#L70

My knowledge of the Debian packaging mechanisms is rudimentary, but
searching for the /usr/share/ess path I found a corresponding overwrite
in debian/rules, see
https://salsa.debian.org/edd/ess/blob/master/debian/rules#L72

Is this intended?

Thanks a lot and best regards,

   Sebastian


-- 
Dr. Sebastian Meyer
Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)
Institut für Medizininformatik, Biometrie und Epidemiologie (IMBE)

Bug#911767: stable-pu: package lastpass-cli/1.0.0-1.2+deb9u1

[Chris Lamb]

Package: release.debian.org
Severity: normal
Tags: stable
User: release.debian@packages.debian.org
Usertags: pu

Dear stable release managers,

Please consider lastpass-cli (1.0.0-1.2+deb9u1) for stable:
  
  lastpass-cli (1.0.0-1.2+deb9u1) stable; urgency=medium
  
* Backport hardcoded certificate pins from lastpass-cli 1.3.1 to reflect
  changes in hosted Lastpass.com service. (Closes: #898940)
* Add missing ca-certificates to Depends.


The full diff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/changelog b/debian/changelog
index a49b342..3283985 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lastpass-cli (1.0.0-1.2+deb9u1) stable; urgency=medium
+
+  * Backport hardcoded certificate pins from lastpass-cli 1.3.1 to reflect
+changes in hosted Lastpass.com service. (Closes: #898940)
+  * Add missing ca-certificates to Depends.
+
+ -- Chris Lamb   Wed, 24 Oct 2018 10:40:01 -0400
+
 lastpass-cli (1.0.0-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index 5d13597..64c4ed5 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.9.8.0
 
 Package: lastpass-cli
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, binutils
+Depends: ${shlibs:Depends}, ${misc:Depends}, binutils, ca-certificates
 Description: command line interface to LastPass.com
  This application is a command line interface to the LastPass.com services. It
  brings both better security and convenience by allowing you to access, add,
diff --git 
a/debian/patches/0004-backport-hardcoded-certificate-pins-from-1.3.1.patch 
b/debian/patches/0004-backport-hardcoded-certificate-pins-from-1.3.1.patch
new file mode 100644
index 000..60cab8d
--- /dev/null
+++ b/debian/patches/0004-backport-hardcoded-certificate-pins-from-1.3.1.patch
@@ -0,0 +1,26 @@
+From: Chris Lamb 
+Date: Wed, 24 Oct 2018 10:33:53 -0400
+Subject: Backport hardcoded certificate pins from lastpass 1.3.1 to reflect
+ changes in the hosted LastPass.com service. (Closes: #898940)
+
+---
+ pins.h | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/pins.h b/pins.h
+index e629b6f..7455574 100644
+--- a/pins.h
 b/pins.h
+@@ -5,8 +5,12 @@ const char *PK_PINS[] = {
+   "HXXQgxueCIU5TTLHob/bPbwcKOKw6DkfsTWYHbxbqTY=",
+   /* current lastpass.eu primary (AddTrust) */
+   "lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=",
++  /* future lastpass root CA (GlobalSign R1) */
++  "K87oWBWM9UZfyddvDfoxL+8lpNyoUB2ptGtn0fv6G2Q=",
+   /* future lastpass root CA (GlobalSign R2) */
+   "iie1VXtL7HzAMF+/PVPR9xzT80kQxdZeJ+zduCB3uj0=",
++  /* future lastpass root CA (GlobalSign R3) */
++  "cGuxAXyFXFkWm61cF4HPWX8S0srS9j0aSqN0k4AP+4A=",
+   /* future lastpass.com primary (leaf) */
+   "0hkr5YW/WE6Nq5hNTcApxpuaiwlwy5HUFiOt3Qd9VBc=",
+   /* future lastpass.com backup (leaf) */
diff --git a/debian/patches/series b/debian/patches/series
index 45a126b..1e88d92 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 0001-cipher-support-opaque-EVP_CIPHER_CTX.patch
 0002-cipher-drop-p8inf-broken-flag-check.patch
 0003-pbkdf2-support-openssl-1.1.patch
+0004-backport-hardcoded-certificate-pins-from-1.3.1.patch

Bug#856638: apt: "apt-get update" downloads of '/var/lib/apt/lists/partial/*_debian_dists_testing_InRelease' unsandboxed

[Antoine Beaupré]

On 2017-03-10 08:34:26, David Kalnischkies wrote:
> Not sure apt can really do anything about this… we could auto-fixup
> permissions perhaps, but that feels rather strange to do given that
> there might be a deliberate choice of the user involved (for reasons as
> of yet unknown) and a (different) warning would both be annoying (for
> the deliberate choice user) as well as not really helpful for the
> unsuspecting user… but perhaps no by-choice user exist… mhhh.

For me this is a regression since the buster upgrade. I didn't have that
warning, I upgraded, and now i have a warning. I don't think it should
be fixed at runtime, but maybe in the apt postinst?

a.

-- 
Je viens d'un pays où engagé veut dire que tu t'es trouvé une job.
- Patrice Desbiens

Bug#911333: curl adds terminal codes (ANSI?) in server header response

[Frank Gevaerts]

Package: curl
Version: 7.61.0-1
Followup-For: Bug #911333

curl supports colourised header output starting with 7.61.0 (enabled by 
default).
Unfortunately the original code isn't properly compatible with all terminal
emulators. The fixed code in 7.61.1 is a lot more compatible, but that's not in
debian yet.

You can disable it with --no-styled-output (or "no-styled-output" in .curlrc)

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

Versions of packages curl depends on:
ii  libc6 2.27-6
ii  libcurl4  7.61.0-1
ii  zlib1g1:1.2.11.dfsg-1

curl recommends no packages.

curl suggests no packages.

-- no debconf information

Bug#898940: lastpass-cli: error: Peer certificate cannot be authenticated with given CA certificates

[Chris Lamb]

affects 911767 lastpass-cli
block 898940 by 911767
thanks

Hi,

> error: Peer certificate cannot be authenticated with given CA
> certificates

An request to update the "stable" distribution has been filed
as #911767.


Regards,

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

Bug#911763: Patch

[Frédéric Bonnard]

Severity: normal
Tags: patch pending
User: debian-powe...@lists.debian.org
Usertags: ppc64el

--

Hi again,
here is a merge request for the patch I did :

https://salsa.debian.org/debichem-team/espresso/merge_requests/1

Regards,

Fred


pgpNhgUdC1S8N.pgp
Description: PGP signature

Bug#911680: xserver-xorg-core: X server crashes when loading libglamorgl.so module

[Bernhard Übelacker]

Hello Massimo,

Am 24.10.2018 um 15:54 schrieb Massimo MANGHI:
> ... and the new patch will be 
> included in the next upload, is it correct? Am I supposed to take any 
> further action? Something like changing the bug status or applying some 
> extra tag to the bug in order to specify the environment (VirtualBox) 
> where the problem occurs?

I really was just trying to debug the issue,
further actions are up to the maintainers.

Also another user reported a workaround in [1] that
you might have not received by mail.

Kind regards,
Bernhard

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911680#18

Bug#544651: Bug 794971 + 544651 - lvm2 - Volume group not found, unable to find LVM during boot

[bakhelit]

I can confirm the mentioned warnings about LVM volume groups on all my 
Debian Stretch systems. Messages seems to be caused by the running order 
of initramfs scripts in "/usr/share/initramfs-tools/scripts/local-*" - 
"lvm2" script seems to be run before "cryptroot" script. This is caused 
by lines 10 to 16 in 
"/usr/share/initramfs-tools/scripts/local-*/cryptroot" - when scripts 
run in a default alphabetic order ("cryptroot" then "lvm2") no warnings 
seems appear.


Note that I made more modifications to my "lvm2" and especially 
"cryptroot" initramfs scripts, so if somebody can confirm that just 
changing the run order of default scripts is enough to avoid the 
warnings about LVM volume groups it would be nice. Also note the 
modified initramfs scripts should be in 
"/etc/initramfs-tools/scripts/local-*" and you need to rebuild your 
initramfs to test the changes.


When this is confirmed maybe the package for bugs 794971 and 544651 
should be changed to "cryptsetup" instead of "lvm2"?


Regards
Bakhelit

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

[Dirk Eddelbuettel]

Hi Sebastian,

There maybe something wrong -- "It works for me".

But I did get one error report already (on the r-sig-debian list, part of the
R lists, good resource)

On 24 October 2018 at 16:32, Sebastian Meyer wrote:
| Yesterday I updated
| 
| elpa-ess:amd64 (17.11-4~ubuntu16.04.1~ppa1, 18.10-1xenial0)
| 
| from the package repository at
| 
| https://cran.wu.ac.at/bin/linux/ubuntu/xenial
| 
| I now have the same symptoms as described by Zack previosly.
| 
| Running emacs -q, evaluating (require 'ess-site), and checking the value

For me it works without (require 'ess-site), in fact it works without a
~/.emacs. 

| of the variable ess-etc-directory gives me
| 
|   /usr/share/ess/etc/
| 
| However, there is no /usr/share/ess directory on my system.

I know. It is an old value from before the elpa conversion.

And ...

| ess-etc-directory is defined in ess-site.el at
| 
|   /usr/share/emacs24/site-lisp/elpa/ess-18.10/ess-site.el
|   -> /usr/share/emacs/site-lisp/elpa-src/ess-18.10//ess-site.el
| 
| which contains
| 
| > (defvar ess-etc-directory "/usr/share/ess/etc/"
| >   "Location of the ESS etc/ directory.
| > The ESS etc directory stores various auxillary files that are useful
| > for ESS, such as icons.")
| 
| This differs from the upstream file, which defines the value as nil, see
| https://github.com/emacs-ess/ESS/blob/v18.10/lisp/ess-site.el#L70
| 
| My knowledge of the Debian packaging mechanisms is rudimentary, but
| searching for the /usr/share/ess path I found a corresponding overwrite
| in debian/rules, see
| https://salsa.debian.org/edd/ess/blob/master/debian/rules#L72
| 
| Is this intended?

... yes, or at least it once was as it was once needed.


If you have a few minutes, I could cook up a new -2 revision without it and
email it to you to see if it works.

Thanks for taking the time to report this!

Dirk
 
| Thanks a lot and best regards,
| 
|Sebastian
| 
| 
| -- 
| Dr. Sebastian Meyer
| Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)
| Institut für Medizininformatik, Biometrie und Epidemiologie (IMBE)

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#749991: A tiresome subject for YEARS.

[Oliver Riesener]

A tiresome subject for YEARS.

It has happened again today.


Debian Stretch 9.5 (stable) kernel 3.16.0-4
* no packages matching kernel failed.

Bug#911769: libdebian-source-perl: dependencies with :$arch qualifiers

[gregor herrmann]

Package: libdebian-source-perl
Version: 0.103
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Recently, when running `dh-make-perl refresh --only control' [0]
I was first greeted with warnings like

Unable to obtain version information for DBI. You may need to install and 
run "apt update" at 
/home/gregoa/src/git-pkg-perl/meta/packages/dh-make-perl/lib/Debian/Control/FromCPAN.pm
 line 351.
+ DBI found in libdbi-perl:amd64

for each arch:any package, and later found e.g. "libdbi-perl:amd64"
in the refreshed debian/control.

Stepping through the code this comes from scan_perl_mod → scan_pattern
→ _cat_lists in lib/Debian/DpkgLists.pm, called from find_debs_for_modules
in lib/Debian/Control/FromCPAN.pm.

As having the arch qualifiers (especially for one random arch)
hard-coded in d/control is not helpful, I'm pushing a patch shortly.

Unfortunately this issue is not caught by the test suite; maybe
someone can review the patch-to-be-pushed and/or come up with a test.


Cheers,
gregor



[0] in the sqitch source package

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlvQjuNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgY2iA//TGrCvXrDCeOnMUN7T0i5z2icS8PHhFoCbY9aqQ4xv8qnhscPK1/jOQ0d
udBX3YumX3zzLLYFB3BTvnG6K9LklXlwhXEuAn9UMA9AUvFW+G86vvALZe4daRux
wCv1WaJIUed8UKkpLgSuNuGnumj4npuFPzUE3X4KbCx+ALLhMhgk4bibEwv5iIZd
lrq5mJHIStdxyKnOJz+DecY83VIJpNDT5norItmcj6pNupqnGAY5NqqxiUmp19QM
QfdvQgmXeDgrpmovI/BC9sv1jXiDcWcZy+r07e5TIrlg27TCqgi7V/cVlcvPZAoU
4JlxarbPaCieEh321YbGfEDvzHZgxI/teN/dYiCIvgf6/wjEY20x9xJ6HmJEQVm4
35U2Ms6zZDfXtseuy+6YrDyzqjvrIGXXY2Fcg0s+nvS5ciJu1i8y+PbZx1tt8K9Z
T9VKWdIro0jW5bFNyu5XaZh2BWU1E5QygH5kd49U8eYg37Vx/LqUED5QkhfAMrhT
1ubKIWGTxO0GxSIzmwzvbMTJ1RlBlkQNvIB0pXkDreb1LBwYXPFhAlKECDFBVHjM
syxGA5gmZDQnd4NCNFUNrt63ktg0dw2+cOouE/oqekr4v7lWI/BJ4U+/0KIDm079
ElUIwbBTZa4xZKdfBEdO5pHjCEi/k5c+8YZGIePhlpwSOrwfDIQ=
=4g/F
-END PGP SIGNATURE-

Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'

[Tiziano Zito]

Package: pinentry-gnome3
Version: 1.1.0-1+b1
Severity: serious

Hi!

pinentry-gnome3 (but also pinentry-gtk-2) does not open a window anymore to ask 
for a passphrase. If run from terminal it shows:

No Gcr System Prompter available, falling back to curses
OK Pleased to meet you

It was working fine since years. Of the packages pinentry-gnome3 depends on, I 
have only upgraded recently libgpg-error0,  libncursesw6, libtinfo6.
Even downgrading libgpg-error0 to 1.32-1 does not fix the issue.

I am clueless, but willing to help to find the culprit...

Ciao!
Tiziano

PS: not sure it is relevant, but I am not running GNOME, I use fvwm instead. 
Dbus is running.

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

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

Versions of packages pinentry-gnome3 depends on:
ii  gcr  3.28.0-1
ii  libassuan0   2.5.1-2
ii  libc62.27-6
ii  libgcr-base-3-1  3.28.0-1
ii  libglib2.0-0 2.58.1-2
ii  libgpg-error01.32-3
ii  libncursesw6 6.1+20181013-1
ii  libsecret-1-00.18.6-3
ii  libtinfo66.1+20181013-1

Versions of packages pinentry-gnome3 recommends:
pn  dbus-user-session  

Versions of packages pinentry-gnome3 suggests:
ii  pinentry-doc  1.1.0-1

-- no debconf information

Bug#911770: ITP: python-pylibdmtx -- Read Data Matrix barcodes

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-pylibdmtx
  Version : 0.1.7
  Upstream Author : Lawrence Hudson 
* URL : https://github.com/NaturalHistoryMuseum/pylibdmtx/
* License : Expat
  Programming Lang: Python
  Description : Read Data Matrix barcodes

 Read and write Data Matrix barcodes from Python using the libdmtx library.
 .
 Features:
  * Pure Python
  * Works with PIL / Pillow images, OpenCV / numpy ndarrays, and raw bytes
  * Decodes locations of barcodes
  * No dependencies, other than the libdmtx library itself

I will provide a Python2 package for this library as some of our researchers
are still tied to Python 2.7, thanks to Google Cloud SDK.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlvQj1cRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoQ0wf/SgifFJ3klcwlu7szvLcKdoJWCVJNz9HP
1W6cGXaMijGxNptAfTa3tcNtY+UKWafrI/McY58UUoUTdPFdowsZ5znyVD6oy9yq
NKxDXdSVC6ANJmEAYCPiIhW/t6pKUf05xyeTuPYJMj2TOfcftOP1CkPBAIk2AI4f
EOB+VrV/jKmE26r5WQZz+GZ/wOn7DqV+4ojSu4np37uR6248nPVE8j5TPRraD3+h
WbZMMVx8wqgkxfPbD9pm9Iwlnl2P8G+U5kfE8Ui20WZsfqvatb7ea846p52l4sU9
OMAGovPwC4G3/QwKGfndVKv9lVT1FluVHFDb3v2EVzkoOKgaZoDY6g==
=F5s+
-END PGP SIGNATURE-

Bug#749991: A tiresome subject for YEARS.

[John Paul Adrian Glaubitz]

On 10/24/18 5:15 PM, Oliver Riesener wrote:
> Debian Stretch 9.5 (stable) kernel 3.16.0-4
> * no packages matching kernel failed.

This error usually comes up with installation media created using
unetbootin. Have you, by any chance, used unetbootin to create your
installation medium?

Adrian

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

Bug#911771: IPv4: AttributeError: 'module' object has no attribute 'in_'

[Ulrike Uhlig]

package: python-twisted
severity:  normal

Dear Maintainer,

when launching torbrowser-launcher, that relies on python-twisted, I get
the following error:

  File "/usr/bin/torbrowser-launcher", line 29, in 
import torbrowser_launcher
  File
"/usr/lib/python2.7/dist-packages/torbrowser_launcher/__init__.py", line
33, in 
from .common import Common, SHARE
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/common.py",
line 55, in 
from twisted.internet import gtk2reactor
  File
"/usr/lib/python2.7/dist-packages/twisted/internet/gtk2reactor.py", line
23, in 
from twisted.internet import _glibbase
  File "/usr/lib/python2.7/dist-packages/twisted/internet/_glibbase.py",
line 20, in 
from twisted.internet import base, posixbase, selectreactor
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line
27, in 
from twisted.internet._resolver import (
  File "/usr/lib/python2.7/dist-packages/twisted/internet/_resolver.py",
line 25, in 
from twisted.internet.address import IPv4Address, IPv6Address
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py",
line 23, in 
class IPv4Address(object):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py",
line 37, in IPv4Address
type = attr.ib(validator=attr.validators.in_(["TCP", "UDP"]))

I'm using 18.7.0-2~bpo9+1 and
python 2.7.13-2 (as the default on Stretch).

Cheers,
u.

Bug#911769: libdebian-source-perl: dependencies with :$arch qualifiers

[gregor herrmann]

On Wed, 24 Oct 2018 17:25:27 +0200, gregor herrmann wrote:

> Unfortunately this issue is not caught by the test suite; maybe
> someone can review the patch-to-be-pushed and/or come up with a test.

Or not. With my simple patch, the test suite fails:

# prove --blib --verbose t/DpkgLists.t
t/DpkgLists.t .. 
1..7
ok 1 - use Debian::DpkgLists;
# Perl API is 5.26
ok 2 - /usr/bin/perl is in perl-base
ok 3 - partial /bin/perl is in perl-base
ok 4 - qr{/bin/perl$} is in perl-base
not ok 5 - Errno is in perl-base

#   Failed test 'Errno is in perl-base'
#   at t/DpkgLists.t line 36.
# Structures begin differing at:
#  $got->[0] = 'libperl5.26'
# $expected->[0] = 'libperl5.26:amd64'
not ok 6 - IO::Socket::UNIX is in perl-base

#   Failed test 'IO::Socket::UNIX is in perl-base'
#   at t/DpkgLists.t line 42.
# Structures begin differing at:
#  $got->[0] = 'libperl5.26'
# $expected->[0] = 'libperl5.26:amd64'
ok 7 - utf8 is in perl-base
# Looks like you failed 2 tests of 7.
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/7 subtests 

Test Summary Report
---
t/DpkgLists.t (Wstat: 512 Tests: 7 Failed: 2)
  Failed tests:  5-6
  Non-zero exit status: 2
Files=1, Tests=7,  0 wallclock secs ( 0.04 usr  0.00 sys +  0.20 cusr  0.01 
csys =  0.25 CPU)
Result: FAIL


The patch I tried, which strips :$arch and does so also for
'libperl5.26:amd64':

--- a/lib/Debian/DpkgLists.pm
+++ b/lib/Debian/DpkgLists.pm
@@ -38,8 +38,9 @@ sub _cat_lists
 my ( $class, $callback ) = @_;
 while ( defined( my $f =  ) ) {
 my $pkg = $f;
+# e.g. /var/lib/dpkg/info/libdbi-perl:amd64.list
 $pkg =~ s{^/var/lib/dpkg/info/}{};
-$pkg =~ s/\.list$//;
+$pkg =~ s/(?::\w+)?\.list$//;
 open my $fh, '<', $f or die "open($f): $!\n";
 while ( defined( my $l = <$fh> ) ) {
 chomp $l;


Looks like this needs more thought and eyeballs.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#894359: Now we have antlr 4.6 - any chance to get 4.7 soon (Was: beast-mcmc2: Cannot find symbol CharStreams.fromString(newick))

[Andrius Merkys]

On 10/24/18 1:40 PM, Emmanuel Bourg wrote:
> I've uploaded mojo-executor and string-template-maven-plugin, they are
> awaiting in the NEW queue for the FTP masters approval. Thanks a lot
> Andrius.

Many thanks for reviewing and uploading the packages!

Best,
Andrius

Bug#909926: No more segfaulting with 0.7.8-1

[Hans van Kranenburg]

Hi,

Just a success report from a user:

I've been seeing this in dmesg on buster previously, every time during boot:

[   37.091372] multipath[530]: segfault at 100 ip 7fdc202b6136 sp
7ffdf8d740d8 error 4 in libc-2.27.so[7fdc20241000+146000]

I found this bug report yesterday, and saw that you just uploaded 0.7.8-1.

So, today I installed it and the segfault doesn't show up any more.

Thanks!

Hans

Bug#783781: apt-show-versions: shows "foo:all not installed" for packages that transitioned from arch any to arch all

[Antoine Beaupré]

On 2015-04-30 08:27:20, Paul Wise wrote:
> The packages apertium-en-es, proj-data and wml have transitioned from
> Architecture: any in unstable to Architecture: all in experimental. I
> have the unstable versions installed but not the experimental ones and
> apt-show-versions shows "foo:all not installed" for all of them. This is
> confusing since apt-show-versions is meant to only show installed stuff.
>
> apertium-en-es:all not installed
> apertium-en-es:amd64/testing 0.6.0-1.1+b2 uptodate
> proj-data:all not installed
> proj-data:amd64/testing 4.8.0-5 uptodate
> wml:all not installed
> wml:amd64/testing 2.0.12ds1-8 uptodate

It seems like this is deliberate in the code, yet it's totally unclear
to me why it's happening. The following patch, of course, fixes the
problem:

diff --git i/apt-show-versions w/apt-show-versions
index 3df13c7..ab1f91c 100755
--- i/apt-show-versions
+++ w/apt-show-versions
@@ -513,7 +513,7 @@ sub print_package_internal {
  "version in archive\n");
 }
 }
-} else {
+} elsif ($ipkg->{$VERS}) {
 push(@print_info, "$pkgarch not installed",
  ($mode == $MODE_SINGLE and not 
keys(%{$apackages->{$package}{$arch}}))
 ? " (even not available)\n" : "\n");

But it's not clear to me what the proper solution is or what the purpose
of this 'not installed' statement is... That code has been present
basically forever (since the 2007, 0.10 original git import) without any
clear explanation.

Another alternative would be to just remove that code completely, since
it's unclear what purpose it serves. This is basically what the above
does anyways.

Other opinions?

A.

-- 
Growth for the sake of growth is the ideology of the cancer cell.
- Edward Abbey

Bug#826994: ZFS Missing init-scripts, Status? #826994

[Chris Dos]

Hello Aron,

I would just like to get a final statement from you regarding if this patch is
going to be applied or not?

If this sysvinit bug is going to forever remain a wishlist and never have the
patch applied, then say so and I'll make other arrangements and no longer
maintain the patch.

Chris

Bug#909926: No more segfaulting with 0.7.8-1

[Ritesh Raj Sarraf]

Hello Hans,

On Wed, 2018-10-24 at 17:42 +0200, Hans van Kranenburg wrote:
> Hi,
> 
> Just a success report from a user:
> 
> I've been seeing this in dmesg on buster previously, every time
> during boot:
> 
> [   37.091372] multipath[530]: segfault at 100 ip 7fdc202b6136 sp
> 7ffdf8d740d8 error 4 in libc-2.27.so[7fdc20241000+146000]
> 
> I found this bug report yesterday, and saw that you just uploaded
> 0.7.8-1.
> 
> So, today I installed it and the segfault doesn't show up any more.

THank you for your test report. Much appreciated.

Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#911773: RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP]

[Jongmin Kim]

Package: sponsorship-requests
Severity: wishlist
Control: -1 block 905240
X-Debbugs-CC: debian...@lists.debian.org, av...@debian.org

Dear mentors,

I am looking for a sponsor for my package "golang-github-rivo-tview".

This package is a prerequisite for upcoming package "git-lab" (#898246).

This package will be maintained as part of the Go Packaging Team going forward.

* Package name: golang-github-rivo-tview
  Version : 0.0~git20181018.a7c1880-1
  Upstream Author : Oliver Kuederle 
* URL : https://github.com/rivo/tview
* License : Expat
  Section : devel

It builds those binary packages:

  golang-github-rivo-tview-dev - Rich interactive widgets for terminal-based 
UIs in Go

If you have access to Salsa, please check out:

  https://salsa.debian.org/go-team/packages/golang-github-rivo-tview

Otherwise, please visit the following URL (You can also find the orig.tar.gz 
here):

  https://mentors.debian.net/package/golang-github-rivo-tview

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-rivo-tview/golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc

Thanks for your time! Any review is appreciated.

Regards,
 Jongmin Kim

-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#804099: apt-xapian-index and Python 3

[Dino]

Hi,

I just realised that update-apt-xapian-index is not working if 
/usr/bin/python is pointing to a Python 3 interpreter. It gives the 
following error:


  File "/usr/sbin/update-apt-xapian-index", line 86
    except OSError, e:
  ^
SyntaxError: invalid syntax


Thus, I guess the changes mentioned above have not been incorporated 
into the code. (The links are not working anymore...)


What do you think about changing the shebang line to:
#!/usr/bin/python2
?

Best,
Dino

Bug#911617: nm.debian.org: AM's profile says "0 applicants processed"

[Mattia Rizzolo]

On Mon, Oct 22, 2018 at 12:34:06PM -0400, Alexandre Viau wrote:
> I have processed two applicants and their process status is now "Closed".
> 
> However, my AM profile still says "0 applicants processed".


In [1]: import backend.models as bmodels

In [2]: from django.db.models import Min, Max

In [3]: am = 
bmodels.AM.objects.get(person=bmodels.Person.objects.get(uid='aviau'))

In [4]: am
Out[4]: b'Alexandre Viau'  [uid:aviau, status:dd_u] a-- 
slots:1

In [5]: am.processed.annotate(started=Min("log__logdate"), 
ended=Max("log__logdate")).order_by('is_active', 'ended')
Out[5]: 

this is what the code does, and as you can see apparently it believes
you processed nobody there.

In [17]: import process.models as pmodels

In [18]: pmodels.Process.objects.filter(ams__am=am).distinct()
Out[18]:  to 
become dd_u>,  to 
become dd_u>,  to become 
dd_u>]>

here instead it finds the 3 applicants by you, which are properly listed
in the table in your profile.


tbh I can't really see where that "processed" property is coming from,
so I'm unable to follow it for now.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#827337: apt-show-versions: option to hide packages that are at the right version based on pinning upgradeable

[Antoine Beaupré]

On 2016-06-15 13:44:50, Paul Wise wrote:
> Package: apt-show-versions
> Version: 0.22.7
> Severity: wishlist
>
> I pin most packages to testing and then have progressively lower pin
> values for less desirable suites. I also pin some particular packages
> to other suites. I also pin security updates using the script in bug
> #725934 to the suite that they come from (mostly unstable). I would
> like to have an option to hide packages that are at the right version
> based on pinning. So for most packages, hide if they are the version in
> testing. For specific packages pinned to a different release, hide if
> they are the version from the pinned release. For security updates
> pinned to unstable release, hide if they are the version from unstable.

I have a similar requirement, at least I think it is. I'm running
testing and pin some packages to "unstable until it hits testing". For
example, I have this for Firefox right now:

Package: firefox-esr
Pin: release n=sid
Pin-Priority: 501

Package: firefox-esr
Pin: release n=buster
Pin: release v=60
Pin-Priority: 502

It gives me a quantum-enabled firefox in buster, from sid, but will
transition to the buster version when it makes it. I also manually
install some packages from sid that are missing from buster in the hope
they transition.

I use apt-show-versions to keep track of those transitions. This
requires me to add a filter to hide "uptodate" entries from
"buster". For example, here's the output I am looking at right now:

$ apt-show-versions  | grep -v '/buster [^ ]* uptodate'
firefox-esr:amd64/sid 60.3.0esr-1 uptodate
network-manager-iodine:amd64/sid 1.2.0-3 uptodate
network-manager-iodine-gnome:amd64/sid 1.2.0-3 uptodate
printer-driver-postscript-hp:amd64 not installed
python-hvac:amd64 0.6.4-1 installed: No available version in archive
wireguard:all/sid 0.0.20181018-1 uptodate
wireguard-dkms:all/sid 0.0.20181018-1 uptodate
wireguard-tools:amd64/sid 0.0.20181018-1 uptodate

The first three and last three are normal there: both firefox-esr,
wireguard, and nm-iodine have excuses for not migrating to testing. The
`not installed` bit doesn't belong there but that's #783781. The
python-hvac one is interesting: it's a package that is currently in WNPP
(#875603) that I've worked on. Hopefully it will get there as well.

So that's really nice, but I always forget that cute regex. I wished
there was a way to simply add an option to get that clean output. I
tried this patch:

diff --git i/apt-show-versions w/apt-show-versions
index 3df13c7..6266b10 100755
--- i/apt-show-versions
+++ w/apt-show-versions
@@ -79,6 +79,7 @@ unless (GetOptions (\%opts,
 'upgradeable|u',
 'brief|b',
 'nohold|nh',
+'nouptodate|nu',
 'initialize|i',
 'verbose|v',
'version|V',
@@ -143,6 +144,7 @@ Options:
  -a|--allversions   Print all available versions.
  -b|--brief Short output.
  -nh|--nohold   Don't treat holded packages.
+ -nu|--nouptodate   Don't display up to date packages.
  -i|--initializeInitialize or update package cache only (as root).
  -v|--verbose   Verbose messages.
  -V|--version  Prints apt-show-versions version
@@ -458,7 +460,9 @@ sub print_package_internal {
 ($found, @version_info) =
&print_version(($irelease ? $irelease : 
&get_rel_name($_->{$RELEASE})),
$pkgarch, $iversion, $version, $cand);
-push @print_info, @version_info if ($found);
+if ($found and ($found != 1 or !$opts{'nouptodate'})) {
+push @print_info, @version_info;
+}
 $aversion = $version;
 }
 $is_upgradeable = 1 if ($found == 2);

But that doesn't give the right output:

$ ./apt-show-versions --nouptodate
python-hvac:amd64 0.6.4-1 installed: No available version in archive

Obviously, it removes just all uptodate packages, regardless of
suite. There should be a way to figure out if the found release (the
$irelease thing above) is the default release, but unfortunately
apt-show-versions does not have a good notion of what that is. It only
relies on APT::Default-Release (#875603) and that's usually not defined.

What *is* the proper way of figuring out what the default release is? Or
should we have a --ignore flag that would ignore a certain suite?

So I'm not sure if there's a clean way of fixing this.

A.

-- 
No animal has more liberty than the cat; but it buries the mess it
makes. The cat is the best anarchist. Until they learn that from the cat
I cannot respect them.
- For whom the bell tolls, Ernest Hemingway

Bug#908064: diaspora-installer: please update to 0.7.6.0

[Gianfranco Costamagna]

control: tags -1 patch pending
On Wed, 5 Sep 2018 20:25:05 +0200 Gianfranco Costamagna 
 wrote:
> Source: diaspora-installer
> Version: 0.7.4.0+nmu1
> Severity: important
> Tags: patch
> 
> This new release drops sigar, that is unmaintained and FTBFS with glibc
> 2.28
> 
> I might NMU later this month or next one, because this will become RC once 
> glibc 2.28 goes in unstable.
> 

in deferred/15
(I don't use the NMU syntax because I don't want to mess up the rules file 
parsing of the versioning)

G.
> Thanks for caring, I'm attaching a diff right now (note: I can't test on 
> pbuilder, so I presume
> the fix works by the fact that the testsuite is now completely green)
> 
> thanks
> 
> Gianfranco

Bug#911773: RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP]

[Jongmin Kim]

Control: block 905240 by -1

-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#911773: RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP]

[Alexandre Viau]

On 2018-10-24 11:55 a.m., Jongmin Kim wrote:
> I am looking for a sponsor for my package "golang-github-rivo-tview".

Why would you set builder and cleaner in debian/gbp.conf?

It has nothing to do with the layout of the repository. It should be up
to whoever maintains the package to decide how he wants to build it.

If you want to build all your packages with pbuilder, please set it in
~/.gbp.conf instead.

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



signature.asc
Description: OpenPGP digital signature

Bug#911773: RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP]

[Alexandre Viau]

On 2018-10-24 12:17 p.m., Alexandre Viau wrote:
> Forgot to CC debian-go.
> 
> On 2018-10-24 12:16 p.m., Alexandre Viau wrote:
>> On 2018-10-24 11:55 a.m., Jongmin Kim wrote:
>>> I am looking for a sponsor for my package "golang-github-rivo-tview".
>>
>> Why would you set builder and cleaner in debian/gbp.conf?
>>
>> It has nothing to do with the layout of the repository. It should be up
>> to whoever maintains the package to decide how he wants to build it.

And here I meant "whoever builds the package"

>> If you want to build all your packages with pbuilder, please set it in
>> ~/.gbp.conf instead.
>>
> 

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



signature.asc
Description: OpenPGP digital signature

Bug#911773: RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP]

[Alexandre Viau]

Forgot to CC debian-go.

On 2018-10-24 12:16 p.m., Alexandre Viau wrote:
> On 2018-10-24 11:55 a.m., Jongmin Kim wrote:
>> I am looking for a sponsor for my package "golang-github-rivo-tview".
> 
> Why would you set builder and cleaner in debian/gbp.conf?
> 
> It has nothing to do with the layout of the repository. It should be up
> to whoever maintains the package to decide how he wants to build it.
> 
> If you want to build all your packages with pbuilder, please set it in
> ~/.gbp.conf instead.
> 

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



signature.asc
Description: OpenPGP digital signature

Bug#911774: O: xview -- XView shared libraries

[Mattia Rizzolo]

Package: wnpp

The current maintainer of xview, Blars Blarson ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a 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
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: xview
Binary: xviewg, xviewg-dev, xview-clients, xview-examples, olwm, olvwm
Version: 3.2p1.4-28.2
Maintainer: Blars Blarson 
Build-Depends: debhelper (>= 5), bison, libfl-dev, ed, libncurses5-dev | 
libncurses-dev, libx11-dev (>= 2:1.0.0), libxt-dev, libxext-dev, libxpm-dev, 
xutils-dev
Architecture: any
Standards-Version: 3.8.0.0
Format: 3.0 (quilt)
Files:
 4f1b6dd7eb789984019d14c35a99084f 2029 xview_3.2p1.4-28.2.dsc
 b9ff26d6ad378af320bac45154ceaeba 3227552 xview_3.2p1.4.orig.tar.gz
 965e46a364ab73fd0ccf52d604edd174 82124 xview_3.2p1.4-28.2.debian.tar.xz
Checksums-Sha256:
 1c904036e7afa1487ec8f90ebf078150076fe9d3621fb958250141a87dd88ec1 2029 
xview_3.2p1.4-28.2.dsc
 fcc88f884a6cb05789ed800edea24d9c4cf1f60cb7d61f3ce7f10de677ef9e8d 3227552 
xview_3.2p1.4.orig.tar.gz
 c84f18a588b848a95f2fed08c3d0514e96792408ebf8120e53e585efd3045f96 82124 
xview_3.2p1.4-28.2.debian.tar.xz
Package-List: 
 olvwm deb x11 optional arch=any
 olwm deb x11 optional arch=any
 xview-clients deb x11 optional arch=any
 xview-examples deb x11 optional arch=any
 xviewg deb x11 optional arch=any
 xviewg-dev deb devel optional arch=any
Directory: pool/main/x/xview
Priority: source
Section: x11

Package: xviewg
Source: xview
Version: 3.2p1.4-28.2
Installed-Size: 1995
Maintainer: Blars Blarson 
Architecture: amd64
Depends: libc6 (>= 2.14), libx11-6, libxext6, xbitmaps
Pre-Depends: x11-common (>= 1:7.0.0)
Suggests: indent
Conflicts: xview (<< 3.2p1.4-1)
Description: XView shared libraries
Description-md5: 0e5206021e9a2582a115e4c7894a9afc
Tag: devel::library, interface::graphical, interface::x11, role::program,
 scope::utility, use::viewing, works-with::image,
 works-with::image:raster, x11::application
Section: x11
Priority: optional
Filename: pool/main/x/xview/xviewg_3.2p1.4-28.2_amd64.deb
Size: 654124
MD5sum: bed6f0025244390c20492f8d36103358
SHA256: 5181e3369fd6f48d7886a3158c413c1422da946478009cce525c9f3c697aa104

Package: xviewg-dev
Source: xview
Version: 3.2p1.4-28.2
Installed-Size: 3916
Maintainer: Blars Blarson 
Architecture: amd64
Depends: xviewg (= 3.2p1.4-28.2), libc6 (>= 2.2.5), libx11-dev
Pre-Depends: x11-common (>= 1:7.0.0)
Conflicts: xview-dev (<< 3.2p1.4-1)
Description: XView development tools
Description-md5: da1e4e1ebe66398a922308862e377aaf
Tag: devel::library, interface::graphical, interface::x11, role::devel-lib,
 role::program, use::viewing, works-with::image,
 works-with::image:raster, x11::application
Section: devel
Priority: optional
Filename: pool/main/x/xview/xviewg-dev_3.2p1.4-28.2_amd64.deb
Size: 883622
MD5sum: 3bfcfb1fa95953d48b9a0d504593598a
SHA256: 6235308e3b9330f2a027e6e167fc6e4d4eae392e28e234e4e8481ba99825c304

Package: xview-clients
Source: xview
Version: 3.2p1.4-28.2
Installed-Size: 196
Maintainer: Blars Blarson 
Architecture: amd64
Depends: libc6 (>= 2.14), libx11-6, libxext6, xviewg (>= 3.2p1.4-6)
Description: XView client programs
Description-md5: 80414ece9f4573d68466143adb9353c9
Tag: interface::graphical, interface::x11, role::program, scope::utility,
 use::configuring, use::editing, use::timekeeping, works-with::text,
 x11::application, x11::terminal
Section: x11
Priority: optional
Filename: pool/main/x/xview/xview-clients_3.2p1.4-28.2_amd64.deb
Size: 67512
MD5sum: 0a3f9a2c5a22b84f3719c892e443b1f8
SHA256: 73a11ac5532cadfcd3630294d7d35858797aaede07250ddaee305df39fd547f7

Package: xview-examples
Source: xview
Version: 3.2p1.4-28.2
Installed-Size: 1473
Maintainer: Blars Blarson 
Architecture: amd64
Depends: libc6 (>= 2.14), libncurses5 (>= 6), libtinfo5 (>= 6), libx11-6, 
libxext6, xviewg (>= 3.2p1.4-6)
Recommends: xviewg-dev, xutils-dev
Description: XView contrib programs
Description-md5: 67cef80319a653e89c65b3940e9f63ca
Tag: devel::examples, interface::graphical, interface::x11, role::app-data,
 role::program, role::source, uitoolkit::ncurses, x11::application
Section: x11
Priority: optional
Filename: pool/main/x/xview/xview-examples_3.2p1.4-28.2_amd64.deb
Size: 178020
MD5sum: 474ba74f1560cd320453984788e95056
SHA256: bd4fd087d5e60f2c6c52aadc0d981520ed4e0f541b3c874bfe94baa5f976cb9c

Package: olwm
Source: xview
Version: 3.2p1.4-28.2
Installed-Size: 371
Maintainer: Blars Blarson 
Architecture: amd64
Provides: x-window-manager
Depends: libc6 (>= 2.14), libx11-6, libxext6, xviewg (>= 3.2p1.4-6)
Suggests: menu (>= 2.1.9), xview-clients
Conflicts: menu (<< 2.1.9), olvwm (<< 4.1.3.2p1.4-1), xview (<< 3.2p1.4-1)
Description: Open Look Window Manager
Description-md5: d0d4334f3b466b34d03687a9faea5982
Tag: interface::graphical, interface::x11, role::p

Bug#911775: Please package Elixir >= 1.6.6

[Thomas Goirand]

Source: elixir
Severity: normal

Dear Maintainer,

I'm packaging RabbitMQ-server, and the latest upstream release needs
Elixir 1.6.6 at least. It'd be nice if you could update the package.

Cheers,

Thomas Goirand (zigo)

Bug#911776: fontconfig: makes Firefox, Gimp, Inkscape occasionally freeze

[Francesco Potortì]

Package: fontconfig
Version: 2.13.0-5
Severity: grave

Details are reported in bug #909818

-- 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.18.0-1-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 fontconfig depends on:
ii  fontconfig-config  2.13.1-1
ii  libc6  2.27-6
pn  libfontconfig1 
ii  libfreetype6   2.8.1-2

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information

Bug#911773: RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP]

[Jongmin Kim]

Thanks, Alexandre!

On Wed, Oct 24, 2018 at 12:17:49PM -0400, Alexandre Viau wrote:
> Why would you set builder and cleaner in debian/gbp.conf?
>
> It has nothing to do with the layout of the repository. It should be up
> to whoever maintains the package to decide how he wants to build it.

Yes, it can be personalisable. I removed it.

Many thanks for your careful review.

-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#839008: scribus no longer finds DejaVu fonts

[Mattia Rizzolo]

Control: reassign -1 libfreetype6 2.6.3-3.2
Control: fixed -1 2.7.1-0.1
Control: affects -1 scribus

On Fri, Nov 24, 2017 at 12:45:46AM +0100, Hartmut Buhrmester wrote:
> Apparently, this is caused by a bug in the FreeType library libfreetype6. An
> upstream bug report says:
> 
> > This is a bug caused by some FreeType versions which fail when loading
> > some glyphs outlines and make us consider some fonts as broken. At
> > least FreeType 2.6.0 to 2.6.3 are affected. FreeType 2.6.5 was
> > fixed. Unfortunately Debian 9 has FreeType 2.6.3. If you upgrade
> > FreeType to >= 2.6.5, you will have to clear scribus font cache.
> 
> - https://bugs.scribus.net/view.php?id=15042

As such, I'm reassign this bug report to freetype.

I don't know whether its maintainer have enough time to go through the
process to find the minimal fix and do a stable update though.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#749991: A tiresome subject for YEARS.

[Oliver Riesener]

No unetbootin, it’s the stock  stretch netboot   installation.
initrd kernel from actual Debian9.5/…./amd64/netboot/netboot.tar.gz
didn’t find kernel modules anymore. The old one before too. 
It’s a point release problem. Older versions of modules (.udeb ?) seems
to be from debian repo. 


> Am 24.10.2018 um 17:26 schrieb John Paul Adrian Glaubitz 
> :
> 
> On 10/24/18 5:15 PM, Oliver Riesener wrote:
>> Debian Stretch 9.5 (stable) kernel 3.16.0-4
>> * no packages matching kernel failed.
> 
> This error usually comes up with installation media created using
> unetbootin. Have you, by any chance, used unetbootin to create your
> installation medium?
> 
> Adrian
> 
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 

Bug#749991: A tiresome subject for YEARS.

[John Paul Adrian Glaubitz]

On 10/24/18 6:42 PM, Oliver Riesener wrote:
> No unetbootin, it’s the stock  stretch netboot   installation.
> initrd kernel from actual Debian9.5/…./amd64/netboot/netboot.tar.gz
> didn’t find kernel modules anymore. The old one before too. 
> It’s a point release problem. Older versions of modules (.udeb ?) seems
> to be from debian repo. 
Are you sure you used a matching kernel image and initrd? Both have to match
their version otherwise it won't work.

I'm creating debian-installer images myself on a regular basis and from my
current knowledge and testing, it's very unlikely that there is a bug in
the kernel and initrd matching.

Adrian

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