Bug#904819: Bug#902936: fixed in zutils 1.7-2

[Daniel Baumann]

Hi Antonio,

On 08/01/2018 02:01 PM, Antonio Diaz Diaz wrote:
> It seems I answered to the wrong bug, sorry.

no problem :)

> The bug fixed in zutils-1.8-pre2 also fixes this one (#904819).

yes, I was going to clean that up, but had to leave (it's closed now).

> Thank you very much Daniel for extracting a patch for 1.7 from 1.8-pre2
> and applying it so fast.

well, pulling patches is easy.. thank you for doing the fix in the first
place ;)

Regards,
Daniel

Bug#904776: /usr/bin/dpkg-source: please parse d/t/control.autodep8 like d/t/control

[Paul Gevers]

Hi Guillem,

On 01-08-18 04:44, Guillem Jover wrote:
> [ Please excuse some of the probably obvious questions, I probably
>   just do not have a clear picture of how the pieces fit together. ]

Thanks for being critical. Some of these pieces are also looked upon by
me for the first time.

> On Mon, 2018-07-30 at 20:03:07 +0200, Paul Gevers wrote:
>> On 30-07-18 05:42, Guillem Jover wrote:
 It would be great if dpkg-source would also parse 
 debian/tests/control.autodep8
 in the same way as it does debian/tests/control, except I guess it should 
 not
 set the Testsuite field (as dpkg-source doesn't know which type of 
 autopkgtest
 this is).
>>>
>>> Hmm, why did we get this new file at all?
>>
>> It's more than two years old. It was added in response to bug 823931.
> 
> Would you be open to revisit that decision?

Sure, if we find a good alternative.

> The current interface
> feels a bit like a wart to me. It didn't look like there were many
> packages involved, when I checked the other day.

I didn't check.
https://codesearch.debian.net/search?q=Test+path%3Adebian%2Ftests%2Fcontrol.autodep8
gives 49 packages.

>>> Why can't we use
>>> debian/tests/control instead? The Testsuite field would be used to
>>> specify that we still want autodep8 to be run, no?
>>
>> Looking at the bug, I can only assume it just wasn't considered to
>> change autopkgtest, e.g. IIAC the maintainer of autodep8 wasn't a
>> developer of autopkgtest at the time.
> 
> Well, autodep8 seems to be called from autopkgtest, so I'm not sure I
> understand that reason? :)

Well, it would need changes in autopkgtest (on top of changes to
autodep8). So there was the "out of my control" argument I guess. But as
said, I am guessing. Anyways, I don't think it is relevant for the
discussion.

>> Also, the current implementation works without the spec needing to
>> mention the debian/control file.
> 
> Isn't it implicitly mentioned in the “Source package header” section?

Right, missed that (I was doing it from memory, not looking up the
file). But the ironic thing is that this paragraph is actually
irrelevant for autopkgtest itself. autopkgtest doesn't care at all. So
only autodep8 is using the Testsuite field, and then only from the
debian/control file (not from the .dsc file). The d/contol file only
needs to mention it when maintainers opt-in for autodep8

>> autopkgtest (the binary that is _an_
>> implementation of the spec) only calls autodep8 when it doesn't find the
>> control file as a fall back. autopkgtest doesn't know why it is called,
>> it doesn't know about the Testsuite field, nor does anything in the CI
>> framework except for the one that requests the test.
> 
> Right, but it seems autodep8 does check, and uses the Testsuite field
> to decide whether some of the precooked checks should be used.

Yes, but it may be absent: autodep8 also works on packages that haven't
set any Testsuite field in debian/control. It tries to figure out if the
binary packages are of some type and cooks up the control stanza for
those. E.g. if a source or binary package starts with python-, it gives
us the python2.7 version, if you run autopkgtest (with auto_control
enabled) on them. This has been very useful on the ci.d.n infrastructure
to have large classes of packages tested. This isn't used for
influencing migration though.

> Wouldn't simply changing the logic to something like the following
> simplified stuff, do the trick?
> 
>   * change autopkgtest to always call autodep8 if auto_control is
> enabled.
>   * change autodep8 to always cat debian/tests/control if present.
>   * then autodep8 would cat the autogenerated tests like now based on
> the Testsuite field, and for backwards compat also the
> control.autodep8 file if present.

What is currently missing is a way for the package maintainer to say:
DON'T add autodep8 stanza to my package (as it fails). Currently that is
implemented by having a file called debian/tests/control. So if we want
to go this route, we either need time to have all packages that need
autodep8 off to be able to migrate to a still to be defined way of
saying so (e.g. by explicitly adding "Testsuite: autopkgtest" to
d/control, which may break a lot of packages when autodep8 adds support
for another class) or we can have autopgktest behave differently for
different ways of calling the test, e.g. when run on .dsc files compared
to when run from an unbuilt source-tree. I don't like to go the route of
different results.

>> If we would want to add support for this adding autodep8 on top of an
>> existing debian/tests/control file, apart from adapting autopkgtest with
>> a new option, also multiple interface would need to be adapted to pass
>> on this info:
>> britney <-> debci <-> autopkgtest
> 
> Why is that, what information do these require?

But rethinking this now it doesn't make sense anymore. The same argument
applies: autopkgtest would behave different for different ways of

Bug#519361: Patch

[Felix Lechner]

Control: tags 519361 patch

Hi,

This has been bothering me for years, as well. The attached patch
excludes backup files (*~). I don't have problems with emacs crashing,
but the second patch addresses those files (#*#) also, in 1.1.8-3.7.
As an alternative, Daniel's suggestion about a standard suffix is a
good one. Thank you!

Best regards,
Felix


exclude-emacs-backups.patch.gz
Description: application/gzip


exclude-emacs-backups-and-crashes.patch.gz
Description: application/gzip

Bug#905219: slapd: apt-get upgrade with Duplicate attributeType: "2.5.4.2"

[Jack McKinney]

Package: slapd
Version: 2.4.44+dfsg-5+deb9u1
Severity: important

Dear Maintainer,

   * What led up to the situation? I wanted to update my system
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I ran "apt-get upgrade"
   * What was the outcome of this action? It bailed when it hit slapd
   * What outcome did you expect instead? apt-get upgrade usually just works

It upgraded most of the packages just fine, but failed when it hit slapd.
If I try it again, I get the same result. It complains about the schema, but
the schema here are the dist schema; I have not modified them. I found this
exact schema error in google going back over a decade, but the fix does not
apply to my system (and it has been working fine for quite some time, not
throwing this error until I tried to apt-get upgrade).

hamilton /home/jackmc [1] # apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 slapd : Depends: libldap-2.4-2 (= 2.4.44+dfsg-5+deb9u1) but 
2.4.44+dfsg-5+deb9u2 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).
hamilton /home/jackmc [2] # apt --fix-broken install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  slapd
Suggested packages:
  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal
The following packages will be upgraded:
  slapd
1 upgraded, 0 newly installed, 0 to remove and 67 not upgraded.
44 not fully installed or removed.
Need to get 0 B/1,430 kB of archives.
After this operation, 1,024 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 199351 files and directories currently installed.)
Preparing to unpack .../slapd_2.4.44+dfsg-5+deb9u2_amd64.deb ...
Saving current slapd configuration to /var/backups/slapd-2.4.44+dfsg-5+deb9u1...
5b61c485 olcAttributeTypes: value #0 olcAttributeTypes: Duplicate 
attributeType: "2.5.4.2"
5b61c485 config error processing cn={0}core,cn=schema,cn=config: 
olcAttributeTypes: Duplicate attributeType: "2.5.4.2"
slapcat: bad configuration directory!
dpkg: error processing archive 
/var/cache/apt/archives/slapd_2.4.44+dfsg-5+deb9u2_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.44+dfsg-5+deb9u2... 
done.
Errors were encountered while processing:
 /var/cache/apt/archives/slapd_2.4.44+dfsg-5+deb9u2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
hamilton /home/jackmc [3] # 



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

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

Versions of packages slapd depends on:
ii  adduser3.115
ii  coreutils  8.26-3
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3
ii  libdb5.3   5.3.28-12+deb9u1
ii  libgnutls303.5.8-5+deb9u3
iu  libldap-2.4-2  2.4.44+dfsg-5+deb9u2
ii  libltdl7   2.4.6-2
ii  libodbc1   2.3.4-1
iu  libperl5.24 [libmime-base64-perl]  5.24.1-3+deb9u4
ii  libsasl2-2 2.1.27~101-g0780600+dfsg-3
ii  libwrap0   7.6.q-26
ii  lsb-base   9.20161125
iu  perl   5.24.1-3+deb9u4
ii  psmisc 22.21-2.1+b2

Versions of packages slapd recommends:
ii  libsasl2-modules  2.1.27~101-g0780600+dfsg-3

Versions of packages slapd suggests:
iu  ldap-utils 2.4.44+dfsg-5+deb9u2
pn  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi  

-- Configuration Files:
/etc/default/slapd changed:
SLAPD_CONF=
SLAPD_USER="openldap"
SLAPD_GROUP="openldap"
SLAPD_PIDFILE=
SLAPD_SERVICES=""
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd
SLAPD_OPTIONS="-f /etc/ldap/slapd.conf"


-- debconf information excluded

Bug#905220: sssd-tools: /usr/sbin/sss_obfuscate fails to run: ImportError: No module named pysss

[Andreas Beckmann]

Package: sssd-tools
Version: 1.16.2-1
Severity: serious

# sss_obfuscate
Traceback (most recent call last):
  File "/usr/sbin/sss_obfuscate", line 8, in 
import pysss
ImportError: No module named pysss


Andreas

Bug#905058: policykit-1: brlapi connections do not work any more

[Simon McVittie]

On Wed, 01 Aug 2018 at 18:13:47 +0200, Samuel Thibault wrote:
> Control: reassign -1 905058 brltty
> Control: tags -1 + patch pending
> 
> Samuel Thibault, le mar. 31 juil. 2018 02:42:06 +0200, a ecrit:
> > As reported also on
> > https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1782320
> > , on upgrading from policykit 0.105-20 to 0.105-21, brlapi connections
> > have stopped working.
> 
> So it seems it is a misuse of the policykit API from brltty, I will
> upload a fixed package.

Thanks. Would you like us to add a versioned Breaks in polkit?

Please could you also prepare the same fix for stretch? We'll need that
to avoid regressing when we upload a polkit with this CVE fix there.

codesearch.debian.net didn't show me any examples of this bug in
packages other than brltty.

smcv

Bug#905213: python3-pyghmi: fails to install with Python 3.7

[Andreas Beckmann]

Package: python3-pyghmi
Version: 1.0.32-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: block 902788 with -1 

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up python3-pyghmi (1.0.32-4) ...
File "/usr/lib/python3/dist-packages/pyghmi/ipmi/private/session.py", line 
502
  self.async = False
   ^
  SyntaxError: invalid syntax
  
  dpkg: error processing package python3-pyghmi (--configure):
   installed python3-pyghmi package post-installation script subprocess 
returned error exit status 1
  Errors were encountered while processing:
   python3-pyghmi


"async" has become a reserved keyword in Python 3.7


cheers,

Andreas


python3-pyghmi=1.0.32-4.log.gz
Description: application/gzip

Bug#905214: isc-kea: Incomplete debian/copyright?

[Chris Lamb]

Source: isc-kea
Version: 1.4.0.P1-3
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: Ondřej Surý , ftpmas...@debian.org

Hi,

I just ACCEPTed isc-kea from NEW but noticed it was missing 
attribution in debian/copyright for at least the files under
src/lib/dhcpsrv/benchmarks.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload. :)


Regards,

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

Bug#905199: mozjs52: Please update debian/test.sh to add sparc64, remove ppc64el from ignore list

[John Paul Adrian Glaubitz]

On 08/01/2018 02:25 PM, John Paul Adrian Glaubitz wrote:
> The testsuite for mozjs52 fails on sparc64 while it passes on ppc64el,
> so please add sparc64 to the list and remove ppc64el.

Please add alpha to the ignore list as well [1].

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=mozjs52=alpha=52.9.1-1=1533127652=0

-- 
 .''`.  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#905217: python-django: Django security releases issued: 2.0.8 and 1.11.15

[Herbert Parentes Fortes Neto]

Source: python-django
Severity: normal
Tags: upstream

Dear Maintainer,

I am looking for watch Django project more closed. Seen tickets, etc.
I hope not bothering with that. 

There is a new release with security fix.

https://www.djangoproject.com/weblog/2018/aug/01/security-releases/



Regards,
Herbert




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

Bug#903163: ITP: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Peter Lebbing]

Hi Guilhem and others,

On Mon, 30 Jul 2018 04:16:23 +0800 Guilhem Moulin 
wrote:
>  * Copying not only the (encrypted) key file and the public keyring,
>but also the private-keys-v1.d directory, sounds very odd to me.
>What is the rationale for doing so?

First, a new GnuPG --homedir /etc/keys is created, and in that homedir,
the smartcard stubs for the OpenPGP card are created (per README.md[1]).
This separate GnuPG homedir, specifically meant just for the unlocking
of the LUKS container, is then copied to the initramfs. If this were not
done, you'd have to do "gpg --card-status" in your initramfs to create
these stubs everytime you boot, before decryption. It'd get awkward if
you forgot to insert your smartcard, because adding --card-status makes
it a two-step process: first --card-status, second --decrypt. Right now,
if you forgot to insert your smartcard, the --decrypt would fail and be
retried. The failure would prompt you to insert your smartcard.

It's not copying your normal GnuPG private-keys-v1.d to initramfs,
that'd be not so clever. Still, in the interest of clarity, it warns the
user that if they dumped sensitive information in /etc/keys, they might
want to reconsider.

> decrypt_gnupg_sc:
>  * How common are the cards requiring pcscd(8) that don't work with the
>existing ‘decrypt_opensc’ keyscript but do work with the
>‘decrypt_gnupg_sc’ keyscript?

It's more tied to the reader rather than the card. My own smartcard
reader works great with the internal CCID driver of GnuPG, and my
version of this script does not have pcscd. Erik Nellessen apparently
has a smartcard reader that is not supported by GnuPG, but the card in
it is still an OpenPGP smartcard, AFAIK. I'm glad I have a
GnuPG-supported reader myself, it makes it all a lot smoother.

HTH,

Peter.

[1]


-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature

Bug#905207: fabio-viewer,python-fabio: both ship usr/share/doc/python-fabio-doc/html/_static/mathjax

[Andreas Beckmann]

Package: fabio-viewer,python-fabio
Version: 0.7.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package python-fabio.
  Preparing to unpack .../18-python-fabio_0.7.0+dfsg-1_amd64.deb ...
  Unpacking python-fabio (0.7.0+dfsg-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-YgDMUP/18-python-fabio_0.7.0+dfsg-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/doc/python-fabio-doc/html/_static/mathjax', 
which is also in package fabio-viewer 0.7.0+dfsg-1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-YgDMUP/18-python-fabio_0.7.0+dfsg-1_amd64.deb


cheers,

Andreas


fabio-viewer=0.7.0+dfsg-1_python-fabio=0.7.0+dfsg-1.log.gz
Description: application/gzip

Bug#905216: python-django: CVE-2018-14574: Open redirect possibility in CommonMiddleware

[Salvatore Bonaccorso]

Message-ID: <153313528104.8270.16608958406899848082.reportbug@eldamar.local>
X-Mailer: reportbug 7.5.0
Date: Wed, 01 Aug 2018 16:54:41 +0200
Delivered-To: sub...@bugs.debian.org
X-Debian-Message: from BTS
X-Mailing-List:  archive/latest/1476425
X-Loop: debian-bugs-dist@lists.debian.org
List-Id: 
List-URL: 
List-Post: 
List-Help: 
List-Subscribe: 

List-Unsubscribe: 

Precedence: list
Resent-Sender: debian-bugs-dist-requ...@lists.debian.org
X-MXTHUNDER-Identifier:  
<153313528104.8270.16608958406899848082.reportbug@eldamar.local>
X-MXTHUNDER-IP-Rating:  0, 82.195.75.100, Ugly c=0.318533 p=-0.181818 Source 
Normal
X-MXTHUNDER-Scan-Result:  100
X-MXTHUNDER-Rules: 
100-75201-4102-4121-m
100-75201-0-5556-f
X-MXTHUNDER-Group:  Bulk Mail

Source: python-django
Version: 1:1.11.14-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for python-django.

CVE-2018-14574[0]:
Open redirect possibility in CommonMiddleware

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-14574
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14574
[1] https://www.djangoproject.com/weblog/2018/aug/01/security-releases/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#905124: Acknowledgement (abcde: Can't use an undefined value as an ARRAY reference at /usr/bin/abcde-musicbrainz-tool line 98)

[Helge Kreutzmann]

Hello Maintainer(s),
I read in #892480 (which seems a similar issue) that you need the
output of abcde with "-D" added.

I attached it to this e-mail.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
+ getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt
+ case "$opt" in
+ OUTPUTTYPE=mp3
+ getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt
+ case "$opt" in
+ PADTRACKS=y
+ getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt
+ case "$opt" in
+ EXTRAVERBOSE=1
+ getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt
+ case "$opt" in
+ EJECTCD=y
+ getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt
+ case "$opt" in
+ COMMENT='Ripped 01.08.2018 on samd'
+ getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt
+ shift 8
+ '[' n = y ']'
+ echo /dev/cdrom
+ grep -i '.flac$'
+ '[' -n '' ']'
+ '[' '' = flac ']'
+ '[' '' = '' ']'
+ for DEFAULT_CDROMREADER in $DEFAULT_CDROMREADERS
+ new_checkexec cdparanoia
+ '[' '!' cdparanoia = '' ']'
++ echo cdparanoia
++ cut '-d ' -f2
+ X=cdparanoia
++ which cdparanoia
+ WHICH=/usr/bin/cdparanoia
+ '[' -z /usr/bin/cdparanoia ']'
+ '[' '!' -x /usr/bin/cdparanoia ']'
+ return 0
+ CDROMREADERSYNTAX=cdparanoia
+ break
+ '[' cdparanoia = '' ']'
+ '[' '' = y ']'
+ '[' 0 -gt 0 ']'
+ DOCDDB=n
+ DOREAD=n
+ DONORMALIZE=n
+ DOPREPROCESS=n
+ DOENCODE=n
+ DOPOSTPROCESS=n
+ DOTAG=n
+ DOMOVE=n
+ DOREPLAYGAIN=n
+ DOPLAYLIST=n
+ DOCLEAN=n
+ '[' '' '!=' y ']'
+ DOCUE=n
++ echo cddb,read,encode,tag,move,clean
++ tr , ' '
+ for ACTION in $(echo "$ACTIONS" | tr , \ )
+ case $ACTION in
+ DOCDDB=y
+ for ACTION in $(echo "$ACTIONS" | tr , \ )
+ case $ACTION in
+ DOREAD=y
+ for ACTION in $(echo "$ACTIONS" | tr , \ )
+ case $ACTION in
+ DOENCODE=y
+ DOREAD=y
+ for ACTION in $(echo "$ACTIONS" | tr , \ )
+ case $ACTION in
+ DOTAG=y
+ DOREAD=y
+ DOENCODE=y
+ DOCDDB=y
+ for ACTION in $(echo "$ACTIONS" | tr , \ )
+ case $ACTION in
+ DOMOVE=y
+ DOTAG=y
+ DOREAD=y
+ DOENCODE=y
+ DOCDDB=y
+ for ACTION in $(echo "$ACTIONS" | tr , \ )
+ case $ACTION in
+ DOCLEAN=y
+ '[' n = y ']'
++ echo year,genre
++ tr , ' '
+ for SHOWCDDBFIELD in $(echo "$SHOWCDDBFIELDS" | tr , \ )
+ case $SHOWCDDBFIELD in
+ SHOWCDDBYEAR=y
+ for SHOWCDDBFIELD in $(echo "$SHOWCDDBFIELDS" | tr , \ )
+ case $SHOWCDDBFIELD in
+ SHOWCDDBGENRE=y
+ '[' X/dev/cdrom '!=' X ']'
+ '[' '' = y ']'
+ '[' '!' -e /dev/cdrom ']'
+ '[' X = Xy ']'
+ '[' X = Xy ']'
+ '[' n = y ']'
+ '[' Xmp3 = X ']'
+ case "$CDROMREADERSYNTAX" in
+ CDROMREADER=cdparanoia
+ CDROMREADEROPTS=
+ case "$NORMALIZERSYNTAX" in
+ NORMALIZER=normalize-audio
+ NORMALIZEROPTS=
+ case "$OUTPUTTYPE" in
++ echo mp3
++ tr , ' '
+ for OUTPUT in $(echo "$OUTPUTTYPE" | tr , \ )
+ case $OUTPUT in
+ '[' default = default ']'
+ MP3ENCODERSYNTAX=lame
+ '[' y = y ']'
+ NEEDTAGGER=y
+ '[' n = y ']'
+ '[' '' = y ']'
+ case "$MP3ENCODERSYNTAX" in
+ MP3ENCODEROPTS=
+ MP3ENCODER=lame
+ case "$OGGENCODERSYNTAX" in
+ case "$OPUSENCODERSYNTAX" in
+ case "$MKAENCODERSYNTAX" in
+ case "$AIFFENCODERSYNTAX" in
+ case "$FLACENCODERSYNTAX" in
+ case "$SPEEXENCODERSYNTAX" in
+ case "$MPCENCODERSYNTAX" in
+ case "$WVENCODERSYNTAX" in
+ case "$TTAENCODERSYNTAX" in
+ case "$APENCODERSYNTAX" in
+ case "$MP2ENCODERSYNTAX" in
+ case "$AACENCODERSYNTAX" in
+ case "$ID3TAGV" in
+ TAGGER=eyeD3
+ '[' 6 -lt 6 ']'
+ eyeD3 --help
+ grep -q -- --set-encoding
+ ID3SYNTAX=eyed3
+ TAGGEROPTS='--encoding utf16 '
+ '[' n = y ']'
+ case "$CUEREADERSYNTAX" in
+ CUEREADEROPTS=/dev/cdrom
+ CUEREADER=mkcue
+ case "$CDDBTOOL" in
+ '[' X = Xogg ']'
+ '[' 10 ']'
+ ENCNICE='-n 10'
+ '[' 10 ']'
+ READNICE='-n 10'
+ '[' 10 ']'
+ DISTMP3NICE='-n 10'
+ '[' '' ']'
+ '[' n = y ']'
+ '[' y = y ']'
+ NEEDEJECT=y
+ '[' '!' y = n ']'
+ '[' y = y ']'
+ case $CDDBMETHOD in
+ '[' n = y ']'
+ '[' X '!=' X ']'
+ '[' '' = y ']'
+ PIPERIPPER_cdparanoia=-
+ PIPERIPPER_libcdio=-
+ PIPERIPPER_cdda2wav=-
+ PIPERIPPER_debug=-
+ PIPERIPPER_flac='-c '
+ PIPERIPPER_pird=-
+ PIPE_mp3enc=-sti
+ PIPE_lame=-
+ PIPE_bladeenc=stdin
+ PIPE_oggenc=-
+ PIPE_opusenc=-
+ PIPE_flac=-
+ PIPE_speexenc=-
+ PIPE_mpcenc=-
+ PIPE_wavpack=-
+ PIPE_faac=-
+ PIPE_qaac=-
+ PIPE_fhgaacenc=-
+ PIPE_ffmpeg=-
+ PIPE_tta=-
+ PIPE_ttaenc=-
+ PIPE_neroAacEnc=-
+ PIPE_fdkaac=-
+ '[' '' = y ']'
+ for X in $CDROMREADER $CDDISCID ${NEEDTAGGER+$TAGGER} $MP3ENCODER $OGGENCODER 
$OPUSENCODER $MKAENCODER $FLACENCODER $SPEEXENCODER $MPCENCODER $AACENCODER 
$WVENCODER $CDDBTOOL $APENCODER $MP2ENCODER $TTAENCODER $AIFFENCODER 
${NEEDHTTPGET+$HTTPGET} ${NEEDDISTMP3+$DISTMP3} ${NEEDCOMMENTER+$VORBISCOMMENT} 
${NEEDMETAFLAC+$METAFLAC} ${NEEDNORMALIZER+$NORMALIZER} ${NEEDEJECT+$EJECT} 
${NEEDDISKUTIL+diskutil} ${NEEDCDSPEED+$CDSPEED} ${NEEDVORBISGAIN+$VORBISGAIN} 

Bug#905206: profnet: autopkgtest regression

[Graham Inggs]

Source: profnet
Version: 1.0.22-5
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 1.0.22-5, profnet fails its autopkgtests [1] with 
the following error:


autopkgtest [02:16:50]:  summary
command1 PASS
command2 PASS
command3 PASS
command4 PASS
command5 FAIL non-zero exit status 139

autopkgtest [02:16:49]: test command5: [---

Program received signal SIGSEGV: Segmentation fault - invalid memory 
reference.


Backtrace for this error:
#0  0x7efe4bafe0ba
#1  0x7efe4bafd2d3
#2  0x7efe4afc071f
#3  0x7efe4bc699cb
#4  0x7efe4bc6aa8b
#5  0x7efe4bc6dc20
#6  0x7efe4bc6f1fc
#7  0x5612e8fd4f84
#8  0x5612e8fd674c
#9  0x5612e8fdf1fd
#10  0x5612e8fcdfde
#11  0x7efe4afacf29
#12  0x5612e8fce019
#13  0x
Segmentation fault

Regards
Graham


[1] https://ci.debian.net/packages/p/profnet/unstable/amd64/

Bug#892612: ITP: conbuilder -- container-basade package builder for Debian packages

[Benjamin Drung]

Am Sonntag, den 11.03.2018, 11:31 + schrieb Federico Ceratto:
> Package: wnpp
> Severity: wishlist
> Owner: Federico Ceratto 
> 
> * Package name: conbuilder
>   Version : 0.0.1
>   Upstream Author : Federico Ceratto 
> * URL : https://salsa.debian.org/federico/conbuilder
> * License : GPLv3
>   Programming Lang: Python
>   Description : container-basade package builder for Debian
> packages
> 
> Build Debian packages using OverlayFS and systemd namespace
> containers.
> 
> conbuilder creates a base filesystem using debootstrap, then
> overlays it with a filesystem to install the required dependencies
> and finally runs the build on another overlay.
> 
> Layers are created, reused and purged automatically to achieve
> fast package builds while minimizing disk usage.
> 
> It takes less than 2 seconds to start a new build on an already
> existing
> overlay.

What's the difference to sbuild which is configured to use overlays?

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL: https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens

Bug#905215: CVE-2018-2941

[Moritz Muehlenhoff]

Source: openjfx
Severity: grave
Tags: security

http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
fixed CVE-2018-2941 in JavaFX, which should affect our openjfx package.

Cheers,
Moritz

Bug#905225: slapd: apt-get upgrade with Duplicate attributeType: "2.5.4.2"

[Jack McKinney]

Package: slapd
Version: 2.4.44+dfsg-5+deb9u1
Severity: important

Dear Maintainer,

   * What led up to the situation? I wanted to update my system
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I ran "apt-get upgrade"
   * What was the outcome of this action? It bailed when it hit slapd
   * What outcome did you expect instead? apt-get upgrade usually just
works

It upgraded most of the packages just fine, but failed when it hit
slapd.
If I try it again, I get the same result. It complains about the
schema, but
the schema here are the dist schema; I have not modified them. I found
this
exact schema error in google going back over a decade, but the fix does
not
apply to my system (and it has been working fine for quite some time,
not
throwing this error until I tried to apt-get upgrade).

hamilton /home/jackmc [1] # apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 slapd : Depends: libldap-2.4-2 (= 2.4.44+dfsg-5+deb9u1) but
2.4.44+dfsg-5+deb9u2 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages
(or specify a solution).
hamilton /home/jackmc [2] # apt --fix-broken install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  slapd
Suggested packages:
  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal
The following packages will be upgraded:
  slapd
1 upgraded, 0 newly installed, 0 to remove and 67 not upgraded.
44 not fully installed or removed.
Need to get 0 B/1,430 kB of archives.
After this operation, 1,024 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 199351 files and directories currently
installed.)
Preparing to unpack .../slapd_2.4.44+dfsg-5+deb9u2_amd64.deb ...
Saving current slapd configuration to /var/backups/slapd-2.4.44+dfsg-
5+deb9u1...
5b61c485 olcAttributeTypes: value #0 olcAttributeTypes: Duplicate
attributeType: "2.5.4.2"
5b61c485 config error processing cn={0}core,cn=schema,cn=config:
olcAttributeTypes: Duplicate attributeType: "2.5.4.2"
slapcat: bad configuration directory!
dpkg: error processing archive
/var/cache/apt/archives/slapd_2.4.44+dfsg-5+deb9u2_amd64.deb (
--unpack):
 subprocess new pre-installation script returned error exit status 1
  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.44+dfsg-
5+deb9u2... done.
Errors were encountered while processing:
 /var/cache/apt/archives/slapd_2.4.44+dfsg-5+deb9u2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
hamilton /home/jackmc [3] # 



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

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

Versions of packages slapd depends on:
ii  adduser3.115
ii  coreutils  8.26-3
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3
ii  libdb5.3   5.3.28-12+deb9u1
ii  libgnutls303.5.8-5+deb9u3
iu  libldap-2.4-2  2.4.44+dfsg-5+deb9u2
ii  libltdl7   2.4.6-2
ii  libodbc1   2.3.4-1
iu  libperl5.24 [libmime-base64-perl]  5.24.1-3+deb9u4
ii  libsasl2-2 2.1.27~101-g0780600+dfsg-3
ii  libwrap0   7.6.q-26
ii  lsb-base   9.20161125
iu  perl   5.24.1-3+deb9u4
ii  psmisc 22.21-2.1+b2

Versions of packages slapd recommends:
ii  libsasl2-modules  2.1.27~101-g0780600+dfsg-3

Versions of packages slapd suggests:
iu  ldap-utils 2.4.44+dfsg-
5+deb9u2
pn  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi  

-- Configuration Files:
/etc/default/slapd changed:
SLAPD_CONF=
SLAPD_USER="openldap"
SLAPD_GROUP="openldap"
SLAPD_PIDFILE=
SLAPD_SERVICES=""
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd
SLAPD_OPTIONS="-f /etc/ldap/slapd.conf"


-- debconf information excluded

Bug#905226: openssh-server: SSH AuthorizedKeysCommand hangs when output is too large

[Dennis Schridde]

Package: openssh-server
Version: 1:7.4p1-10+deb9u3
Severity: important
Tags: patch upstream

Dear Maintainer,

when sshd's AuthorizedKeysCommand outputs a lot of keys and the match is close 
to the beginning of the output sshd will deadlock.  Upstream has a patch ready 
to fix this issue, which would need to be backported to OpenSSH 7.4p1 as used 
by Debian 9.5.

Patch: 
https://github.com/openssh/openssh-portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2

See-Also: https://bugzilla.mindrot.org/show_bug.cgi?id=2655
See-Also: https://bugzilla.redhat.com/show_bug.cgi?id=1496467


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

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

Versions of packages openssh-server depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  dpkg   1.18.25
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libc6  2.24-11+deb9u3
ii  libcomerr2 1.43.4-2
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libkrb5-3  1.15-1+deb9u1
ii  libpam-modules 1.1.8-3.6
ii  libpam-runtime 1.1.8-3.6
ii  libpam0g   1.1.8-3.6
ii  libselinux12.6-3+b3
ii  libssl1.0.21.0.2l-2+deb9u3
ii  libsystemd0232-25+deb9u4
ii  libwrap0   7.6.q-26
ii  lsb-base   9.20161125
ii  openssh-client 1:7.4p1-10+deb9u3
ii  openssh-sftp-server1:7.4p1-10+deb9u3
ii  procps 2:3.3.12-3+deb9u1
ii  ucf3.0036
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages openssh-server recommends:
ii  libpam-systemd  232-25+deb9u4
ii  ncurses-term6.0+20161126-1+deb9u2
ii  xauth   1:1.0.9-1+b2

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: true
>From ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2 Mon Sep 17 00:00:00 2001
From: "d...@openbsd.org" 
Date: Fri, 30 Dec 2016 22:08:02 +
Subject: [PATCH] upstream commit

fix deadlock when keys/principals command produces a lot of
output and a key is matched early; bz#2655, patch from jboning AT gmail.com

Upstream-ID: e19456429bf99087ea994432c16d00a642060afe
---
 auth2-pubkey.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/auth2-pubkey.c b/auth2-pubkey.c
index 20f3309e1..70c021589 100644
--- a/auth2-pubkey.c
+++ b/auth2-pubkey.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: auth2-pubkey.c,v 1.60 2016/11/30 02:57:40 djm Exp $ */
+/* $OpenBSD: auth2-pubkey.c,v 1.61 2016/12/30 22:08:02 djm Exp $ */
 /*
  * Copyright (c) 2000 Markus Friedl.  All rights reserved.
  *
@@ -727,6 +727,9 @@ match_principals_command(struct passwd *user_pw, const 
struct sshkey *key)
 
ok = process_principals(f, NULL, pw, cert);
 
+   fclose(f);
+   f = NULL;
+
if (exited_cleanly(pid, "AuthorizedPrincipalsCommand", command) != 0)
goto out;
 
@@ -1050,6 +1053,9 @@ user_key_command_allowed2(struct passwd *user_pw, Key 
*key)
 
ok = check_authkeys_file(f, options.authorized_keys_command, key, pw);
 
+   fclose(f);
+   f = NULL;
+
if (exited_cleanly(pid, "AuthorizedKeysCommand", command) != 0)
goto out;
 

Bug#905224: openssh-server: SSH AuthorizedKeysCommand hangs when output is too large

[Dennis Schridde]

Package: openssh-server
Version: 1:7.4p1-10+deb9u3
Severity: important
Tags: patch upstream

Dear Maintainer,

uthorizedKeysCommand outputs a lot of keys and the match is close to the 
beginning of the output sshd will deadlock.  Upstream has a patch ready to fix 
this issue, which would need to be backported to OpenSSH 7.4 as used by Debian 
9.

Patch: 
https://github.com/openssh/openssh-portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2

See-Also: https://bugzilla.mindrot.org/show_bug.cgi?id=2655
See-Also: https://bugzilla.redhat.com/show_bug.cgi?id=1496467


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

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

Versions of packages openssh-server depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  dpkg   1.18.25
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libc6  2.24-11+deb9u3
ii  libcomerr2 1.43.4-2
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libkrb5-3  1.15-1+deb9u1
ii  libpam-modules 1.1.8-3.6
ii  libpam-runtime 1.1.8-3.6
ii  libpam0g   1.1.8-3.6
ii  libselinux12.6-3+b3
ii  libssl1.0.21.0.2l-2+deb9u3
ii  libsystemd0232-25+deb9u4
ii  libwrap0   7.6.q-26
ii  lsb-base   9.20161125
ii  openssh-client 1:7.4p1-10+deb9u3
ii  openssh-sftp-server1:7.4p1-10+deb9u3
ii  procps 2:3.3.12-3+deb9u1
ii  ucf3.0036
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages openssh-server recommends:
ii  libpam-systemd  232-25+deb9u4
ii  ncurses-term6.0+20161126-1+deb9u2
ii  xauth   1:1.0.9-1+b2

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: true
>From ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2 Mon Sep 17 00:00:00 2001
From: "d...@openbsd.org" 
Date: Fri, 30 Dec 2016 22:08:02 +
Subject: [PATCH] upstream commit

fix deadlock when keys/principals command produces a lot of
output and a key is matched early; bz#2655, patch from jboning AT gmail.com

Upstream-ID: e19456429bf99087ea994432c16d00a642060afe
---
 auth2-pubkey.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/auth2-pubkey.c b/auth2-pubkey.c
index 20f3309e1..70c021589 100644
--- a/auth2-pubkey.c
+++ b/auth2-pubkey.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: auth2-pubkey.c,v 1.60 2016/11/30 02:57:40 djm Exp $ */
+/* $OpenBSD: auth2-pubkey.c,v 1.61 2016/12/30 22:08:02 djm Exp $ */
 /*
  * Copyright (c) 2000 Markus Friedl.  All rights reserved.
  *
@@ -727,6 +727,9 @@ match_principals_command(struct passwd *user_pw, const 
struct sshkey *key)
 
ok = process_principals(f, NULL, pw, cert);
 
+   fclose(f);
+   f = NULL;
+
if (exited_cleanly(pid, "AuthorizedPrincipalsCommand", command) != 0)
goto out;
 
@@ -1050,6 +1053,9 @@ user_key_command_allowed2(struct passwd *user_pw, Key 
*key)
 
ok = check_authkeys_file(f, options.authorized_keys_command, key, pw);
 
+   fclose(f);
+   f = NULL;
+
if (exited_cleanly(pid, "AuthorizedKeysCommand", command) != 0)
goto out;
 

Bug#905209: libgraphviz-dev: broken symlinks: /usr/lib/tcl8.6/graphviz/lib*.so -> lib*.so.0.0.0

[Andreas Beckmann]

Package: libgraphviz-dev
Version: 2.40.1-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

2m19.5s ERROR: FAIL: Broken symlinks:
  /usr/lib/tcl8.6/graphviz/libtclplan.so -> libtclplan.so.0.0.0
  /usr/lib/tcl8.6/graphviz/libtcldot_builtin.so -> libtcldot_builtin.so.0.0.0
  /usr/lib/tcl8.6/graphviz/libtcldot.so -> libtcldot.so.0.0.0
  /usr/lib/tcl8.6/graphviz/libgdtclft.so -> libgdtclft.so.0.0.0

The target files seem to live at a different location now:

libgv-tcl: /usr/lib/x86_64-linux-gnu/graphviz/tcl/libtclplan.so.0.0.0
libgv-tcl: /usr/lib/x86_64-linux-gnu/graphviz/tcl/libtcldot_builtin.so.0.0.0
libgv-tcl: /usr/lib/x86_64-linux-gnu/graphviz/tcl/libtcldot.so.0.0.0
libgv-tcl: /usr/lib/x86_64-linux-gnu/graphviz/tcl/libgdtclft.so.0.0.0


cheers,

Andreas


lcl-nogui-1.8_1.8.4+dfsg-2.log.gz
Description: application/gzip

Bug#884190: graphite2: FTBFS on x32: Test #78: bits: Failed

[Thorsten Glaser]

Source: graphite2
Version: 1.3.11-2
Followup-For: Bug #884190

I’ve discovered the root of the issue: a check for __x86_64__
without a corresponding check for __ILP32__ makes x32 being
misdetected as amd64.

The actual test failed because the preparation of the test data
uses UL not ULL, and long is only 32 bit on x32.

Please also forward this upstream, although they’ll want to use…

#if (defined(__x86_64__) && !defined(__ILP32__)) || defined(_WIN64)

… instead.
diff -Nru graphite2-1.3.11/debian/changelog graphite2-1.3.11/debian/changelog
--- graphite2-1.3.11/debian/changelog   2018-03-11 13:22:48.0 +0100
+++ graphite2-1.3.11/debian/changelog   2018-08-01 17:39:17.0 +0200
@@ -1,3 +1,10 @@
+graphite2 (1.3.11-2+x32.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix x32 being misdetected as amd64 in tests. (Closes: #884190)
+
+ -- Thorsten Glaser   Wed, 01 Aug 2018 17:39:17 +0200
+
 graphite2 (1.3.11-2) unstable; urgency=medium
 
   * backport upstream commit db132b4731a9b4c9534144ba3a18e65b390e9ff6
diff -Nru graphite2-1.3.11/debian/patches/fix-x32.diff 
graphite2-1.3.11/debian/patches/fix-x32.diff
--- graphite2-1.3.11/debian/patches/fix-x32.diff1970-01-01 
01:00:00.0 +0100
+++ graphite2-1.3.11/debian/patches/fix-x32.diff2018-08-01 
17:39:09.0 +0200
@@ -0,0 +1,22 @@
+# DP: x32 is not amd64, fix FTBFS
+
+--- a/tests/bittwiddling/bits.cpp
 b/tests/bittwiddling/bits.cpp
+@@ -65,7 +65,7 @@ namespace
+ patterns(8);
+ patterns(16);
+ patterns(32);
+-#ifdef __x86_64__
++#if defined(__x86_64__) && !defined(__ILP32__)
+ patterns(64);
+ #endif
+ 
+@@ -124,7 +124,7 @@ int main(int argc , char *argv[])
+ test_bit_set_count(s16_pat);
+ test_bit_set_count(u32_pat);
+ test_bit_set_count(s32_pat);
+-#ifdef __x86_64__
++#if defined(__x86_64__) && !defined(__ILP32__)
+ test_bit_set_count(u64_pat);
+ test_bit_set_count(s64_pat);
+ #endif
diff -Nru graphite2-1.3.11/debian/patches/series 
graphite2-1.3.11/debian/patches/series
--- graphite2-1.3.11/debian/patches/series  2018-03-11 13:22:11.0 
+0100
+++ graphite2-1.3.11/debian/patches/series  2018-08-01 17:37:51.0 
+0200
@@ -6,3 +6,4 @@
 reproducible-build.diff
 PYTHON_EXECUTABLE.diff
 db132b4731a9b4c9534144ba3a18e65b390e9ff6.diff
+fix-x32.diff

Bug#905230: elfutils: FTBFS on x32 due to bugs in testsuite

[Thorsten Glaser]

Source: elfutils
Version: 0.170-0.5
Severity: important
Justification: fails to build from source (but built successfully in the past)

debian/patches/testsuite-core-files.diff essentially cleans up
a core file that is only created when the architecture to be
tested does not support unwinding as tested in run-backtrace-dwarf.sh
which made the “rmdir” after the test fail.

The change to debian/rules lets me successfully build this.
It might be related to eatmydata, or not, but it’s actually
nontrivial to disable eatmydata in my cowbuilder environment…

Please apply with the next regular upload to unstable.

Thanks!
diff -Nru elfutils-0.170/debian/changelog elfutils-0.170/debian/changelog
--- elfutils-0.170/debian/changelog 2018-06-24 20:54:50.0 +0200
+++ elfutils-0.170/debian/changelog 2018-08-01 17:53:57.0 +0200
@@ -1,3 +1,11 @@
+elfutils (0.170-0.5+x32.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable biarch tests on x32 to fix FTBFS.
+  * Patch testsuite to clean up core files created on some targets.
+
+ -- Thorsten Glaser   Wed, 01 Aug 2018 17:53:57 +0200
+
 elfutils (0.170-0.5) unstable; urgency=medium
 
   * Non-maintainer upload acked by Kurt Roeckx.
diff -Nru elfutils-0.170/debian/patches/series 
elfutils-0.170/debian/patches/series
--- elfutils-0.170/debian/patches/series2018-04-09 14:21:19.0 
+0200
+++ elfutils-0.170/debian/patches/series2018-08-01 17:52:25.0 
+0200
@@ -13,3 +13,4 @@
 disable_werror.patch
 GNU_variable_value.patch
 locviews.patch
+testsuite-core-files.diff
diff -Nru elfutils-0.170/debian/patches/testsuite-core-files.diff 
elfutils-0.170/debian/patches/testsuite-core-files.diff
--- elfutils-0.170/debian/patches/testsuite-core-files.diff 1970-01-01 
01:00:00.0 +0100
+++ elfutils-0.170/debian/patches/testsuite-core-files.diff 2018-08-01 
17:53:50.0 +0200
@@ -0,0 +1,11 @@
+# DP: fix FTBFS on x32 where unwinding is not supported
+
+--- a/tests/run-backtrace-dwarf.sh
 b/tests/run-backtrace-dwarf.sh
+@@ -28,3 +28,6 @@ tempfiles dwarf.{bt,err}
+ cat dwarf.{bt,err}
+ check_native_unsupported dwarf.err dwarf
+ check_main dwarf.bt dwarf
++# running this on architectures not supporting unwinding calls abort()
++# causing core dump creation
++rm -f core
diff -Nru elfutils-0.170/debian/rules elfutils-0.170/debian/rules
--- elfutils-0.170/debian/rules 2017-09-06 10:11:35.0 +0200
+++ elfutils-0.170/debian/rules 2018-08-01 17:29:17.0 +0200
@@ -15,6 +15,7 @@
 
 # These are used for cross-compiling and for saving the configure script
 # from having to guess our platform (since we know it already)
+DEB_HOST_ARCH   ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_MULTIARCH  ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
@@ -25,6 +26,10 @@
 confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
+ifneq (,$(filter x32,$(DEB_HOST_ARCH)))
+   confenv += utrace_cv_cc_biarch=no
+endif
+
 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
 NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
 MAKEFLAGS += -j$(NUMJOBS)
@@ -37,12 +42,12 @@
dh_testdir
autoreconf -fis
 ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
-   ./configure --enable-maintainer-mode
+   $(confenv) ./configure --enable-maintainer-mode
$(MAKE) $(MAKEFLAGS)
$(MAKE) clean
 endif
CFLAGS="$(CFLAGS) -O3" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" \
-   ./configure $(confflags) --prefix=/usr \
+   $(confenv) ./configure $(confflags) --prefix=/usr \
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
--program-prefix=eu- --disable-silent-rules
 

Bug#905058: policykit-1: brlapi connections do not work any more

[Samuel Thibault]

Control: reassign -1 905058 brltty
Control: tags -1 + patch pending

Samuel Thibault, le mar. 31 juil. 2018 02:42:06 +0200, a ecrit:
> As reported also on
> https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1782320
> , on upgrading from policykit 0.105-20 to 0.105-21, brlapi connections
> have stopped working.

So it seems it is a misuse of the policykit API from brltty, I will
upload a fixed package.

Samuel

Bug#905204: Add support for reminding page authors to update content periodically

[Steve McIntyre]

Package: wiki.debian.org
Severity: wishlist

An idea I've had for a while but not yet implemented properly. Here as
a reminder...

Add support for extra metadata (Category) to mark pages as needing
checking/updating after a specified period (e.g. 3w, 6m, after a new
major Debian release). Then we can add a script to walk the wiki page
data periodically and mail people (the last page editor?) when pages
are outdated.

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

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

Bug#905187: php7.2/7.2.8-1 appears to break multiple autopkgtest: /usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found

[Lior Kaplan]

Thanks. I'll check it ASAP.

There's an RC bug against the package for the maintainer address, I'll keep
it open as it prevent the transition to testing for now (:

On Wed, Aug 1, 2018 at 2:08 PM, Paul Gevers  wrote:

> Source: php7.2
> Version: 7.2.8-1
> User: debian...@lists.debian.org
> Usertags: breaks
> Control: affects -1 src:php-luasandbox src:wikidiff2
>
> Dear maintainers, [X-Debbugs-CC set to affected packages and CI team]
>
> With a recent upload of php7.2 the autopkgtest of php-luasandbox and
> wikidiff2 started to fail in unstable and testing. I copied the error
> below.
>
> Currently this regression is delaying the migration of php7.2 to
> testing by 13 days. From the error it seems that a dependency on sed is
> missing somewhere, but that is just a hunch. Could you please
> investigate the situation? If php-luasandbox and wikidiff2 need to adapt
> their autopkgtest, please clone and re-assign.
>
> More information about this bug and the reason for filing it can be
> found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/
> php-luasandbox/749361/log.gz
>
> autopkgtest [04:34:43]: test unittests: [---
> /usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
> /usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
> /usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
> Configuring for:
> PHP Api Version:
> Zend Module Api No:
> Zend Extension Api No:
> /usr/bin/phpize: 157: /usr/bin/phpize: /usr/bin/sed: not found
> autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
> autopkgtest [04:34:43]: test unittests: ---]
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/w/
> wikidiff2/749373/log.gz
>
> autopkgtest [04:36:15]: test unittests: [---
> /usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
> /usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
> /usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
> Configuring for:
> PHP Api Version:
> Zend Module Api No:
> Zend Extension Api No:
> /usr/bin/phpize: 157: /usr/bin/phpize: /usr/bin/sed: not found
> autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
> autopkgtest [04:36:16]: test unittests: ---]
>
>

Bug#901563:

[Ricardo Ribalda Delgado]

As suggested in https://github.com/amonakov/primus/issues/201

PRIMUS_UPLOAD=1 primusrun glxgears

works for me
-- 
Ricardo Ribalda

Bug#859453: dunst: Installing dunst does not ensure dbus is running

[Pascal De Vuyst]

Package: dunst
Version: 1.3.0-2
Severity: normal
Tags: patch

Michael,

As described in
 I
created a patch for this issue, see attachment please include it.

Thanks,
Pascal
--- debian/control.orig	2018-01-29 16:53:39.0 +0100
+++ debian/control	2018-08-01 16:39:24.085282837 +0200
@@ -23,7 +23,7 @@
 
 Package: dunst
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, default-dbus-session-bus | dbus-session-bus
 Provides: notification-daemon
 Description: dmenu-ish notification-daemon
  Dunst is a highly configurable and lightweight notification-daemon: The

Bug#905218: python-django: CVE-2018-14574

[Chris Lamb]

Package: python-django
Version: 1.4.22-1+deb7u4
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-django.

CVE-2018-14574[0]:
Open redirect possibility in CommonMiddleware

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-14574
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14574


Regards,

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

Bug#905221: kicad: pcbnew immediately crashes after invocation without showing a GUI (failed assertion)

[Werner Frey]

Package: kicad
Version: 5.0.0+dfsg1-1
Severity: important
Tags: upstream

Dear Maintainer,

pcbnew aborts immediately after invocation on my i386 Debian Buster 
installation.
The kicad package was freshly installed for the first time.
There were no changes to the default configuration of the package.
When I started pcbnew the very first time a hint window pops up, saying that I 
am
using pcbnew the first time using the new search method for footprints. After I
confirmed the popup by clicking the OK button, the messages below appeared and
pcbnew aborted. On later invocations the popup window doesn't appear and pcbnew
aborts immediatly showing the messages below.

As this behaviour also kills eeschema without any warning  when searching for 
footprints
from within eeschema the complete kicad package is unusable for me.

-
$ pcbnew
16:43:53: Debug: Checking template path '/usr/share/kicad/template' exists
16:43:53: Debug: wxColour::Set - couldn't set to colour string 'NONE'
   ... message repeated 70 times
16:43:53: Debug: wxColour::Set - couldn't set to colour string 'NONE'
pcbnew: /build/kicad-0u70G2/kicad-5.0.0+dfsg1/include/geometry/rtree.h:1643: 
void RTree::Classify(int, int, RTree::PartitionVars*) [with DATATYPE = KIGFX::VIEW_ITEM*; 
ELEMTYPE = int; int NUMDIMS = 2; ELEMTYPEREAL = float; int TMAXNODES = 8; int 
TMINNODES = 4]: Zusicherung !a_parVars->m_taken[a_index] nicht erfllt.
Abgebrochen
-

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

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

Versions of packages kicad depends on:
ii  libc6   2.27-5
ii  libcairo2   1.15.10-3
ii  libcurl47.60.0-2
ii  libgcc1 1:8.1.0-12
ii  libglew2.0  2.0.0-6
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libglx0 1.0.0+git20180308-3
ii  libgomp18.1.0-12
ii  libopengl0  1.0.0+git20180308-3
ii  libpixman-1-0   0.34.0-2
ii  libpython2.72.7.15-3
ii  libssl1.1   1.1.0h-4
ii  libstdc++6  8.1.0-12
ii  libwxbase3.0-0v53.0.4+dfsg-4
ii  libwxgtk3.0-0v5 3.0.4+dfsg-4
ii  python  2.7.15-3
ii  python-wxgtk3.0 3.0.2.0+dfsg-8

Versions of packages kicad recommends:
ii  kicad-demos  5.0.0+dfsg1-1
ii  kicad-libraries  5.0.0+dfsg1-1
pn  xsltproc 

Versions of packages kicad suggests:
ii  extra-xdg-menus   1.0-4
ii  kicad-doc-en  5.0.0+dfsg1-1
pn  kicad-packages3d  

-- no debconf information

Bug#905219: [Pkg-openldap-devel] Bug#905219: slapd: apt-get upgrade with Duplicate attributeType: "2.5.4.2"

[Ryan Tandy]

Hi Jack,

Thanks for the report.

On Wed, Aug 01, 2018 at 10:35:00AM -0400, Jack McKinney wrote:

Saving current slapd configuration to /var/backups/slapd-2.4.44+dfsg-5+deb9u1...
5b61c485 olcAttributeTypes: value #0 olcAttributeTypes: Duplicate attributeType: 
"2.5.4.2"
5b61c485 config error processing cn={0}core,cn=schema,cn=config: olcAttributeTypes: 
Duplicate attributeType: "2.5.4.2"
slapcat: bad configuration directory!


Interesting. I wonder how it got that way?

Can you confirm by pasting the output of:

grep -Frw 2.5.4.2 /etc/ldap/slapd.d

that it actually occurs twice in your config?

You might have some older config backups in /var/backups/slapd-*; can 
you also check those and see if you can determine in which version it 
was introduced?


What is your upgrade history like for slapd? Were you running 
2.4.44+dfsg-5 and then upgraded to +deb9u1 before this upgrade to 
+deb9u2?


If there is a bug in the package, I would be most suspicious of the 
upgrade path from jessie to stretch...


thanks,
Ryan

Bug#902788: python3.7: needs Breaks for software/modules broken by 3.7 ("async" became a reserved keyword)

[Andreas Beckmann]

Followup-For: Bug #902788

Hi,

Breaks are missing against

* python3-pyatspi (<= 2.26.0+dfsg-1)#902989


Andreas

Bug#905229: python3-stem: missing Depends: python3-distutils

[Andreas Beckmann]

Package: python3-stem
Version: 1.6.0-3
Severity: serious
Control: affects -1 onionshare

$ onionshare
Traceback (most recent call last):
  File "/usr/bin/onionshare", line 21, in 
import onionshare
  File "/usr/lib/python3/dist-packages/onionshare/__init__.py", line 24, in 

from .onion import *
  File "/usr/lib/python3/dist-packages/onionshare/onion.py", line 21, in 

from stem.control import Controller
  File "/usr/lib/python3/dist-packages/stem/control.py", line 265, in 
import stem.descriptor.microdescriptor
  File "/usr/lib/python3/dist-packages/stem/descriptor/__init__.py", line 55, 
in 
import stem.util.system
  File "/usr/lib/python3/dist-packages/stem/util/system.py", line 70, in 

import distutils.spawn
ModuleNotFoundError: No module named 'distutils.spawn'


Andreas

Bug#905058: policykit-1: brlapi connections do not work any more

[Samuel Thibault]

Simon McVittie, le mer. 01 août 2018 17:29:39 +0100, a ecrit:
> On Wed, 01 Aug 2018 at 18:13:47 +0200, Samuel Thibault wrote:
> > Control: reassign -1 905058 brltty
> > Control: tags -1 + patch pending
> > 
> > Samuel Thibault, le mar. 31 juil. 2018 02:42:06 +0200, a ecrit:
> > > As reported also on
> > > https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1782320
> > > , on upgrading from policykit 0.105-20 to 0.105-21, brlapi connections
> > > have stopped working.
> > 
> > So it seems it is a misuse of the policykit API from brltty, I will
> > upload a fixed package.
> 
> Thanks. Would you like us to add a versioned Breaks in polkit?

That could be useful, just in case.

> Please could you also prepare the same fix for stretch? We'll need that
> to avoid regressing when we upload a polkit with this CVE fix there.

Oh right, I'll do it.

Samuel

Bug#905199: mozjs52: Please update debian/test.sh to add sparc64, remove ppc64el from ignore list

[Simon McVittie]

On Wed, 01 Aug 2018 at 16:44:35 +0200, John Paul Adrian Glaubitz wrote:
> On 08/01/2018 02:25 PM, John Paul Adrian Glaubitz wrote:
> > The testsuite for mozjs52 fails on sparc64 while it passes on ppc64el,
> > so please add sparc64 to the list and remove ppc64el.
> 
> Please add alpha to the ignore list as well [1].

Sure. Do we already have bug numbers for the failure modes on these
architectures? If not, you could speed this up by opening appropriately
usertagged and X-Debbugs-Cc'd bugs with a brief description of what is
failing, or mentioning the failures on an existing bug if they look
like the same bug as on some other architecture. As an active porter
you probably know the right usertags better than I do :-)

I'm trying not to ignore test failures unless I've already opened a bug
about them; I did cheat for m68k, where you mentioned the failure mode
in a comment on a different bug, but now that mozjs52 is buildable on
m68k the test failure really deserves a separate non-RC bug.

smcv

Bug#905231: dh-python: generate dependency on python{,3}-pkg-resources ?

[Andreas Beckmann]

Package: dh-python
Version: 3.20180723
Severity: normal

Hi,

should dh_python{,3} generate a dependency on python{,3}-pkg-resources
if needed?

There are a lot of packages in the archive using a construct like

$ cat /usr/bin/thonny
#!/usr/bin/python3
# EASY-INSTALL-ENTRY-SCRIPT: 'thonny==2.1.17','gui_scripts','thonny'
__requires__ = 'thonny==2.1.17'
import re
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(
load_entry_point('thonny==2.1.17', 'gui_scripts', 'thonny')()
)

but missing a dependency on python{,3}-pkg-resources, resulting in

$ thonny
Traceback (most recent call last):
  File "/usr/bin/thonny", line 6, in 
from pkg_resources import load_entry_point
ModuleNotFoundError: No module named 'pkg_resources'

I started filing bugs, but didn't expect the huge number of failures.
Right now I have about 230 (mostly unchecked) logfiles for sid with
related failures. And 180 for stretch.

Since this is a rather common pattern, could the tooling be improved to
add this missing dependency automatically?

Since most/all affected packages are arch:all, they will need a sourceful
upload to fix the dependency anyway, but still having the dependency
generated instead of hardcoding it should have benefits.

A few bugs: #904772, #904771, #904769, #904768, #904762, #904748,
  #842393, #870359, 

We should give them a usertag, what would you prefer?


Andreas

Bug#905205: system-config-printer: Ask root password to configure printer while beeing in lpadmin group

[Simone Piccardi]

Package: system-config-printer
Version: 1.5.11-2
Severity: normal

Dear Maintainer,

I'm using the XFCE desktop, and lanching printer manager from application 
menu. I tryied to unblock it to add a printer, and it's asking me the 
root password not the one of the user I was using.

The user is the user created on installation, and it's inside the lpadmin 
group. If I try to install a printer using lpadmin it works fine:

antani@buster:~$ id antani
uid=1000(antani) gid=1000(antani) 
gruppi=1000(antani),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),106(netdev),113(lpadmin),114(scanner)
antani@buster:~$ /usr/sbin/lpadmin -p prova -E -v ipp://192.168.0.2:631
antani@buster:~$ lpstat -v
dispositivo per prova: ipp://192.168.0.2:631

It also works via browser in port 631 using the current user and password.

This way I cannot give an user the privilege of adding or managing printers

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

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

Versions of packages system-config-printer depends on:
ii  gir1.2-gdkpixbuf-2.0  2.36.12-1
ii  gir1.2-glib-2.0   1.56.1-1
ii  gir1.2-gtk-3.03.22.30-2
ii  gir1.2-notify-0.7 0.7.7-3
ii  gir1.2-packagekitglib-1.0 1.1.10-1
ii  gir1.2-pango-1.0  1.42.1-2
ii  gir1.2-polkit-1.0 0.105-21
ii  python3   3.6.5-3
ii  python3-cups  1.9.73-2+b1
ii  python3-cupshelpers   1.5.11-2
ii  python3-dbus  1.2.8-2+b1
ii  python3-gi3.28.2-1+b1
ii  system-config-printer-common  1.5.11-2

Versions of packages system-config-printer recommends:
ii  system-config-printer-udev  1.5.11-2

Versions of packages system-config-printer suggests:
pn  gnome-software  

-- no debconf information

Bug#904441: linux-image-4.17.0-1-amd64: system disk stopped during boot

[Olivier Berger]

On Tue, Jul 31, 2018 at 01:40:45AM +0900, YOSHINO Yoshihito wrote:
> I have the same problem.
> Setting "dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0" works well.
> 
FWIW, same here on Dell Latitude 5580.

# cat /sys/bus/scsi/devices/2\:0\:0\:0/model
SAMSUNG SSD PM87
# cat /sys/bus/scsi/devices/2\:0\:0\:0/rev
2D0Q

# uname -a
Linux newlatitude 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 
GNU/Linux

Also, laptop-mode-tools 1.72-2 installed, FWIW.

Now seems fine after I added dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0

Best regards,

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#905165: debootstrap - fails in docker environment

[Bastian Blank]

Package: debootstrap
Version: 1.0.106
Severity: grave

debootstrap fails in docker environment completely by:

- symlinking $TARGET/proc to /proc
- running chroot $TARGET mount -t proc none /proc

The later obviously failing with a recursive symlink:

| mount: mount proc on /proc failed: Too many levels of symbolic links

I have no idea what this detection is about, but if you are going to run
chroot, you have to also mount /proc.

Regards,
Bastian

-- 
We Klingons believe as you do -- the sick should die.  Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2

Bug#905092: ros-ros-comm: breaking reverse-dependencies

[Gianfranco Costamagna]

control: notfound -1 1.13.5+ds1-4

On Tue, 31 Jul 2018 10:02:24 +0200 Gianfranco Costamagna 
 wrote:
> Source: ros-ros-comm
> Version: 1.13.5+ds1-5
> Severity: serious
> Affects: ros-actionlib
> Affects: ros-bond-core
> Affects: ros-dynamic-reconfigure
> Affects: ros-geometry
> Affects: ros-nodelet-core
> Affects: ros-bond-core
> 
> The renaming of libroscpp-msgs-dev to libroscpp-msg-dev broke 6 ros packages, 
> can you please fixup in some way?
> 
> thanks
> 
> G.
> 
> 
> 

Bug#905166: Enable support for Opus

[Pavel Sofishchenko]

Package: sox
Version:  14.4.2-3
Severity: wishlist

Is it possible to enable Opus support using libopusfile?

Bug#905167: debmake-doc: Handling Upstream Autotools Packaging on Debian

[Paul Hardy]

Package: debmake-doc
Version: 1.9-1
Tags: patch

Section 5.16.1 recommends running autoreconf when building a package
on Debian GNU/Linux, to improve portability to new systems.  That
brings with it considerations about automake.  The default
"strictness" level of an automake setup is the "gnu" level, which
requires files AUTHORS, ChangeLog, INSTALL, NEWS, and README along
with the Makefile.am and configure.ac files that autoreconf will
expect.  That then brings other implications for using such a package
on Debian.

Elsewhere, the document refers to the GNU Coding Standards, which is
further reason to make mention of the above files, and which get
installed and which do not get installed (COPYING and INSTALL) on
Debian.

I propose that wording like what follows be considered for the end of
Section 8.9 or 8.11.  Both of those examples set the automake
strictness level to "foreign", which is good for a simple example but
leaves out some details that could help someone new with Debian
packaging.

I tried to capture the major considerations for packages that follow
GNU standards, and think something along these lines would help:

[begin insert]
The line AM_INIT_AUTOMAKE([foreign]) in configure.ac above tells
automake to use a "foreign" strictness level, which has loose
requirements for what files are in a package.  The default strictness
level for automake is "gnu", which expects the following files in the
top-level directory: AUTHORS, INSTALL, NEWS, README, ChangeLog, and
either COPYING (with a copy of a GPL license) or COPYING.LESSER (with
a copy of a LGPL license).  If you are building such a package,
Section 5.16.1 [Autotools] of this guide recommends invoking autoreconf
in debian/rules to provide better support for porting to new architectures,
compared to just running "./configure && make".  If you intend to run
autoreconf on a package with automake set to a strictness level of "gnu",
automake will complain if the files it expects in the top-level directory
are not present.  In this case the INSTALL and COPYING (or COPYING.LESSER)
files must be present in the source directory.  However, they are not
installed on Debian systems because Debian uses its own package manager
for installation, and keeps copies of common licenses in
/usr/share/common-licenses.

The other files besides Makefile.am and configure.ac that Autotools
expects in the top-level directory (AUTHORS, NEWS, README, and
ChangeLog) can be installed in /usr/share/doc/.  This
can be done by listing those files in debian/doc.  If you keep any
Autotools-generated files in the Debian package, make sure that
those files have their copyright and license information captured
in the debian/copyright file.  Their copyright notices and license
terms differ slightly, so you will have to check every one.  The
GNU Project standard practice is to leave all such files in place
if a "make distclean" leaves them, so asking upstream to remove
them is probably not the correct solution.

Running "autoreconf -ivf"  as described in Section 5.16.1 will create
a new INSTALL file even if one existed.  That file will have a copyright,
as will the GPL or LGPL in the COPYING or COPYING.LESSER file.  Therefore,
list those files in the Files-Exclude field in the first paragraph of
debian/copyright.  Also list any files that "autoreconf -ivf" creates
but that remain following a "make distclean" in the Files-Exclude field,
because autoreconf will recreate those files.  Some maintainer discretion
is allowed to leave a config.h file that should not change, etc.

Apart from those files, the only other files that must exist with the
"gnu" automake strictness level to run autoreconf in the top-level
directory are Makefile.am and configure.ac.

One of the standard "make" targets that automake creates is "distcheck".
That builds a copy of the package in a staging directory by defining
the DESTDIR variable, then creates a distribution tar file of the package
from the newly-built copy, and finally tries building from that tar file
a second time along with running various checks on the final result (see
the GNU Automake manual for further details).  It is advisable if you are
using GNU Autotools to ensure that "make distcheck" succeeds on the upstream
package before attempting to create a debianized version.  If the upstream
package fails a "make distcheck" with Autotools, it will probably have
issues on Debian.
[end insert]

Thanks,


Paul Hardy

Bug#878337: [Pkg-javascript-devel] Bug#878337: Remove the package?

[Paolo Greppi]

Il 31/07/2018 17:07, Julien Puydt ha scritto:
> Hi,
> 
> is there any hope for this package? At one point node-source-map will need to 
> be updated.
> 
> For now I have a RC bug on node-source-map to remind me not to update it too 
> fast, but it's a bit unfair : the problem doesn't stem from node-source-map 
> if node-grunt-contrib-concat is abandoned...
> 
> jpuydt on irc.debian.org

Development is abandoned, but it's actively used.
Stats from yarnpkg.com rate it in the top five downdloaded grunt-contrib-* 
modules:

grunt-contrib-watch: 1 M downloads in the last 30 days
grunt-contrib-clean 995.9 k
grunt-contrib-copy 958.5 k
grunt-contrib-uglify 870.3 k
grunt-contrib-concat 720.5 k
grunt-contrib-jshint 612 k
grunt-contrib-cssmin 560.5 k
grunt-contrib-less 373.1 k
...

Grunt itself is 2.1 M.

source-map is much more popular (79 M downloads in the last 30 days)

Paolo

Bug#903282: Bundling a potential 'home-end' debian package

[Boruch Baum]

On 2018-07-30 13:55, Nicholas D Steeves wrote:
> Dear Boruch,
>
> On Mon, Jul 30, 2018 at 01:14:20AM -0400, Boruch Baum wrote:
> >
> >   ref: https://github.com/melpa/melpa/pull/5594
> >
> > The method I used to re-write 'home-end' for MELPA was to first write a
> > small generic el that handles an arbitrary number of responses for an
> > arbitrary number of repeated key-presses for an arbitrary key (I'm
> > calling it 'keypress-multi-event'), and then have my version of
> > 'home-end' use that as its back-end.
> >
> > For the purpose of debian packaging, should those two files (each very
> > small, BTW) be packaged separately? Does debian want each small file to
> > be in a separate repository (eg., on github).
>
> They can be in the same repository, if the intent is for home-end.el
> and keypress-multi-event.el to always have equal versions and every
> update to one file necessitates upgrading both packages, because a tag
> stores the state of the branch.  Is that the intent?  Magit did it
> this way for a while.

I don't have a specific intent. From the programming design perspective
it makes sense to maintain them independently, but from the perspective
of a distribution, it would be piling on two more debian packages for a
very minor feature of a program. For a person not using either MELPA or
debian, it means an extra download / un-compress operation.

> If keypress-multi-event.el is a library that would be useful to most
> GNU Emacs users, then—ideally—a patch should be submitted to GNU
> Emacs.  I noticed that you're willing to assign © to the FSF, so maybe
> this is the plan?

No, but if they want it, they already know who I am, and I'm happy to
perform the assignment.

> > In the bigger picture, I question the 'efficiency' of administering
> > emacs packages this way. Debian is setting itself up for a tremendous
> > amount of work involving potentially hundreds of MELPA packages.
>
> One reason emacs-goodies-el is being broken up is to distribute the
> burden of maintenance of x packages between y volunteers, where
> previously it was 1 mega-package that no one had time to maintain. [3]

Huh? How does that math work? How do you auto-magically get those more
volunteers (rhetorical question, no need to answer in writing)?

>
> > Going through the use-cases and scenarios in my head, it doesn't
> > make sense to me that on the one hand debian is not restricting
> > individual user accounts from using MELPA (eg. by removing /
> > patching-out functions from package.el ), but on the other hand is
> > curating a MELPA subset that individual user accounts would
> > potentially be duplicating in their local user-space, with much
> > potential for version mis-matching.
>
> Dh-elpa protects against this.

  $ apt-cache show emacs25 |grep dh-elpa

I'm not getting an indication that debian is requiring / suggesting /
recommending the install of that package. Should I file that as a bug
against all emacsen? How?

I then thought that maybe the dependency should only be upon the class
of debian elpa-* packages, but performing the same check for elpa-org
likewise came up with nothing (BTW, isn't org-mode now packaged by fsf
itself as part of emacs, and installed by all debian emacs core
packages?).

>  eg: A user installs elpa-libfoo=1.0 and elpa-bar-mode=1.0;

tldr; (nothing personal, just not for now, for me).

> Finally, no one is going to do a copyright review for the entirety of
> MELPA.

Now that's a real policy issue to respect, if you aren't respecting
MELPA's own due diligence.

> Unmaintainable mega package that is impossible to QA as a whole.

Maintenance and QA of the mega-package is by upstream, as is the case
for emacs itself (the mother of all mega-packages - my latest head-slap
is 'M-x proc-ed' ...); why should debian be micro-managing individual
features / extensions of such mega-upstream-packages on an opt-in basis?
(another question for your consideration but don't need to respond here
in writing).

> > 2.3] On large enterprise debian installations (eg. universities), this
> > would save a lot of redundant bandwidth and storage, since all of MELPA
> > would already be local.
>
> "Every package" is a massive exploitable attack surface (and source of
> bugs)

... that already exists currently for the entire emacs community. Any
individual component would still need to be manually installed / loaded by
the individual user-account, but it would be a completely local
operation, not requiring a specific site-wide intervention of a sysadmin.

> and will slow down package upgrades

If I understand you correctly, quite the opposite. The semi-automatic
site-wide upgrading of debian by a sysadmin is going to be more current,
consistent, and reliable than that of each individual user-account
remembering to manually check and update their local MELPA downloads.

> and Emacs initialisation,

Ah, I wasn't clear. My intent was not to propose that debian have emacs
load all MELPA packages upon launching any 

Bug#905168: automysqlbackup: Two backups in "latest" on first of month

[Karsten Koop]

Package: automysqlbackup
Version: 2.6+debian.4-1
Severity: minor

Dear Maintainer,

on the first of a month, I see two files in the "latest" directory: One with a 
name like
.._2018-08-01_06h25m.August.smgr.sql.gz, and another with name like 
.._2018-08-01_06h25m.Mittwoch.sql.gz.
As I'm copying the latest backup off-site, this creates problems when there are 
more files than expected.


-- 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-7-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 automysqlbackup depends on:
ii  mailutils [mailx]   1:3.1.1-1
ii  mariadb-client-10.1 [virtual-mysql-client]  10.1.26-0+deb9u1

Versions of packages automysqlbackup recommends:
ii  mutt  1.7.2-1

automysqlbackup suggests no packages.

-- Configuration Files:
/etc/default/automysqlbackup changed:
DBHOST=localhost
DBNAMES=`mysql --defaults-file=/etc/mysql/debian.cnf --execute="SHOW DATABASES" 
| awk '{print $1}' | grep -v ^Database$ | grep -v ^mysql$ | grep -v 
^performance_schema$ | grep -v ^information_schema$ | tr \\\r\\\n ,\ `
BACKUPDIR="/var/lib/automysqlbackup"
MAILCONTENT="quiet"
MAXATTSIZE="4000"
MAILADDR="kk...@ld-didactic.de"
MDBNAMES="mysql $DBNAMES"
DBEXCLUDE=""
CREATE_DATABASE=yes
SEPDIR=yes
DOWEEKLY=6
COMP=gzip
COMMCOMP=no
LATEST=yes
MAX_ALLOWED_PACKET=
SOCKET=
POSTBACKUP="/etc/mysql-backup-post"
ROUTINES=yes


-- no debconf information

Bug#905163: lftp: CVE-2018-10916: Exploit in reverse mirror job deletes cwd on source

[Salvatore Bonaccorso]

Control: found -1 4.7.4-1

Hi Noel,

On Wed, Aug 01, 2018 at 05:46:55AM +0200, Salvatore Bonaccorso wrote:
> Source: lftp
> Version: 4.8.3-1
> Severity: grave
> Tags: patch security upstream
> Forwarded: https://github.com/lavv17/lftp/issues/452
> 
> Hi,
> 
> The following vulnerability was published for lftp, were in cse revers
> mirror option is used can lead on data loss on source.
> 
> CVE-2018-10916[0]:
> Exploit in reverse mirror job deletes cwd on source
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2018-10916
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10916
> [1] https://github.com/lavv17/lftp/issues/452
> [2] 
> https://github.com/lavv17/lftp/commit/a27e07d90a4608ceaf928b1babb27d4d803e1992
> 
> Please adjust the affected versions in the BTS as needed.

We marked it as no-dsa for stretch, but a fix would still be great as
well for stable. Could you prepare an update for next point release
for stretch?

Regards,
Salvatore

Bug#905169: golang-github-graph-gophers-graphql-go: Incomplete debian/copyright?

[Chris Lamb]

Source: golang-github-graph-gophers-graphql-go
Version: 0.0~git20180609.bb97385-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Sascha Steinbiss , 
ftpmas...@debian.org

Hi,

I just ACCEPTed golang-github-graph-gophers-graphql-go from NEW but 
noticed it was missing attribution in debian/copyright for at least 
internal/validation/testdata.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#704527: biber: Character "(" not allowed in key although valid in BiBTeX

[David Bremner]

control: tag -1 wontfix upstream

Harri Kiiskinen  writes:

> biber does not seem to accept the character "(" in a bibtex key. This
> is rather irritating, as the old bibtex did accept it along some other
> non-letter characters. This may of course be a conscious choice of the
> developers, but in any case it breaks the backwards compatibility of
> the databases (and for me, a lot of documents) and perhaps should be
> investigated. In older versions of biber there was an option to select
> a different type of parser, which in fact did circumvent the problem,
> but this option has obviously been removed.

I forwarded your request to the libbtparse maintainer [1]. Unfortunately
it looks like your problem will not be fixed in libbtparse.  I don't
know it's worth persuing upstream with biber or not. Maybe we could at
least ask biber to document their (inherited) incompatibility?

[1]: https://rt.cpan.org/Ticket/Display.html?id=125914

Bug#905017: LXDE: Frozen display issue

[Julien Puydt]

Hi,

Le 31/07/2018 à 17:53, Julien Puydt a écrit :

I'll have to check what happens when disabling extensions... but for now 
I have a long-running program, so I don't want to risk breaking my 
session : it will have to wait a little before I can do some tests.


I made some more tests following your advice : I'm unable to reproduce 
the problem :-(


On the one hand it means we could close the bug report... on the other 
hand, that means something wrong has managed to escape :-/


jpuydt on irc.debian.org

Bug#904774: stretch-pu: package sympa/6.2.16~dfsg-3+deb9u1

[Salvatore Bonaccorso]

Hi Adam,

On Sat, Jul 28, 2018 at 09:25:34AM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2018-07-27 at 20:20 +0200, Salvatore Bonaccorso wrote:
> > Sympa in stable is affected by 863631, where on every update of
> > sympa, the values reinjectend to sympa config file were false doe to
> > an issue in the shell function used to prefill the debconf questions.
> > 
> > This was earlier fixed for buster, but updates within stretch will
> > still have the problem.
> > 
> > Now, there is a security update planned for CVE-2018-1000550 and for
> > the above reason I would include the cherry picked fix for the above,
> > but would like to get an official ack, given it's not for the
> > security fix.
> 
> That looks fine to me, thanks.

Thanks!

Regards,
Salvatore

Bug#902582: (some kind of) transition: add python3.7 as a supported python3 version

[PICCA Frederic-Emmanuel]

Hello,

It seems that pyopengl is not tracked in the transition tracker.
But this package is affected by the python3.7 transition #903218.

Bug#905150: transition: libpqxx

[Marcin Kulisz]

Due to lack of Breaks+Replaces it will require additional upload with those
options added to fix #905146.

Please let me know if I should upload it or wait.

Tho as Bas mentioned earlier package version meant to trigger transition is
already in unstable (it will just need update) and sorry for uploading it
without filling transition request beforehand.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3

Bug#905153: autodep8: set Restrictions: allow-stderr on generated tests

[Rebecca N. Palmer]

On 01/08/18 02:58, Antonio Terceiro wrote:

FWIW, most of the supported package types do already set allow-stderr.
 From a quick look, of 4 of 9 explictly set allow-stderr, and 2 append
`2>/dev/null` to the Test-Command.


Those being dkms, go, octave, r (allow-stderr) and ruby (2>&1).  I don't 
see anything using 2>/dev/null for the test itself.


Is there a reason python isn't on that list?

Bug#904456: Update

[V V]

The problem is that the clang sanitizers are trying to use the
llvm-symbolizer exercutable (see
https://github.com/google/sanitizers/wiki/AddressSanitizerCallStack) to
show the symbols. This file is installed but it has the wrong when a non
default clang package is installed. For me when having installed clang-6.0
it is called `llvm-symbolizer-6.0`.
The linked wiki page details that users can use the ASAN_SYMBOLIZER_PATH
environment variable to set the path for the symbolizer but it looks like
the executable still has to have the exact name because clang refuses to
use llvm-symbolizer-6.0. My solution was to link llvm-symbolizer to
llvm-symbolizer-6.0.
The problem is also present in debian stable.

Bug#711757: Wired connection, static IP profile: immediately disconnects

[Jan Korbel]

Hello.

Same here, after more than 5 years... But for me, one second is too
little - changed to 3s and it works now.

Thanks for report.

jackc:~# diff /root/monitor.py /usr/share/wicd/daemon/monitor.py
139a140
> time.sleep(3)


wicd 1.7.4+tb2-6
Debian unstable
without systemd
xfce

J.

Bug#905169: golang-github-graph-gophers-graphql-go: Incomplete debian/copyright?

[Sascha Steinbiss]

Hi Chris,

> I just ACCEPTed golang-github-graph-gophers-graphql-go from NEW but 
> noticed it was missing attribution in debian/copyright for at least 
> internal/validation/testdata.
> 
> This is in no way exhaustive so please check over the entire package 
> carefully and address these on your next upload.

Thanks for taking a close look that quickly. Sure enough, I will address
this issue asap.

Have a nice DebConf!

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#905151: [Debian-ha-maintainers] Bug#905151: ocfs2-tools: small DEP8 change to avoid broken pipe error

[Valentin Vidic]

On Tue, Jul 31, 2018 at 06:25:10PM -0300, Andreas Hasenack wrote:
> at some point we in Ubuntu started having an error with the
> ocfs2-tools test that happened in the "basic" test when running
> fsck.ocfs2 in the image file. The error was about a broken pipe. I
> can't find a link to an example right now, I'm afraid.
> 
> We then changed that line from this:
> yes | fsck.ocfs2 -f -y -F $DISK 2>&1
> 
> to this:
> echo yes | fsck.ocfs2 -f -y -F $DISK 2>&1
> 
> And that immediately got rid of the problem. We believe that "yes" was
> "too insistent" and was writing to the pipe after it was closed, or
> something like that.
> 
> The broken pipe error was never seen in debian's ci for this package,
> as far as I know, but we would kindly ask you to consider this change
> to the debian package. At the moment, this is the only delta this
> package in Ubuntu has with Debian, and it may make this test more
> robust.

Thanks for reporting the problem, will include this fix in the next
package release.

-- 
Valentin

Bug#905173: [installation-guide] Document EFI firmware as successor of BIOS

[Holger Wansing]

Package: installation-guide
Severity: normal


Please update the guide on information about EFI firmware.
Currently, the guide only talks about BIOS.



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#897724: collectd: ftbfs with GCC-8

[Niko Tyni]

On Fri, May 04, 2018 at 12:21:07PM +, Matthias Klose wrote:
> Package: src:collectd
> Version: 5.8.0-4
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-8

> src/aggregation.c: In function 'agg_lookup_class_callback':
> src/aggregation.c:204:20: error: '%s' directive output may be truncated 
> writing 14 bytes into a region of size between 0 and 127 
> [-Werror=format-truncation=]
> "%s-%s", tmp_plugin, AGG_FUNC_PLACEHOLDER);

> cc1: all warnings being treated as errors

Dear maintainers,

this is one of the few remaining blockers for the Perl 5.28 transition.

I've forwarded the issue upstream at
  https://github.com/collectd/collectd/issues/2883

I see Fedora is configuring with --disable-werror, so these warnings
does not cause a build failure there. Would you consider doing that
until a solution is implemented upstream?

Thanks for your work on Debian,
-- 
Niko Tyni   nt...@debian.org

Bug#905170: PrivateTmp causing issues again

[Christian Ehrhardt]

Package: open-vm-tools
Version: 2:10.2.0-3

Hi,
I'll start with a try to map all related bugs as it is confusing enough
already.

I had reported [DEB-1] in the past which was based on [UBU-1], but then
realized there was [DEB-2]. So we closed [DEB-1] and continued in [DEB-1].
The TL;DR there as well as in [UBU-1] looking forward was that there is no
issue with newer systemd's anymore and releases having older systemd might
need the fix discussed there.

But there also is/was [UBU-2] which is actually a different issue.
I myself did mix it up as removing PrivateTmp was a solution there as well
:-/

But it is a different issue, the TL;DR on it is that due to PrivateTmp=yes
one can no more drive code execution trough VMOMI API that needs tmp.

The suggestion came by Olvier Kurth (open-vm-tools upstream) to drop
PrivateTmp from the systemd service file. This was also later verified and
considered ok by VMware testing people - you can see that part of the
history in [UBU-1].

The TL;DR for you is - would you consider dropping PrivateTmp to eliminate
this issue from Debian as well?

[DEB-1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891071
[DEB-2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888955
[UBU-1]:
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1750780
[UBU-2]:
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1758428

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#905171: Subject: network-manager: Network-manager will not connect to known wifi networks "no secrets provided"

[Jon Westgate]

Package: network-manager
Version: 1.12.2-1
Severity: important

Dear Maintainer,

Since upgrading from NM version 1.10.x I've noticed that it is getting 
increasingly hard to connect to wifi networks.
With version 1.11.x you couldn't switch networks without first 
disconnecting. That was not ideal but I could deal with it.
Version 1.12.x is just unusable it just tells me "No secrets provided" 
and or "No Agents were available for this request"
I'm running KDE so using the plasma UI. If I just downgrade to 1.10.x 
everything just works again wifi automaticly connects as soon as dpkg 
has finished.
Is there something silly that needs doing like purging settings that 
will fix this? The annoying thing about downgrading is that it means I 
can't use PPP and therefore

most VPN's are unavailable to me.

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

Kernel: Linux 4.17.11 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB (charmap=UTF-8)

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

Versions of packages network-manager depends on:
ii  adduser    3.117
ii  dbus   1.12.8-3
ii  libaudit1  1:2.8.3-1+b1
ii  libbluetooth3  5.50-1
ii  libc6  2.27-5
ii  libcurl3-gnutls    7.60.0-2
ii  libglib2.0-0   2.56.1-2
ii  libgnutls30    3.5.19-1
ii  libjansson4    2.11-1
ii  libmm-glib0    1.7.990-1
ii  libndp0    1.6-1+b1
ii  libnewt0.52    0.52.20-5
ii  libnm0 1.12.2-1
ii  libpam-systemd 239-7
ii  libpolkit-agent-1-0    0.105-21
ii  libpolkit-gobject-1-0  0.105-21
ii  libpsl5    0.20.2-1
ii  libreadline7   7.0-5
ii  libselinux1    2.8-1+b1
ii  libsystemd0    239-7
ii  libteamdctl0   1.27-1
ii  libudev1   239-7
ii  libuuid1   2.32-0.3
ii  lsb-base   9.20170808
ii  policykit-1    0.105-21
ii  udev   239-7
ii  wpasupplicant  2:2.6-17

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.79-1
ii  iptables 1.6.2-1
ii  isc-dhcp-client  4.3.5-4+b1
ii  modemmanager 1.7.990-1
pn  ppp  

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#535033: route to remote using net_gateway fails for p2p links

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Martin

thank you for spending your time helping to make Debian better with
this bug report.

You file this bug against a currently not longer supported release. 
 
So I close this more then 9 years old bug. If the bug still exists
please file a new bug from a supported release.

CU 
Jörg
- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlthVBsACgkQCfifPIyh
0l1WJA//d6ZAJ6MkE+HU9FSzx/OlUrz6R8h5k2vaZC2eAFTfmoYY3Pred2fInvJV
EazIqDd9qmHdCja6qwxe6cbN3UfDAilSyxeibOhSHOopUaA4JjiXiOryMm7o0+pI
hnzgmhpoGH02KpnVxdHQ7cTO7c20lMruozejF5SpZ03Z29IHYlM5OxeDs9IIpr45
RkoPkOsRDWWBdd1inrmjUMwCVX90D+PG7W6gP348dHZl3Q9bIx05q0iuaOT83/WB
bnUiU2ElVwEJAbsQ4Pf8MOJJDTtcGs+SqVLf8DQuc+2vu3o3YkdGoXgDP3IUMoGh
CtpWjIa7DRPTzpTh0EZC29JiLVeFL8SOpXpXdkHAV0pjmXt9lytfgGpZ56oGoOsr
p2X3reHJ1mnfLNRqyeuaTcNQx9OTHL1oDRbWaXeXulz1FtRPocOstUZe7ZTWsdw6
8GahKDZxyLGz/6YrXLzZbGCK3HncRHSGVfN5LOdE1muGg7CXEsuOMxoc0fi5mFvp
tSQDLADrER1p7mCefWsbGjsblJmJJyNP5UEcfmUpZApv/FBRqk45SAV6aJShO1Gz
Kzj74n+2Kh1/LEsQzWnQOEfHqc3LEHCyQ4X/LuVKe6RK9EC1/if/urvB1RSnBlWL
9h2H9Yd0XK3IhiBWYSfFZo0XqlAkRJipk8aaCBNoK4ijLiNLT/Q=
=guEp
-END PGP SIGNATURE-

Bug#905172: RM: squid3 -- RoQA; renamed to src:squid

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the obsolete source package squid3 from sid.
Except for the dropped -dbg package, everything is now built from
src:squid.


Andreas

Bug#905174: ITP: ufonormalizer -- Normalize XML and other data inside Unified Font Object files

[魏銘廷]

Package: wnpp
Severity: wishlist
Owner: Yao Wei (魏銘廷) 

* Package name: ufonormalizer
  Version : 0.3.5
  Upstream Author : Tal Leming
* URL : https://github.com/unified-font-object/ufoNormalizer
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Normalize XML and other data inside UFO

This utility normalizes XML and other files inside United Fonts Object,
to avoid differences due to spacing, reordering of keys, etc.

This package is the new dependency of glyphslib since 3.0.0.

This package should be maintained under Debian Fonts Task Force, and I
would need someone for sponsor upload.

Yao Wei


signature.asc
Description: PGP signature

Bug#905178: apt-cacher: prompting due to modified conffiles which were not modified by the user: /etc/default/apt-cacher

[Andreas Beckmann]

Package: apt-cacher
Version: 1.7.18
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up apt-cacher (1.7.18) ...
  Installing new version of config file /etc/apt-cacher/apt-cacher.conf ...
  
  Configuration file '/etc/default/apt-cacher'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** apt-cacher (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
apt-cacher (--configure):
   end of file on stdin at conffile prompt
  Processing triggers for libc-bin (2.27-5) ...
  Processing triggers for ca-certificates (20170717) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   apt-cacher


cheers,

Andreas


apt-cacher_1.7.18.log.gz
Description: application/gzip

Bug#889989: openvpn host route not restored after suspend-to-ram on systems using systemd

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

tags 889989 + moreinfo
thanks


Hello Alex,

thank you for spending your time helping to make Debian better with
this bug report.


Please can you modify your openvpn.service from

 * After=network.target
 * WantedBy=multi-user.target

to

 * After=network.target suspend.target
 * WantedBy=multi-user.target sleep.target

and check it again.

Many thanks!


CU
Jörg

- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlthlYYACgkQCfifPIyh
0l32RA//dSmuKU4S+6ybS3pCl/UvCMDSeFUhMh8m9MvW4QTo5WX476r2ndi/7+gG
GBG3rlRX4nZuWZSW8FmSK2iORpQySgH1ujnL99R3ZPVq/LXtHPkyBpud7yCpzPsW
HGA+0pF8e130laQXXtWeEix8wT7IV9M4Rj0tGu6ijkRgKAiVzOy1YYrIapjs30Ln
PLHzd4RTAbf+8v1p8yzk/8vLZ6ShOWSf2I+NZ8qoOSSjlKkrKYYMqF+h7+RP1AUX
G8/NyHc/5IpEQsGmtGDgfKWk+pLpCZsHbjys1P13i5Rcw8vV9vFseEUWKFO+mWYT
6FSPWveE37TEf0cS9hukLiDT6uw1vkDaykIm5IZtlIrZi9pT2T6Uj6FT/dAdVYzN
DCtGKoPbi/jqeXKGC8/klNagUcG46/fnYq5nuqVkfZw8pkm+bXLKToZ7q6WBUAS6
zQyl1ymy7aolhPsx+claNEPD7ovk9x0aITb1xaI1oUimuoNn1t//rXmPONr3ZHfj
v9l+n9yYEHnKtBLgVb+nbdexnSRS/zhEhcNjJ7xI4C58fIVwSJqkPV0Quh8LcWjh
Ph2xFUdaRbXPWTh9aItWwfkH5X6PjJKYGX9oAETQ88J4KBzqFae7JdIOgVO16NJ2
W5Vg0GNw1oJkcajAnEYHnUaXZkbHLVo9BcrIQ/IS8IDE5bVCFl8=
=wHBb
-END PGP SIGNATURE-

Bug#905171: [Pkg-utopia-maintainers] Bug#905171: Subject: network-manager: Network-manager will not connect to known wifi networks "no secrets provided"

[Michael Biebl]

Control: tags -1 moreinfo

Am 01.08.2018 um 08:57 schrieb Jon Westgate:
> Package: network-manager
> Version: 1.12.2-1
> Severity: important
> 
> Dear Maintainer,
> 
> Since upgrading from NM version 1.10.x I've noticed that it is getting
> increasingly hard to connect to wifi networks.
> With version 1.11.x you couldn't switch networks without first
> disconnecting. That was not ideal but I could deal with it.
> Version 1.12.x is just unusable it just tells me "No secrets provided"
> and or "No Agents were available for this request"
> I'm running KDE so using the plasma UI. If I just downgrade to 1.10.x
> everything just works again wifi automaticly connects as soon as dpkg
> has finished.
> Is there something silly that needs doing like purging settings that
> will fix this? The annoying thing about downgrading is that it means I
> can't use PPP and therefore
> most VPN's are unavailable to me.

Secrects are typically provided by a desktop component. In your case plasma.

Can you try with a minimal desktop environment and network-manager-gnome
(nm-applet) if the problem is reproducible there?
If not, this should probably be reassigned to the plasma desktop (not
sure which component exactly is responsible there for NM support)

An (temporary) workaround might be to store the wifi password system
wide. You can use nm-connection-editor.
In the WiFi Security tab, choose the option "Store the password for all
users"



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



signature.asc
Description: OpenPGP digital signature

Bug#905176: ganeti: fails to upgrade from 'stretch': removal of ganeti-{haskell,htools}-2.15 fails

[Andreas Beckmann]

Package: ganeti
Version: 2.16.0~rc2-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package ganeti-2.16.
  Preparing to unpack .../48-ganeti-2.16_2.16.0~rc2-4_all.deb ...
  Unpacking ganeti-2.16 (2.16.0~rc2-4) ...
  Preparing to unpack .../49-ganeti_2.16.0~rc2-4_all.deb ...
  Unpacking ganeti (2.16.0~rc2-4) over (2.15.2-7+deb9u2) ...
  (Reading database ... 
(Reading database ... 7847 files and directories currently installed.)
  Removing ganeti-htools-2.15 (2.15.2-7+deb9u2) ...
  dpkg: error processing package ganeti-htools-2.15 (--remove):
   installed ganeti-htools-2.15 package pre-removal script subprocess returned 
error exit status 30
  Removing ganeti-haskell-2.15 (2.15.2-7+deb9u2) ...
  dpkg: error processing package ganeti-haskell-2.15 (--remove):
   installed ganeti-haskell-2.15 package pre-removal script subprocess returned 
error exit status 30
  dpkg: libcurl3:amd64: dependency problems, but removing anyway as you 
requested:
   ganeti-htools-2.15 depends on libcurl3 (>= 7.16.2).
   ganeti-haskell-2.15 depends on libcurl3 (>= 7.16.2).
  
  Removing libcurl3:amd64 (7.52.1-5+deb9u6) ...
  Errors were encountered while processing:
   ganeti-htools-2.15
   ganeti-haskell-2.15


cheers,

Andreas


ganeti_2.16.0~rc2-4.log.gz
Description: application/gzip

Bug#905177: bind9: prompting due to modified conffiles which were not modified by the user: /etc/bind/named.conf.options

[Andreas Beckmann]

Package: bind9
Version: 1:9.11.4+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up bind9 (1:9.11.4+dfsg-2) ...
  Installing new version of config file /etc/apparmor.d/usr.sbin.named ...
  Installing new version of config file /etc/bind/bind.keys ...
  
  Configuration file '/etc/bind/named.conf.options'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** named.conf.options (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing 
package bind9 (--configure):
   end of file on stdin at conffile prompt
  Processing triggers for libc-bin (2.27-5) ...
  Errors were encountered while processing:
   bind9


cheers,

Andreas


bind9_1:9.11.4+dfsg-2.log.gz
Description: application/gzip

Bug#905181: bbdb: Fail to install with emacs-common 1:25.2+1-8

[Christian Marillat]

Package: bbdb
Version: 2.36-4.1
Severity: normal

Dear Maintainer,

$ sudo dpkg-reconfigure bbdb
ERROR: bbdb is broken - called emacs-package-remove as a new-style add-on, but 
has no compat file.
Remove bbdb for emacs
remove/bbdb: Ignoring Flavor emacs ...
ERROR: bbdb is broken - called emacs-package-install as a new-style add-on, but 
has no compat file.
Install bbdb for emacs
install/bbdb: Ignoring Flavor emacs ...
Install bbdb for emacs
install/bbdb: Ignoring Flavor emacs ...


And when loaded from ~/.emcas with :

(load "~/.emacs.d/init-bbdb.el")


bbdb fail to start

Warning (initialization): An error occurred while loading 
‘/home/marillat/.emacs’:

File error: Cannot open load file, Aucun fichier ou dossier de ce type, 
bbdb-autoloads

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace.


Christian

Versions of packages bbdb depends on:
ii  emacs-gtk [emacsen]  1:25.2+1-8
ii  emacs25  1:25.2+1-8
ii  make 4.2.1-1.1
ii  perl 5.26.2-6

bbdb recommends no packages.

Versions of packages bbdb suggests:
pn  gnus | t-gnus  
pn  gnuserv
ii  perl   5.26.2-6
pn  vm 
pn  w3m-el 

-- no debconf information

Bug#905180: libmoe-dev: missing Breaks+Replaces: libmoe1.5 (<< 1.5.8-3)

[Andreas Beckmann]

Package: libmoe-dev
Version: 1.5.8-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Unpacking libmoe-dev (1.5.8-3) over (1.5.8-2+b1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libmoe-dev_1.5.8-3_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/libmoe.so', which is also in package libmoe1.5 
1.5.8-2+b1
  Preparing to unpack .../libmoe1.5_1.5.8-3_amd64.deb ...
  Unpacking libmoe1.5 (1.5.8-3) over (1.5.8-2+b1) ...
  Preparing to unpack .../multiarch-support_2.27-5_amd64.deb ...
  Unpacking multiarch-support (2.27-5) over (2.24-11+deb9u3) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/libmoe-dev_1.5.8-3_amd64.deb


cheers,

Andreas


libmoe-dev_1.5.8-3.log.gz
Description: application/gzip

Bug#905183: openstack-dashboard: dependency problems upgrading from stretch to buster

[Andreas Beckmann]

Package: openstack-dashboard
Version: 3:13.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

>From the attached log (scroll to the bottom...):

  Starting 2 pkgProblemResolver with broken count: 1
  Investigating (0) python3-django-horizon:amd64 < none -> 3:13.0.1-1 @un uN Ib 
>
  Broken python3-django-horizon:amd64 Conflicts on 
python-django-openstack-auth:amd64 < 2.4.1-2 -> 3.5.0-2 @ii umU >
Considering python-django-openstack-auth:amd64 0 as a solution to 
python3-django-horizon:amd64 0
Holding Back python3-django-horizon:amd64 rather than change 
python-django-openstack-auth:amd64
  Investigating (1) openstack-dashboard:amd64 < 3:10.0.1-1 -> 3:13.0.1-1 @ii 
umU Ib >
  Broken openstack-dashboard:amd64 Depends on python3-django-horizon:amd64 < 
none | 3:13.0.1-1 @un uH > (= 3:13.0.1-1)
Considering python3-django-horizon:amd64 0 as a solution to 
openstack-dashboard:amd64 0
Holding Back openstack-dashboard:amd64 rather than change 
python3-django-horizon:amd64
  Investigating (2) python-django:amd64 < 1:1.10.7-2+deb9u1 -> 1:1.11.14-1 @ii 
umU Ib >
  Broken python-django:amd64 Breaks on openstack-dashboard:amd64 < 3:10.0.1-1 | 
3:13.0.1-1 @ii umH > (< 3:12)
Considering openstack-dashboard:amd64 0 as a solution to 
python-django:amd64 11
Upgrading openstack-dashboard:amd64 due to Breaks field in 
python-django:amd64
  Investigating (2) openstack-dashboard:amd64 < 3:10.0.1-1 -> 3:13.0.1-1 @ii 
umU Ib >
  Broken openstack-dashboard:amd64 Depends on python3-django-horizon:amd64 < 
none | 3:13.0.1-1 @un uH > (= 3:13.0.1-1)
Considering python3-django-horizon:amd64 0 as a solution to 
openstack-dashboard:amd64 0
Holding Back openstack-dashboard:amd64 rather than change 
python3-django-horizon:amd64
  Investigating (3) python-django:amd64 < 1:1.10.7-2+deb9u1 -> 1:1.11.14-1 @ii 
umU Ib >
  Broken python-django:amd64 Breaks on openstack-dashboard:amd64 < 3:10.0.1-1 | 
3:13.0.1-1 @ii umH > (< 3:12)
Considering openstack-dashboard:amd64 0 as a solution to 
python-django:amd64 11
Upgrading openstack-dashboard:amd64 due to Breaks field in 
python-django:amd64
  Investigating (3) openstack-dashboard:amd64 < 3:10.0.1-1 -> 3:13.0.1-1 @ii 
umU Ib >
  Broken openstack-dashboard:amd64 Depends on python3-django-horizon:amd64 < 
none | 3:13.0.1-1 @un uH > (= 3:13.0.1-1)
Considering python3-django-horizon:amd64 0 as a solution to 
openstack-dashboard:amd64 0
Holding Back openstack-dashboard:amd64 rather than change 
python3-django-horizon:amd64
...
  Investigating (9) python-django:amd64 < 1:1.10.7-2+deb9u1 -> 1:1.11.14-1 @ii 
umU Ib >
  Broken python-django:amd64 Breaks on openstack-dashboard:amd64 < 3:10.0.1-1 | 
3:13.0.1-1 @ii umH > (< 3:12)
Considering openstack-dashboard:amd64 0 as a solution to 
python-django:amd64 11
Upgrading openstack-dashboard:amd64 due to Breaks field in 
python-django:amd64
  Investigating (9) openstack-dashboard:amd64 < 3:10.0.1-1 -> 3:13.0.1-1 @ii 
umU Ib >
  Broken openstack-dashboard:amd64 Depends on python3-django-horizon:amd64 < 
none | 3:13.0.1-1 @un uH > (= 3:13.0.1-1)
Considering python3-django-horizon:amd64 0 as a solution to 
openstack-dashboard:amd64 0
Holding Back openstack-dashboard:amd64 rather than change 
python3-django-horizon:amd64
  Done
  
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   fonts-roboto-fontface : Breaks: openstack-dashboard (< 3:12) but 3:10.0.1-1 
is to be installed
   python-django : Breaks: openstack-dashboard (< 3:12) but 3:10.0.1-1 is to be 
installed
  E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.


The problem seems to come from the conflict against
python-django-openstack-auth, but that package is still available
in buster and therefore apt is quite reluctant to remove a package
that is not obsolete, but upgradable.

cheers,


Andreas


openstack-dashboard_3:13.0.1-1.log.gz
Description: application/gzip

Bug#905182: zhcon-data,zhcon: Missing Breaks + Replaces causes error on upgrade

[Boyuan Yang]

Package: zhcon
Severity: serious
Version: 1:0.2.6-13
X-Debbugs-CC: f...@debian.org
Justification: File conflict

正在选中未选择的软件包 zhcon-data。
正准备解包 .../4-zhcon-data_1%3a0.2.6-13_all.deb  ...
正在解包 zhcon-data (1:0.2.6-13) ...
dpkg: 处理归档 /tmp/apt-dpkg-install-FgGkRR/4-zhcon-data_1%3a0.2.6-13_all.deb
(--unpack)时出错：
 正试图覆盖 /usr/share/zhcon/font/asc12.bpsf，它同时被包含于软件包 zhcon 1:0.2.6-12
dpkg-deb: 错误: 粘贴 subprocess was killed by signal (断开的管道)
正准备解包 .../5-zhcon_1%3a0.2.6-13_amd64.deb  ...
正在将 zhcon (1:0.2.6-13) 解包到 (1:0.2.6-12) 上 ...
在处理时有错误发生：
 /tmp/apt-dpkg-install-FgGkRR/4-zhcon-data_1%3a0.2.6-13_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

--
Regards,
Boyuan Yang

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

[YunQiang Su]

Index: rustc-1.27.1+dfsg1/src/bootstrap/bootstrap.py
===
--- rustc-1.27.1+dfsg1.orig/src/bootstrap/bootstrap.py
+++ rustc-1.27.1+dfsg1/src/bootstrap/bootstrap.py
@@ -591,6 +591,8 @@ class RustBuild(object):
 (os.pathsep + env["LIBRARY_PATH"]) \
 if "LIBRARY_PATH" in env else ""
 env["RUSTFLAGS"] = "-Cdebuginfo=2"
+if self.build_triple().startswith('mips'):
+env["RUSTFLAGS"] += " -Cllvm-args=-mxgot"
 env["PATH"] = os.path.join(self.bin_root(), "bin") + \
 os.pathsep + env["PATH"]
 if not os.path.isfile(self.cargo()):


This patch should work.
And I pasted it on the upstream github.
YunQiang Su  于2018年7月24日周二 上午9:04写道：
>
> 1.27.1+dfsg1-1~exp4 still FTBFS.
> As rustc seems need big got.
>
> --- a/src/bootstrap/bootstrap.py
> +++ b/src/bootstrap/bootstrap.py
> @@ -590,7 +590,7 @@
>  env["LIBRARY_PATH"] = os.path.join(self.bin_root(), "lib") + \
>  (os.pathsep + env["LIBRARY_PATH"]) \
>  if "LIBRARY_PATH" in env else ""
> -env["RUSTFLAGS"] = "-Cdebuginfo=2"
> +env["RUSTFLAGS"] = "-Cdebuginfo=2 -Cllvm-args=-mxgot"
>  env["PATH"] = os.path.join(self.bin_root(), "bin") + \
>  os.pathsep + env["PATH"]
>  if not os.path.isfile(self.cargo()):
> --- a/src/vendor/cc/src/lib.rs
> +++ b/src/vendor/cc/src/lib.rs
> @@ -1106,6 +1106,8 @@
>  cmd.args.push("-mx32".into());
>  } else if target.contains("x86_64") ||
> target.contains("powerpc64") {
>  cmd.args.push("-m64".into());
> +} else if target.contains("mips") {
> +cmd.args.push("-mxgot".into());
>  }
>
>  if self.static_flag.is_none() {
> John Paul Adrian Glaubitz  于2018年7月20日周五
> 下午11:30写道：
> >
> > Blacklisting doesn’t fix the transition block.
> >
> > Once the package is outdated on any of the release architectures, 
> > transition is blocked.
> >
> > > On Jul 20, 2018, at 5:15 PM, YunQiang Su  wrote:
> > >
> > > On Tue, 17 Jul 2018 18:10:14 +0200 John Paul Adrian Glaubitz
> > >  wrote:
> > >> On 07/17/2018 06:03 PM, Ximin Luo wrote:
> > >>> Aron, the next version 1.27.1 is already in binary-NEW so the same 
> > >>> issue will block testing migration again, when that gets accepted.
> > >>
> > >> Well, I have to partially take my criticism back. Aron has pointed out 
> > >> on IRC
> > >> that rustc was not yet removed for mips64el, I thought that had happened 
> > >> but
> > >> indeed that wasn't the case, just cargo was removed.
> > >>
> > >> So, his upload didn't really change anything in this regard.
> > >>
> > >>> Earlier you said "Binary only upload from porter is allowed [..]" but I 
> > >>> am not sure the other porters have access to a loongson-3a box. Will 
> > >>> you continue to run builds of new rustc versions on your box? I think 
> > >>> that is the key point here.
> > >>
> > >> DSA could blacklist rustc from being built on buildds other than eberlin
> > >> but I assume they won't agree to applying such a hack.
> > >
> > > I have asked Aurelien to blacklist rustc.
> > > @Aurelien, oh the rustc problem is not about `make', it is about llvm.
> > >
> > >>
> > >> 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
> > >>
> > >>
> > >
> > > ___
> > > Pkg-rust-maintainers mailing list
> > > pkg-rust-maintain...@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> >
>
>
> --
> YunQiang Su



-- 
YunQiang Su

Bug#905186: uim-qt5-immodule: missing Breaks+Replaces: uim-qt5 (<< 1:1.8.6+gh20161003.0.d63dadd-5~exp1)

[Andreas Beckmann]

Package: uim-qt5-immodule
Version: 1:1.8.8-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package uim-qt5-immodule:amd64.
  Preparing to unpack .../32-uim-qt5-immodule_1%3a1.8.8-2_amd64.deb ...
  Unpacking uim-qt5-immodule:amd64 (1:1.8.8-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-sqVbwc/32-uim-qt5-immodule_1%3a1.8.8-2_amd64.deb 
(--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so',
 which is also in package uim-qt5 1:1.8.6+gh20161003.0.d63dadd-2
  Preparing to unpack .../33-uim-qt5_1%3a1.8.8-2_amd64.deb ...
  Unpacking uim-qt5 (1:1.8.8-2) over (1:1.8.6+gh20161003.0.d63dadd-2) ...

The other *-immodule packages might have similar problems.


cheers,

Andreas


task-japanese-desktop_3.44.log.gz
Description: application/gzip

Bug#902826: Fixed in latest upload

[Julien Puydt]

Control: fixed -1 6.0.1-5

Hi,

according to the buildd's logs, there is no problem building on i386 
anymore.


Thanks,

jpuydt on irc.debian.org

Bug#905175: fsdialog: doesn't get auto indexed

[Andrej Shadura]

Package: tk-fsdialog
Version: 1.15+20140601-1
Severity: important

The package only provides tclIndex, which has to be on auto_path to be
loaded, which it isn't, and since there's no pkgIndex.tcl, it is not
possible to [package require] this package.

Bug#904949: [Pkg-electronics-devel] Bug#904949: geda package disappeared from your system

[Niels Thykier]

reassign 904949 geda
thanks

On Mon, 30 Jul 2018 09:02:31 +0200
=?utf-8?B?2KPYrdmF2K8g2KfZhNmF2K3ZhdmI2K/Zig==?=
 wrote:
> reassign debhelper
> quit
> 
> For some reason:
> dh_installdocs -pgeda -pgeda-doc --link-doc=geda-doc
> 
> installs the docs in geda-doc package indeed, but in usr/share/doc/geda 
> instead of usr/share/doc/geda-doc !
> 
> -- 
> ‎أحمد المحمودي (Ahmed El-Mahmoudy)
>  Digital design engineer
> GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
> GPG Fingerprints:
>  6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
>  8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7

Hi,

This is an intentional change in debhelper when you upgrade to compat 11
prompted by a Debian policy change.

>-   The dh_installdocs and dh_installexamples tools may now 
> install most of the documentation in a different path to
>comply with the recommendation from Debian policy §12.3 
> (since version 3.9.7).
> 
>Note that if a given source package only contains a single 
> binary package in debian/control or none of the
>packages are -doc packages, then this change is not 
> relevant for that source package and you can skip to the
>next change.
> 
>By default, these tools will now attempt to determine a 
> "main package for the documentation" (called a doc-main-
>package from here on) for every -doc package.  If they 
> find such a doc-main-package, they will now install the
>documentation into the path 
> /usr/share/doc/doc-main-package in the given doc package.  I.e. the path can 
> change
>but the documentation is still shipped in the -doc package.
> 
>The --doc-main-package option can be used when the 
> auto-detection is insufficient or to reset the path to its
>previous value if there is a reason to diverge from Debian 
> policy recommendation.
> 
>Some documentation will not be affected by this change.  
> These exceptions include the copyright file, changelog
>files, README.Debian, etc.  These files will still be 
> installed in the path /usr/share/doc/package.
>
Thanks,
~Niels

Bug#905179: apticron: prompting due to modified conffiles which were not modified by the user: /etc/apticron/apticron.conf

[Andreas Beckmann]

Package: apticron
Version: 1.2.0
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up apticron (1.2.0) ...
  
  Configuration file '/etc/apticron/apticron.conf'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** apticron.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
apticron (--configure):
   end of file on stdin at conffile prompt
  Setting up libgssapi-krb5-2:amd64 (1.16-2) ...
  Processing triggers for libc-bin (2.27-5) ...
  Errors were encountered while processing:
   apticron


cheers,

Andreas


apticron_1.2.0.log.gz
Description: application/gzip

Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc

[Jan Kowalsky]

Package: 389-ds-base
Version: 1.3.5.17-2
Severity: serious

Upgrade to newer version of 389-ds-base fails with dpkg configuration
error on postinstall script /var/lib/dpkg/info/389-ds-base.postinst

After getting full log of postinstall I saw:

[18/08/01:10:33:37] - [Setup] Info Could not rename config file
'/etc/dirsrv/slapd-INSTANCE/slapd-collations.conf' to
'/var/lib/dirsrv/slapd-INSTANCE/bak.bak/slapd-collations.conf'.  Error:
Invalid cross-device link

This is caused by line 24:

setup-ds -l $OUT -u -s General.UpdateMode=offline > $OUT 2>&1

calling this directly we got the same failure.

The reason is that the script tries to make a backup of configuration
files in /var/lib/dirsrv/INSTANCE/bak.bak:


# these files are obsolete, or we want to replace
# them with newer versions
my @toremove = qw(slapd-collations.conf);

# make a backup directory to store the deleted config file, then
# don't really delete it, just move it to that directory
my $mode = (stat($inf->{slapd}->{config_dir}))[2];
my $bakdir = $inf->{slapd}->{bak_dir} . ".bak";
if (! -d $bakdir) {
$! = 0; # clear
mkdir $bakdir, $mode;
if ($!) {
return ('error_creating_directory', $bakdir, $!);
}
}

my @errs;
for my $file (@toremove) {
my $oldname = $inf->{slapd}->{config_dir} . "/" . $file;
next if (! -f $oldname); # does not exist - skip - already (re)moved
my $newname = "$bakdir/$file";
$! = 0; # clear
rename $oldname, $newname;
if ($!) {
push @errs, ["error_renaming_config", $oldname, $newname, $!];
}
}


According to
https://www.unix.com/shell-programming-and-scripting/27747-perl-rename-failed.html
the perl rename call can cause this error.

My workaround was to create the directories in /etc and make symlinks in
/var/lib/dirsrv/...

  mkdir /etc/dirsrv/slapd-INSTANCE/bak
  ln -s /etc/dirsrv/slapd-INSTANCE/bak /var/lib/dirsrv/slapd-INSTANCE/bak
  mkdir /etc/dirsrv/slapd-INSTANCE/bak.bak
  ln -s /etc/dirsrv/slapd-INSTANCE/bak.bak
/var/lib/dirsrv/slapd-INSTANCE/bak.bak


Upgrade succeeded now.

I originally encountered this problem while upgrading 389-ds-base on
jessie from 1.3.3.5-4 to 1.3.3.5-4+deb8u1. Since upgrade scripts didn't
change this should be still valid for the actual version.

Bug#905185: libreoffice-help-common: missing Breaks+Replaces: libreoffice-common (<< 1:6.1.0~alpha1-1)

[Andreas Beckmann]

Package: libreoffice-help-common
Version: 1:6.1.0~rc2-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libreoffice-help-common.
  Preparing to unpack .../02-libreoffice-help-common_1%3a6.1.0~rc2-3_all.deb ...
  Unpacking libreoffice-help-common (1:6.1.0~rc2-3) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-a0UQpU/02-libreoffice-help-common_1%3a6.1.0~rc2-3_all.deb 
(--unpack):
   trying to overwrite '/usr/share/libreoffice/help/idxcaption.xsl', which is 
also in package libreoffice-common 1:5.2.7-1+deb9u4
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

If I parsed the changelog correctly, libreoffice-help-common was
added in 1:6.1.0~alpha1-1


cheers,

Andreas


libreoffice-help-ca_1:6.1.0~rc2-3.log.gz
Description: application/gzip

Bug#905187: php7.2/7.2.8-1 appears to break multiple autopkgtest: /usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found

[Paul Gevers]

Source: php7.2
Version: 7.2.8-1
User: debian...@lists.debian.org
Usertags: breaks
Control: affects -1 src:php-luasandbox src:wikidiff2

Dear maintainers, [X-Debbugs-CC set to affected packages and CI team]

With a recent upload of php7.2 the autopkgtest of php-luasandbox and
wikidiff2 started to fail in unstable and testing. I copied the error below.

Currently this regression is delaying the migration of php7.2 to
testing by 13 days. From the error it seems that a dependency on sed is
missing somewhere, but that is just a hunch. Could you please
investigate the situation? If php-luasandbox and wikidiff2 need to adapt
their autopkgtest, please clone and re-assign.

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

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-luasandbox/749361/log.gz

autopkgtest [04:34:43]: test unittests: [---
/usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
/usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
/usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
Configuring for:
PHP Api Version:
Zend Module Api No:
Zend Extension Api No:
/usr/bin/phpize: 157: /usr/bin/phpize: /usr/bin/sed: not found
autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
autopkgtest [04:34:43]: test unittests: ---]

https://ci.debian.net/data/autopkgtest/testing/amd64/w/wikidiff2/749373/log.gz

autopkgtest [04:36:15]: test unittests: [---
/usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
/usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
/usr/bin/phpize: 1: /usr/bin/phpize: /usr/bin/sed: not found
Configuring for:
PHP Api Version:
Zend Module Api No:
Zend Extension Api No:
/usr/bin/phpize: 157: /usr/bin/phpize: /usr/bin/sed: not found
autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
autopkgtest [04:36:16]: test unittests: ---]



signature.asc
Description: OpenPGP digital signature

Bug#905190: nmu: fs-uae_2.8.4+dfsg-1~bpo9+1

[Andreas Beckmann]

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

nmu fs-uae_2.8.4+dfsg-1~bpo9+1 . amd64 . stretch-backports . -m "Rebuild in a 
clean stretch environment."

The maintainer-uploaded binaries were not built in a clean stretch
environment and have
  Depends: libsdl2-2.0-0 (>= 2.0.7) 
which is unsatisfiable in stretch(-backports).


Andreas

Bug#904972: vmdebootstrap going away in September, switch now

[Paul Gevers]

Dear Lars,

On 30-07-18 06:34, Lars Wirzenius wrote:
> On Sun, 2018-07-29 at 23:24 +0200, Michael Biebl wrote:
>> I notice that the autopkgtest man pages still reference vmdebootstrap,
>> specifically autopkgtest-virt-qemu.1:
>>
>>> BUILDING IMAGES
>>>Debian
>>>For Debian you can use vmdebootstrap(8) to build a suitable image. 
>>> E. g. for unstable:
>>>
>>>   vmdebootstrap --verbose --serial-console --distribution=sid \
>>>  
>>> --customize=/usr/share/autopkgtest/setup-commands/setup-testbed \
>>>  --user=test/test --size=100 --grub 
>>> --image=autopkgtest-sid.raw
>>>   qemu-img convert -O qcow2 autopkgtest-sid.raw  
>>> autopkgtest-sid.img
>>>   rm autopkgtest-sid.raw
>>
>>
>> Could those man pages be updated to list the commands for a/the
>> recommended replacement/successor of vmdebootstrap?
> 
> vmdebootstrap is going away and the manual page quoted above needs to be
> updated to use a replacement, such a debos or vmdb2 or FAI.

I have zero experience with either vmdebootstrap or any of its
successors. Would you be able and willing to propose a replacement
command for that example?

On top of that, the man page goes on with (already slightly adapted):
"""
You can run those commands with setting the environment variable
AUTOPKGTEST_APT_PROXY to a proxy which will be used by apt in the VM. If
you have an apt proxy configured on the host, this will be used
automatically.
"""

Do you know if any/all of the replacements honor that variable in the
same way as vmdebootstrap does?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905196: pike8.0-web-sass: Previous binary upload on amd64 linked against dropped libsass0, blocking transition, needs rebuild

[Boyuan Yang]

Package: pick8.0-web-sass
Version: 8.0.610-1
Severity: serious
Control: affects -1 + libsass1

Dear pike8.0 maintainer,

Your previous upload pike8.0 8.0.610-1 was not a source-only upload
[1], which brings binary packages for amd64 architecture onto the
Archive. However, it was built against the old libsass source and
pike8.0-web-sass is linked against the old libsass0 library, which
should now be removed from the Archive.

Please consider making another upload to make sure that pike8.0 is
built against new libsass / libsass1 library. BinNMU might be
applicable but considering that the Testing migration is already
blocked by some other problems [2], it might be better to fix the
problem together with another upload.

--
Regards,
Boyuan Yang

[1] https://tracker.debian.org/news/969383
[2] https://qa.debian.org/excuses.php?package=pike8.0

Bug#904972: vmdebootstrap going away in September, switch now

[Lars Wirzenius]

On Wed, 2018-08-01 at 13:54 +0200, Paul Gevers wrote:
> I have zero experience with either vmdebootstrap or any of its
> successors. Would you be able and willing to propose a replacement
> command for that example?

I, on the other hand, have never used autopkgtest... I see Martin linked to
the /usr/share/autopkgtest/setup-commands/setup-testbed file, but given I
entirely lack the context, it's a bit tricky to try to translate that to
something vmdb2 or debos does, blindly. I'm afraid I don't really have the
time or energy to try. I can answer specific questions, though.



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

Bug#905199: mozjs52: Please update debian/test.sh to add sparc64, remove ppc64el from ignore list

[John Paul Adrian Glaubitz]

Source: mozjs52
Version: 52.3.1-9
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

The testsuite for mozjs52 fails on sparc64 while it passes on ppc64el,
so please add sparc64 to the list and remove ppc64el.

Thanks,
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#905188: cryptsetup-initramfs: fails to install, remove, distupgrade, and install again

[Andreas Beckmann]

Package: cryptsetup-initramfs
Version: 2:2.0.3-6
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + cryptsetup

Hi,

during a test with piuparts I noticed your package cryptsetup failed to
install (in 'stretch'), remove (but not purge), distupgrade to 'buster',
and install again.
Before the second installation the package is in config-files-remaining
state. The configuration is remaining from the last version that was
successfully configured - which is from the previous release.

The problem shows up in cryptsetup-initramfs, which prompts about a
deleted conffile, which was not deleted by the user, but probably by a
buggy script in the old package.

Like a plain failure on initial install this makes the package too buggy
for a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up initramfs-tools-core (0.131) ...
  Setting up initramfs-tools (0.131) ...
  update-initramfs: deferring update (trigger activated)
  Setting up cryptsetup-initramfs (2:2.0.3-6) ...
  
  Configuration file '/etc/cryptsetup-initramfs/conf-hook'
   ==> Deleted (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** conf-hook (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
cryptsetup-initramfs (--configure):
   end of file on stdin at conffile prompt
  dpkg: dependency problems prevent configuration of cryptsetup:
   cryptsetup depends on cryptsetup-initramfs (>= 2:2.0.3-1); however:
Package cryptsetup-initramfs is not configured yet.
  
  dpkg: error processing package cryptsetup (--configure):
   dependency problems - leaving unconfigured
  Processing triggers for libc-bin (2.27-5) ...
  Processing triggers for initramfs-tools (0.131) ...
  Errors were encountered while processing:
   cryptsetup-initramfs
   cryptsetup


cheers,

Andreas


cryptsetup_2:2.0.3-6.log.gz
Description: application/gzip

Bug#905189: ruby-ruby2ruby: autopkgtest needs update for ruby-sexp-processor or ruby-parser

[Paul Gevers]

Source: ruby-ruby2ruby
Version: 2.3.0-1
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ruby-sexp-processor src:ruby-parser

Dear maintainers, [X-Debbugs-CC set to affected packages and CI team]

With a recent upload of either ruby-sexp-processor or ruby-parser the
autopkgtest of ruby-ruby2ruby started to fail in unstable and testing. I
copied the error below.

Currently this regression is delaying the migration of
ruby-sexp-processor and ruby-parser to testing by 13 days. From the
error it seems that this is just intended change of code and the
reference of your autopkgtest just needs an update, but that is just a
hunch. Could you please investigate the situation? If
ruby-sexp-processor and/or ruby-parser need to fix something, please
re-assign. By the way, if my hunch is correct, it would help both
ruby-sexp-processor and ruby-parser migration if a versioned Breaks on
ruby-ruby2ruby is added (I'll need to manually help the migration
software in that case, so please inform me if this happens).

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

Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-ruby2ruby/750122/log.gz

autopkgtest [10:01:44]: test command1: [---

┌──┐
│ Checking Rubygems dependency resolution on ruby2.5
  │
└──┘

GEM_PATH= ruby2.5 -e gem\ \"ruby2ruby\"

┌──┐
│ Run tests for ruby2.5 from debian/ruby-test-files.yaml
  │
└──┘

mv lib .gem2deb.lib
RUBYLIB=. GEM_PATH= ruby2.5 -ryaml -e
YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\ \{\ \|f\|\
require\ f\ \}


Run options: --seed 50537

# Running:

.FF..F.../usr/lib/ruby/vendor_ruby/ruby2ruby.rb:438:
warning: constant ::Fixnum is deprecated
..F.F..F...FF...F.F.(eval):362:
warning: constant ::Fixnum is deprecated
F..FF.FFFFFF.F.F...F.F.F...F...F..FF.F...F...F.F.FF...FFF...F..F..F..F..(eval):362:
warning: constant ::Fixnum is deprecated
.FF..F.F..F..F.F.F...F

Finished in 1.144486s, 2092.6421 runs/s, 5797.3614 assertions/s.

  1) Failure:
TestRuby2Ruby#test_if_post_not__19_20_21_22_23_24_25 [(eval):8]:
Expected: "a unless b"
  Actual: "a if (not b)"

  2) Failure:
TestRuby2Ruby#test_until_pre_not__19_20_21_22_23_24_25 [(eval):8]:
--- expected
+++ actual
@@ -1,3 +1,3 @@
-"while true do
+"until (not true) do
   (1 + 1)
 end"


  3) Failure:

Bug#904819: Bug#902936: fixed in zutils 1.7-2

[Antonio Diaz Diaz]

On Tue, 31 Jul 2018 10:58:41 +0800 Ben Hutchings wrote:

*** Error in `zcat': free(): invalid next size (normal): 0x016e6980 ***


It seems I answered to the wrong bug[1], sorry. The bug fixed in 
zutils-1.8-pre2 also fixes this one (#904819).


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

Thank you very much Daniel for extracting a patch for 1.7 from 1.8-pre2 
and applying it so fast.



Best regards,
Antonio.

Bug#905191: libecm1-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: libecm1-dev
Version: 7.0.4+ds-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  stretch -> buster

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (scroll to the bottom...):

0m29.3s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libecm1-dev/AUTHORS (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/AUTHORS (?)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/NEWS.gz (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/NEWS.gz (?)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/README.gz (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/README.gz (?)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/README.lib.gz (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/README.lib.gz (?)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/changelog.Debian.gz (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/changelog.Debian.gz (libecm1-dev-common)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/changelog.gz (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/changelog.gz (libecm1-dev-common)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/copyright (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/copyright (libecm1-dev-common)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/examples (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/examples (?)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/examples/Makefile (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/examples/Makefile (?)
/usr/share/doc/libecm1-dev -> libecm1-dev-common
  /usr/share/doc/libecm1-dev/examples/ecmfactor.c (libecm1-dev:amd64) != 
/usr/share/doc/libecm1-dev-common/examples/ecmfactor.c (?)
/usr/share/doc/libecm1-dev -> libecm1-dev-common


cheers,

Andreas


libecm1-dev_7.0.4+ds-2.log.gz
Description: application/gzip

Bug#905192: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility.

[Picca Frédéric-Emmanuel]

Source: python-greenlet
Severity: normal

Dear Maintainer,

while preparing my pytango package for the python3.7 transition.
I get this message during the build of pytango[1]


/usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: 
greenlet.greenlet size changed, may indicate binary incompatibility. Expected 
72, got 64
  return f(*args, **kwds)
/usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: 
greenlet.greenlet size changed, may indicate binary incompatibility. Expected 
72, got 64
  return f(*args, **kwds)
/usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: 
greenlet.greenlet size changed, may indicate binary incompatibility. Expected 
72, got 64
  return f(*args, **kwds)
/usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: 
greenlet.greenlet size changed, may indicate binary incompatibility. Expected 
72, got 64
  return f(*args, **kwds)


Cheers

Frederic

[1] 
https://buildd.debian.org/status/fetch.php?pkg=pytango=i386=9.2.4-2=1533070318=0


-- System Information:
Debian Release: 9.5
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

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

Bug#905193: alot-doc: unhandled symlink to directory conversion: /usr/share/doc/alot/html -> ../alot-doc/html

[Andreas Beckmann]

Package: alot-doc
Version: 0.7-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  stretch -> buster

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (scroll to the bottom...):

0m29.5s INFO: dirname part contains a symlink:
  /usr/share/doc/alot/html/_sources (alot-doc) != 
/usr/share/doc/alot-doc/html/_sources (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/_sources/api (alot-doc) != 
/usr/share/doc/alot-doc/html/_sources/api (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/_sources/api/commands.rst.txt (alot-doc) != 
/usr/share/doc/alot-doc/html/_sources/api/commands.rst.txt (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/_sources/api/contributing.rst.txt (alot-doc) != 
/usr/share/doc/alot-doc/html/_sources/api/contributing.rst.txt (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/_sources/api/crypto.rst.txt (alot-doc) != 
/usr/share/doc/alot-doc/html/_sources/api/crypto.rst.txt (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/_sources/api/database.rst.txt (alot-doc) != 
/usr/share/doc/alot-doc/html/_sources/api/database.rst.txt (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/_sources/api/index.rst.txt (alot-doc) != 
/usr/share/doc/alot-doc/html/_sources/api/index.rst.txt (?)
/usr/share/doc/alot/html -> ../alot-doc/html
[...]
  /usr/share/doc/alot/html/usage/modes/search.html (alot-doc) != 
/usr/share/doc/alot-doc/html/usage/modes/search.html (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/usage/modes/taglist.html (alot-doc) != 
/usr/share/doc/alot-doc/html/usage/modes/taglist.html (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/usage/modes/thread.html (alot-doc) != 
/usr/share/doc/alot-doc/html/usage/modes/thread.html (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/usage/signals.html (alot-doc) != 
/usr/share/doc/alot-doc/html/usage/signals.html (?)
/usr/share/doc/alot/html -> ../alot-doc/html
  /usr/share/doc/alot/html/usage/synopsis.html (alot-doc) != 
/usr/share/doc/alot-doc/html/usage/synopsis.html (?)
/usr/share/doc/alot/html -> ../alot-doc/html


This is probably caused by a behavioral change of dh_installdocs
in debhelper compat level 11.


cheers,

Andreas


alot-doc_0.7-1.log.gz
Description: application/gzip

Bug#905194: python-greenlet: please revert removing of -dbg packages

[Picca Frédéric-Emmanuel]

Source: python-greenlet
Severity: wishlist

Dear Maintainer,

In the version python-greenlet (0.4.13-1) unstable; urgency=medium

we can read this

- remove python{,3}-greenlet-dbg packages and use the auto-generated ones.

but for python these -dbg package are not equivalent to the autogenerated
-dbgsym packages.
these -dbg packages are meant to be used wuth the pyton[3]-dbg interpreter.

So please considere reverting this change.

Cheers

Frederic

-- System Information:
Debian Release: 9.5
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

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

Bug#905195: e2fslibs-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: e2fslibs-dev
Version: 1.44.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  stretch -> buster

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (scroll to the bottom...):

0m30.5s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/e2fslibs-dev/changelog.Debian.gz (e2fslibs-dev) != 
/usr/share/doc/e2fslibs/changelog.Debian.gz (e2fslibs:amd64)
/usr/share/doc/e2fslibs-dev -> e2fslibs
  /usr/share/doc/e2fslibs-dev/copyright (e2fslibs-dev) != 
/usr/share/doc/e2fslibs/copyright (e2fslibs:amd64)
/usr/share/doc/e2fslibs-dev -> e2fslibs


cheers,

Andreas


e2fslibs-dev_1.44.3-1.log.gz
Description: application/gzip

Bug#904972: vmdebootstrap going away in September, switch now

[Martin Pitt]

Hello Paul,

Paul Gevers [2018-08-01 13:54 +0200]:
> On top of that, the man page goes on with (already slightly adapted):
> """
> You can run those commands with setting the environment variable
> AUTOPKGTEST_APT_PROXY to a proxy which will be used by apt in the VM. If
> you have an apt proxy configured on the host, this will be used
> automatically.
> """
> 
> Do you know if any/all of the replacements honor that variable in the
> same way as vmdebootstrap does?

vmdebootstrap knows nothing about $AUTOPKGTEST_APT_PROXY. This is being handled
in setup-testbed [1] which gets called as a setup script by vmdebootstrap and
passed on to the command line. So as long as any replacement supports passing
on a setup shell script, it should be fine.

E. g. said script is also being used for creating LXC/LXD containers or even
OpenStack instances.

Martin

[1] 
https://salsa.debian.org/ci-team/autopkgtest/blob/master/setup-commands/setup-testbed



signature.asc
Description: PGP signature

Bug#905198: python-ldap-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: python-ldap-dbg
Version: 3.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  stretch -> buster

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (scroll to the bottom...):

0m38.4s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/python-ldap-dbg/changelog.Debian.amd64.gz (python-ldap-dbg) != 
/usr/share/doc/python-ldap/changelog.Debian.amd64.gz (python-ldap:amd64)
/usr/share/doc/python-ldap-dbg -> python-ldap
  /usr/share/doc/python-ldap-dbg/changelog.Debian.gz (python-ldap-dbg) != 
/usr/share/doc/python-ldap/changelog.Debian.gz (python-ldap:amd64)
/usr/share/doc/python-ldap-dbg -> python-ldap
  /usr/share/doc/python-ldap-dbg/changelog.gz (python-ldap-dbg) != 
/usr/share/doc/python-ldap/changelog.gz (python-ldap:amd64)
/usr/share/doc/python-ldap-dbg -> python-ldap
  /usr/share/doc/python-ldap-dbg/copyright (python-ldap-dbg) != 
/usr/share/doc/python-ldap/copyright (python-ldap:amd64)
/usr/share/doc/python-ldap-dbg -> python-ldap


cheers,

Andreas


python-ldap-dbg_3.1.0-1+b1.log.gz
Description: application/gzip

Bug#905197: libcue-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: libcue-dev
Version: 2.2.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  stretch -> buster

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (scroll to the bottom...):

0m28.7s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libcue-dev/changelog.Debian.gz (libcue-dev:amd64) != 
/usr/share/doc/libcue1/changelog.Debian.gz (libcue1)
/usr/share/doc/libcue-dev -> libcue1
  /usr/share/doc/libcue-dev/changelog.gz (libcue-dev:amd64) != 
/usr/share/doc/libcue1/changelog.gz (libcue1)
/usr/share/doc/libcue-dev -> libcue1
  /usr/share/doc/libcue-dev/copyright (libcue-dev:amd64) != 
/usr/share/doc/libcue1/copyright (libcue1)
/usr/share/doc/libcue-dev -> libcue1


cheers,

Andreas


libcue-dev_2.2.1-1.log.gz
Description: application/gzip

Bug#905200: natpmp-utils,libnatpmp-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: natpmp-utils,libnatpmp-dev
Version: 20150609-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  stretch -> buster

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (scroll to the bottom...):

0m28.4s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/natpmp-utils/changelog.Debian.gz (natpmp-utils) != 
/usr/share/doc/libnatpmp1/changelog.Debian.gz (libnatpmp1)
/usr/share/doc/natpmp-utils -> libnatpmp1
  /usr/share/doc/natpmp-utils/changelog.gz (natpmp-utils) != 
/usr/share/doc/libnatpmp1/changelog.gz (libnatpmp1)
/usr/share/doc/natpmp-utils -> libnatpmp1
  /usr/share/doc/natpmp-utils/copyright (natpmp-utils) != 
/usr/share/doc/libnatpmp1/copyright (libnatpmp1)
/usr/share/doc/natpmp-utils -> libnatpmp1

0m27.9s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libnatpmp-dev/changelog.Debian.gz (libnatpmp-dev:amd64) != 
/usr/share/doc/libnatpmp1/changelog.Debian.gz (libnatpmp1)
/usr/share/doc/libnatpmp-dev -> libnatpmp1
  /usr/share/doc/libnatpmp-dev/changelog.gz (libnatpmp-dev:amd64) != 
/usr/share/doc/libnatpmp1/changelog.gz (libnatpmp1)
/usr/share/doc/libnatpmp-dev -> libnatpmp1
  /usr/share/doc/libnatpmp-dev/copyright (libnatpmp-dev:amd64) != 
/usr/share/doc/libnatpmp1/copyright (libnatpmp1)
/usr/share/doc/libnatpmp-dev -> libnatpmp1


cheers,

Andreas


natpmp-utils_20150609-4.log.gz
Description: application/gzip

Bug#905138: [Pkg-cmake-team] Bug#905138: cmake: FTBFS on kfreebsd-any

[Felix Geyer]

Hi,

On 31.07.2018 17:01, Svante Signell wrote:
> Source: cmake
> Version: 3.11.2-1
> Severity: important
> Tags: patch
> Usertags: linux-any, freebsd-any, hurd-any
>
> Hello,
>
> Currently cmake does FTBFs on kfreebsd-any due to a missing dependency
> on libfreebsd-glue-0 and a missing dependency on freebsd-glue,
> providing the link:
> /usr/lib/libfreebsd-glue.so -> /lib/libfreebsd-glue.so.0
>
> Ideally a library libfreebsd-glue-dev should be split out of the
> package freebsd-glue. Until that happens, the added dependency will do,
> see the attached file debian_control.diff.
>
> With the attached patches bootstrap.patch, debian_control.diff, and the
> upcoming bug report on linux-any,providing
> Source_Modules_FindLibUV.cmake.diff cmake builds fine. 

Have you forwarded your non-packaging changes upstream to cmake / libuv
(#905140 is already fixed in 3.12)?
I really don't want to carry those as patches.

Cheers,
Felix