Bug#905440: www.debian.org: remove "last modified" from footer

[Steve McIntyre]

On Sun, Aug 05, 2018 at 05:51:36AM +0200, Thomas Lange wrote:
>
>In the long run we may be able to read the git logs and have the
>accurate information of the 'last modification'. Currently that does
>not seem to be possible, because the build already takes too long.

That's actually one of the bits of information we can get quite
cheaply. Happy to play with it...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#905440: www.debian.org: remove "last modified" from footer

[Steve McIntyre]

On Sat, Aug 04, 2018 at 07:32:17PM +0200, Laura Arjona Reina wrote:
>>
>>The last commit on index.wml was in 2014, which only changed http to
>>https, so no real content change. In fact, the content didn't changed
>>since 2012 and may be out of date.
>
>The content is current.
>
>>Please just remove this useless information from every page.
>
>The date shown is the date of last build. This can be the date when
>something changed in the page (content or layout), in the templates
>used to build that page (e.g. a change in the footer), or a force
>rebuild for any reason.
>
>We probably change the string from "Last modified" to something else
>("Last build" or other wording), but I don't think that it is useless
>and we should remove it (I'm open to listen to other opinions,
>though).

Definitely it should stay - a major part of the usefulness of many
pages is "can I trust this to be up to date?". If desired, I'm happy
to prod the wml tooling to give us more useful data ("page content
last modified , page built ")...?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#903392: want support for packaging-only maintainer views

[Shengjing Zhu]

On Tue, Jul 31, 2018 at 10:50 AM Shengjing Zhu  wrote:
>
> Here's the example for my package, which only has debian dir in
> debian-branch.
>
> https://salsa.debian.org/zhsj-guest/anbox
>
> To build, using
>
> gbp clone https://salsa.debian.org/zhsj-guest/anbox
> gbp buildpackage --git-export-dir=../build-area --git-builder=sbuild
>

That should be
1. gbp buildpackage --git-export-dir=../build-area --git-overlay
or
2. gbp buildpackage --git-builder=sbuild

-- 
Best regards,
Shengjing Zhu

Bug#905472: libtextwrap FTBFS: cannot find -ltextwrap

[Helmut Grohne]

Source: libtextwrap
Version: 0.1-14.1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

libtextwrap fails to build from source on amd64 in unstable. A build log
ends with:

| touch configure-stamp
| dh_testdir
| /usr/bin/make
| make[1]: Entering directory '/<>'
| /usr/bin/make  all-am
| make[2]: Entering directory '/<>'
| gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -MT dotextwrap.o -MD -MP -MF .deps/dotextwrap.Tpo -c -o 
dotextwrap.o dotextwrap.c
| mv -f .deps/dotextwrap.Tpo .deps/dotextwrap.Po
| /bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wl,-z,relro -o dotextwrap dotextwrap.o -ltextwrap 
| libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -o 
dotextwrap dotextwrap.o  -ltextwrap
| /usr/bin/ld: cannot find -ltextwrap
| collect2: error: ld returned 1 exit status
| make[2]: *** [Makefile:515: dotextwrap] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:373: all] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:56: build-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

This looks very strange and more of a breakage of makefile dependencies.
It didn't even try building -ltextwrap and links it already. The issue
is reproducible without parallelism. I haven't seen it until "recently"
though since meson and then pcre3 have fucked up bootstrap qa lately,
"recently" means like two weeks here though reproducible builds didn't
encounter the issue (yet?). The make-dfsg upload looks a bit suspicious,
so I'm Ccing Ben here.

I hope that someone can make sense of this, or at least reproduce it.

Helmut

Bug#900938: blueman: Blueman-manager should not automatically reconnect when manually disconnected

[Ron Murray]

On 06/09/2018 03:12 PM, Ron Murray wrote:
> On Fri, 8 Jun 2018 07:48:30 +0200 Christopher Schramm wrote:
> > Hi Ron,
> >
> > there should not be any such auto-connect feature in blueman. You can
> > easily confirm that by stopping blueman-applet and check if it still
> > happens (you can use bluetoothctl to disconnect if that's necessary).
> >
> > I actually think it is a feature of the headphones and not triggered
> > from your Linux system.
> >
> >

Sorry this took so long, but you're probably right. I connected them,
killed blueman-applet, and used bluetoothctl to disconnect. It
reconnected, so it's probably the headphones.

Perhaps Windows 10 (which doesnt exhibit the problem) doesn't care,
which wouldn't sur[prise me.

You can go ahead and close this bug if you like.

Thanks,

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761



signature.asc
Description: OpenPGP digital signature

Bug#905454: php-common: Update to php-common (1:62) stuck in php.common-post at systemd-tty-ask

[Ondřej Surý]

Control: reassign -1 systemd

I’ve seen this few times in the past, but there’s nothing I can do from 
php-common.  The units are pretty standard.

Reassigning this to systemd.

Thanks
Ondrej
--
Ondřej Surý
ond...@sury.org



> On 4 Aug 2018, at 22:00, Jaap Keuter  wrote:
> 
> Package: php-common
> Version: 1:62
> Severity: normal
> 
> Dear Maintainer,
> 
> While updating to php-common 1:62 the update gets stuck at:
> 
> ...
> Unpacking mesa-va-drivers:amd64 (18.1.5-1) over (18.1.4-1) ...
> Preparing to unpack .../17-php-common_1%3a62_all.deb ...
> Unpacking php-common (1:62) over (1:61) ...
> Preparing to unpack .../18-php7.2-xml_7.2.8-2_amd64.deb ...
> Unpacking php7.2-xml (7.2.8-2) over (7.2.4-1) ...
> ...
> Processing triggers for libc-bin (2.27-5) ...
> Setting up mesa-va-drivers:amd64 (18.1.5-1) ...
> Setting up php-common (1:62) ...
> 
> 
> Looking at the process tree reveils the following:
> 
>  |   |-konsole -session 
> 10dd616e7500015331903250014310008_1533191244_922307   
>   
>  |   |   |-bash   
>   
> 
>  |   |   |   `-update-debian.s /home/jaap/bin/update-debian.sh
>   
> 
>  |   |   |   `-sudo aptitude  
>   
> 
>  |   |   |   `-aptitude   
>   
> 
>  |   |   |   |-dpkg --status-fd 96 --configure --pending  
>   
> 
>  |   |   |   |   `-php-common.post 
> /var/lib/dpkg/info/php-common.postinst configure 1:61 
>
>  |   |   |   |   `-systemctl start phpsessionclean.timer  
>   
> 
>  |   |   |   |   `-systemd-tty-ask --watch
>   
> 
>  |   |   |   `-{aptitude} 
> 
> Somehow systemd-tty-ask tries to get something from us, but can't?
> 
> Ended up killing the systemd-tty-ask and systemctl processes to get the 
> update to complete.
> 
> -- System Information:
> Debian Release: buster/sid
>  APT prefers testing
>  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
> 'oldstable-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages php-common depends on:
> ii  psmisc  23.1-1
> ii  sed 4.5-1
> 
> php-common recommends no packages.
> 
> php-common suggests no packages.
> 
> -- no debconf information
> 

Bug#897414: plantuml: Upgrade to version 1.2018.4 and improve description

[Alex Kirchhoff]

retitle 897414 plantuml: Upgrade to version 1.2018.9 and improve description
tags 897414 patch
thanks

Hi,

Upstream has released version 1.2018.9 in the mean-time (see [1]).  I have 
prepared an updated source package, available at [2], which ought to be usable 
as a patch.

Thanks,
Alex Kirchhoff

  [1]: https://github.com/plantuml/plantuml/releases
  [2]: https://usertracker.org/otemp/debian/plantuml/plantuml_1.2018.9-0.1.dsc

Bug#904781: closing because h5py 2.8.0 has been uploaded

[Lumin]

control: close -1

closing because 0.2.8 has been uploaded.
I forgot to close this bug.

Bug#905439: su from util-linux breaks autopkgtest

[Lumin]

control: close -1

Hi Antonio,

The log is available here and the autopkgtest version used is 5.4.1~bpo9+2
http://debomatic-amd64.debian.net/distribution#unstable/h5py/2.8.0-1/autopkgtest

So I think it would be fixed when the backported backage is updated.
Sorry for the noise.

On Sat, Aug 04, 2018 at 01:31:27PM -0300, Antonio Terceiro wrote:
> Control: tag -1 + moreinfo unreproducible
> 
> On Sat, Aug 04, 2018 at 03:11:17PM +, Lumin wrote:
> > Package: autopkgtest
> > Version: 5.4.2
> > Severity: serious
> > 
> > the "su" command from util-linux breaks autopkgtest. The previous
> > working one comes from shadow.
> > 
> > python-h5py-dbg is already the newest version (2.8.0-1).
> > python-h5py-dbg set to manually installed.
> > python-h5py is already the newest version (2.8.0-1).
> > python-h5py set to manually installed.
> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > (Reading database ... 13709 files and directories currently installed.)
> > Removing autopkgtest-satdep (0) ...
> > autopkgtest [16:38:33]: test command1: set -e ; for py in $(pyversions -r 
> > 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
> > "import h5py; h5py.run_tests()" ; echo "Testing with $py-dbg:" ; $py-dbg -c 
> > "import h5py; h5py.run_tests()" ; done
> > autopkgtest [16:38:33]: test command1: [---
> > su: user  does not exist
> > autopkgtest [16:38:33]: test command1: ---]
> > Unexpected error:
> > Traceback (most recent call last):
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
> > command()
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 646, in command
> > r = f(c, ce)
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 584, in cmd_copyup
> > copyupdown(c, ce, True)
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 469, in copyupdown
> > copyupdown_internal(ce[0], c[1:], upp)
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 494, in 
> > copyupdown_internal
> > copyup_shareddir(sd[0], sd[1], dirsp, downtmp_host)
> >   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 408, in 
> > copyup_shareddir
> > shutil.copy(tb, host)
> >   File "/usr/lib/python3.5/shutil.py", line 241, in copy
> > copyfile(src, dst, follow_symlinks=follow_symlinks)
> >   File "/usr/lib/python3.5/shutil.py", line 120, in copyfile
> > with open(src, 'rb') as fsrc:
> > FileNotFoundError: [Errno 2] No such file or directory: 
> > '/var/run/schroot/mount/unstable-amd64-debomatic-98e10886-4014-46ea-a35e-37ffe71bdcf3/tmp/autopkgtest.mZ5fp7/command1-stdout'
> > autopkgtest [16:38:34]: ERROR: testbed failure: unexpected eof from the 
> > testbed
> 
> Are you sure you saw this with autopkgtest 5.4.2? This bug was present
> 5.4.1, but explicitly fixed in 5.4.2.
> 
> See the attached log for an attempt I just made at reproducing this. The
> tests fail but autopkgtest itself works as expected.

> autopkgtest [13:26:52]: version 5.4.2
> autopkgtest [13:26:52]: host lemur; command line: /usr/bin/autopkgtest 
> --apt-upgrade --log-file /tmp/log -B h5py -- lxc --sudo 
> autopkgtest-unstable-amd64
> autopkgtest: WARNING: running as root in testbed, because no normal user 
> could be determined
> autopkgtest [13:27:04]:  test bed setup
> Get:1 http://deb.debian.org/debian unstable InRelease [233 kB]
> Get:2 http://deb.debian.org/debian unstable/non-free Sources.diff/Index [27.8 
> kB]
> Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB]
> Get:4 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
> [27.9 kB]
> Get:5 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index 
> [27.8 kB]
> Get:6 http://deb.debian.org/debian unstable/non-free Sources 
> 2018-08-03-2013.11.pdiff [1,306 B]
> Get:7 http://deb.debian.org/debian unstable/non-free Sources 
> 2018-08-04-0814.44.pdiff [665 B]
> Get:8 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-02-1416.04.pdiff [5,521 B]
> Get:7 http://deb.debian.org/debian unstable/non-free Sources 
> 2018-08-04-0814.44.pdiff [665 B]
> Get:9 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-02-2015.39.pdiff [10.3 kB]
> Get:10 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-03-0208.52.pdiff [3,145 B]
> Get:11 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-03-0811.08.pdiff [15.6 kB]
> Get:12 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-03-1408.50.pdiff [39.5 kB]
> Get:13 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-03-2013.11.pdiff [8,876 B]
> Get:14 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-04-0211.02.pdiff [5,928 B]
> Get:15 http://deb.debian.org/debian unstable/main Sources 
> 2018-08-04-0814.44.pdiff [11.7 kB]
> Get:16 http://incoming.debian.org/debian-buildd buildd-unstable InRelease 
> [55.3 kB]
> Get:17 http://deb.debian.org/debian unstable/main 

Bug#905469: lintian: Please emit tag on direct access to dpkg database

[Chris Lamb]

tags 905469 + moreinfo
thanks


Hi Guillem,

> This is one blocker that is getting in the way of deploying mtree
> support as the dpkg database store, because .list, .md5sums and
> .conffiles are intended to disappear from under /var/lib/dpkg/info/
> and that will break all these packages and programs.

Ah, neat. I wasn't aware of this proposal and I hope Lintian can help
get us to that quicker. (Is there a wishlist bug or similar with more
info about this, just out of interest?)

>   * Using «dpkg --status» for package status.
>   * Using «dpkg --status» for Conffiles field.
>   * Using «dpkg-query --listfiles» for file lists.
>   * Using «dpkg-query --control-(list|show)» to get control file
> information.

Cool. So, some quick questions:

 * Are there some existing packages that currently break that we can
   crib as testcases? 

 * What files should actually be checked? We wouldn't want to fire on
   docs, just as one obvious example.

 * Could you write a quick tag description? What you wrote in the
   introduction to this tag would be a good start at the very least.

 * What sort of severity level would you be looking for?


Best wishes,

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

Bug#905471: fwupd-amd64-signed-template: conflicting source package name

[Ansgar Burchardt]

Package: fwupd-amd64-signed-template
Version: 1.1.0-5
Severity: serious

>From the code signing service:

+---
| dpkg-source: error: source package has two conflicting values - 
fwupd-amd64-signed and fwupd-signed-amd64
+---

d/changelog and d/control use different source package names.

This should be reproducible by just invoking `dpkg-source -b` in the
template directory (or a copy of it).

Ansgar

Bug#892883: mirrors: Debian mirror opensource.nchc.org.tw: add as candidate of ftp.tw

[Martin Zobel-Helas]

Hi Marco,

i only partly agree with your oberservations.

zobel@dag:~$ dig nchc.org.tw ns

; <<>> DiG 9.10.3-P4-Debian <<>> nchc.org.tw ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47092
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nchc.org.tw.   IN  NS

;; ANSWER SECTION:
nchc.org.tw.300 IN  NS  ns3.nchc.org.tw.
nchc.org.tw.300 IN  NS  ns4.nchc.org.tw.
nchc.org.tw.300 IN  NS  ns1.nchc.org.tw.
nchc.org.tw.300 IN  NS  ns2.nchc.org.tw.

;; ADDITIONAL SECTION:
ns1.nchc.org.tw.66267   IN  2001:e10:2000:16::1
ns2.nchc.org.tw.77026   IN  2001:e10:2000:4::1
ns1.nchc.org.tw.18070   IN  A   140.110.16.1
ns2.nchc.org.tw.42059   IN  A   140.110.4.1
ns3.nchc.org.tw.55875   IN  A   140.110.96.2
ns4.nchc.org.tw.29006   IN  A   140.110.143.75


While i agree with you the you mentioned 2001:e10:2000:10::1 does not
answer to DNS requests, 2001:e10:2000:16::1 and 2001:e10:2000:4::1 are
working perfect from my machine at Hetzner in Germany.

I poked the DNS admins here localy at DebConf18 to fix the glue record,
though.

Best regards,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Bug#905440: www.debian.org: remove "last modified" from footer

[Thomas Lange]

> On Sat, 04 Aug 2018 19:32:17 +0200, Laura Arjona Reina 
>  said:

> The content is current.
That's good.

> The date shown is the date of last build. This can be the date when 
something changed in the page (content or layout), in the templates used to 
build that page (e.g. a change in the footer), or a force rebuild for any 
reason.
I figured that this should be the date of the last build.

> We probably change the string from "Last modified" to something else 
("Last build" or other wording), but I don't think that it is useless and we 
should remove it (I'm open to listen to other opinions, though).
"Last build" is fine for me.

In the long run we may be able to read the git logs and have the
accurate information of the 'last modification'. Currently that does
not seem to be possible, because the build already takes too long.

-- 
regards Thomas

Bug#905409: upgrade of util-linux and login break the xhost command for other users

[Andreas Henriksson]

Hello Davide Prina,

Thanks for your bug report. (Reply inline below.)

On Sat, Aug 04, 2018 at 08:59:29AM +0200, Davide Prina wrote:
> Package: util-linux
> Version: 2.32-0.1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> upgrading
> * util-linux:amd64 (2.32-0.1, 2.32-0.3)
> * login:amd64 (1:4.5-1, 1:4.5-1.1)
> 
> do not let work anymore something like this:
> 
> $ xhost +si:localuser:temp
> $ su - temp

You are right that the old su would copy over DISPLAY and XAUTHORITY
environment variables, even when you tell it to give you a new
clean environment.

The util-linux implementation does what you tell it to do.

> $ firefox &
> Error: GDK_BACKEND does not match available displays

The error message is a bit misleading. Please just try running this
instead:

DISPLAY=:0 firefox &

> 
> downgrade this two packages (as I have done now before writing this bug
> report) solve the problem
> 
> If I mistake and this is a login package problem please reassign the bug.

Please feel free to submit a merge request with a util-linux.NEWS entry
addition mentioning the difference if you can come up with a nice
user-understandable description.

You might also want to file a minor bug report against firefox
(upstream?) to give a less misleading error message.

Regards,
Andreas Henriksson

Bug#897797: Help to build libsmithwaterman with gcc-8 needed

[Andreas Tille]

Hi,

I thinks I've fixed the issue for bug #897797 in Git[1] for
libsmithwaterman but somehow it fails to build for a different
reason now.  Any idea why this might happen:

...
make  all-am
make[2]: Entering directory '/build/libsmithwaterman-0.0+git20160702.2610e25'
g++ -DHAVE_CONFIG_H -I.   -I. -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o smithwaterman.o 
smithwaterman.cpp
/bin/bash ./libtool  --tag=CXX   --mode=link g++  -g -O2 
-fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
-fstack-protector-strong -Wformat -Werror=format-security  -  Wl,-z,relro 
-Wl,-z,now -o smithwaterman smithwaterman.o -lsmithwaterman -ldisorder
libtool: link: g++ -g -O2 
-fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -o smithwaterman smithwaterman.o  -lsmithwaterman -ldisorder
/usr/bin/ld: cannot find -lsmithwaterman
collect2: error: ld returned 1 exit status
...


Any hints?

Kind regards

 Andreas.


[1] https://salsa.debian.org/med-team/libsmithwaterman

-- 
http://fam-tille.de

Bug#905470: 0ad: Alpha 23 Lobby lag and other multiplayer issues

[Elia Argentieri]

Package: 0ad
Version: 0.0.23-1+b1
Severity: normal

Dear maintainer,

it looks like upstream made a "lobby lag" release fix.
I had this problem with the multiplayer lobby, so I looked at the svn history
and I found this:
 https://code.wildfiregames.com/D1518

Please consider adding this fixes to Debian's 0ad package.



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

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

Versions of packages 0ad depends on:
ii  0ad-data   0.0.23-1
ii  0ad-data-common0.0.23-1
ii  dpkg   1.19.0.5+b1
ii  libboost-filesystem1.62.0  1.62.0+dfsg-8
ii  libc6  2.27-5
ii  libcurl3-gnutls7.60.0-2
ii  libenet7   1.3.13+ds-1
ii  libgcc11:8.2.0-1
ii  libgl1 1.0.0+git20180308-3
ii  libgloox17 1.0.20-2
ii  libicu60   60.2-6
ii  libminiupnpc17 2.1-1
ii  libnspr4   2:4.19-3
ii  libnvtt2   2.0.8-1+dfsg-8.1+b3
ii  libopenal1 1:1.18.2-3
ii  libpng16-161.6.34-2
ii  libsdl2-2.0-0  2.0.8+dfsg1-1
ii  libsodium231.0.16-2
ii  libstdc++6 8.2.0-1
ii  libvorbisfile3 1.3.6-1
ii  libwxbase3.0-0v5   3.0.4+dfsg-4
ii  libwxgtk3.0-0v53.0.4+dfsg-4
ii  libx11-6   2:1.6.5-1
ii  libxcursor11:1.1.15-1
ii  libxml22.9.4+dfsg1-7+b1
ii  zlib1g 1:1.2.11.dfsg-1

0ad recommends no packages.

0ad suggests no packages.

-- no debconf information

Bug#905469: lintian: Please emit tag on direct access to dpkg database

[Guillem Jover]

Package: lintian
Version: 2.5.94
Severity: wishlist

Hi!

The entire dpkg database, its layout and files are an internal interface
to dpkg, no program or package (in theory) should be accessing it other
than dpkg itself and any of the dpkg suite tools. While by design the
database is all editable by the admin, that's a supported property
intended and reserved for sentient beings, not for automatic tools,
even though it's not a practice that should be recommended.

AFAIR this was communicated in the past (but cannot find references
now) as part of the multiarch database layout change, and there's even
already a test to detect direct accesses to dpkg's status files.

This is one blocker that is getting in the way of deploying mtree
support as the dpkg database store, because .list, .md5sums and
.conffiles are intended to disappear from under /var/lib/dpkg/info/,
and that will break all these packages and programs.

I think currently the only exceptions that might be allowed are:

  * Any package modifying (harmful) prerm scripts in the database,
because we do not currently have any way to mark this yet.


  * And any frontend that might currently be accessing
/var/lib/dpkg/info, because libdpkg-dev was neither a PIC library
until PIE was globally enabled in dpkg, nor did it contain the db
handling code, which was restricted to the dpkg binary itself.
I think apt/cupt and similar would be grandfathered for now, until
both libdpkg-dev contains such support (should come in dpkg 1.19.1)
and these have switched over.

Anything else, should be:

  * Using «dpkg --status» for package status.
  * Using «dpkg --status» for Conffiles field.
  * Using «dpkg-query --listfiles» for file lists.
  * Using «dpkg-query --control-(list|show)» to get control file
information.
  * etc, happy to provide more alternatives to current uses.

Thanks,
Guillem

Bug#905468: fwupd-amd64-signed-template: invalid Build-Depends (syntax error)

[Ansgar Burchardt]

Package: fwupd-amd64-signed-template
Version: 1.1.0-4
Severity: serious

The source template for code signing contains invalid Build-Depends:

Build-Depends: ... fwupd (= ) [amd64]

The version is missing.  The same problem occurs in `Depends` too:

Depends: ... fwupd (= })

Ansgar

Bug#905467: lintian: Please detect source-only non-free uploads w/o opt-in autobuild

[Guillem Jover]

Package: lintian
Version: 2.5.94
Severity: wishlist

Hi!

I recently did a source-only QA upload for snmp-mibs-downloader, a
non-free package. And didn't notice until way later that the package
had not been migrated [M], because of the missing binaries, due to the
package not having opted into the non-free autobuild network.

  [M] 

I think lintian should at least warn (or perhaps even error) on
source-only non-free uploads that do not declare the Autobuild:yes
field. [A]

  [A] 


Thanks,
Guillem

Bug#905466: ITP: binutils-mipsen

[YunQiang Su]

Package: wnpp

Since binutils need to produce lots of packages and
it cost lots of time and disk when building.

We decide to split it. This packages contains non-official port for mips,
aka mips* except mips/mipsel/mips64el.

-- 
YunQiang Su

Bug#905465: thunderbird: Please adjust Build-Depends, as checked while trying to backport to stretch

[Cyril Brulebois]

Source: thunderbird
Version: 1:60.0~b10-1
Severity: important
Tags: patch

Hi,

While working on a Tails-enabled backport of Thunderbird for stretch,
I've encountered a number of issues with minimal versions of some build
dependencies.

Here's a summary of my findings (a bit verbose so that I can reference
this bug report in Tails tickets):

 - nss and nspr have their minimal version documented correctly. Both
   packages can be trivially backported to stretch, but only nss gets
   updated dependencies in the resulting package (meaning one would
   only need the backported version of nspr for building, but need
   the backported nss both at build time and at run time):
 libnss3 (>= 2:3.30)
 libnspr4 (>= 2:4.10.9)

 - libsqlite-dev needs a trivial backport as well, only needed at build
   time (not at runtime):
 libsqlite3-0 (>= 3.14.0)
   → The version in Build-Depends is insufficient though.

 - libicu-dev is needed (and needs a backport too) for icu-i18n.pc; at
   this point I noticed the debian/mozconfig.default file and started
   toying with embedded code copies instead of backporting more
   packages.
   → The package isn't documented in Build-Depends at all.

 - Even if the configure script doesn't check for a minimal version of
   libhunspell-dev, the one declared in Build-Depends (1.2) isn't
   sufficient. Building within stretch (so against 1.4) leads to build
   errors:
| error: 'class Hunspell' has no member named 'get_dict_encoding'
| error: no matching function for call to 
'Hunspell::spell(std::__cxx11::string&)'
| error: no matching function for call to 
'Hunspell::suggest(std::__cxx11::string&)'

   hunspell can be trivially backported as well, and a build results in
   an unversioned dependency against a new binary package:
 libhunspell-1.6-0
   
   Checking upstream's git history, those first appeared in 1.5.1.
   → I think it'd be good to mention this upstream, so that they
 adjust their configure script.
   → And it'd be nice to bump the minimal version in Build-Depends.

I've addressed all packaging points (i.e. everything except suggested
upstream change) through 3 commits in my debian/experimental, available
on salsa:
  https://salsa.debian.org/kibi/thunderbird/commits/debian/experimental

(They are also attached to this bug report.)


On the Tails side, I've decided to switch to embedded code copies for
the following libraries: nss, nspr, icu, hunspell, sqlite. While
backporting them seems easy, I'd like to avoid possible side effects in
other reverse dependencies, hoping to have a self-contained thunderbird
update. Relevant commit in my Tails topic branch:
  
https://salsa.debian.org/kibi/thunderbird/commit/8b81093efea0b9a81dcea96b74e3459e5db3a396

I guess you might follow a similar path as well for stretch/updates,
which was done in the past already:
  
https://salsa.debian.org/kibi/thunderbird/commit/6755547f7d8e2df047bd779683e8204a8ddba94e

but feel free to double check, and maybe correct me on this.


Final note: trying to build such a package within stretch currently
depends on having stretch-proposed-updates enabled, to get cargo and
friends.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
>From 9234830b940c98f34aedbd18eb7e44397c8ddb94 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Sun, 5 Aug 2018 04:04:51 +0200
Subject: [PATCH 1/3] Bump libsqlite3-dev version.

Let's align with what configure scripts check.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index ce6bc6fb0b..641f6928de 100644
--- a/debian/control
+++ b/debian/control
@@ -39,7 +39,7 @@ Build-Depends:
  libpulse-dev,
  libreadline-dev,
  libstartup-notification0-dev,
- libsqlite3-dev (>= 3.20.1),
+ libsqlite3-dev (>= 3.22.0~),
  libvpx-dev (>= 1.5.0),
  libx11-dev,
  libx11-xcb-dev,
-- 
2.11.0

>From e5a12c7dc5cfde65cb557a3a785b51cab5968f58 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Sun, 5 Aug 2018 04:05:18 +0200
Subject: [PATCH 2/3] Add libicu-dev to Build-Depends (required for
 icu-i18n.pc).

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 641f6928de..27f4b22809 100644
--- a/debian/control
+++ b/debian/control
@@ -29,6 +29,7 @@ Build-Depends:
  libgtk2.0-dev,
  libgtk-3-dev (>= 3.4),
  libhunspell-dev (>= 1.2),
+ libicu-dev (>= 59.1~),
  libjsoncpp-dev,
  libidl-dev (>= 0.8.0),
  libiw-dev [linux-any],
-- 
2.11.0

>From 37cabf67afeac2bfbe2b0a360cf7c094fce59249 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Sun, 5 Aug 2018 04:08:04 +0200
Subject: [PATCH 3/3] Bump libhunspell-dev version.

Building thunderbird in stretch, against hunspell 1.4, leads to these
errors because of missing functions in its API:
| error: 'class Hunspell' has no member named 'get_dict_encoding'
| error: no matching function for call to 
'Hunspell::spell(std::__cxx11::string&)'
| error: no matching function for 

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

[Carsten Schoenert]

Hello Werner,

On Wed, Aug 01, 2018 at 05:11:40PM +0200, Werner Frey wrote:
... 
> 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.

mhh, I don't use i386 based hardware normaly, on amd64 KiCad is working
well so far.
O.k., this is an upstream issue and need to be addressed there. Can you
please make a GDB log of a segfault? You need to install kicad-dbgsym
for this.

https://wiki.debian.org/HowToGetABacktrace

Once we have a GDB log we can open a issue within the upstream bug
tracker.

Regards
Carsten

Bug#905457: munin: general protection fault

[Lars Kruse]

Package: munin
Followup-For: Bug #905457

Hello Bertrand,

On Sat, 04 Aug 2018 22:35:54 +0200, BERTRAND Joël wrote,

> I don't understand why perl tries to run /usr/sbin/munin, there is no
> such script nor executable.

indeed there is no such file shipped in any munin package.

I just tried to reproduce this issue on a fresh and up-to-date buster
system. But I failed to find this log message here on my host.

I could only imagine the following two sources of this log messages
(both of which feel equally unlikely):
1) a locally installed munin plugin
2) a cron-job that is not related to the packaged "munin-cron"

For 1) you could take a look at /etc/munin/plugins/ and check for
non-packaged plugins.
For 2) you could temporarily disable the "munin-cron" cron job and check
whether the mysterious log message still appears.

Or maybe you have a different idea how to trace the origin of this
message?

Cheers,
Lars

Bug#904685: diffoscope: RuntimeError when trying to extract an encrypted file (.bmp)

[Chris Lamb]

tags 904685 + patch
thanks

Dear Ricardo,

> Based on this bug, please find attached a proposed patch for handling
> this error gracefully [..]

Wow, thank you so much for this :)

> Additionally, I see that I could have also just submitted a merge request
> via salsa.debian.org. What is the usual workflow, email patches or merge
> requests?

It might depend more on the size of the patch and whether you were
thinking of making more in the future. Using salsa also has the
advantages of running the testsuite too, which may be useful here (see
below). Please do join our group on salsa ...

> I would gladly appreciate some feedback. I tried to update the changelog as
> best as I understood here
> .

Sure thing.

So, the debian/changelog entries for diffoscope are generated
automatically upon release so updating the changelog is not required.
In your commit message please suffix with "(Closes: #904685)" so the
versions/state is handled properly though.

(Furthermore, the "~reproducibleX" suffix as outlined on that page is
typically used when we fork packages from /elsewhere/ in Debian and, as
this project is part of the reproducible builds effort, there is no
naturally need to fork..)


   targetpath = os.path.join(dest_dir, 
os.path.basename(member_name)).encode(
   sys.getfilesystemencoding(), errors='replace')
  -with self.archive.open(member_name) as source, open(targetpath, 
'wb') as target:
  -shutil.copyfileobj(source, target)
  -return targetpath.decode(sys.getfilesystemencoding())
  +try:
  +with self.archive.open(member_name) as source, open(targetpath, 
'wb') as target:
  +shutil.copyfileobj(source, target)
  +return targetpath.decode(sys.getfilesystemencoding())
  +except Exception as exc:
  ^

Isn't this a bit too "wide" an exception class to catch? How narrow can
we safely make it?

  +raise ContainerExtractionError(member_name, exc)

I think I would also like to see:

 * A comment in the except block explaining why we might be seeing an
   exception in the first place.

 * A test :)


Best wishes,

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

Bug#905464: dh-elpa: Expects .desc file name to be based on package name (and does not consider "${pkg}-mode.desc")

[Axel Beckert]

Control: retitle -1 dh-elpa: Expects .desc file name to be based on package 
name (and does not consider "${pkg}-mode.desc")

Hi,

Axel Beckert wrote:
> Subject: dh-elpa: Expects .el file name to be based on package name (and does 
> not consider "${pkg}-mode.el")
 ^^ 
  ^^

Sorry, I meant ".desc" instead of ".el" as written in the body of the
body of the bug report:

> edit tpp files), dh_elpa expects a file named
> debian/.debhelper/elpa/tpp.desc despite debian/elpa lists
 
> "contrib/tpp-mode.el".
> 
> The content of the debian/elpa file seems to be ignored when calculating
> the path to the .desc file.
   
> dh_elpa: failed to open /home/abe/tpp/tpp/debian/.debhelper/elpa/tpp.desc
   
> → ls -l debian/.debhelper/elpa/*.desc
> -rw-r--r-- 1 abe abe 54 Aug  5 02:20 debian/.debhelper/elpa/tpp-mode.desc
   

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#891136: ITP: tools-deps-alpha-clojure -- functional API for dependency management and classpath creation

[Elana Hashman]

Okay, since I got a bug report about this, let's take a look at this
again for the latest tools.deps.alpha release 0.5.422. From deps.edn:

org.clojure/clojure {:mvn/version "1.9.0"}

* Good here: https://tracker.debian.org/pkg/clojure

org.apache.maven.resolver/maven-resolver-api {:mvn/version "1.1.1"}
org.apache.maven.resolver/maven-resolver-spi {:mvn/version "1.1.1"}
org.apache.maven.resolver/maven-resolver-impl {:mvn/version "1.1.1"}
org.apache.maven.resolver/maven-resolver-util {:mvn/version "1.1.1"}
org.apache.maven.resolver/maven-resolver-connector-basic {:mvn/version "1.1.1"}
org.apache.maven.resolver/maven-resolver-transport-file {:mvn/version "1.1.1"}
org.apache.maven.resolver/maven-resolver-transport-http {:mvn/version "1.1.1"}
org.apache.maven.resolver/maven-resolver-transport-wagon {:mvn/version "1.1.1"}

* Good here: https://tracker.debian.org/pkg/maven-resolver

org.apache.maven/maven-resolver-provider {:mvn/version "3.5.2"}
org.apache.maven/maven-core {:mvn/version "3.5.2"}
org.apache.maven/maven-settings-builder {:mvn/version "3.5.2"}

* We have 3.5.3, shouldn't be an issue: https://tracker.debian.org/pkg/maven

org.slf4j/slf4j-nop {:mvn/version "1.6.2"}

* We have 1.7.25, shouldn't be an issue: 
https://tracker.debian.org/pkg/libslf4j-java

org.clojure/data.xml {:mvn/version "0.2.0-alpha5"}

* This one might be a little hairy. We currently have 0.0.8 in Debian.
  Leiningen (and possibly other libraries) depend on it. If it's fully
  backwards compatible, we can upgrade. But we might wanna try being
  conservative and patch upstream.

s3-wagon-private {:mvn/version "1.3.1" :exclusions 
[ch.qos.logback/logback-classic]}

* We do not have this one.

org.clojure/tools.gitlibs {:mvn/version "0.2.64"}

* We do not have this one.

org.clojure/tools.cli {:mvn/version "0.3.5"}

* Good here: https://tracker.debian.org/pkg/tools-cli-clojure


Okay, that leaves us with new uploads needed for:

s3-wagon-private {:mvn/version "1.3.1" :exclusions 
[ch.qos.logback/logback-classic]}
org.clojure/tools.gitlibs {:mvn/version "0.2.64"}

Let's recurse. With the help of lein:

[s3-wagon-private "1.3.1"]
  [com.amazonaws/aws-java-sdk-s3 "1.11.184" :exclusions
  [[com.fasterxml.jackson.core/jackson-core]
  [com.fasterxml.jackson.core/jackson-databind]]]
[com.amazonaws/aws-java-sdk-core "1.11.184"]
  [com.fasterxml.jackson.dataformat/jackson-dataformat-cbor "2.6.7"]
  [commons-logging "1.1.3"]
  [joda-time "2.8.1"]
  [software.amazon.ion/ion-java "1.0.2"]
[com.amazonaws/aws-java-sdk-kms "1.11.184"]
[com.amazonaws/jmespath-java "1.11.184"]
  [com.fasterxml.jackson.core/jackson-core "2.5.5"]
  [com.fasterxml.jackson.core/jackson-databind "2.5.5"]
[com.fasterxml.jackson.core/jackson-annotations "2.5.0"]
  [org.springframework.build/aws-maven "4.8.0.RELEASE" :exclusions 
[[com.amazonaws/aws-java-sdk]]]
[org.slf4j/jcl-over-slf4j "1.7.5"]
[org.slf4j/slf4j-api "1.7.5"]

Of s3-private-wagon's deps, we're also missing
com.amazonaws/aws-java-sdk-s3 (and its deps
com.amazonaws/aws-java-sdk-core software.amazon.ion/ion-java
com.amazonaws/aws-java-sdk-kms com.amazonaws/jmespath-java) and
org.springframework.build/aws-maven; everything else looks okay.

[org.clojure/tools.gitlibs "0.2.64"]
  [com.jcraft/jsch.agentproxy.connector-factory "0.0.9"]
[com.jcraft/jsch.agentproxy.core "0.0.9"]
[com.jcraft/jsch.agentproxy.pageant "0.0.9"]
[com.jcraft/jsch.agentproxy.sshagent "0.0.9"]
[com.jcraft/jsch.agentproxy.usocket-jna "0.0.9"]
  [net.java.dev.jna/jna-platform "4.1.0"]
  [net.java.dev.jna/jna "4.1.0"]
[com.jcraft/jsch.agentproxy.usocket-nc "0.0.9"]
  [com.jcraft/jsch.agentproxy.jsch "0.0.9"]
  [org.eclipse.jgit "4.10.0.201712302008-r"]
[com.googlecode.javaewah/JavaEWAH "1.1.6"]
[com.jcraft/jsch "0.1.54"]
[org.apache.httpcomponents/httpclient "4.5.2"]
  [commons-codec "1.9"]
  [org.apache.httpcomponents/httpcore "4.4.4"]

libjsch-agent-proxy-java is in Debian but needs a version bump from
0.0.8 to 0.0.9. jgit is also in Debian but needs a major version bump
from 3.7.1 to 4.10.0.


In summary...

Needs version bump:
- data-xml-clojure to 0.2.0-alpha5
- libjsch-agent-proxy-java to 0.0.9
- jgit to 4.10.0

Needs new upload:
- s3-wagon-private "1.3.1"
- com.amazonaws/aws-java-sdk-core "1.11.184"
- com.amazonaws/aws-java-sdk-kms "1.11.184"
- com.amazonaws/aws-java-sdk-s3 "1.11.184"
- software.amazon.ion/ion-java "1.0.2"
- com.amazonaws/jmespath-java "1.11.184"
- org.springframework.build/aws-maven "4.8.0.RELEASE"
- org.clojure/tools.gitlibs "0.2.64"

I'm happy to package the two new Clojure dependencies, s3-wagon-private
and tools-gitlibs. Anyone wanna package some AWS Java stuff?

- e


signature.asc
Description: Digital signature

Bug#905401: permit access to apt repositories during builds

[Jonathan Nieder]

Josh Triplett wrote:

> Why don't we make a specific exception for d-i in the short term, in the
> hopes that in the long term we'll have a way to handle dependencies on
> sources

Thanks, that makes a lot of sense to me.

I retract my second in message #13, but I'd be happy to review a patch
that provides a more targeted carve-out to support existing practice
without making the problem worse.

I also would be happy to see a separate thread to discuss expanding
supported packages that can be put in build-deps, for example as an
email thread in debian-boot@ or as a wishlist bug against dpkg with
debian-boot and a...@packages.debian.org cc-ed.  If I understand
correctly, it's a little different from build-time deps because there
is not a standard way to install a udeb or deb on the build system.

Thanks and hope that helps,
Jonathan

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

[Theodore Y. Ts'o]

Thanks for the report.  I've checked in a fix for this into the
e2fsprogs git repository, and it will be in the next release of e2fsprogs.

  - Ted

Bug#905464: dh-elpa: Expects .el file name to be based on package name (and does not consider "${pkg}-mode.el")

[Axel Beckert]

Package: dh-elpa
Version: 1.13

Hi,

when trying to switch the package tpp (which also ships "tpp-mode.el" to
edit tpp files), dh_elpa expects a file named
debian/.debhelper/elpa/tpp.desc despite debian/elpa lists
"contrib/tpp-mode.el".

The content of the debian/elpa file seems to be ignored when calculating
the path to the .desc file.

Error message:

dh_elpa
Using elpa package name tpp
emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f 
package-initialize -l dh-elpa.el -f dhelpa-batch-install-file 
debian/tpp//usr/share/emacs/site-lisp/elpa-src contrib/tpp-mode.el 
/home/abe/tpp/tpp/debian/.debhelper/elpa 1533407657
dh_elpa: failed to open /home/abe/tpp/tpp/debian/.debhelper/elpa/tpp.desc
make[1]: *** [debian/rules:23: override_dh_elpa] Error 2

Existing file:

→ ls -l debian/.debhelper/elpa/*.desc
-rw-r--r-- 1 abe abe 54 Aug  5 02:20 debian/.debhelper/elpa/tpp-mode.desc

Since this is not primarily an emacs mode package but only ships an
emacs mode as an add-on, the package is not named elpa-tpp-mode or
tpp-mode but just tpp.

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

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

Versions of packages dh-elpa depends on:
ii  debhelper   11.3.5
ii  dh-make-perl0.102
ii  emacs25 1:25.2+1-8
ii  libarray-utils-perl 0.5-1
ii  libconfig-tiny-perl 2.23-1
ii  libdebian-source-perl   0.102
ii  libdpkg-perl1.19.0.5
ii  libfile-find-rule-perl  0.34-1
ii  libtext-glob-perl   0.10-1
ii  perl5.26.2-6

dh-elpa recommends no packages.

dh-elpa suggests no packages.

-- no debconf information

Bug#905463: leatherman: FTBFS - test hangs

[Andreas Beckmann]

Source: leatherman
Version: 1.4.2+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

leatherman FTBFS in the buildd environent on all architectures:
https://buildd.debian.org/status/package.php?p=leatherman

The testsuite seems to hang or take forever:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>/leatherman-1.4.2+dfsg'
# Tests are locale-dependent
LC_ALL=C LC_CTYPE=C dh_auto_test
cd obj-i686-linux-gnu && make -j4 test ARGS\+=-j4
make[2]: Entering directory 
'/<>/leatherman-1.4.2+dfsg/obj-i686-linux-gnu'
Running tests...
/usr/bin/ctest --force-new-ctest-process -j4
Test project /<>/leatherman-1.4.2+dfsg/obj-i686-linux-gnu
Start 1: leatherman tests
E: Build killed with signal TERM after 150 minutes of inactivity


Andreas

Bug#905437: libreoffice-common: AppArmor denies access to mesa shader cache

[intrigeri]

Vincas Dargis:
> Cool, I will work on MR.

:)))

Also, would be good to have a 2.13.x upstream release with the
fixes/improvements we need.

> "Why not" could be "don't want to manage backports too much" :) .

Right, at least not without being aware of a real need.

Cheers,
-- 
intrigeri

Bug#904699: patch with solution

[Nicolai Lissner]

Meanwhile, I've tested this and it works fine for me.

patch attached.

--- src/parser_rfc822.c~	2013-07-13 10:10:25.0 +
+++ src/parser_rfc822.c	2018-08-05 00:15:58.034730797 +
@@ -35,7 +35,7 @@
 #include 
 #include 
 
-#define READSIZE 16384
+#define READSIZE 65536
 
 int di_parser_rfc822_read (char *begin, size_t size, di_parser_info *info, di_parser_read_entry_new entry_new, di_parser_read_entry_finish entry_finish, void *user_data)
 {

Bug#905433: git-debrebase: debrebase new-upstream fails with "uninitialized value"

[Ian Jackson]

Johannes Schauer writes ("Re: Bug#905433: git-debrebase: debrebase new-upstream 
fails with "uninitialized value""):
> I was reading the dgit-maint-debrebase man page wrongly. Here is where I
> tripped:

Thanks for that very helpful explanation.

I think you've probably figured this out now, but in your situation
git-debrebse convert-from-gbp will do what you need.

I'm increasingly of the opinion that that subcommand needs to be
renamed, in addition to improving the docs.

> Quoting Ian Jackson (2018-08-04 18:15:47)
> > This error message is fixed in git but not in 6.4.
> > My current branch says this instead:
> > 
> >   git-debrebase: error: found unprocessable commit, cannot cope; bare
> >   dgit dsc import: (commit d3481fe48afe150f38f331048abe6452b8389723)
> >   (d.0x30 0x32)
> > 
> > Related UI bugs are:
> > 
> >   #905005 Want better user hinting for unprocessable commits
> >   #905279 Suggest `dgit convert-from-dgit-view` sometimes
> 
> Okay, that would tell me that it cannot cope with a commit that was created by
> dgit very early on in my git history. From this error message I would still 
> not
> know what to do next.

Indeed.  Hence, in particular, #905005.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#905462: ITP: boohu -- Break Out Of Hareka's Underground -- a roguelike game

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: boohu
  Version : 0.9.0
  Upstream Author : Yon 
* URL : https://download.tuxfamily.org/boohu/index.html
* License : ISC
  Programming Lang: Go
  Description : Break Out Of Hareka's Underground -- a roguelike game
 Break Out Of Hareka's Underground (Boohu) is a roguelike game mainly
 inspired from DCSS and its tavern, with some ideas from Brogue, but aiming
 for very short games, almost no character building, and a simplified
 inventory.

Bug#905459: Acknowledgement (nautilus: Can't unlock LUKS encrypted volume : the function "bd_crypto_luks_open_blob" called but not implemented)

[Tuxicoman]

I think I found a solution from https://github.com/pop-os/pop/issues/16
3

Just install the missing package "libblockdev-crypto2" and restart the
computer

So maybe the fix is just to add this package as a dependency to
nautilus.

Best regards,

Bug#905461: ia64: architecture is incompatible with CONFIG_SCHED_STACK_END_CHECK

[Jason Duerstock]

Source: linux
Severity: normal

On ia64, enabling the CONFIG_SCHED_STACK_END_CHECK kernel option renders the 
kernel unbootable.
The "stack end" magic number that is set to enable this feature is overwritten 
by the ia64 processor backing store.
Is it possible to override a global kernel setting in the arch config file?

Thanks,

Jason

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.17.0-1-mckinley (SMP w/2 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)
LSM: AppArmor: enabled

Bug#905459: nautilus: Can't unlock LUKS encrypted volume : the function "bd_crypto_luks_open_blob" called but not implemented

[Tuxicoman]

Package: nautilus
Version: 3.26.3.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
I want to open a encrypted disk partition through Nautilus by double
clicking on it

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
If I double click on on the volume in Nautilus, it doesn't work.
If I open the encrypted disk volume in command line with crytpsetup, it
works.

   * What was the outcome of this action?
If I double click on on the volume in Nautilus, I get an error message
saying :
Error unlock /dev/sdd1 : the function 'bd_crypto_luks_open_blob' called
but not implemented!

   * What outcome did you expect instead?
Open the encrypted as it works on Debian 9.



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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-3
ii  gsettings-desktop-schemas  3.28.0-1
ii  gvfs   1.36.2-1
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-5
ii  libcairo-gobject2  1.15.10-3
ii  libcairo2  1.15.10-3
ii  libexempi3 2.4.5-2
ii  libexif12  0.6.21-5
ii  libgail-3-03.22.30-2
ii  libgdk-pixbuf2.0-0 2.36.12-1
ii  libglib2.0-0   2.56.1-2
ii  libglib2.0-data2.56.1-2
ii  libgnome-autoar-0-00.2.3-1
ii  libgnome-desktop-3-17  3.28.2-2
ii  libgtk-3-0 3.22.30-2
ii  libnautilus-extension1a3.26.3.1-1
ii  libpango-1.0-0 1.42.1-2
ii  libpangocairo-1.0-01.42.1-2
ii  libselinux12.8-1+b1
ii  libtracker-sparql-2.0-02.0.3-3
ii  libx11-6   2:1.6.5-1
ii  nautilus-data  3.26.3.1-1
ii  shared-mime-info   1.9-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.28.3-1
ii  gvfs-backends1.36.2-1
ii  librsvg2-common  2.40.20-2

Versions of packages nautilus suggests:
ii  eog 3.28.3-1
ii  evince [pdf-viewer] 3.28.2-1
pn  nautilus-extension-brasero  
ii  nautilus-sendto 3.8.6-2
ii  totem   3.26.1-1
ii  tracker 2.0.3-3
ii  vlc [mp3-decoder]   3.0.3-1-2
ii  xdg-user-dirs   0.17-1

-- no debconf information

Bug#905460: ITP: opencamlib -- C++ library for creating 3D toolpaths for CNC machines

[Kurt Kremitzki]

Package: wnpp
Severity: wishlist
Owner: Kurt Kremitzki 

* Package name: opencamlib
  Version : 2018.08
  Upstream Author : Anders Wallin 
* URL : https://github.com/aewallin/opencamlib
* License : LGPL-2.1
  Programming Lang: C++
  Description : C++ library for creating 3D toolpaths for CNC machines

OpenCAMLib is a 3D CAM library in C++ with Python bindings. The main
functionality it provides is axial and radial cutter-projection algorithms
against polyhedral (triangulated) surfaces.

Along with OpenVoronoi, OpenCAMLib was recently relicensed to allow for
inclusion in FreeCAD's Path Workbench.

I plan on packaging this under the Debian Science Team.

Bug#905401: permit access to apt repositories during builds

[Josh Triplett]

On Sat, 4 Aug 2018 06:06:22 +0100 Ian Jackson  
wrote:
> Package: debian-policy
> Version: 4.2.0.1
> Tags: patch
> 
> Apropos of discussion in #813471:
> 
> Paul writes:
> > In addition, d-i relies on access to the apt repo for the system.
> > I can imagine other uses of that, so I added a carve-out for that.
> 
> In general I think this should be done by saying that packages may
> access the apt repository.  Binaries, and sources, because packages
> cannot depend on each others' sources and implementing that is a lot
> of work.
> 
> See
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813471#126
> for a more extended rationale for permitting access to sources
> as well as binaries.
> 
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index d6a21b8..2d6f9ea 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -288,6 +288,13 @@ For packages in the main archive, no required targets 
> may attempt
>  network access, except, via the loopback interface, to services on the
>  build host that have been started by the build.
>  
> +Nevertheless, required targets may use ``apt`` to access the apt
> +repositories provided by the build environment (which are those which
> +were used to resolve the package's build-dependencies).  If
> +appropriate, :ref:`Built-Using `` must then be
> +declared.  It is permitted to download both binaries and/or sources.
> +However, this facility should not normally be used.
> +

This seems potentially quite problematic.

First of all, this isn't something we should allow arbitrary packages to
use. If we have to do this at all, I'd suggest that we explicitly say
that packages should *not* do this in general, and that if they must do
so, any such usage should be explicitly discussed and approved on
debian-devel first, and only after determining that no other mechanism
will work.

Second, I don't think it's appropriate to guarantee that any package
*other* than those with declared Build-Depends will exist. It's
completely reasonable to build a package with a repository containing
nothing other than its build-dependencies.

Third, under normal circumstances you are *not* required to have deb-src
lines in sources.list. This would be the first instance I'm aware of
that would require that.

In the absence of some specific dependency mechanism, this seems like a
fast way to end up with packages that will only build in particular
environments that aren't fully described by their declared requirements
in debian/control.

Why don't we make a specific exception for d-i in the short term, in the
hopes that in the long term we'll have a way to handle dependencies on
sources (and, for that matter, ways to incorporate the Build-Depends of
another package into your own Build-Depends, though sometimes you'll
just need a subset).

Bug#759410: Different approach for safe-rm

[Dimitri John Ledkov]

I agree that's the generic way forward for safe-rm in light of usrmerge but
did not feel it was right to make up such a path in Ubuntu. I'm happy with
such a solution for Debian, and for Ubuntu. I'm off for two weeks, but will
migrate Ubuntu over to that if and when available for merging/syncing into
Ubuntu.

Sorry for top post. Writing from phone.

On Sun, 5 Aug 2018, 00:21 Francois Marier,  wrote:

> I took a look at the details of the diversion that the latest version of
> dash sets up and it's really quite complicated. It's not clear that I could
> easily get it right, even copying that code, and the consequences of
> getting
> it wrong could be disastrous.
>
> So instead I went for an easier approach: install the rm symlink in
> /usr/share/safe-rm/bin/ and then add that to the front of the PATH in
> /etc/profile.d/safe-rm.sh.
>
> That seems to work both for login shells (on a virtual terminal) and for
> interactive shells (e.g. gnome-terminal) after logging out and logging back
> in.
>
> The downside is that it may not for shells which are not Bourne-compatible.
> I believe it works in bash, dash, ksh and zsh, but I could be wrong. I'm
> happy to accept patches to make it work on other shells of course.
>
> Francois
>
> --
> https://fmarier.org/
>

Bug#759410: Different approach for safe-rm

[Francois Marier]

I took a look at the details of the diversion that the latest version of
dash sets up and it's really quite complicated. It's not clear that I could
easily get it right, even copying that code, and the consequences of getting
it wrong could be disastrous.

So instead I went for an easier approach: install the rm symlink in
/usr/share/safe-rm/bin/ and then add that to the front of the PATH in
/etc/profile.d/safe-rm.sh.

That seems to work both for login shells (on a virtual terminal) and for
interactive shells (e.g. gnome-terminal) after logging out and logging back
in.

The downside is that it may not for shells which are not Bourne-compatible.
I believe it works in bash, dash, ksh and zsh, but I could be wrong. I'm
happy to accept patches to make it work on other shells of course.

Francois

-- 
https://fmarier.org/

Bug#905375: RFS: bitz-server/2.0.1-1

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Herbert,


Am Samstag, den 04.08.2018, 09:05 -0300 schrieb Herbert Fortes:
> Hi,
> 
>  > -BEGIN PGP SIGNED MESSAGE-
>  > Hash: SHA512
>  >
>  > retitle 905375 RFS: bitz-server/2.0.1-1
>  > thanks
>  >
> 
> I ran 'blhc --all ../*.build and there are some
> 
> CXXFLAGS missing (-fPIE)
> LDFLAGS missing (-fPIE -pie)
> 
> I saw debian/rules has 'hardening=+all' but can
> you please add:
> 
> export DEB_CXXFLAGS_MAINT_APPEND  = -fPIE
> export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
> 

Many thanks!!

Changed, tested and uploaded to mentors again.


> 
> 
> Regards,
> Herbert
> 

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+AHX8jUOrs1qzDuCfifPIyh0l0FAltmJtIACgkQCfifPIyh
0l2YXQ/+LAJOMGzvP43zHLmknl8hKBogc3e//fy14vP2TNFYqhlA6FK0QOBRzgxe
04NmaWIvmTmkHhiaXCYbXJMw4i6aT+UYF+xfrRyD6bKlGQaPe5m/4JLKWctD9aze
4X7nO/vs1fljr5LXz2x4qQh4gCAPaEH4QW3p57zRdBQdlFEl4fHmtxBvRuPjBXRi
+447lliAcKjSHL9M1ojfeOhr4R4nkj8Bx6nleRBJw3dC9p2vd7nMXSvgp6e7DywO
zl46VtWhslRmxiffJ2WqVzXYpNrsJjpK2xIQ4b/YQCbafCiHTSJ/1BsBu896bXVV
uee1b60BgYTRBQS+PbExaF6HnV4/J/nFCqA5lMd1NKnQFVYuDQp4r+7zY4Q+uioJ
pYWJ87cprXDXnP17tcazx0ti4hFVemzzbF53fUQ1ZKfF2rURuZ571WUKKOxdjLm/
sCO0bb1sZhLkvsGpDEhkMg+75HG67x8Q3PSgG1VUZ20BL09xE1Eg0nZvbcnHylwO
QrmNOFhnWmTiWzaPtgJOUpLVIGhxn+Itxrrs7XRoKmQbghTldjq8AfJsdIzIsBTH
xcee9OR65sr6ZfsPkJdoiiHO5BlLb0A6SQN6LwpVstuB2JQYdguVWxlPy/X6berh
/7kG2qmxsu1VbV3FSYmPX0TFAq7ZoNNzlYQdXkD9xVGki0kGBuc=
=5ZED
-END PGP SIGNATURE-

Bug#905363: fails to start on rotated screen

[Simon McVittie]

On Fri, 03 Aug 2018 at 17:09:24 +0200, W. Martin Borgert wrote:
> On a device with rotated screen, gdm3 fails to start
[...]
> I tested the patch on the Debian package and it seems to work
> well on my machine. Please consider applying it. Thanks!

I've uploaded this to experimental, but not unstable yet (sorry, I only
have a test environment for GNOME 3.29 right now). Any GNOME team members
who are still able to test 3.28 are welcome to upload the same change
to unstable.

smcv

Bug#902763: clojure: Include new CLI tools and runner scripts

[Elana Hashman]

Hi Daniel,

Thanks for the report! My apologies for not getting back to you
sooner; the maintainer email for Clojure was incorrect so I didn't
receive a copy of this bug. I just uploaded a fix for that today.


I would like to package the new Clojure CLI scripts, and have an ITP
open here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891141

However, as you noted, the new CLI has a dependency on
tools.deps.alpha. Unfortunately, that package has a very long
dependency tree, many of which are not currently in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891136

It took me about a year to package a similarly complex dependency tree
for Leiningen, and maintaining that package has been eating up most of
my development cycles. If you are interested in working on packaging
some of tools.deps.alpha's dependencies, I'd be happy to review and
sponsor uploads.

It would be really great to get this into the buster release as the
default CLI for clojure 1.9, but I think it is going to be a lot of
work :)

Cheers,

- e


signature.asc
Description: Digital signature

Bug#904102: locales: Interface is in english but french is set.

[Aurelien Jarno]

control: retitle -1 gnome: Interface is in english but french is set.
control: reassign -1 gnome 

On 2018-07-19 19:30, Alexandre wrote:
> Package: locales
> Version: 2.27-3
> Severity: normal
> 
> Dear Maintainer,
> 
> I set my interface in french (i have only FR in locales list)
> 
> But not working, only english.
> 
> In gnome setting panel i have mixed language : Menu is in French and content 
> is
> in english.
> 
> Thank you
> 
> alexandre@debian:~$ locale
> LANG=fr_FR.UTF-8
> LANGUAGE=
> LC_CTYPE="fr_FR.UTF-8"
> LC_NUMERIC=fr_FR.UTF-8
> LC_TIME=fr_FR.UTF-8
> LC_COLLATE="fr_FR.UTF-8"
> LC_MONETARY=fr_FR.UTF-8
> LC_MESSAGES="fr_FR.UTF-8"
> LC_PAPER=fr_FR.UTF-8
> LC_NAME="fr_FR.UTF-8"
> LC_ADDRESS="fr_FR.UTF-8"
> LC_TELEPHONE="fr_FR.UTF-8"
> LC_MEASUREMENT=fr_FR.UTF-8
> LC_IDENTIFICATION="fr_FR.UTF-8"
> LC_ALL=

This looks all well configured from the glibc point of view. It can be a
Gnome issue though, reassigning the bug.

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

Bug#905458: pari: enable OpenPGP verification of upstream source with uscan

[John Scott]

Source: pari
Version: 2.11.0-1
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It doesn't seem that the package has a VCS, so I've made a patch to do
as the subject says and am including it here instead.

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

*** /home/john/pari.diff
diff -urN a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
- --- a/debian/upstream/signing-key.asc 1969-12-31 19:00:00.0 -0500
+++ b/debian/upstream/signing-key.asc   2018-08-04 17:03:26.626501967 -0400
@@ -0,0 +1,77 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+
+mQINBFCtY5YBEAC5Wdpmw7015pqAVAJ0LAhyY74ZkqHURVsWZOfwZDJm4MDxExpz
+iedKpiMAttoD4aGaG9ON5VPfjIIw7HcnSRvoUlyQOWY+K1XGIU9bTclHingTQrKy
+uZm7qRK8viP+QCdg6E5dse7I3m7CIkP89ejcG3BmYxaJOlTwmI5/dvxvqZjAMy+L
+U3XqSJ2C/fyZXFYkLcdfbFbV/QNj9PQtfInCr3EfpvyQmffkPXPDoNNp6Ppu2ZCi
++O1lsEtdaHKwxErstuNJ4OvmE3ZKvDSZBhT4u5vbv1oz7LWroSrVF98xXTjBxCJs
+ezYCNTmscZFuVtDy3j0D1KslVDa8H16KEoQ0fCD8a0RzULemzmsBTuxWzrudQhdI
+12Zcg0VkkkbA8dLAxQnz1LRJKbh2yNbuP4uIoGBdp4ywKtgNmgz+C7XbEwS1wgcO
+Jj6gvjwd3ukPcN0XnBhurmM2SojpdR1kg0w+JFt2DjbabobN61vapcDcy+Op6Y6f
+4l67fv6Q2ZtpI+VaercG6eYlOQr8hiV0b9L5lxwrEPAZT9fCZEbCvKfzrLN1N0WJ
+T3tJCl0rdo1oy4BdJ8bEbg9wslzd4YbJIkCe2faH5njnziFXZ/sTl0stAty8ZA8l
+736h+wuolHeNKDjYK5tL7lsiOj70kezRUvayTEnTIWa1N3Vf8EJ5fUAemQARAQAB
+tCRCaWxsIEFsbG9tYmVydCA8YmFsbG9tYmVAZGViaWFuLm9yZz6JAjgEEwECACIF
+AlCtY5YCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEI8OfCtFIuOH5g0P
+/29fRCukD9qk/+i83psv61krUcRqmFt1YbECR5Ij7u0ZnfEbx2g+3+hZn1682O2T
+ayS5ealuKOzqAn2bKOISo2bwJUECNH9PQM5gro3bBTtDDRwtmDfqMzSY4YHFM5qJ
+bbKNEnTeFpo4FtuXg8lrm1JNVproWI8fgVV5wsvsYPSv9rkY6dWP1ZWjw1lDn0Tr
+JJjQbwTql5mYvkx3jQTdD4dKoknXpYfkKIgvbzGPpwESyQv8tR07ILUHVYAoeBdB
+8GNlzTzxOWYNZ69hctJKXsgjnB1vMZ/bWCnRN0m5JBIa7jDCfzkpQSOIp0rSxJui
+bw1UppvhBaJiXQl1bIWup1kgKriDfkfidvnFJtAa9Hs0Z3sTbwN8vN0VGX1l3vQi
+/ZLzD+WCA7L+WnLk/BDoGKZ11s0JyCwQiNtXk9ol2z6SjzNRqmvX1EHHVSvj6z5c
+qq+uyKXTu5VaTZXv7rf1B6NKfNEMsfOAF2UYDhllQc5XkSQgjsBtYpHb8B7tn08c
+uiPXu/xDRlHoydXmBpompR34G6xKisRN8iC/AaHBzFcuRQLhXF74sMsriOoo0kcK
+pzw4d4onmWvkXWXAZyzXJrICN+nYMItgsDDjQ9UvZANPkz5j4ytRDIpYZR+fIveF
+IDcsfeZH+Ho+inc9aqj1wFxXo5UFL8wsNGbRM6uO2Bq6tDJCaWxsIEFsbG9tYmVy
+dCA8QmlsbC5BbGxvbWJlcnRAbWF0aC51LWJvcmRlYXV4LmZyPokCOAQTAQIAIgUC
+WmziAAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQjw58K0Ui44e9uQ/8
+ChUkbpmTi+SnfY4P3l4TPJAuyR9HidASn7D3hRPRaseipuwNnXJXj98V2UWB0NRj
+jpaPiHdmXD9x4C2VIDSonUvp3NkazpCkMK2ZZEdOJmPQZIVHx8TE8Cxr1S0TvqqZ
+jTrX5/hu4W6ezwqhNEzSjVOVcYB3knkFPAz3+25aic7IpxbuvdwKFwpdrJ7Pv+al
+vDt/+Hz82J29pdHncynBt9NcUa9d5/i8y57MdqNoKTQllW+uT/rUktSOC/080fZy
+DYryVzlDJfX9YYVrO2amp9ZDnmeLrvmf63gNO3lPvN0WjQslJJL96zD+X0VI/QDz
+QavS+XhlTNrgxpJEt53DfMvm+Wd2o38f+6mP7V84NuThH4JtyOpXli0RrbdAXetC
+lPptap3HvpT/u3ct31vAdmNYtORhTq+gtz0/53CN0F9CkKJgi9tcAGxUNJAtdLMD
+xJSDcMRH44uzyOnQHYt3+z0RJwAEssK/bY07ivTbKaQIvVaWC8X7ak8JojACa+YS
+6usB3mCpjdYaVVMfqy/wLEGuOuhpPnGvCEL0346xfdggEnytYe2TeP1Cfcf3fI3p
+drm6PrLZrK2d6beUb21bdb8WtaXaJvGwbLfAE9VVxPMCZonBbCFyuZeuTfdqiQ/x
+apN51B+9cCfA+cRWs+hVueib+jFdgzmync0iS0wzaWK0M0JpbGwgQWxsb21iZXJ0
+IDxCaWxsLkFsbG9tYmVydEBtYXRoLnUtYm9yZGVhdXgxLmZyPokCOAQTAQIAIgUC
+UK1m+AIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQjw58K0Ui44fBpQ//
+fzjbbYzSbGKaq98/syPCXIYtKEM6lOiBIHsJz8UQO5s9TQDdCZDl1aVrWVcIbsW9
+/k+SYXhQOGDo2PPx5DBBqhhklKs/FR4A/dfw1rEhbMY4RVXx5kq3gR/kOlWkJDGU
+GpVZL/4i16I/2BuI9wTxIcrD4XR9WqVMq3KnrKGaTcwMY4leFoKwtpiM9/fXvP6D
+l2R5mdhokOv/MxPKXg5WR5DBFPpizBuUPIpYJKr8WanI2XNcB6D+ZVwf16xlgovb
+SZWqIhh5r3haHZT+wAIJn5y5bnlo28iTQYrxZPoSJRdBQyGocavLS8POF3jh7Hs0
+siAs1xGOiw5YKbHJkXiV+VcFzdAAG9EbA0lVC/gRa16BIVCDcPfLPxY6WuiBYUEz
+TOvma90yX94jzUUzQbyMrDlBeWM6+rGrwnv7SXF+zDR8B1c/tWp57IV6CgW7bfO1
+HF8zy5juO8sIs6n3TVUaY18vc/uk+GcD09oJyOz/mXq3w/cvMi09M1kZ7lq8BfKX
+PyQYD/zr2DvnuqHM4CX3TfOc3FLYX3Qg2Eqn67tAOIkmJf+tNcK2meP1w3Q6PCoV
+X05TsxXEX+3m1Axz2HZQwVdcZxXho0jSNP6wWEGrvJmGE7Ue+I1rS+Mq/RsbyDNR
+qvWZvCdmucwdlm/+NpJto0YrkO04WXsAdIapjI7+cvu5Ag0EUK1jlgEQALP4KvqO
+s/D6pWUpgRWNm3S+fG+DsFVX3BrU9mJw2XlU8bYTfkgbOASD+4oI62HRwTT1v9I6
+brUaSGf8owb4TIMVqIcXjLCl1VGoEt7/duOeG9UbRbwA2mo4M/U2K/qd6C0+OH2s
+tfotP4PNITqjtgUUW2N3SaLicIkc6e4sYlS23UaJBO+uayOazEIf8UnZMJOQF0Jj
+q/GCt8KhZIBHsnVgD0h8ij0fimApnYpMDBOnViUDEZl2Civr/S2FzuE42EeR7BHc
+T0L2jZVRNVdAjYuIfU0vrZVDvSxk+v2Sglm31YGu2mRPUTZSk3FaHl5n7Vk1vZJ6
+/jmiRAEBzC+Y48Wp1hoPweNDgTuX/C2Y+KjrEW6FO3R/wKgja7F4cCL8D0dcfB7r
+MeiOTYsj66fhFxTC49+xau8CejMTbwkmP22NRHsA8y2mlYZtAiGZ91FJcDnmia+S
+z+CGT8CIyd2h5nrDOYeiubDMi5hQ3Ok48ixHpMf/VgqfhNWs6E99Tw9rInP7Y+Y1
+MQEIxOOtInvNsv5zxEWNupm59VMxlydeI+NXNKI2ar11Xicag9vu690IUVAM8GQN
+wZV7oLVw+dOEGilXClfhsyf3m5kRT6nzZ2Oam4nMVVUjnc+/WwDLOdUoixuBGgV4
+vg2GxbGATL38LmGILyVl5n5MuNz+eP9FTmH1ABEBAAGJAh8EGAECAAkFAlCtY5YC

Bug#861856: oping: CSV output uses locale decimal separator

[Simon Valiquette]

Package: oping
Followup-For: Bug #861856

> When running noping -O foo.csv 127.0.0.1, I get file output like:
> 
> 1493922621,709,"127.0.0.1",11,28
>
> This is somewhat unfortunate, since it's not really comma separated
> values any more.
>
>(My locale has «,» as its decimal separator.)

I am not sure what exactly you consider to be a bug, as you didn't show
an example of what you expected instead.

If it is about the IP, I must remind you that this is NOT a decimal number,
and thus dots are always used (I am not aware of any language that enforce
a different typographical convention that would be here technicaly wrong).


AFAIK, it is fully compliant with RFC-4180 and others.

https://tools.ietf.org/html/rfc4180

My 2nd guess is that you were not aware that you can enclose with a '"'
character the start and the end of any field, even when not strictly
required.  But doing so here is a good idea, as I can imagine securities
issues in some extreme case, perhaps with some unicode domain names or
bogus ones (passed fake domains names that include comas or \n) so as to exploit
scripts that didn't properly sanitized their parameters.

I think I will mark this as WONTFIX, as "fixing" it is likely to break
many scripts that expect those quotes to always be included, and the
current behaviour make sure that scripts are aware that they could have
to handle special strings and characters (it is also much easier that way).

And so I suggest that you or the maintainer simply close this bug.

Have a nice day,

Simon Valiquette


-- 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_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages oping depends on:
ii  libc6 2.24-11+deb9u3
ii  libncursesw5  6.0+20161126-1+deb9u2
ii  liboping0 1.9.0-1+b1
ii  libtinfo5 6.0+20161126-1+deb9u2

oping recommends no packages.

oping suggests no packages.

-- debconf-show failed

Bug#858159: [installation-guide] Memory requirements for installing Stretch have increased since Jessie

[Holger Wansing]

Hi,

John Paul Adrian Glaubitz  wrote:
> 
> 
> > On Aug 3, 2018, at 9:26 PM, Holger Wansing  wrote:
> > 
> > Since desktop environments like Gnome and KDE still move forward and add
> > new features, it seems likely to me, that memory requirements could change
> > over 4 years.
> 
> That doesn’t necessarily mean they need more RAM. KDE5 has been seriously 
> improved over KDE4 when it comes to performance. So even here you probably
> need less memory now. Don’t know about GNOME though.
> 
> > In Jessie and Stretch, we have
> >With desktop| 256 megabytes | 1 gigabyte| 10 gigabytes
> > 
> > What do people think about doubling the minimum value from 
> > 256 to 512 megabytes at least?
> > (Since Gnome is the default desktop, we should choose values here, that will
> > work almost for Gnome. Orienting on LXDE or Xfce is probably not the right
> > thing ...)
> 
> Did you do some testing inside a VM with different memory configurations to 
> get some data points?

That's what the OP of this bug did, right?
I just tried to push things forward ...

> Just bumping the numbers because we haven’t done so for a while makes them
> less meaningful, in my opinion.

That sounds also reasonable, yes.


Holger


-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#904685: diffoscope: RuntimeError when trying to extract an encrypted file (.bmp)

[Ricardo Gaviria]

Hi Chris,

Based on this bug, please find attached a proposed patch for handling this
error gracefully by catching any exceptions caused by trying to open an
encrypted file in an archive. and forwarding it on as a
*ContainerExtractionError*.

I would gladly appreciate some feedback. I tried to update the changelog as
best as I understood here
.

Additionally, I see that I could have also just submitted a merge request
via salsa.debian.org. What is the usual workflow, email patches or merge
requests?

Regards,
Ricardo

On Fri, Jul 27, 2018 at 5:28 PM Ricardo Gaviria 
wrote:

> Perfect! thanks for the clarification. Will look into it so ;)
>
> P.S. I love diffoscope!
>
> On Fri, Jul 27, 2018 at 5:26 PM Chris Lamb  wrote:
>
>> Hi Ricardo,
>>
>> > By the way, if this is a lower priority bug than others. I will gladly
>> have
>> > a look into the issue and try and resolve it, provided that we agree on
>> the
>> > expected behaviour of the tool under such a scenario.
>>
>> AIUI the *ideal* behaviour would be that encrypted files would:
>>
>>   a) Not cause a traceback
>>   b) Be marked as such in the diff (see `add_comment` in the code)
>>   c) Be compared in a fallback (ie. binary) fashion
>>
>> Hope that helps. :)
>>
>>
>> Regards,
>>
>> --
>>   ,''`.
>>  : :'  : Chris Lamb
>>  `. `'`  la...@debian.org / chris-lamb.co.uk
>>`-
>>
> --
> Regards,
> Ricardo Gaviria
> Software Engineer, UniteLabs
> *M: *+41 77 956 2376 <+41%2077%20956%2023%2076>
> *W: *http://unitelabs.ch
> *In: *https://www.linkedin.com/in/ricardogaviria/
>
> --
Regards,
Ricardo Gaviria
Software Engineer, UniteLabs
*M: *+41 77 956 2376
*W: *http://unitelabs.ch
*In: *https://www.linkedin.com/in/ricardogaviria/
From ba6c74914827cb5ace2c15a609d8c1be5c553ce8 Mon Sep 17 00:00:00 2001
From: Ricardo Gaviria 
Date: Sat, 4 Aug 2018 22:46:10 +0200
Subject: [PATCH] Handle error when encrypted file is exctracted inside archive

---
 debian/changelog  |  5 +
 diffoscope/comparators/zip.py | 10 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 93bd3dc..330f6f5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,8 @@
+diffoscope (100.0~reproducible1) UNRELEASED; urgency=medium
+  
+  [Ricardo Gaviria]
+  * Handle error when trying to extract an encrypted file from archive
+
 diffoscope (100) UNRELEASED; urgency=medium
 
   * WIP.
diff --git a/diffoscope/comparators/zip.py b/diffoscope/comparators/zip.py
index e77979c..b033abf 100644
--- a/diffoscope/comparators/zip.py
+++ b/diffoscope/comparators/zip.py
@@ -25,6 +25,7 @@ import zipfile
 
 from diffoscope.tools import tool_required
 from diffoscope.difference import Difference
+from diffoscope.exc import ContainerExtractionError
 
 from .utils.file import File
 from .directory import Directory
@@ -98,9 +99,12 @@ class ZipContainer(Archive):
 # any weird character so we can get to the bytes.
 targetpath = os.path.join(dest_dir, os.path.basename(member_name)).encode(
 sys.getfilesystemencoding(), errors='replace')
-with self.archive.open(member_name) as source, open(targetpath, 'wb') as target:
-shutil.copyfileobj(source, target)
-return targetpath.decode(sys.getfilesystemencoding())
+try:
+with self.archive.open(member_name) as source, open(targetpath, 'wb') as target:
+shutil.copyfileobj(source, target)
+return targetpath.decode(sys.getfilesystemencoding())
+except Exception as exc:
+raise ContainerExtractionError(member_name, exc)
 
 def get_member(self, member_name):
 zipinfo = self.archive.getinfo(member_name)
-- 
2.7.4

Bug#905457: munin: general protection fault

[BERTRAND Joël]

Package: munin
Version: 2.0.37-2
Severity: important

Dear Maintainer,

I run debian testing (buster) and since a few days, munin doesn't run as
expected. In syslog, I have a lot of :

Aug  4 22:35:01 rayleigh CRON[11229]: (munin) CMD (if [ -x /usr/bin/munin-cron 
]; then /usr/bin/munin-cron; fi > /dev/null 2>&1)
Aug  4 22:35:02 rayleigh kernel: [986015.327521] traps: /usr/sbin/munin[11238] 
general protection ip:559e936f2282 sp:71816870 error:0 in 
perl[559e93627000+1f8000]
Aug

I don't understand why perl tries to run /usr/sbin/munin, there is no such
script nor executable.

Best regards,

JB

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

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

Versions of packages munin depends on:
ii  cron [cron-daemon]3.0pl1-130
ii  fonts-dejavu-core 2.37-1
ii  libdate-manip-perl6.72-1
pn  libdigest-md5-perl
ii  libfile-copy-recursive-perl   0.44-1
ii  libhtml-template-perl 2.97-1
ii  libio-socket-inet6-perl   2.72-2
ii  liblog-log4perl-perl  1.49-1
ii  libperl5.22 [libtime-hires-perl]  5.22.2-5
ii  libperl5.24 [libtime-hires-perl]  5.24.1-7
ii  librrds-perl  1.7.0-1+b2
pn  libstorable-perl  
ii  liburi-perl   1.74-1
ii  lsb-base  9.20170808
ii  munin-common  2.0.37-2
ii  perl [libtime-hires-perl] 5.26.2-6
ii  rrdtool   1.7.0-1+b2
ii  systemd-sysv  239-7

Versions of packages munin recommends:
ii  libcgi-fast-perl  1:2.13-1
ii  munin-doc 2.0.37-2
ii  munin-node2.0.37-2

Versions of packages munin suggests:
iu  apache2 [httpd]2.4.34-1
ii  elinks [www-browser]   0.12~pre6-13
ii  firefox [www-browser]  61.0.1-1
ii  iceape [www-browser]   2.7.12-1+b1
ii  konqueror [www-browser]4:18.04.0-1
pn  libapache2-mod-fcgid   
ii  libnet-ssleay-perl 1.85-1
ii  links [www-browser]2.16-1
ii  lynx [www-browser] 2.8.9rel.1-1
ii  seamonkey-mozilla-build [www-browser]  2.49.3-0ubuntu1
ii  w3m [www-browser]  0.5.3-36+b1

-- Configuration Files:
/etc/cron.d/munin changed:
MAILTO=root
*/5 * * * * munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; 
fi > /dev/null 2>&1
14 10 * * * munin if [ -x /usr/share/munin/munin-limits ]; then 
/usr/share/munin/munin-limits --force --contact nagios --contact old-nagios; fi

/etc/munin/munin.conf changed:
dbdir   /var/lib/munin
htmldir /var/cache/munin/www
logdir /var/log/munin
rundir  /var/run/munin
tmpldir /etc/munin/templates
staticdir /etc/munin/static
cgitmpdir /var/lib/munin/cgi-tmp
includedir /etc/munin/munin-conf.d
graph_period second
graph_strategy cron
munin_cgi_graph_jobs 6
html_strategy cron
[rayleigh.systella.fr]
address 127.0.0.1
use_node_name yes
[legendre.systella.fr]
address 192.168.1.2
use_node_name yes
[pythagore.systella.fr]
address 192.168.10.102
use_node_name yes
[cervantes.systella.net]
address 192.168.2.5
use_node_name yes


-- no debconf information

Bug#905431: libreoffice-common: LibreOffice fails to print text unless "PDF as standard print job format" is chosen

[Andrew Rule]

Hi Rene,

Just checked, and it appears that print option "PDF as standard print job
format" is a standard setting, so I imagine you have to go into settings to
turn it off.

Kind regards,

Andrew Rule

On 4 August 2018 at 21:24, Andrew Rule  wrote:

> Hi Rene,
>
> Thanks for your quick reply!
>
> Sorry I'm not expert at trying to work out these problems.
>
> However, I have tried it with another computer running Debian
> testing/unstable.  I get exactly the same bug with this version of
> LibreOffice, using the first computer as a print server.  The first
> computer is running debian amd64, on an AMD A4, and the second is running
> debian i386 on an intel i3.  The first computer is running wayland, the
> second running Xorg.
>
> Previously, from the first computer I tried printing to a local printer,
> and also to a remote printer served from a pi2, with exactly the same
> result, so it can't be the print server, as far as I can see.
>
> I wondered if it was to do with font substitutions (the documents were
> using "Times New Roman" which must have been substituted for Liberation
> Serif somewhere along the line, but it made no difference with a non
> substituted font (Noto Serif).
>
> What can I try to to narrow it down for us?  I tried "Safe Mode" but that
> just turns on the option "PDF as standard print job format" so gives me no
> further insight.
>
> Both my computers have been running debian for a while.
>
> Kind regards,
>
> Andrew Rule
>
> On 4 August 2018 at 17:20, Rene Engelhard  wrote:
>
>> tag 905431 + moreinfo
>> tag 905431 + unreproducible
>> thanks
>>
>> Hi,
>>
>> On Sat, Aug 04, 2018 at 02:41:27PM +0100, Andrew Rule wrote:
>> > Upon further investigation, I found that enabling the option "PDF as
>> standard
>> > print job format" allows the application to print as normal.
>> >
>> > I did test this on two printers, so I am sure it is not a problem with a
>> > specific printer.  Furthermore, both Okular and MuseScore packages
>> print with
>> > no special settings on the computer.
>> >
>> > As I presume the attached information tells you, I print using CUPS,
>> which is
>> > currently 2.2.8-5
>>
>> Can't reproduce this. LO on buster with CUPS from buster (so same
>> versions as in sid. print server also is buster). No special settings
>> ttbomk and it just prints a test document just saying "Test" just fine.
>>
>> Regards,
>>
>> Rene
>>
>
>

Bug#904662: sddm 0.14.0-4+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: sddm
Version: 0.14.0-4+deb9u1

Explanation: honour PAM's ambient supplemental groups; add missing 
utmp/wtmp/btmp handling

Bug#905431: libreoffice-common: LibreOffice fails to print text unless "PDF as standard print job format" is chosen

[Andrew Rule]

Hi Rene,

Thanks for your quick reply!

Sorry I'm not expert at trying to work out these problems.

However, I have tried it with another computer running Debian
testing/unstable.  I get exactly the same bug with this version of
LibreOffice, using the first computer as a print server.  The first
computer is running debian amd64, on an AMD A4, and the second is running
debian i386 on an intel i3.  The first computer is running wayland, the
second running Xorg.

Previously, from the first computer I tried printing to a local printer,
and also to a remote printer served from a pi2, with exactly the same
result, so it can't be the print server, as far as I can see.

I wondered if it was to do with font substitutions (the documents were
using "Times New Roman" which must have been substituted for Liberation
Serif somewhere along the line, but it made no difference with a non
substituted font (Noto Serif).

What can I try to to narrow it down for us?  I tried "Safe Mode" but that
just turns on the option "PDF as standard print job format" so gives me no
further insight.

Both my computers have been running debian for a while.

Kind regards,

Andrew Rule

On 4 August 2018 at 17:20, Rene Engelhard  wrote:

> tag 905431 + moreinfo
> tag 905431 + unreproducible
> thanks
>
> Hi,
>
> On Sat, Aug 04, 2018 at 02:41:27PM +0100, Andrew Rule wrote:
> > Upon further investigation, I found that enabling the option "PDF as
> standard
> > print job format" allows the application to print as normal.
> >
> > I did test this on two printers, so I am sure it is not a problem with a
> > specific printer.  Furthermore, both Okular and MuseScore packages print
> with
> > no special settings on the computer.
> >
> > As I presume the attached information tells you, I print using CUPS,
> which is
> > currently 2.2.8-5
>
> Can't reproduce this. LO on buster with CUPS from buster (so same
> versions as in sid. print server also is buster). No special settings
> ttbomk and it just prints a test document just saying "Test" just fine.
>
> Regards,
>
> Rene
>

Bug#905456: Please create new list debian-clojure

[Elana Hashman]

Package: lists.debian.org
Severity: wishlist

Hello!

I realize that alioth-lists.debian.net is only a temporary service and
will be going away within the next couple of years[1]. It would be
better to move the Clojure packaging list
 sooner versus later.
I'm currently the admin of that list.

This has been proposed as part of our team's overall Alioth
migration[2].

The details...

Name: debian-cloj...@lists.debian.org
Rationale: see above
Short description: Clojure packages and maintenance
Long description: Coordination of the maintenance of Clojure packages
in Debian.
Category: Developers
Subscription Policy: open
Post Policy: open
Web Archive: yes
Moving an existing list: Attachment has an encrypted list of current
subscribers in the correct format (one email per line). I
encrypted it for Alex's key as he is listed as responsible for
list creation.[3]

Thanks!

- e

[1]: https://wiki.debian.org/Alioth/MailingListContinuation
[2]: https://wiki.debian.org/Clojure/AliothMigration#Mailing_Lists
[3]: https://wiki.debian.org/Teams/ListMaster
-BEGIN PGP MESSAGE-
Version: GnuPG v1

hQIMAyw6FZGd0OwpARAAh/SVD7VfUUCKZAqCnWOVfV10h0JGMxwtRs/rF919Ka6O
+t9zPpXr3VLRQTilsfxGHOE44k1DpJhwANfH5O42IVhxDH+OZdyOavivTzk4v4a8
YwM0/QRPts+YfE5IttjiZkdpVW68SsNu5tVku4eXrj29w+cDgrNTG5Tet5eRVQr9
3knbZjVAkN5jbGhgbheFfarHxpVNVo6k8yyb4hUvQtCBnkVd0nDQtgXGKsNozNVa
fLjM3WqPLzM5zmOhHyECua4CFvT08EbkuPKtGM4zRxJ2AHDcP8lzEpA7HpgVn2oF
1ulvmag0uMwS3nebM8toyds/DYbljYqRitE/4QIDfa+Mjj+6Qd4kEaBD3qxz1GCx
OUFi5edxB5UovsK8HjVSxAuZRtNEHHj3s4rtkTyzMPtmX8W7vJ2SL72qThgAFsAf
hjl6snyf3lph2wEJ/kFI/myqY6I+/SqXKkLG9ooZAhNJjk7l/DFwadMAKrA07f6Q
O1B46240K+pz/ooFXBeIUrAF+OELuH3C27YIBl6lFBNIsqqFgVT5xKQN6/NZG+NA
V1Ywm2mtZnjSgTokrcrzw0iC8UOpUpVoqDxhsZgIrWfTWHAa4UE574jMKimQVaWg
btEktP3wNdviOyEBt9GlIgbmJOmUEUADg5Z6Qwc5zjO3DFlOHgz4tUBTpFbOCMTS
wB0BFm8PfaNyTD2WMS8EjpixEQ+Bz/Hs0S9mE8I6WmmC9dvDmjVRkY3MoOXBRuDb
enilWh6wcSYYkj/Ejq/VsCf8S+Oh3brfA+oAZ109lnv0QTozaR0x+9z9XKGosMNY
t1vpkNdOArzoUVf5jfZwrikVsT/A8c4hpwXLjhaBrvjQopAb9b56E1ehWbA5DfLa
68IeJLptQM1uYGb49PcGJ1vpUb4fmO91YWasWnDJyyMQ6ICLpjG7ZVX6FHrJt18c
hq7zxVlKiipm2uS4Rs/nuPXBlO6kw5XZmB5ilODTDQ==
=ildb
-END PGP MESSAGE-


signature.asc
Description: Digital signature

Bug#905455: RFS: dmidecode/3.1-2

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "dmidecode"

   Package name: dmidecode
   Version : 3.1-2
   Upstream Author : dmidecode-de...@nongnu.org
   URL : https://nongnu.org/dmidecode/
   License : GPL-2+
   Section : utils

  It builds those binary packages:

 dmidecode  - SMBIOS/DMI table decoder
 dmidecode-udeb - SMBIOS/DMI table decoder (udeb) (udeb)

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

  https://mentors.debian.net/package/dmidecode


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dmidecode/dmidecode_3.1-2.dsc
  
  Changes since the last upload:

  * debian/control:
- Change to my new email address.
- Use secure homepage URI.
- Switch Vcs-* to new location (Closes: #902259).
  * debian/copyright:
- Change to my new email address.
- Use secure copyright format URI.
- Add year 2018 to debian/*.
  * debian/watch:
- Use secure URI.
  * Declare compliance with Debian Policy 4.1.5 (No changes needed).
  * Migrate to debhelper 11:
- Change debian/compat to 11.
- Bump minimum debhelper version in debian/control to >= 11.

  Regards,
   Jörg Frings-Fürst
- -- 
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+AHX8jUOrs1qzDuCfifPIyh0l0FAltmCDIACgkQCfifPIyh
0l1uPhAAksoWic6EK6xIjD285Nh3vfFLdymBD4HbfjtqI0cmnnQ3mHM3CElO9YJG
503DEkrDyLDMxRyakntpRTjMbqn1QbPvX7Yxj7iUoHr9n/nOT8ErPLVLCdtua7Mo
serSm9p2VpYQJ/hWyGy/FxvMPU/8yso8ZYgFhplsD2xUfnj85Hnoqi/hP+nTwwGt
wujtC8Rz23x66tY7QtTAdfFuqm5nIvCc9TpIwXy1bVD+D0GKk0N/FSivbqrT0wo4
b5QazTb7AjIjh69QSGe5pvIDf+KJyjGtniUP1VYg3Aj1HiBHDgNMy767IlpFA7Fd
FNFnyBBxqVLpa2AMqaVa51pebpN0jZ/AzFgM2n8V0e/H0Pcae2xq6iok9hZ7edA8
cbTSHGE3qlevSsvzN8UNfTtwKeGVJSjN7oI/lmMwR0UjDDk7lb+1OxS6zizmMxTr
+DW758xKMIXobab5XvR9dhDc77V6R58Xfqi7K9JtPO76bO1hQXB20g1+tD/qER+1
CoC7Y+Nk8zkTOPRZi7d38SwXTG3zayafKbyMrwlT2ToizXSrp7jtt30MIHDK914c
/ljpp4ry3tc3DFcKLchtnqxsY7eOPR2OPoyNd3db9IbskiYpOge+GSmISpmxdrxV
58OonWnLfiA8oDLQTTtdju4M8kwJBO8zV+a4/TzaJCzxjncz4tY=
=RGEn
-END PGP SIGNATURE-

Bug#618862: systemd: ignores keyscript in crypttab

[Michael Niewöhner]

Hi all,

I stumbled on this, too but I have a work-around for at least 'decrypt_keyctl'.

systemd uses systemd-cryptsetup -> systemd-ask-password -> linux keyring.
The keyring can be modified by keyctl just as 'decrypt_keyctl' does.
As I wanted to use 'decrypt_keyctl' for unlocking root and data with the same
password, I applied this patch:

--- /lib/cryptsetup/scripts/decrypt_keyctl.distrib  2017-05-09
13:50:59.0 +0200
+++ /lib/cryptsetup/scripts/decrypt_keyctl  2018-08-04 21:34:01.130979945
+0200
@@ -24 +24 @@ die()
-ID_="cryptkey-$1"
+ID_="cryptsetup"

My entries in crypttab are these:
crypt_sys /dev/zpool_sys/zvol_sys none luks,discard,keyscript=decrypt_keyctl
crypt_data /dev/zpool_data/zvol_data none luks,discard,keyscript=decrypt_keyctl

Now cryptsetup-initramfs unlocks my root device and decrypt_keyctl caches the
password to linux keyring with desc=cryptsetup.

Systemd then reads the key from keyring with desc=cryptsetup and unlocks my data
 device! :-)

That keyring caching could be easily added to all other keyscripts to make
systemd unlock work ;-)


Best regards
Michael

Bug#905433: git-debrebase: debrebase new-upstream fails with "uninitialized value"

[Johannes Schauer]

Hi Ian,

Quoting Ian Jackson (2018-08-04 18:15:47)
> Thanks for the report.  This is a very new tool and as you can see it has
> some rough edges both in docs and (at least) error messages.

no problem! I'm happy to report the bugs I find. ^^

> > I just wanted to try out using git-debrebase with my package img2pdf which
> > is currently maintained using dgit. Having read the dgit-maint-debrebase
> > man page, I did:
> I did dgit clone img2pdf and it appears to have no patches.  I'm not sure why
> you think you need git-debrebase ?

Because I wanted to add one.

> If you really want to use it (eg you are about to start a patch queue) you
> will need git-debrebase convert-from-gbp.
> 
> Which bits of dgit-maint-debrebase gave you the impression you could
> just dgit clone without doing more ?  (You're the 2nd perso to think
> this, but I think your context is different...)

I was reading the dgit-maint-debrebase man page wrongly. Here is where I
tripped:

Firstly, I was reading the section "converting an existing package" because
obviously the package already existed and thus the section "initial
debianisation" didn't apply to me. Still correct so far.

I then had to decide between "no existing git history" and "existing git
history using another workflow". I read both sections and decided for "no
existing git history" for the following reasons:

 - "existing git history using another workflow" cloned from salsa as an
   example but I was using dgit, so no salsa (or former alioth) is involved

 - "existing git history using another workflow" mentioned a command called
   "git debrebase convert-from-gbp" but I was not using gbp so I thought it
   would not apply to my package

 - "no existing git history" on the other hand showed a command that I *do* use
   when I want to work with my package: "dgit clone foo"

Thus, I concluded that "git history" was probably referring to "a gbp based
workflow on salsa" which was not the case for me. Thus I thought I should just
follow the instructions given in "no existing git history".

> > Use of uninitialized value $r[2] in join or string at 
> > /usr/bin/git-debrebase line 935.
> >  at /usr/share/dgit/gdr/perl5/Debian/Dgit.pm line 127.
> >   Debian::Dgit::__ANON__("Use of uninitialized value \$r[2] in join or 
> > string at /usr/bi"...) called at /usr/bin/git-debrebase line 935
> >   main::walk("813ddd3849b33668d7120276a1219038411cc075") called at 
> > /usr/bin/git-debrebase line 1267
> >   main::cmd_new_upstream() called at /usr/bin/git-debrebase line 1864
> 
> This error message is fixed in git but not in 6.4.
> My current branch says this instead:
> 
>   git-debrebase: error: found unprocessable commit, cannot cope; bare
>   dgit dsc import: (commit d3481fe48afe150f38f331048abe6452b8389723)
>   (d.0x30 0x32)
> 
> Related UI bugs are:
> 
>   #905005 Want better user hinting for unprocessable commits
>   #905279 Suggest `dgit convert-from-dgit-view` sometimes
> 
> Ian.

Okay, that would tell me that it cannot cope with a commit that was created by
dgit very early on in my git history. From this error message I would still not
know what to do next.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#905454: php-common: Update to php-common (1:62) stuck in php.common-post at systemd-tty-ask

[Jaap Keuter]

Package: php-common
Version: 1:62
Severity: normal

Dear Maintainer,

While updating to php-common 1:62 the update gets stuck at:

...
Unpacking mesa-va-drivers:amd64 (18.1.5-1) over (18.1.4-1) ...
Preparing to unpack .../17-php-common_1%3a62_all.deb ...
Unpacking php-common (1:62) over (1:61) ...
Preparing to unpack .../18-php7.2-xml_7.2.8-2_amd64.deb ...
Unpacking php7.2-xml (7.2.8-2) over (7.2.4-1) ...
...
Processing triggers for libc-bin (2.27-5) ...
Setting up mesa-va-drivers:amd64 (18.1.5-1) ...
Setting up php-common (1:62) ...


Looking at the process tree reveils the following:

  |   |-konsole -session 
10dd616e7500015331903250014310008_1533191244_922307 

  |   |   |-bash

 
  |   |   |   `-update-debian.s /home/jaap/bin/update-debian.sh 

 
  |   |   |   `-sudo aptitude   

 
  |   |   |   `-aptitude

 
  |   |   |   |-dpkg --status-fd 96 --configure --pending   

 
  |   |   |   |   `-php-common.post 
/var/lib/dpkg/info/php-common.postinst configure 1:61   
 
  |   |   |   |   `-systemctl start phpsessionclean.timer   

 
  |   |   |   |   `-systemd-tty-ask --watch 

 
  |   |   |   `-{aptitude} 

Somehow systemd-tty-ask tries to get something from us, but can't?

Ended up killing the systemd-tty-ask and systemctl processes to get the update 
to complete.

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

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

Versions of packages php-common depends on:
ii  psmisc  23.1-1
ii  sed 4.5-1

php-common recommends no packages.

php-common suggests no packages.

-- no debconf information

Bug#905235: emacs-goodies-el failed to install due to old broken symlinks

[Nicholas D Steeves]

Hi Göran,

On Fri, Aug 03, 2018 at 10:31:08AM +0200, Göran Weinholt wrote:
> Package: emacs-goodies-el
> Version: 40.0
> Followup-For: Bug #905235
> 
> Hi,
> 
> I ran into this myself today and had a stab at reproducing it. In case
> it doesn't work on your machine, you can try it with Docker:
> 
> $ docker run -it debian:buster-20180716
> 
> # echo deb http://snapshot.debian.org/archive/debian/20180802T205558Z buster 
> main > /etc/apt/sources.list
> # apt update
> # apt -y --no-install-recommends install emacs25-nox=25.2+1-6+b3 
> emacs-goodies-el=39.0
> # echo deb http://snapshot.debian.org/archive/debian/20180802T205558Z sid 
> main > /etc/apt/sources.list
> # apt update
> # apt -y --no-install-recommends upgrade

Ah, that's what's happening!  Bugs are popping up in various emacs
packages that don't use dh-elpa because users are doing partial
upgrades to sid without installing the new emacsen-common.  It's a bit
heavy-handed, but having packages such as emacs-goodies-el (or w3m-el,
see #903200) declare a hard dependency on emacsen-common >= 3.0.2 will
prevent this issue from triggering.  I confirmed this 3 Aug with
clean chroot upgrades of buster from @/20180802T205558Z to sid.

Russ,

On Sat, 04 Aug 2018 09:41:17 -0700, Russ Allbery wrote:

> Filed as important rather than higher since I think this may be some
> edge case that happened on my system rather than a universal problem,
> since I haven't let the emacs25 -> emacs upgrade happen yet (waiting
> for auctex).

Yes, to my eye that is what's causing this.

On a related issue, it seems a number of users are upgrading
emacs-goodies-el without installing recommends.  At some point
Emacs-goodies-el will become a dummy transitional package that only
contains documentation.  If these dependencies remain as recommends
and users --no-install-recommends then they will lose functionality
that was previously part of goodies—gives users maximum freedom to do
so.

Alternatively, we can make emacs-goodies-el hard depend on this
packages.  This is what a dummy transitional package usually does.  A
side effect of this is that some of the modes have heavier depends
than in the past.  Eg: eproject now depends on helm.

Cheers,
Nicholas

Bug#903871: libsane: sane-genesys backend segfaults

[Alison Chaiken]

I have replugged my scanner into my desktop system.   I can scan media, 
but I always get empty or all-black images, for example:




$ scanimage -vvv -d genesys:libusb:001:005 --format jpeg > 
/tmp/test.jpeg
scanimage: scanning image 649 pixels wide and variable height at 8 
bits/pixel

scanimage: acquiring gray frame
scanimage: min/max graylevel value = 255/0
Maximum supported image dimension is 65500 pixels

$ ls -l /tmp/test.jpeg
-rw-r--r-- 1 alison alison 0 Aug  4 11:57 /tmp/test.jpeg

$ scanimage -vvv -d genesys:libusb:001:005 --calibrate
scanimage: setting of option --calibrate failed (Operation not 
supported)

Closing device
Calling sane_exit
scanimage: finished


---

I notice that when I run xsane, there is white illumination, but the 
resulting image is all black.  When I run scanimage, the illumination is 
red, and the file is empty.


Both 'man sane-genesys' and http://www.sane-project.org/sane-mfgs.html 
say that the Xerox Travel Scanner 100 is well-supported.   I bought this 
device only because I read those documents first, and it cost me $200.   
I suggest removing it from the list of supported devices, at least 
temporarily.


Thanks for your help,
Alison Chaiken

---
Alison Chaiken   ali...@she-devel.com
http://she-devel.com
The real trolley problem is that trolleys are underfunded.  -- Alex Roy

On 2018-07-17 04:00, Jörg Frings-Fürst wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Alison,

I think it is an problem with your USB HUP.

This is form your logs:



[  155.985709] usb 1-1: device descriptor read/64, error -110
[  171.600752] usb 1-1: device descriptor read/64, error -110


The error code 110 indicates that the interface can not supply enough
power.

Can you check the scanner on an other port and/or on an active external
Hub?

If the error still exists please remove all power plugs from the main
board for 10-15 minutes and then test it again.


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+AHX8jUOrs1qzDuCfifPIyh0l0FAltNzD8ACgkQCfifPIyh
0l2AUBAAk/qrgmJ1B7Y8n8RJyhCztfotGJumJSYtF0kClypeoV5TuzghwTI9oofc
lMJcqrPiAljvahPRMx1K4Ew16SKGgJDbyA8M1n3rDtYo1HFA6hBZ81NTLybc3kLL
fHc0hDAg8GXG6LLmV+FUcA8mTcQXQbgo3o9d8O/6C4k3YdE7VlSAKHtkaTKSDaxj
cWLlXzio5GSehg26YvSg97LJYXeie1j3VB0o+tVOHE9TSHiByvqt03pyDCoT71Q+
xYMlf+3GK0+qzd2wKK62s7HqxhKmtPu95MtmlGTvXr/k3anlGSCEw0qp4U8TZVut
U1/ta8pAzBBET+Q/viy/1lrEqXoeEbeCm/+h/NOgLYkt5UtEYnOo11+n4CL4llq5
NETlNkfY7x4Z9nPvFQBw1gL+LjNKBF42nAd9Ydub7CI6iSNI1OTc6f2hT9+go2Ds
Aeim1wYHoYY8aW9zje3+XK7B2BtykE1Ttyc/P+M8qkPiovejvkydsc+sdhF60VmS
DS6eAP5SX8lRpF2694zoV9FBmmk6yNh1ubIg2hk6RlgpvEg0gWGEqCmRgmuP/h1X
+91crhPbrP2h+V5Iac04t1tosS4tWE1CVXSzjODgedAS5AwhWbwjxb5A6+QbPdoZ
34pUdverbG1hWqSjt3mY2CYF3KQ3iXivS80X9MYfQk9uundQxYg=
=mxFz
-END PGP SIGNATURE-

Bug#905453: debian-policy: Policy does not include a section on NEWS.Debian files

[Elana Hashman]

Package: debian-policy
Version: 4.2.0.0
Severity: normal

NEWS.Debian files are listed in the "unofficial policy"[1] but not in
the official policy.

It seems this was proposed in 2002[2], but in 2003, folks were
hesitant to "[get] this into policy until enough stuff uses it that we
can tell it works well".

Is 15 years long enough? Can we make this official?

- e

[1]: 
https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-news-debian
[2]: https://lists.debian.org/debian-devel/2002/07/msg00267.html
[3]: https://lists.debian.org/debian-devel/2003/07/msg00286.html


signature.asc
Description: Digital signature

Bug#896305: laditools: diff for NMU version 1.1.0-3.1

[Adrian Bunk]

Control: tags 896305 + patch
Control: tags 896305 + pending

Dear maintainer,

I've prepared an NMU for laditools (versioned as 1.1.0-3.1) and uploaded 
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru laditools-1.1.0/debian/changelog laditools-1.1.0/debian/changelog
--- laditools-1.1.0/debian/changelog	2018-05-06 21:28:15.0 +0300
+++ laditools-1.1.0/debian/changelog	2018-08-04 22:02:00.0 +0300
@@ -1,3 +1,11 @@
+laditools (1.1.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move the python-xdg dependency from laditools to python-laditools.
+(Closes: #896305)
+
+ -- Adrian Bunk   Sat, 04 Aug 2018 22:02:00 +0300
+
 laditools (1.1.0-3) unstable; urgency=medium
 
   [ Ross Gammon ]
diff -Nru laditools-1.1.0/debian/control laditools-1.1.0/debian/control
--- laditools-1.1.0/debian/control	2018-05-06 21:28:15.0 +0300
+++ laditools-1.1.0/debian/control	2018-08-04 22:02:00.0 +0300
@@ -25,7 +25,6 @@
  python-gi,
  python-gi-cairo,
  python-laditools,
- python-xdg,
  ${misc:Depends},
  ${python:Depends}
 Recommends: gladish
@@ -59,6 +58,7 @@
  python-dbus,
  python-enum34,
  python-gi,
+ python-xdg,
  ${misc:Depends},
  ${python:Depends}
 Breaks: laditools (<< 1.0)

Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[Helmut Grohne]

Hi Niels,

On Sat, Aug 04, 2018 at 08:38:00AM +, Niels Thykier wrote:
> On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
>  wrote:
> > I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
> > packages should have explicit parent package arch dependency
> >Depend: foo:${Arch} (=${binary:Version})
> > instead of
> >Depend: foo (=${binary:Version})
> > Untested patch against debhelper 11.3.5 attached (please review 
> > carefully, I'm neither M-A nor debhelper expert).

Yes, this makes somewhat sense.

Personally, I disagree with the Depends though. I've often been in the
situation of wanting to debug a foreign core file or remotely attaching
to a process on a different system. These dependencies were not helpful
at all in these situations. Personally, I'm in favour of making -dbgsym
packages dependency-less. I acknowledge that others see things
different.

In any case, we agree that if we want the dependency, then it is
presently too weak.

> I believe you are correct that the dependency is too weak.  But my
> understanding is that "pkg:" dependencies are poorly supported.
> Accordingly, I am not sure it is possible to fix this bug at the moment.
> (CC'ing Helmut, whom I hope could remind me if "pkg:" support is
> good enough to rely on it or if he has a different take on the problem).

Actually, I don't exactly know either. I know some aspects though. Let
me share those.

You should strongly between cross-arch dependencies and same
arch-dependencies. Having Architecture: arch1 and Depends foo:arch2 is
not as well supported as having Architecture: arch1 and Depends:
foo:arch1. For instance, crossbuild-essential- used to Depends:
libc-dev:, which is a cross-arch dependency. Here, we are talking
about same-arch restrictions.

In the crossbuild-essential- issue, I think the problem was
testing migration. The installability checker would flag the dependency
and never let the package pass. If that is correct, it indicates that
what you want to do here, actually works rather well.

Johannes Schauer wrote a tool that can tell you whether dose, dpkg and
apt agree on satisfiability situations. You can find it at
https://gitlab.mister-muffin.de/josch/deb-m-a-dep-check. I believe that
its output would provide a valuable data point here. The tool
systematically constructs artificial packages and asks these resolvers
to check potential installation sets. There were some interesting
differences. I'd avoid situations where different resolvers disagree.
For instance, they disagree about :native annotations on Architecture:
all packages, see #854438. I'm not quite sure whether it handles :
though.

Hope this helps

Helmut

Bug#858281: hydrogen: Please remove GMkit content from the package due to license

[Reiner Herrmann]

Control: tags -1 + fixed-upstream

The current beta 1.0.0-beta1 has a new and free drumkit included
(GMRockKit instead of Gkit).


signature.asc
Description: PGP signature

Bug#903398: autopkgtest: documentation doesn't mention Build-Depends-Arch

[Paul Gevers]

tags 903398 patch
forwarded 903398 https://salsa.debian.org/ci-team/autopkgtest/merge_requests/30

Hi Mattia

On 09-07-18 14:54, Mattia Rizzolo wrote:
> This doc:
> 
> https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
> doesn't mention Build-Depends-Arch as a value @builddeps@ is expanded to
> in the Depends field of d/tests/control.
> 
> Is that correct?  If it is, then autopkgtest should probably learn about
> that field as well.

It was correct. So I'm making autopkgtest aware.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#905053: RFS: trojan/1.5.1-1 [ITP]

[GreaterFire]

Dear mentors,

The upstream has been updated to 1.5.2, so I updated the package accordingly.

Get the newer package by:

  dget -x 
https://mentors.debian.net/debian/pool/main/t/trojan/trojan_1.5.2-1.dsc

Thanks,
GreaterFire

Bug#905377: kontact: Kontact opens introduction in konqueror on each start

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 3 de agosto de 2018 15:17:24 -03 Matt Stamp escribió:
> Package: kontact
> Version: 4:17.12.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> On upgrade kontact:amd64 4:17.08.3-1 to 4:17.12.3-1 I am now getting the
> Konqueror introduction page on each start. I am unable to dismiss it as the
> 'Skip this introduciton' button throws an error 'Could not find any
> application or handler for exec:/switch'. So I close the Konqueror window
> only to have it open again.
> 
> My other machine does not have Konqueror installed and on each load I am met
> with 'File not found: data:text/html;charset=UTF-8,%3C%3Fxml
> version%3D%221.0%22...'
> 
> Is there a way to disable the introduction outright in an rc file somewhere?
> It's a pain to have to close this each time.

Not that I know of, but we can try to update the kde pim stuff after the Qt 
transition. This will probably solve it.

Kinds regards, Lisandro.

-- 
Sea estricto cuando envíe y tolerante cuando reciba. En otras palabras, solo
envíe paquetes que cumplan rigurosamente con lo estándares, pero espere
paquetes que tal vez no cumplan del todo y trate de lidiar con ellos.
  Andrew S. Tanenbaum, de su libro "Computer Networks"

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


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

Bug#905447: emacs-goodies-el fails to upgrade

[Russ Allbery]

Control: forcemerge 905235 -1

David Bremner  writes:
> Russ Allbery  writes:

>> Setting up emacs-goodies-el (40.0) ...
>> Install emacsen-common for emacs25
>> emacsen-common: Handling install of emacsen flavor emacs25
>> Install emacs-goodies-el for emacs25
>> install/emacs-goodies-el: Handling emacs25, logged in /tmp/elc_sbQgUN.log
>> Building autoloads for emacs25 in 
>> /usr/share/emacs25/site-lisp/emacs-goodies-el
>> ERROR: install script from emacs-goodies-el package failed
>> dpkg: error processing package emacs-goodies-el (--configure):
>>  installed emacs-goodies-el package post-installation script subprocess 
>> returned error exit status 1
>> Errors were encountered while processing:
>>  emacs-goodies-el
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>>
>> This appears to be because the upgrade process left behind a ton of broken
>> symlinks in /usr/share/emacs25/site-lisp/emacs-goodies-el.  I deleted all
>> of the files in that directory and then the installation completed.

> Is this the same as #905235?

Yes, indeed.  Apologies, somehow I missed that.

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

Bug#905452: fapg lacks support for FLAC audio files

[Intense Red]

Package: fapg
Version: 0.41-1+b2
Severity: wishlist

Dear Maintainer,

With FLAC encoded files becoming increasingly popular, this outstanding utility
lacks a critical function: the ability to read/process *.flac files and add
them to the lists it generates.



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

Versions of packages fapg depends on:
ii  libc6  2.24-11+deb9u3
ii  liburiparser1  0.8.4-1

fapg recommends no packages.

fapg suggests no packages.

-- no debconf information
-- 

Bug#905440: www.debian.org: remove "last modified" from footer

[Laura Arjona Reina]

El 4 de agosto de 2018 19:32:17 CEST, Laura Arjona Reina  
escribió:

>
>We probably change the string 

I wanted to say: we probably should change the string...

Kind regards

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#905440: www.debian.org: remove "last modified" from footer

[Laura Arjona Reina]

Hello Thomas

El 4 de agosto de 2018 17:23:06 CEST, Thomas Lange 
 escribió:
>
>Package: www.debian.org
>
>In the footer of every page we list the date the page was last
>modified. Currently this information is completly useless, because it
>does not show a correct date. e.g.
>
>https://www.debian.org/women/
>Last Modified: Fri, Jun 1 18:42:17 UTC 2018 
>
>Let's look into the git log:
>
>The last commit on index.wml was in 2014, which only changed http to
>https, so no real content change. In fact, the content didn't changed
>since 2012 and may be out of date.
>

The content is current.

>Please just remove this useless information from every page.

The date shown is the date of last build. This can be the date when something 
changed in the page (content or layout), in the templates used to build that 
page (e.g. a change in the footer), or a force rebuild for any reason.

We probably change the string from "Last modified" to something else ("Last 
build" or other wording), but I don't think that it is useless and we should 
remove it (I'm open to listen to other opinions, though).

Kind regards
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#905430: Libravatar is shutting down in 2018-09-01

[Don Armstrong]

Control: tag -1 help

On Sat, 04 Aug 2018, Louis-Philippe Véronneau wrote:
> Libravatar is shutting down in 2018-09-01 [1]. I guess Debian could take
> over the service is someone is interested?

It looks like libravatar is going to find interim hosting/project
support, but it definitely needs more assistance in the long term. If
you value the avatars, please help them out.


-- 
Don Armstrong  https://www.donarmstrong.com

He wore trifocals. There was stratigraphy even in his glasses.
 -- John McPhee _Annals of the Former World_ p364

Bug#905451: texlive-latex-recommended-doc: listings-devel.pdf not built and shipped

[Thorsten Glaser]

Package: texlive-latex-recommended-doc
Version: 2018.20180725-1
Severity: wishlist

/usr/share/doc/texlive-doc/latex/listings/ contains:
-rw-r--r-- 1 root root   1833 Nov 25  2016 Makefile.gz
-rw-r--r-- 1 root root723 Nov 25  2016 README
-rw-r--r-- 1 root root 731003 Nov 25  2016 listings.pdf
-rw-r--r-- 1 root root 503595 Nov 25  2016 lstdrvrs.pdf

Funnily, the Makefile with which listings-devel.pdf could be
generated is there (but useless as the .dtx file etc. aren’t)
but listings-devel.pdf isn’t.

I was able to successfully build it with:

$ apt-get source texlive-latex-recommended-doc
$ cd texlive-base-2018.20180725/texmf-dist/source/latex/listings
$ cp /usr/share/doc/texlive-doc/latex/listings/Makefile.gz .
$ gzip -d Makefile.gz
$ make pdf-devel

It would be cool if this file could be shipped (and perhaps
the Makefile not). Similarily for other packages that have
this distinction, probably.


##
 List of ls-R files

-rw-r--r-- 1 root root 2113 Jul 26 18:28 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Aug 17  2017 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jul 25 10:27 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jul 25 10:27 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 22  2017 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jul 25 10:27 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jul 25 10:27 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5068 Jul 26 18:27 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Nov 26  2007 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 22  2017 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-recommended-doc depends on:
ii  tex-common6.09
ii  texlive-base  2018.20180725-1

texlive-latex-recommended-doc recommends no packages.

texlive-latex-recommended-doc suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.19.0.5+b1
ii  ucf   3.0038

Versions of packages tex-common suggests:
ii  debhelper  11.3.5

Versions of packages texlive-latex-recommended-doc is related to:
ii  tex-common6.09
ii  texlive-binaries  2018.20180710.48169-1

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:

Bug#905447: emacs-goodies-el fails to upgrade

[David Bremner]

Russ Allbery  writes:

> Package: emacs-goodies-el
> Version: 40.0
> Severity: important
>
> Setting up emacs-goodies-el (40.0) ...
> Install emacsen-common for emacs25
> emacsen-common: Handling install of emacsen flavor emacs25
> Install emacs-goodies-el for emacs25
> install/emacs-goodies-el: Handling emacs25, logged in /tmp/elc_sbQgUN.log
> Building autoloads for emacs25 in 
> /usr/share/emacs25/site-lisp/emacs-goodies-el
> ERROR: install script from emacs-goodies-el package failed
> dpkg: error processing package emacs-goodies-el (--configure):
>  installed emacs-goodies-el package post-installation script subprocess 
> returned error exit status 1
> Errors were encountered while processing:
>  emacs-goodies-el
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> This appears to be because the upgrade process left behind a ton of broken
> symlinks in /usr/share/emacs25/site-lisp/emacs-goodies-el.  I deleted all
> of the files in that directory and then the installation completed.
>

Hi Russ;

Is this the same as #905235?

d

Bug#756417: vim-scripts: diff for NMU version 20130814+nmu1

[James McCoy]

On Sat, Aug 04, 2018 at 06:05:33PM +0200, Sebastian Ramacher wrote:
> since deBPlugin is no longer able to handle control.tar members modern debs,
> I've prepared an NMU for vim-scripts (versioned as 20130814+nmu1) and uploaded
> it to DELAYED/7. Please feel free to tell me if I should delay it longer.

Thanks for the prod.  I'm reworking the packaging and updating various
plugins now.  I'll review this patch along with that work.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB


signature.asc
Description: PGP signature

Bug#905450: lexicon: Please package the last upstream release

[Martin Quinson]

Package: lexicon
Version: 2.3.0-1
Severity: normal

Hello,

I'd like to use the newest gandi API, that was included in the release 2.4.1 of
upstream lexicon. Could you please update the package for me to use it, please?

I could help here if you want, but the last uploaded package does not
seem to be pushed in the git (according to the QA page).

Thanks in advance,
Mt.



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

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

Versions of packages lexicon depends on:
ii  python3  3.6.5-3
ii  python3-lexicon  2.3.0-1

lexicon recommends no packages.

lexicon suggests no packages.

-- no debconf information

-- 
I don't suffer from Insanity, I enjoy every minute of it...


signature.asc
Description: PGP signature

Bug#904957: emacs-lucid: trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package emacs25-lucid 25.2+1-6+b3

[Rob Browning]

Rob Browning  writes:

> Sounds like I need to (at least) change the replaces line to:
>
>   Replaces: emacs-gtk, emacs-lucid, emacs25-gtk (<<1:25), emacs25-lucid 
> (<<1:25)

...rather:

  Replaces: emacs-gtk, emacs-lucid,
emacs25-nox (<< 1:25) emacs25-gtk (<< 1:25), emacs25-lucid (<< 1:25)

i.e. it perhaps needs to be all three.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#904957: emacs-lucid: trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package emacs25-lucid 25.2+1-6+b3

[Rob Browning]

Adrian Bunk  writes:

> But during the upgrade the Replaces is additionally required, for 
> telling dpkg that emacs-lucid contains files that are during the
> upgrade still present from the not yet fully removed emacs25-lucid
> package.

Sven Joachim  writes:

> I think emacs-lucid needs a "Replaces: emacs25-lucid (<< 1:25)" here,
> and similarly for the other flavors.

Ahh, ok.  So I can't use an indirect dependency for that -- in which
case, given the current deps:

  Package: emacs-nox
  Architecture: any
  ...
  Conflicts: emacs-gtk, emacs-lucid
  Replaces: emacs-gtk, emacs-lucid

Sounds like I need to (at least) change the replaces line to:

  Replaces: emacs-gtk, emacs-lucid, emacs25-gtk (<<1:25), emacs25-lucid (<<1:25)

and do something similar to the emacs-lucid and emacs-gtk replaces lines.

Plausible?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#903663:

[Adrian Bunk]

On Thu, Aug 02, 2018 at 11:01:29AM +1200, Michael Hudson-Doyle wrote:
> I reopened and reduced the severity; I think it's at least a bit strange
> that the package hard depends on all supported versions of Python.

Note that this is just a temporary state during Python3 transitions 
in unstable.

Stable releases of Debian (and Ubuntu) never support more than one
Python3 version, so doesn't make any difference there.

> I had a
> very quick poke to try to work out why this was happening and completely
> failed.

$ head -1 /usr/bin/f2py3.7 
#!/usr/bin/python3.7
$ 

cu
Adrian

-- 

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

Bug#904542: [debian-mysql] Bug#904542: Bug#904542: libmariadb-dev: Header files don't match mariadb-server-10.1 10.1.26-0+deb9u1

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello Joe!

Can you please confirm if this is fixed for you now so we can close this issue?


ke 25. heinäk. 2018 klo 16.12 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Hello!
>
> The package libmariadb-dev contains the client library files.
> Use the package libmariadbd-dev for server stuff.
>
> Yes, package names are very close to each other, but this is the same
> naming scheme as in mysql vs mysqld.

Bug#890966: [debian-mysql] Bug#890966: libmariadb-dev: mysql_config doesn't accept arguments

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello!

You have used an version from experimental that was badly packaged and
not intended for wider use.

Can you please confirm if this issue is present in the latest
libmariadb3 et al in Debian sid?

ke 21. helmik. 2018 klo 15.57 Takuro Ashie (as...@clear-code.com) kirjoitti:
>
> Package: libmariadb-dev
> Version: 10.3.0-0+exp2
> Severity: normal
>
> /usr/bin/mysql_config doesn't accept arguments.
>
> Expected:
>
>   $ /usr/lib/x86_64-linux-gnu/mysql_config --cflags
>   -I/usr/include/mysql -I/usr/include/mysql/..
>
> Actual:
>
>   $ mysql_config --flags
>   Usage: /usr/lib/x86_64-linux-gnu/mysql_config [OPTIONS]
>   Options:
>   --cflags [-I/usr/include/mysql -I/usr/include/mysql/.. ]
>   --include[-I/usr/include/mysql -I/usr/include/mysql/..]
>   --libs   [-L/usr/lib/x86_64-linux-gnu  -lmariadb]
>   --libs_r [-L/usr/lib/x86_64-linux-gnu  -lmariadb]
>   --plugindir  [/usr/lib/x86_64-linux-gnu/mariadb3/plugin]
>   --socket [/var/run/mysqld/mysqld.sock]
>   --port   [0]
>   --version[10.3.0]
>   --libmysqld-libs [-L/usr/lib/x86_64-linux-gnu  -lmysqld -lpthread 
> -lz -lm -ldl -lpcre -lcrypt -laio]
>   --variable=VAR   VAR is one of:
>   pkgincludedir [/usr/include/mysql]
>   pkglibdir [/usr/lib/x86_64-linux-gnu]
>   plugindir [/usr/lib/x86_64-linux-gnu/mariadb3/plugin]
>
> It's caused by the wrapper script for the actual mysql_config:
>
>   % cat /usr/bin/mysql_config
>   #!/bin/sh
>   exec /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/$(basename $0)
>
> "$@" should be added to the tail of the command.
>
> Probably #881073 is triggered by the same cause with it.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-5-amd64 (SMP w/2 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 libmariadb-dev depends on:
> ii  libc62.26-6
> ii  libmariadb3  10.3.0-0+exp2
> ii  zlib1g-dev   1:1.2.8.dfsg-5
>
> libmariadb-dev recommends no packages.
>
> libmariadb-dev suggests no packages.
>
> -- no debconf information

Bug#888392: [debian-mysql] Bug#888392: Bug#888392: mariadb-connector-c: FTBFS on non-Linux: version script unused

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello Aaron!

su 4. maalisk. 2018 klo 7.24 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Current Debian packaging now has:
>
> mariadb-connector-c$ head debian/libmariadb3.symbols
> libmariadb.so.3 libmariadb3 #MINVER#
>  libmariadb_3@libmariadb_3 3.0.0
>  libmariadbclient_18@libmariadbclient_18 3.0.0
>  libmysqlclient_18@libmysqlclient_18 3.0.0
>  ma_pvio_register_callback@libmariadb_3 3.0.0
>  mariadb_cancel@libmariadb_3 3.0.0
>  mariadb_connection@libmariadb_3 3.0.0
>  mariadb_convert_string@libmariadb_3 3.0.0
>  mariadb_deinitialize_ssl@libmariadb_3 3.0.0
>  mariadb_dyncol_check@libmariadb_3 3.0.0
>
> Full source at:
> https://salsa.debian.org/mariadb-team/mariadb-connector-c/blob/master/debian/libmariadb3.symbols

Latest build of hurd still fails with make shlibs. Can you please
advice what should be done next? Or maybe even make a merge request on
Salsa to fix this?


>From https://buildd.debian.org/status/package.php?p=mariadb-connector-c

Tail of log for mariadb-connector-c on hurd-i386:

+ stmt_read_execute_response@Base 1:3.0.3-2
+ stmt_set_error@Base 1:3.0.3-2
+ store_param@Base 1:3.0.3-2
+ str_to_TIME@Base 1:3.0.3-2
+ tls_library_version@Base 1:3.0.3-2
+ tls_protocol_version@Base 1:3.0.3-2
+ unpack_fields@Base 1:3.0.3-2
dh_makeshlibs: failing due to earlier errors
debian/rules:20: recipe for target 'override_dh_makeshlibs' failed
make[1]: *** [override_dh_makeshlibs] Error 2
make[1]: Leaving directory '/<>'
debian/rules:6: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 2
/bin/fakeauth: Error 2 for child 6799
/bin/settrans: Error 2 for child 6798

Bug#905411: New list creation: debian-fundraising

[Alexander Wirt]

On Sat, 04 Aug 2018, Louis-Philippe Véronneau wrote:

> On 2018-08-04 18:58, Alexander Wirt wrote:
> >> Subscription Policy: closed, manual approval. We don't want random
> >> people to subscribe to this ML. This list will eventually be used to
> >> talk about confidential discussions we've had with sponsors.
> > in general I can say that we had bad experiences with such closes lists and
> > that we don't want them. This has to be discussed within the team. I also
> > think debian should be more transparent. 
> 
> By 'random', I meant people not part of the Debian project. Bad choice
> of language on my end, sorry.
users are also part of the project. 

> 
> Is there a way to make the subscription only available to DDs/DMs? I
> wouldn't mind that.
No, we don't have such a mechanism.

Alex
> 
> -- 
>   ,''`.
>  : :'  : Louis-Philippe Véronneau
>  `. `'`  po...@debian.org / veronneau.org
>`-
> 





signature.asc
Description: PGP signature

Bug#903004: marked as done (scour: Please upgrade to 0.37)

[Martin Pitt]

Hello Niels,

Debian Bug Tracking System [2018-08-04  6:33 +]:
> The bug was not closed during the upload (I presume due to a syntax
> mistake in the changelog), so I am using this email to close it.

Whoops, forgot the colon after "Closes". I work with GitHub too much :-)

Thanks!

Martin

Bug#904957: emacs-lucid: trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package emacs25-lucid 25.2+1-6+b3

[Sven Joachim]

On 2018-08-04 11:24 -0500, Rob Browning wrote:

> Axel Beckert  writes:
>
>> upgrading emacs25-lucid on armhf pulls in emacs-lucid, but that fails
>> to install as follows:
>>
>> Preparing to unpack .../emacs-lucid_1%3a25.2+1-8_armhf.deb ...
>> Unpacking emacs-lucid (1:25.2+1-8) ...
>> dpkg: error processing archive 
>> /var/cache/apt/archives/emacs-lucid_1%3a25.2+1-8_armhf.deb (--unpack):
>>  trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in 
>> package emacs25-lucid 25.2+1-6+b3
>> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>> Errors were encountered while processing:
>>  /var/cache/apt/archives/emacs-lucid_1%3a25.2+1-8_armhf.deb
>>
>> The Replaces header only contains emacs-gtk and emacs-nox, but likely
>> also needs emacs25-lucid. And probably also needs a "Breaks:
>> emacs25-lucid".
>
> I suspect I'm just misunderstanding the dependency system, but this
> confuses me because:
>
>   emacs25-lucid 25.2+1-6+b3
> Depends: emacs25-bin-common
>
> and
>
>   emacs25-bin-common
> Depends: emacs25-common
>
> and on the newer side
>
>   emacs-lucid 1:25.2+1-8
> Depends: emacs-common (= 1:25.2+1-8)
>
> and 
>
>   emacs-common 1:25.2+1-8
> Depends: emacsen-common (>= 3.0.0)
>
> and
>
>   emacsen-common (>= 3.0.0)
> Conflicts: emacs25-common

AFAICS this does not prevent emacs-lucid to be unpacked before
emacs-common and the new emacsen-common and emacs25-lucid versions, in
which case you hit the file conflict.

> So I'd expected the indirect dependency of emacs-lucid on the newer
> emacsen-common to have indirectly forced emacs25-lucid out (via the
> emacsen-common conflicts), so that there wouldn't be a file conflict,
> but obviously I'm missing something (and agree that it's a somewhat
> tortuous route).

I think emacs-lucid needs a "Replaces: emacs25-lucid (<< 1:25)" here,
and similarly for the other flavors.

Cheers,
   Sven

Bug#904957: emacs-lucid: trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package emacs25-lucid 25.2+1-6+b3

[Adrian Bunk]

On Sat, Aug 04, 2018 at 11:24:27AM -0500, Rob Browning wrote:
> Axel Beckert  writes:
> 
> > upgrading emacs25-lucid on armhf pulls in emacs-lucid, but that fails
> > to install as follows:
> >
> > Preparing to unpack .../emacs-lucid_1%3a25.2+1-8_armhf.deb ...
> > Unpacking emacs-lucid (1:25.2+1-8) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/emacs-lucid_1%3a25.2+1-8_armhf.deb (--unpack):
> >  trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in 
> > package emacs25-lucid 25.2+1-6+b3
> > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/emacs-lucid_1%3a25.2+1-8_armhf.deb
> >
> > The Replaces header only contains emacs-gtk and emacs-nox, but likely
> > also needs emacs25-lucid. And probably also needs a "Breaks:
> > emacs25-lucid".
> 
> I suspect I'm just misunderstanding the dependency system, but this
> confuses me because:
> 
>   emacs25-lucid 25.2+1-6+b3
> Depends: emacs25-bin-common
> 
> and
> 
>   emacs25-bin-common
> Depends: emacs25-common
> 
> and on the newer side
> 
>   emacs-lucid 1:25.2+1-8
> Depends: emacs-common (= 1:25.2+1-8)
> 
> and 
> 
>   emacs-common 1:25.2+1-8
> Depends: emacsen-common (>= 3.0.0)
> 
> and
> 
>   emacsen-common (>= 3.0.0)
> Conflicts: emacs25-common
> 
> So I'd expected the indirect dependency of emacs-lucid on the newer
> emacsen-common to have indirectly forced emacs25-lucid out (via the
> emacsen-common conflicts), so that there wouldn't be a file conflict,
> but obviously I'm missing something (and agree that it's a somewhat
> tortuous route).

This needs Breaks+Replaces:
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages

The Breaks part might be covered by the Conflicts relationship you showed.

But during the upgrade the Replaces is additionally required, for 
telling dpkg that emacs-lucid contains files that are during the
upgrade still present from the not yet fully removed emacs25-lucid
package.

> Thanks

cu
Adrian

-- 

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

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

[Aurelien Jarno]

On 2018-07-23 22:17, Paul Gevers wrote:
> On Sun, 01 Apr 2018 21:56:33 +0200 Florian Weimer  wrote:
> > > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours
> > > built on amd64, the glibc takes around 20 minutes to build and the
> > > testsuite around 2h to run.
> > 
> > This is still rather slow.  I see native builds on relatively current
> > hardware taking 2 minutes, plus 12 to 15 minutes to build and run the
> > test suite (all with parallel make, although parallel make for tests
> > is disabled automatically for some subdirectories).  200 minutes on
> > current (amd64) hardware sounds quite excessive.
> 
> I just did a retry on our infrastructure and it ran in 57 minutes. But
> it ran on one of the two big workers (8 cores and 30 GB memory). We want
> to make all workers equal and we are going down to 2 cores and 7.2 GB.
> 
> Could it be that the memory is the actual problem and/or also an issue?

I don't think think the memory is really a problem, at least not for the
values you give. A few tests might be memory hungry, but 4GB should be
enough.

Aurelien

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


signature.asc
Description: PGP signature

Bug#878039: [debian-mysql] Bug#878039: libmariadb-dev-compat: Static library symlinked to dynamic one, compile error

[Otto Kekäläinen]

Control: merge -1 868131

This is a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868131 and will be
fixed in 3.0.6-1.

Bug#905449: libfsharp-core4.3-cil: It is impossible to configure libfsharp-core4.3-cil package

[Warlock]

Package: libfsharp-core4.3-cil
Version: 4.0.0.4+dfsg2-2
Severity: important

Dear Maintainer,

When I try to install libfsharp-core4.3-cil package, I get the following error:

Setting up libfsharp-core4.3-cil (4.0.0.4+dfsg2-2) ...
* Installing 13 assemblies from libfsharp-core4.3-cil into Mono
E: installing Assembly /usr/lib/cli/FSharp.Core-4.3/FSharp.Core.dll failed
E: Installation of libfsharp-core4.3-cil with 
/usr/share/cli-common/runtimes.d/mono failed
dpkg: error processing package libfsharp-core4.3-cil (--configure):
 subprocess installed post-installation script returned error exit status 29

If I then try to gac FSharp.Core.dll manually:

# gacutil -i /usr/lib/cli/FSharp.Core-4.3/FSharp.Core.dll

I get the folloing error:

Couldn't find machine.config
Failure adding assembly /usr/lib/cli/FSharp.Core-4.3/FSharp.Core.dll to the 
cache: Strong name cannot be verified for delay-signed assembly

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 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 libfsharp-core4.3-cil depends on:
ii  cli-common  0.9+nmu1
ii  libmono-corlib4.5-cil   4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-numerics4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system4.0-cil   4.6.2.7+dfsg-1
ii  mono-runtime4.6.2.7+dfsg-1
ii  mono-runtime-common 4.6.2.7+dfsg-1

libfsharp-core4.3-cil recommends no packages.

libfsharp-core4.3-cil suggests no packages.

-- no debconf information

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

[Aurelien Jarno]

On 2018-07-30 23:14, Florian Weimer wrote:
> * Paul Gevers:
> 
> > Hi Florian,
> >
> > On 29-07-18 13:26, Florian Weimer wrote:
> >> I'm not sure why it is necessary to build glibc three times (unless
> >> it's impossible to get multi-arch packages into the buildroot).
> >
> > I am not sure if I understand what you mean, but currently having
> > multiple arches available in the autopkgtest testbed isn't supported. I
> > have seen packages try (gnupg2), but this goes easily wrong considering
> > the unstable-to-testing migration setup. If there is a real need for
> > this, it should come from autopkgtest.
> 
> Sorry, I never worked on the Debian toolchain, so my phrasing was
> poor.
> 
> In concrete terms, what I meant was: Why build libc6-i386 on amd64
> when there is a libc6:i386 package as well?

This package is basically only used by gcc to support multilib.
Therefore it's indeed possible to not include those builds in the
autopkgtests.

Aurelien

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

Bug#877845: [debian-mysql] Bug#877845: libmariadb-dev-compat: Cannot install static libmysqlclient with libmysql++-dev

[Otto Kekäläinen]

Control: tags -1 wontfix

Hello!

The whole point of a -compat package is that it replaces the other
with files with the same names in the same paths.
You cannot co-install them and there should be no need or use case for
anybody to want to do so. Use either one.


$ sudo apt install libmysql++-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  default-libmysqlclient-dev libmysql++3v5 libmysqlclient-dev
Suggested packages:
  libmysql++-doc
The following packages will be REMOVED: libmariadb-dev-compat
The following NEW packages will be installed:
  default-libmysqlclient-dev libmysql++-dev libmysql++3v5 libmysqlclient-dev



$ dpkg -L libmariadb-dev-compat
/.
/usr
/usr/bin
/usr/include
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/share
/usr/share/doc
/usr/share/doc/libmariadb-dev-compat
/usr/share/doc/libmariadb-dev-compat/copyright
/usr/share/man
/usr/share/man/man1
/usr/bin/mysql_config
/usr/include/mysql
/usr/lib/x86_64-linux-gnu/libmysqlclient.a
/usr/lib/x86_64-linux-gnu/libmysqlclient.so
/usr/lib/x86_64-linux-gnu/libmysqlclient_r.a
/usr/lib/x86_64-linux-gnu/libmysqlclient_r.so
/usr/share/doc/libmariadb-dev-compat/changelog.Debian.gz
/usr/share/man/man1/mysql_config.1.gz

Bug#903933: openvpn cannot read config files outside /etc/openvpn when systemd is used

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

tags 903933 + moreinfo
thanks



Hello Alex,

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

I think it comes from the tag

 * ProtectHome=true

in your service file.

Please copy the used service file to /etc/systemd/system, remove the
tag, run 'systemctl daemon-reload" and test it again.


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+AHX8jUOrs1qzDuCfifPIyh0l0FAltl1/AACgkQCfifPIyh
0l2zYg//dEtc4fZrIDRWLUaOQO2rTLr7A5n+EKtn57u4NhvjpcesaDH2rhaV16jU
yvLmPmQVmp4Y/PezghtcDq/XNSw37VsmtMAkb2csrABaYBXr3cu/SyyqSqa+3V3Q
D8k4qUnV9WWVU5SO6Aw5pUVT4ModU+6xH+ooCI0nqldCXAyaoyPbDUSEUjSUspPd
+vEbQE+9AoG0oV7g9GiOIGS4z+wEHUiHNSPwYYzrYw/V/pIBSliN5S7ejk0dM8Pv
QgWS2nmmxYzUUepUM5q82bUSMrDN5826rgvBpj3TGRzpnag3VHirAIrUm3StpS/p
Ju+Dl3dlSRqJ1S9uOMI1SYS1zat36C0DpA4hKZBf8LkKYpGIsSa+UJFfaZbOGcV6
9pPuUTERduS1c1+jv5C7+OyLGP4YCABhXPnFfi6xrSFUmdfHkw9TDeeAgUvWbSh8
VakAwbq8Vf18e8F7G9UM4Tp0JEheabYhMtUuIrCTTSvwm6SsMb4dZJ8lSDeiRiJr
BP0KyNV0xseoNYf9tTx0u0XZpWo+Xk8OzzXR0j89c9mXpg0Kx7N4xi2jZvJiqzGB
wAIQiK9t+pKlaJRzeaPZPwc+ihgeBOqOZjHzzXGNhfu4eK4Lx2Sby+vUO2xIDTeo
/1U6xsBFcAOsutdkN5kgcf0VuKK0mnk63U+i2mP87Afjw/XYqKQ=
=JStA
-END PGP SIGNATURE-

Bug#905448: libidn: Please package libidn2 2.0.5

[Aurelien Jarno]

Source: libidn
Severity: wishlist

glibc 2.28 has replaced its own internal forked idn implementation by
libidn2. However it requires at least version 2.0.5, while the version
in Debian testing/unstable is 2.0.4.

Would it be possible to package this new version? Thanks in advance.

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

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

Bug#890962: [debian-mysql] Bug#890962: libmariadb-dev: Cannot run mysql_config & mariadb_config when dpkg-dev isn't installed

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello!

You have used an version from experimental that was badly packaged and
not intended for wider use.

Can you please confirm if this issue is present in the latest
libmariadb3 et al in Debian sid?


ke 21. helmik. 2018 klo 15.33 Takuro Ashie (as...@clear-code.com) kirjoitti:
>
> Package: libmariadb-dev
> Version: 10.3.0-0+exp2
> Severity: normal
>
> I got the following error when I run mysql_config without dpkg-dev
> package:
>
>   $ mysql_config --cflags
>   /usr/bin/mysql_config: 2: /usr/bin/mysql_config: dpkg-architecture: not 
> found
>   /usr/bin/mysql_config: 2: exec: /usr/lib//mysql_config: not found
>
>   $ mariadb_config --cflags
>   /usr/bin/mariadb_config: 2: /usr/bin/mariadb_config: dpkg-architecture: not 
> found
>   /usr/bin/mariadb_config: 2: exec: /usr/lib//mariadb_config: not found
>
> dpkg-architecture is included in dpkg-dev.
> So libmariadb-dev should depend on it.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-5-amd64 (SMP w/2 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 libmariadb-dev depends on:
> ii  libc62.26-6
> ii  libmariadb3  10.3.0-0+exp2
> ii  zlib1g-dev   1:1.2.8.dfsg-5
>
> libmariadb-dev recommends no packages.
>
> libmariadb-dev suggests no packages.
>
> -- no debconf information

Bug#905447: emacs-goodies-el fails to upgrade

[Russ Allbery]

Package: emacs-goodies-el
Version: 40.0
Severity: important

Setting up emacs-goodies-el (40.0) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
Install emacs-goodies-el for emacs25
install/emacs-goodies-el: Handling emacs25, logged in /tmp/elc_sbQgUN.log
Building autoloads for emacs25 in /usr/share/emacs25/site-lisp/emacs-goodies-el
ERROR: install script from emacs-goodies-el package failed
dpkg: error processing package emacs-goodies-el (--configure):
 installed emacs-goodies-el package post-installation script subprocess 
returned error exit status 1
Errors were encountered while processing:
 emacs-goodies-el
E: Sub-process /usr/bin/dpkg returned an error code (1)

This appears to be because the upgrade process left behind a ton of broken
symlinks in /usr/share/emacs25/site-lisp/emacs-goodies-el.  I deleted all
of the files in that directory and then the installation completed.

Filed as important rather than higher since I think this may be some edge
case that happened on my system rather than a universal problem, since I
haven't let the emacs25 -> emacs upgrade happen yet (waiting for auctex).

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

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

Versions of packages emacs-goodies-el depends on:
ii  bash 4.4.18-3.1
ii  dpkg 1.19.0.5+b1
ii  emacs25-lucid [emacsen]  25.2+1-6+b3
ii  emacsen-common   2.0.8
ii  install-info 6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
pn  elpa-apache-mode
pn  elpa-bar-cursor 
pn  elpa-bm 
pn  elpa-boxquote   
pn  elpa-browse-kill-ring   
pn  elpa-csv-mode   
ii  elpa-debian-el  37.5
pn  elpa-devscripts 
pn  elpa-diminish   
ii  elpa-dpkg-dev-el37.4
pn  elpa-eproject   
pn  elpa-graphviz-dot-mode  
ii  elpa-htmlize1.53-1
pn  elpa-initsplit  
pn  elpa-markdown-mode  
pn  elpa-pod-mode   
pn  elpa-session
pn  elpa-tabbar 
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#904997: convert-from-gbp should warn when deleting unused patches

[Ian Jackson]

Ben Hutchings writes ("Bug#904997: convert-from-gbp should warn when deleting 
unused patches"):
> But it removed the whole of debian/patches, which in this case
> included 2 patches not listed in the series file.

Hrm, yes, it would do that.

I think this should be a snag.

> There is a small, but real, chance of losing valuable patches this

Of course they are still there in the git history, if you can find
them...

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#905446: haskell-hackage-mirror: FTBFS: Module `Control.Monad.Trans.Resource' does not export `monadThrow'

[Andreas Beckmann]

Source: haskell-hackage-mirror
Version: 0.1.1.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
Control: affects -1 + libghc-hackage-mirror-dev libghc-hackage-mirror-doc 
libghc-hackage-mirror-prof

Hi,

haskell-hackage-mirror FTBFS everywhere:
https://buildd.debian.org/status/package.php?p=haskell-hackage-mirror=unstable


[...]
build_recipe
Running debian/hlibrary.setup build --builddir=dist-ghc
Preprocessing library for hackage-mirror-0.1.1.1..
Building library for hackage-mirror-0.1.1.1..
[1 of 1] Compiling Hackage.Mirror   ( src/Hackage/Mirror.hs, 
dist-ghc/build/Hackage/Mirror.o )

src/Hackage/Mirror.hs:75:7: error:
Module `Control.Monad.Trans.Resource' does not export `monadThrow'
   |
75 |   monadThrow,
   |   ^^

src/Hackage/Mirror.hs:82:38: error:
Module `Data.Conduit' does not export `unwrapResumable'
   |
82 | import Data.Conduit ( Source, yield, unwrapResumable, ($=), ($$) )
   |  ^^^
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


Andreas

Bug#905439: su from util-linux breaks autopkgtest

[Antonio Terceiro]

Control: tag -1 + moreinfo unreproducible

On Sat, Aug 04, 2018 at 03:11:17PM +, Lumin wrote:
> Package: autopkgtest
> Version: 5.4.2
> Severity: serious
> 
> the "su" command from util-linux breaks autopkgtest. The previous
> working one comes from shadow.
> 
> python-h5py-dbg is already the newest version (2.8.0-1).
> python-h5py-dbg set to manually installed.
> python-h5py is already the newest version (2.8.0-1).
> python-h5py set to manually installed.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> (Reading database ... 13709 files and directories currently installed.)
> Removing autopkgtest-satdep (0) ...
> autopkgtest [16:38:33]: test command1: set -e ; for py in $(pyversions -r 
> 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
> "import h5py; h5py.run_tests()" ; echo "Testing with $py-dbg:" ; $py-dbg -c 
> "import h5py; h5py.run_tests()" ; done
> autopkgtest [16:38:33]: test command1: [---
> su: user  does not exist
> autopkgtest [16:38:33]: test command1: ---]
> Unexpected error:
> Traceback (most recent call last):
>   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
> command()
>   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 646, in command
> r = f(c, ce)
>   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 584, in cmd_copyup
> copyupdown(c, ce, True)
>   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 469, in copyupdown
> copyupdown_internal(ce[0], c[1:], upp)
>   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 494, in 
> copyupdown_internal
> copyup_shareddir(sd[0], sd[1], dirsp, downtmp_host)
>   File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 408, in 
> copyup_shareddir
> shutil.copy(tb, host)
>   File "/usr/lib/python3.5/shutil.py", line 241, in copy
> copyfile(src, dst, follow_symlinks=follow_symlinks)
>   File "/usr/lib/python3.5/shutil.py", line 120, in copyfile
> with open(src, 'rb') as fsrc:
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/var/run/schroot/mount/unstable-amd64-debomatic-98e10886-4014-46ea-a35e-37ffe71bdcf3/tmp/autopkgtest.mZ5fp7/command1-stdout'
> autopkgtest [16:38:34]: ERROR: testbed failure: unexpected eof from the 
> testbed

Are you sure you saw this with autopkgtest 5.4.2? This bug was present
5.4.1, but explicitly fixed in 5.4.2.

See the attached log for an attempt I just made at reproducing this. The
tests fail but autopkgtest itself works as expected.
autopkgtest [13:26:52]: version 5.4.2
autopkgtest [13:26:52]: host lemur; command line: /usr/bin/autopkgtest 
--apt-upgrade --log-file /tmp/log -B h5py -- lxc --sudo 
autopkgtest-unstable-amd64
autopkgtest: WARNING: running as root in testbed, because no normal user could 
be determined
autopkgtest [13:27:04]:  test bed setup
Get:1 http://deb.debian.org/debian unstable InRelease [233 kB]
Get:2 http://deb.debian.org/debian unstable/non-free Sources.diff/Index [27.8 
kB]
Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB]
Get:4 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[27.9 kB]
Get:5 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index 
[27.8 kB]
Get:6 http://deb.debian.org/debian unstable/non-free Sources 
2018-08-03-2013.11.pdiff [1,306 B]
Get:7 http://deb.debian.org/debian unstable/non-free Sources 
2018-08-04-0814.44.pdiff [665 B]
Get:8 http://deb.debian.org/debian unstable/main Sources 
2018-08-02-1416.04.pdiff [5,521 B]
Get:7 http://deb.debian.org/debian unstable/non-free Sources 
2018-08-04-0814.44.pdiff [665 B]
Get:9 http://deb.debian.org/debian unstable/main Sources 
2018-08-02-2015.39.pdiff [10.3 kB]
Get:10 http://deb.debian.org/debian unstable/main Sources 
2018-08-03-0208.52.pdiff [3,145 B]
Get:11 http://deb.debian.org/debian unstable/main Sources 
2018-08-03-0811.08.pdiff [15.6 kB]
Get:12 http://deb.debian.org/debian unstable/main Sources 
2018-08-03-1408.50.pdiff [39.5 kB]
Get:13 http://deb.debian.org/debian unstable/main Sources 
2018-08-03-2013.11.pdiff [8,876 B]
Get:14 http://deb.debian.org/debian unstable/main Sources 
2018-08-04-0211.02.pdiff [5,928 B]
Get:15 http://deb.debian.org/debian unstable/main Sources 
2018-08-04-0814.44.pdiff [11.7 kB]
Get:16 http://incoming.debian.org/debian-buildd buildd-unstable InRelease [55.3 
kB]
Get:17 http://deb.debian.org/debian unstable/main Sources 
2018-08-04-1411.17.pdiff [12.2 kB]
Get:18 http://deb.debian.org/debian unstable/main amd64 Packages 
2018-08-02-1416.04.pdiff [27.6 kB]
Get:19 http://deb.debian.org/debian unstable/main amd64 Packages 
2018-08-02-2015.39.pdiff [16.0 kB]
Get:17 http://deb.debian.org/debian unstable/main Sources 
2018-08-04-1411.17.pdiff [12.2 kB]
Get:20 http://deb.debian.org/debian unstable/main amd64 Packages 
2018-08-03-0208.52.pdiff [2,583 B]
Get:21 http://deb.debian.org/debian unstable/main amd64 Packages 
2018-08-03-0811.08.pdiff [13.7 

Bug#905445: libgl1: Binaries fail to start with "undefined symbol: _glapi_tls_Current"

[mys...@free.fr]

Package: libgl1
Version: 1.0.0+git20180308-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
 Upgraded system to latest packages, including nvidia-driver 390.77. l

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Tried downgrading libgl1 package to previous version
(1.0.0+git20180308-2~bpo9+1) but did not manage to do so as it would have
desinstalled half of the system.

   * What was the outcome of this action?
N/A

   * What outcome did you expect instead?


These are some error excerpts from various daemons/binaries :

/var/log/Xorg.0.log
[12.270] (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so:
/usr/lib/x86_64-linux-gnu/libGL.so.1: undefined symbol: _glapi_tls_Current
[12.270] (EE) Failed to load module "glx" (loader failed, 0)
[12.437] (EE) NVIDIA(0): Failed to initialize the GLX module; please check
in your X
[12.437] (EE) NVIDIA(0): log file that the GLX module has been loaded
in your X
[12.437] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX
module.  If
[12.437] (EE) NVIDIA(0): you continue to encounter problems, Please try
[12.437] (EE) NVIDIA(0): reinstalling the NVIDIA driver.

glxinfo:
glxinfo: symbol lookup error: /usr/lib/x86_64-linux-gnu/libGL.so.1: undefined
symbol: _glapi_tls_Current











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

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

Versions of packages libgl1 is related to:
ii  libgl1-nvidia-glvnd-glx [libgl1-nvidia-glx-any]  390.77-1

Bug#905444: libcipux-rpc-client-perl: uninstallable in sid: libcipux-perl is gone

[Andreas Beckmann]

Package: libcipux-rpc-client-perl
Version: 3.4.0.7-2.1
Severity: serious
Tags: sid buster
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 libcipux-rpc-client-perl : Depends: libcipux-perl (>= 3.4.0.0) but it is not 
installable


Cheers,

Andreas