Bug#921495: Does not affect testing

[Andreas Tille]

Control: tags -1 -help
Control: notfound -1 1.7.2-3

Bug#922243: mailman3-full : Depends: mailman3 but it is not going to be installed

[K E N O]

Dear Pierre,

This is my `sources.list`:

> ## Note, this file is written by cloud-init on first boot of an instance
> ## modifications made here will not survive a re-bundle.
> ## if you wish to make changes you can:
> ## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/cloud.cfg
> ## or do the same in user-data
> ## b.) add sources in /etc/apt/sources.list.d
> ## c.) make changes to template file 
> /etc/cloud/templates/sources.list.debian.tmpl
> ###
> 
> # See 
> http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.html
> # for how to upgrade to newer versions of the distribution.
> deb http://deb.debian.org/debian stretch main contrib non-free
> deb-src http://deb.debian.org/debian stretch main contrib non-free
> 
> ## Major bug fix updates produced after the final release of the
> ## distribution.
> deb http://security.debian.org/ stretch/updates main contrib non-free
> deb-src http://security.debian.org/ stretch/updates main contrib non-free
> deb http://deb.debian.org/debian stretch-updates main contrib non-free
> deb-src http://deb.debian.org/debian stretch-updates main contrib non-free
> 
> ## Uncomment the following two lines to add software from the 'backports'
> ## repository.
> ##
> ## N.B. software from this repository may not have been tested as
> ## extensively as that contained in the main release, although it includes
> ## newer versions of some applications which may provide useful features.
> # deb http://deb.debian.org/debian stretch-backports main contrib non-free
> # deb-src http://deb.debian.org/debian stretch-backports main contrib non-free

Best

> Am 13.02.2019 um 22:32 schrieb Pierre-Elliott Bécue :
> 
> Le mercredi 13 février 2019 à 18:07:39+0100, kenokenobingo a écrit :
>> Package: mailman3-full
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> there are problems with the dependencies while trying to install 
>> `mailman3-full` via aptitutde.
>> 
>> The following packages have unmet dependencies:
>> mailman3-full : Depends: mailman3 but it is not going to be installed
>>  Depends: mailman3-web (>= 0+20180916-1) but it is not going 
>> to be installed
>> Depends: python3-mailman-hyperkitty but it 
>> is not going to be installed
>> E: Unable to correct problems, you have held 
>> broken packages.
>> 
>> -- System Information:
>> Debian Release: 9.7
>>  APT prefers stable-updates
>>  APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> 
>> Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
>> 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)
> 
> Hi,
> 
> I'll need a little more input regarding the available mirrors for your
> system. My bet would be that your package manager doesn't try to fetch
> all the dependencies from the backports when they fail to be resolved in
> stretch.
> 
> Best regards,
> 
> -- 
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
> It's far easier to fight for one's principles than to live up to them.

Bug#922285: libpython3.7-stdlib: Please add ann_module, ann_module2, ann_module3

[Michael R. Crusoe]

Package: libpython3.7-stdlib
Version: 3.7.2-2
Severity: normal

Dear Maintainer,

As per the description of libpython3.7-testsuite I'm requesting that the 
ann_module{,2,3} be added to libpython3.x-stdlib so that the testsuite of
python-typing-extensions can run.


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

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

Versions of packages libpython3.7-stdlib depends on:
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-7
ii  libdb5.3  5.3.28+dfsg1-0.3
ii  libffi6   3.2.1-9
ii  liblzma5  5.2.4-1
ii  libmpdec2 2.4.2-2
ii  libncursesw6  6.1+20181013-2
ii  libpython3.7-minimal  3.7.2-2
ii  libreadline7  7.0-5
ii  libsqlite3-0  3.27.1-1
ii  libtinfo6 6.1+20181013-2
ii  libuuid1  2.33.1-0.1
ii  mime-support  3.62

libpython3.7-stdlib recommends no packages.

libpython3.7-stdlib suggests no packages.

-- no debconf information

Bug#922284: wmaker-common: Should not set GNUSTEP_USER_ROOT; unable to build GNUstep software

[Yavor Doganov]

Package: wmaker-common
Version: 0.95.8-3
Severity: important
File: /usr/bin/wmaker
Control: affects -1 gnustep

As evident from the prefix, GNUSTEP_USER_ROOT is a GNUstep variable and
Window Maker should not set it.  Furthemore, it has been deprecated for
12 years already.  As of gnustep-make/2.7.0-4 the GNUstep build system
is configured in strict v2 mode which makes it impossible to compile
GNUstep software.  In a terminal started from a Window Maker session:

yavor@aneto:/tmp/gorm.app-1.2.24$ make
This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
rm -f InterfaceBuilder; \
ln -s GormLib InterfaceBuilder
/usr/share/GNUstep/Makefiles/config-noarch.make:121: *** GNUSTEP_USER_ROOT is 
obsolete.  Stop.

It is also impossible to build gnustep-make from pristine upstream
source:

yavor@aneto:/tmp$ wget -q 
ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-make-2.7.0.tar.gz
yavor@aneto:/tmp$ tar xzf gnustep-make-2.7.0.tar.gz
yavor@aneto:/tmp$ cd gnustep-make-2.7.0/
yavor@aneto:/tmp/gnustep-make-2.7.0$ ./configure
...
yavor@aneto:/tmp/gnustep-make-2.7.0$ make
config-noarch.make:121: *** GNUSTEP_USER_ROOT is obsolete.  Stop.

Note that the majority of GNUstep users use Window Maker as their window
manager and many of them build GNUstep software from source, mostly
because of the GNUstep Objective-C runtime which depends on Clang
(Debian packages use GCC and the GCC/GNU runtime).

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

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

wmaker-common depends on no packages.

wmaker-common recommends no packages.

Versions of packages wmaker-common suggests:
ii  wmaker  0.95.8-3

-- no debconf information

Bug#922283: RM: ruby-fog-sakuracloud -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-fog, which is now 
removed.

No other reverse dependencies.

Bug#922282: RM: ruby-azure -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-fog-azure which is 
now removed. No other reverse dependencies.

Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Pirate Praveen]

On Wed, 19 Dec 2018 00:55:39 +0100 Dominik George
 wrote:
> >> We had volatile, which, redefined properly, could help. I am trying
> >to draft such a definition.
> >
> >Did you get a chance to work on it?
> 
> I do have this on my todo list for around Christmas.
> 
> People who know me that I deliberately leave out the year, but my intentions 
> are 2018 ;).

Adding this here for completeness
https://lists.debian.org/debian-devel/2018/12/msg00297.html



signature.asc
Description: OpenPGP digital signature

Bug#922281: Fw: SD Card Format Bug

[TS Brownie]

Package: base

Version: all

1) I have repeated this on 3 different SD cards (16 GB), using windows 7 and 10 
and 3 different computers and 2 SD card readers.  Both Pi 2 and 3.
2) I used to be a software engineer
3) Happens on Jessie and Stretch

Summary:
Load Debian (usually NOOB or package with desired options) on SD card, finish 
install.  No problems (more than 10 times), can use it normally
Try to install new OS on "old" SD card with existing Debian OS and it gives an 
error.
- Windows can't format it (not surprising).
- The last recommended formatter/installer (don't recall the name) can't 
format it or install new OS
- The latest formatter / installer balenaEtcher gives an error
- The SD card formatter from SDcard.org can't format it (throws an error)
- True with Kingston, Acer and SanDisk SD cards
- Used Nobi card adapter and built in card port on HP computer (same result)

Take these SD cards in on "warranty" and the companies show they are "bad" 
(they replaced them for free).  I can take a brand new card and make it go 
"bad" with the above procedure.  That should not happen.  It seems the install 
may be overwriting something important at a low level, or similar to "damage" 
these cards.

Best Regards,

tsb

PS: Suggestion, your bug reporting system may be wonderful for the programmers, 
but it sucks for those trying to help.  You might rethink it.

Bug#922280: Wrong name of dynamic linker is in binaries cross-compiled by arm-gcc.

[Wang Shanker]

Package: gcc-arm-linux-gnueabi
Version: 6.3.0-4 

The name of dynamic linker of binaries cross-compiled by arm-gcc is 
`/lib/ld-linux.so.3`.

```
# # on an amd64 machine
# echo "int main(){ return 0; }" > test.c
# arm-linux-gnueabi-gcc test.c -o test
# env LC_ALL=C arm-linux-gnueabi-readelf -l test

Elf file type is DYN (Shared object file)
Entry point 0x464
There are 9 program headers, starting at offset 52

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX  0x0006cc 0x06cc 0x06cc 0x8 0x8 R   0x4
  PHDR   0x34 0x0034 0x0034 0x00120 0x00120 R E 0x4
  INTERP 0x000154 0x0154 0x0154 0x00013 0x00013 R   0x1
  [Requesting program interpreter: /lib/ld-linux.so.3]
  LOAD   0x00 0x 0x 0x006d8 0x006d8 R E 0x1
  LOAD   0x000f04 0x00010f04 0x00010f04 0x00140 0x00144 RW  0x1
  DYNAMIC0x000f10 0x00010f10 0x00010f10 0x000f0 0x000f0 RW  0x4
  NOTE   0x000168 0x0168 0x0168 0x00044 0x00044 R   0x4
  GNU_STACK  0x00 0x 0x 0x0 0x0 RW  0x10
  GNU_RELRO  0x000f04 0x00010f04 0x00010f04 0x000fc 0x000fc R   0x1

 Section to Segment mapping:
  Segment Sections...
   00 .ARM.exidx 
   01 
   02 .interp 
   03 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr 
.gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata 
.ARM.exidx .eh_frame 
   04 .init_array .fini_array .jcr .dynamic .got .data .bss 
   05 .dynamic 
   06 .note.ABI-tag .note.gnu.build-id 
   07 
   08 .init_array .fini_array .jcr .dynamic 
```

However, in debian-armhf, the dynamic linker should be 
`/lib/ld-linux-armhf.so.3`.

```
# # on an armhf machine
# readelf -l /bin/true 

Elf file type is DYN (Shared object file)
Entry point 0x109d
There are 9 program headers, starting at offset 52

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX  0x004060 0x4060 0x4060 0x8 0x8 R   0x4
  PHDR   0x34 0x0034 0x0034 0x00120 0x00120 R E 0x4
  INTERP 0x000154 0x0154 0x0154 0x00019 0x00019 R   0x1
  [Requesting program interpreter: /lib/ld-linux-armhf.so.3]
  LOAD   0x00 0x 0x 0x0406c 0x0406c R E 0x1
  LOAD   0x004ed0 0x00014ed0 0x00014ed0 0x002d8 0x0041c RW  0x1
  DYNAMIC0x004f08 0x00014f08 0x00014f08 0x000f8 0x000f8 RW  0x4
  NOTE   0x000170 0x0170 0x0170 0x00044 0x00044 R   0x4
  GNU_STACK  0x00 0x 0x 0x0 0x0 RW  0x10
  GNU_RELRO  0x004ed0 0x00014ed0 0x00014ed0 0x00130 0x00130 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00 .ARM.exidx 
   01 
   02 .interp 
   03 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr 
.gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata 
.ARM.exidx .eh_frame 
   04 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .data .bss 
   05 .dynamic 
   06 .note.ABI-tag .note.gnu.build-id 
   07 
   08 .init_array .fini_array .jcr .data.rel.ro .dynamic 
```

When I copy the cross-compiled binary to an armhf machine, the 
executable cannot get executed.

```
# ./test 
/lib/ld-linux.so.3: No such file or directory
```

I wonder whether it is a bug or left on purpose.

Bug#922247: security-tracker: please use new urlpath for DLAs on www.d.o

[Salvatore Bonaccorso]

Control: tags -1 + pending

Hi Holger,

On Wed, Feb 13, 2019 at 06:08:31PM +, Holger Levsen wrote:
> package: security-tracker
> x-debbugs-cc: debian-...@lists.debian.org
> 
> Hi,
> 
> this is a bug to track fixing this small glitch in the new
> www.debian.org/lts/security/ area:
> 
> On Mon, Feb 11, 2019 at 04:26:38PM -0500, Antoine Beaupr?? wrote:
> > >> * Adaptation in the security tracker so the new URL paths are used from
> > >> now on is also needed.
> > > right. shall we file a bug to not forget this?
> > Sure, please do.
> 
> done. Salvatore also prepared a patch for this.

https://salsa.debian.org/security-tracker-team/security-tracker/commit/cfccb4bb04d4bc5129645fa48d17914d3fbf8936
for reference. Bug can be closed once deployed.

Regards,
Salvatore

Bug#922279: debconf: Can't select long choices in dialog (whiptail) multiselect

[Kevin Locke]

Package: debconf
Version: 1.5.70
Severity: normal
Tags: patch

Dear Maintainer,

After upgrading libpam-cap, systemd user sessions stopped working.  I
traced the problem to pam-auth-update, which uses debconf to manage the
PAM configuration.  Using the dialog frontend with whiptail in a
terminal that is 80 characters wide, it is not possible to enable the
pam_systemd module, even if it is selected in whiptail.  To reproduce:

DEBIAN_FRONTEND=dialog DEBCONF_DEBUG=developer PERL_DL_NONLAZY=1 
/usr/share/debconf/frontend sh -c '
. /usr/share/debconf/confmodule
db_x_loadtemplatefile /var/lib/dpkg/info/libpam-runtime.templates libpam-runtime
db_subst libpam-runtime/profiles profile_names unix, systemd, mkhomedir, cgfs, 
capability
db_subst libpam-runtime/profiles profiles Unix authentication, Register user 
sessions in the systemd control group hierarchy, Create home directory on 
login, Create cgroups for user login sessions, Inheritable Capabilities 
Management
db_fset libpam-runtime/profiles seen false
db_set libpam-runtime/profiles unix, systemd, cgfs, capability
db_input critical libpam-runtime/profiles || echo $RET
db_go
db_get libpam-runtime/profiles
echo "<$RET>"'

Which will produce output like the following:

debconf (developer): frontend started
debconf (developer): Trying to find a templates file..
debconf (developer): Trying sh.templates
debconf (developer): Trying /usr/share/debconf/templates/sh.templates
debconf (developer): Couldn't find a templates file.
debconf (developer): frontend running, package name is 
debconf (developer): starting sh -c 
. /usr/share/debconf/confmodule
db_x_loadtemplatefile /var/lib/dpkg/info/libpam-runtime.templates libpam-runtime
db_subst libpam-runtime/profiles profile_names unix, systemd, mkhomedir, cgfs, 
capability
db_subst libpam-runtime/profiles profiles Unix authentication, Register user 
sessions in the systemd control group hierarchy, Create home directory on 
login, Create cgroups for user login sessions, Inheritable Capabilities 
Management
db_fset libpam-runtime/profiles seen false
db_set libpam-runtime/profiles unix, systemd, cgfs, capability
db_input critical libpam-runtime/profiles || echo $RET
db_go
db_get libpam-runtime/profiles
echo "<$RET>"
debconf (developer): <-- X_LOADTEMPLATEFILE 
/var/lib/dpkg/info/libpam-runtime.templates libpam-runtime
debconf (developer): --> 0
debconf (developer): <-- SUBST libpam-runtime/profiles profile_names unix, 
systemd, mkhomedir, cgfs, capability
debconf (developer): --> 0
debconf (developer): <-- SUBST libpam-runtime/profiles profiles Unix 
authentication, Register user sessions in the systemd control group hierarchy, 
Create home directory on login, Create cgroups for user login sessions, 
Inheritable Capabilities Management
debconf (developer): --> 0
debconf (developer): <-- FSET libpam-runtime/profiles seen false
debconf (developer): --> 0 false
debconf (developer): <-- SET libpam-runtime/profiles unix, systemd, cgfs, 
capability
debconf (developer): --> 0 value set
debconf (developer): <-- INPUT critical libpam-runtime/profiles
debconf (developer): --> 0 question will be asked
debconf (developer): <-- GO 
debconf (developer): Input value, "Register user sessions in the systemd 
control group ..." not found in C choices! This should never happen. Perhaps 
the templates were incorrectly localized.
debconf (developer): --> 0 ok
debconf (developer): <-- GET libpam-runtime/profiles
debconf (developer): --> 0 unix, cgfs, capability


Note that systemd does not appear in the output regardless of whether or
not the option is selected.  The problem is that the ellipsized choice
text can't be mapped back to the choice value.  I have attached a patch
which adds this mapping.  It also handles the case that ellipsized
options become ambiguous by allowing screen overflow instead of blindly
mapping both to a single value.

Thanks for considering,
Kevin

P.S.  I have set Severity: normal, but the systemd breakage was severe
and difficult to track down without familiarity with systemd user
sessions.  The issue may have significant impact.


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

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

Versions of packages debconf depends on:
ii  perl-base  5.28.1-4

Versions of packages debconf recommends:
ii  apt-utils 1.8.0~rc2
ii  debconf-i18n  1.5.70

Versions of packages debconf suggests:
pn  debconf-doc
pn  debconf-kde-helper 
pn  debconf-utils  
pn  libgtk3-perl   
pn  libnet-ldap-perl   
ii  libterm-readline-gnu-perl  1.36-1
ii  perl   5.28.1-4
ii  whipta

Bug#922278: mpfr4: please update the www.mpfr.org URLs to use https

[Vincent Lefevre]

Source: mpfr4
Version: 4.0.2-1
Severity: normal

The www.mpfr.org URLs under the debian directory should be updated
to use https:

debian/control:Homepage: http://www.mpfr.org/
debian/copyright:MPFR was downloaded from http://www.mpfr.org/.
debian/watch:http://www.mpfr.org/mpfr-current/   mpfr-(.+).tar.gz

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

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

Bug#922133: src:marionnet: build-depends/depends on cruft packages

[Scott Kitterman]

On February 13, 2019 7:23:14 PM UTC, Ralf Treinen  wrote:
>Hi,
>
>On Tue, Feb 12, 2019 at 08:57:55AM -0500, Scott Kitterman wrote:
>> Package: src:marionnet
>> Version: 0.90.6+bzr508-1
>> Severity: serious
>> Justification: fails to build from source (but built successfully in
>the past)
>> 
>> liblablgtksourceview2-ocaml and liblablgtksourceview2-ocaml-dev are
>no longer
>> built by lablgtk2 and will be removed.  Marionnet build-depends on
>> liblablgtksourceview2-ocaml-dev and as a result depends on
>> liblablgtksourceview2-ocaml, which lablgtk2 no longer provides.
>
>Stephane Glondu did an upload of lablgtk2 today which puts these two
>packages back on the map, so they should be available on the
>autobuilders
>by now or at least very soon.
>

Thanks.  Feel free to close the bug once it's there.

Scott K

Bug#918887: RFA:quickml -- Very-easy-to-use mailing list system

[Bekks Oruta]

I would be willing to adopt this package if you would assist me to get started.

Emeka


On Thu, 10 Jan 2019 19:57:12 +0900 Kenshi Muto  wrote:
>  Package: wnpp
>  Severity: normal
>
>  I request a maintainer for quickml package.
>  This program is implemented in Ruby language.
>
>  Unfortunately upstream development was dead
>  a long long time ago.
>  Codes are bit old and would be better to update for
>  newer Ruby version.
>
>  Even so, I believe this list server software is
>  very unique and useful.
>
>  Thanks,
>  - --
>  Kenshi Muto
>  km...@debian.org
>
>> -BEGIN PGP SIGNATURE-
>>  Comment: Processed by Mailcrypt 3.5.9 
>>
>>  iQIzBAEBCAAdFiEEnMxcIsEJVbWPVaUbHSHIPcRS4PwFAlw3JQQACgkQHSHIPcRS
>>  4PzuJBAAk7yDEjofjQpEC2x3XO9f/PxJF+bKWImtkbrpq313vOC4Gw0o/KJWYe7N
>>  6AdO5ZeJnxzobIfWdMUWSKErTAcM5yIA1kZBGunCrWK5YIRhPML8zlALjEDMFzhU
>>  ZscRiBwKKyGP0pwWg7Xdkn4K/Ze86F4IfNfLfYIauqQLkNfdIkJ+thxq7hYWb7ld
>>  ovc9uYDkqrUu5WKikJT9lKKJJ9EaGO9/+SjEkP2eotzy/4B0Q+Y+GeolRmkq5kJk
>>  OgA8V6MjcyefUfj2x6YgjZFACxDSqf14BRRDqiJzPDvV9a3/y3kd0IPpl5mjYWDi
>>  l2/KdsyHdQwsYqhaDW0bBwfaS6CttfbyMNMBUGY7pzbRF+17G0RArIxxDEV7YQSW
>>  NtFo8MX0VDvVPz1n0cVyehh1tUiYmoRvENXZJ73WiwkjdAWQdEIwcQWqxTWzs5oh
>>  gU795mIhbyrD9/PfvitzrRNIJJPrxmZCHaC+Zjbt+0l92lRwqybzOnVCcOT8swP9
>>  f2n1h7jJrflfn6zeJzeZfBZaERGETaC0w5wdAYIDEk+ts6G7it8uPQV2wdLiQRNo
>>  y8BeHCsmFc+GDQXtfGCGKTYilBb0wi72+w/n0/oXWm1DeT9DYR1Ct9uQIPPnWhUm
>>  3t8xh3+2eTaxPscB/Xke50hC/wueBYCwZO6xVZFJfq8dTpH1mkE=
>>  =Jvro
>>  -END PGP SIGNATURE-
 End of forwarded message 

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[Synthea]

(gdb) thread apply all bt

Thread 3 (Thread 0x7fffe6f80700 (LWP 22789)):
#0  0x74dec67d in poll () at ../sysdeps/unix/syscall-
template.S:84
#1  0x775269f6 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#2  0x77526d82 in g_main_loop_run () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#3  0x77b0e656 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-
2.0.so.0
#4  0x7754e3d5 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#5  0x750b3494 in start_thread (arg=0x7fffe6f80700) at
pthread_create.c:333
#6  0x74df5acf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 2 (Thread 0x7fffe7781700 (LWP 22788)):
#0  0x74dec67d in poll () at ../sysdeps/unix/syscall-
template.S:84
#1  0x775269f6 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#2  0x77526b0c in g_main_context_iteration () from /lib/x86_64-
linux-gnu/libglib-2.0.so.0
#3  0x77526b51 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#4  0x7754e3d5 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#5  0x750b3494 in start_thread (arg=0x7fffe7781700) at
pthread_create.c:333
#6  0x74df5acf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 1 (Thread 0x77f07a80 (LWP 22778)):
#0  raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x74263038 in ffi_call_unix64 () from /usr/lib/x86_64-
linux-gnu/libffi.so.6
#2  0x74262a9a in ffi_call () from /usr/lib/x86_64-linux-
gnu/libffi.so.6
#3  0x77800c8a in g_cclosure_marshal_generic_va () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x778001a4 in ?? () from /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#5  0x7781a8cd in g_signal_emit_valist () from /usr/lib/x86_64-
linux-gnu/libgobject-2.0.so.0
---Type  to continue, or q  to quit---
#6  0x7781afbf in g_signal_emit () from /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#7  0x77afa165 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-
2.0.so.0
#8  0x775266aa in g_main_context_dispatch () from /lib/x86_64-
linux-gnu/libglib-2.0.so.0
#9  0x77526a60 in ?? () from /lib/x86_64-linux-gnu/libglib-
2.0.so.0
#10 0x77526d82 in g_main_loop_run () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#11 0x76dbe3b7 in gtk_main () from /usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0
#12 0x5558ec29 in fe_main ()
#13 0x55582c6b in main ()
(gdb) 

It should be what you want

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

Bug#922276: ss man page: add example of how to get maximal output

[積丹尼 Dan Jacobson]

Package: iproute2
Version: 4.20.0-2
Severity: wishlist
File: /usr/share/man/man8/ss.8.gz

Add example(s) of how to absolutely print out everything (all options on
at the same time) about everything.

Bug#922277: su: write errors to STDERR not STDOUT

[積丹尼 Dan Jacobson]

Package: util-linux
Version: 2.33.1-0.1

Can you believe this error message is written to STDOUT

# su -c : nobody|wc
  1   6  41
# su -c : nobody
This account is currently not available.

instead of STDERR!

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[James Clarke]

On 14 Feb 2019, at 03:07, Synthea  wrote:
> 
> Here's the full backtrace with the command you asked:
> 
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  .html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from hexchat...(no debugging symbols found)...done.
> (gdb) thread apply all bt
> (gdb) run

You need to run it at the point when the SIGTERM is received, otherwise it
won't do anything.

James

Bug#921667: [pkg-apparmor] Bug#921667: lxc, lava-dev: lxc fails to install along lava-dev --install-recommends

[Seth Arnold]

On Wed, Feb 13, 2019 at 08:18:40PM +0100, Pierre-Elliott Bécue wrote:
> See my staged commits.
> 
> https://salsa.debian.org/lxc-team/lxc/commit/a0e6b5f26227236e44ab8ff4cee745228201bb7d

Hello, there's a small user-visible typo "runn" in the new message.

Is this section of code automatically generated by dh_apparmor in the
packaging? Is your modification persistent?

Thanks


signature.asc
Description: PGP signature

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[Synthea]

Here's the full backtrace with the command you asked:

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from hexchat...(no debugging symbols found)...done.
(gdb) thread apply all bt
(gdb) run
Starting program: /usr/bin/hexchat 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-
gnu/libthread_db.so.1".
[New Thread 0x7fffe7781700 (LWP 22788)]
[New Thread 0x7fffe6f80700 (LWP 22789)]

** (hexchat:22778): WARNING **: Invalid borders specified for theme
pixmap:
/usr/share/themes/Breeze-Dark/gtk-2.0/../assets/line-h.png,
borders don't fit within the image

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

** (hexchat:22778): WARNING **: invalid source position for vertical
gradient

Thread 1 "hexchat" received signal SIGTERM, Terminated.
raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

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

Bug#922268: rxvt-unicode: tabbed extension segfaults

[Ryan Kavanagh]

Hi,

On Thu, Feb 14, 2019 at 12:19:26AM +0100, gregor herrmann wrote:
> Does this help?

It does, thank you. I managed to produce a second segfault at a
different location by providing the colour resources under URxvt.tabbed
with bogus values. What resources do you have set for URxvt? (See the
output of "appres URxvt" or of "xrdb -query -all")

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#791400: [yagf] Please update to 0.9.5

[Alexey Loginov]

Please update on qt5 branch:
http://svnweb.mageia.org/packages/cauldron/yagf/current/

Bug#922275: libomp-7-dev: Feature Request To Have libomp-7-dev Install Symlink /usr/lib//libomp.so

[Ron Lovell]

Package: libomp-7-dev
Version: 1:7.0.1-6
Severity: wishlist

Dear Maintainer,

While testing flang-7 for OpenMP programs, I noticed that 'flang
-fopenmp=libomp' doesn't know to link libomp. (clang -fopenmp=libomp
has no problem.) It's easy enough to work around that by using linker
option -L/usr/lib/llvm-7/lib in the case of libomp-7-dev, with some
smarts in my meson.build to adjust to versions other than 7.

But it would be even better if libomp--dev installed a
symlink /usr/lib//libomp.so -> ../llvm-/lib/libomp.so
Then flang and other programs would find it in a standard library
directory.

It does install a /usr/lib//libomp5.so symlink, but Clang
doesn't accept -fopenmp=libomp5.

P.S. Wondering how I'm using Meson to build programs with Flang?
I hacked Meson. Let me know if you're interested.

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

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

Versions of packages libomp-7-dev depends on:
ii  libc6   2.28-7
ii  libgcc1 1:8.2.0-20
ii  libomp5-7   1:7.0.1-6
ii  libstdc++6  8.2.0-20

libomp-7-dev recommends no packages.

Versions of packages libomp-7-dev suggests:
pn  libomp-7-doc  

-- no debconf information

Bug#922273: [hexchat] Thread 1 closes for missing raise.c

[James Clarke]

Control: tags -1 moreinfo
Control: retitle -1 [hexchat] Receives unexpected SIGTERM

On Thu, Feb 14, 2019 at 03:06:32AM +0100, Synthea wrote:
> Package: hexchat
> Version: 2.14.2-3~bpo9+1
> Severity: important
>
> Noticed this problem while running hexchat in gdb
> Thread 1 "hexchat" received signal SIGTERM, Terminated.
> raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51

So this is telling you something (maybe hexchat itself, though likely
not) sent a SIGTERM signal to hexchat. Are you low on memory (since that
could cause the OOM killer to send a SIGTERM to hexchat)? Please run the
"thread apply all bt" command to get a backtrace so we can have more of
an idea what's going on

> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

This is not the error. This is just GDB trying to print out the source
code corresponding to where the debugger as stopped, but since you don't
have glibc's source code unpacked in a location it can find, it instead
prints this message to tell you it can't find the source.

James

Bug#916692: #916692

[eamanu15]

Control: tags -1 +help

Hello,

I tag help because I am having some problems while build
this package.

when I make `sbuild -s -A` I have errors like this:

dpkg-source: error: cannot represent change to data/pics/iwaAlles.xcf:
binary file contents changed

and warnings like this:
dpkg-source: warning: executable mode 0755 of 'data/pics/itrVorderrand.xpm'
will not be represented in diff

What is the meaning of it?

I create the repo on salsa for this package:
https://salsa.debian.org/eamanu-guest/cuyo

Thanks!
regards!

El mié., 13 de feb. de 2019 a la(s) 09:52, eamanu15 (
emmanuelaria...@gmail.com) escribió:

> Hi,
>
>
> El sáb., 9 de feb. de 2019 a la(s) 08:45, Bernhard R. Link (
> brl...@debian.org) escribió:
>
>> Hi,
>>
>> any news on this one? Given the poor state the package is in,
>> do you have the resources for an upload before buster release?
>>
>> Otherwise I plan to request a removal from testing once
>> the soft freeze started (as autoremoval via #916691 did
>> not happen).
>>
>
> I requested the source on salsa but I have not response, and sincerely
> I forgot this track.
>
> Today, I will work on ITA this package. Sorry and thanks
>
> Please can you sponsor me?
>
> Regards!
>
>>
>> Bernhard R. Link
>> --
>> F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC
>>
>
>
> --
> Arias Emmanuel
> http://eamanu.com
> Github/Gitlab; @eamanu
> Debian: @eamanu-guest
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#902722: beep: CVE-2018-1000532

[Axel Beckert]

Hi Moritz,

Moritz Mühlenhoff wrote:
> > Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000532
> 
> There's now a new release/fork:
> https://github.com/johnath/beep/issues/11#issuecomment-454056858

Thanks for that hint.

FTR: Rhonda and me are on it.

Packaging has moved over to https://salsa.debian.org/rhonda/beep and a
partially packaged 1.4.3 is currently in
https://salsa.debian.org/rhonda/beep/tree/debian-1.4.3

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#922273: [hexchat] Thread 1 closes for missing raise.c

[Synthea]

Package: hexchat
Version: 2.14.2-3~bpo9+1
Severity: important

Noticed this problem while running hexchat in gdb
Thread 1 "hexchat" received signal SIGTERM, Terminated.
raise (sig=15) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-5-amd64

Debian Release: 9.5
  500 stable-updates  deb.debian.org 
  500 stable  security.debian.org 
  500 stable  repo.skype.com 
  500 stable  dl.google.com 
  500 stable  deb.debian.org 
  500 newstable   deb.i2p2.de 
  100 stretch-backports deb.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-
hexchat-common (= 2.14.2-3~bpo9+1) | 2.14.2-3~bpo9+1
libc6(>= 2.14) | 
libcanberra0  (>= 0.2) | 
libdbus-glib-1-2 (>= 0.88) | 
libgdk-pixbuf2.0-0 (>= 2.25.2) | 
libglib2.0-0   (>= 2.35.9) | 
libgtk2.0-0(>= 2.24.0) | 
libnotify4  (>= 0.7.0) | 
libpango-1.0-0 (>= 1.29.4) | 
libproxy1v5(>= 0.4.14) | 
libssl1.1   (>= 1.1.0) | 
libx11-6   | 


Recommends   (Version) | Installed
==-+-===
hexchat-perl   | 2.12.4-3
hexchat-plugins| 2.12.4-3
hexchat-python3| 2.12.4-3
libglib2.0-bin | 2.50.3-2


Suggests (Version) | Installed
==-+-===
hexchat-otr| 
unifont| 





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

Bug#922274: thinkpad_acpi: Error probing battery 2 (Lenovo Thinkpad Yoga 11e)

[Daniel Leidert]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since some time I get these error messages during startup (however, the system
starts without any issue):

[   31.210320] ACPI: \_SB_.PCI0.LPCB.EC__.HKEY: BCTG evaluated but flagged as 
error
[   31.210325] thinkpad_acpi: Error probing battery 2
[   31.210462] battery: error in extension, unloading: ThinkPad Battery 
Extension
[   31.210468] battery: extension unregistered: ThinkPad Battery Extension
[   31.210545] battery: ACPI: Battery Slot [BAT1] (battery present)

Searching for this issue I found these resources:

https://patchwork.kernel.org/patch/10552407/
https://bbs.archlinux.org/viewtopic.php?id=238170

I haven't checked, if the suggested patch has already been accepted into
the kernel. If yes, my model is probably missing. So maybe this information
helps, to fix the kernel to fix the issue on my system too:

[   29.593658] thinkpad_acpi: ThinkPad ACPI Extras v0.26
[   29.593661] thinkpad_acpi: http://ibm-acpi.sf.net/
[   29.593663] thinkpad_acpi: ThinkPad BIOS N15ET75W (1.35), EC unknown
[   29.593664] thinkpad_acpi: Lenovo ThinkPad Yoga 11e, model 20DA001CUK
[   29.625754] thinkpad_acpi: radio switch found; radios are enabled
[   29.629774] thinkpad_acpi: Tablet mode switch found (type: GMMS), currently 
in laptop mode
[   29.630080] thinkpad_acpi: This ThinkPad has standard ACPI backlight 
brightness control, supported by the ACPI video driver
[   29.630082] thinkpad_acpi: Disabling thinkpad-acpi brightness events by 
default...
[   29.640950] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is 
unblocked
[   29.641331] thinkpad_acpi: Standard ACPI backlight interface available, not 
loading native one
[   29.641473] thinkpad_acpi: Console audio control enabled, mode: monitor 
(read only)
[   29.680689] input: ThinkPad Extra Buttons as 
/devices/platform/thinkpad_acpi/input/input10
[   31.210325] thinkpad_acpi: Error probing battery 2

If I can provide useful input to fix the situation, please let me know.

Regards, Daniel


- -- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20DA001CUK
product_version: ThinkPad Yoga 11e
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: N15ET75W (1.35)
board_vendor: LENOVO
board_name: Intel powered classmate PC
board_version: SDK0E50510 PRO

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Series SoC Transaction Register [8086:0f00] (rev 0e)
Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx Series SoC Transaction 
Register [17aa:2224]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:13.0 SATA controller [0106]: Intel Corporation Atom Processor E3800 Series 
SATA AHCI Controller [8086:0f23] (rev 0e) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo Atom Processor E3800 Series SATA AHCI Controller 
[17aa:2224]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:14.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx, 
Celeron N2000 Series USB xHCI [8086:0f35] (rev 0e) (prog-if 30 [XHCI])
Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series 
USB xHCI [17aa:2224]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor 
Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18] (rev 0e)
Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx Series Trusted Execution 
Engine [17aa:2224]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:1b.0 Audio device [0403]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Series High Definition Audio Controller [8086:0f04] (rev 0e)
Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx Series High Definition 
Audio Controller [17aa:2224]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
E

Bug#921136: lintian: hardening-no-fortify-functions possible false positive

[Scott Talbert]

On Wed, 13 Feb 2019, Chris Lamb wrote:


I can confirm this. Yes, it does look like these are some sort of
auto-generated C++ function. However, is there any reason why these
should not be subject to hardening too? If they should, then either
we are missing some kind of compiler/linker flag or perhaps even
these functions are being generated incorrectly (!).

If not, then we need to discover how to detect such functions and
ignore them in this Lintian check.


Decoding the function name with c++filt reveals:

$ c++filt 
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPKwEEvT_S8_St20forward_iterator_tag
void std::__cxx11::basic_string, 
std::allocator >::_M_construct(wchar_t const*, 
wchar_t const*, std::forward_iterator_tag)


I really don't understand C++ templates very well, but grepping around the 
system includes directory, I have a hunch this might be the wmemcpy in 
question:

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/char_traits.h#L477

Scott

Bug#922272: irssi-plugin-otr: trying to overwrite '/usr/share/irssi/help/otr', which is also in package irssi 1.2.0-1

[Axel Beckert]

Package: irssi-plugin-otr
Version: 1.2.0-1
Severity: serious

Hi Rhonda,

unfortunately the file moving between irssi and irssi-plugin-otr doesn't
seem to completely fixed yet. When upgrading them from 1.2.0-1 to
1.2.0-2, I get:

Preparing to unpack .../04-irssi-plugin-otr_1.2.0-2_amd64.deb ...
Unpacking irssi-plugin-otr (1.2.0-2) over (1.2.0-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-dVLCdE/04-irssi-plugin-otr_1.2.0-2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/irssi/help/otr', which is also in package 
irssi 1.2.0-1
Preparing to unpack .../05-irssi_1.2.0-2_amd64.deb ...
Unpacking irssi (1.2.0-2) over (1.2.0-1) ...

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

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

Versions of packages irssi-plugin-otr depends on:
ii  irssi1.2.0-2
ii  libc62.28-7
ii  libgcrypt20  1.8.4-5
ii  libotr5  4.1.1-3

irssi-plugin-otr recommends no packages.

irssi-plugin-otr suggests no packages.

-- no debconf information

Bug#880245: statsmodels

[Yaroslav Halchenko]

Sorry for being allow to respond... Please do what you need to do

On February 13, 2019 5:47:41 PM EST, "Rebecca N. Palmer" 
 wrote:
>On 13/02/2019 09:10, Andreas Tille wrote:
>> Any volunteer to backport the relevant changes I pushed to Git right
>now
>> to 0.8.0?
>
>I intend to try tomorrow, if the uploaders don't say anything first.
>
>> I'm actually wondering why the package did not got any removal
>> from testing warning (or did I missed something)?
>
>statsmodels is considered a key package (i.e. can't be autoremoved) 
>because of the statsmodels -> seaborn -> sphinx-gallery -> matplotlib 
>build-dependency chain.
>
>The autoremoval list (sorted by maintainer/team) is
>https://udd.debian.org/cgi-bin/autoremovals.cgi
>
>> PS: As a general note: We probably need more people dedicated to
>Debian
>> Science QA work.
>
>I guess that's sort of what I do (and if statsmodels and/or pandas were
>
>to become available, they are at least things I use).

Bug#782644: xscreensaver always rejects my password

[Tormod Volden]

Nicolas,

I see that you are using a French locale and so probably have a French
keyboard. Is it possible that the keyboard mapping becomes wrong, so
it would work if you typed your password as if you had an English
keyboard?

Best regards,
Tormod

On Sat, Feb 2, 2019 at 7:09 PM Nicolas Patrois wrote:
> I have the same bug but it’s worse: I did not launch xscreensaver by myself.
> I suspend the computer with the Moon key and when I wake it back, xscreensaver
> is launched and refuses my password.
> I can’t even kill it in a tty, Ctrl-Alt-Fx won’t work and ssh seems locked 
> too.
> I only can reboot.

Bug#920753: xscreensaver-data-extra: trouble with glitchpeg.desktop

[Tormod Volden]

tag 920753 pending
thanks

On Mon, Jan 28, 2019 at 7:33 PM Patrice Duroux wrote:
> Could you please consider this:
> https://salsa.debian.org/debian/xscreensaver/merge_requests/1
> or I am wrong to solve the trouble with this desktop file?

Thanks, I have applied your fix.

Best regards,
Tormod

Bug#922268: rxvt-unicode: tabbed extension segfaults

[gregor herrmann]

On Wed, 13 Feb 2019 17:12:10 -0500, Ryan Kavanagh wrote:

> On Wed, Feb 13, 2019 at 10:31:44PM +0100, gregor herrmann wrote:
> > After upgrading to 9.22-5, urxvt -pe tabbed just leads to a segfault.
> > Downgrading to 9.22-4+b1 helps.
> I am unable to reproduce this. Could you please submit a backtrace?

Here we go:

% gdb /usr/bin/rxvt
…
(gdb) run -pe tabbed
Starting program: /usr/bin/rxvt -pe tabbed
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 6100]

Program received signal SIGSEGV, Segmentation fault.
rxvt_term::lookup_color (this=0x55e344fef090, color=33554150, 
color@entry=33554426, table=) at screen.C:656
656 screen.C: No such file or directory.
(gdb) bt full
#0  0x55e33c8cb23a in rxvt_term::lookup_color(unsigned int, rxvt_color*) 
(this=0x55e344fef090, color=33554150, 
color@entry=33554426, table=) at screen.C:656
#1  0x55e33c8cb96d in rxvt_term::lookup_color(unsigned int, rxvt_color*)
(this=, color=color@entry=33554426, table=) 
at screen.C:654
#2  0x55e33c8c30e5 in rxvt_font_xft::draw(rxvt_drawable&, int, int, 
unsigned int const*, int, int, int)
(this=0x55e34547aa30, d=..., x=42, y=0, text=, 
len=, fg=10, bg=33554426) at rxvtfont.C:1471
d2 = @0x55e345483870: {screen = 0x55e344ff15b8, drawable = 81788963, 
xftdrawable = 0x0}
dst = 
extents = {width = 3, height = 8, x = -1, y = 8, xOff = 3, yOff = 0}
enc = 0x55e34525b7c0
ep = 0x55e34525b7c8
disp = 0x55e344ffdb10
gc = 0x55e34546c000
w = 7
h = 13
buffered = true
x_ = 
y_ = 
#3  0x55e33c8bd93b in rxvt_term::scr_refresh() 
(this=this@entry=0x55e344fef090) at screen.C:2451
count = 
xpixel = 42
fore = 10
rend = 18436610974346641410
text = 0x7f51ad3eeb80
back = 33554426
font = 0x55e34547aa30
stp = 0x7f51ad3eeb68
srp = 0x7f51ad3eedc0
dtp = 0x7f51ad3a8668
drp = 0x7f51ad3a88c0
ypixel = 0
col = 6
row = 0
ocrow = 
i = 
ccol1 = 
ccol2 = 
cur_rend = 
cur_col = 
cursorwidth = 
old_screen_flags = 4
have_bg = false
showcursor = 
#4  0x55e33c8bf578 in rxvt_term::flush() (this=0x55e344fef090) at 
command.C:1006
#5  0x55e33c8da75c in ev_invoke_pending() () at ./../libev/ev.c:3288
p = 
#6  0x55e33c8dbbe3 in ev_run(int) (flags=flags@entry=0) at 
./../libev/ev.c:3688
#7  0x55e33c8b9fe3 in main(int, char**) (argc=3, argv=0x7fff245d8108) at 
rxvt.C:38
t = 0x55e344fef090
(gdb) 


Does this help?


Cheers,
gregor


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


signature.asc
Description: Digital Signature

Bug#807671: 20copyfiles doesn't cope well with absolute symlinks in destination path

[Florian Schlichting]

this is now https://gitlab.com/codelibre/schroot/merge_requests/20 and
was merged to master two years ago.

However, this still doesn't fix the issue I face when entering a schroot
of main system, with

/etc/resolv.conf -> /run/NetworkManager/resolv.conf

$ schroot -c thinkpad -u root
E: 20copyfiles: realpath: 
/run/schroot/mount/thinkpad-7b8f67af-f952-4f84-be1d-07ef66e9249a/run/NetworkManager/resolv.conf:
 No such file or directory
E: 20copyfiles: cp: cannot create regular file '': No such file or directory
E: thinkpad-7b8f67af-f952-4f84-be1d-07ef66e9249a: Chroot setup failed: 
stage=setup-start

BTW without that patch, it looks like this:

$ schroot -c thinkpad -u root
E: 20copyfiles: cp: '/etc/resolv.conf' and 
'/var/run/schroot/mount/thinkpad-fe82a8ce-cf15-4cbb-928c-dfabea3eebbd/etc/resolv.conf'
 are the same file
E: thinkpad-fe82a8ce-cf15-4cbb-928c-dfabea3eebbd: Chroot setup failed: 
stage=setup-start

Bug#920673: firefox alsa

[Mike Hommey]

On Wed, Feb 13, 2019 at 04:41:28PM -0500, Erik Dobák wrote:
> Hi Mike,
> 
> how was it fixed?
> 
> i cant find an alternative alsa/firefox package when searching:

The firefox package itself has support for alsa.

Bug#880245: statsmodels

[Rebecca N. Palmer]

On 13/02/2019 09:10, Andreas Tille wrote:

Any volunteer to backport the relevant changes I pushed to Git right now
to 0.8.0?


I intend to try tomorrow, if the uploaders don't say anything first.


I'm actually wondering why the package did not got any removal
from testing warning (or did I missed something)?


statsmodels is considered a key package (i.e. can't be autoremoved) 
because of the statsmodels -> seaborn -> sphinx-gallery -> matplotlib 
build-dependency chain.


The autoremoval list (sorted by maintainer/team) is
https://udd.debian.org/cgi-bin/autoremovals.cgi


PS: As a general note: We probably need more people dedicated to Debian
Science QA work.


I guess that's sort of what I do (and if statsmodels and/or pandas were 
to become available, they are at least things I use).

Bug#902174: #902174: RFP: mes

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

Hi!

I have resurrected the debian package descriptions for Nyacc,
MesCC-tools and Mes, and updated them to the latest versions.

It would be great if you could take a look at them.

The descriptions are available on a `wip-debian' branch for

https://gitlab.com/janneke/nyacc
https://gitlab.com/janneke/mescc-tools
https://gitlab.com/janneke/mes   # for convenience, canonical git at
  https://git.savannah.gnu.org/git/mes.git

Meanwhile a lot has happened with Mes: it has become a GNU package and
now drives the Reduced Binary Seed bootstrap of the GNU Guix system, see
http://joyofsource.com/reduced-binary-seed-bootstrap.html

Anyway, the latest release of Mes (v0.19) does not build and install
well on Debian; so you'll need not only the debian/ directory for Mes
but also the state of the git archive it lives in.  If that's a problem
we can do a 0.19.1 release -- we're expecting a nice 0.20 release within
a month or so.

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Bug#918067: Wrong pulseaudio profile set in patch

[Felipe Sateler]

Hi,

On Thu, Feb 7, 2019 at 6:30 PM Jan Graichen  wrote:

> Package: pulseaudio
> Version: 12.2-3
> Followup-For: Bug #918067
>
> Dear Maintainer,
>
> the patch seems to set the wrong pulseaudio profile for the new IDs and
> the Arctis Pro Wireless. It tries to load the file
>
>   steelseries-arctis-7-usb-audio.conf
>
> while the shipped file is named
>
>   steelseries-arctis-usb-audio.conf
>
> Just renaming the profile or changing the udev rules does work.
>
>
Could you send a (tested) patch please? Ideally on salsa. I'm extremely low
on time so any help would be appreciated.

-- 

Saludos,
Felipe Sateler

Bug#922190: Fwd: Bug#922190: netbeans: Illegal reflective access by org.netbeans.core.windows.view.ui.MainWindow

[Gustavo Castro]

hi Markus

Thank you very much for answering

uninstall openjdk-11, and the flaw remains
dpkg -l | grep openjdk
ii  openjdk-10-jdk:amd64
10.0.2+13-2  amd64OpenJDK Development Kit
(JDK)
ii  openjdk-10-jdk-headless:amd64
10.0.2+13-2  amd64OpenJDK Development Kit
(JDK) (headless)
ii  openjdk-10-jre:amd64
10.0.2+13-2  amd64OpenJDK Java runtime,
using Hotspot JIT
ii  openjdk-10-jre-headless:amd64
10.0.2+13-2  amd64OpenJDK Java runtime,
using Hotspot JIT (headless)
ii  openjdk-8-jdk:amd64
8u191-b12-2  amd64OpenJDK Development Kit
(JDK)
ii  openjdk-8-jdk-headless:amd64
8u191-b12-2  amd64OpenJDK Development Kit
(JDK) (headless)
ii  openjdk-8-jre:amd64
8u191-b12-2  amd64OpenJDK Java runtime,
using Hotspot JIT
ii  openjdk-8-jre-headless:amd64
8u191-b12-2  amd64OpenJDK Java runtime,
using Hotspot JIT (headless)


WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.netbeans.core.windows.view.ui.MainWindow
(jar:file:/usr/share/netbeans/10.0/platform/modules/org-netbeans-core-windows.jar!/)
to field sun.awt.X11.XToolkit.awtAppClassName
WARNING: Please consider reporting this to the maintainers of
org.netbeans.core.windows.view.ui.MainWindow
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release

I add more bug information
rg.netbeans.InvalidException: StandardModule:org.netbeans.modules.db
jarFile: /usr/share/netbeans/10.0/ide/modules/org-netbeans-modules-db.jar:
java.lang.UnsupportedClassVersionError: org/netbeans/lib/ddl/DBConnection
has been compiled by a more recent version of the Java Runtime (class file
version 55.0), this version of the Java Runtime only recognizes class file
versions up to 54.0

java.lang.SecurityException: sealing violation
at org.netbeans.JarClassLoader.doLoadClass(Unknown Source)
at org.netbeans.ProxyClassLoader.selfLoadClass(Unknown Source)
at org.netbeans.ProxyClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:291)
at org.netbeans.modules.java.source.NoJavacHelper.hasNbJavac(Unknown
Source)
at
org.netbeans.modules.java.source.usages.BuildArtifactMapperImpl.isCompileOnSaveSupported(Unknown
Source)
at
org.netbeans.api.java.source.BuildArtifactMapper.isCompileOnSaveSupported(Unknown
Source)
at
org.netbeans.modules.java.j2seproject.J2SEProjectUtil.isCompileOnSaveSupported(Unknown
Source)
at
org.netbeans.modules.java.j2seproject.J2SEProjectUtil.isCompileOnSaveEnabled(Unknown
Source)
at
org.netbeans.modules.java.j2seproject.J2SEProject$CoSAwareFileBuiltQueryImpl.setCoSEnabledAndXor(Unknown
Source)
at
org.netbeans.modules.java.j2seproject.J2SEProject$CoSAwareFileBuiltQueryImpl.(Unknown
Source)
at
org.netbeans.modules.java.j2seproject.J2SEProject.createLookup(Unknown
Source)
at org.netbeans.modules.java.j2seproject.J2SEProject.(Unknown
Source)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488)
at
org.netbeans.modules.project.ant.AntBasedGenericType.createProject(Unknown
Source)
at
org.netbeans.modules.project.ant.AntBasedProjectFactorySingleton.loadProject(Unknown
Source)
at
org.netbeans.modules.projectapi.nb.NbProjectManager.createProject(Unknown
Source)
at
org.netbeans.modules.projectapi.nb.NbProjectManager.access$300(Unknown
Source)
at org.netbeans.modules.projectapi.nb.NbProjectManager$2.run(Unknown
Source)
at org.netbeans.modules.projectapi.nb.NbProjectManager$2.run(Unknown
Source)
at
org.netbeans.modules.openide.util.DefaultMutexImplementation.readAccess(Unknown
Source)
at org.openide.util.Mutex.readAccess(Unknown Source)
at
org.netbeans.modules.projectapi.nb.NbProjectManager.findProject(Unknown
Source)
at org.netbeans.api.project.ProjectManager.findProject(Unknown Source)
at
org.netbeans.modules.project.ui.OpenProjectList.fileToProject(Unknown
Source)
at org.netbeans.modules.project.ui.actions.OpenProject$1.run(Unknown
Source)
at org.openide.util.RequestProcessor$Task.run(Unknown Source)
at org.netbeans.modules.openide.util.GlobalLookup.execute(Unknown
Source)
[catch] at org.openide.util.lookup.Lookups.executeWith(Unknown Source)
at org.

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Francesco Poli]

On Wed, 13 Feb 2019 19:39:25 +0100 Michael Biebl wrote:

> Am 09.02.19 um 23:26 schrieb Francesco Poli:
[...]
> > regarding my search for a command that works like s6-setuidgid, but
> > runs the given command inside the user's login shell (with all the
> > environment that the user would get on a normal login).
> 
> Aren't those conflicting requirements?
> On the one hand you want a full login shell, which typically involves
> PAM. On the other hand you don't want PAM involved.

Maybe you are right, I haven't yet searched for this hypothetical tool
too diligently...

[...]
> > Maybe setpriv is equivalent to s6-setuidgid.
> > If this is the case, it can be used as an alternative to s6-setuidgid.
> 
> setpriv should do pretty much the same as s6-setuidgid, with the benefit
> of not requiring an exotic package being installed.
> 
> > But I would like to have a command that runs a given command inside the
> > regular user's login environment, as I said above.
> > Do you know one such command?
> 
> What exactly do you mean by "user's login environment"?

I am dreaming about the possibility to find the environment variables
that the impersonated regular user sets in his/her own login shell
initialization files, to find his/her favorite web browser (via
sensible-browser or xdg-open) and, perhaps, connecting to the X server
running his/her graphical session (if any) and launching the web
browser (say, firefox) attaching to the running instance (if any).

Maybe all this is too good to be possible, but still...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgphu3CPiNwiq.pgp
Description: PGP signature

Bug#921382: kineticstools: autopkgtest needs update for new version of h5py

[Andreas Tille]

Hi Paul,

On Tue, Feb 12, 2019 at 10:58:16PM +0100, Paul Gevers wrote:
> On 12-02-2019 14:29, Andreas Tille wrote:
> > thanks a lot for this bug report.  I'd love to fix this but I have no
> > idea what to do.  Any hint from h...@packages.debian.org ?
> 
> I don't want to offend you,

You don't. ;-)

> but did you look at the error message? I
> think it tells you what to do: "dataset.value has been deprecated. Use
> dataset[()] instead". I assume you should replace calls like
> dataset.value() with dataset[()].

The thing is that there is no dataset.value in kineticstools source.
I checked

   grep -Rw "\.value"

in the source repository which is empty.
 
> If you really don't know how to fix the issue, I guess you could reduce
> the log-level in your test cases.

OK, I tried

diff --git a/debian/rules b/debian/rules
index c425a85..7c443c9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -27,3 +27,10 @@ override_dh_auto_install:
rst2man doc/manual.rst > $(MANDIR)/man1/ipdSummary.1
mkdir -p debian/kineticstools-data/usr/share/kineticstools
mv 
debian/python-kineticstools/usr/lib/python2.7/dist-packages/kineticsTools/resources
 debian/kineticstools-data/usr/share/kineticstools/
+
+override_dh_auto_test:
+#ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+   # FIXME: This should be deactivated once bug #921382 is solved
+   find test/cram -type f -name "*.t" -exec sed -i 
's/--log-level=WARNING/--log-level=DEBUG/' \{\} \;
+   dh_auto_test
+#endif

but it is not really more enlightening. 

> Remember, you are blocking h5py from migrating with your autopkgtest.

Thus I was asking for help since I do not have the slightest idea about
h5py and we just lost the original Uploader.  I simply try to do my best
but it is not sufficient. :-(

Kind regards

   Andreas.


-- 
http://fam-tille.de

Bug#922271: camomile: ocaml-gettext build still fails, due to wrong search path caused by camomile build

[Hilko Bengen]

Source: camomile
Version: 1.0.1-2
Severity: grave

Dear Maintainer,

I just had a look at the still-failing builds of ocaml-gettext/0.3.7-1
with the pacakges produced by camomile/1.0.1-2. The logs don't show a
lot, just a Not_found exception:

,[ 
https://buildd.debian.org/status/fetch.php?pkg=ocaml-gettext&arch=armel&ver=0.3.7-1%2Bb3&stamp=1549887522&raw=0
 ]
| make[2]: Entering directory '/<>/po'
| /<>/_build/bin/ocaml-gettext --action compile \
| --compile-output fr.mo fr.po
| Fatal error: exception Not_found
| make[2]: *** [Makefile:50: fr.mo] Error 2
| make[2]: Leaving directory '/<>/po'
| make[1]: *** [Makefile:28: all] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [/usr/share/cdbs/1/class/makefile.mk:77: 
debian/stamp-makefile-build] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2
`

I was able to reproduce this error in a sid-amd64 chroot. Running
_build/bin/ocaml-gettext using strace shows that it goes looking for
general_category.mar in the directory that was used for installation on
the buildhost where camomile was being built:

,
| execve("_build/bin/ocaml-gettext", ["_build/bin/ocaml-gettext"], 
0x7fffaee13180 /* 23 vars */) = 0
:
: ...
:
| readlink("/proc/self/exe", 
"/home/bengen/src/deb/ocaml-gettext/_build/bin/ocaml-gettext", 256) = 59
| stat("/home/bengen/src/deb/ocaml-gettext/_build/bin/ocaml-gettext", 
{st_mode=S_IFREG|0755, st_size=3062688, ...}) = 0
| lseek(0, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
| mmap(NULL, 794624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f2d65c49000
| brk(0x5559f5984000) = 0x5559f5984000
| lseek(1, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
| lseek(2, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
| mmap(NULL, 532480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f2d65bc7000
| mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f2d65b86000
| openat(AT_FDCWD, 
"/build/camomile-1.0.1/debian/tmp/usr/share/database/general_category.mar", 
O_RDONLY) = -1 ENOENT (No such file or directory)
| write(2, "Fatal error: exception Not_found\n", 33) = 33
| exit_group(2)   = ?
| +++ exited with 2 +++
`

Cheers,
-Hilko

Bug#922259: python-libnacl: FTBFS randomly (ValueError: byte must be in range(0, 256))

[Santiago Vila]

severity 922259 important
retitle 922259 python-libnacl: FTBFS randomly (ValueError: byte must be in 
range(0, 256))
thanks

I tested again in my autobuilders and this is "only" random, so I'm
downgrading from serious, but please note that this randomness also
happens in reproducible-builds.

(I hope this is fixed before the release of buster anyway. Trying to
build a package and having a successful build only sometimes is quite
annoying for the end user)

Thanks.

Bug#922268: rxvt-unicode: tabbed extension segfaults

[Ryan Kavanagh]

Control: tags -1 + unreproducible moreinfo

On Wed, Feb 13, 2019 at 10:31:44PM +0100, gregor herrmann wrote:
> After upgrading to 9.22-5, urxvt -pe tabbed just leads to a segfault.
> Downgrading to 9.22-4+b1 helps.

I am unable to reproduce this. Could you please submit a backtrace?

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#914794: Please upload fix for #914794 (libmspack fails tests on big endian architectures (s390x, mips))

[Jens Reyer]

Hi,

libmspack in unstable fixes a bug in cabextract (#914263
cabextract: -F option doesn't work correctly.) which affects winetricks.
 But cabextract and libmspack don't migrate because of this bug here.

This issue is already fixed upstream, but afaics not released yet.  Do
you know if this will happen soon, or may you consider uploading a fixed
version with the commits from upstream cherrypicked?

Debian buster is already in soft-freeze, so it would be best to have
this resolved in February.

Thanks in advance, also to upstream who seems to be reading this here!

Greets
jre

Bug#922269: x11-utils: X do not triggers the screensaver

[Nicolas Évrard]

Package: x11-utils
Version: 7.7+4
Severity: normal

Hello,

I noticed that my screensaver is not triggered anymore after the
default timeout yet I can activate it through "xset s activate".

It tried the following:

nicoe@mirabelle:~% while true; do
echo `xssstate -i` `xssstate -t` `xssstate -s`
sleep 10
done

Here's the result:

7 29983 off
9941 20054 off
19959 10036 off
29978 17 off
39997 0 off
50016 0 off

What's strange is that the timeout reach zero but the state of the
screensaver stays on "off".

I am not sure the bug resides in this package to be honest but since
xset sets user preferences for X it might be related.


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.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 x11-utils depends on:
ii  libc6   2.28-7
ii  libfontconfig1  2.13.1-2
ii  libfontenc1 1:1.1.3-1+b2
ii  libfreetype62.9.1-3
ii  libgl1  1.1.0-1
ii  libx11-62:1.6.7-1
ii  libx11-xcb1 2:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxcb-shape0   1.13.1-2
ii  libxcb1 1.13.1-2
ii  libxcomposite1  1:0.4.4-2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  libxi6  2:1.7.9-1
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2
ii  libxmuu12:1.1.2-2
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.1.5-1
ii  libxtst62:1.2.3-1
ii  libxv1  2:1.0.11-1
ii  libxxf86dga12:1.1.4-1+b3
ii  libxxf86vm1 1:1.1.4-1+b2

x11-utils recommends no packages.

Versions of packages x11-utils suggests:
pn  mesa-utils  

-- no debconf information

Bug#922270: kmail - "Name" column in message window can not made smaller

[Hans-J. Ullrich]

Package: kmail
Version: 4:18.08.1-1
Severity: minor

Dear Maintainer,

I got into a minor problem. In the window (where the "Kmail-folder", "Inbox", 
"Sent" etc. folders appear), it is not possible, to resize the firs column 
(called "name").

The first column is very, very, very large and on the buttom of the window 
there appeared a slider. 

I did not find any way, to get rid of this (slider and get smaller column).

The other columns, which can be added, like "unread mails", can be resized.

I believe, this might be a bug. Thank you for reading this, any help is very 
welcome.

Best regards

Hans 

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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.1-1+b2
ii  kdepim-runtime   4:18.08.1-1
ii  kio  5.54.1-1
ii  libc62.28-6
ii  libgcc1  1:8.2.0-16
ii  libgpgmepp6  1.12.0-6
ii  libkf5akonadiagentbase5  4:18.08.1-1+b2
ii  libkf5akonadicontact54:18.08.1-1
ii  libkf5akonadicore5abi2   4:18.08.1-1+b2
ii  libkf5akonadimime5   4:18.08.1-2
ii  libkf5akonadisearch-bin  4:18.08.1-1+b1
ii  libkf5akonadisearch-plugins  4:18.08.1-1+b1
ii  libkf5akonadisearchdebug54:18.08.1-1+b1
ii  libkf5akonadisearchpim5  4:18.08.1-1+b1
ii  libkf5akonadiwidgets5abi14:18.08.1-1+b2
ii  libkf5bookmarks5 5.54.0-1
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5calendarutils5 4:18.08.3-1
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1
ii  libkf5configgui5 5.54.0-1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5followupreminder5  4:18.08.1-1
ii  libkf5grantleetheme-plugins  18.08.3-1
ii  libkf5gravatar5abi2  4:18.08.1-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5identitymanagement518.08.3-1
ii  libkf5itemmodels55.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5kontactinterface5  18.08.3-1
ii  libkf5ksieveui5  4:18.08.1-1
ii  libkf5libkdepim-plugins  4:18.08.1-1
ii  libkf5libkdepim5 4:18.08.1-1
ii  libkf5libkdepimakonadi5  4:18.08.1-1
ii  libkf5libkleo5   4:18.08.3-1
ii  libkf5mailcommon5abi24:18.08.1-1
ii  libkf5mailtransport5 18.08.1-2
ii  libkf5mailtransportakonadi5  18.08.1-2
ii  libkf5messagecomposer5abi1   4:18.08.1-1+b1
ii  libkf5messagecore5abi1   4:18.08.1-1+b1
ii  libkf5messagelist5abi1   4:18.08.1-1+b1
ii  libkf5messageviewer5abi1 4:18.08.1-1+b1
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5mimetreeparser5abi14:18.08.1-1+b1
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5pimcommon5abi2 4:18.08.1-1
ii  libkf5pimcommonakonadi5abi1  4:18.08.1-1
ii  libkf5pimtextedit5abi2   18.08.3-1
ii  libkf5sendlater5 4:18.08.1-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5sonnetui5  5.54.0-1
ii  libkf5templateparser54:18.08.1-1+b1
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5tnef5  4:18.08.3-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5webengineviewer5abi1   4:18.08.1-1+b1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libqgpgme7   1.12.0-6
ii  libqt5core5a 5.11.3+dfsg-2
ii  libqt5dbus5  5.11.3+dfsg-2
ii  libqt5gui5   5.11.3+dfsg-2
ii  libqt5network5   5.11.3+dfsg-2
ii  libqt5widgets5   5.11.3+dfsg-2
ii  libqt5xml5   5.11.3+dfsg-2
ii  libstdc++6   8.2.0-16

Versions of packages kmail recommends:
ii  accountwizard   4:18.08.1-1
ii  gnupg   2.2.12-1
ii  kdepim-addons   18.08.1-1
ii  kdepim-themeedito

Bug#908879: pyparted: FTBFS randomly (ImportError: No module named _ped)

[Herbert Fortes]

Hi Santiago,

On 2/13/19 2:28 PM, Santiago Vila wrote:
> found 908879 3.11.1-12
> thanks
> 
> Sorry for the reopening but this problem is here again.
> I've put a bunch of build logs here:
> 
> https://people.debian.org/~sanvila/build-logs/pyparted/
> 
> and this problem also happens (randomly) in reproducible-builds:
> 
> https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/pyparted_3.11.2-5.rbuild.log.gz
> 
> If you need a test machine where this happens, please contact me
> privately and I will gladly provide one.
> 

No problem. It was expected. I had this
'undefined symbol: _Py_ZeroStruct' error
here in my notebook. But I decided to 
confirm doing the upload.

I received a bugreport with a patch and
asking to enable build-time tests again.

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




Regards,
Herbert

Bug#922243: mailman3-full : Depends: mailman3 but it is not going to be installed

[Pierre-Elliott Bécue]

Le mercredi 13 février 2019 à 18:07:39+0100, kenokenobingo a écrit :
> Package: mailman3-full
> Severity: normal
> 
> Dear Maintainer,
> 
> there are problems with the dependencies while trying to install 
> `mailman3-full` via aptitutde.
> 
> The following packages have unmet dependencies:
>  mailman3-full : Depends: mailman3 but it is not going to be installed
>   Depends: mailman3-web (>= 0+20180916-1) but it is not going 
> to be installed
>  Depends: python3-mailman-hyperkitty but it 
> is not going to be installed
>  E: Unable to correct problems, you have held 
> broken packages.
> 
> -- System Information:
> Debian Release: 9.7
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
> 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)

Hi,

I'll need a little more input regarding the available mirrors for your
system. My bet would be that your package manager doesn't try to fetch
all the dependencies from the backports when they fail to be resolved in
stretch.

Best regards,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#922268: rxvt-unicode: tabbed extension segfaults

[gregor herrmann]

Package: rxvt-unicode
Version: 9.22-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

After upgrading to 9.22-5, urxvt -pe tabbed just leads to a segfault.
Downgrading to 9.22-4+b1 helps.

Cheers,
gregor

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.5.46
ii  libc6 2.28-7
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.2.0-20
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.58.3-1
ii  libperl5.28   5.28.1-4
ii  libstartup-notification0  0.12-6
ii  libx11-6  2:1.6.7-1
ii  libxft2   2.3.2-2
ii  libxrender1   1:0.9.10-1
ii  ncurses-base  6.1+20181013-2
ii  ncurses-term  6.1+20181013-2

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu2.37-1
pn  fonts-vlgothic | fonts-japanese-gothic  

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.12

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlxkjLxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbvLA//Stgv8sZfEgEUEHh0MiQtD3J6wP54bEwkZbhxviRoeJS9Tdyhrse9OoCj
0nbOkKuqyeTEMjlYvLTFkTR43TmKiUxUltFzIkqfzchEhuFm0ayrsZ1gcrGfUN5G
2rDUEFhG4VYPhK534FikG8BPTQzMCbjnq8OWGHTOUJ6wXun5iP7VoozGz9/j/47O
10KUJi6RUlhaJkvFD4fA8KkaQnkMM9gkgukqQMzdaRY05Z0WmPyJd8pc93O+OAF9
RE+ctUPDi5K8ptnxQLrLxXvfQbiUHdhB1SSozY4SkYzEJK6H53f117ur9NKhow/F
sGuCbkVnKozivkLplart/CtisyzwBYMTY3s8wtcMnqT1iUqPdsngPm6w55W9yOVN
+v42wrtUDWbb5yRNX7VbzDeWIvr8NXm2IqEsQlubod62Mmw1qK4Gn1wnWGZY9JSF
CdSlGbs4Cd2Mq8O37NrYunpPitiLzPlWRKdHjmnlSYYt715HdLFylu7T5Kn+l4B4
/bP5tLPLIlJV40TeFMCrTYVUy76h7lquUM87XEnTxxKyGP34avqdrx53xpXdVc34
/UZcFHMW+W3BisrBiEHNLl1gxfY0/vqLLIJGDCeFGoEMpiDTbuCNrs3V0XFROswN
MmaNUdZY3ojbUO4xOiCXOS7pux0Rf9T/JzBhQalArsKNY9MKNAM=
=PkFE
-END PGP SIGNATURE-

Bug#918206: Pandas new version (not?)

[Rebecca N. Palmer]

This builds (including build-time tests; haven't tried the autopkgtest).

Description: Fix np.array @ DataFrame matrix multiplication

Author: jbrockmendel
Origin: upstream 
https://github.com/pandas-dev/pandas/commit/ad2a14f4bec8a004b2972c12f12ed3e4ce37ff52

Bug-Debian: https://bugs.debian.org/918206
Forwarded: not-needed

--- a/pandas/core/generic.py
+++ b/pandas/core/generic.py
@@ -1602,6 +1602,7 @@ class NDFrame(PandasObject, SelectionMix
 # 
--

 # Array Interface

+__array_priority__ = 1000
 def __array__(self, dtype=None):
 return com._values_from_object(self)

--- a/pandas/tests/frame/test_analytics.py
+++ b/pandas/tests/frame/test_analytics.py
@@ -2283,8 +2283,11 @@ class TestDataFrameAnalytics(TestData):

 # np.array @ DataFrame
 result = operator.matmul(a.values, b)
+assert isinstance(result, DataFrame)
+assert result.columns.equals(b.columns)
+assert result.index.equals(pd.Index(range(3)))
 expected = np.dot(a.values, b.values)
-tm.assert_almost_equal(result, expected)
+tm.assert_almost_equal(result.values, expected)

 # nested list @ DataFrame (__rmatmul__)
 result = operator.matmul(a.values.tolist(), b)

Bug#922267: dh_missing reports missing files, though installed

[Christian Kastner]

Package: debhelper
Version: 12.1
Severity: normal

I just uploaded libmpikmeans_1.5+dfsg-6. During its build, I noticed
dh_missing report two files, even though they were installed.

With an override and dh_missing --fail-tmp, I get

  dh_missing: usr/bin/mpi_assign exists in debian/tmp but is not installed to 
anywhere
  dh_missing: usr/bin/mpi_kmeans exists in debian/tmp but is not installed to 
anywhere
  dh_missing: missing files, aborting

but these binaries have always been listed in
debian/mpikmeans-tools.install:
  mpi_kmeans usr/bin
  mpi_assign usr/bin

And they are installed correctly, eg `find debian -name mpi_kmeans`

  ./debian/tmp/usr/bin/mpi_kmeans
  ./debian/mpikmeans-tools/usr/bin/mpi_kmeans

Regards,
Christian

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

Kernel: Linux 4.19.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.1.1-1
ii  dpkg 1.19.4
ii  dpkg-dev 1.19.4
ii  dwz  0.12-3
ii  file 1:5.35-2
ii  libdpkg-perl 1.19.4
ii  man-db   2.8.5-2
ii  perl 5.28.1-4
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#919831: Javadoc -link makes broken links if module name matches package name

[Markus Koschany]

Hi,

Am 26.01.19 um 20:07 schrieb tony mancill:
[...]
> I'm trying to peel the onion and believe that this is a problem in the
> maven-javadoc-plugin package.  I found the same issue for a project
> outside of Debian, for example [1], which refers to a JIRA ticket for that
> plugin [2].  There is a commit [3] referencing that JIRA on the master
> branch of maven-javadoc-plugin.
> 
> I would like to try cherry-picking the fix onto our current version of
> maven-javadoc-plugin to see if it resolves our issue.  Or if that gets
> too complicated, we could look into updating to a snapshot of 3.1.0 (our
> version would 3.1.0~foo), since it looks like all of these commits will
> be part of 3.1.0 [4].
> 
> I'm not sure how much time I'll have to dedicate to this over the
> weekend and so would be happy if someone fixes it before I get to it.

I have updated the maven-javadoc-plugin package to the latest Git
snapshot and pushed the changes. An update of libplexus-languages-java
was also necessary (currently in experimental) and tony already took
care of it. I also had to add a compatibility patch for Debian's version
of maven-artifact-transfer. A new upstream release just because of some
minor refactoring seemed to be not the best way forward during the freeze.

Now I would have expected that libparanamer-java (#920750) just built
fine again but it doesn't. According to README.source in
maven-javadoc-plugin maven2-core (should be src:maven?) must be updated
as well. I'm not sure what button I have to press to make this work
right now. Any ideas?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#922240: ftp.debian.org: consider switching to merged pdiffs

[Joerg Jaspert]

On 15312 March 1977, Julian Andres Klode wrote:

It might make sense to consider switching to merged pdiffs, which generate
one Pdiff from each generation to the latest one. This can be done either
by preserving old index files and creating pdiffs from them, or simply by
concatenating the new pdiff to the old ones.


The code is in dak, generate_index_diffs.py - as soon as one gets me a
MR on salsa for it, we can have this.

Make it "just work", that is, when its merged, next run should just do
the right thing, and we are all happy. :)

--
bye, Joerg

Bug#921784: [Debichem-devel] Bug#921784: gromacs: FTBFS (ld returned 1 exit status)

[Santiago Vila]

severity 921784 important
thanks

I'm making this not serious until I have a test machine to which you
can ssh into and reproduce it.

(Stay tuned).

Thanks.

Bug#921784: [Debichem-devel] Bug#921784: gromacs: FTBFS (ld returned 1 exit status)

[Santiago Vila]

> > The build was made in my autobuilder with "dpkg-buildpackage -A"
> > and it also fails here:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gromacs.html
> > 
> > where you can get a full build log if you need it.
> 
> This is actually a different error.

Oops, yes, they are indeed different. Sorry for that.

So: Let's make this report to be the one about what I got in my
autobuilder (which I believe it's some kind of Makefile bug) and not
what happens in reproducible-builds.org (which seems to be
network-related).

I'm going to prepare a test machine where you can reproduce that one.
Please contact me privately for access details.

Thanks.

Bug#922266: kfreebsd-kernel-headers: ufs/ufs/quota.h uses uint32_t but doesn't include stdint.h

[Bas Zoetekouw]

Package: kfreebsd-kernel-headers
Severity: normal

It seems that some kfreebsd headers use exact-width integer types
(uint32_t and friends) but do not include stdint.h

This leads to build failures like this one 
https://buildd.debian.org/status/fetch.php?pkg=quotatool&arch=kfreebsd-amd64&ver=1%3A1.6.2-2&stamp=1549998565&raw=0

I'll work around it in my package by patching in the include by hand,
but this should probably be fixed, anyway.


As discussed on irc:

21:28  anyone got an idea of why this build fails?  
https://buildd.debian.org/status/fetch.php?pkg=quotatool&arch=kfreebsd-amd64&ver=1%3A1.6.2-2&stamp=1549998565&raw=0
21:29  uh I would guess that the mix of FreeBSD's ufs/ headers and 
glibc's sys/ is bad
21:29  most likely ufs/ufs/quota.h is including sys/types.h and 
expecting uint32_t
21:30  FreeBSD's sys/types.h gives intX_t and uintX_t, but glibc's only 
gives intX_t
21:30  workaround: include stdint.h before including ufs/quota.h
21:32  ah ok
21:32  so it's not a bug in kfreebsd per se?
21:32  it's a bug in the system headers
21:33  the lazy solution would be to fix it in glibc and diverge from 
linux
21:33  the better solution is probably to fix all the places that need 
uintX_t in FreeBSD's headers
21:33  ok, I'll send a bug report about that
21:34  feel free to just paste this discussion in the bug report, it'll 
be enough to remind me
21:34  ok



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

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

Bug#919773: libdbd-sqlite3-perl FTBFS on mips: test failure

[Niko Tyni]

Control: tag -1 patch

On Sat, Jan 19, 2019 at 03:44:43PM +0200, Adrian Bunk wrote:
> Source: libdbd-sqlite3-perl
> Version: 1.62-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=libdbd-sqlite3-perl&arch=mips&ver=1.62-1&stamp=1546291045&raw=0

> Test Summary Report
> ---
> t/65_db_config.t(Wstat: 11 Tests: 76 
> Failed: 0)
>   Non-zero wait status: 11
>   Parse errors: Bad plan.  You planned 79 tests but ran 76.

Hi, a standalone test case is

 perl -Iblib/lib -Iblib/arch -MDBI -e 
'DBI->connect("dbi:SQLite:dbname=:memory:", "","", { sqlite_defensive => 1})'

and the attached patch fixes it for me.
-- 
Niko Tyni   nt...@debian.org
>From daf3153f7ad67edd7071886c866fe790a7875427 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Wed, 13 Feb 2019 20:42:06 +
Subject: [PATCH] Fix SQLITE_DBCONFIG_DEFENSIVE parameter types

The sqlite3_db_config() function with SQLITE_DBCONFIG_DEFENSIVE
takes two 'int' parameters, but Perl integers may have a different
size. Passing a 64-bit argument ('long long int') has been observed
to cause a segmentation fault on 32-bit big-endian platforms.

Bug: https://github.com/DBD-SQLite/DBD-SQLite/issues/45
Bug-Debian: https://bugs.debian.org/919773
---
 dbdimp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dbdimp.c b/dbdimp.c
index ee08425..f4523d7 100644
--- a/dbdimp.c
+++ b/dbdimp.c
@@ -463,7 +463,7 @@ sqlite_db_login6(SV *dbh, imp_dbh_t *imp_dbh, char *dbname, char *user, char *pa
 if (hv_exists(hv, "sqlite_defensive", 16)) {
 val = hv_fetch(hv, "sqlite_defensive", 16, 0);
 if (val && SvIOK(*val)) {
-sqlite3_db_config(imp_dbh->db, SQLITE_DBCONFIG_DEFENSIVE, SvIV(*val), 0);
+sqlite3_db_config(imp_dbh->db, SQLITE_DBCONFIG_DEFENSIVE, (int)SvIV(*val), 0);
 }
 }
 }
-- 
2.11.0

Bug#782836: Debian Edu Jessie Beta 1 should be mentioned

[Paul Gevers]

Hi Holger,

On Sat, 18 Apr 2015 16:35:26 +0200 Holger Levsen 
wrote:
> package: release-notes
> tags: + patch
> x-debbugs-cc: debian-...@lists.debian.org, debian-public...@lists.debian.org
> 
> Hi,
> 
> please include the following patch to the release-notes. I also assume this 
> is 
> a nice information for the planned live-denting...
> 
> 
> News from Debian Edu Blend
> 
> The Debian Edu / Skolelinux project is proud to announce the first Beta 
> release of Debian Edu based on Debian Jessie. For the first time Debian Edu 
> is 
^^

I am pretty sure we can just close this bug, no? Or do you want to add
something like this for the buster release?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#921128: [Pkg-mailman-hackers] Bug#921128: Info received (mailman3-web fails to initialize mysql: Specified key was too long)

[Pierre-Elliott Bécue]

Le lundi 11 février 2019 à 23:40:51+0100, Jonas Meurer a écrit :
> Hi PEB, hi anarcat,
> 
> Pierre-Elliott Bécue:
> > Le lundi 11 février 2019 à 16:27:21-0500, Antoine Beaupré a écrit :
> >> On 2019-02-11 21:52:32, Pierre-Elliott Bécue wrote:
> >>> Le lundi 11 février 2019 à 09:14:55-0500, Antoine Beaupré a écrit :
>  Right, the only way this could be properly implemented would be if
>  debconf would attempt to connect with the configured DB credentials to
>  check the remote server version (or, better, to test the actuall code
>  bugginess).
> 
>  That's probably overkill though.
> >>>
> >>> ISTM that it is.
> >>>
> >>> But if you wish to go to such extents I'd be glad to include a patch!
> >>> (no time to dev it though)
> >>
> >> Alright, let good win in the face of non-existing perfect threats. ;)
> > 
> > I'll leave ourselves 24h of thinking and then I'll upload.
> > 
> > If you get attacked by insomnia, you know what to do. :P
> 
> Sorry for not responding earlier, I was to busy with other things.
> Still, I should have reacted earlier ...
> 
> As you might have seen, mariadb-10.1 10.1.37-0+deb9u1 is in stable-new
> queue[1]. I don't know the details why it didn't proceed to stable yet,
> but there's hope that this issue will be sorted out in Stretch soon. The
> 10.1.37 contains both the upstream backport of
> `innodb_default_row_format`[2] and the patch to the config[3] that sets
> the default row format to `dynamic`, so the `max key length is 767
> bytes` error is definitely fixed in this release.
> 
> Therefore I don't think it's still *needed* to upload the patch that PEB
> poposed in this bugreport. I don't *object* to uploading it either. So
> if you want to, go ahead, PEB. But we should track the mariadb 10.1
> version in Stretch and remove the Debconf question again once mariadb
> 10.1.37 got accepted into Stretch.
> 
> Cheers

This mariadb release seems to be already in security for stretch.

I changed a little the warning but I think we should keep it (at least
until the point release of stretch is really done):
https://salsa.debian.org/mailman-team/mailman-suite/commits/stretch-backports

Tell me what you think about it.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#921667: lxc, lava-dev: lxc fails to install along lava-dev --install-recommends

[Pierre-Elliott Bécue]

Le mercredi 13 février 2019 à 18:40:53-0200, Antonio Terceiro a écrit :
> On Wed, Feb 13, 2019 at 08:18:40PM +0100, Pierre-Elliott Bécue wrote:
> > Le 13 février 2019 20:09:33 GMT+01:00, Andreas Beckmann  a 
> > écrit :
> > >Control: reassign -1 lxc,apparmor
> > >Control: found -1 lxc/1:3.1.0+really3.0.3-2
> > >Control: found -1 apparmor/2.13.2-7
> > >Control: retitle -1 lxc,apparmor: lxc fails to install in a chroot with
> > >apparmor installed
> > >
> > >On 2019-02-10 20:06, Antonio Terceiro wrote:
> > >> I can reproduce this on a clean chroot (but not on a clean VM)
> > >
> > >I can also reproduce this in piuparts by testing lxc with
> > >--fake-essential-packages=apparmor (neither lava nor
> > >--install-recommends needed)
> > >
> > >> + apparmor_parser -r -W -T /etc/apparmor.d/lxc-containers
> > >> Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
> > >> Use --subdomainfs to override.
> > >> dpkg: error processing package lxc (--configure):
> > >>  installed lxc package post-installation script subprocess returned
> > >error exit status 1
> > >
> > >So this is either an lxc or apparmor issue.
> > >
> > >
> > >Andreas
> > 
> > See my staged commits.
> > 
> > https://salsa.debian.org/lxc-team/lxc/commit/a0e6b5f26227236e44ab8ff4cee745228201bb7d
> 
> weirdy, if you first install apparmor, then install lxc in a separate
> apt invocaation, it works just fine. and, if you do `apt install -f`
> after the initial failure, it also works fine.

I think it's a matter of AppArmor doing some magic at the end via a
trigger.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#921784: [Debichem-devel] Bug#921784: gromacs: FTBFS (ld returned 1 exit status)

[Nicholas Breen]

On Sat, Feb 09, 2019 at 12:15:22AM +, Santiago Vila wrote:
> Package: src:gromacs
> Version: 2019-2
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
[...]
> /usr/bin/mpicxx.openmpi   -msse2   -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11   -O3 
> -DNDEBUG -funroll-all-loops -fexcess-precision=fast  
> -L/usr/lib/openmpi/lib -Wl,-z,relro -Wl,-z,now -Wl,--as-needed 
> CMakeFiles/mdlib-test.dir/calc_verletbuf.cpp.o 
> CMakeFiles/mdlib-test.dir/mdebin.cpp.o CMakeFiles/mdlib-test.dir/settle.cpp.o 
> CMakeFiles/mdlib-test.dir/shake.cpp.o 
> CMakeFiles/mdlib-test.dir/simulationsignal.cpp.o 
> CMakeFiles/mdlib-test.dir/updategroups.cpp.o 
> CMakeFiles/mdlib-test.dir/updategroupscog.cpp.o 
> CMakeFiles/mdlib-test.dir/__/__/__/testutils/unittest_main.cpp.o  -o 
> ../../../../bin/mdlib-test ../../../../lib/libtestutils.a 
> ../../../../lib/libgromacs_mdrun_mpi_d.openmpi.a ../../../../lib/libgmock.a 
> -fopenmp /usr/lib/x86_64-linux-gnu/libz.so 
> /usr/lib/x86_64-linux-gnu/libhwloc.so -lrt 
> /usr/lib/x86_64-linux-gnu/libfftw3.so /usr/lib/x86_64-linux-gnu/libblas.so 
> /usr/lib/x86_64-linux-gnu/liblapack.so /usr/lib/x86_64-linux-gnu/libblas.so 
> /usr/lib/x86_64-linux-gnu/liblapack.so -lm 
> collect2: error: ld returned 1 exit status
> make[4]: *** 
> [src/gromacs/mdlib/tests/CMakeFiles/mdlib-test.dir/build.make:190: 
> bin/mdlib-test] Error 1
[...]

Hi Santiago,

I can't reproduce this build failure in a clean buster or sid chroot.
Both build successfully.

> The build was made in my autobuilder with "dpkg-buildpackage -A"
> and it also fails here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gromacs.html
> 
> where you can get a full build log if you need it.

This is actually a different error.  Is this running under pbuilder or a
derivative?  The test case that this build log failed on requires a
semi-functional network setup - it doesn't need (or attempt to use)
outside access, but it does at least need gethostbyname() to return a
reachable address for the system's hostname, with localhost being fine.
This does *not* work with the default pbuilder configuration, only with
USENETWORK=yes.  sbuild on the buildds works, as does a build outside a
constrained environment.  pbuilder also breaks further down the chain
for a few tests that don't allow running as root, unless BUILDUSERID is
also configured to a non-zero value.  It does make testing more
difficult!  If those constraints can't be met and pbuilder is essential,
it should be built with 'nocheck'.

Since it's no problem for either the buildds or users in their own
shell, I haven't considered those issues as serious bugs.



-- 
Nicholas Breen
nbr...@debian.org

Bug#907452: Raising severity

[Hilko Bengen]

control: severity -1 grave

This bug, along with various rounds of passive-aggressive
finger-pointing among the involved projects, has been around for a few
years now and it's getting more frustrating every time I look at it.

As I found out this week, it has only gotten worse from stretch to
buster:

For stretch (OpenVPN 2.4.0/pkcs11-helper 1.21-1), I was able to work
around any issues (#772812) by rebuilding OpenVPN without systemd
support so that no external program was spawned via a callback function
for reading a passphrase for the YubiKey I use. At some point, opensc
itself in stretch got broken by a botched "security" update (#910786),
but that's an unrelated issue and not relevant for buster.

For buster (OpenVPN 2.4.6/pkcs11-helper 1.25.1), this is not enough:
OpenVPN hangs when trying to call an external program (in our case:
"/sbin/ip link set dev $DEV up mtu $MTU").

On a more positive note, I'd really like to get this fixed for buster:

The only other relevant libpkcs11-helper1 reverse dependency seems to be
gnupg-pkcs11-scd. Would we break that if we built pkcs11-helper with
"--disable-threading" and "--disable-slotevent"?

Cheers,
-Hilko

Bug#921667: lxc, lava-dev: lxc fails to install along lava-dev --install-recommends

[Antonio Terceiro]

On Wed, Feb 13, 2019 at 08:18:40PM +0100, Pierre-Elliott Bécue wrote:
> Le 13 février 2019 20:09:33 GMT+01:00, Andreas Beckmann  a 
> écrit :
> >Control: reassign -1 lxc,apparmor
> >Control: found -1 lxc/1:3.1.0+really3.0.3-2
> >Control: found -1 apparmor/2.13.2-7
> >Control: retitle -1 lxc,apparmor: lxc fails to install in a chroot with
> >apparmor installed
> >
> >On 2019-02-10 20:06, Antonio Terceiro wrote:
> >> I can reproduce this on a clean chroot (but not on a clean VM)
> >
> >I can also reproduce this in piuparts by testing lxc with
> >--fake-essential-packages=apparmor (neither lava nor
> >--install-recommends needed)
> >
> >> + apparmor_parser -r -W -T /etc/apparmor.d/lxc-containers
> >> Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
> >> Use --subdomainfs to override.
> >> dpkg: error processing package lxc (--configure):
> >>  installed lxc package post-installation script subprocess returned
> >error exit status 1
> >
> >So this is either an lxc or apparmor issue.
> >
> >
> >Andreas
> 
> See my staged commits.
> 
> https://salsa.debian.org/lxc-team/lxc/commit/a0e6b5f26227236e44ab8ff4cee745228201bb7d

weirdy, if you first install apparmor, then install lxc in a separate
apt invocaation, it works just fine. and, if you do `apt install -f`
after the initial failure, it also works fine.


signature.asc
Description: PGP signature

Bug#922239: libpam0g 1.3.1-2 upgrade kills xdm

[Steve Langasek]

Control: tags -1 confirmed pending

Thanks for the report.

On Wed, Feb 13, 2019 at 05:03:25PM +0100, Johannes Stezenbach wrote:
> I think the cause is a bug in postinst script which checks for X:

> if ! who | awk '{print $2}'|grep -q ':[0-9]'; then
> check="$check wdm xdm"
> fi

> However, the output format of "who" (GNU coreutils 8.30) is:

>   js   console  Feb 13 15:54 (:0)
>   js   pts/1Jan 11 16:00 (tmux(2459).%0)
>   js   pts/2Jan 11 16:00 (tmux(2459).%1)
>   js   pts/3Jan 11 16:00 (tmux(2459).%2)
>   js   pts/4Jan 11 16:00 (tmux(2459).%3)
>   js   pts/5Feb 13 15:56 (:0)
>   ...

FWIW this is not a behavior change in coreutils, it's a (unexpected by me)
behavior change in xdm.  With gdm, 'who' still shows :1 as the terminal
listed in /run/utmpx.

I'll update the maintainer script and upload today.

> Incidentally debconf also failed to display any UI before
> restarting services, not sure why.

The debconf information from your system included in your bug report has the
answer:

> -- debconf information:
>   libpam0g/restart-services:
>   libpam0g/restart-failed:
>   libpam0g/xdm-needs-restart:
> * libraries/restart-without-asking: true

At some point in the past you told your system it was ok to restart services
on upgrade without prompting each time.  It just fell afoul of the wrong
handling of xdm specifically.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Thomas Schmitt]

Hi,

Matthijs Kooijman wrote:
> it seems isohybrid can include a small FAT filesystem with the
> bootloader files. [...]
> https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI

This describes the equipment of debian-live and debian-cd (DVD-*, BD-*,
netinst) ISOs. See e.g. debian-live-9.5.0-i386-xfce.iso and its
MBR partition table.

Debian and nearly all others use GRUB 2 for their EFI capable ISOs.
See Knoppix 8.[12] for examples of SYSLINUX EFI in ISOs.

SYSLINUX EFI stuff is known not to boot from CD, DVD, or BD, but only from
HDD, SSD, and alike.


Have a nice day :)

Thomas

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

[Nye Liu]

Also, I'm not sure that the infinite spin wait while() makes sense in 
GNUTLS_E_EAGAIN either. Is some sort of select() more appropriate? 

On February 13, 2019 9:54:12 AM PST, Andreas Metzler  wrote:
>On 2019-02-13 "Torrance, Douglas"  wrote:
>> On 12/27/18 3:48 PM, Nye Liu wrote:
>>> Package: wmbiff
>>> Version: 0.4.31-1
>>> Severity: important
>>> Tags: upstream patch
> 
>>> If gnutls_read() or read() report EAGAIN, tlscomm_expect() fails:
> 
>>> wmbiff/nyet  comm: wrote a000 CAPABILITY
>>> wmbiff/nyet  comm: imap.***.***:993: expecting: * CAPABILITY
>>> wmbiff/nyet  comm: imap.***.***:993: gnutls error reading: Resource
>temporarily unavailable, try again.
>>> wmbiff/nyet  imap4: unable to query capability stringwmbiff/nyet 
>comm: wrote a002 LOGOUT
>>> wmbiff/nyet  comm: imap.***.***:993: closing.
>
>> Thanks for the bug report and patch!  I submitted the patch upstream
>[1] 
>> and released a new version of wmbiff [2].
>
>> Andreas, I've pushed a new Debian package to git [3].  Would you be
>able 
>> to review and sponsor?
>
>Hello,
>
>I am not sure about the second part of the patch. I understand wmbiff
>breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started
>to happen recently (with TLS1.3) on blocking sockets.
>
>What I do not get from my rudimentary understanding C programmimg is
>the
>second part, this is in the else of "if (scs->tls_state)", so, afaiui
>for
>non-encrypted connections. Is the change necessary there at all, is it
>the right thing to retry read on EAGAIN then?
>
>cu Andreas
>
>-- 
>`What a good friend you are to him, Dr. Maturin. His other friends are
>so grateful to you.'
>`I sew his ears on from time to time, sure'

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

[Nye Liu]

Probably not, unless some other code change changes the conventional fd to no 
block. I added it only for symmetry sake. It does not fix any currently known 
bug. 

On February 13, 2019 9:54:12 AM PST, Andreas Metzler  wrote:
>On 2019-02-13 "Torrance, Douglas"  wrote:
>> On 12/27/18 3:48 PM, Nye Liu wrote:
>>> Package: wmbiff
>>> Version: 0.4.31-1
>>> Severity: important
>>> Tags: upstream patch
> 
>>> If gnutls_read() or read() report EAGAIN, tlscomm_expect() fails:
> 
>>> wmbiff/nyet  comm: wrote a000 CAPABILITY
>>> wmbiff/nyet  comm: imap.***.***:993: expecting: * CAPABILITY
>>> wmbiff/nyet  comm: imap.***.***:993: gnutls error reading: Resource
>temporarily unavailable, try again.
>>> wmbiff/nyet  imap4: unable to query capability stringwmbiff/nyet 
>comm: wrote a002 LOGOUT
>>> wmbiff/nyet  comm: imap.***.***:993: closing.
>
>> Thanks for the bug report and patch!  I submitted the patch upstream
>[1] 
>> and released a new version of wmbiff [2].
>
>> Andreas, I've pushed a new Debian package to git [3].  Would you be
>able 
>> to review and sponsor?
>
>Hello,
>
>I am not sure about the second part of the patch. I understand wmbiff
>breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started
>to happen recently (with TLS1.3) on blocking sockets.
>
>What I do not get from my rudimentary understanding C programmimg is
>the
>second part, this is in the else of "if (scs->tls_state)", so, afaiui
>for
>non-encrypted connections. Is the change necessary there at all, is it
>the right thing to retry read on EAGAIN then?
>
>cu Andreas
>
>-- 
>`What a good friend you are to him, Dr. Maturin. His other friends are
>so grateful to you.'
>`I sew his ears on from time to time, sure'

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#922265: lemonldap-ng: FTBFS in sid (failing tests)

[Santiago Vila]

Package: src:lemonldap-ng
Version: 2.0.2+ds-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_autoreconf -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/lemonldap-ng-2.0.2+ds'
/usr/bin/make configure STORAGECONFFILE=/etc/lemonldap-ng/lemonldap-ng.ini \
PERLOPTIONS="INSTALLDIRS=vendor"
make[2]: Entering directory '/<>/lemonldap-ng-2.0.2+ds'
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Lemonldap::NG::Common
Writing MYMETA.yml and MYMETA.json

[... snipped ...]

t/61-GrantSession.t ... ok
t/61-Session-ActivityTimeout.t  ok
t/61-Session-Timeout.t  ok
t/62-SingleSession.t .. ok
t/63-History.t  ok
t/64-StayConnected.t .. ok
t/65-AutoSignin.t . ok
t/66-CDA-already-auth.t ... ok
t/66-CDA-with-REST.t .. ok
t/66-CDA-with-SOAP.t .. ok
t/66-CDA.t  ok
t/70-2F-TOTP-with-HISTORY.t ... ok
t/70-2F-TOTP.t  ok
t/70-2F-TOTP_8.t .. ok
t/71-2F-U2F-with-HISTORY.t  ok
t/71-2F-U2F.t . ok
t/72-2F-REST-with-HISTORY.t ... ok
t/73-2F-UTOTP-TOTP-and-U2F-with-HISTORY.t . ok
t/73-2F-UTOTP-TOTP-and-U2F.t .. ok
t/73-2F-UTOTP-TOTP-only-with-HISTORY.t  ok
t/73-2F-UTOTP-TOTP-only.t . ok
t/74-2F-Required.t  ok
t/75-2F-Registers.t ... ok
t/76-2F-Ext-with-BruteForce.t . ok
t/76-2F-Ext-with-GrantSession.t ... ok
t/76-2F-Ext-with-HISTORY.t  ok
t/77-2F-Mail.t  ok
t/90-Translations.t ... ok
t/99-pod.t  ok

Test Summary Report
---
t/29-AuthGPG.t  (Wstat: 512 
Tests: 13 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
Files=119, Tests=4738, 158 wallclock secs ( 1.38 usr  0.40 sys + 97.22 cusr 
16.18 csys = 115.18 CPU)
Result: FAIL
Failed 1/119 test programs. 0/4738 subtests failed.
make[2]: *** [Makefile:1062: test_dynamic] Error 255
make[2]: Leaving directory 
'/<>/lemonldap-ng-2.0.2+ds/lemonldap-ng-portal'
make[1]: *** [Makefile:371: portal_test] Error 2
make[1]: Leaving directory '/<>/lemonldap-ng-2.0.2+ds'
dh_auto_test: make -j1 test returned exit code 2
make: *** [debian/rules:20: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

https://buildd.debian.org/status/package.php?p=lemonldap%2dng

where you can get a full build log if you need it.

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

Thanks.

Bug#922264: pkg-perl-autopkgtest: use "skippable" and "superficial" restrictions

[Xavier Guimard]

Package: pkg-perl-autopkgtest
Version: 0.50
Severity: wishlist

Hi all,

Some suggestions for pkg-js-autopkgtest based on pkg-js-autopkgtest
discussion with autodep8 maintainers:
 - tests skipped should return a 77 exit code and all tests marked as
   "Restrictions: skippable". It avoids to consider that a test succeeds
   if maintainer skipped it, but needs a merge request to autodep8. See
   https://salsa.debian.org/ci-team/autodep8/blob/master/support/nodejs/generate
   (changed by MR !11)
 - runtime-deps* tests should be tagged as "Restrictions: superficial"
   since these tests don't really test package features but just Perl
   syntax

Then with this 2 changes, if "build-deps.d" is skipped, success won't
give the benefit of 3-days-reduce.

Cheers,
Xavier

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

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

Versions of packages pkg-perl-autopkgtest depends on:
ii  perl  5.28.1-4

pkg-perl-autopkgtest recommends no packages.

pkg-perl-autopkgtest suggests no packages.

-- no debconf information

Bug#922259: python-libnacl: FTBFS (ValueError: byte must be in range(0, 256))

[Santiago Vila]

Package: src:python-libnacl
Version: 1.6.1-3
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules binary-indep
dh binary-indep --with python2,python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython2_2.7_libnacl/build/libnacl
copying libnacl/public.py -> 
/<>/.pybuild/cpython2_2.7_libnacl/build/libnacl

[... snipped ...]

test_box (unit.test_raw_public.TestPublic) ... ok
test_box_seal (unit.test_raw_public.TestPublic) ... ok
test_boxnm (unit.test_raw_public.TestPublic) ... ok
test_gen (unit.test_raw_public.TestPublic) ... ok
copied from libsodium default/randombytes.c ... ok
test_randombytes_random (unit.test_raw_random.TestRandomBytes) ... ok
test_randombytes_uniform (unit.test_raw_random.TestRandomBytes) ... ok
test_secretbox (unit.test_raw_secret.TestSecret) ... ok
test_box (unit.test_raw_sign.TestSign) ... ok
test_gen (unit.test_raw_sign.TestSign) ... ok
test_save_load (unit.test_save.TestSave) ... ok
test_save_load_secret (unit.test_save.TestSave) ... ok
test_save_load_sign (unit.test_save.TestSave) ... ok
test_save_perms (unit.test_save.TestSave) ... ok
test_publickey_only (unit.test_seal.TestSealed) ... ok
test_secretkey (unit.test_seal.TestSealed) ... ok
test_secret (unit.test_secret.TestSecret) ... ok
test_sign (unit.test_sign.TestSigning) ... ok
test_verify16 (unit.test_verify.TestVerify) ... ok
test_verify32 (unit.test_verify.TestVerify) ... ERROR
test_verify64 (unit.test_verify.TestVerify) ... ok
test_different (unit.test_verify.TestVerifyBytesEq) ... ok
test_different_length (unit.test_verify.TestVerifyBytesEq) ... ok
test_equal (unit.test_verify.TestVerifyBytesEq) ... ok
test_invalid_type (unit.test_verify.TestVerifyBytesEq) ... ok
test_library_version_major (unit.test_version.TestSodiumVersion) ... ok
test_library_version_minor (unit.test_version.TestSodiumVersion) ... ok
test_version_string (unit.test_version.TestSodiumVersion) ... ok

==
ERROR: test_verify32 (unit.test_verify.TestVerify)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.7_libnacl/build/tests/unit/test_verify.py",
 line 30, in test_verify32
v32x[libnacl.randombytes_random() & 31] += 1
ValueError: byte must be in range(0, 256)

--
Ran 43 tests in 0.776s

FAILED (errors=1)
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.7_libnacl/build; python3.7 -m nose -v tests
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:7: binary-indep] Error 25
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

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

where you can get a full build log if you need it.

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

Thanks.

Bug#922261: python-sunlight: FTBFS (Could not import extension sphinx.ext.pngmath)

[Santiago Vila]

Package: src:python-sunlight
Version: 1.1.5-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc
dh: Compatibility levels before 9 are deprecated (level 8 in use)
   dh_update_autotools_config -i
   dh_auto_configure -i
dh_auto_configure: Compatibility levels before 9 are deprecated (level 8 in use)
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
set -xe; \
for py in python2.7 python3.7; do \
$py setup.py build; \
done
+ python2.7 setup.py build
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/sunlight
copying sunlight/config.py -> build/lib.linux-x86_64-2.7/sunlight
copying sunlight/__init__.py -> build/lib.linux-x86_64-2.7/sunlight
copying sunlight/errors.py -> build/lib.linux-x86_64-2.7/sunlight
copying sunlight/service.py -> build/lib.linux-x86_64-2.7/sunlight
creating build/lib.linux-x86_64-2.7/sunlight/services
copying sunlight/services/capitolwords.py -> 
build/lib.linux-x86_64-2.7/sunlight/services
copying sunlight/services/__init__.py -> 
build/lib.linux-x86_64-2.7/sunlight/services
copying sunlight/services/influenceexplorer.py -> 
build/lib.linux-x86_64-2.7/sunlight/services
copying sunlight/services/openstates.py -> 
build/lib.linux-x86_64-2.7/sunlight/services
copying sunlight/services/congress.py -> 
build/lib.linux-x86_64-2.7/sunlight/services
+ python3.7 setup.py build
running build
running build_py
creating build/lib
creating build/lib/sunlight
copying sunlight/config.py -> build/lib/sunlight
copying sunlight/__init__.py -> build/lib/sunlight
copying sunlight/errors.py -> build/lib/sunlight
copying sunlight/service.py -> build/lib/sunlight
creating build/lib/sunlight/services
copying sunlight/services/capitolwords.py -> build/lib/sunlight/services
copying sunlight/services/__init__.py -> build/lib/sunlight/services
copying sunlight/services/influenceexplorer.py -> build/lib/sunlight/services
copying sunlight/services/openstates.py -> build/lib/sunlight/services
copying sunlight/services/congress.py -> build/lib/sunlight/services
make -C docs html
make[2]: Entering directory '/<>/docs'
sphinx-build -b html -d build/doctrees   source build/html
Running Sphinx v1.8.3

Extension error:
Could not import extension sphinx.ext.pngmath (exception: No module named 
pngmath)
make[2]: *** [Makefile:40: html] Error 2
make[2]: Leaving directory '/<>/docs'
make[1]: *** [debian/rules:21: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:13: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

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

where you can get a full build log if you need it.

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

Thanks.

Bug#922256: nitime: FTBFS (Could not import extension sphinx.ext.pngmath)

[Santiago Vila]

Package: src:nitime
Version: 0.7-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with python2
   dh_update_autotools_config -i
   dh_auto_configure -i
dh_auto_configure: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
   dh_auto_build -i
dh_auto_build: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_build: This feature will be removed in compat 12.
python setup.py build --force
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7

[... snipped ...]

  zt /= st[sl]
/<>/debian/tmp/usr/lib/python2.7/dist-packages/nitime/viz.py:1391: 
RuntimeWarning: divide by zero encountered in log
  toplot = np.log(toplot)
/usr/lib/python2.7/dist-packages/matplotlib/cbook/deprecation.py:107: 
MatplotlibDeprecationWarning: Adding an axes using the same arguments as a 
previous axes currently reuses the earlier instance.  In a future version, a 
new instance will always be created and returned.  Meanwhile, this warning can 
be suppressed, and the future behavior ensured, by passing a unique label to 
each axes instance.
  warnings.warn(message, mplDeprecation, stacklevel=1)
grasshopper.py
snr_example.py
mtm_baseband_power.py
event_related_fmri.py
ar_est_3vars.py
mtm_harmonic_test.py
('freqs:', array([0.02217944, 0.02897103, 0.05012797]), '\testimated:', 
array([0.02218628, 0.02897644, 0.05012512]), '\terr: 8.410e-11')
('amp:', array([1.14652768, 1.5882896 , 0.77338958]), '\testimated:', 
array([1.13804782, 1.59692699, 0.76345026]), '\terr: 5.531e-05')
('phase:', array([3.28272585, 4.84241539, 1.8610345 ]), '\testimated:', 
array([3.07380887, 4.4496, 1.98370608]), '\terr: 8.959e-02')
MS error over noise: 2.350e-02
granger_fmri.py
seed_analysis.py
multi_taper_coh.py
resting_state_fmri.py
ar_est_1var.py
ar_model_fit.py
filtering_fmri.py
multi_taper_spectral_estimation.py
ar_est_2vars.py
python ../tools/build_modref_templates.py
('WARNING: Empty -', 'nitime')
('WARNING: Empty -', 'nitime.algorithms')
('WARNING: Empty -', 'nitime.analysis')
('WARNING: Empty -', 'nitime.fmri')
('WARNING: Empty -', 'nitime.version')
25 files written
Build API docs finished.
sphinx-build -b html -d _build/doctrees   . _build/html
Running Sphinx v1.8.3
/usr/lib/python2.7/dist-packages/matplotlib/cbook/deprecation.py:107: 
MatplotlibDeprecationWarning: The mpl_toolkits.axes_grid module was deprecated 
in version 2.1. Use mpl_toolkits.axes_grid1 and mpl_toolkits.axisartist provies 
the same functionality instead.
  warnings.warn(message, mplDeprecation, stacklevel=1)

Extension error:
Could not import extension sphinx.ext.pngmath (exception: No module named 
pngmath)
make[2]: *** [Makefile:35: htmlonly] Error 2
make[2]: Leaving directory '/<>/doc'
make[1]: *** [debian/rules:28: override_dh_auto_install] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:16: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

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

where you can get a full build log if you need it.

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

Thanks.

Bug#922257: pyfr: FTBFS (dh_installman: Could not determine section for ./build/man/_static)

[Santiago Vila]

Package: src:pyfr
Version: 1.5.0-2
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
pybuild --configure -i python{version} -p 3.7
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
pybuild --build -i python{version} -p 3.7
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build

[... snipped ...]

I: pybuild pybuild:295: mv /<>/debian/tmp/usr/bin/pyfr 
/<>/debian/tmp/usr/share/pyfr/run
   dh_install -i -O--buildsystem=pybuild
install -d debian/pyfr//usr/share
cp --reflink=auto -a debian/tmp/usr/share/pyfr debian/pyfr//usr/share/
install -d debian/.debhelper/generated/pyfr
install -d debian/.debhelper/generated/pyfr-doc
   dh_installdocs -i -O--buildsystem=pybuild
install -d debian/pyfr/usr/share/doc/pyfr
install -p -m0644 debian/copyright 
debian/pyfr/usr/share/doc/pyfr/copyright
install -d debian/pyfr-doc/usr/share/doc/pyfr-doc
cd './build/html/..' && find 'html' \( -type f -or -type l \) -and ! 
-empty -print0 | LC_ALL=C sort -z | xargs -0 -I {} cp --reflink=auto --parents 
-dp {} /<>/debian/pyfr-doc/usr/share/doc/pyfr-doc
chown -R 0:0 debian/pyfr-doc/usr/share/doc
chmod -R u\+rw,go=rX debian/pyfr-doc/usr/share/doc
install -p -m0644 debian/copyright 
debian/pyfr-doc/usr/share/doc/pyfr-doc/copyright
install -d debian/pyfr-doc/usr/share/doc-base/
install -p -m0644 debian/pyfr-doc.doc-base 
debian/pyfr-doc/usr/share/doc-base/pyfr-doc
rm -f debian/pyfr-doc.debhelper.log debian/pyfr.debhelper.log
   debian/rules override_dh_sphinxdoc
make[1]: Entering directory '/<>'
dh_sphinxdoc --exclude=MathJax.js
ln -sf ../../../../javascript/sphinxdoc/1.0/sidebar.js 
debian/pyfr-doc/usr/share/doc/pyfr-doc/html/_static/sidebar.js
ln -sf ../../../../javascript/sphinxdoc/1.0/underscore.js 
debian/pyfr-doc/usr/share/doc/pyfr-doc/html/_static/underscore.js
ln -sf ../../../../javascript/sphinxdoc/1.0/jquery.js 
debian/pyfr-doc/usr/share/doc/pyfr-doc/html/_static/jquery.js
ln -sf ../../../../javascript/sphinxdoc/1.0/doctools.js 
debian/pyfr-doc/usr/share/doc/pyfr-doc/html/_static/doctools.js
ln -sf ../../../../javascript/sphinxdoc/1.0/searchtools.js 
debian/pyfr-doc/usr/share/doc/pyfr-doc/html/_static/searchtools.js
rm -rf debian/pyfr-doc/usr/share/doc/pyfr-doc/html/.doctrees
rm -f debian/pyfr-doc/usr/share/doc/pyfr-doc/html/.buildinfo
rm -f debian/pyfr-doc/usr/share/doc/pyfr-doc/html/_static/websupport.js
(grep -a -s -v sphinxdoc:Depends debian/pyfr-doc.substvars; echo 
"sphinxdoc:Depends=libjs-sphinxdoc (>= 1.0)") > debian/pyfr-doc.substvars.new
mv debian/pyfr-doc.substvars.new debian/pyfr-doc.substvars
(grep -a -s -v sphinxdoc:Built-Using debian/pyfr-doc.substvars; echo 
"sphinxdoc:Built-Using=sphinx (= 1.8.3-2)") > debian/pyfr-doc.substvars.new
mv debian/pyfr-doc.substvars.new debian/pyfr-doc.substvars
make[1]: Leaving directory '/<>'
   dh_installchangelogs -i -O--buildsystem=pybuild
install -p -m0644 debian/changelog 
debian/pyfr/usr/share/doc/pyfr/changelog.Debian
install -p -m0644 debian/changelog 
debian/pyfr-doc/usr/share/doc/pyfr-doc/changelog.Debian
   dh_installexamples -i -O--buildsystem=pybuild
install -d debian/pyfr-doc/usr/share/doc/pyfr-doc/examples
cp --reflink=auto -a ./examples/couette_flow_2d 
debian/pyfr-doc/usr/share/doc/pyfr-doc/examples
cp --reflink=auto -a ./examples/euler_vortex_2d 
debian/pyfr-doc/usr/share/doc/pyfr-doc/examples
   dh_installman -i -O--buildsystem=pybuild
dh_installman: Could not determine section for ./build/man/_static
dh_installman: Aborting due to earlier error
make: *** [debian/rules:12: binary-indep] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

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

where you can get a full build log if you need it.

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

Thanks.

Bug#922260: python-ncclient: FTBFS (Could not import extension sphinx.ext.pngmath)

[Santiago Vila]

Package: src:python-ncclient
Version: 0.6.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=pybuild --with python2,python3,sphinxdoc
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
Warning: 'keywords' should be a list, got type 'tuple'
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python setup.py build 
running build
running build_py

[... snipped ...]

byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/transport/notify.py
 to notify.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/transport/session.py
 to session.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/transport/__init__.py
 to __init__.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/transport/ssh.py
 to ssh.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/transport/errors.py
 to errors.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/transport/third_party/__init__.py
 to __init__.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/transport/third_party/junos/ioproc.py
 to ioproc.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/transport/third_party/junos/__init__.py
 to __init__.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/debug.py
 to debug.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/junos.py
 to junos.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/__init__.py
 to __init__.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/default.py
 to default.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/nexus.py
 to nexus.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/h3c.py
 to h3c.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/csr.py
 to csr.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/huawei.py
 to huawei.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/iosxr.py
 to iosxr.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/hpcomware.py
 to hpcomware.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/alu.py
 to alu.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/devices/iosxe.py
 to iosxe.cpython-37.pyc
byte-compiling 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient/xml_.py
 to xml_.cpython-37.pyc
running install_egg_info
running egg_info
writing ncclient.egg-info/PKG-INFO
writing dependency_links to ncclient.egg-info/dependency_links.txt
writing requirements to ncclient.egg-info/requires.txt
writing top-level names to ncclient.egg-info/top_level.txt
reading manifest file 'ncclient.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'ncclient.egg-info/SOURCES.txt'
Copying ncclient.egg-info to 
/<>/debian/python3-ncclient/usr/lib/python3.7/dist-packages/ncclient-0.6.0.egg-info
Skipping SOURCES.txt
running install_scripts
   dh_installdocs -i -O--buildsystem=pybuild
   debian/rules override_dh_sphinxdoc
make[1]: Entering directory '/<>'
sphinx-build -b html docs/source/ 
/<>/debian/python-ncclient-doc/usr/share/doc/python-ncclient/html
Running Sphinx v1.8.3

Extension error:
Could not import extension sphinx.ext.pngmath (exception: No module named 
'sphinx.ext.pngmath')
make[1]: *** [debian/rules:15: override_dh_sphinxdoc] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

https://tests.reproducible

Bug#922263: turbogears2-doc: FTBFS (ImportError: cannot import name flatten_arguments)

[Santiago Vila]

Package: src:turbogears2-doc
Version: 2.3.7-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh_testdir
cd docs/ && /usr/bin/make html
make[1]: Entering directory '/<>/docs'
mkdir -p _build/html _build/doctrees
sphinx-build -b html -d _build/doctrees  -w sphinxlog.txt . _build/html
Running Sphinx v1.8.3

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

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sphinx/config.py", line 368, in 
eval_config_file
execfile_(filename, namespace)
  File "/usr/lib/python2.7/dist-packages/sphinx/util/pycompat.py", line 150, in 
execfile_
exec_(code, _globals)
  File "/usr/lib/python2.7/dist-packages/six.py", line 709, in exec_
exec("""exec _code_ in _globs_, _locs_""")
  File "", line 1, in 
  File "/<>/docs/conf.py", line 15, in 
from tg.release import version as tg_release_version
  File "/usr/lib/python2.7/dist-packages/tg/__init__.py", line 52, in 
from tg.controllers import TGController, RestController, redirect, url, 
lurl, abort
  File "/usr/lib/python2.7/dist-packages/tg/controllers/__init__.py", line 2, 
in 
from tg.controllers.decoratedcontroller import DecoratedController
  File 
"/usr/lib/python2.7/dist-packages/tg/controllers/decoratedcontroller.py", line 
14, in 
from crank.util import get_params_with_argspec, flatten_arguments
ImportError: cannot import name flatten_arguments

make[1]: *** [Makefile:42: html] Error 2
make[1]: Leaving directory '/<>/docs'
make: *** [debian/rules:25: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

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

where you can get a full build log if you need it.

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

Thanks.

Bug#922262: ripe-atlas-tools: FTBFS (Could not import extension sphinx.ext.pngmath)

[Santiago Vila]

Package: src:ripe-atlas-tools
Version: 2.3.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep  --with=python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython3_3.7/build/ripe

[... snipped ...]

copying ripe/atlas/tools/renderers/raw.py -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers
copying ripe/atlas/tools/renderers/ssl_consistency.py -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers
copying ripe/atlas/tools/renderers/sslcert.py -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers
copying ripe/atlas/tools/renderers/traceroute.py -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers
copying ripe/atlas/tools/renderers/traceroute_aspath.py -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers
creating 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers/templates
creating 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers/templates/reports
copying ripe/atlas/tools/renderers/templates/reports/aggregate_ping.txt -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers/templates/reports
copying ripe/atlas/tools/renderers/templates/reports/dns.txt -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers/templates/reports
copying ripe/atlas/tools/renderers/templates/reports/ssl_consistency.txt -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers/templates/reports
copying ripe/atlas/tools/renderers/templates/reports/sslcert.txt -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/renderers/templates/reports
creating /<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/settings
copying ripe/atlas/tools/settings/__init__.py -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/settings
creating 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/settings/templates
copying ripe/atlas/tools/settings/templates/base.yaml -> 
/<>/.pybuild/cpython3_3.7/build/ripe/atlas/tools/settings/templates
running build_scripts
creating build
creating build/scripts-3.7
copying and adjusting scripts/aping -> build/scripts-3.7
copying and adjusting scripts/atraceroute -> build/scripts-3.7
copying and adjusting scripts/adig -> build/scripts-3.7
copying and adjusting scripts/asslcert -> build/scripts-3.7
copying and adjusting scripts/ahttp -> build/scripts-3.7
copying and adjusting scripts/antp -> build/scripts-3.7
copying and adjusting scripts/ripe-atlas -> build/scripts-3.7
changing mode of build/scripts-3.7/aping from 664 to 775
changing mode of build/scripts-3.7/atraceroute from 664 to 775
changing mode of build/scripts-3.7/adig from 664 to 775
changing mode of build/scripts-3.7/asslcert from 664 to 775
changing mode of build/scripts-3.7/ahttp from 664 to 775
changing mode of build/scripts-3.7/antp from 664 to 775
changing mode of build/scripts-3.7/ripe-atlas from 664 to 775
/usr/bin/make -C docs html
make[2]: Entering directory '/<>/docs'
sphinx-build -b html -d _build/doctrees   . _build/html
Running Sphinx v1.8.3

Extension error:
Could not import extension sphinx.ext.pngmath (exception: No module named 
'sphinx.ext.pngmath')
make[2]: *** [Makefile:53: html] Error 2
make[2]: Leaving directory '/<>/docs'
make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:10: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ripe-atlas-tools.html

where you can get a full build log if you need it.

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

Thanks.

Bug#922258: python-biom-format: FTBFS (Could not import extension sphinx.ext.pngmath)

[Santiago Vila]

Package: src:python-biom-format
Version: 2.1.7+dfsg-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,bash-completion,sphinxdoc 
--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
pybuild --configure --test-nose -i python{version} -p 2.7
I: pybuild base:217: python2.7 setup.py config 
running config
pybuild --configure --test-nose -i python{version} -p 3.7
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/python-biom-format-2.1.7+dfsg'
# arch

[... snipped ...]

copying biom/tests/test_data/test.json -> 
/<>/python-biom-format-2.1.7+dfsg/.pybuild/cpython3_3.7_biom-format/build/biom/tests/test_data
copying biom/tests/test_data/test.json.gz -> 
/<>/python-biom-format-2.1.7+dfsg/.pybuild/cpython3_3.7_biom-format/build/biom/tests/test_data
running build_ext
building 'biom._filter' extension
creating build/temp.linux-amd64-3.7
creating build/temp.linux-amd64-3.7/biom
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 
-fdebug-prefix-map=/<>/python-biom-format-2.1.7+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python3/dist-packages/numpy/core/include 
-I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.7m 
-c biom/_filter.c -o build/temp.linux-amd64-3.7/biom/_filter.o
In file included from 
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1822,
 from 
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarrayobject.h:12,
 from 
/usr/lib/python3/dist-packages/numpy/core/include/numpy/arrayobject.h:4,
 from biom/_filter.c:632:
/usr/lib/python3/dist-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2:
 warning: #warning "Using deprecated NumPy API, disable it with " "#define 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
 #warning "Using deprecated NumPy API, disable it with " \
  ^~~
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wl,-z,relro -Wl,-z,now -g -O2 
-fdebug-prefix-map=/<>/python-biom-format-2.1.7+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 build/temp.linux-amd64-3.7/biom/_filter.o -o 
/<>/python-biom-format-2.1.7+dfsg/.pybuild/cpython3_3.7_biom-format/build/biom/_filter.cpython-37m-x86_64-linux-gnu.so
building 'biom._transform' extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 
-fdebug-prefix-map=/<>/python-biom-format-2.1.7+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python3/dist-packages/numpy/core/include 
-I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.7m 
-c biom/_transform.c -o build/temp.linux-amd64-3.7/biom/_transform.o
In file included from 
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1822,
 from 
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarrayobject.h:12,
 from 
/usr/lib/python3/dist-packages/numpy/core/include/numpy/arrayobject.h:4,
 from biom/_transform.c:632:
/usr/lib/python3/dist-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2:
 warning: #warning "Using deprecated NumPy API, disable it with " "#define 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
 #warning "Using deprecated NumPy API, disable it with " \
  ^~~
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wl,-z,relro -Wl,-z,now -g -O2 
-fdebug-prefix-map=/<>/python-biom-format-2.1.7+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 build/temp.linux-amd64-3.7/biom/_transform.o -o 
/<>/python-biom-format-2.1.7+dfsg/.pybuild/cpython3_3.7_biom-format/build/biom/_transform.cpython-37m-x86_64-linux-gnu.so
building 'biom._subsample' extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 
-fdebug-prefix-map=/<>/python-biom-format-2.1.7+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python3/dist-packages/numpy/core/include 
-I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.7m 
-c biom/_subsample.c -o build/temp.linux-amd64-3.7/biom/_subsample.o
In file included from 
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1822,
 from 
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarrayobject.h:12,
 from 
/usr/lib/python3/dist-packages/n

Bug#922253: hamradio-maintguide: FTBFS (Could not import extension sphinx.ext.pngmath)

[Santiago Vila]

Package: src:hamradio-maintguide
Version: 0.4
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
make html
make[2]: Entering directory '/<>'
sphinx-build -b html -d _build/doctrees   . _build/html
Running Sphinx v1.8.3

Extension error:
Could not import extension sphinx.ext.pngmath (exception: No module named 
'sphinx.ext.pngmath')
make[2]: *** [Makefile:53: html] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:7: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

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

where you can get a full build log if you need it.

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

Thanks.

Bug#922254: jsxgraph: FTBFS (ERROR: module path does not exist)

[Santiago Vila]

Package: src:jsxgraph
Version: 1.3.5+dfsg1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with apache2 --with python2
   dh_update_autotools_config -i
   dh_auto_configure -i
   dh_auto_build -i
make -j1
make[1]: Entering directory '/<>/jsxgraph-1.3.5+dfsg1'
# add symlinks to replace node_modules utilities
#
# replace almond
mkdir -p node_modules/almond
ln -s /usr/lib/nodejs/node-almond/almond.js node_modules/almond/
mkdir -p node_modules/requirejs/bin
#ln -s /usr/lib/nodejs/r.js node_modules/requirejs/bin
mkdir -p build/bin
nodejs ./node_modules/bin/r.js -o build/core.build.json
Error: Error: ERROR: module path does not exist: 
/<>/jsxgraph-1.3.5+dfsg1/src/../node_modules/almond/almond.js for 
module named: ../node_modules/almond/almond. Path is relative to: 
/<>/jsxgraph-1.3.5+dfsg1
at /<>/jsxgraph-1.3.5+dfsg1/node_modules/bin/r.js:30214:35

make[1]: *** [Makefile:72: core] Error 1
make[1]: Leaving directory '/<>/jsxgraph-1.3.5+dfsg1'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:13: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

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

where you can get a full build log if you need it.

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

Thanks.

Bug#922252: ganeti-2.15: FTBFS (ImportError: cannot import name Directive)

[Santiago Vila]

Package: src:ganeti-2.15
Version: 2.15.2-13
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --with python2,sphinxdoc,bash_completion
   dh_update_autotools_config -i
   debian/rules override_dh_autoreconf
make[1]: Entering directory '/<>'
dh_autoreconf /<>/autogen.sh
configure.ac:15: installing 'autotools/install-sh'
configure.ac:15: installing 'autotools/missing'
Makefile.am:443: installing 'autotools/py-compile'
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dpkg-parsechangelog -Sversion > vcs-version
./configure \

[... snipped ...]

cat /<>/lib/_constants.py.in > lib/_constants.py
src/hs2py --constants >> lib/_constants.py
set -e; \
VCSVER=`cat /<>/vcs-version`; \
{ echo '# This file is automatically generated, do not edit!'; \
  echo '#'; \
  echo ''; \
  echo '"""Build-time VCS version number for Ganeti.'; \
  echo '';\
  echo 'This file is autogenerated by the build process.'; \
  echo 'For any changes you need to re-run ./configure (and'; \
  echo 'not edit by hand).'; \
  echo ''; \
  echo '"""'; \
  echo ''; \
  echo '# pylint: disable=C0301,C0324'; \
  echo '# because this is autogenerated, we do not want'; \
  echo '# style warnings' ; \
  echo ''; \
  echo "VCS_VERSION = '$VCSVER'"; \
} > lib/_vcsversion.py
cat /<>/lib/opcodes.py.in_before > lib/opcodes.py
src/hs2py --opcodes >> lib/opcodes.py
cat /<>/lib/opcodes.py.in_after >> lib/opcodes.py
src/hs2py --wconfd-rpc > lib/rpc/stub/wconfd.py
src/hs2py --metad-rpc > lib/rpc/stub/metad.py
PYTHONPATH=. ./autotools/run-in-tempdir /<>/./autotools/build-rpc 
lib/rpc_defs.py > lib/_generated_rpc.py
Checking man/ganeti-cleaner.rst for hardcoded paths...
set -e ; \
trap 'echo auto-removing man/ganeti-cleaner.gen; rm man/ganeti-cleaner.gen' 
EXIT; \
PYTHONPATH=. ./autotools/run-in-tempdir /<>/./autotools/docpp < 
man/ganeti-cleaner.rst > man/ganeti-cleaner.gen ;\
./autotools/check-man-references man/ganeti-cleaner.gen; \
trap - EXIT
Traceback (most recent call last):
  File "/<>/./autotools/docpp", line 39, in 
from ganeti.build import sphinx_ext
  File "/tmp/gntbuild.rQlbNdFI/ganeti/build/sphinx_ext.py", line 47, in 
from sphinx.directives import Directive
ImportError: cannot import name Directive
auto-removing man/ganeti-cleaner.gen
make[1]: *** [Makefile:4455: man/ganeti-cleaner.gen] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:21: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

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

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

where you can get a full build log if you need it.

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

Thanks.

Bug#922255: libkgapi: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:libkgapi
Version: 18.08.3-1
Severity: important
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.pl --with=kf5,pkgkde-symbolshelper 
dpkg-buildflags --export=make > debian/dhmk_env.mk
/usr/bin/make -f debian/rules dhmk_run_configure_commands 
DHMK_TARGET="configure"
make[1]: Entering directory '/<>'
dh_testdir  # [-i]
dh_auto_configure '--buildsystem=kf5' --parallel  # [-i]
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_BUILD_TYPE=Debian 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DKDE_INSTALL_USE_QT_SYS_PATHS=ON ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done

[... snipped ...]

* Finished testing of TaskCreateJobTest *

  Start 25: tasks-taskdeletejobtest
25/37 Test #25: tasks-taskdeletejobtest ...   Passed0.24 sec
  Start 26: tasks-taskfetchjobtest
26/37 Test #26: tasks-taskfetchjobtest    Passed0.24 sec
  Start 27: tasks-taskmodifyjobtest
27/37 Test #27: tasks-taskmodifyjobtest ...   Passed0.24 sec
  Start 28: tasks-taskmovejobtest
28/37 Test #28: tasks-taskmovejobtest .   Passed0.24 sec
  Start 29: tasks-tasklistcreatejobtest
29/37 Test #29: tasks-tasklistcreatejobtest ...   Passed0.24 sec
  Start 30: tasks-tasklistdeletejobtest
30/37 Test #30: tasks-tasklistdeletejobtest ...   Passed0.24 sec
  Start 31: tasks-tasklistfetchjobtest
31/37 Test #31: tasks-tasklistfetchjobtest    Passed0.23 sec
  Start 32: tasks-tasklistmodifyjobtest
32/37 Test #32: tasks-tasklistmodifyjobtest ...   Passed0.24 sec
  Start 33: drive-aboutfetchjobtest
33/37 Test #33: drive-aboutfetchjobtest ...   Passed0.23 sec
  Start 34: drive-changefetchjobtest
34/37 Test #34: drive-changefetchjobtest ..   Passed0.23 sec
  Start 35: drive-filecopyjobtest
35/37 Test #35: drive-filecopyjobtest .   Passed0.24 sec
  Start 36: drive-filecreatejobtest
36/37 Test #36: drive-filecreatejobtest ...   Passed0.25 sec
  Start 37: drive-filesearchquerytest
37/37 Test #37: drive-filesearchquerytest .   Passed0.22 sec

97% tests passed, 1 tests failed out of 37

Total Test time (real) =  10.13 sec

The following tests FAILED:
 24 - tasks-taskcreatejobtest (Failed)
Errors while running CTest
make[3]: *** [Makefile:86: test] Error 8
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
dh_auto_test: cd obj-x86_64-linux-gnu && make -j1 test ARGS\+=-j1 returned exit 
code 2
make[2]: *** [debian/rules:12: override_dh_auto_test] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.mk:97: 
pre_build-indep_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
make: *** [/usr/share/pkg-kde-tools/qt-kde-team/3/dhmk.mk:112: 
debian/dhmk_build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -A", where
it fails randomly, but it seems to fail almost always here:

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

where you can get a full build log if you need it.

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

Thanks.

Bug#919507: Reboot required patch for Debian policy

[Sean Whitton]

Hello,

On Sat 09 Feb 2019 at 08:47PM -06, Karl O. Pinc wrote:

> Anyway, do whatever you think best.

Having read it a few more times I think both are valid, and will use
your patch unmodified.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Luca Boccassi]

On Wed, 2019-02-13 at 20:57 +0100, Matthijs Kooijman wrote:
> Package: live-build
> Version: 1:20180925
> Severity: wishlist
> 
> Hi folks,
> 
> currently, live-build seems to only support EFI systems using the
> grub-efi bootloader, but not for netboot or hdd images (effectively
> only
> for iso images, I believe).
> 
> Syslinux also has an EFI version, that can be installed through
> the syslinux-efi package. It would be useful for live-build to
> support
> this. I need this for a client, so I'm planning to implement support
> in
> the coming weeks. This report serves to track progress and discuss
> the implementation.
> 
> I've done some experiments by adding syslinux-efi to an existing
> image
> manually (not with a full live-build image, but with my own hdd image
> that at least uses live-build for building the image, so should be
> representative in this area). This shows that adding syslinux-efi is
> fairly easy. The existing FAT partition can function as an ESP (EFI
> System Partition) as it is now.
> 
> Installing the bootloader is a matter of dumping some files in the
> EFI/BOOT directory. This lets the bootloader be detected as a
> fallback
> bootloader, which is AFAIU intended for removable media. Syslinux
> needs
> some additional files (ldlinux, additional modules, configuration)
> which
> can live in that same directory.
> 
> Both 32-bit and 64-bit EFI can be supported at the same time, by
> installing both versions of syslinux-efi (named bootx64.efi and
> bootia32.efi respectively). One caveat is that syslinux needs
> different
> .c32 modules for both architectures (though they are both named .c32
> and
> are explicitly referenced in the config file). This means either
> duplicating the bootloader configuration file for 32 and 64 bit
> (which
> hinders modifications to the config), or putting the modules in
> subdirectories and using the PATH config directive to point to either
> directive before including the common configuration. I have not tried
> this latter approach but it is described here (though currently
> syslinux.org seems to be unavailable, I tried the Google cache):
> 
> https://www.syslinux.org/archives/2014-August/022545.html
> 
> (subject: syslinux efi configuration file name proposal)
> 
> I've also tried to let the syslinux-efi config file include the
> normal
> syslinux configuration file (or at least the bulk that is in
> live.cfg),
> which seems to work just fine.
> 
> Since config sharing is easy and syslinux-efi is a matter of adding
> some
> files to the existing image, it would make sense to add syslinux-efi
> by
> default on normal syslinux hdd images (perhaps adding a new option to
> disable this?). This also seems to hold for ISO9660 images, where
> it seems isohybrid can include a small FAT filesystem with the
> bootloader files. This might need some additional work to generate
> the
> filesystem image and/or pass options when generating the iso. See:
> 
> https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
> 
> 
> Using syslinux-efi exclusively (e.g. passing it to --bootloader and
> not
> installing normal syslinux) might also be an extra option. However,
> I'm
> not much interested in this case, so I will likely not implement it
> (I'll try not to make it too hard to add it later).
> 
> 
> In terms of code, this is probably best implemented in the existing
> binary_syslinux script. The bulk of what needs to happen is
> essentially
> copying bootloader files from config/bootloaders into binary, taking
> care to resolve symlinks. I'm planning to put the code that does that
> into a shell function, so it can be called at the current place and
> then
> a second time for syslinux-efi later.
> 
> I think it would be good to copy files *from*
> config/bootloaders/syslinux-efi-addon or something similar, to leave
> config/bootloaders/syslinux-efi available for an EFI-only image.
> These
> two directories would be identical in terms of syslinux binary files,
> but the configurations would differ (the addon would include the
> normal
> boot/syslinux/syslinux.cfg, while the standalone version would
> contain
> the complete config).
> 
> I haven't really looked at the iso version yet (which is also not my
> primary interest, but I think it would be good to handle as well).
> 
> Happy to hear any thoughts :-)
> 
> Gr.
> 
> Matthijs

Hi,

At a quick glance it all sounds good to me, although I can't say I have
a lot of experience with syslinux.

For feature parity, I'd encourage to look into supporting Secure Boot
like the grub-efi implementation does, since we are preparing to ship
that in Debian 10. It's not much extra work on top of adding the rest
anyway.

-- 
Kind regards,
Luca Boccassi

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

Bug#862887: 14 tests fail gulp

[Xavier]

This outdated version of gulp depends on (at least) outdated
node-vinyl-fs and node-first-chunk-stream and unpackaged
node-glob-watcher. That's why tests fail, this reveals that
"auto-rebuild" feature is unusable. I hope nothing else is broken.

To avoid uploading a major change during Buster freeze, I packaged gulp
with tests related to Gulp.watch() disabled and with a patch to throw an
error that points here if vinyl-fs.watch() is called.

Cheers,
Xavier

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Matthijs Kooijman]

Package: live-build
Version: 1:20180925
Severity: wishlist

Hi folks,

currently, live-build seems to only support EFI systems using the
grub-efi bootloader, but not for netboot or hdd images (effectively only
for iso images, I believe).

Syslinux also has an EFI version, that can be installed through
the syslinux-efi package. It would be useful for live-build to support
this. I need this for a client, so I'm planning to implement support in
the coming weeks. This report serves to track progress and discuss
the implementation.

I've done some experiments by adding syslinux-efi to an existing image
manually (not with a full live-build image, but with my own hdd image
that at least uses live-build for building the image, so should be
representative in this area). This shows that adding syslinux-efi is
fairly easy. The existing FAT partition can function as an ESP (EFI
System Partition) as it is now.

Installing the bootloader is a matter of dumping some files in the
EFI/BOOT directory. This lets the bootloader be detected as a fallback
bootloader, which is AFAIU intended for removable media. Syslinux needs
some additional files (ldlinux, additional modules, configuration) which
can live in that same directory.

Both 32-bit and 64-bit EFI can be supported at the same time, by
installing both versions of syslinux-efi (named bootx64.efi and
bootia32.efi respectively). One caveat is that syslinux needs different
.c32 modules for both architectures (though they are both named .c32 and
are explicitly referenced in the config file). This means either
duplicating the bootloader configuration file for 32 and 64 bit (which
hinders modifications to the config), or putting the modules in
subdirectories and using the PATH config directive to point to either
directive before including the common configuration. I have not tried
this latter approach but it is described here (though currently
syslinux.org seems to be unavailable, I tried the Google cache):

https://www.syslinux.org/archives/2014-August/022545.html

(subject: syslinux efi configuration file name proposal)

I've also tried to let the syslinux-efi config file include the normal
syslinux configuration file (or at least the bulk that is in live.cfg),
which seems to work just fine.

Since config sharing is easy and syslinux-efi is a matter of adding some
files to the existing image, it would make sense to add syslinux-efi by
default on normal syslinux hdd images (perhaps adding a new option to
disable this?). This also seems to hold for ISO9660 images, where
it seems isohybrid can include a small FAT filesystem with the
bootloader files. This might need some additional work to generate the
filesystem image and/or pass options when generating the iso. See:

https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI


Using syslinux-efi exclusively (e.g. passing it to --bootloader and not
installing normal syslinux) might also be an extra option. However, I'm
not much interested in this case, so I will likely not implement it
(I'll try not to make it too hard to add it later).


In terms of code, this is probably best implemented in the existing
binary_syslinux script. The bulk of what needs to happen is essentially
copying bootloader files from config/bootloaders into binary, taking
care to resolve symlinks. I'm planning to put the code that does that
into a shell function, so it can be called at the current place and then
a second time for syslinux-efi later.

I think it would be good to copy files *from*
config/bootloaders/syslinux-efi-addon or something similar, to leave
config/bootloaders/syslinux-efi available for an EFI-only image. These
two directories would be identical in terms of syslinux binary files,
but the configurations would differ (the addon would include the normal
boot/syslinux/syslinux.cfg, while the standalone version would contain
the complete config).

I haven't really looked at the iso version yet (which is also not my
primary interest, but I think it would be good to handle as well).

Happy to hear any thoughts :-)

Gr.

Matthijs

Bug#921737: iproute2: `ip route get` problems with 0.0.0.0 and ::

[Luca Boccassi]

On Tue, 2019-02-12 at 17:15 +, Clément Hertling (Wxcafé) wrote:
> Hey,
> 
> February 11, 2019 6:27 PM, "Luca Boccassi"  wrote:
> 
> > On Fri, 2019-02-08 at 11:55 -0500, Clément 'wxcafé' Hertling wrote:
> > 
> > > Package: iproute2
> > > Version: 4.20.0-2
> > > Severity: normal
> > > Tags: ipv6 upstream
> > > 
> > > When using `ip route get` with 0.0.0.0 or ::, iproute2 shows
> > > multiple
> > > incorrect behaviors:
> > > 
> > > - `ip route get 0.0.0.0/0` answers "need at least a destination
> > > address",
> > > where it should answer with the default route. 0.0.0.0/0 is a
> > > valid
> > > network and it should be possible to query for the default route
> > > that way
> > > - similarly, `ip route get `::/0` also answers "need at least a
> > > destination
> > > address". For the same reason, it should also answer with the
> > > default
> > > route.
> > 
> > Those sound reasonable, can you send a patch upstream and see what
> > they
> > say?
> 
> Sorry, I wouldn't know how to write a patch or which upstream to send
> it to.
> Should I open an issue upstream? Who should I contact for that?
> 
> > 
> > > - finally, `ip route get 0.0.0.0/1`, or any other non-0 netmask,
> > > answers
> > > with "local 0.0.0.0 dev lo src 127.0.0.1 uid 1000", which is
> > > simply
> > > wrong. 0.0.0.0/1 IS NOT routed via lo, and this query should
> > > answer
> > > with the most-specific route for 0.0.0.0/1 or the default if
> > > there
> > > is
> > > no such route. Interestingly, `ip route get 1.0.0.0/1`, while a
> > > query
> > > for the exact same subnet, actually gives the right route (in my
> > > case,
> > > the default route).
> > 
> > The netlink messages sent by iproute2 look exactly the same, apart
> > from
> > the address:
> > 
> > (gdb) p req
> > $17 = {n = {nlmsg_len = 36, nlmsg_type = 26, nlmsg_flags = 1,
> > nlmsg_seq = 0, nlmsg_pid = 0}, r = {
> > rtm_family = 2 '\002', rtm_dst_len = 0 '\000', rtm_src_len = 0
> > '\000', rtm_tos = 0 '\000',
> > rtm_table = 0 '\000', rtm_protocol = 0 '\000', rtm_scope = 0
> > '\000', rtm_type = 0 '\000',
> > rtm_flags = 0}, buf = "\b\000\001", '\000' }
> > 
> > (gdb) p req
> > $13 = {n = {nlmsg_len = 36, nlmsg_type = 26, nlmsg_flags = 1,
> > nlmsg_seq = 0, nlmsg_pid = 0}, r = {
> > rtm_family = 2 '\002', rtm_dst_len = 0 '\000', rtm_src_len = 0
> > '\000', rtm_tos = 0 '\000',
> > rtm_table = 0 '\000', rtm_protocol = 0 '\000', rtm_scope = 0
> > '\000', rtm_type = 0 '\000',
> > rtm_flags = 0}, buf = "\b\000\001\000\001", '\000'  > times>}
> > 
> > So I would guess the issue is in the kernel.
> 
> Same question, should I open an issue to the debian linux package, or
> to the linux kernel directly?

No worries, I'll take care of both if you are not familiar with the
processes

-- 
Kind regards,
Luca Boccassi

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

Bug#922133: src:marionnet: build-depends/depends on cruft packages

[Ralf Treinen]

Hi,

On Tue, Feb 12, 2019 at 08:57:55AM -0500, Scott Kitterman wrote:
> Package: src:marionnet
> Version: 0.90.6+bzr508-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> liblablgtksourceview2-ocaml and liblablgtksourceview2-ocaml-dev are no longer
> built by lablgtk2 and will be removed.  Marionnet build-depends on
> liblablgtksourceview2-ocaml-dev and as a result depends on
> liblablgtksourceview2-ocaml, which lablgtk2 no longer provides.

Stephane Glondu did an upload of lablgtk2 today which puts these two
packages back on the map, so they should be available on the autobuilders
by now or at least very soon.

-Ralf.

Bug#921987: mysqld-akonadi: Could not open required defaults file

[Sandro Knauß]

Hey,

> I used mysql and not mariadb.

well mysql is not in buster.
mysql-5.5 is oldstable
So using mysql can't be a supported case. I strongly encourage you to switch 
to mariadb!

If you need to use mysql, than you find a workaround at the upstream bugreport:
https://bugs.kde.org/show_bug.cgi?id=399346

> As I changed to sqlite3 I can't test with mariadb.

So you get the error with sqlite3 backend? The sqlite3 backend is not 
recommended to be used in production. As sqlite3 lacks about many features of 
a proper sql database.

> Some times ago I tested mariadb, but mariadb didn't start, I forget the 
exact message, but it complaned about unknown version 5.7.

I'm using mariadb without issues for several years now. We had an issue with 
fresh installations, that was solved with 18.08.3-2. But without any concrete 
log messages I can't help.

regards

hefee


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

Bug#921667: lxc, lava-dev: lxc fails to install along lava-dev --install-recommends

[Pierre-Elliott Bécue]

Le 13 février 2019 20:09:33 GMT+01:00, Andreas Beckmann  a 
écrit :
>Control: reassign -1 lxc,apparmor
>Control: found -1 lxc/1:3.1.0+really3.0.3-2
>Control: found -1 apparmor/2.13.2-7
>Control: retitle -1 lxc,apparmor: lxc fails to install in a chroot with
>apparmor installed
>
>On 2019-02-10 20:06, Antonio Terceiro wrote:
>> I can reproduce this on a clean chroot (but not on a clean VM)
>
>I can also reproduce this in piuparts by testing lxc with
>--fake-essential-packages=apparmor (neither lava nor
>--install-recommends needed)
>
>> + apparmor_parser -r -W -T /etc/apparmor.d/lxc-containers
>> Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
>> Use --subdomainfs to override.
>> dpkg: error processing package lxc (--configure):
>>  installed lxc package post-installation script subprocess returned
>error exit status 1
>
>So this is either an lxc or apparmor issue.
>
>
>Andreas

See my staged commits.

https://salsa.debian.org/lxc-team/lxc/commit/a0e6b5f26227236e44ab8ff4cee745228201bb7d

Best regards.
-- 
PEB from my phone.

Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

[Jonas Smedegaard]

Quoting Linda Lapinlampi (2019-02-13 16:41:06)
> On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote:
> > Quoting Jonas Smedegaard (2019-02-12 19:38:57)
> > > I believe this package belongs in contrib, as its only use-case is 
> > > with together with software outside of Debian main.
> > 
> > ...and now posting to the actual bugreport as well.
> 
> I'm not opposed to having this matrix-archive-keyring package in the 
> contrib area, although for comparison I should note 
> leap-archive-keyring has no rdepends, the keyring package is available 
> from Debian's main archive area and is valid for verifying package 
> signatures from leap.se. An example of a package from deb.leap.se is 
> bitmask-core (which is not available in Debian), and it's not in the 
> contrib area in the leap.se repository.
> 
> Maybe this is an error/bug in the leap-archive-keyring package, but it 
> does seem confusing. The other *-archive-keyring packages in Debian 
> main seem to be at least vaguely related to the Debian Project or its 
> teams, although they are all (with the exception of 
> debian-archive-keyring) meant to be used with third-party data sources 
> (usually with APT).

Thanks for comparing with similar packages: That indicates you go that 
extra mile in striving towards perfection in your packaging - Cool!

Please file bugreports for such other packages that you notice - should 
be fine filing such bugs with high severity, since it is a violation of 
a "must" in Debian Policy § 2.2.1.


> As of yesterday, there is also this high-priority debconf(1) question 
> template in the matrix-archive-keyring package:
> 
> Template: matrix-archive-keyring/sources.list
> Type: boolean
> Default: false
> _Description: Use APT data sources from Matrix.org?
>  The Matrix.org Debian package repository distributes supplemental Matrix.org
>  related packages intended to work with the Debian distribution, but require
>  software software outside of the distribution to either build or function.
>  These packages are digitally signed with keys from matrix-archive-keyring.
>  .
>  The Debian Project will be unable to directly support issues faced from using
>  supplemental packages from this third-party repository. Packages from these
>  APT sources may be non-conforming to the technical requirements set in the
>  Debian Policy for the Debian distribution.

Cool!


> (Sorry if I fell under the assumption the package will be usable on 
> Debian only, and not derivative distributions with different names.)
> 
> Choosing "yes" here would obviously enable the contrib bits from the 
> default of "false". And as I said, packages from Matrix.org are 
> already in the contrib area (Section: contrib/*).
> 
> If this debconf(1) question makes it a hard-requirement of contrib 
> archive area, I could split the main parts (keyring) and the 
> debconf(1) question (sources.list) to seperate packages in main and 
> contrib sections respectively if that is more desirable.
> 
> I have currently set the package's "Section:" to "contrib/misc", in 
> any case.
> 
> What do you think?

The addition of a debconf question - with default being false - seems an 
excellent improvement over the package silently activating the keys (if 
that was the previous behaviour - I am only guessing here).

I find the keys themselves to be the reason for the package belonging in 
contrib, however - regardless of adding that nice debconf message.

Thanks a lot for your contribution to Debian!


 - Jonas

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

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


signature.asc
Description: signature

Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

[Linda Lapinlampi]

On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote:
> More important is the question if the system should /trust/ the keys.
> 
> IMHO installing a non-Debian keyring should *not* make the keys trusted
> by APT by default (i.e. with the default answer if debconf is used).

I've agreed, it's the problem I'm trying to solve with this
matrix-archive-keyring package. As said in the OP of Bug#922155 (ITP):

> I have made this package install an OpenPGP-armored keyring to
> /usr/share/keyrings (instead of /etc/apt/trusted.gpg.d);

Since they are not in Dir::Etc::trusted or Dir::Etc::trustedparts, the
system won't trust the Matrix archive keys for APT by default (unless
the sysadmin has explicitly configured otherwise). By default,
sources.list(5) entries will need to specifically have

[signed-by:/usr/share/keyrings/matrix-archive-keyring.gpg]

for APT to trust the data sources with this package.

To clarify, trust to keys in the matrix-archive-keyring package is all a
multi-step opt-in:

1. Using the keyring to manually verify packages from Matrix.org (yes)
2. Trusting the keyring for Matrix.org APT sources (default: no)
3. Trusting the keyring for any APT sources (default: hell no)

What the Internet says to do and what's currently happening in practice:

1. Using the repository key to manually verify packages from Matrix.org
2. Trusting the repository key for Matrix.org APT sources (yes, but...)
3. Trusting the repository key for any APT sources (yikes)

There is an additional low priority debconf(1) question in
matrix-archive-keyring if #3 should be true, but with sane default of
"false" and a warning about it being unnecessary in most cases.
Although it's so trivial, I'm open to removing this option altogether if
desired for lacking much real use.

The other debconf(1) question (#2) serves to answer if the user should
trust packages from the third-party repository. If you meant the
description of that question does not adequately ask if the user should
/trust/ packages from that repository (instead of just mentioning they
are supplemental packages which are not officially supported), would you
like me to change the description for the release to point out trust
more prominently? The alternative may be a seperate contrib package for
a sources.list source.

> ubuntu-keyring does that; most other keyrings sadly do not follow this.

I'd suggest to file bugs. I've found many issues in the past few days.

Bug#921667: lxc, lava-dev: lxc fails to install along lava-dev --install-recommends

[Andreas Beckmann]

Control: reassign -1 lxc,apparmor
Control: found -1 lxc/1:3.1.0+really3.0.3-2
Control: found -1 apparmor/2.13.2-7
Control: retitle -1 lxc,apparmor: lxc fails to install in a chroot with 
apparmor installed

On 2019-02-10 20:06, Antonio Terceiro wrote:
> I can reproduce this on a clean chroot (but not on a clean VM)

I can also reproduce this in piuparts by testing lxc with
--fake-essential-packages=apparmor (neither lava nor --install-recommends 
needed)

> + apparmor_parser -r -W -T /etc/apparmor.d/lxc-containers
> Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
> Use --subdomainfs to override.
> dpkg: error processing package lxc (--configure):
>  installed lxc package post-installation script subprocess returned error 
> exit status 1

So this is either an lxc or apparmor issue.


Andreas

Bug#922249: Unable to cross-compile Ada programs for ARM

[Matthias Klose]

Control: tags -1 + wontfix

This is known, and fixed in gcc-7 and gcc-8.  Won't fix that for gcc-6, already
removed in testing/unstable.  As a workaround, create the bogus symlinks.

On 13.02.19 19:23, Tamas, Flaviu wrote:
> Package: gnat-6-arm-linux-gnueabihf
> Version: 6.3.0-18cross1
> 
> When I invoke `arm-linux-gnueabihf-gnat make hello.adb`, I
> get the following output:
> 
> # arm-linux-gnueabihf-gnat make hello.adb
> arm-linux-gnueabihf-gnatbind-6 -x hello.ali
> arm-linux-gnueabihf-gnatlink-6 hello.ali
> arm-linux-gnueabihf-gnatlink-6: Couldn't locate arm-linux-gnueabihf-gcc-6-6
> arm-linux-gnueabihf-gnatmake: *** link failed.
> 
> I would instead expect this to produce an excutable instead
> of erroring. `hello.adb` is a basic "hello world":
> 
> with Ada.Text_IO;
> procedure Hello is
> begin
> Ada.Text_IO.Put_Line("Hello, world!");
> end Hello;
> 
> I'm not sure how to fix this. I would expect that some
> changes to the build script are required so that gnat uses
> "arm-linux-gnueabihf-gcc" instead of
> "arm-linux-gnueabihf-gcc-6-6"
> 
> --
> 
> Additionally, there is another bug where
> gnat-6-arm-linux-gnueabihf does not depend on libgnat-6,
> despite libgnat-6 being required on the host:
> 
> # ldd /usr/bin/arm-linux-gnueabihf-gnat
> linux-vdso.so.1 (0x7ffc0daeb000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
> (0x7fe17ae5b000)
> libgnat-6.so.1 => /usr/lib/x86_64-linux-gnu/libgnat-6.so.1 
> (0x7fe17a8d)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe17a531000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe17a22d000)
> /lib64/ld-linux-x86-64.so.2 (0x7fe17b1dd000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
> (0x7fe17a016000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fe179e12000)
> 
> Before installing the libgnat-6 package,
> arm-linux-gnueabihf-gnat would refuse to run.
> 
> I am using Debian Stretch inside Docker, with all updates
> applied. libc v2.24-11+deb9u3.
> 

Bug#922250: Debian 10 Alpha 5 successfully installed at Asus Zenbook UX501J

[Bernhard]

Package: installation-reports

Boot method: PXE Network with Syslinux/UEFI
Image version: Debian 10 Alpha 5
Date: 2018-02-12

Machine: Asus Zenbook Pro UX501J
Processor: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
Memory: 16GB
Partitions:

> DateisystemTyp  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
> udev   devtmpfs   8141184   0   81411840% /dev
> tmpfs  tmpfs  1631296   17328   16139682% /run
> /dev/sda2  ext4 105628416 7026188  931935648% /
> tmpfs  tmpfs  81564803524   81529561% /dev/shm
> tmpfs  tmpfs 5120   4  51161% /run/lock
> tmpfs  tmpfs  8156480   0   81564800% /sys/fs/cgroup
> /dev/sda1  vfat523248 1325231161% /boot/efi
> tmpfs  tmpfs  1631296  48   16312481% /run/user/1000

Output of lspci -knn:

> 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor DRAM Controller [8086:0c04] (rev 06)
>   Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor 
> DRAM Controller [1043:18dd]
>   Kernel modules: ie31200_edac
> 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor PCI Express x16 Controller [8086:0c01] (rev 06)
>   Kernel driver in use: pcieport
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
> Processor Integrated Graphics Controller [8086:0416] (rev 06)
>   Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor Integrated 
> Graphics Controller [1043:18dd]
>   Kernel driver in use: i915
>   Kernel modules: i915
> 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor HD Audio Controller [8086:0c0c] (rev 06)
>   Subsystem: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD 
> Audio Controller [8086:2010]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB xHCI [8086:8c31] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB xHCI [1043:18dd]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 
> Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> MEI Controller [1043:18dd]
>   Kernel driver in use: mei_me
>   Kernel modules: mei_me
> 00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB EHCI #2 [8086:8c2d] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB EHCI [1043:18dd]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset 
> High Definition Audio Controller [8086:8c20] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset High 
> Definition Audio Controller [1043:18dd]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #1 [8086:8c10] (rev d5)
>   Kernel driver in use: pcieport
> 00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #3 [8086:8c14] (rev d5)
>   Kernel driver in use: pcieport
> 00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #4 [8086:8c16] (rev d5)
>   Kernel driver in use: pcieport
> 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB EHCI #1 [8086:8c26] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB EHCI [1043:18dd]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:1f.0 ISA bridge [0601]: Intel Corporation HM87 Express LPC Controller 
> [8086:8c4b] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. HM87 Express LPC Controller [1043:18dd]
>   Kernel driver in use: lpc_ich
>   Kernel modules: lpc_ich
> 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series 
> Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c03] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> 6-port SATA Controller 1 [AHCI mode] [1043:18dd]
>   Kernel driver in use: ahci
>   Kernel modules: ahci
> 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family 
> SMBus Controller [8086:8c22] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> SMBus Controller [1043:18dd]
>   Kernel driver in use: i801_smbus
>   Kernel modules: i2c_i801
> 01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX 960M] 
> 

Bug#922240: ftp.debian.org: consider switching to merged pdiffs

[Niels Thykier]

On Wed, 13 Feb 2019 17:32:24 +0100 Julian Andres Klode 
wrote:
> Package: ftp.debian.org
> Severity: wishlist
> 
> 
> I'd like to reopen the discussion about the pdiff format on
> the archive. Currently a pdiff is generated for each generation
> of the archive, which means that apt has to fetch 4 pdiffs per
> day it has to catch up.
> 
> This means that for a 10 day interval, we have to fetch 40 pdiffs
> per index. Assuming amd64+i386 with Contents files and Sources
> enabled, we are looking at 2*(1+1+1)*40=6*40=240 files to fetch.
> 
> This is clearly suboptimal, as it makes the log output unreadable,
> and causes severe slowdowns on high-latency or non-persistent
> connections.
> 
> It might make sense to consider switching to merged pdiffs, which generate
> one Pdiff from each generation to the latest one. This can be done either
> by preserving old index files and creating pdiffs from them, or simply by
> concatenating the new pdiff to the old ones.
> 
> A point against it could be increased space requirements and time to
> compress the pdiffs, but I'd welcome more discussion on that subject.
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
> 
> 

On a related note, the last known blocker for #649882 is solved.
If/when #649882 is implemented, we will have even more PDiffs by default
for apt-file at the trade-off of making the Contents file smaller
(particular multi-arch setups will benefit there).  I suspect it will
also off-set any grows in PDiffs being merged server side.

Thanks,
~Niels

Bug#921819: Please consider dropping dependency on s6 / s6-setuidgid

[Michael Biebl]

Am 09.02.19 um 23:26 schrieb Francesco Poli:
> On Sat, 9 Feb 2019 22:31:14 +0100 Michael Biebl wrote:
> 
>> Hi
>>
>> Am 09.02.19 um 10:39 schrieb Francesco Poli:
>>
>>> Could you please do me a favor?
>>> I would like you to read bug [#916753] log and then tell me what you
>>> think. Your insight might be useful to find a better solution.
>>
>> What kind of input do you need?
> 
> I would like some insight especially on [message #30], regarding the
> fact that runuser does something basically equivalent to what su does,
> and thus seems to be unfit to irreversibly drop root privileges, and
> regarding my search for a command that works like s6-setuidgid, but
> runs the given command inside the user's login shell (with all the
> environment that the user would get on a normal login).

Aren't those conflicting requirements?
On the one hand you want a full login shell, which typically involves
PAM. On the other hand you don't want PAM involved.

> [message #30]: 
> 
>> I guess I already mentioned the two alternatives (runuser/setpriv).
> [...]
> 
> Maybe setpriv is equivalent to s6-setuidgid.
> If this is the case, it can be used as an alternative to s6-setuidgid.

setpriv should do pretty much the same as s6-setuidgid, with the benefit
of not requiring an exotic package being installed.

> But I would like to have a command that runs a given command inside the
> regular user's login environment, as I said above.
> Do you know one such command?

What exactly do you mean by "user's login environment"?

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



signature.asc
Description: OpenPGP digital signature

Bug#922249: Unable to cross-compile Ada programs for ARM

[Tamas, Flaviu]

Package: gnat-6-arm-linux-gnueabihf
Version: 6.3.0-18cross1

When I invoke `arm-linux-gnueabihf-gnat make hello.adb`, I
get the following output:

# arm-linux-gnueabihf-gnat make hello.adb
arm-linux-gnueabihf-gnatbind-6 -x hello.ali
arm-linux-gnueabihf-gnatlink-6 hello.ali
arm-linux-gnueabihf-gnatlink-6: Couldn't locate arm-linux-gnueabihf-gcc-6-6
arm-linux-gnueabihf-gnatmake: *** link failed.

I would instead expect this to produce an excutable instead
of erroring. `hello.adb` is a basic "hello world":

with Ada.Text_IO;
procedure Hello is
begin
Ada.Text_IO.Put_Line("Hello, world!");
end Hello;

I'm not sure how to fix this. I would expect that some
changes to the build script are required so that gnat uses
"arm-linux-gnueabihf-gcc" instead of
"arm-linux-gnueabihf-gcc-6-6"

--

Additionally, there is another bug where
gnat-6-arm-linux-gnueabihf does not depend on libgnat-6,
despite libgnat-6 being required on the host:

# ldd /usr/bin/arm-linux-gnueabihf-gnat
linux-vdso.so.1 (0x7ffc0daeb000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fe17ae5b000)
libgnat-6.so.1 => /usr/lib/x86_64-linux-gnu/libgnat-6.so.1 
(0x7fe17a8d)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe17a531000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe17a22d000)
/lib64/ld-linux-x86-64.so.2 (0x7fe17b1dd000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fe17a016000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fe179e12000)

Before installing the libgnat-6 package,
arm-linux-gnueabihf-gnat would refuse to run.

I am using Debian Stretch inside Docker, with all updates
applied. libc v2.24-11+deb9u3.

Bug#859122: about 500 DLAs missing from the website

[Holger Levsen]

On Mon, Feb 11, 2019 at 03:56:41PM -0500, Antoine Beaupré wrote:
> It's true there's a lot of junk in there... I suspect most of the `.pl`
> scripts in there could actually be symlink to the main secteam scripts,
> because they are basically the same.
> 
> I also suspect most of the stuff is unused, even from the secteam's
> point of view. For example, `check-cve-refs.pl` assumes there's a
> `security/data` directory in the website, which is not the case
> (anymore?). 

I'll also leave that to the security/www teams considerations ;)

> I would suggest removing those from at least the LTS
> section and have done so in the following MR:
> https://salsa.debian.org/webmaster-team/webwml/merge_requests/55

I've reviewed, merged and pushed this now. Thank you!

 
> > * This new /lts section of the website is not referenced yet in other
> > places of the Debian website. I'm not sure if it should be referenced in
> > /security, in /releases/, or in both. There is also the temptation
> > of creating a link in the homepage but there is also the suggestion of
> > reducing the links in the homepage, so... For now, I'll try to add it to
> > the sitemap and see how many references to the LTS wiki page we have
> > currently, to see if any of them can be replaced with link to this
> > section in the website. But I'll wait some days to do it because it's
> > not clear for me if you want to populate the section to cover all the
> > aspects of LTS, or keep it only/mainly for security stuff.
> I would avoid putting the LTS work too proeminently on the website at
> this point, to be honest. The goal of publishing those advisories there,
> for me, is coherence: they were already partly present and I wanted to
> have them *all* available *somewhere* with a predictable URL and RSS
> feeds (as opposed to, say the mailing list).
 
agreed.

> We shouldn't get into the slippery debate of how much we want LTS
> content on the website, in my opinion.

at least for here and now! :)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature