Bug#888073: Suggestions about multiarch and AMD64 systems without /lib64, SVABI

[Andreas Jaeger]

On 2018-01-25 20:36, Javier Serrano Polo wrote:
> X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net
> 
> Dear editors,
> 
> I would appreciate if you could point me to the latest version of the
> "System V Application Binary Interface: AMD64 Architecture Processor
> Supplement", which seems to be draft version 0.99.7.
> 
> I run AMD64 Linux systems that do not have a /lib64 directory. These
> systems follow a multiarch structure, which allows to run programs from
> any architecture, e.g. Intel386 on PowerPC. All program interpreters
> have unique names and are located under /lib. AMD64 has
> the /lib/ld-linux-x86-64.so.2 interpreter.
> 
> Section 5.2.1 of the draft says:
> 
> There is one valid program interpreter for programs conforming
> to the AMD64 ABI: /lib/ld64.so.1
> However, Linux puts this in /lib64/ld-linux-x86-64.so.2
> 
> Could the following text be appended?
> 
> Multiarch systems may put this in /lib/ld-linux-x86-64.so.2

No, this is not possible - it would break binary compatibility. The path
is hardcoded into each binary and if you change it, your application
will not run anywhere else,

Andreas

> "may put" could be "puts" if a distro like Debian did this. Debian
> follows a multiarch structure too. It does not follow appendix A.1,
> which says:
> 
> Libraries conforming to the Intel386 ABI will live in the normal
> places like /lib, /usr/lib and /usr/bin. Libraries following the
> AMD64, will use lib64 subdirectories for the libraries,
> e.g /lib64 and /usr/lib64.
> 
> In multiarch systems, Intel386 libraries are under /lib/i386-linux-gnu
> or /usr/lib/i386-linux-gnu, and AMD64 ones are
> under /lib/x86_64-linux-gnu or /usr/lib/x86_64-linux-gnu. Could the
> appendix show this fact?
> 
> Thank you.
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Bug#888478: systemd FTBFS on mipsel: /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.90.20180122 assertion fail ../../bfd/elflink.c:9757

[Helmut Grohne]

Source: systemd
Version: 236-3
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

systemd fails to build from source on mipsel. Very likely this is not
caused by this particular systemd upload, but by the binutils upload
instead. In any case, the build log (attached) ends with:

| [1514/1858] cc  -o test-dhcp-server 
'test-dhcp-server@exe/src_libsystemd-network_test-dhcp-server.c.o' -flto 
-Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie 
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/home/helmutg/systemd-236=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,--start-group src/shared/libsystemd-shared-236.so 
src/libsystemd-network/libsystemd-network.a -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/src/shared' 
-Wl,-rpath-link,/home/helmutg/systemd-236/build-deb/src/shared  
| FAILED: test-dhcp-server 
| cc  -o test-dhcp-server 
'test-dhcp-server@exe/src_libsystemd-network_test-dhcp-server.c.o' -flto 
-Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie 
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/home/helmutg/systemd-236=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,--start-group src/shared/libsystemd-shared-236.so 
src/libsystemd-network/libsystemd-network.a -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/src/shared' 
-Wl,-rpath-link,/home/helmutg/systemd-236/build-deb/src/shared  
| /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.90.20180122 assertion fail 
../../bfd/elflink.c:9757
| collect2: error: ld returned 1 exit status
| [1515/1858] cc  -o test-ipv4ll 
'test-ipv4ll@exe/src_libsystemd-network_test-ipv4ll.c.o' -flto 
-Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie 
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/home/helmutg/systemd-236=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,--start-group src/shared/libsystemd-shared-236.so 
src/libsystemd-network/libsystemd-network.a -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/src/shared' 
-Wl,-rpath-link,/home/helmutg/systemd-236/build-deb/src/shared  
| FAILED: test-ipv4ll 
| cc  -o test-ipv4ll 'test-ipv4ll@exe/src_libsystemd-network_test-ipv4ll.c.o' 
-flto -Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie 
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/home/helmutg/systemd-236=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,--start-group src/shared/libsystemd-shared-236.so 
src/libsystemd-network/libsystemd-network.a -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/src/shared' 
-Wl,-rpath-link,/home/helmutg/systemd-236/build-deb/src/shared  
| /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.90.20180122 assertion fail 
../../bfd/elflink.c:9757
| collect2: error: ld returned 1 exit status
| [1516/1858] cc  -o test-dhcp-client 
'test-dhcp-client@exe/src_libsystemd-network_test-dhcp-client.c.o' -flto 
-Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie 
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/home/helmutg/systemd-236=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,--start-group src/shared/libsystemd-shared-236.so 
src/libsystemd-network/libsystemd-network.a -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/src/shared' 
-Wl,-rpath-link,/home/helmutg/systemd-236/build-deb/src/shared  
| FAILED: test-dhcp-client 
| cc  -o test-dhcp-client 
'test-dhcp-client@exe/src_libsystemd-network_test-dhcp-client.c.o' -flto 
-Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie 
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/home/helmutg/systemd-236=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,--start-group src/shared/libsystemd-shared-236.so 
src/libsystemd-network/libsystemd-network.a -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/src/shared' 
-Wl,-rpath-link,/home/helmutg/systemd-236/build-deb/src/shared  
| /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.90.20180122 assertion fail 
../../bfd/elflink.c:9757
| /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.90.20180122 assertion fail 
../../bfd/elflink.c:9757
| /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.90.20180122 assertion fail 
../../bfd/elflink.c:9757
| collect2: error: ld returned 1 exit status
| [1517/1858] cc  -o test-sched-prio 
'test-sched-prio@exe/src_test_test-sched-prio.c.o' 
'test-sched-prio@exe/src_test_test-helper.c.o' -flto -Wl,--no-undefined 
-Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie -Wl,--gc-sections -g -O2 
-fdebug-prefix-map=/home/helmutg/systemd-236=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z,relro -Wl,--start-group 
src/core/libcore.a src/shared/libsystemd-shared-236.a 
src/shared/libsystemd-shared-236.so -pthread -lrt -lseccomp -lselinux -lmount 
-lblkid -Wl,--end-group -lseccomp -lpam -laudit -lkmod -lapparmor -lmount -lrt 
-lcap -lacl -lcryptsetup -lgcrypt -lip4tc -lip6tc -lseccomp -lselinux -lidn 
-llzma -llz4 -lblkid '-Wl,-rpath,$ORIGIN/src/shared' 
-Wl,-rpath-link,/home/helmutg/systemd-236/build-deb/src/shared  
| ninja: build stopped: subcommand 

Bug#884229: Bug #884229: [packages.debian.org] 500 error/Internal Server Error (in packages-pkgmirror-csail.debian.org)

[Cyril Brulebois]

Hi Olly,

Olly Betts  (2018-01-26):
> Yes.  The directory on pkgmirror-csail actually had two different
> versions of the database using different database backends, so the
> files which aren't in the directory on picconi are essentially an
> old version of the same database.
> 
> That alone shouldn't cause the search to fail though - it should just
> open one or the other (it looks like both Xapian 1.2.x and 1.4.x will
> open the old one in this rather odd situation).
> 
> Xapian's replication should cleanly handle the database being replicated
> switching backends so I'm guessing the replication here is using rsync
> (without --delete-after) or similar?  That might also explain why the
> old database is broken as the databases aren't safe to rsync if an
> update is in progress - if the last rsync of the old database happened
> while an update was in progress, it could have been left broken, which
> would typically result in particular searches failing.
> 
> Updating with rsync can also break searches on the mirror while the
> rsync is in progress even if the master isn't updating, so perhaps we
> should switch to using Xapian's replication?  That's already being
> used for the main website search (I set it up with weasel at Debconf
> 15).
> 
> Happy to assist with that, though I'll probably need ssh access to
> pkgmirror-csail (seems I currently only have it for picconi).  My
> Debian username is "olly".

Looking around without knowing much about pkg stuff:
 - picconi has: conf/pushpdo.mirror → csail pkgmirror-csail.debian.org pkg_user
 - those bits are read by bin/pushpdo, which calls rsync this way:
 rsync -e "ssh -i ${MKEYFILE} -${MPROTO} ${SSH_OPTS}" -av --stats  
"${MIRRORPATH}"  ${MUSER}@${MHOSTNAME}:/does/not/matter 
>"${LOGDIR}/pushpdo.${MLNAME}.log"

I suppose help is welcome to possibly fix/improve that, but I'm no pkg
expert (I just happened to have helped one or twice in the past, and to
still be in the pkg_maint group…)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#888476: ITP: kicad-templates -- read to use project templates for KiCad

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 

* Package name: kicad-templates
  Version : 5.x.x+$date
  Upstream Author : KiCad Community
* URL : https://github.com/KiCad/kicad-templates
* License : CC-BY-SA 4.0 with exception*
  Programming Lang: Plain text
  Description : read to use project templates for KiCad

KiCad is a cross platform and Open Source EDA (Electronics Design Automation)
suite which can be used for the creation of electronic schematic diagrams and
PCB artwork. The flexibility is mainly based on libraries for schematic symbols,
footprints and 3D models. But it also offers a template mechanism which makes it
easy for user to base their work on prepared projects which can include
prearranged schematic and or basic PCB layouts.
Really common examples for such templates are well prepared PCB layouts for the
Arduino boards but also for Raspberry PI or BeagleBone.

Such templates are currently installed by kicad-common. Due the regular updates
to the kicad-templates library it's difficult to follow that dynamic development
with the more contrary static preparation of point releases of KiCad without
(the mostly unneeded) completely rebuild of the existing src:kicad package.
Like done for the schematic symbols, footprints and 3d-packages this ITP is to
move out the templates into a own source package and make package maintenance
easier. For the users this brings more frequent updates of the KiCad community
templates.

The package will be maintained in the pkg-electronics-team together with
Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu).
We will try to keep the package the same in Debian and Ubuntu. More Co
maintainers are welcome!

*License exception
"To the extent that the creation of electronic designs that use 'Licensed
Material' can be considered to be 'Adapted Material', then the copyright
holder waives article 3 of the license with respect to these designs and
any generated files which use data provided as part of the 'Licensed
Material'."

more license information http://kicad-pcb.org/libraries/license/

Bug#888475: ITP: node-node-fetch-npm -- A light-weight module that brings window.fetch to Node.js

[Manas Kashyap]

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

* Package name: node-node-fetch-npm
  Version : 2.0.2
  Upstream Author : David Frank
* URL : https://github.com/npm/node-fetch-npm
* License : Expat
  Programming Lang: JavaScript
  Description : A light-weight module that brings window.fetch to
Node.js
 .
 Instead of implementing XMLHttpRequest in Node.js to run browser-specific
 , why not go from native http to Fetch API directly? Hence node-fetch,
 minimal code for a window.fetch compatible API on Node.js runtime.
 .
 Node.js is an event-based server-side JavaScript engine.

 Praveen agreed to sponsor this package

Bug#888334: survex: FTBFS with FFmpeg 3.5

[Olly Betts]

Control: tags -1 + fixed-upstream patch

> Build log:
> https://people.debian.org/~jcowgill/ffmpeg-3.5-20180122/survex_amd64.build

Thanks James,

Based on the two errors in the log I've pushed a patch upstream (though
not tested with the new FFmpeg yet):

https://git.survex.com/?p=survex/.git;a=commit;h=5e46ae2e95e0f88c9efe8fe2a6632069ef09a18d

I'll probably wait for the next upstream release to upload, unless
FFmpeg 3.5 appears first.

Cheers,
Olly

Bug#888422: libmpfr6 should add Breaks: libmpfr4

[Adrian Bunk]

Control: severity -1 serious

On Thu, Jan 25, 2018 at 09:53:21PM +0200, Adrian Bunk wrote:
> Control: tags -1 - moreinfo
> 
> On Thu, Jan 25, 2018 at 07:39:27PM +0100, Julien Cristau wrote:
> > Control: severity -1 normal
> > Control: tag -1 moreinfo
> > 
> > On Thu, Jan 25, 2018 at 14:11:49 +0200, Adrian Bunk wrote:
> > 
> > > Package: libmpfr6
> > > Version: 4.0.0-5
> > > Severity: serious
> > > 
> > > Mixing libmpfr4 and libmpfr6 doesn't work well:
> > > 
> > > flint-arb FTBFS with:
> > > /usr/bin/ld: warning: libmpfr.so.4, needed by /usr/lib/libflint.so, may 
> > > conflict with libmpfr.so.6
> > > /usr/bin/ld: mpfr_free_func: TLS definition in 
> > > //usr/lib/x86_64-linux-gnu/libmpfr.so.4 section .tbss mismatches non-TLS 
> > > definition in 
> > > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libmpfr.so 
> > > section .text
> > > //usr/lib/x86_64-linux-gnu/libmpfr.so.4: error adding symbols: Bad value
> > > collect2: error: ld returned 1 exit status
> > > 
> > > Some packages like fractalnow FTBFS when gcc and libmpc3 use
> > > different mpfr libraries, with a gcc ICE:
> > > ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <= 
> > > ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
> > > src/fractal_compute_engine.c: In function 
> > > 'FractalLoopMANDELBROTPINTAVERAGECOLORINGDISCRETECURVATURENONESINGLE':
> > > src/fractal_compute_engine.c:285:1: internal compiler error: Aborted
> > > 
> > > It is not even obvious in the latter case that this is always only an ICE,
> > > and not sometimes a miscompilation.
> > > 
> > > The libmpc3 issue is also expected to hit users who have older gcc 
> > > versions
> > > still installed, e.g. gcc-6 still installed after stretch->buster upgrade.
> > > 
> > > When the dependencies are fulfilled users can expect to have working 
> > > software,
> > > even a forced removal on stretch->buster upgrades is better than runtime 
> > > problems.
> > 
> > Is this actually a problem between libmpfr4 and libmpfr6, or libmpfr4
> > and the new libmpfr-dev?
> >...
> 
> This is a problem between libmpfr4 and libmpfr6.
> 
> libmpfr-dev is not installed when gcc ICEs building mathgl.[1,2]
>...

It is not even obvious that we will always be lucky and get an ICE,
it is even possible that in some cases gcc might end up silenty
miscompiling code.

ICE or worse, this would be a problem for anyone still having gcc-6
or older compiler packages from previous releases installed when 
upgrading to buster.

And without an RC bug it would already cause problems much earlier for 
derivates based on testing, since mpfr4 and mpclib3 would currently
migrate to testing before gcc-7 migrates.

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#888422: libmpfr6 should add Breaks: libmpfr4

[Adrian Bunk]

On Thu, Jan 25, 2018 at 11:53:46PM +0100, Vincent Lefevre wrote:
> On 2018-01-25 20:32:45 +0200, Adrian Bunk wrote:
> > On Thu, Jan 25, 2018 at 02:15:15PM +0100, Vincent Lefevre wrote:
> > > On 2018-01-25 14:11:49 +0200, Adrian Bunk wrote:
> > > > Mixing libmpfr4 and libmpfr6 doesn't work well:
> > > 
> > > Wasn't symbol versioning supposed to solve this issue?
> > 
> > Yes, versioning all symbols could solve this problem
> > (assuming libraries like libmpc3 don't expose mpfr internals).
> 
> Note that MPFR internals (among what could be exposed, I think) have
> not changed, so that I don't think this would even be a problem.

In that case adding symbol versions might fix the problems.

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#878088: [Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Sandro Tosi]

On Wed, Jan 24, 2018 at 5:59 PM, Nis Martensen  wrote:
> On 24-01-2018 19:37, Markus Koschany wrote:
>> Thanks. How do you catch the case when security updates are part of a
>> stable point release?
>
> This requires more effort.  Does the package tracker offer a way to
> query such information?  The only other idea I have right now involves
> inspecting the latest entry in changelog.Debian.gz. ("Was the package
> uploaded by the maintainer or one of the normal uploaders?")  Do you
> have other ideas on how a user might know whether a package update
> delivered in a stable point release was a security update?
>
> Would it be feasible to make all security updates available via the
> security update channel?  Then the simple suggested method would be
> sufficient.  But it is probably infeasible, otherwise it would be done?
>
> If there is no good way, maybe asking your question only for the
> packages identified by the proposed method would be acceptable as a
> first step, until a reliable approach is developed?
>
>
> But perhaps Sandro may even be willing to accept a patch based on your
> original version string pattern matching, if his other concerns are
> addressed.  Sandro, what do you think?

i like the idea of trying hard to avoid to ask questions to the users
so maybe we can do something like

* check if that version is coming from the debian-security repo
** if so, copy the relevant security team
** if not, ask the user

in neither case is acceptable to sys.exit() if you cant connect to the
internet: either you decide a default address for this case, or print
a warning message that you cant fetch the needed information and the
sec team wont be copied in the repo.

thanks both for working together on reaching consensus

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#836771: lintian: source-is-missing false positive: correctly named directory in debian/missing-sources

[Chris Lamb]

tags 836771 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=5f3da5839c6819a491b52bfb6993a3a7db773a12


Regards,

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

Bug#888474: ITP: minieap -- Extensible 802.1x client

[GengYu Rao]

Package: wnpp

Severity: wishlist

* Package name : minieap

Upstream Author : updating 
* URL : https://github.com/updateing/minieap
* License : GPL-3.0

Description : Extensible 802.1x client with Ruijie v3/v4 support

It can be used as a supplicant for modified

802.1x authentication methods like Ruijie.

I wish to maintain this package.

Regards,

GengYu Rao

Bug#883719: lintian: false positive spelling-error-in-description (duplicate word) on 'ORA (ORA Recursive Acronym)'

[Chris Lamb]

tags 883719 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=3a514f01f6eb4796a7802ad5fc8802c16f099d23


Regards,

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

Bug#882523: snapd-glib: FTBFS on hurd-i386: tests fail (can't start server)

[Jeremy Bicha]

Considering that snapd is unbuildable on hurd and the architecture
isn't a priority to upstream Snap developers, I'm just going to stop
trying to build this package on hurd.

https://buildd.debian.org/status/package.php?p=snapd

I expect Canonical would take patches for hurd support though if
anyone wrote and submitted them.

Thanks,
Jeremy Bicha

Bug#887978: Backtrace

[John Hasler]

No symbols package to be found:

toncho/~ 23 sudo apt-get install solvespace-dbgsym
[sudo] password for john: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
E: Unable to locate package solvespace-dbgsym

-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Bug#887978: Backtrace

[John Hasler]

Reading symbols from solvespace...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/solvespace 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
cannot load settings: Resource temporarily unavailable
[New Thread 0x7fffe435e700 (LWP 2126)]
malloc(): memory corruption

Thread 1 "solvespace" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x73c646a0 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x73c65cf7 in __GI_abort () at abort.c:90
#2  0x73ca6f87 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x73dacc38 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x73cad27a in malloc_printerr (str=str@entry=0x73daae9e 
"malloc(): memory corruption") at malloc.c:5354
#4  0x73cb05d4 in _int_malloc (av=av@entry=0x73fe0c20 , 
bytes=bytes@entry=232) at malloc.c:3738
#5  0x73cb2a3e in __libc_calloc (n=, 
elem_size=) at malloc.c:3430
#6  0x7fffe9894ff3 in  () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#7  0x7fffe96ddc9d in  () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#8  0x7fffe9526b79 in  () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#9  0x7fffe9544923 in  () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#10 0x7fffe9509e96 in  () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#11 0x7fffe94ee27c in  () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#12 0x7fffe9506c53 in  () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#13 0x7fffe943f643 in  () at /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#14 0x55609049 in SolveSpace::Entity::Draw(bool) ()
#15 0x55609100 in SolveSpace::Entity::DrawAll(bool) ()
#16 0x555f8a25 in SolveSpace::GraphicsWindow::Paint() ()
#17 0x555e5cce in 
SolveSpace::GlWidget::on_expose_event(_GdkEventExpose*) ()
#18 0x76eaa3c4 in Gtk::Widget_Class::expose_event_callback(_GtkWidget*, 
_GdkEventExpose*) ()
at /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1
#19 0x764532ab in  () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#20 0x750b6f9d in g_closure_invoke () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x750c9748 in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x750d1e3f in g_signal_emit_valist () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x750d2ebf in g_signal_emit () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x7656926c in  () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#25 0x76451b88 in gtk_main_do_event () at 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#26 0x75e61bbf in  () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#27 0x75e61b65 in  () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#28 0x75e5e643 in  () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#29 0x75e5efd0 in gdk_window_process_all_updates () at 
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#30 0x763d80e1 in  () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#31 0x75e3dc3c in  () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#32 0x72ca7dd5 in g_main_context_dispatch () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#33 0x72ca81a0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#34 0x72ca84b2 in g_main_loop_run () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#35 0x76450977 in gtk_main () at 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#36 0x76e46d06 in Gtk::Main::run(Gtk::Window&) () at 
/usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1
#37 0x555c40b4 in main ()
(gdb) quit
A debugging session is active.

Inferior 1 [process 2122] will be killed.

Quit anyway? (y or n) y

-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Bug#886799: openafs-modules-dkms: install fails with compile error "implicit declaration of function 'inode_change_ok'"

[A. Lewenberg]

1. Download the three files (*.dsc, *orig.tar.xz, and *debian.tar.xz) 
for the 1.6.9 distribution on the wheezy-backports page 
https://packages.debian.org/source/wheezy-backports/openafs


2. Run git-import-dsc

3. Add the patch file provided by Zdenek Salvet to debian/patches and 
update the series file (patch file: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=886799;filename=meta_port_inode_change_ok.patch;msg=15)


4. Build the package using "pbuild wheezy".

5. Copy the created debian package 
openafs-modules-dkms_1.6.9-2+deb8u4~bpo70+1_all.deb to a wheezy server 
on the 3.2.0-5 kernel and install via "dpkg -i".


6. The install fails; these lines in 
/var/lib/dkms/openafs/1.6.9/build/make.log indicate the error:


/var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c: 
In function 'osi_UFSTruncate':
/var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:195:5: 
error: implicit declaration of function 'inode_change_ok' 
[-Werror=implicit-function-declaration]



Thanks, Adam Lewenberg


On 1/25/2018 6:03 PM, Benjamin Kaduk wrote:

On Thu, Jan 25, 2018 at 09:21:48AM -0800, deb...@lewenberg.com wrote:


The patch you provide works fine with jessie and the 1.6.9 source
packages. However, I cannot get it to work with wheezy.

I compile the openafs source package against wheezy and the compilation
completes without error and creates a bunch of  .deb files. But when I
try to install the patched openafs-modules-dkms on a 3.2.0-5 wheezy
kernel I get the same error as before:

/var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:
In function 'osi_UFSTruncate':
/var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:195:5:
error: implicit declaration of function 'inode_change_ok'
[-Werror=implicit-function-declaration]

Has anyone successfully compiled and installed 1.6.9 on a 3.2.0-5 wheezy
machine?


I have one running, yes.  I put my progress so far into the
soon-to-be-non-canonical packaging repo at
https://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git/log/?id=refs/heads/wheezy
and asked on debian-lts about the procedure for getting it into
wheezy, since this is not technically a security update
(https://lists.debian.org/debian-lts/2018/01/msg00079.html).

How are you building your packages that are failing to build a DKMS
module?

-Ben

Bug#880505: New upstream release and upload to unstable

[Sandro Tosi]

> Is sponsored the upload of network-manager-fortisslvpn just the other day.

that's great, but does it work? all i can do is to import a PAC
(what's a PAC?) script and i can never press save, hmmm

> I completely missed that openfortivpn has not been uploaded to unstable
> yet, so we now have network-manager-fortisslvpn in unstable which can't
> migrate to testing as openfortivpn is not available in testing.
>
> Thus please consider making the upload.

done, 1.6.0 is in unstable

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#888473: RFS: gmchess/0.29.6.1-1 [RC]

[Boyuan Yang]

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org

Dear mentors and chinese-developers folks,

I am looking for a sponsor for my package "gmchess".

 * Package name: gmchess
   Version : 0.29.6.1-1
   Upstream Author : lerosua 
 * URL : [defunct]
 * License : GPL-2+
   Section : games

  It builds those binary packages:

 convert-pgn - chess book format converter
 eleeye - Chinese chess (Xiangqi) engine
 gmchess- Chinese chess game (Xiangqi)
 libeval0   - support library for eleeye
 libeval0-dev - support library for eleeye - development file

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gmchess/gmchess_0.29.6.1-1.dsc

  Git packaging repository:

https://salsa.debian.org/chinese-team/gmchess

  Changes since last upload:

 gmchess (0.29.6.1-1) unstable; urgency=medium
 .
   * New release (2018-01-25).
 + Developing under Debian Salsa platform as upstream already dead.
 + Complete zh_CN translation.
 + Various clean-up and bugfixes.
   * Drop dependency against libglademm, no longer used.
   * Bump Standards-Version to 4.1.3.
   * Bump debhelper compat version to v11.
   * d/menu: File already dropped, thus closes: #776771.
   * d/control: Remove homepage field, upstream already dead.
   * d/control: Add Vcs fields.
   * d/patches: Remove all patches, we are acting as the de fecto upstream.
   * d/copyright: Rewrite in machine-readable format.
   * d/watch: Removed, upstream dead.
   * d/rules: Modernize usage of dh sequencer.

This upload would drop build-dependency against libglademm thus makes gmchess
not affected by RC bug #885078 (libglademm's removal).

Regards,
Boyuan Yang

Bug#888470: pa_glib_main_loop_new()

[Joël Krähemann]

Due to refactoring in GSequencer pa_main_loop_new() was not suitable
anymore. Moving to pa_glib_main_loop_new() actually solved the issue.

Bests,
Joël

Bug#886799: openafs-modules-dkms: install fails with compile error "implicit declaration of function 'inode_change_ok'"

[Benjamin Kaduk]

On Thu, Jan 25, 2018 at 09:21:48AM -0800, deb...@lewenberg.com wrote:
> 
> The patch you provide works fine with jessie and the 1.6.9 source 
> packages. However, I cannot get it to work with wheezy.
> 
> I compile the openafs source package against wheezy and the compilation 
> completes without error and creates a bunch of  .deb files. But when I 
> try to install the patched openafs-modules-dkms on a 3.2.0-5 wheezy 
> kernel I get the same error as before:
> 
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:
>  
> In function 'osi_UFSTruncate':
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:195:5:
>  
> error: implicit declaration of function 'inode_change_ok' 
> [-Werror=implicit-function-declaration]
> 
> Has anyone successfully compiled and installed 1.6.9 on a 3.2.0-5 wheezy 
> machine?

I have one running, yes.  I put my progress so far into the
soon-to-be-non-canonical packaging repo at
https://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git/log/?id=refs/heads/wheezy
and asked on debian-lts about the procedure for getting it into
wheezy, since this is not technically a security update
(https://lists.debian.org/debian-lts/2018/01/msg00079.html).

How are you building your packages that are failing to build a DKMS
module?

-Ben

Bug#888234: dpkg: packages not fully upgraded, but dpkg doesn't notice

[Guillem Jover]

Hi!

On Fri, 2018-01-26 at 01:04:08 +0100, Christoph Anton Mitterer wrote:
> On Fri, 2018-01-26 at 00:42 +0100, Guillem Jover wrote:
> > Are you sure they are not fully upgraded? What makes you think so?
> > Just the dpkg.log below?
> 
> No, I ignored it at first cause I thought it's not so unlikely, that
> the log simply didn't got flushed out before the freeze.

Yeah, I guess it's never been considered an important file to preserve
above all, including performance degradation. I'll have to ponder, or
benchmark whether fdatasync(2)ing the log file would penalize too much.

> But then there was recently an upgrade to glibc (which includes local
> re-generation). A crash happened and afterwards e.g. gnome-terminal
> didn't even start anymore (with some locale related errors, when
> started from xterm).
> Once I regenerated the locales, gnome-terminal worked fine again.
> 
> Of course it could simply be, that the locales didn't get flushed out
> in time (respectively no commit was made in btrfs),... but then dpkg
> shouldn't think it would be configured, right?

dpkg does not and cannot control what and how things are done in
packages's maintainer scripts. So it can happen that dpkg syncs all
its databases and all the extracted files to disk, but the maintainer
scripts do not call the equivalent fsync(2) and thus those linger
around in memory and get lost on a crash. I'd expect most maintainer
script to not be abrupt-crash-safe, or even many applications TBH,
as not many things do the rename(2)/fsync(2) dance or similar.

> > > Normally dpkg -C would show this then, but it doesn't.
> > > Neither does dpkg --configure -a do anything.
> > 
> > And there are no packages in the status file with Status less than
> > installed. And no lingering files under «/var/lib/dpkg/updates»?
> 
> /var/lib/dpkg/updates/ is empty (well at least right now... not sure if
> it would have gotten cleaned up somehow else in the meantime).

Any subsequent write action would have incorporated the database
journal entries.

> > > This happened alrready quite some times now, an probably my system
> > > has
> > > many packages in a state not fully installed, while dpkg thinks
> > > everything
> > > would be fine.
> > 
> > dpkg is very careful about how it handles its database. If it think
> > they are installed, and there are no update journal entries on the
> > above directory. Then this might indicate something more severe like
> > a very broken filesystem on-disk or implementation or hardware
> > failure
> > or similar.
> 
> Arguably, btrfs isn't perfect, but so far I never found any real
> corruptions in case of any freezes/crashes/etc.
> The only thing what I ever found was that something wasn't committed
> yet, and got completely removed, but that in turn should dpkg protect
> against, AFAIU (with syncs at the appropriate places).

dpkg can only protect what it does itself.

> > > Interestingly: debsums -asc doesn't find problems.
> > 
> > That to me would indicate that the packages are either the old
> > versions or the new ones, but thay match.
> 
> Is there any easy way to check that (i.e. whether they files are all
> still old, but dpkg thinks the upgrade was performed and the new
> version would be in place)?
> I did a random sample and compared one file of libc6 and locales
> package, but from my system with that of the .deb,... but of course I
> may have just picked the wrong one that still matches.

The easiest is probably to download the .debs matching the versions in
the system, and compare their md5sums with the ones in the dpkg db. If
«dpkg -V» then says there's no problem, then that should mean the
unpacked files are fine.

This of course does not cover any files generated by maintainer
scripts.

> Could it be, that they always got unpacked, but not configured and that
> only this information would have been somehow lost?
> Cause that could explain why the locales haven't been regenerated.

If they are unpacked but not configured the new files would be on
disk, and the new md5sums as well, and the db would contain an
appropriate status. The package status does not progress until the
current stage has been finished, and those get properly synced to
disk. So in principle no, that should never happen.

I assume though that the locales had been generated but not flushed
to disk. I don't see any fsync(2)/fdatasync(2) in the glibc source
for the locale generators (one is a shell script, the other is a perl
script, and the last is a C program).

So, if the above checks look fine, I'd say the only thing that can
be done is perhaps to consider syncing the log file, but that might
be too much. And perhaps clone and reassign to glibc to make its
maintainer scripts more robust against abrupt-crashes. But take
into account this will be an uphill battle, as mentioned above
most maintscript and even most programs and applications are not
abruch-crash safe anyway…

Thanks,
Guillem

Bug#888469: [Aptitude-devel] Bug#888469: aptitude: build-dep gmime fails

[Axel Beckert]

Control: forcemerge 509100 -1

Hi,

= wrote:
> I tried (on the shell command-line):
> 
> aptitude build-dep gmime
> 
> and got an error message:
> 
> Unable to satisfy the build-depends: Build-Depends: libgpgme11-dev
> Unable to apply some actions, aborting

This is https://bugs.debian.org/509100 ("aptitude: build-dep fails
when a virtual package is needed"): libgpgme11-dev is a virtual
package.

Hence merging.

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#888461: nvidia-persistenced: Daemon will not start

[Marc Bonnor]

I would like to use the graphics card on my laptop when I need it.

ii  bumblebee-nvidia  3.2.1-
17amd64NVIDIA Optimus support using
the proprietary NVIDIA driver
ii  glx-alternative-
nvidia0.8.1   amd64
allows the selection of NVIDIA as GLX provider
ii  libegl-nvidia0:amd64  384.111-
3   amd64NVIDIA binary EGL library
ii  libegl1-nvidia:amd64  384.111-
3   amd64NVIDIA binary EGL library
(non-GLVND variant)
ii  libgl1-nvidia-glx:amd64   384.111-
3   amd64NVIDIA binary OpenGL/GLX
library (non-GLVND variant)
ii  libgles-nvidia1:amd64 384.111-
3   amd64NVIDIA binary OpenGL|ES 1.x
library
ii  libgles-nvidia2:amd64 384.111-
3   amd64NVIDIA binary OpenGL|ES 2.x
library
ii  libgles1-glvnd-nvidia:amd64   384.111-
3   amd64NVIDIA binary OpenGL|ES 1.x
GLVND stub library
ii  libglx-nvidia0:amd64  384.111-
3   amd64NVIDIA binary GLX library
ii  libnvidia-cfg1:amd64  384.111-
3   amd64NVIDIA binary OpenGL/GLX
configuration library
ii  libnvidia-egl-wayland1:amd64  384.111-
3   amd64NVIDIA binary Wayland EGL
external platform library
ii  libnvidia-eglcore:amd64   384.111-
3   amd64NVIDIA binary EGL core
libraries
ii  libnvidia-glcore:amd64384.111-
3   amd64NVIDIA binary OpenGL/GLX core
libraries
ii  libnvidia-ml1:amd64   384.111-
3   amd64NVIDIA Management Library
(NVML) runtime library
ii  nvidia-alternative384.111-
3   amd64allows the selection of NVIDIA
as GLX provider
ii  nvidia-driver 384.111-
3   amd64NVIDIA metapackage
ii  nvidia-driver-bin 384.111-
3   amd64NVIDIA driver support binaries
ii  nvidia-driver-libs-nonglvnd:amd64 384.111-
3   amd64NVIDIA metapackage (non-GLVND
OpenGL/GLX/EGL/GLES libraries)
ii  nvidia-egl-common 384.111-
3   amd64NVIDIA binary EGL driver -
common files
ii  nvidia-egl-icd:amd64  384.111-
3   amd64NVIDIA EGL installable client
driver (ICD)
ii  nvidia-egl-wayland-common 384.111-
3   amd64NVIDIA binary Wayland EGL
external platform - common files
ii  nvidia-egl-wayland-icd:amd64  384.111-
3   amd64NVIDIA Wayland EGL external
platform library (ICD)
ii  nvidia-installer-
cleanup  20151021+7  amd64c
leanup after driver installation with the nvidia-installer
ii  nvidia-kernel-
common  20151021+7  amd64  
  NVIDIA binary kernel module support files
ii  nvidia-kernel-dkms384.111-
3   amd64NVIDIA binary kernel module
DKMS source
ii  nvidia-kernel-support 384.111-
3   amd64NVIDIA binary kernel module
support files
ii  nvidia-legacy-check   384.111-
3   amd64check for NVIDIA GPUs
requiring a legacy driver
ii  nvidia-modprobe   384.111-
1   amd64utility to load NVIDIA kernel
modules and create device nodes
ii  nvidia-nonglvnd-vulkan-common 384.111-
3   amd64NVIDIA Vulkan driver - common
files (non-GLVND variant)
ii  nvidia-nonglvnd-vulkan-icd:amd64  384.111-
3   amd64NVIDIA Vulkan installable
client driver (ICD) (non-GLVND variant)
ii  nvidia-persistenced   384.111-
1   amd64daemon to maintain persistent
software state in the NVIDIA driver
ii  nvidia-settings   384.111-
1   amd64tool for configuring the
NVIDIA graphics driver
ii  nvidia-smi384.111-
3   amd64NVIDIA System Management
Interface
ii  nvidia-
support20151021+7  amd6
4NVIDIA binary graphics driver support files
ii  nvidia-vdpau-driver:amd64 384.111-
3   amd64Video Decode and Presentation
API for Unix - NVIDIA driver
ii  xserver-xorg-video-nvidia 384.111-
3   amd64   

Bug#888312: RFS: streamlink/0.10.0+dfsg-1

[Paul Wise]

On Thu, 2018-01-25 at 22:35 +0100, Alexis Murzeau wrote:

> Without this override, dh_installchangelogs uses "docs/changelog.rst"
> instead, which contains only an include statement and not the actual
> content (see diffoscope in attachment)
> 
> According to its sources, dh_installchangelogs iterates ".", "doc/",
> "docs/" directories in this order and takes the last found. Only if
> there are several matches in a given directory, it takes the first
> one found in that directory.

I see, thanks for the explanation. Seems I misread the code :)

> I've added a comment about that on top of
> override_dh_installchangelogs.

Great.

> Do you think there is something better to do here ?

Maybe debhelper could be smarter about not choosing tiny changelog
files over larger files, but you would still need the override for
older suites.

If it doesn't already, it would be a good idea for lintian to check
that the upstream changelog file is a sane one; it should have a
version number in it and not be too tiny.

If you would like to do some more research and file bugs for these,
that would be appreciated.

> The python3-iso3166 package is indeed available, the missing one is
> iso639 which I miss-written. When not using pycountry, streamlink
> need both iso3166 and iso639 python packages.
> I updated the comment with python3-iso639 instead of python3-iso3166.

I see, great.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#882187: git-buildpackage: gbp pull: add option to setup missing tracking branches upstream, pristine-tar

[Andreas Beckmann]

On 2018-01-24 22:20, Michael Stapelberg wrote:
> To be able to push to the repository, you don’t need to authenticate
> when cloning it, you can also configure git to automatically substitute
> the URLs:
> 
> git config --global url."git.debian.org:/git/".insteadOf 
> "https://anonscm.debian.org/cgit/;
> git config --global url."git.debian.org:/git/".insteadOf 
> "https://anonscm.debian.org/git/;
> git config --global url."git.debian.org:/git/".insteadOf 
> "git://anonscm.debian.org/"

Great idea! And especially

git config --global url."g...@salsa.debian.org:".pushInsteadOf 
"https://salsa.debian.org/;

should save me a lot of "git remote set-url --push ..." :-)

Many thanks!


Andreas

Bug#888461: nvidia-persistenced: Daemon will not start

[Andreas Beckmann]

On 2018-01-25 23:54, Marc wrote:
> Jan 26 06:31:48 debian nvidia-persistenced: Failed to open libnvidia-cfg.so.1:
> libnvidia-cfg.so.1: cannot open shared object file: No such file or directory

> /usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-cfg.so.1
> /usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-cfg.so.384.111
> /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1

but the glx alternative does not add it as a slave and link it to
/usr/lib/x86_64-linux-gnu

Which nvidia/cuda packages do you have installed?

dpkg -l | grep -E 'nvidia|cuda'

(i.e. for which usage scenario do you want to use nvidia-persistenced?)


Andreas

Notes to myself:
* nvidia-persistenced does not have a dependency on a driver component
(either xorg driver or libcuda1)
* nvidia-alternative-glx probably needs to put libnvidia-cfg.so.1 into
misc_slaves to be available on cudaonly
* nvidia-alternative-glx: lib*_mesa_slaves should look in mesa-diverted
first, all the /mesa/ path bits can go away - that was never used

Bug#888472: Please switch to gktspell

[Laurent Bigonville]

Source: xchat
Version: 2.8.8-11
Severity: normal

Hi,

xchat it is the last user of libsexy. Last upstream release of libsexy
is 2007 and I guess it's time to RM it.

Could you please switch to gtkspell instead of libsexy?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#797844: kmail: TLSv1.1 and TLSv1.2 are not supported

[Maximilian Engelhardt]

tag 797844 + patch
thanks

Hi,

I recently ran into this bug when my mail server switched to TLS 1.2 only.

I backported the upstream changes to the Debian stretch packages and are 
running them now without problems.

The patches are are attached to this mail. Affect source packages are kimap, 
libkf5ksieve and kde4libs.

As the patches are fairly trivial can this be applied to Debian stable? If I 
remember correctly severity important classifies for fixing in stable.

Pleas let me know if you have any questions.

Thank you for maintaining KDE packages in Debian!--- a/kio/kio/tcpslavebase.cpp
+++ b/kio/kio/tcpslavebase.cpp
@@ -499,7 +499,7 @@
 {
 if (d->usingSSL)
 return false;
-return d->startTLSInternal(KTcpSocket::TlsV1) & ResultOk;
+return d->startTLSInternal(KTcpSocket::SecureProtocols) & ResultOk;
 }
 
 TCPSlaveBase::SslResult TCPSlaveBase::TcpSlaveBasePrivate::startTLSInternal (KTcpSocket::SslVersion version,
--- a/src/loginjob.cpp
+++ b/src/loginjob.cpp
@@ -383,7 +383,7 @@
 
 switch (d->authState) {
 case LoginJobPrivate::StartTls:
-d->sessionInternal()->startSsl(KTcpSocket::TlsV1);
+d->sessionInternal()->startSsl(KTcpSocket::SecureProtocols);
 break;
 
 case LoginJobPrivate::Capability:
--- a/src/kmanagesieve/sessionthread.cpp
+++ b/src/kmanagesieve/sessionthread.cpp
@@ -453,7 +453,7 @@
 m_sslCheck->setInterval(60 * 1000);
 connect(m_sslCheck, ::timeout, this, ::slotSslTimeout);
 }
-m_socket->setAdvertisedSslVersion(KTcpSocket::TlsV1);
+m_socket->setAdvertisedSslVersion(KTcpSocket::SecureProtocols);
 m_socket->ignoreSslErrors();
 connect(m_socket, ::encrypted, this, ::slotEncryptedDone);
 m_sslCheck->start();


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

Bug#888471: Please keep libsexy out of buster

[Laurent Bigonville]

Source: libsexy
Version: 0.1.11-4
Severity: serious

Hi,

I guess that libsexy should not be part of buster.

The package only seems to be used by xchat. Xchat could switch to
gtkspell I guess?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#777089: Next python-mote pre-condition - issue with pybuild: python-backports.tempfile conflicting python-backports.weakref

[Simon McVittie]

On Thu, 25 Jan 2018 at 17:45:33 +, peter green wrote:
> > However, in Debian case, I do not know how this can be handled as
> > 2 packages cannot hold the same file (even if __init__ is only an empty
> > file), and at least one must be present (if you install only one).

The Python jargon is that the "backports" shared by backports.tempfile
and backports.weakref is a "namespace package".

For Python 2, dh_python2 handles this: python-lazr.restfulclient and
python-lazr.uri are an example of cooperating packages that share a
namespace package.

For Python >= 3.3, the __init__.py is unnecessary due to
.

> I'm not a python expert but I expect the least-horrible way to do this
> would be to ship a package that only contained the __init__. Then have
> all the python-backports.* packages depend on it.

This is not necessary, and would probably (hopefully?) lead to rejection
from the NEW queue.

smcv

Bug#885754: New upload planned

[Adrian Bunk]

Control: reassign -1 network-manager
Control: forcemerge 887815 -1
Control: affects 887815 src:network-manager-strongswan src:network-manager-ssh 
src:network-manager-iodine

On Thu, Jan 25, 2018 at 12:46:37AM +, Ian Jackson wrote:
> FYI Harald Dunkel has emailed me to say he plans to provide a fixed
> version, which I intend to sponsor.

#885754 was a bug in network-manager, and has already been fixed there.

> Ian.

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#888470: pulseaudio: make pulseaudio callback less penetrant

[Joël Krähemann]

Package: pulseaudio
Version: 11.1-4
Severity: normal
File: pulseaudio

Dear Maintainer,

pulseaudio callback is such penetrant that it brings down my desktop 
environment.
The current situation is as running GSequencer with pulseaudio on a macbook pro 
2016
it slows down the entire desktop. The mouse pointer starts to jump and no 
precise
pointing anymore possible. Keyboard input is delayed, too. The input subsystem 
went
mad.

The issue was introduced recently. Prior it worked seemless. There was some 
modifications
in pulseaudio disturbing my application and desktop environment.

During early development of GSequencer, I experienced similar problems as 
writing to
ALSA.

A software mustn't bring down the input subsystem.

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/24 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 pulseaudio depends on:
ii  adduser  3.116
ii  libasound2   1.1.3-5
ii  libasound2-plugins   1.1.1-1
ii  libc62.26-5
ii  libcap2  1:2.25-1.2
ii  libdbus-1-3  1.12.2-1
ii  libgcc1  1:7.2.0-20
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-2
ii  liborc-0.4-0 1:0.4.28-1
ii  libpulse011.1-4
ii  libsm6   2:1.2.2-1+b3
ii  libsndfile1  1.0.28-4
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   7.2.0-20
ii  libsystemd0  236-3+b1
ii  libtdb1  1.3.15-2
ii  libudev1 236-3+b1
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 9.20170808
ii  pulseaudio-utils 11.1-4

Versions of packages pulseaudio recommends:
ii  dbus-user-session  1.12.2-1
ii  libpam-systemd 236-3+b1
ii  rtkit  0.11-5

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 236-3+b1

Bug#888424: Nothing happens when enabling extension

[Simon McVittie]

On Thu, 25 Jan 2018 at 13:38:55 +0100, Enrico Zini wrote:
> Looking at 
> /usr/share/gnome-shell/extensions/topic...@phocean.net/metadata.json
> gnome-shell 3.26 is not listed in shell-version.

Recent gnome-shell versions don't enforce the supported version list
from metadata.json, so this *should* already work; the Steam tray-icon
certainly does work with 3.26 in an X11 session.

If you have previously toggled
/org/gnome/shell/disable-extension-version-validation in dconf, then
your Shell might still be enforcing the version check? (Try
dconf-editor, or
`gsettings reset org.gnome.shell disable-extension-version-validation`;
only the default behaviour changed, the code for the check still exists.)

For this particular extension it might also be necessary to log out and
back in: I'm not sure whether the X11 tray-icon embedding protocol is
such that it can work correctly if the tray appears when you are already
running an app that wants to be displayed there.

Finally, if you're using the default GNOME-on-Wayland session, it might
be necessary to switch session mode to GNOME on Xorg (using the gear
wheel icon below the password box, if you're using gdm) - I don't
know whether tray icon embedding works in XWayland.

smcv

Bug#888465: CPU usage reporting issues

[Ryan Thoryk]

(cleaned the post up for readability, sorry about that)

On 01/25/2018 05:40 PM, Hans van Kranenburg wrote:

This means that your vcpus want to execute work but are not being
scheduled on a physical cpu core. Either the physical machine gets too
much work from all the virtual machines that are requesting cpu time, or
other things are going on, like your virtual machine getting paused
(e.g. when doing live migration there's a handover moment when it's
shortly paused and then resumed, this is also visible as a short 100%
steal spike).


After going over log files, it appears that the issue started when 
Amazon did a live migration of the VM, probably for the Meltdown patching.



A patch to fix that cpu accounting breakage (picked from linux 4.15) was
included in 4.9.65-3. So only for the 4.9.0-3 (which actual version?)
you could be seeing that one happening.


The versions were both 4.9.30-2+deb9u2 and the latest, 4.9.65-3+deb9u2.  
So basically the kernel never recovered properly after being paused 
during a live migration.



Because of the mentioned steal time fix that was included in a version
in between the 2 versions you mention, my first suggestion would be to
see if the symptoms on the old and new kernel are exactly the same, or
if they are only similar but different.

Hans


I already rebooted the system running the 4.9.65 kernel, and beforehand, 
the symptoms were the same.  The CPU usage stats went back to normal 
after the reboot.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#888391: lynx: RUBOUT deletes character in FRONT of the cursor instead of BEHIND

[Thomas Dickey]

On Thu, Jan 25, 2018 at 11:43:28AM +0100, Axel Beckert wrote:
> Control: tag -1 + confirmed upstream
> Control: found -1 2.8.9dev11-1
> Control: found -1 2.8.9dev1-2
> Control: fixed -1 2.8.8dev.12-2
> Control: retitle -1 lynx: DEL deletes character in FRONT of the cursor 
> instead of BEHIND
> 
> Hi,
> 
> Ankman wrote:
> > Deleting a character (anywhere: web form, url fields...) with RUBOUT
> > (or DEL) deletes the character BEFORE the cursor instead of AFTER
> > (next right to the cursor).
> 
> thanks for this bug report. This is indeed the case, but I never
> noticed it (probably because I usually use backspace in web form
> fields).
> 
> > I want to note this might not be a bug but a design flaw.
> 
> It's very likely a bug, or more specific: It seems to be a regression.
> 
> > But this happens in any lynx on Linux, UNIX, OpenBSD I tried.
> 
> I've tested all lynx versions available in supported Debian releases
> and found that those lynx versions in
> 
> * Debian Unstable/Buster (2.8.9dev16-2),
> * Debian 9 Stretch (2.8.9dev11-1), and
> * Debian 8 Jessie (2.8.9dev1-2)
> 
> exhibit this behaviour, but not the lynx version in
> 
> * Debian 7 Wheezy (2.8.8dev.12-2).

hmm.  I rewrote a chunk of configuration around this point:

2013-11-28 (2.8.8pre.1)
2013-11-28 (2.8.8dev.17)
...
* modify logic in lkcstring_to_lkc() to allow named keys, e.g., from curses,
  to be used consistently in a KEYMAP directive -TD
...
* add symbols in Keysym_Strings[] and table in setup_vtXXX_keymap() for
  function keys 2-12, to improve keymap-configurability -TD
* change extra-key #define's in LYStrings.h to enum -TD
* cleanup pre-2.7 debris from LYStrings.c and LYStrings.h -TD
* modify tables for key-bindings and edit-bindings to allow them to be reloaded
  to their initial values -TD

I'll test the Debian 7 version to see if I can reproduce the behavior
as described.
 
> So I assume, this regression has crept in during the 2.8.9
> development (since Debian does not patch any Lynx code, only default
> config and the configure script).
> 
> P.S.: I've never heard of "RUBOUT" as an alternative name for DEL or
> DELETE.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#888234: dpkg: packages not fully upgraded, but dpkg doesn't notice

[Christoph Anton Mitterer]

On Fri, 2018-01-26 at 00:42 +0100, Guillem Jover wrote:
> Are you sure they are not fully upgraded? What makes you think so?
> Just the dpkg.log below?

No, I ignored it at first cause I thought it's not so unlikely, that
the log simply didn't got flushed out before the freeze.

But then there was recently an upgrade to glibc (which includes local
re-generation). A crash happened and afterwards e.g. gnome-terminal
didn't even start anymore (with some locale related errors, when
started from xterm).
Once I regenerated the locales, gnome-terminal worked fine again.

Of course it could simply be, that the locales didn't get flushed out
in time (respectively no commit was made in btrfs),... but then dpkg
shouldn't think it would be configured, right?


Also, when I was actually looking at the upgrade process in aptitude...
I had several times such a freeze, and it didn't even reach the
"Setting up..." phase.
So intuitively I'd guess it couldn't finish that after the freeze (at
least the HDD LED didn't show any flashing).



> Intel microcode?

Unlikely, cause I've seen these freezes long before the
spectre/meltdown upgrades, and at least once again after the microcode
was withdrawn since.


> > Normally dpkg -C would show this then, but it doesn't.
> > Neither does dpkg --configure -a do anything.
> 
> And there are no packages in the status file with Status less than
> installed. And no lingering files under «/var/lib/dpkg/updates»?

/var/lib/dpkg/updates/ is empty (well at least right now... not sure if
it would have gotten cleaned up somehow else in the meantime).

/var/lib/dpkg# grep ^Status status | sort -u
Status: deinstall ok config-files
Status: hold ok installed
Status: install ok installed

but these are all expected (i.e. the deinstall config-files are
deleted/not-purged packages)


> > This happened alrready quite some times now, an probably my system
> > has
> > many packages in a state not fully installed, while dpkg thinks
> > everything
> > would be fine.
> 
> dpkg is very careful about how it handles its database. If it think
> they are installed, and there are no update journal entries on the
> above directory. Then this might indicate something more severe like
> a very broken filesystem on-disk or implementation or hardware
> failure
> or similar.

Arguably, btrfs isn't perfect, but so far I never found any real
corruptions in case of any freezes/crashes/etc.
The only thing what I ever found was that something wasn't committed
yet, and got completely removed, but that in turn should dpkg protect
against, AFAIU (with syncs at the appropriate places).

As for the hardware: I think it could then only be the SSD, cause this
is the only common thing, after I switched the notebook now.


> > Interestingly: debsums -asc doesn't find problems.
> 
> That to me would indicate that the packages are either the old
> versions or the new ones, but thay match.

Is there any easy way to check that (i.e. whether they files are all
still old, but dpkg thinks the upgrade was performed and the new
version would be in place)?
I did a random sample and compared one file of libc6 and locales
package, but from my system with that of the .deb,... but of course I
may have just picked the wrong one that still matches.


Could it be, that they always got unpacked, but not configured and that
only this information would have been somehow lost?
Cause that could explain why the locales haven't been regenerated.


> > I have no idea how to debug this any further... please tell me if
> > you need
> > anything.
> > btw: this is on btrfs
> 
> That alone seems very suspect IMO.

;-)
Well it's much better IMO than it's reputation. Of course when one uses
not-yet-stable features like qgroups or raid56, things get easily
problematic,... but other than that the design of btrfs with CoW should
in principle prevent any corruptions and just allow for either-old-or-
new.
And as I've said, so far I never found a really corrupt file.



Thanks :)

Bug#886154: gnome-shell: segfault in libgobject

[Simon McVittie]

Control: tags -1 + moreinfo

On Wed, 03 Jan 2018 at 17:29:00 +, Kjö Hansi Glaz wrote:
> Thread 1 (Thread 0x7fe7bb08d340 (LWP 1981)):
> #0  0x7fe7ba4d0da2 in g_type_check_instance_cast
> (type_instance=0x558a749f68a0, iface_type=94053112939904)
> at ../../../../gobject/gtype.c:4057
> #1  0x7fe7b7c65278 in st_label_set_text (label=0x558a749ee890
> [StLabel], text=0x558a772bcf90 "76") at ../src/st/st-label.c:331
> #2  0x7fe7ba4b2a3e in object_set_property (nqueue=0x558a77cd1230,
> value=, pspec=0x558a732e1cb0 [GParamString],
> object=0x558a749ee890 [StLabel]) at ../../../../gobject/gobject.c:1439

Do you still get this with libgjs0g >= 1.50.2-3? This looks like it might
be the same thing as #881301.

(Unfortunately libgjs0g (>= 1.50.2-3) seems to have solved crashes for
some people, and caused new crashes for others... so be prepared to
downgrade back to 1.50.2-2 if necessary.)

smcv

Bug#888465: CPU usage reporting issues

[Ryan Thoryk]

On 01/25/2018 05:40 PM, Hans van Kranenburg wrote:

Hi Ryan,

On 01/26/2018 12:20 AM, Ryan Thoryk wrote:

Package: linux-image-4.9.0-5-amd64
Version: 4.9.65-3+deb9u2
Severity: normal

I'm having an issue with CPU usage reporting, tested on kernels 4.9.0-3
and 4.9.0-5.  The machines are running on Amazon EC2, which could be
related.  With the "sar" utility, after some time, the system's "steal"
value periodically is 100%,

This means that your vcpus want to execute work but are not being
scheduled on a physical cpu core. Either the physical machine gets too
much work from all the virtual machines that are requesting cpu time, or
other things are going on, like your virtual machine getting paused
(e.g. when doing live migration there's a handover moment when it's
shortly paused and then resumed, this is also visible as a short 100%
steal spike).
After going over log files, it appears that the issue started when 
Amazon did a live migration of the VM, probably for the Meltdown patching.

and the normal CPU user/system values,
including idle, are always 0.  When running a cpu-intensive app and
using the "top" utility, the user and system values are always 0, the
"idle" field stays at 100%, and only the "wait" field increases.

Sounds a lot like this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871608

A patch to fix that cpu accounting breakage (picked from linux 4.15) was
included in 4.9.65-3. So only for the 4.9.0-3 (which actual version?)
you could be seeing that one happening.
The versions were both 4.9.30-2+deb9u2 and the latest, 4.9.65-3+deb9u2.  
So basically the kernel never recovered properly after being paused 
during a live migration.

The attached file shows the "sar" output around the time the issue
started.  This has happened on 2 separate machines (started at different
times on each), and a reboot appears to (temporarily) fix the issue.
I'm wondering if anyone else has this issue, and if it could be
something to do with the hypervisor.

Because of the mentioned steal time fix that was included in a version
in between the 2 versions you mention, my first suggestion would be to
see if the symptoms on the old and new kernel are exactly the same, or
if they are only similar but different.

Hans
I already rebooted the system running the 4.9.65 kernel, and beforehand, 
the symptoms were the same.  The CPU usage stats went back to normal 
after the reboot.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#888199: gnome-shell crashes at different circumstances (not usable anymore)

[Simon McVittie]

Control: reassign 888199 libgjs0g 1.50.3-1
Control: severity 888199 grave
Control: tags 888199 + moreinfo
Control: affects 888199 gnome-shell

On Thu, 25 Jan 2018 at 21:39:22 +0100, Thomas Renard wrote:
> I downgraded libgjs0g to 1.50.2-2 and the whole desktop is stable again.
> 
> Bug seems to depend on bug #887082 and #881301

The changes I merged from upstream in 1.50.2-3 to address #881301 were
intended to make gnome-shell *more* robust/less likely to crash, by
turning potential segfaults into warnings, so I'm quite surprised we're
seeing the opposite effect here.

I'm fairly sure #887082 is a pre-existing bug that was made visible by
the changes in 1.50.2-3: previously, accessing a previously destroyed
object would have failed silently, but now gjs makes more noise about it
(which will hopefully help us to track down and fix it). I get the
same backtrace reported in the Journal that you do (#887082), quite
frequently, but my gnome-shell isn't crashing...

I don't see any gnome-shell crashes (or even unsuccessful exits) in the
journalctl output that you attached, but your log seems to end at the
point where you log in to gdm. Can you provide further log entries from
after you've logged in?

Would you be able to install systemd-coredump, upgrade libgjs0g to the
broken version, let gnome-shell crash a few times, downgrade back to
1.50.2-2 so you can get back into a working GUI, and report what was
logged about the crashes?

Also, if you use 1.50.2-3, do you get the same crashing behaviour as
with 1.50.3-1?

If gjs is hitting an "unrecoverable exception" I would expect to see
something like this in the Journal, similar to #888052:

Jan 23 12:34:56 yourmachine gnome-session[1234]: gnome-session-binary[1234]:
WARNING: App 'org.gnome.Shell.desktop' exited with code 1

and if gnome-shell is crashing, I'd expect to see that logged too.

It seems odd that this version is working fine for me (and presumably
for upstream GNOME maintainers) but crashing so repeatably for you. Are
you using any gnome-shell extensions or other special configuration?

Am I right in thinking that the gdm "greeter" (the login screen), which
is actually just GNOME Shell in a special mode, is working correctly for
you, and it's only the copy of GNOME Shell that runs *after* you log in
that is crashing? If so, that's useful information.

https://gitlab.gnome.org/GNOME/gjs/issues/38 might be related: it's
reported to be a regression caused by the same changes that arrived in
1.50.2-3 (and upstream in 1.50.3).

Thanks,
smcv

Bug#835394: [pkg-gnupg-maint] Bug#835394: Same issue here

[Daniel Kahn Gillmor]

On Thu 2018-01-25 22:53:18 +0100, Thomas Goirand wrote:
> so really, it looks like systemd is the badly configured thing here.

I don't see how systemd is "badly configured" -- the user service starts
up gpg-agent the first time it's needed.

gpg-agent itself invokes pinentry in order to talk to the user, so
pinentry needs to know some sort of environment information.

if you use pinentry-gnome3 (which is the preferred graphical pinentry)
it just needs to know the $DBUS_SESSION_BUS_ADDRESS, which should be
already available because the bus is already available at the time the
service is launched.  This will work whether you're running Wayland or
X11.

if you use pinentry-gtk2 or pinentry-qt within an X11 session, then
gpg-agent needs to know $DISPLAY and $XAUTHORITY so it can launch
pinentry.  These variables should be set into the systemd user service
activation environment when you log into a graphical session.  (i expect
"dbus-update-activation-environment --systemd DISPLAY XAUTHORITY" to be
invoked by however you start your X session -- if it's not happening,
that'd be good to know)

so as long as you don't try to use gpg-agent (either as ssh-agent or as
gpg-agent, or by explicitly "systemctl --user start gpg-agent.service")
before you've logged into your graphical user session, when gpg-agent is
launched, it will already know how to prompt you for a password for ssh,
and you shouldn't need to manually run workarounds like:

   gpg-connect-agent updatestartuptty /bye

If you can tell me how you start up your graphical session, maybe we can
track down the problem further.

Regards,

  --dkg


signature.asc
Description: PGP signature

Bug#888465: CPU usage reporting issues

[Hans van Kranenburg]

Hi Ryan,

On 01/26/2018 12:20 AM, Ryan Thoryk wrote:
> Package: linux-image-4.9.0-5-amd64
> Version: 4.9.65-3+deb9u2
> Severity: normal
> 
> I'm having an issue with CPU usage reporting, tested on kernels 4.9.0-3
> and 4.9.0-5.  The machines are running on Amazon EC2, which could be
> related.  With the "sar" utility, after some time, the system's "steal"
> value periodically is 100%,

This means that your vcpus want to execute work but are not being
scheduled on a physical cpu core. Either the physical machine gets too
much work from all the virtual machines that are requesting cpu time, or
other things are going on, like your virtual machine getting paused
(e.g. when doing live migration there's a handover moment when it's
shortly paused and then resumed, this is also visible as a short 100%
steal spike).

> and the normal CPU user/system values,
> including idle, are always 0.  When running a cpu-intensive app and
> using the "top" utility, the user and system values are always 0, the
> "idle" field stays at 100%, and only the "wait" field increases.

Sounds a lot like this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871608

A patch to fix that cpu accounting breakage (picked from linux 4.15) was
included in 4.9.65-3. So only for the 4.9.0-3 (which actual version?)
you could be seeing that one happening.

> The attached file shows the "sar" output around the time the issue
> started.  This has happened on 2 separate machines (started at different
> times on each), and a reboot appears to (temporarily) fix the issue. 
> I'm wondering if anyone else has this issue, and if it could be
> something to do with the hypervisor.

Because of the mentioned steal time fix that was included in a version
in between the 2 versions you mention, my first suggestion would be to
see if the symptoms on the old and new kernel are exactly the same, or
if they are only similar but different.

Hans

Bug#887863: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

Hi!

On Sun, 2018-01-21 at 17:13:38 +0200, Niko Tyni wrote:
> On Sun, Jan 21, 2018 at 05:32:01AM +0100, Guillem Jover wrote:
> > On Sun, 2018-01-21 at 02:59:53 +0100, Andreas Beckmann wrote:
> > > Even if python is going to get fixed, this probably won't help
> > > libglib2.0-dev (which drops the python dependency in buster), therefore
> > > it will need to add the dummy empty prerm to mitigate this issue.
> > 
> > I don't see why this would be needed. If python gets fixed to use
> > Pre-Depends, then it does not matter whether libglib2.0-dev stops
> > depending on it, as python should then be always usable even when
> > just unpacked.
> 
> stretch# apt --no-install-recommends install glib2.0-dev
> [...]
> stretch# dpkg --unpack libexpat1_2.2.5-3_amd64.deb # from sid
> [...]
> stretch# dpkg --unpack libglib2.0-dev_2.54.3-1_amd64.deb # from sid
> /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> found (required by /lib/x86_64-linux-gnu/libexpat.so.1)
> dpkg: warning: subprocess old pre-removal script returned error exit status 1
> dpkg: trying script from the new package instead ...
> dpkg: error processing archive libglib2.0-dev_2.54.3-1_amd64.deb (--unpack):
>  there is no script in the new version of the package - giving up
> /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> found (required by /lib/x86_64-linux-gnu/libexpat.so.1)
> dpkg: error while cleaning up:
>  subprocess installed post-installation script returned error exit status 1
> 
> No python3 change in sid/buster is going to prevent this afaics?

Ah sorry, you are exactly right. Good think this is even worked around
now in unstable anyway. :)

Thanks,
Guillem

Bug#888465: Additional example

[Ryan Thoryk]

Here's an additional example, showing the "vmstat" command output while 
running a cpu-intensive program.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

ryan@elaina:~$ vmstat 2
procs ---memory-- ---swap-- -io -system-- --cpu-
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
 1  0 1213872 544528  0 123229200 7 300  0  0  4  0 
96
 1  0 1213872 544188  0 123228800 2 3  393  264  0  0  0  0 
 0
 1  0 1213872 544176  0 123229200 2 2  395  238  0  0  0  0 
 0
 1  0 1213872 544368  0 123229200 0 0  511  365  0  0  0  0 
 0
 1  0 1213872 544568  0 123229200 084  388  234  0  0  0  0 
100
 1  0 1213872 544284  0 123230000 6 0  541  426  0  0  0  0 
 0
 1  0 1213872 544132  0 123230400 0 0  433  337  0  0  0  0 
 0
 1  0 1213872 544140  0 123229200 0 2  356  193  0  0  0  0 
 0
 1  0 1213872 544040  0 123231200 820  455  410  0  0  0  0 
 0
 1  0 1213872 543916  0 123231600 0   230  386  260  0  0  0  0 
 0
 1  0 1213872 544288  0 123231600 0 0  354  226  0  0  0  0 
 0
 1  0 1213872 545684  0 123231600 073  385  272  0  0  0  0 
 0
 1  0 1213872 545808  0 123231600 010  589  473  0  0  0  0 
 0
 1  0 1213864 545652  0 123232040 4   126  763  656  0  0  0  0 
 0
 1  0 1213864 545528  0 123232000 0   232  417  267  0  0  0  0 
 0

Bug#888234: dpkg: packages not fully upgraded, but dpkg doesn't notice

[Guillem Jover]

Control: severity -1 important

[ The severity might deserve to be even lower though, depending on the
  analysis of the bug. ]

Hi!

On Wed, 2018-01-24 at 06:05:14 +0100, Christoph Anton Mitterer wrote:
> Package: dpkg
> Version: 1.19.0.5
> Severity: serious

> Not sure if the following is expected to happen, but I think
> dpkg doesn't notice when some packages aren't actually fully upgraded.

Are you sure they are not fully upgraded? What makes you think so?
Just the dpkg.log below?

> Here's the situation:
> Since a while I see sporadic freezes of my system (quite often actually
> while I do upgrades via aptitude and dpkg runs through the packages).
> 
> Until know I thought it would be my new notebook, but I just went back to
> my old one (swapped the SSD) and there it hapened as well, so it must be
> something else in Debian (kernel, GPU drivers whatever).

Intel microcode?

> Once it's frozen, only power off helps (no magic sysrq), after reboot, when
> I check the logs, then apt's termlog, doesn't show the end message, and
> it seems also that dpkg's log shows that packages haven't completely installed
> /configured, etc.
> (see attached log)

That might well be because the log file is not fsync()ed to disk, so
the operations might hae finished but the log not been written.

> And I noticed that my locales where broken, because of the recent new libc
> packages in sid... and "locales" wasn't configured.
> 
> 
> Normally dpkg -C would show this then, but it doesn't.
> Neither does dpkg --configure -a do anything.

And there are no packages in the status file with Status less than
installed. And no lingering files under «/var/lib/dpkg/updates»?

> This happened alrready quite some times now, an probably my system has
> many packages in a state not fully installed, while dpkg thinks everything
> would be fine.

dpkg is very careful about how it handles its database. If it think
they are installed, and there are no update journal entries on the
above directory. Then this might indicate something more severe like
a very broken filesystem on-disk or implementation or hardware failure
or similar.

> Interestingly: debsums -asc doesn't find problems.

That to me would indicate that the packages are either the old
versions or the new ones, but thay match.

> I have no idea how to debug this any further... please tell me if you need
> anything.

> btw: this is on btrfs

That alone seems very suspect IMO.

Thanks,
Guillem

Bug#888469: aptitude: build-dep gmime fails

[=]

Package: aptitude
Version: 0.8.7-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I wanted to build gmime from source

I tried (on the shell command-line):

aptitude build-dep gmime

and got an error message:

Unable to satisfy the build-depends: Build-Depends: libgpgme11-dev
Unable to apply some actions, aborting

I then tried

apt-get build-dep gmime

it completed successfully

"aptitude build-dep gmime" still gives the same error message.



-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.7
Compiler: g++ 6.3.0 20170406
Compiled against:
  apt version 5.0.1
  NCurses version 6.0
  libsigc++ version: 2.10.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20161126
  cwidget version: 0.5.17
  Apt version: 5.0.1

aptitude linkage:
linux-vdso.so.1 (0x7ffce23f2000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f5defdbd000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f5defb8d000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f5def963000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f5def75c000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f5def45f000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f5def157000)
libboost_iostreams.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7f5deef3f000)
libboost_filesystem.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7f5deed26000)
libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f5deeb22000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f5dee70e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f5dee4f1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f5dee16f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5dede6b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f5dedc54000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5ded8b5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5ded6b1000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f5ded49a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f5ded28)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f5ded07)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f5dece4a000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f5decc38000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f5deca3)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f5dec82b000)
/lib64/ld-linux-x86-64.so.2 (0x7f5df0786000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.8.7-1
ii  libapt-pkg5.0  1.4.8
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-iostreams1.62.0   1.62.0+dfsg-4
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libc6  2.24-11+deb9u1
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.3.0-18
ii  libncursesw5   6.0+20161126-1+deb9u1
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libsqlite3-0   3.16.2-5
ii  libstdc++6 6.3.0-18
ii  libtinfo5  6.0+20161126-1+deb9u1
ii  libxapian301.4.3-2

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-12
ii  sensible-utils 0.0.9+deb9u1

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 3.39

-- debconf-show failed

Bug#888234: dpkg: Upgrades freeze laptop

[Guillem Jover]

On Wed, 2018-01-24 at 09:32:13 +0100, Julien Patriarca wrote:
> Package: dpkg
> Version: 1.19.0.5
> Followup-For: Bug #888234

> I meet this bug 1 in 2 upgrades on my laptop. Apt is downloading the
> packages, then dpkg kicks in to install them, and the laptop is
> completely frozen. I have to power-cycle it.

I don't think this bug has much to do with the reported one TBH.

> Once back into the system, I have to run dpkg --configure -a and apt
> install --fix-broken.
> Each time I get this message from apt : the package 
> needs to be reinstalled, but i can't find an archive for it.

This means apt and dpkg are aware something is broken, which
apparently does not happen with the reported bug.

> I have to rm -rf /var/lib/apt/lists, then run the apt install
> --fix-broken and finally upgrade if necessary.

Removing the lists should not be needed? Perhaps you just need to
run «apt update» because the archive does not contain the packages
listed in your local metadata.

> Please tell me if you wish me to provide some more details, logs or
> whatever to investigate this.

I'm not sure whether this is really a bug at all, if it is it might
be in apt though.

Thanks,
Guillem

Bug#888448: ftp.debian.org,dpkg: dpkg-source and dak disagree on tarball signatures for format 1.0 source packages

[Guillem Jover]

Control: reassign -1 ftp.debian.org

On Thu, 2018-01-25 at 19:57:09 +0100, Julien Cristau wrote:
> Package: ftp.debian.org, dpkg
> Severity: important

> In the past, dpkg-source -x would refuse to unpack a source package with
> format 1.0 referencing such a file.
> 
> As a result, dak would reject such uploads that couldn't be unpacked
> (https://anonscm.debian.org/git/mirror/dak.git/commit/?id=fe8fc1bfe57b90)
> 
> As of dpkg 1.19.0, dpkg-source -b now includes upstream tar signatures
> when building source packages with format 1.0, thus creating source
> packages that get rejected on upload.

Yes.

> That seems like a bad situation to be in.  Can we please revert either
> the recent dpkg-source -b change or the older dak change?

This should be allowed in dak, I guess I just forgot to notify
ftp-masters, or had forgotten there was this restriction in place.

The timeline for upstream tarball signatures support in dpkg is:

  - extracting implemented for source >= 2.x in 1.17.20
  - extracting implemented for source == 1.x in 1.18.5
  - building implemented for source >= 1.x in 1.18.5
  - building disabled for source == 1.x in 1.18.8
(due to stable not supporting its extraction)
  - building reenabled for source == 1.x in 1.19.0

Thanks,
Guillem

Bug#888456: lintian: FTBFS: apparently-corrupted-elf-binary check not being emitted

[Chris Lamb]

tags 888456 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=2e2d23f6d60e3f8d82f9799527e44df042c0762b


Regards,

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

Bug#733750: support patching hexen2 game data

[Simon McVittie]

Control: tags -1 = pending

On Thu, 25 Jan 2018 at 14:56:19 +0100, Alexandre Detiste wrote:
> This also confuses GDP which ends up thinking data1/pak*.pak?v1.11 are 
> downloadable.
> It then dowloads gamedata-all-1.29a.tgz for nothing.

Thanks, fixed in git. The code was correctly taking into account the
other_parts of a multi-part archive that is present, but not doing the
same for one that is merely downloadable (and deltas are treated like
the first part of a multi-part archive).

smcv

Bug#888468: pandoc: please support new YAML fields "front/back-notice" for LaTeX and HTML5 output

[Francesco Poli (wintermute)]

Package: pandoc
Version: 1.19.2.4~dfsg-1+b1
Severity: wishlist
Tags: patch

Hello Debian Haskell Group!
Thanks a lot for maintaining this really nice markup converter in
Debian! The package is very useful and having it in Debian is greatly
appreciated.

While using it, I found that YAML metadata fields are useful for
keeping some metadata about a markdown document in a compact
block between a pair of "---" lines.

So far so good.

But, after reading the documentation, I seem to understand that
(at least for the LaTeX, and hence PDF, output and for the HTML5
output) there is no YAML field suitable for inserting a notice
(with customizable style) at the beginning (between title and TOC)
or at the end of a document.
This notice may possibly be useful to state the copyright and license
terms for the document; it may also be used to state other pieces of
information that should be displayed in a special area at the beginning
or at the end of the document.

Well, I found out that adding support for this feature is really
easy: one just needs to modify the templates used for LaTeX and HTML5
outputs.

I prepared a patch for these two templates, supporting two new
YAML fields named "front-notice" and "back-notice".

Since I think this feature may be useful for other users, I would
like to see my patch applied to the official default templates.

The patch is attached to this bug report: as you can see, it's almost
trivial. Maybe it's so trivial that it is not even copyrighted.
At any rate, in case it should turn out to be copyrighted by me,
I hereby release it under the same terms as pandoc (that is to say,
under the terms of the GNU GPL, version 2 or later).

Please apply my patch to the Debian package and forward my wishlist
bug report upstream.

Thanks for your time and dedication!
Bye.


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

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

Versions of packages pandoc depends on:
ii  libc62.26-4
ii  libffi6  3.2.1-8
ii  libgmp10 2:6.1.2+dfsg-1.2
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.1
ii  libpcre3 2:8.39-8
ii  libyaml-0-2  0.1.7-2
ii  pandoc-data  1.19.2.4~dfsg-1
ii  zlib1g   1:1.2.8.dfsg-5

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  context
ii  pandoc-citeproc0.10.5.1-1+b1
ii  texlive-latex-extra2017.20180110-1
ii  texlive-latex-recommended  2017.20180110-1
pn  texlive-luatex 
ii  texlive-xetex  2017.20180110-1
pn  wkhtmltopdf

-- no debconf information


add-notice-to-templates.diff.gz
Description: application/gzip

Bug#878945: Request from cloud team: please add a debconf option for PasswordAuthentication

[Colin Watson]

On Mon, Nov 27, 2017 at 09:26:33PM -0500, Jimmy Kaplowitz wrote:
> On Wed, Oct 18, 2017 at 08:17:49AM +0100, Colin Watson wrote:
> > On Tue, Oct 17, 2017 at 02:50:24PM -0700, Jimmy Kaplowitz wrote:
> > > Hello from the Debian cloud team sprint at Microsoft! We were just
> > > discussing the appropriate default value for the PasswordAuthentication
> > > option in sshd_config in Debian's cloud images. Most of these currently
> > > set it to 'no' by modifying the config file; we'd like a debconf option
> > > for this to be added, so that we make the change that way and offer a 
> > > better
> > > user experience across package upgrades.
> > 
> > Thanks for the suggestion.  Does this patch look OK?  It seems to do the
> > job in my local testing.
> 
> Your reply was impressively fast, and mine was depressingly slow! I
> apologize for the latter. We reviewed it during the sprint and marveled
> at your quick response time, but I failed to send a follow-up email.
> 
> The patch looks great. The description would make more sense to me
> without the "(for internal use)" caveat, but I'm not going to bikeshed
> over such a detail.

That's just the magic string Lintian checks for to decide whether it
should complain about an untranslatable template.  I guess it's a bit
ugly here; I'll work out the necessary overrides instead.

> I note when reviewing our build scripts that we also add a
> ClientAliveInterval line (not using sed), as befits a cloud environment
> where a network-level firewall will drop connections after extended
> periods of inactivity. Would you like me to file a separate wishlist bug
> for a debconf option for that value, or do you think it should stay a
> manual modification?

Hmm.  Of course you can file a bug about anything you like, and I do see
that you only really get the full benefit of this if you can make all
the changes you need to make without sed.  However, while needing to
change PasswordAuthentication is pretty common, I'm starting to get a
bit worried about having to basically reflect all of sshd_config into
debconf.  Is there any particular reason to believe that the changes
you've needed to make so far form a closed set?

I'm hoping that eventually
https://bugzilla.mindrot.org/show_bug.cgi?id=2468 will happen so that
this is less of a problem ...

Thanks,

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

Bug#888466: ITP: django-ipware -- Django app to retrieve client's IP address

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 

* Package name: django-ipware
  Version : 2.0.1
  Upstream Author : Val Neekman 
* URL : https://github.com/un33k/django-ipware
* License : MIT
  Programming Lang: Python
  Description : Django app to retrieve client's IP address

django-ipware can be used in a view or a middleware where the
`request` object is available. It will attempt to get the client's IP
address, and determine if that IP address is publicly routable on the
Internet.

This is a dependency for new versions of django-axes. I plan to
maintain it within Debian Python Modules Team.

Bug#888467: afl: ASAN error suggests nonexistant documentation

[D Haley]

Package: afl
Version: 2.36b-1
Severity: minor

Dear Maintainer,

When running afl, the following error is generated on a binary compiled with 
UBSAN (ASAN) support.

[-] Whoops, the target binary crashed suddenly, before receiving any input
from the fuzzer! Since it seems to be built with ASAN and you have a
restrictive memory limit configured, this is expected; please read
/usr/share/doc/afl/notes_for_asan.txt for help.

However this file does not exist. Expected result is that documentation 
suggested by program should exist.

Contents of doc dir:
$ ls /usr/share/doc/afl/*
/usr/share/doc/afl/buildinfo_amd64.gz
/usr/share/doc/afl/changelog.Debian.gz
/usr/share/doc/afl/changelog.gz
/usr/share/doc/afl/copyright
/usr/share/doc/afl/NEWS.Debian.gz
/usr/share/doc/afl/README

I belive this file is actually in /usr/share/doc/afl-doc/docs/ as part of the 
afl-doc package (in sid, 2.52b-1).

Thanks!


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages afl depends on:
ii  build-essential  12.3
ii  libc62.24-11+deb9u1

Versions of packages afl recommends:
ii  afl-clang  2.36b-1
ii  afl-doc2.36b-1

Versions of packages afl suggests:
pn  gnuplot  

-- no debconf information

Bug#888464: mupdf: CVE-2018-6187: heap-based buffer overflow in pdf/pdf-write.c:do_pdf_save_document()

[Salvatore Bonaccorso]

Source: mupdf
Version: 1.11+ds1-2
Severity: important
Tags: security upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=698908

Hi,

the following vulnerability was published for mupdf.

CVE-2018-6187[0]:
| In Artifex MuPDF 1.12.0, there is a heap-based buffer overflow
| vulnerability in the do_pdf_save_document function in the
| pdf/pdf-write.c file. Remote attackers could leverage the vulnerability
| to cause a denial of service via a crafted pdf file.

Reproducible with an ASAN build 

mutool poster ~/CVE-2018-6187.poc

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-6187
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6187
[1] https://bugs.ghostscript.com/show_bug.cgi?id=698908

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore


CVE-2018-6187.poc
Description: Adobe PDF document

Bug#888465: CPU usage reporting issues

[Ryan Thoryk]

Package: linux-image-4.9.0-5-amd64
Version: 4.9.65-3+deb9u2
Severity: normal

Hi,

I'm having an issue with CPU usage reporting, tested on kernels 4.9.0-3 
and 4.9.0-5.  The machines are running on Amazon EC2, which could be 
related.  With the "sar" utility, after some time, the system's "steal" 
value periodically is 100%, and the normal CPU user/system values, 
including idle, are always 0.  When running a cpu-intensive app and 
using the "top" utility, the user and system values are always 0, the 
"idle" field stays at 100%, and only the "wait" field increases.


The attached file shows the "sar" output around the time the issue 
started.  This has happened on 2 separate machines (started at different 
times on each), and a reboot appears to (temporarily) fix the issue.  
I'm wondering if anyone else has this issue, and if it could be 
something to do with the hypervisor.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

11:05:01 AM all  0.01  0.00  0.02  0.00  0.00 99.97
11:15:01 AM all  0.01  0.00  0.02  0.00  0.00 99.97
11:25:01 AM all  0.01  0.00  0.02  0.00  0.00 99.97
11:35:01 AM all  0.01  0.00  0.02  0.00  0.00 99.97
11:45:01 AM all  0.01  0.00  0.02  0.00  0.00 99.97
11:55:01 AM all  0.01  0.00  0.02  0.00  0.00 99.97
12:05:01 PM all  0.01  0.00  0.01  0.00  0.00 99.97
12:15:01 PM all  0.01  0.00  0.01  0.00  0.00 99.97
12:25:01 PM all  0.01  0.00  0.02  0.00  0.00 99.97

12:25:01 PM CPU %user %nice   %system   %iowait%steal %idle
12:35:01 PM all  0.01  0.00  0.02  0.00  0.00 99.97
12:45:01 PM all  0.01  0.00  0.02  0.00  0.00 99.97
12:55:01 PM all  0.02  0.00  0.02  0.00  0.00 99.96
01:05:01 PM all  0.01  0.00  0.02  0.00  0.00 99.97
01:15:01 PM all  0.00  0.00  0.00  0.00100.00  0.00
01:25:01 PM all  0.00  0.00  0.00  0.00  0.00  0.00
01:35:01 PM all  0.00  0.00  0.00  0.00  0.00  0.00
01:45:01 PM all  0.00  0.00  0.00  0.00100.00  0.00
01:55:01 PM all  0.00  0.00  0.00  0.00  0.00  0.00
02:05:01 PM all  0.00  0.00  0.00  0.00  0.00  0.00
02:15:01 PM all  0.00  0.00  0.00  0.00100.00  0.00
02:25:01 PM all  0.00  0.00  0.00  0.00  0.00  0.00
02:35:01 PM all  0.00  0.00  0.00  0.00  0.00  0.00
02:45:01 PM all  0.00  0.00  0.00  0.00100.00  0.00
02:55:01 PM all  0.00  0.00  0.00  0.00  0.00  0.00

Bug#888462: Bugs

[Ginés Priede Rivero]

If I activate the airplane mode and deactivate it with the fn keys. The upper 
menu looks correct, vpn also correct.

Bug#865931: mysql-server: Does not allow me to change root password

[Leon Klingele]

Package: mariadb-server-10.1
Version: 1:10.1.29-6
Followup-For: Bug #865931

Dear Maintainer,

I stumbled across the exact same issue: `mysql_secure_installation` was
asking for a new password which — when specified — wasn't set. `mysql -u root`
would still not ask for a password, rendering the password prompt inside
`mysql_secure_installation` useless.

Steps to reproduce:

Create new testing environment:
$ lxc launch images:debian/stretch test-865931-mysql
$ lxc exec test-865931-mysql -- bash

Reproduce issue:
$ # Add 'testing' repo to your sources.list file
$ apt update
$ apt install --no-install-recommends -y mariadb-server
$ mysql_secure_installation # Make sure to specify a password when asked for
$ mysql -u root # Opens the mysql root prompt without asking for the password

I was able to set a root password as follows.

$ mysql -u root
MariaDB [(none)]> use mysql;
MariaDB [mysql]> update user set authentication_string=password('toor'), 
plugin='mysql_native_password' where user='root';
MariaDB [mysql]> flush privileges;


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

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

Versions of packages mariadb-server-10.1 depends on:
ii  adduser   3.115
ii  debconf [debconf-2.0] 1.5.61
ii  galera-3  25.3.22-1
ii  gawk  1:4.1.4+dfsg-1
ii  iproute2  4.9.0-1+deb9u1
ii  libaio1   0.3.110-5
ii  libc6 2.26-2
ii  libdbi-perl   1.639-1
ii  libpam0g  1.1.8-3.6
ii  libstdc++66.3.0-18
ii  libsystemd0   232-25+deb9u1
ii  lsb-base  9.20161125
ii  lsof  4.89+dfsg-0.1
ii  mariadb-client-10.1   1:10.1.29-6
ii  mariadb-common1:10.1.29-6
ii  mariadb-server-core-10.1  1:10.1.29-6
ii  passwd1:4.4-4.1
ii  perl  5.26.1-4
ii  psmisc23.1-1
ii  rsync 3.1.2-2.1
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mariadb-server-10.1 recommends:
pn  libhtml-template-perl  

Versions of packages mariadb-server-10.1 suggests:
pn  mailx   
pn  netcat-openbsd  
pn  tinyca  

-- debconf information excluded
---




signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#886352: tar: garbage instead of owner set in TAR_OPTIONS

[Jakub Wilk]

Control: forwarded -1 
https://lists.gnu.org/archive/html/bug-tar/2016-09/msg5.html
Tags: -1 + fixed-upstream

http://git.savannah.gnu.org/cgit/tar.git/commit/?id=c2886473a803 (which 
is included in tar 1.30) fixes it for me.


--
Jakub Wilk

Bug#888463: bind9utils: missing python3-ply dependency for python scripts

[Andreas Hasenack]

Package: bind9utils
Version: 1:9.11.2.P1-1
Severity: normal

Dear Maintainer,

The bind9utils package is missing a runtime dependency on python3-ply. For
some reason, it wasn't included automatically during the package build
process.

root@sid-bind9-ply3-depends:~# dpkg -s bind9utils|grep ^Depends|grep
python3-ply
root@sid-bind9-ply3-depends:~#

If you install bind9utils without python3-ply, the scripts will fail like
this:
root@sid-bind9-ply3-depends:~# dnssec-checkds
Traceback (most recent call last):
  File "/usr/sbin/dnssec-checkds", line 18, in 
import isc.checkds
  File "/usr/lib/python3/dist-packages/isc/__init__.py", line 17, in

from isc.keyseries import *
  File "/usr/lib/python3/dist-packages/isc/keyseries.py", line 13, in

from .policy import *
  File "/usr/lib/python3/dist-packages/isc/policy.py", line 10, in 
import ply.lex as lex
ModuleNotFoundError: No module named 'ply'

The three scripts are:
/usr/sbin/dnssec-checkds
/usr/sbin/dnssec-coverage
/usr/sbin/dnssec-keymgr


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

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

Versions of packages bind9utils depends on:
ii  libbind9-160  1:9.11.2.P1-1
ii  libc6 2.26-5
ii  libcap2   1:2.25-1.2
ii  libcomerr21.43.8-2
ii  libdns169 1:9.11.2.P1-1
ii  libgeoip1 1.6.12-1
ii  libgssapi-krb5-2  1.16-2
ii  libisc166 1:9.11.2.P1-1
ii  libisccc160   1:9.11.2.P1-1
ii  libisccfg160  1:9.11.2.P1-1
ii  libjson-c30.12.1-1.3
ii  libk5crypto3  1.16-2
ii  libkrb5-3 1.16-2
ii  liblmdb0  0.9.21-1
ii  libssl1.1 1.1.0g-2
ii  libxml2   2.9.4+dfsg1-6.1
ii  python3   3.6.4-1

bind9utils recommends no packages.

bind9utils suggests no packages.

-- no debconf information

Bug#888462: gnome-menus: nm-applet on top vpn missing

[Gines Priede]

Package: gnome-menus
Version: 3.13.3-11
Severity: normal

Dear Maintainer,

The vpn menu on the top is missing appear but its blank. If I click if it
appears vpn configuration


I have other bug open i dont know if this affects-.

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



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

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

Versions of packages gnome-menus depends on:
ii  python3  3.6.4-1

gnome-menus recommends no packages.

gnome-menus suggests no packages.

-- no debconf information

Bug#888460: libxss: bad git URL in package description

[Jakub Wilk]

Source: libxss
Version: 1:1.2.2-2
Tags: patch

$ apt-cache show libxss1 | grep git:// | xargs git ls-remote
fatal: repository 'https://anongit.freedesktop.org/git/xorg/lib/libScrnSaver/' 
not found

--
Jakub Wilk
From bb62d415b80f8eeeae5c1163ab2801dfba475c97 Mon Sep 17 00:00:00 2001
From: Jakub Wilk 
Date: Thu, 25 Jan 2018 23:50:19 +0100
Subject: [PATCH] Fix git URL in package description

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 652cc84..f82af43 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,7 @@ Description: X11 Screen Saver extension library
  
  .
  This module can be found at
- git://anongit.freedesktop.org/git/xorg/lib/libScrnSaver
+ git://anongit.freedesktop.org/git/xorg/lib/libXScrnSaver
 
 Package: libxss-dev
 Section: libdevel
@@ -65,4 +65,4 @@ Description: X11 Screen Saver extension library (development headers)
  
  .
  This module can be found at
- git://anongit.freedesktop.org/git/xorg/lib/libScrnSaver
+ git://anongit.freedesktop.org/git/xorg/lib/libXScrnSaver
-- 
2.15.1

Bug#888422: libmpfr6 should add Breaks: libmpfr4

[Vincent Lefevre]

On 2018-01-25 20:32:45 +0200, Adrian Bunk wrote:
> On Thu, Jan 25, 2018 at 02:15:15PM +0100, Vincent Lefevre wrote:
> > On 2018-01-25 14:11:49 +0200, Adrian Bunk wrote:
> > > Mixing libmpfr4 and libmpfr6 doesn't work well:
> > 
> > Wasn't symbol versioning supposed to solve this issue?
> 
> Yes, versioning all symbols could solve this problem
> (assuming libraries like libmpc3 don't expose mpfr internals).

Note that MPFR internals (among what could be exposed, I think) have
not changed, so that I don't think this would even be a problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#888459: flint-arb's tests fail on 32bit archs using mpfr 4.0.0

[Matthias Klose]

Package: src:flint-arb
Version: 2.11.1-2
Severity: serious
Tags: sid buster

as seen on
https://release.debian.org/transitions/html/auto-mpfr4.html
https://buildd.debian.org/status/package.php?p=flint-arb

the testsuite fails on all 32bit architectures.

cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -I/<>
-I/usr/local/include -I/usr/local/include -I/usr/include test/t-sqrt.c -o
../build/arf/test/t-sqrt -L/<> -L/usr/local/lib -L/usr/local/lib
-L/usr/lib -lflint-arb -lflint -lmpfr -lgmp -lm -lpthread  -MMD -MP -MF
../build/arf/test/t-sqrt.d -MT "../build/arf/test/t-sqrt" -MT
"../build/arf/test/t-sqrt.d"
flooraddmul_uiPASS
cmpabs_2exp_siPASS
addset_round_uirootPASS
add_siPASS
mulPASS
set_fmpqPASS
submul_uiPASS
mul_siPASS
abs_bound_lt_2exp_siPASS
sub_siPASS
get_dPASS
addmul_fmpzPASS
add_uiPASS
frexpPASS
rsqrtPASS
subPASS
cmpabsPASS
set_fmprPASS
set_round_fmpzPASS
mul_uiPASS
abs_bound_lt_2exp_fmpzPASS
sub_uiPASS
set_fmpz_2expPASS
complex_sqrPASS
complex_mulPASS
abs_bound_le_2exp_fmpzPASS
submul_fmpzPASS
divFAIL (aliasing 4)!
prec = 352, rnd = 4

x =
(4586997233048136541430758450064474100387735230759824291973833691816938709832156080645343570059119116156929
* 2^-154742412678922490659733883)

y =
(51814976846671518298238808760042830604686502339620382299366747655022166929406808804341858227567903870767891933265103849315791036770763130077955430384829058539908460614800988509303528381975119100503701824233100229972596599113543202092890645352456600459286399836135725531911334505568114757105479020098464557517116791851426250751
* 2^-154742431125385089392575577)

v =
(2135987036418233318920600437589210504846524088997312026086185915310372929010612927677735486095361
* 2^-154742412678922490659733852)

r1 = 1, r2 = 1
../Makefile.subdirs:84: recipe for target '../build/arf/test/t-div_RUN' failed
make[3]: *** [../build/arf/test/t-div_RUN] Aborted
make[3]: *** Waiting for unfinished jobs
PASS
PASS
PASS
make[3]: Leaving directory '/<>/arf'
Makefile:179: recipe for target 'check' failed
make[2]: *** [check] Error 2
make[2]: Leaving directory '/<>'

Bug#888402: diffoscope: Also report differences in file metadata when comparing individual files

[Chris Lamb]

tags 888402 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=59eb4bfd298f3fdb6f4f0d84780b53eb67703f52


Regards,

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

Bug#888458: python-networkx: packages out of date, haven't been updated for 18 months

[Jameson Graef Rollins]

Package: python-networkx
Version: 1.11-2
Severity: normal

The python-networkx packages were last updated in August 2016, which
was 18 months ago.  There has been a major upstream releases since
then (current stable upstream is 2.1).  The missing major release
update is causing compatibility problems with other platforms.

Has this package been orphaned?  Please advise.

Thanks for the help.

jamie.


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

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

Versions of packages python-networkx depends on:
ii  python2.7.14-4
ii  python-decorator  4.1.2-1

Versions of packages python-networkx recommends:
ii  python-matplotlib 2.0.0+dfsg1-2+b1
ii  python-numpy  1:1.13.3-2
ii  python-pkg-resources  38.2.4-2
ii  python-pydot  1.2.3-1
ii  python-pygraphviz 1.4~rc1-1+b1
ii  python-scipy  0.19.1-2
ii  python-yaml   3.12-1+b1

Versions of packages python-networkx suggests:
ii  python-networkx-doc  1.11-2

-- no debconf information

Bug#883338: congress: [INTL:ru] Russian translation of debconf template

[David Rabel]

Thanks Lev.

I adjusted the boilerplate and pushed it to the repo.

Yours
  David



signature.asc
Description: OpenPGP digital signature

Bug#888246: RFS: ddccontrol/0.4.3-1

[Antoine Beaupre]

I have found some minor issues in the package that I think should be
fixed.

 1. the lintian-override is not necessary. binary-without-manpage is
just a warning, not an error, and we can live with it until the
binary moves to the right place. in fact, it provides a good
reminder that this still needs to be done, so do not override it.

 2. in gbp.conf, "upstream-tree = 0.4.3" is out of place. it shouldn't
be necessary because "upstream-tag = %(version)s" should work.

Other comments, which are not blockers for an upload - but if you're
going to reroll the package anyways, might as well consider fixing this:

 3. could you clarify why the override_dh_autoreconf target is
necessary? isn't autoreconf exactly designed for the purpose of
running autogen.sh?

 4. it is quite strange to see a 10k line diff for a patch release
(0.4.2 -> 0.4.3). I would encourage you to release a new *major*
version (e.g. 0.5.0 or 1.0.0) next time you make such significant
changes. not sure you can fix this now that the tag is public on
github, so maybe just a note for next time...

 5. as lintian noticed, debian/copyright now has a formal syntax,
specified by DEP5. no big deal, but you could do a refresh on that
file. decopy is a tool that does this well.

Once issues 1 and 2 are fixed, I'm happy to upload the package.

Cheers,

A.


signature.asc
Description: PGP signature

Bug#888305: afalg engine is disabled, please reenable it

[Sebastian Andrzej Siewior]

Control: forwarded -1 https://github.com/openssl/openssl/pull/5169

Sebastian

Bug#888457: getmail: please supply a systemd user service file

[Daniel Kahn Gillmor]

Package: getmail
Version: 5.5-2
Severity: wishlist

Charles Cazabon (getmail upstream) says [0]:

>   If your OS ships and uses, say, systemd, then perhaps you should
>   ask your OS vendor to provide a way to run getmail in their getmail
>   package, if you feel it's that important and don't feel up to
>   configuring it yourself.

consider this a feature request, then, since debian is the one doing
system integration.

I'm imagining a getmail user service template, shipped somewhere like
/usr/lib/systemd/user/getmail@.socket

so the user could do something like:

   systemctl --user enable getmail@example.service

and that would start a backgrounded idling IMAP connection that reads
its config from ~/.getmail/config/example

I'm not sure exactly how we'd choose which folder to idle on -- maybe
the template should be instantiated as getmail@example-INBOX.service
instead?

anyway, just wanted to record this wishlist request.  thanks for
maintaining getmail in debian!

--dkg

[0] id:20180125194345.7ihk7gzshzm7e...@pyropus.ca

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

Kernel: Linux 4.14.0-3-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 getmail depends on:
ii  python  2.7.14-4

getmail recommends no packages.

getmail suggests no packages.

-- no debconf information

Bug#835394: Same issue here

[Thomas Goirand]

Hi,

$work imposed using a yubikey on me for ssh auth. After a long painful
search on how to disable the gnome-keyring on mate, I finally had the
same issue as Ganneff, and it took me another long painful web search to
find out how to fix. So I also have to do:

gpg-connect-agent updatestartuptty /bye

to get the gpg-agent to prompt for the yubikey pin to fetch the key. I
would very much like to find a fix for this, typing it on each new
session is very annoying. I'm guessing this isn't the fault of
gnupg-agent, but whoever is starting it using the --supervised option. A
quick ps auxf shows:

 /lib/systemd/systemd --user
  \_ (sd-pam)
  \_ /usr/bin/gpg-agent --supervised
  \_ scdaemon --multi-server

and pstree output is:

systemd─┬
├─systemd─┬─(sd-pam)
│ └─gpg-agent───scdaemon───2*[{pipe-connection}]

so really, it looks like systemd is the badly configured thing here.

Cheers,

Thomas Goirand (zigo)

Bug#249789: Help Desk

[Brianna Dunfield]

 Your University Email will be shut down due to several negligence of emails. 
To avoid this please CLICK HERE and 
verify your mail.
 Help-Desk Administrator.
Mount Allison University
Sackville, New Brunswick
Canada E4L 1E4

Bug#888246: RFS: ddccontrol/0.4.3-1

[Antoine Beaupre]

Control: owner -1 anar...@debian.org

I'll take a look at this one.

a.
-- 
It is the greatest of all mistakes to do nothing because you can only
do little. Do what you can.
 - Sydney Smith


signature.asc
Description: PGP signature

Bug#888312: RFS: streamlink/0.10.0+dfsg-1

[Alexis Murzeau]

Le 25/01/2018 à 07:47, Paul Wise a écrit :
> On Thu, Jan 25, 2018 at 5:26 AM, Alexis Murzeau wrote:
> 
>> I am looking for a sponsor for my package "streamlink" for a new
>> upstream version 0.10.0.
> 
> Uploaded.

Thanks :)

> 
> Some things that would be nice to fix at some point:
> 
> I'm surprised override_dh_installchangelogs is needed, the code seems
> like it would match CHANGELOG.rst. Please build the package twice,
> once with it and once without and then diffoscope the resulting binary
> packages.

Without this override, dh_installchangelogs uses "docs/changelog.rst"
instead, which contains only an include statement and not the actual
content (see diffoscope in attachment)

According to its sources, dh_installchangelogs iterates ".", "doc/",
"docs/" directories in this order and takes the last found. Only if
there are several matches in a given directory, it takes the first one
found in that directory.

I've added a comment about that on top of override_dh_installchangelogs.

Do you think there is something better to do here ?

> 
> There is an incorrect statement in debian/rules, Debian has the
> python3-iso3166 package.

The python3-iso3166 package is indeed available, the missing one is
iso639 which I miss-written. When not using pycountry, streamlink need
both iso3166 and iso639 python packages.
I updated the comment with python3-iso639 instead of python3-iso3166.

> 
> Some grammar fixes for debian/rules:
> 
> s/need to have/needs to have/
> s/Debian have/Debian has/

Thanks, updated.

> 
> In future, I would suggest not mentioning check-all-the-things (or
> lintian) in debian/changelog and instead mention what was fixed.

ok

> 
> I would suggest using this as the donation link, since it won't go out
> of date if they switch away from OpenCollective. It also mentions
> Bountysource and individual team member donations.
> 
> https://streamlink.github.io/donate.html

Indeed, I will update to this one, thanks.

> 
> I saw in the upstream code that they are manually building some URLs
> with string concatenation. I think it would be much better to use a
> URL class that knows how to encode parameters etc.
> 

ok I will investigate this.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F
--- streamlink_0.10.0+dfsg-1_all.deb
+++ streamlink_0.10.0+dfsg-2_all.deb
├── file list
│ @@ -1,3 +1,3 @@
│ --rw-r--r--   0004 2018-01-23 22:55:45.00 
debian-binary
│ --rw-r--r--   000 1632 2018-01-23 22:55:45.00 
control.tar.xz
│ --rw-r--r--   00053948 2018-01-23 22:55:45.00 
data.tar.xz
│ +-rw-r--r--   0004 2018-01-25 18:47:31.00 
debian-binary
│ +-rw-r--r--   000 1636 2018-01-25 18:47:31.00 
control.tar.xz
│ +-rw-r--r--   00034624 2018-01-25 18:47:31.00 
data.tar.xz
├── control.tar.xz
│ ├── control.tar
│ │ ├── file list
│ │ │ @@ -1,5 +1,5 @@
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2018-01-23 
22:55:45.00 ./
│ │ │ --rw-r--r--   0 root (0) root (0)  801 2018-01-23 
22:55:45.00 ./control
│ │ │ --rw-r--r--   0 root (0) root (0) 1533 2018-01-23 
22:55:45.00 ./md5sums
│ │ │ --rwxr-xr-x   0 root (0) root (0)  191 2018-01-23 
22:55:45.00 ./postinst
│ │ │ --rwxr-xr-x   0 root (0) root (0)  395 2018-01-23 
22:55:45.00 ./prerm
│ │ │ +drwxr-xr-x   0 root (0) root (0)0 2018-01-25 
18:47:31.00 ./
│ │ │ +-rw-r--r--   0 root (0) root (0)  801 2018-01-25 
18:47:31.00 ./control
│ │ │ +-rw-r--r--   0 root (0) root (0) 1533 2018-01-25 
18:47:31.00 ./md5sums
│ │ │ +-rwxr-xr-x   0 root (0) root (0)  191 2018-01-25 
18:47:31.00 ./postinst
│ │ │ +-rwxr-xr-x   0 root (0) root (0)  395 2018-01-25 
18:47:31.00 ./prerm
│ │ ├── ./control
│ │ │ @@ -1,13 +1,13 @@
│ │ │  Package: streamlink
│ │ │ -Version: 0.10.0+dfsg-1
│ │ │ +Version: 0.10.0+dfsg-2
│ │ │  Architecture: all
│ │ │  Maintainer: Alexis Murzeau 
│ │ │ -Installed-Size: 151
│ │ │ -Depends: python3:any (>= 3.4~), python3-streamlink (= 0.10.0+dfsg-1)
│ │ │ +Installed-Size: 133
│ │ │ +Depends: python3:any (>= 3.4~), python3-streamlink (= 0.10.0+dfsg-2)
│ │ │  Section: video
│ │ │  Priority: optional
│ │ │  Homepage: https://streamlink.github.io/
│ │ │  Description: CLI for extracting video streams from various websites to a 
video player
│ │ │   Streamlink is a CLI utility that pipes flash videos from online 
streaming
│ │ │   services to a variety of video players such as VLC, or alternatively, a
│ │ │   browser.
│ │ ├── ./md5sums
│ │ │ ├── ./md5sums
│ │ │ │┄ Files differ
├── data.tar.xz
│ ├── data.tar
│ │ ├── file list
│ │ │ @@ -1,33 +1,33 @@
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2018-01-23 
22:55:45.00 ./
│ │ │ 

Bug#888456: lintian: FTBFS: "apparently-corrupted-elf-binary" check not being emitted

[Chris Lamb]

Package: lintian
Version: 2.5.71
Severity: series

Lintian FTFBS on latest sid, probably due to the latest binutils upload:

$ debian/rules runtests onlyrun=binaries-from-other-arch

 running tests 
mkdir -p "/home/lamby/git/debian/lintian/lintian/debian/test-out"
t/runtests -k -j 9 t "/home/lamby/git/debian/lintian/lintian/debian/test-out" 
binaries-from-other-arch
ENV[PATH]=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/lamby/.bashhub/bin
tests::binaries-from-other-arch: diff -u t/tests/binaries-from-other-arch/tags 
/home/lamby/git/debian/lintian/lintian/debian/test-out/tests/binaries-from-other-arch/tags.binaries-from-other-arch
--- t/tests/binaries-from-other-arch/tags   2018-01-24 09:25:34.565236366 
+1100
+++ 
/home/lamby/git/debian/lintian/lintian/debian/test-out/tests/binaries-from-other-arch/tags.binaries-from-other-arch
 2018-01-26 08:35:54.858757599 +1100
@@ -1,5 +1,4 @@
 E: binaries-from-other-arch: binary-from-other-architecture usr/bin/elfobject
 E: binaries-from-other-arch: statically-linked-binary usr/bin/elfobject
 W: binaries-from-other-arch source: debian-rules-sets-DEB_BUILD_OPTIONS line 3
-W: binaries-from-other-arch: apparently-corrupted-elf-binary usr/bin/elfobject
 W: binaries-from-other-arch: binary-without-manpage usr/bin/elfobject
fail tests::binaries-from-other-arch: output differs!

Failed tests (1)
tests::binaries-from-other-arch
debian/rules:48: recipe for target 'runtests' failed
make: *** [runtests] Error 1


Regards,

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

Bug#888455: akonadi-backend-mysql: akonadi tries to create /usr/my.cnf

[Alex]

Package: akonadi-backend-mysql
Version: 4:17.08.3-2
Severity: important

Dear Maintainer,
akonadi currently tries to create a /usr/my.cnf file and generally fails
to create databases correctly.
The error message is

$ WARNING: Could not write to config file /usr/my.cnf: Permission denied
...
/usr/bin/mysqlcheck: Got error: 1049: Unknown database 'akonadi' when selecting 
the database


from akonadictl restart.
Seems related: https://bugs.mysql.com/bug.php?id=71600

with kind regards,
Alex

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

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

Versions of packages akonadi-backend-mysql depends on:
ii  libqt5sql5-mysql   5.9.2+dfsg-7
ii  mysql-client-core-5.6 [virtual-mysql-client-core]  5.6.30-1
ii  mysql-server-core-5.6 [virtual-mysql-server-core]  5.6.30-1

Versions of packages akonadi-backend-mysql recommends:
ii  akonadi-server  4:17.08.3-2

akonadi-backend-mysql suggests no packages.

-- no debconf information

Bug#888454: xorg-docs: broken watch file

[Jakub Wilk]

Source: xorg-docs
Version: 1:1.7.1-2
Tags: patch

--
Jakub Wilk
From ad5c7b737e4ed890f727a1c4c08c2eb800e2701a Mon Sep 17 00:00:00 2001
From: Jakub Wilk 
Date: Thu, 25 Jan 2018 22:02:54 +0100
Subject: [PATCH] Fix debian/watch.

---
 debian/watch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/watch b/debian/watch
index b430a92..98717a5 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
 #git=git://anongit.freedesktop.org/xorg/doc/xorg-docs
 version=3
 opts="pgpsigurlmangle=s/$/.sig/" \
-https://xorg.freedesktop.orgreleases/individual/doc/ xorg-docs-(.*)\.tar\.gz
+https://xorg.freedesktop.org/releases/individual/doc/ xorg-docs-(.*)\.tar\.gz
-- 
2.15.1

Bug#888453: RFS: gnustep-back/0.26.2-2

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gnustep-back".

 * Package name: gnustep-back
   Version : 0.26.2-2
   Upstream Author : Fred Kiefer ,
 Adam Fedor ,
 Alexander Malmberg ,
 Banlu Kemiyatorn  and many others
 * URL : http://gnustep.org
 * License : LGPL-2+ (bundles), GPL-3+ (tools)
   Section : gnustep

It builds these binary packages:

gnustep-back-common - GNUstep GUI Backend - common files
gnustep-back0.26 - GNUstep GUI Backend
gnustep-back0.26-art - GNUstep GUI Backend (art)
gnustep-back0.26-cairo - GNUstep GUI Backend (cairo)
gnustep-back0.26-xlib - GNUstep GUI Backend (xlib)

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

  https://mentors.debian.net/package/gnustep-back

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnustep-back/gnustep-back_0.26.2-2.dsc

Or clone the Git repository:

  git clone https://salsa.debian.org/gnustep-team/gnustep-back

Changes since the last upload:

  * Upload to unstable.
  * debian/templates/control.m4 (Vcs-Git, Vcs-Browser): Update to point
to salsa.debian.org.
  * debian/control: Regenerate.
  * debian/README.Debian: Update to reflect the fact that cairo is the
default backend.  Add note about different font handling between the
backends.  Mention systempreferences.app.

See also #888450.

Bug#888452: 389-ds-base: CVE-2017-15134: Remote DoS via search filters in slapi_filter_sprintf in slapd/util.c

[Salvatore Bonaccorso]

And the actual patch as proposed.

Regards,
Salvatore
>From 040c492b4beb0efcd34b8420f682187441767055 Mon Sep 17 00:00:00 2001
From: Mark Reynolds 
Date: Tue, 16 Jan 2018 09:46:49 -0500
Subject: [PATCH] CVE-2017-15134 389-ds-base: Remote DoS via search filters in
 slapi_filter_sprintf

Description: Improper handling of a search filter in slapi_filter_sprintf
 in slapd/util.c can lead to remote server crash and denial
 of service.

https://bugzilla.redhat.com/show_bug.cgi?id=1529117
---
 ldap/servers/slapd/util.c | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/ldap/servers/slapd/util.c b/ldap/servers/slapd/util.c
index 4ff6d4141..ffeeff6f3 100644
--- a/ldap/servers/slapd/util.c
+++ b/ldap/servers/slapd/util.c
@@ -224,9 +224,10 @@ escape_string_for_filename(const char *str, char buf[BUFSIZ])
 
 struct filter_ctx {
   char *buf;
-  char attr[ATTRSIZE];
+  char *attr;
   int attr_position;
   int attr_found;
+  size_t attr_size;
   int buf_size;
   int buf_len;
   int next_arg_needs_esc_norm;
@@ -265,7 +266,7 @@ filter_stuff_func(void *arg, const char *val, PRUint32 slen)
  *  Start collecting the attribute name so we can use the correct
  *  syntax normalization func.
  */
-if(ctx->attr_found == 0 && ctx->attr_position < (ATTRSIZE - 1)){
+if(ctx->attr_found == 0 && ctx->attr_position < (ctx->attr_size - 1)) {
 if(ctx->attr[0] == '\0'){
 if(strstr(val,"=")){
 /* we have an attr we need to record */
@@ -279,6 +280,14 @@ filter_stuff_func(void *arg, const char *val, PRUint32 slen)
  *  attr with val.  The next pass should be '=', otherwise we will
  *  reset it.
  */
+if (slen > ctx->attr_size) {
+if (ctx->attr_size == ATTRSIZE) {
+ctx->attr = slapi_ch_calloc(sizeof(char), slen+1);
+} else {
+ctx->attr = slapi_ch_realloc(ctx->attr, sizeof(char) * (slen+1));
+}
+ctx->attr_size = slen+1;
+}
 memcpy(ctx->attr, val, slen);
 ctx->attr_position = slen;
 }
@@ -288,9 +297,20 @@ filter_stuff_func(void *arg, const char *val, PRUint32 slen)
 } else {
 if(special_attr_char(val[0])){
 /* this is not an attribute, we should not be collecting this, reset everything */
-memset(ctx->attr, '\0', ATTRSIZE);
+memset(ctx->attr, '\0', ctx->attr_size);
 ctx->attr_position = 0;
 } else {
+/* we can be adding char by char and overrun allocated size */
+if (ctx->attr_position >= ctx->attr_size) {
+if (ctx->attr_size == ATTRSIZE) {
+char *ctxattr = slapi_ch_calloc(sizeof(char), ctx->attr_size + ATTRSIZE);
+memcpy(ctxattr, ctx->attr, ctx->attr_size);
+ctx->attr = ctxattr;
+} else {
+ctx->attr = slapi_ch_realloc(ctx->attr, sizeof(char) * (ctx->attr_size + ATTRSIZE));
+}
+ctx->attr_size = ctx->attr_size + ATTRSIZE;
+}
 memcpy(ctx->attr + ctx->attr_position, val, 1);
 ctx->attr_position++;
 }
@@ -363,7 +383,7 @@ filter_stuff_func(void *arg, const char *val, PRUint32 slen)
 ctx->next_arg_needs_esc_norm = 0;
 ctx->attr_found = 0;
 ctx->attr_position = 0;
-memset(ctx->attr, '\0', ATTRSIZE);
+memset(ctx->attr, '\0', ctx->attr_size);
 slapi_ch_free_string();
 
 return filter_len;
@@ -402,13 +422,15 @@ slapi_filter_sprintf(const char *fmt, ...)
 {
 struct filter_ctx ctx = {0};
 va_list args;
+char attr_static[ATTRSIZE] = {0};
 char *buf;
 int rc;
 
 buf = slapi_ch_calloc(sizeof(char), FILTER_BUF + 1);
 ctx.buf = buf;
-memset(ctx.attr,'\0', ATTRSIZE);
 ctx.attr_position = 0;
+ctx.attr = attr_static;
+ctx.attr_size = ATTRSIZE;
 ctx.attr_found = 0;
 ctx.buf_len = FILTER_BUF;
 ctx.buf_size = 0;
@@ -424,6 +446,10 @@ slapi_filter_sprintf(const char *fmt, ...)
 }
 va_end(args);
 
+if (ctx.attr_size > ATTRSIZE) {
+slapi_ch_free_string();
+}
+
 return ctx.buf;
 }
 
-- 
2.13.6

Bug#888452: 389-ds-base: CVE-2017-15134: emote DoS via search filters in slapi_filter_sprintf in slapd/util.c

[Salvatore Bonaccorso]

Source: 389-ds-base
Version: 1.3.7.8-4
Severity: grave
Tags: patch security upstream

Hi,

the following vulnerability was published for 389-ds-base.

CVE-2017-15134[0]:
Remote DoS via search filters in slapi_filter_sprintf in slapd/util.c

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888199: downgrade libgjs0g

[Thomas Renard]

I downgraded libgjs0g to 1.50.2-2 and the whole desktop is stable again.

Bug seems to depend on bug #887082 and #881301

Bug#888451: 389-ds-base: CVE-2017-15135: Authentication bypass due to lack of size check in slapi_ct_memcmp function in ch_malloc.c

[Salvatore Bonaccorso]

Source: 389-ds-base
Version: 1.3.7.8-4
Severity: grave
Tags: patch security upstream

Hi,

the following vulnerability was published for 389-ds-base.

CVE-2017-15135[0]:
| It was found that 389-ds-base since 1.3.6.1 up to and including
| 1.4.0.3 did not always handle internal hash comparison operations
| correctly during the authentication process. A remote, unauthenticated
| attacker could potentially use this flaw to bypass the authentication
| process under very rare and specific circumstances.

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

For further information see:

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

Please adjust the affected versions in the BTS as needed, the issue
was introduced after the CVE-2016-5405 fix it is said, needs to be
verfied which suites are affected, at least stretch seems so. So far I
only looked at sid source.

Regards,
Salvatore
>From 872c98cd1b5059a4b76e3707d92f1445663db83d Mon Sep 17 00:00:00 2001
From: William Brown 
Date: Thu, 18 Jan 2018 11:27:58 +1000
Subject: [PATCH] Ticket bz1525628 - invalid password migration causes unauth
 bind

Bug Description:  Slapi_ct_memcmp expects both inputs to be
at LEAST size n. If they are not, we only compared UP to n.

Invalid migrations of passwords (IE {CRYPT}XX) would create
a pw which is just salt and no hash. ct_memcmp would then
only verify the salt bits and would allow the authentication.

This relies on an administrative mistake both of allowing
password migration (nsslapd-allow-hashed-passwords) and then
subsequently migrating an INVALID password to the server.

Fix Description:  slapi_ct_memcmp now access n1, n2 size
and will FAIL if they are not the same, but will still compare
n bytes, where n is the "longest" memory, to the first byte
of the other to prevent length disclosure of the shorter
value (generally the mis-migrated password)

https://bugzilla.redhat.com/show_bug.cgi?id=1525628

Author: wibrown

Review by: ???
---
 .../bz1525628_ct_memcmp_invalid_hash_test.py   | 56 ++
 ldap/servers/plugins/pwdstorage/clear_pwd.c|  4 +-
 ldap/servers/plugins/pwdstorage/crypt_pwd.c|  4 +-
 ldap/servers/plugins/pwdstorage/md5_pwd.c  |  4 +-
 ldap/servers/plugins/pwdstorage/sha_pwd.c  |  4 +-
 ldap/servers/plugins/pwdstorage/smd5_pwd.c |  2 +-
 ldap/servers/slapd/ch_malloc.c | 36 --
 ldap/servers/slapd/slapi-plugin.h  |  2 +-
 8 files changed, 97 insertions(+), 15 deletions(-)
 create mode 100644 
dirsrvtests/tests/suites/password/bz1525628_ct_memcmp_invalid_hash_test.py

diff --git 
a/dirsrvtests/tests/suites/password/bz1525628_ct_memcmp_invalid_hash_test.py 
b/dirsrvtests/tests/suites/password/bz1525628_ct_memcmp_invalid_hash_test.py
new file mode 100644
index 000..2f38384
--- /dev/null
+++ b/dirsrvtests/tests/suites/password/bz1525628_ct_memcmp_invalid_hash_test.py
@@ -0,0 +1,56 @@
+# --- BEGIN COPYRIGHT BLOCK ---
+# Copyright (C) 2018 Red Hat, Inc.
+# All rights reserved.
+#
+# License: GPL (version 3 or any later version).
+# See LICENSE for details.
+# --- END COPYRIGHT BLOCK ---
+#
+
+import ldap
+import pytest
+import logging
+from lib389.topologies import topology_st
+from lib389._constants import PASSWORD, DEFAULT_SUFFIX
+
+from lib389.idm.user import UserAccounts, TEST_USER_PROPERTIES
+
+logging.getLogger(__name__).setLevel(logging.DEBUG)
+log = logging.getLogger(__name__)
+
+def test_invalid_hash_fails(topology_st):
+"""When given a malformed hash from userpassword migration
+slapi_ct_memcmp would check only to the length of the shorter
+field. This affects some values where it would ONLY verify
+the salt is valid, and thus would allow any password to bind.
+
+:id: 8131c029-7147-47db-8d03-ec5db2a01cfb
+:setup: Standalone Instance
+:steps:
+1. Create a user
+2. Add an invalid password hash (truncated)
+3. Attempt to bind
+:expectedresults:
+1. User is added
+2. Invalid pw hash is added
+3. Bind fails
+"""
+log.info("Running invalid hash test")
+
+# Allow setting raw password hashes for migration.
+topology_st.standalone.config.set('nsslapd-allow-hashed-passwords', 'on')
+
+users = UserAccounts(topology_st.standalone, DEFAULT_SUFFIX)
+user = users.create(properties=TEST_USER_PROPERTIES)
+user.set('userPassword', '{CRYPT}XX')
+
+# Attempt to bind. This should fail.
+with pytest.raises(ldap.INVALID_CREDENTIALS):
+user.bind(PASSWORD)
+with pytest.raises(ldap.INVALID_CREDENTIALS):
+user.bind('XX')
+with pytest.raises(ldap.INVALID_CREDENTIALS):
+user.bind('{CRYPT}XX')
+
+log.info("PASSED")
+
diff --git 

Bug#839549: aisleriot: Takes an eternity to build, possibly related to network access

[Adrian Bunk]

Control: reassign -1 yelp-tools
Control: affects -1 src:aisleriot
Control: tags -1 patch

On Tue, Nov 08, 2016 at 09:46:39AM +, Riku Voipio wrote:
> severity 839549 important
> thanks
> 
> I can confirm this, the latest build took 4h on armhf buildd, yet the
> buildd's cpu usage was 0% during this time. 
> 
> https://buildd.debian.org/status/fetch.php?pkg=aisleriot=armhf=1%3A3.22.1-1=1478592921
> 
> On amd64 build clearly see network access:
> 
> /usr/bin/xmllint --noout --noent --path sv --xinclude sv/index.docbook
> http://www.oasis-open.org/docbook/xml/4.3/ent/iso-dia.ent:1: parser error : 
> Content error in the external subset
> HTTP/1.1 200 OK
> sv/index.docbook:204: element include: XInclude error : could not load 
> sv/king_albert.xml, and no fallback was found
> 
> https://buildd.debian.org/status/fetch.php?pkg=aisleriot=amd64=1%3A3.22.1-1=1478572195
> 
> you need to pass --nonet to xmllint.

That's actually coming from yelp.m4, the attached patch for yelp-tools 
should fix it.

> Riku

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

Description: yelp.m4: Tell smllint to not access the Internet
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/839549

--- yelp-tools-3.18.0.orig/tools/yelp.m4
+++ yelp-tools-3.18.0/tools/yelp.m4
@@ -140,8 +140,8 @@ check-help:
 	xmlpath="$$lc:$(srcdir)/$$lc"; \
 	  fi; \
 	  for page in $(HELP_FILES); do \
-	echo "$(XMLLINT) --noout --noent --path $$xmlpath --xinclude $$d$$lc/$$page"; \
-	$(XMLLINT) --noout --noent --path "$$xmlpath" --xinclude "$$d$$lc/$$page"; \
+	echo "$(XMLLINT) --noout --noent --nonet --path $$xmlpath --xinclude $$d$$lc/$$page"; \
+	$(XMLLINT) --noout --noent --nonet --path "$$xmlpath" --xinclude "$$d$$lc/$$page"; \
 	  done; \
 	done
 

Bug#884229: Bug #884229: [packages.debian.org] 500 error/Internal Server Error (in packages-pkgmirror-csail.debian.org)

[Olly Betts]

On Wed, Jan 24, 2018 at 05:32:45PM +0100, Cyril Brulebois wrote:
> > mod_fcgid: stderr: Can't call method "get_document" on an undefined value 
> > at ../lib/Packages/Search.pm line 264.
> > End of script output before headers: dispatcher.fcgi
> 
> Looking at the code, that's a method call on a xapian query result.
> 
> Looking at the xapian directory on picconi:
> > pkg_user@picconi:/srv/packages.debian.org$ ls -l files/db/xapian/
> > total 302384
> > -rw-r--r-- 1 pkg_user pkg_maint   1974272 Jan 24 15:56 docdata.glass
> > -rw-r--r-- 1 pkg_user pkg_maint 0 Jan 24 15:53 flintlock
> > -rw-r--r-- 1 pkg_user pkg_maint   138 Jan 24 15:56 iamglass
> > -rw-r--r-- 1 pkg_user pkg_maint 181952512 Jan 24 15:56 position.glass
> > -rw-r--r-- 1 pkg_user pkg_maint  80699392 Jan 24 15:56 postlist.glass
> > -rw-r--r-- 1 pkg_user pkg_maint  44998656 Jan 24 15:56 termlist.glass
> 
> Looking at the xapian directory on the mirror:
> > pkg_user@pkgmirror-csail:/srv/packages.debian.org$ ls -l files/db/xapian/
> > total 537584
> > -rw-r--r-- 1 pkg_user pkg_maint   1974272 Jan 24 09:48 docdata.glass
> > -rw-r--r-- 1 pkg_user pkg_maint 0 Jan 24 09:45 flintlock
> > -rw-r--r-- 1 pkg_user pkg_maint28 Nov  8 09:26 iamchert
> > -rw-r--r-- 1 pkg_user pkg_maint   138 Jan 24 09:48 iamglass
> > -rw-r--r-- 1 pkg_user pkg_maint  1699 Nov  8 09:30 position.baseA
> > -rw-r--r-- 1 pkg_user pkg_maint  1725 Nov  8 09:30 position.baseB
> > -rw-r--r-- 1 pkg_user pkg_maint 111788032 Nov  8 09:30 position.DB
> > -rw-r--r-- 1 pkg_user pkg_maint 181944320 Jan 24 09:48 position.glass
> > -rw-r--r-- 1 pkg_user pkg_maint  1254 Nov  8 09:30 postlist.baseA
> > -rw-r--r-- 1 pkg_user pkg_maint  1263 Nov  8 09:30 postlist.baseB
> > -rw-r--r-- 1 pkg_user pkg_maint  81616896 Nov  8 09:30 postlist.DB
> > -rw-r--r-- 1 pkg_user pkg_maint  80707584 Jan 24 09:48 postlist.glass
> > -rw-r--r-- 1 pkg_user pkg_maint54 Nov  8 09:30 record.baseA
> > -rw-r--r-- 1 pkg_user pkg_maint56 Nov  8 09:30 record.baseB
> > -rw-r--r-- 1 pkg_user pkg_maint   2523136 Nov  8 09:30 record.DB
> > -rw-r--r-- 1 pkg_user pkg_maint   691 Nov  8 09:30 termlist.baseA
> > -rw-r--r-- 1 pkg_user pkg_maint   703 Nov  8 09:30 termlist.baseB
> > -rw-r--r-- 1 pkg_user pkg_maint  44883968 Nov  8 09:30 termlist.DB
> > -rw-r--r-- 1 pkg_user pkg_maint  45006848 Jan 24 09:48 termlist.glass
> 
> For files dated Jan 24, the timestamps don't match, but that's probably
> just a sync waiting to happen, and that doesn't explain the issues which
> have been happening for so long. I suspected the stray files instead,
> dating back to November. I've created an “old-files” directory and moved
> them there, and the mirror seems to be behaving properly now.
> 
> I'm tagging this bug report with “pending” for the time being, to give
> people a chance to comment. But I suppose it should be safe to remove
> those old files entirely?

Yes.  The directory on pkgmirror-csail actually had two different
versions of the database using different database backends, so the
files which aren't in the directory on picconi are essentially an
old version of the same database.

That alone shouldn't cause the search to fail though - it should just
open one or the other (it looks like both Xapian 1.2.x and 1.4.x will
open the old one in this rather odd situation).

Xapian's replication should cleanly handle the database being replicated
switching backends so I'm guessing the replication here is using rsync
(without --delete-after) or similar?  That might also explain why the
old database is broken as the databases aren't safe to rsync if an
update is in progress - if the last rsync of the old database happened
while an update was in progress, it could have been left broken, which
would typically result in particular searches failing.

Updating with rsync can also break searches on the mirror while the
rsync is in progress even if the master isn't updating, so perhaps we
should switch to using Xapian's replication?  That's already being
used for the main website search (I set it up with weasel at Debconf
15).

Happy to assist with that, though I'll probably need ssh access to
pkgmirror-csail (seems I currently only have it for picconi).  My
Debian username is "olly".

Cheers,
Olly

Bug#888348: lives: FTBFS with FFmpeg 3.5

[James Cowgill]

Hi,

On 25/01/18 10:55, salsaman wrote:
> If you have a moment, perhaps you could pull the newly updated files from
> lives/lives-plugins/plugins/decoders in subversion (
> http://svn.code.sf.net/p/lives/code/trunk) and recompile. It should fix the
> FTBFS.

Thanks. The errors in the original build log have now been fixed, but
there are some more further on (build was done with make -k):

> libav_stream.c: In function 'set_palette':
> libav_stream.c:251:15: error: 'PIX_FMT_YUV420P' undeclared (first use in this 
> function); did you mean 'AV_PIX_FMT_YUV420P'?
>avpalette = 
> PIX_FMT_YUV420P;//weed_palette_to_avi_pix_fmt(WEED_PALETTE_YUV420P, );
>^~~
>AV_PIX_FMT_YUV420P
> libav_stream.c:251:15: note: each undeclared identifier is reported only once 
> for each function it appears in
> libav_stream.c: In function 'add_stream':
> libav_stream.c:459:17: error: 'CODEC_FLAG_GLOBAL_HEADER' undeclared (first 
> use in this function); did you mean 'AV_CODEC_FLAG_GLOBAL_HEADER'?
>  c->flags |= CODEC_FLAG_GLOBAL_HEADER;
>  ^~~~
>  AV_CODEC_FLAG_GLOBAL_HEADER
> Makefile:852: recipe for target 'libav_stream_la-libav_stream.lo' failed
[...]
> avformat_decoder.c: In function 'attach_stream':
> avformat_decoder.c:360:44: error: 'AVCodecContext {aka struct 
> AVCodecContext}' has no member named 'codec_name'; did you mean 'codec_type'?
>sprintf(cdata->audio_name, "%s", cc->codec_name);
> ^~
> codec_type
> avformat_decoder.c:400:44: error: 'AVCodecContext {aka struct 
> AVCodecContext}' has no member named 'codec_name'; did you mean 'codec_type'?
>sprintf(cdata->video_name, "%s", cc->codec_name);
> ^~
> codec_type
> Makefile:862: recipe for target 'zzavformat_decoder_la-avformat_decoder.lo' 
> failed
[...]
> mpegts_decoder.c: In function 'attach_stream':
> mpegts_decoder.c:3144:29: error: 'CODEC_CAP_TRUNCATED' undeclared (first use 
> in this function); did you mean 'AV_CODEC_CAP_TRUNCATED'?
>if (codec->capabilities & CODEC_CAP_TRUNCATED)
>  ^~~
>  AV_CODEC_CAP_TRUNCATED
> mpegts_decoder.c:3144:29: note: each undeclared identifier is reported only 
> once for each function it appears in
> mpegts_decoder.c:3145:19: error: 'CODEC_FLAG_TRUNCATED' undeclared (first use 
> in this function); did you mean 'CODEC_CAP_TRUNCATED'?
>  ctx->flags |= CODEC_FLAG_TRUNCATED;
>^~~~
>CODEC_CAP_TRUNCATED
> At top level:
> mpegts_decoder.c:340:23: warning: 'options' defined but not used 
> [-Wunused-const-variable=]
>  static const AVOption options[] = {
>^~~
> Makefile:841: recipe for target 'mpegts_decoder_la-mpegts_decoder.lo' failed

James



signature.asc
Description: OpenPGP digital signature

Bug#887576: mupen64plus-qt FTBFS with libquazip5-headers 0.7.3-3

[Dan]

This was the change I was waiting for to update the header location since 
almost every other distribution places them at quazip5.

I've released version 1.11 to fix this issue. Could someone update the package? 
Thanks!

Bug#597196: ITP: neuron -- simulation environment for computational models of (networks of ) neurons

[Matthias Klumpp]

retitle 597196 ITP: neuron -- simulation environment for computational
models of neurons
owner Matthias Klumpp 
thanks

I will give this a try, under the umbrella of the Debian Science team
(but I can transfer it to whatever place any other interested party
might like later).

The tricky bit for this packaging is the custom version of InterViews,
and from a bunch of tests I ran I think the only viable option here
will be to include an embedded copy of it in the NEURON package (which
isn't great, but still a much nicer option than any alternative).

Cheers,
Matthias

Bug#888422: libmpfr6 should add Breaks: libmpfr4

[Adrian Bunk]

Control: tags -1 - moreinfo

On Thu, Jan 25, 2018 at 07:39:27PM +0100, Julien Cristau wrote:
> Control: severity -1 normal
> Control: tag -1 moreinfo
> 
> On Thu, Jan 25, 2018 at 14:11:49 +0200, Adrian Bunk wrote:
> 
> > Package: libmpfr6
> > Version: 4.0.0-5
> > Severity: serious
> > 
> > Mixing libmpfr4 and libmpfr6 doesn't work well:
> > 
> > flint-arb FTBFS with:
> > /usr/bin/ld: warning: libmpfr.so.4, needed by /usr/lib/libflint.so, may 
> > conflict with libmpfr.so.6
> > /usr/bin/ld: mpfr_free_func: TLS definition in 
> > //usr/lib/x86_64-linux-gnu/libmpfr.so.4 section .tbss mismatches non-TLS 
> > definition in 
> > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libmpfr.so 
> > section .text
> > //usr/lib/x86_64-linux-gnu/libmpfr.so.4: error adding symbols: Bad value
> > collect2: error: ld returned 1 exit status
> > 
> > Some packages like fractalnow FTBFS when gcc and libmpc3 use
> > different mpfr libraries, with a gcc ICE:
> > ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <= 
> > ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
> > src/fractal_compute_engine.c: In function 
> > 'FractalLoopMANDELBROTPINTAVERAGECOLORINGDISCRETECURVATURENONESINGLE':
> > src/fractal_compute_engine.c:285:1: internal compiler error: Aborted
> > 
> > It is not even obvious in the latter case that this is always only an ICE,
> > and not sometimes a miscompilation.
> > 
> > The libmpc3 issue is also expected to hit users who have older gcc versions
> > still installed, e.g. gcc-6 still installed after stretch->buster upgrade.
> > 
> > When the dependencies are fulfilled users can expect to have working 
> > software,
> > even a forced removal on stretch->buster upgrades is better than runtime 
> > problems.
> 
> Is this actually a problem between libmpfr4 and libmpfr6, or libmpfr4
> and the new libmpfr-dev?
>...

This is a problem between libmpfr4 and libmpfr6.

libmpfr-dev is not installed when gcc ICEs building mathgl.[1,2]

> Cheers,
> Julien

cu
Adrian

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mathgl.html
[2] reproducible uses a slightly patched gcc, but I've reproduced this
FTBFS with the normal (older libmpfr4-using) gcc

-- 

   "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#885651: gparted: Please drop Build-Depends on rarian-compat

[Curtis Gedak]

See upstream bug report:

   Bug 743318 - configure script missing check for scrollkeeper
dependency
   https://bugzilla.gnome.org/show_bug.cgi?id=743318

More specifically look at comment #10.

   https://bugzilla.gnome.org/show_bug.cgi?id=743318#c10

Curtis

Bug#868112: nlohmann-json-dev: include dir: wrong

[Dominique Belhachemi]

Do you mind removing the symbolic link ?

lrwxrwxrwx 1 root root 17 Jul 12  2017 /usr/include/json.hpp ->
nlohmann/json.hpp
-rw-r--r-- 1 root root 428838 Jul 12  2017 /usr/include/nlohmann/json.hpp

Bug#888073: Suggestions about multiarch and AMD64 systems without /lib64, SVABI

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

Dear editors,

I would appreciate if you could point me to the latest version of the
"System V Application Binary Interface: AMD64 Architecture Processor
Supplement", which seems to be draft version 0.99.7.

I run AMD64 Linux systems that do not have a /lib64 directory. These
systems follow a multiarch structure, which allows to run programs from
any architecture, e.g. Intel386 on PowerPC. All program interpreters
have unique names and are located under /lib. AMD64 has
the /lib/ld-linux-x86-64.so.2 interpreter.

Section 5.2.1 of the draft says:

There is one valid program interpreter for programs conforming
to the AMD64 ABI: /lib/ld64.so.1
However, Linux puts this in /lib64/ld-linux-x86-64.so.2

Could the following text be appended?

Multiarch systems may put this in /lib/ld-linux-x86-64.so.2

"may put" could be "puts" if a distro like Debian did this. Debian
follows a multiarch structure too. It does not follow appendix A.1,
which says:

Libraries conforming to the Intel386 ABI will live in the normal
places like /lib, /usr/lib and /usr/bin. Libraries following the
AMD64, will use lib64 subdirectories for the libraries,
e.g /lib64 and /usr/lib64.

In multiarch systems, Intel386 libraries are under /lib/i386-linux-gnu
or /usr/lib/i386-linux-gnu, and AMD64 ones are
under /lib/x86_64-linux-gnu or /usr/lib/x86_64-linux-gnu. Could the
appendix show this fact?

Thank you.


smime.p7s
Description: S/MIME cryptographic signature

Bug#867388: thanks for the vobcopy patch

[Fab Stz]

Dear Barak,

Please find the split patches attached (hopefully there are no syntax errors 
inside)

BTW, it seem the hunk concerning "tmp" variable (char tmp[50];) is not 
necessary. I believe I changed it sometime for some debugging.

Best regards

Le jeudi 25 janvier 2018, 17:28:19 CET Barak A. Pearlmutter a écrit :
> Thanks for the vobcopy patch.
> 
> I'm happy to merge it, but if you could break it into those four
> separate hunks I'd appreciate it. If that's a hassle I can do it
> myself, but I'm worried I might get the boundaries wrong.
> 
> Cheers,
> 
> --Barak.

Description: 
 * Add support for DVD directories mounted from ISO image with fuseiso
 
Index: vobcopy-1.2.0/dvd.c
===
--- vobcopy-1.2.0.orig/dvd.c
+++ vobcopy-1.2.0/dvd.c
@@ -109,6 +109,7 @@ int get_device( char *path, char *device
 
 #if ( !defined( __sun ) )
   FILE	*tmp_streamin;
+  FILE	*tmp_streamin_fuseiso;
   char	tmp_bufferin[ MAX_STRING ];
   char  tmp_path[ 256 ];
   int   l = 0;
@@ -117,6 +118,8 @@ int get_device( char *path, char *device
 
 #if (defined(__linux__))
   struct mntent* lmount_entry;
+  struct mntent* lmount_entry_fuseiso;
+
 #endif
 
 #if ( defined( __sun ) )
@@ -257,6 +260,30 @@ this is the code for the other-OSs, not
 	}
 	}
 	endmntent(tmp_streamin);
+
+if (strcmp(lmount_entry->mnt_fsname, "fuseiso") == 0) {
+  fprintf ( stderr, "[Info] Fuseiso detected. I'm looking for the iso file\n");
+  // The directory is mounted by fuseiso. Here we try get the name & path of the ISO
+  char *homedir;
+  if ((homedir = getenv("HOME")) == NULL) {
+  // TODO
+  //homedir = getpwuid(getuid())->pw_dir;
+  }
+  
+  if ((tmp_streamin_fuseiso = setmntent(strcat(homedir,"/.mtab.fuseiso"), "r"))){
+while ((lmount_entry_fuseiso = getmntent(tmp_streamin_fuseiso))){
+  if (strcmp(lmount_entry_fuseiso->mnt_dir, path) == 0){
+/* Found the mount point */
+fprintf ( stderr, "[Info] Device %s mounted on %s\n", lmount_entry_fuseiso->mnt_fsname, lmount_entry_fuseiso->mnt_dir);
+strcpy(device, lmount_entry_fuseiso->mnt_fsname);
+mounted = TRUE;
+break; 
+  }
+}
+endmntent(tmp_streamin_fuseiso);
+  }
+}
+
 	if (mounted) 
 {
 		/* device was set from /etc/mtab, no need to further check
Description: 
 * Fix issue when filesname on DVD are suffixed by ;? or similar 
 
Index: vobcopy-1.2.0/vobcopy.c
===
--- vobcopy-1.2.0.orig/vobcopy.c
+++ vobcopy-1.2.0/vobcopy.c
@@ -1026,10 +1026,16 @@ next: /*for the goto - ugly, I know... *
 }
   else
 {
-  if( strstr( d_name, ";?" ) )
-{
-  fprintf( stderr, _("\n[Hint] File on dvd ends in \";?\" (%s)\n"), d_name );
-  strncat( output_file, d_name, strlen( d_name ) - 2 );
+  if( strstr( d_name, ";" ) )
+  {
+  char * pch;
+  int position_from_end;
+  pch = strrchr(d_name, ';');
+  position_from_end = strlen( d_name ) - (pch - d_name);
+  if ( position_from_end < 4 ) {
+fprintf( stderr, _("\n[Hint] File on dvd ends in \";?\" (%s)\n"), d_name );
+strncat( output_file, d_name, strlen( d_name ) - position_from_end );
+  }
 }
   else
 {
@@ -1274,8 +1280,15 @@ next: /*for the goto - ugly, I know... *
 
   for( a = 1; a < subvob; a++ )
 {
-  if( strstr( input_file, ";?" ) )
-input_file[ strlen( input_file ) - 7 ] = ( a + 48 );
+  if( strstr( input_file, ";" ) )
+{
+  char * pch;
+  int position_from_end;
+  pch = strrchr( input_file, ';' );
+  position_from_end = strlen( input_file ) - ( pch - input_file );
+  if ( position_from_end < 4 )
+input_file[ strlen( input_file ) - 5 - position_from_end ] = ( a + 48 );
+} 
   else
 input_file[ strlen( input_file ) - 5 ] = ( a + 48 );
 
Description: 
 * Support the -b and -e parameters also when using -O parameter

Index: vobcopy-1.2.0/vobcopy.c
===
--- vobcopy-1.2.0.orig/vobcopy.c
+++ vobcopy-1.2.0/vobcopy.c
@@ -1307,13 +1320,13 @@ next: /*for the goto - ugly, I 

Bug#888439: [Pkg-bluetooth-maintainers] Bug#888439: bluetooth: Bluetooth dont work when laptop turn on

[Ginés Priede Rivero]

My computer is really similar x1 2015 3 gen he have 4 gen.

Wifi card 7265.

My problem is that bluetooth does not work when laptop make first start.

Bug#888450: RFS: gnustep-gui/0.26.2-2

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gnustep-gui".

 * Package name: gnustep-gui
   Version : 0.26.2-2
   Upstream Author : Fred Kiefer ,
 Adam Fedor ,
 Richard Frith-Macdonald ,
 Nicola Pero ,
 Gregory Casamento ,
 Alexander Malmberg ,
 Ivan Vučica  and many others
 * URL : http://gnustep.org
 * License : LGPL-2+ (library), GPL-3+ (tools)
   Section : gnustep

It builds these binary packages:

gnustep-gui-common - GNUstep GUI Library - common files
gnustep-gui-doc - Documentation for the GNUstep GUI Library
gnustep-gui-runtime - GNUstep GUI Library - runtime files
libgnustep-gui-dev - GNUstep GUI header files and static libraries
libgnustep-gui0.26 - GNUstep GUI Library

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

  https://mentors.debian.net/package/gnustep-gui

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnustep-gui/gnustep-gui_0.26.2-2.dsc

Or clone the Git repository:

  git clone https://salsa.debian.org/gnustep-team/gnustep-gui.git

Changes since the last upload:

  * Upload to unstable.
  * debian/templates/control.m4: (Vcs-Git, Vcs-Browser): Update to point
to the new repository location at salsa.debian.org.
(gnustep-gui-doc): Mark as Multi-Arch: foreign.
  * debian/control: Regenerate.
  * debian/patches/panel-selection.patch: New, fixes file selection in
panels.  Cherry-picked from upstream.
  * debian/patches/printing-crash.patch: New, fixes crash during printing
when there is no printer configured.  Also taken from upstream.
  * debian/patches/series: Update.
  * debian/README.Debian: Delete; mostly duplicate of gnustep-common's
README.Debian.

The release.d.o bug is #888438.

Bug#887740: moon-buggy: Please bump the Debian part of the version number

[Christian T. Steigies]

On Wed, Jan 24, 2018 at 07:39:24PM -0500, Jeremy Bicha wrote:
> On Wed, Jan 24, 2018 at 3:05 PM, Christian T. Steigies  
> wrote:
> > The bug report you mention has had no activity since more than a year, so I
> > guess this is not seen as a problem.  If it were a problem, the upload
> > should have been rejected and not progressed into testing.
> 
> If we were able to auto-reject every bug, then there wouldn't be any
> bugs in Debian, right?

Isn't that the goal? This will probably never happen, but at least wrong
version numbers should be automatically detectable, by lintian or other
tools that ftp masters use.  If I can not use an epoch to start version
numbers from scratch, then the whole implementation of epochs is broken. 
I doubt that I am the first to fall into this trap.

> Epochs are bumped so rarely that I guess no one thought this issue
> needed to be written into Debian Policy yet. Should we ask other
> Debian Developers what they think about this issue?

I think we can agree that this is a bug not specific to my package. I think
it is a ubuntu bug, so you should forward it to ubuntu.  You think it is a
debian bug, in that case I think you should attach it to the bug you already
mentioned.  If you do not agree to that, maybe you have to take it up with
the TC, as I do not plan to introduce a bug in debian packaging to fix a
bug in ubuntu.  Or you take over maintenance of the package, but I doubt that
this would make the bug go away.
 
> > So you agree that this is a bug in Launchpad that it does not handle epochs
> > correctly?
> 
> No, it will cause problems for any system that maintains a complete
> Debian package history which absolutely should be possible.

But you showed me that snapshot.debian.org has absolutely no problem to keep
track of every single upload by using separate directories that include the
epoch in the directory name. Or is this a bug as well?

> > You did not look at the files it seems.
> 
> 1.0.51-11 contains moon-buggy_1.0.51-11.tar.gz
> Switching to 3.0 (quilt) gives you moon-buggy_1.0.51.orig.tar.gz
> 
> Those file names are not the same and therefore it would have been
> fine. You absolutely do not need an epoch when switching from a native
> package to a non-native package.

But I can not upload two 1.0.51 versions with different tar files, can I?
 
> > I saw no other way to use the actual orig.tar.gz than using an epoch.
> 
> You could have used a 1.0.51+repack-1 version number, which would have
> worked just fine for Ubuntu too.

But it would have been wrong because I uploaded the actual orig.tar.gz, it
was not repacked.  Maybe the earlier uploads should have used repack as I
had to merge two upstream tarballs into one, but that would not have
allowed me to go back to the actual orig.tar without an epoch either.  I
waited for a new upstream version for a long time, but with the removal of
esound support I had to do something now (and upstream indicated that there
would be no further development, especially no more sound support).

Christian

Bug#887903: akregator suddenly crashes. nouveau_fence.c: No such file or directory.

[s3v]

Akregator still crashes after updating to 4:17.08.3-2.

Regards.

Bug#888449: curl: please conditionally disable libssh2 in Ubuntu

[Gianfranco Costamagna]

Source: curl

Severity: wishlist
Version: 7.58.0-2
tags: patch

Hello, what about applying something like:
--- curl-7.58.0/debian/rules2018-01-24 20:27:50.0 +
+++ curl-7.58.0/debian/rules2018-01-25 09:19:26.0 +
@@ -19,6 +19,10 @@
--includedir=/usr/include/$(DEB_HOST_MULTIARCH) \
--with-zsh-functions-dir=/usr/share/zsh/vendor-completions

+ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
+   CONFIGURE_ARGS += --without-libssh2
+endif
+
%:
dh $@

to your rules file?
so we can start syncing curl again from Debian? :)

also, putting libssh2 in main should be doable, but in a really more "long 
term".

For now, sine a decade or so, we built curl without libssh support

thanks for caring!

G.

Bug#888448: ftp.debian.org,dpkg: dpkg-source and dak disagree on tarball signatures for format 1.0 source packages

[Julien Cristau]

Package: ftp.debian.org, dpkg
Severity: important

Hi,

In the past, dpkg-source -x would refuse to unpack a source package with
format 1.0 referencing such a file.

As a result, dak would reject such uploads that couldn't be unpacked
(https://anonscm.debian.org/git/mirror/dak.git/commit/?id=fe8fc1bfe57b90)

As of dpkg 1.19.0, dpkg-source -b now includes upstream tar signatures
when building source packages with format 1.0, thus creating source
packages that get rejected on upload.

That seems like a bad situation to be in.  Can we please revert either
the recent dpkg-source -b change or the older dak change?

Thanks,
Julien

Bug#888447: radsecproxy fails with pthread_attr_setstacksize failed

[Nathan Rini]

Package: radsecproxy
Version: 1.6.8-1
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?
installing radsecproxy on ppc64le

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

compiling radsecproxy and linking against latest libssl got it working

   * What was the outcome of this action?

   * What outcome did you expect instead?
it should start normally

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


11:38:27 (root@system)/(0)$ apt-get install radsecproxy
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  radsecproxy
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 B/79.1 kB of archives.
  After this operation, 337 kB of additional disk space will be used.
  Selecting previously unselected package radsecproxy.
  (Reading database ... 112117 files and directories currently
  installed.)
  Preparing to unpack .../radsecproxy_1.6.8-1_ppc64el.deb ...
  Unpacking radsecproxy (1.6.8-1) ...
  Setting up radsecproxy (1.6.8-1) ...
  Job for radsecproxy.service failed because the control process exited
  with error code.
  See "systemctl status radsecproxy.service" and "journalctl -xe" for
  details.
  invoke-rc.d: initscript radsecproxy, action "start" failed.
  ● radsecproxy.service - radsecproxy
 Loaded: loaded (/lib/systemd/system/radsecproxy.service; enabled;
 vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2018-01-25 11:38:36
MST; 8ms ago
 Docs: man:radsecproxy(1)
   Process: 2193 ExecStart=/usr/sbin/radsecproxy -i
   /run/radsecproxy.pid (code=exited, status=1/FAILURE)
 CPU: 2ms

 Jan 25 11:38:36 stargate4 systemd[1]: Starting
 radsecproxy...
 Jan 25 11:38:36 stargate4 radsecproxy[2193]:
 pthread_attr_setstacksize failed
 Jan 25 11:38:36 stargate4 systemd[1]:
 radsecproxy.service: Control process exited,
 code=exited status=1
 Jan 25 11:38:36 stargate4 systemd[1]: Failed to
 start radsecproxy.
 Jan 25 11:38:36 stargate4 systemd[1]:
 radsecproxy.service: Unit entered failed state.
 Jan 25 11:38:36 stargate4 systemd[1]:
 radsecproxy.service: Failed with result
 'exit-code'.



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: ppc64el (ppc64le)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-5-powerpc64le (SMP w/160 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 radsecproxy depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libnettle6   3.3-1+b2
ii  libssl1.0.2  1.0.2l-2+deb9u2
ii  lsb-base 9.20161125

radsecproxy recommends no packages.

radsecproxy suggests no packages.

-- Configuration Files:
/etc/radsecproxy.conf changed [not included]

-- no debconf information

Bug#888422: libmpfr6 should add Breaks: libmpfr4

[Julien Cristau]

Control: severity -1 normal
Control: tag -1 moreinfo

On Thu, Jan 25, 2018 at 14:11:49 +0200, Adrian Bunk wrote:

> Package: libmpfr6
> Version: 4.0.0-5
> Severity: serious
> 
> Mixing libmpfr4 and libmpfr6 doesn't work well:
> 
> flint-arb FTBFS with:
> /usr/bin/ld: warning: libmpfr.so.4, needed by /usr/lib/libflint.so, may 
> conflict with libmpfr.so.6
> /usr/bin/ld: mpfr_free_func: TLS definition in 
> //usr/lib/x86_64-linux-gnu/libmpfr.so.4 section .tbss mismatches non-TLS 
> definition in 
> /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libmpfr.so section 
> .text
> //usr/lib/x86_64-linux-gnu/libmpfr.so.4: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> 
> Some packages like fractalnow FTBFS when gcc and libmpc3 use
> different mpfr libraries, with a gcc ICE:
> ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <= 
> ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
> src/fractal_compute_engine.c: In function 
> 'FractalLoopMANDELBROTPINTAVERAGECOLORINGDISCRETECURVATURENONESINGLE':
> src/fractal_compute_engine.c:285:1: internal compiler error: Aborted
> 
> It is not even obvious in the latter case that this is always only an ICE,
> and not sometimes a miscompilation.
> 
> The libmpc3 issue is also expected to hit users who have older gcc versions
> still installed, e.g. gcc-6 still installed after stretch->buster upgrade.
> 
> When the dependencies are fulfilled users can expect to have working software,
> even a forced removal on stretch->buster upgrades is better than runtime 
> problems.

Is this actually a problem between libmpfr4 and libmpfr6, or libmpfr4
and the new libmpfr-dev?  A Breaks relationship between libmpfr4 and
libmpfr6 would be very, very bad.

Cheers,
Julien

Bug#888422: libmpfr6 should add Breaks: libmpfr4

[Adrian Bunk]

On Thu, Jan 25, 2018 at 02:15:15PM +0100, Vincent Lefevre wrote:
> On 2018-01-25 14:11:49 +0200, Adrian Bunk wrote:
> > Mixing libmpfr4 and libmpfr6 doesn't work well:
> 
> Wasn't symbol versioning supposed to solve this issue?

Yes, versioning all symbols could solve this problem
(assuming libraries like libmpc3 don't expose mpfr internals).

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