Bug#932389: gnome-sound-recorder crashes when trying to play back a recording

[Tarik Graba]

Hi there,

I can confirm having the same bug here since upgrading to Buster.

The bug seems to be identified and corrected upstream:

https://gitlab.gnome.org/GNOME/gjs/issues/223

I don't know if it is easy to apply the proposed patch to the Debian
version.

Tarik

Bug#934767: ecbuild: please make the build reproducible

[Chris Lamb]

Source: ecbuild
Version: 3.0.3-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that ecbuild could not be built reproducibly.

This is due to it shipping /usr/lib/cmake/ecbuild/ecbuild-import.cmake
which contains the absolute build path:

│ │ │ │ @@ -1,9 +1,9 @@
│ │ │ │  if(ecbuild_IS_BUILD_DIR_EXPORT)
│ │ │ │ -  set(ecbuild_MACROS_DIR /build/1st/ecbuild-3.0.3/cmake)
│ │ │ │ +  set(ecbuild_MACROS_DIR /build/2/ecbuild-3.0.3/2nd/cmake)
│ │ │ │  else()

A patch is attached that replaces the build dir in the installed
package to /usr/share/ecbuild/cmake.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-08-14 08:17:56.207222971 -0700
--- b/debian/rules  2019-08-14 08:26:29.084849212 -0700
@@ -9,3 +9,7 @@
dh_fixperms
chmod +x debian/ecbuild/usr/share/ecbuild/cmake/sg.pl
chmod -x 
debian/ecbuild/usr/share/ecbuild/toolchains/preprocess_cray_fortran
+
+override_dh_install:
+   dh_install
+   sed -i -e 's@$(CURDIR)@/usr/share/ecbuild@g' 
debian/ecbuild/usr/lib/cmake/ecbuild/ecbuild-import.cmake

Bug#934766: libexosip2: CVE-2014-10375

[Salvatore Bonaccorso]

Source: libexosip2
Version: 4.1.0-2.1
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for libexosip2.

CVE-2014-10375[0]:
| handle_messages in eXtl_tls.c in eXosip before 5.0.0 mishandles a
| negative value in a content-length header.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2014-10375
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-10375
[1] 
http://git.savannah.nongnu.org/cgit/exosip.git/commit/?id=2549e421c14aff886629b8482c14af800f411070

Regards,
Salvatore

Bug#871945: mercurial: suboptimal diff compared to previous versions

[Vincent Lefevre]

On 2019-08-14 14:37:45 +0200, Julien Cristau wrote:
> On Sun, Aug 13, 2017 at 12:01:49AM +0200, Vincent Lefevre wrote:
> > Control: forwarded -1 https://bz.mercurial-scm.org/show_bug.cgi?id=5656
> > 
> > I've reported this bug upstream.
> > 
> Thanks for doing that.  As the upstream issue was resolved as wontfix,
> I'm doing the same here.

OK, the Mutt repository has migrated to git anyway.

If someone else is affected by this issue, I think that a workaround
is to use the extdiff extension, as the GNU diff output was fine on
the example I had provided.

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

Bug#934765: ITP: ruby-omniauth-ultraauth -- Omniauth strategy for UltraAuth

[Samyak Jain]

Package: wnpp
Severity: wishlist
Owner: Samyak Jain 

* Package name: ruby-omniauth-ultraauth
  Version : 0.0.2
  Upstream Author : 2019, Kartikey Tanna 
* URL : https://github.com/ultraauth/omniauth-ultraauth
* License : Expat
  Programming Lang: Ruby
  Description : Object Oriented DOM Tree in Ruby

 OmniAuth is a Ruby library that standardizes multi-provider
authentication for web applications. It was created to be powerful,
flexible, and do as little as possible. Any developer can create
strategies for OmniAuth that can authenticate users via disparate
systems. OmniAuth strategies have been created for everything from
Facebook to LDAP.

 Eliminate customer phishing / hijacking and increase user
satisfaction with password-less authentication.


It is a dependency for loomio and hence needs to be packaged.

Thanks,
Samyak Jain

Bug#934764: RFS: ycm-cmake-modules/0.10.4-2 [ITP] -- Extra CMake Modules for YARP and friends

[Daniele E. Domenichelli]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ycm-cmake-modules"

* Package name: ycm-cmake-modules
  Version : 0.10.4-2
  Upstream Author : Istituto Italiano di Tecnologia (IIT)
* URL : https://github.com/robotology/ycm/ 
* License : BSD-3-Clause
  Section : libs

It builds those binary packages:

  ycm-cmake-modules - Extra CMake Modules for YARP and friends

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

https://mentors.debian.net/package/ycm-cmake-modules


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

  dget -x 
https://mentors.debian.net/debian/pool/main/y/ycm-cmake-modules/ycm-cmake-modules_0.10.4-2.dsc

More information about ycm-cmake-modules can be obtained from 
https://www.example.com.

Changes since the last upload:

  * Initial release (Closes: #934757)


Regards,
 Daniele E. Domenichelli

Bug#934763: wireguard-dkms: kernel module fails to build with latest Stretch linux kernel sources

[Thomas Kapoulas]

Package: wireguard-dkms
Version: 0.0.20190702-1
Severity: important

Hello, wireguard-dkms failed to build its module on a Debian Stretch 
system with the latest kernel (4.9.0-9-amd64). Although it works with 
the previous one (4.9.0-8-amd64).


root@debian# apt install wireguard
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dkms linux-headers-4.9.0-9-amd64 linux-headers-4.9.0-9-common 
linux-headers-amd64 wireguard-dkms wireguard-tools

Suggested packages:
  python3-apport menu
The following NEW packages will be installed:
  dkms linux-headers-4.9.0-9-amd64 linux-headers-4.9.0-9-common 
linux-headers-amd64 wireguard wireguard-dkms

  wireguard-tools
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 8,207 kB/8,589 kB of archives.
After this operation, 52.4 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://security.debian.org/debian-security stretch/updates/main 
amd64 linux-headers-4.9.0-9-common all 4.9.168-1+deb9u5 [7,677 kB]
Get:2 http://security.debian.org/debian-security stretch/updates/main 
amd64 linux-headers-4.9.0-9-amd64 amd64 4.9.168-1+deb9u5 [449 kB]
Get:3 http://cdn-aws.deb.debian.org/debian stretch/main amd64 dkms all 
2.3-2 [74.8 kB]
Get:4 http://cdn-aws.deb.debian.org/debian stretch/main amd64 
linux-headers-amd64 amd64 4.9+80+deb9u7 [6,040 B]

Fetched 8,207 kB in 0s (12.7 MB/s)
Selecting previously unselected package dkms.
(Reading database ... 91286 files and directories currently installed.)
Preparing to unpack .../0-dkms_2.3-2_all.deb ...
Unpacking dkms (2.3-2) ...
Selecting previously unselected package linux-headers-4.9.0-9-common.
Preparing to unpack 
.../1-linux-headers-4.9.0-9-common_4.9.168-1+deb9u5_all.deb ...

Unpacking linux-headers-4.9.0-9-common (4.9.168-1+deb9u5) ...
Selecting previously unselected package linux-headers-4.9.0-9-amd64.
Preparing to unpack 
.../2-linux-headers-4.9.0-9-amd64_4.9.168-1+deb9u5_amd64.deb ...

Unpacking linux-headers-4.9.0-9-amd64 (4.9.168-1+deb9u5) ...
Selecting previously unselected package linux-headers-amd64.
Preparing to unpack .../3-linux-headers-amd64_4.9+80+deb9u7_amd64.deb 
...

Unpacking linux-headers-amd64 (4.9+80+deb9u7) ...
Selecting previously unselected package wireguard-dkms.
Preparing to unpack .../4-wireguard-dkms_0.0.20190702-1_all.deb ...
Unpacking wireguard-dkms (0.0.20190702-1) ...
Selecting previously unselected package wireguard-tools.
Preparing to unpack .../5-wireguard-tools_0.0.20190702-1_amd64.deb ...
Unpacking wireguard-tools (0.0.20190702-1) ...
Selecting previously unselected package wireguard.
Preparing to unpack .../6-wireguard_0.0.20190702-1_all.deb ...
Unpacking wireguard (0.0.20190702-1) ...
Setting up wireguard-tools (0.0.20190702-1) ...
Setting up linux-headers-4.9.0-9-common (4.9.168-1+deb9u5) ...
Setting up dkms (2.3-2) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up wireguard-dkms (0.0.20190702-1) ...
Loading new wireguard-0.0.20190702 DKMS files...
Building for 4.9.0-9-amd64
Building initial module for 4.9.0-9-amd64
Error! Bad return status for module build on kernel: 4.9.0-9-amd64 
(x86_64)
Consult /var/lib/dkms/wireguard/0.0.20190702/build/make.log for more 
information.

Setting up linux-headers-4.9.0-9-amd64 (4.9.168-1+deb9u5) ...
/etc/kernel/header_postinst.d/dkms:
Error! Bad return status for module build on kernel: 4.9.0-9-amd64 
(x86_64)
Consult /var/lib/dkms/wireguard/0.0.20190702/build/make.log for more 
information.

Setting up wireguard (0.0.20190702-1) ...
Setting up linux-headers-amd64 (4.9+80+deb9u7) ...

root@debian# cat /var/lib/dkms/wireguard/0.0.20190702/build/make.log
DKMS make.log for wireguard-0.0.20190702 for kernel 4.9.0-9-amd64 
(x86_64)

Wed Aug 14 14:30:29 UTC 2019
make: Entering directory '/usr/src/linux-headers-4.9.0-9-amd64'
  LD  /var/lib/dkms/wireguard/0.0.20190702/build/built-in.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/main.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/device.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/peer.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/timers.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/queueing.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/send.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/receive.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/socket.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/peerlookup.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/allowedips.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190702/build/ratelimiter.o
/var/lib/dkms/wireguard/0.0.20190702/build/ratelimiter.c:25:8: error: 
unknown type name ‘hsiphash_key_t’

 static hsiphash_key_t key;
^~
/var/lib/dkms/wireguard/0.0.20190702/build/ratelimiter.c: In function 
‘wg_ratelimiter_allow’:

Bug#934762: new upstream (1.39.2)

[Daniel Baumann]

Package: nghttp2
Severity: normal

Hi,

1.39.2 was released with some DoS fixed. It would be nice if you could
upload it to unstable.

Regards,
Daniel

Bug#934761: exim4: 2) Callout timeout in recipient verify can result in the lost of the TLS incoming connexion

[Martin Duspiva]

Package: exim4
Version: 4.92-8+deb10u1~bpo9+1
Severity: normal
Tags: upstream

Dear Maintainer,

I think that the bug #887489, which is  already archived, is still persist.
I have Debin 9 with backported Exim4 ( 4.92-8+deb10u1~bpo9+1 ) and the callout 
funciton in rcpt acl has  as the same bad behavior as described in bug #887489.

My acl rule in acl_smtp_rcpt :

  accept hosts =  +relay_from_hosts
!verify = recipient/defer_ok/callout=30s,defer_ok,use_sender
ratelimit = NONEX_LIM / NONEX_PERIOD / per_rcpt / relayuser-$acl_m_user
continue = ${run{SHELL -c "echo $acl_m_user \
   >>$spool_directory/blocked_relay_users; \
   \N{\N echo Subject: relay user $acl_m_user blocked; echo; echo \
   because has sent mail to NONEX_LIM invalid recipients during 
NONEX_PERIOD.; \
   \N}\N | NONEX_EXIMBINARY NONEX_WARNTO"}}
control = freeze/no_tell
control = submission/domain=
add_header = X-Relayed-From: $acl_m_user

And relay hosts sometimes get te following 421 error when sending email:
"SMTP command timeout on TLS connection from of.aira.cz (remote.aira.cz) 
[84.242.100.166]"


This is in Exim's debug log:

 5272 tls_write(0x5639a0cfa550, 14)
 5272 gnutls_record_send(SSL, 0x5639a0cfa550, 14)
 5272 outbytes=14
 5272 DSN: orcpt: NULL  flags: 0
 5272 Calling gnutls_record_recv(0x5639a0d8d410, 0x5639a11560e0, 4096)
 5272 GnuTLS<3>: ASSERT: buffers.c[_gnutls_io_read_buffered]:587
 5272 GnuTLS<3>: ASSERT: record.c[_gnutls_recv_int]:1473
 5272 LOG: lost_incoming_connection MAIN
 5272   SMTP command timeout on TLS connection from of.aira.cz (remote.aira.cz) 
[84.242.100.166]
 5272 SMTP>> 421 holub.aira.cz: SMTP command timeout - closing connection

The acl works well with comment out "callout" line. 


exim4: 2) Callout timeout in recipient verify can result in the lost of the TLS 
incoming connexion 


-- Package-specific info:
Exim version 4.92 #3 built 21-Jul-2019 09:43:55
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event OCSP PRDR PROXY 
SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /etc/exim4/exim4.conf
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='local'
dc_other_hostnames='holub.aira.cz'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
mailname:holub.aira.cz
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='10m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# options for daemon listening on port 25
SMTPLISTENEROPTIONS=''

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 

Bug#934744: Acknowledgement (Installation of the boot loader to e.g. USB-Sticks is confusing and inconsistent.)

[Michel Firholz]

Please let me precise the problem.
Once the main installation process is finished you get into the options of 
installing the boot record.

Following message gets displayed:

  The following other operating systems have been detected on this computer: 
[..]
  If all of your operating systems are listed above, then it should be safe to 
install the boot loader to the monster boot record of your first hard drive. 
  When your computer boots, you will be able to choose to load one of the seas 
operating systems on your new system.
  Install the GRUB boot loader to the master boot record?  "

Everybody would understand that the next step would install directly the GRUB 
loader to the hard disk,
Pretty nobody would expect that the next step would be asking where to install 
the GRUB loader!

So, if you need the boot loader installed on the USB stick, it is natural to 
answer that question with  instead of  .

Then you come into the confusing process displaying the UUIDS and telling that 
you must install GRUB...

If you answer , then the process is straightforward.

IMHO this can easily be improved as requested in my first mail.

Regards and thanks for considering.


Michel Firholz

-Original Message-
From: Debian Bug Tracking System  
Sent: Wednesday, August 14, 2019 12:48 PM
To: Michel Firholz 
Subject: Bug#934744: Acknowledgement (Installation of the boot loader to e.g. 
USB-Sticks is confusing and inconsistent.)

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 934744: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934744.

This is an automatically generated reply to let you know your message has been 
received.

Your message is being forwarded to the package maintainers and other interested 
parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Install Team 

If you wish to submit further information on this problem, please send it to 
934...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish to report a 
problem with the Bug-tracking system.

--
934744: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934744
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#934760: update node-style-loader to 0.23.1

[Pirate Praveen]

package: rainloop
severity: important
version: 1.12.1-2

I have uploaded ruby-style-loader 0.23.1 to experimental. This is just 
a heads up before I upload it to unstable. As per
 
I don't see any breaking changes. In some days I will upload this to 
unstable. In the worst case scenario if it is not compatible we can 
embed old style-loader in rainloop.

Bug#934759: ITP: ruby-sassc-rails -- Integrate SassC-Ruby into Rails

[Sruthi Chandran]

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

* Package name: ruby-sassc-rails
  Version : 2.1.2
  Upstream Author : Ryan Boland
* URL : https://github.com/sass/sassc-rails
* License : Expat
  Description : Integrate SassC-Ruby into Rails
 Compilation of Sass can take quite a long time for larger codebases.
This gem integrates the C implementation of Sass, LibSass, into the
asset pipeline. In one larger project, this made compilation 4x faster.
 .
 This should essentially be a drop in alternative to sass-rails.



signature.asc
Description: OpenPGP digital signature

Bug#934482: prctl: probably shouldn't be in testing/stable

[Andreas Beckmann]

Control: tag -1 moreinfo

On Sun, 11 Aug 2019 15:09:15 +0200 Ivo De Decker  wrote:
> The buildd 'Packages-arch-specific' configuration has this line for prct:
> 
> %prctl: hppa ia64 alpha powerpc # 
> ANAIS based on syscall availability
> 
> https://buildd.debian.org/quinn-diff/sid/Packages-arch-specific
> 
> As can be seen from the buildd page, this means that it will never be built
> for any release architecture:
> 
> https://buildd.debian.org/status/package.php?p=prctl
> 
> However, prctl has a binary on am64. Either the Packages-arch-specific is
> wrong, or the package is unusable there and should be removed.
> 
> If it doens't have a working binary on any release architecture, it shouldn't
> be in a release.

The package builds for me on amd64, i386, armhf (pbuilder chroots, armhf
via qemu). The existing amd64 binary works, i.e. I was able to query and
change the mcekill setting. (More settings are not supported, maybe
architecture/kernel/cpu dependent).

So maybe the packages-arch-specific setting is wrong.


Andreas

Bug#934758: DKMS module fails to build for linux 5.2.0-2

[Ryan Kavanagh]

Package: openafs-modules-dkms
Version: 1.8.2-1
Severity: grave
Justification: renders package unusable

The openafs DKMS module fails to build for Linux kernel 5.2.0-2.
This renders openafs unusable. I have attached the build log containing
the error messages, in particular, it seems to have something to do
with:

/var/lib/dkms/openafs/1.8.2/build/src/crypto/hcrypto/kernel/config.h: In 
function ‘gettimeofday’:
/var/lib/dkms/openafs/1.8.2/build/src/afs/LINUX/osi_machdep.h:85:22: error: 
‘xtime’ undeclared (first use in this function); did you mean ‘vtime’?
 # define osi_Time() (xtime.tv_sec)
  ^

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

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

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.7.1-2
ii  libc6-dev  2.28-10
ii  perl   5.28.1-6

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.8.2-1

openafs-modules-dkms suggests no packages.

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
DKMS make.log for openafs-1.8.2 for kernel 5.2.0-2-amd64 (x86_64)
Wed Aug 14 09:45:20 EDT 2019
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/bin/bash: /var/lib/dkms/openafs/1.8.2/build/build-tools/missing: No such file 
or directory
configure: WARNING: 'missing' script is too old or missing
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... none
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libxslt... no
checking for saxon... no
checking for xalan-j... no
checking for xsltproc... xsltproc
checking for fop... no
checking for dblatex... no
checking for docbook2pdf... no
configure: WARNING: Docbook stylesheets not found; some documentation can't be 
built
checking for kindlegen... no
checking for doxygen... no
checking for dot... dot
checking for library containing strerror... none required
checking for pid_t... yes
checking for size_t... yes
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for bison... bison -y
checking if lex is flex... yes
checking whether byte order is known at compile time... yes
checking whether byte ordering is bigendian... no
checking whether printf understands the %z length modifier... yes
checking your OS... linux
checking for ranlib... (cached) ranlib
checking for as... as
checking for ar... ar
checking for mv... mv
checking for rm... rm
checking for ld... ld
checking for cp... cp
checking for strip... strip
checking for gencat... gencat
checking if gcc accepts -march=pentium... no
checking if gcc needs -fno-strength-reduce... yes
checking if gcc needs -fno-strict-aliasing... yes
checking if gcc supports -fno-common... yes
checking if gcc supports -pipe... yes
checking if linux kbuild requires EXTRA_CFLAGS... no
checking if linux kernel module build works... yes
checking operation follow_link in 

Bug#933736: [pkg-uWSGI-devel] Bug#933736: uwsgi-plugin-php: Please include "for php7 return failures only on failure"

[Jonas Smedegaard]

Quoting Alexandre Rossi (2019-08-14 15:10:58)
> > > > Should I push directly to master, send a patcht o the mailing list 
> > > > or propose a pull request in salsa, or other?
> > > 
> > > The fix has been pushed to master.
> > 
> > Good.  But where is that, exactly?  URL?
> 
> https://salsa.debian.org/uwsgi-team/uwsgi/commit/78c4ab534609f01b30ebcc2560e269bd78af6c0d

Ah, silly me - I was looking at the -php project which contains zero 
upstream code.

Looks good - I just prefer having patches more tight so will tidy up the 
ones recently added by others than myself, then release.

Nice!

 - Jonas

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

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

Bug#933060: About qiskit package reorganisation

[Frédéric Bonnard]

Hi,
I think it would help to distinguish between upstream github source repos,
debian source packages and debian binary packages to better understand
all the past and current naming.

Previously :

Github source|  Debian source packages  |  Debian binary packages 
---
Qiskit/qiskit|  src:qiskit-terra|  qasm-simulator-cpp [any]
 |  |  python3-qiskit [all]
 |  |  qiskit-doc [all]

Now :

Github source|  Debian source packages  |  Debian binary packages 
---
Qiskit/qiskit-terra  |  src:qiskit-terra|  python3-qiskit-terra pka 
python3-qiskit [all]
---
Qiskit/qiskit-aer|  src:qiskit-aer  |  qiskit-aer pka 
qasm-simulator-cpp [any]
---
Qiskit/qiskit|  src:qiskit-doc  |  qiskit-doc [all]


Am I correct restating things this way ?
Dependencies (runtime/build) on the Debian side are dealt by each
package not the pip setup so Qiskit/qiskit's role would only be to
provide documentation, thus the src:qiskit-doc Debian source package name.

The point is, if one starts reworking the packaging, we should not
undergo another package (upstream/source/binary) renaming too often.
The condition for packaging in Debian is also that the upstream software
should be in a stable state.

F.


pgpjY2xolHs1s.pgp
Description: PGP signature

Bug#934749: welle.io: some icons & widgets not displayed

[Gürkan Myczko]

Dear Fab,

Are you on irc? I'm tarzeau there.

Could you provide me the output of lsusb, only the line of which rtl-sdr 
usb stick you use

And the output of welle-io in from a terminal?

Best,

Bug#934453: curl: SSL

[Johannes Schauer]

Hi Sebastian & Kurt,

Quoting Sebastian Andrzej Siewior (2019-08-13 21:09:35)
> On 2019-08-12 23:59:10 [+0200], Kurt Roeckx wrote:
> > > Kurt, could we get something into OpenSSL (aka openssl s_client
> > > -connect) which describes the error more accurate / verbose?
> > > I will try to collect some information and point the ssllabs people to
> > > it hoping that it will pop up in the server rating…
> > The error is very clear to me. The server picked a signature
> > algorithm that the client didn't offer.
> signature algorithm used for the key-exchange (forward-security) if I'm
> not mistaken. My point is that with more information here, we maybe
> could avoid being involved :)
> I don't know if the problem is a bug in an older openssl version or a
> bad configarion used on the server side.
> 
> > Should I try to contact
> > level 3?
> 
> Yes, please. As an openssl dev you might have more luck. With a template
> I would ping the ssllabs folks :)

thanks a lot for looking into this issue.

I would volunteer to help somehow as well but so far I don't know enough to be
of any help, I'm afraid. I wouldn't even know how to show that the server
picked a signature algorithm that the client didn't offer.

Thanks a lot to you both and tell me if there is anything I can do.

cheers, josch


signature.asc
Description: signature

Bug#934757: ITP: ycm-cmake-modules -- Extra CMake Modules for YARP and friends

[Daniele E. Domenichelli]

Package: wnpp
Severity: wishlist
Owner: "Daniele E. Domenichelli" 

* Package name: ycm-cmake-modules
  Version : 0.10.4
  Upstream Author : Istituto Italiano di Tecnologia (IIT)
* URL : https://github.com/robotology/ycm/ 
* License : BSD-3-Clause
  Programming Lang: CMake
  Description : Extra CMake Modules for YARP and friends

The package YCM contains a set of CMake files that support creation and
maintenance of repositories and software packages. YCM has been written
with the aim of solving some of the problems encountered while managing
large research projects but it can be used outside it initial context.

YCM is not a replacement to CMake or yet another build system. YCM is
just a thin layer over CMake. It does not add extra dependencies like
other build systems, it does not use Python, Ruby, or other scripting
languages, it is written using CMake language. It is a collection of
CMake modules, most of them candidate for being contributed upstream.

Bug#933736: [pkg-uWSGI-devel] Bug#933736: uwsgi-plugin-php: Please include "for php7 return failures only on failure"

[Alexandre Rossi]

> > > Should I push directly to master, send a patcht o the mailing list 
> > > or propose a pull request in salsa, or other?
> > 
> > The fix has been pushed to master.
> 
> Good.  But where is that, exactly?  URL?

https://salsa.debian.org/uwsgi-team/uwsgi/commit/78c4ab534609f01b30ebcc2560e269bd78af6c0d

Alex

Bug#934756: ITP: ruby-omniauth-salesforce -- OmniAuth strategy for salesforce.com

[Sruthi Chandran]

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

* Package name: ruby-omniauth-salesforce
  Version : 1.0.5
  Upstream Author : Richard Vanhook
* URL : https://github.com/realdoug/omniauth-salesforce
* License : Expat
  Description : OmniAuth strategy for salesforce.com
 OmniAuth is a Ruby library that standardizes multi-provider
authentication for web applications. It was created to be powerful,
flexible, and do as little as possible. Any developer can create
strategies for OmniAuth that can authenticate users via disparate
 systems. OmniAuth strategies have been created for everything from
Facebook to LDAP.
 .
 This package contains the OmniAuth strategy for salesforce.com



signature.asc
Description: OpenPGP digital signature

Bug#934755: menulibre 2.2.0-2 does not start on debian 10

[Сергей Фёдоров]

Package: menulibre
Version: 2.2.0-2
Severity: normal

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

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

Versions of packages menulibre depends on:
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  gir1.2-glib-2.0   1.58.3-2
ii  gir1.2-gmenu-3.0  3.32.0-1
ii  gir1.2-gtk-3.03.24.10-1
ii  gnome-menus   3.32.0-1
ii  python3   3.7.3-1
ii  python3-gi3.32.2-1
ii  python3-psutil5.5.1-1
ii  xdg-utils 1.1.3-1

menulibre recommends no packages.

menulibre suggests no packages.

-- no debconf information

Menulibre writes on start in terminal window:

(menulibre:6937): Gtk-WARNING **: 12:58:15.804: gtk_menu_attach_to_widget(): 
menu already attached to GtkMenuButton
(menulibre:6937): Gtk-WARNING **: 12:58:15.860: gtk_menu_attach_to_widget(): 
menu already attached to GtkMenuButton
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/menulibre/MenulibreApplication.py", line 
2217, in do_activate
self.win = MenulibreWindow(self, headerbar)
  File "/usr/lib/python3/dist-packages/menulibre/MenulibreApplication.py", line 
250, in __init__
self.configure_application_treeview(builder)
  File "/usr/lib/python3/dist-packages/menulibre/MenulibreApplication.py", line 
589, in configure_application_treeview
self.treeview = MenulibreTreeview.Treeview(self, builder)
  File "/usr/lib/python3/dist-packages/menulibre/MenulibreTreeview.py", line 
48, in __init__
self._configure_treeview(builder)
  File "/usr/lib/python3/dist-packages/menulibre/MenulibreTreeview.py", line 
59, in _configure_treeview
treestore = MenuEditor.get_treestore()
  File "/usr/lib/python3/dist-packages/menulibre/MenuEditor.py", line 123, in 
get_treestore
return menu_to_treestore(treestore, None, menu)
  File "/usr/lib/python3/dist-packages/menulibre/MenuEditor.py", line 100, in 
menu_to_treestore
tooltip = escapeText(item[2]['comment'])
  File "/usr/lib/python3/dist-packages/menulibre/util.py", line 99, in 
escapeText
return GLib.markup_escape_text(text, len(text))
  File "/usr/lib/python3/dist-packages/gi/overrides/GLib.py", line 418, in 
markup_escape_text
return GLib.markup_escape_text(text, length)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd0 in position 27: 
unexpected end of data

... and does not start.

If this packets have a version 2.58.3-2, menulibre executes.
But for packets version 2.60.5-1, 2.60.6-2 menulibre does not start:
  libglib2.0-0
  libglib2.0-bin
  libglib2.0-dev
  libglib2.0-dev-bin

On TabletPC Acer Iconiatab W500 (Debian 10 32-bit) menulibre does not execute
also with same error messages.

Bug#934754: upload geary 3.32 to unstable

[Pirate Praveen]

Package: geary
version: 3.32.0-1
Severity: wishlist

mail client being a very important software for a desktop, I think geary
should be available in buster backports. I was able to rebuild geary
3.32 on buster without any changes in dependencies. Please upload geary
3.32 to unstable so it can reach testing and backports.

I'd also be happy to join gnome team (already requested access in salsa
for libgit2 related updates) and do it myself if the idea is accepted.

Thanks
Praveen

Bug#933736: [pkg-uWSGI-devel] Bug#933736: uwsgi-plugin-php: Please include "for php7 return failures only on failure"

[Jonas Smedegaard]

Hi Alexandre (cc bugreport),

[ but dropping mailinglist indirectly covered via bugreport ]

Quoting Alexandre Rossi (2019-08-14 13:08:15)
> > Should I push directly to master, send a patcht o the mailing list 
> > or propose a pull request in salsa, or other?
> 
> The fix has been pushed to master.

Good.  But where is that, exactly?  URL?


> Any upload planned? Or should I prepare an upload on mentors.d.o?

mentors.d.o is a service for "lonely riders" to find sponsors for their 
otherwise self-maintained packages.  Since this is team-maintained (and 
we have Debian Developers with upload rights in the team) we don't need 
that.

As soon as I understand where you pushed the code, I will have a look at 
it, and assuming it looks sensible I will make a release.


> Also, I'm pondering raising the severity of this bug. uwsgi-plugin-php 
> cannot run PHP applications that are using PHP sessions, basically 
> most applications that use some kind of login/password process. This 
> fits "a bug which has a major effect on the usability of a package, 
> without rendering it completely unusable to everyone". This would open 
> the door to a stable update. What do people think?

Makes good sense.


 - Jonas

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

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

Bug#934753: dropbear-initramfs: please add an autopkgtest

[Johannes 'josch' Schauer]

Package: dropbear-initramfs
Severity: wishlist

Hi,

when I upgraded my Squeeze box to Jessie, remote unlocking via dropbear
in my initramfs stopped working. This is a remote host in a datacenter,
so I cannot directly investigate the issue.

I propose to add an autopkgtest for dropbear-initramfs to make sure that
the functionality continues to work even as the packages around it
change over time.

I attached a shell script which uses qemu to prepare a system that has
an unencrypted /boot and / and swap on an LVM on luks, which I guess is
the classical layout.

If you like the script, then I could prepare a patch against
src:dropbear which implements an autopkgtest that runs the script.

Thanks!

cheers, josch
#!/bin/sh

set -exu

ssh="ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no -i id_rsa"

pkgs="linux-image-amd64,openssh-server,systemd-sysv,libpam-systemd,policykit-1"
pkgs="$pkgs,iproute2,util-linux,e2fsprogs,ifupdown,net-tools,netbase"
pkgs="$pkgs,iputils-ping,isc-dhcp-client,lvm2,parted,cryptsetup"
pkgs="$pkgs,dropbear-initramfs,busybox,fdisk,mmdebstrap,udev"

mmdebstrap --mode=unshare --variant=apt --include=$pkgs \
--customize-hook='chroot "$1" passwd --delete root' \
--customize-hook='chroot "$1" useradd --home-dir /home/user 
--create-home user' \
--customize-hook='chroot "$1" passwd --delete user' \
--customize-hook='echo host > "$1/etc/hostname"' \
--customize-hook='echo "127.0.0.1 localhost host" > "$1/etc/hosts"' \
--customize-hook='echo "/dev/sda1 / auto errors=remount-ro 0 1" > 
"$1/etc/fstab"' \
unstable debian-unstable.tar

fallocate -l 2G crypt.img

cat << END > extlinux.conf
default linux
timeout 0

label linux
kernel /vmlinuz
append initrd=/initrd.img root=/dev/sda1 console=ttyS0
END

cat << END > interfaces
auto lo
iface lo inet loopback

auto ens3
iface ens3 inet dhcp
END

[ -e ./id_rsa ] && [ -e ./id_rsa.pub ] || ssh-keygen -q -t rsa -f ./id_rsa -N ""

guestfish -N debian-unstable.img=disk:2G -- \
part-disk /dev/sda mbr : \
part-set-bootable /dev/sda 1 true :  \
mkfs ext2 /dev/sda1 : \
mount /dev/sda1 / : \
tar-in debian-unstable.tar / : \
extlinux / : \
mkdir /root/.ssh : \
copy-in id_rsa.pub /root/ : \
mv /root/id_rsa.pub /root/.ssh/authorized_keys : \
chown 0 0 /root/.ssh/authorized_keys : \
copy-in extlinux.conf / : \
copy-in interfaces /etc/network

qemu-img convert -O qcow2 debian-unstable.img debian-unstable.qcow2

qemu-system-x86_64 -enable-kvm -m 4G -net user,hostfwd=tcp::10022-:22 \
-net nic -nographic -serial mon:stdio \
-drive file=debian-unstable.qcow2 \
-drive file=crypt.img,format=raw >qemu1.log &1 &

QEMUPID=$!

trap "kill $QEMUPID" EXIT

TIMESTAMP=$(sleepenh 0 || [ $? -eq 1 ])
TIMEOUT=3
i=0
while true; do
rv=0
$ssh -p 10022 -o ConnectTimeout=$TIMEOUT root@localhost echo success || 
rv=1
[ $rv -eq 0 ] && break
# if the command before took less than $TIMEOUT seconds, wait the 
remaining time
TIMESTAMP=$(sleepenh $TIMESTAMP $TIMEOUT || [ $? -eq 1 ]);
i=$((i+1))
if [ $i -ge 10 ]; then
break
fi
done

if [ $i -eq 10 ]; then
echo "timeout reached: unable to connect to qemu via ssh"
exit 1
fi

$ssh -p 10022 root@localhost << 'SSHSCRIPT'
set -exu

cat << END | sfdisk /dev/sdb
label: gpt
unit: sectors

start=   2048, size=2048, type=21686148-6449-6E6F-744E-656564454649
start=   4096, size=  999424, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
start=1003520,type=CA7D7CCB-63ED-4C53-861C-1742536059CC
END

fdisk -l

printf myinsecurepassphrase | cryptsetup luksFormat /dev/sdb3 -
printf myinsecurepassphrase | cryptsetup luksOpen /dev/sdb3 mycrypt
pvcreate /dev/mapper/mycrypt
vgcreate myvg /dev/mapper/mycrypt
lvcreate --name swap --size 15M myvg
mkswap /dev/myvg/swap
swapon /dev/myvg/swap
lvcreate --name root --size 1G myvg
mkfs.ext4 /dev/myvg/root
mkfs.ext2 /dev/sdb2

BOOTUUID=`blkid -s UUID -o value /dev/sdb2`
SDB3UUID=`blkid -s UUID -o value /dev/sdb3`
SWAPUUID=`blkid -s UUID -o value /dev/myvg/swap`

mount /dev/myvg/root /mnt

# need to use /dev/null on stdin because of #934199
mmdebstrap --debug --mode=root --variant=apt unstable /mnt  
"/mnt/etc/apt/apt.conf.d/99no-install-recommends"

cat > "/mnt/etc/apt/apt.conf.d/99autoremove" << END
APT::AutoRemove::SuggestsImportant false;
APT::AutoRemove::RecommendsImportant false;
END

mkdir -p "/mnt/etc/default"

cat > "/mnt/etc/default/grub" << 'END'
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="ip=:ens3:dhcp cgroup_enable=memory swapaccount=1 
console=ttyS0 "
END

cat > "/mnt/etc/fstab" << END
/dev/myvg/root  / autoerrors=remount-ro 0 1
UUID=$BOOTUUID  /boot autodefaults  0 2
/dev/myvg/swap  none  

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

[Pavel Matěja]

Package: glibc
Version: 2.28-10:amd64

Dear Maintainer,

We are running manually compiled Apache and OpenSSL on Debian servers in 
Debian-based chroots.
After chroot upgrade from Stretch to Buster we started to see strange 
SEGFAULTs.

The strange means they appear only on 2 servers out of 6.
Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon 
E3-1220 v6 produced crashes.

It did not matter if the host Debian was Stretch or Buster.

I was able to collect coredumps and get backtraces. They look like:
(gdb) bt
#0  tcache_get (tc_idx=0) at malloc.c:2934
#1  __GI___libc_malloc (bytes=3) at malloc.c:3042
#2  0x7fd8cc0961be in CRYPTO_malloc (num=3, file=0x7fd8cc2a548c 
"ssl/statem/extensions_clnt.c", line=1376) at crypto/mem.c:222
#3  0x7fd8cc26c7b9 in tls_parse_stoc_ec_pt_formats 
(s=0x7fd8640592d0, pkt=0x7fd864061810, context=256, x=0x0, chainidx=0)

    at ssl/statem/extensions_clnt.c:1376
#4  0x7fd8cc266af5 in tls_parse_extension (s=0x7fd8640592d0, 
idx=TLSEXT_IDX_ec_point_formats, context=256, exts=0x7fd864061770, 
x=0x0, chainidx=0)

    at ssl/statem/extensions.c:715
#5  0x7fd8cc266bbb in tls_parse_all_extensions (s=0x7fd8640592d0, 
context=256, exts=0x7fd864061770, x=0x0, chainidx=0, fin=1)

    at ssl/statem/extensions.c:748
#6  0x7fd8cc2798b6 in tls_process_server_hello (s=0x7fd8640592d0, 
pkt=0x7fd83cff8440) at ssl/statem/statem_clnt.c:1698
#7  0x7fd8cc277fc7 in ossl_statem_client_process_message 
(s=0x7fd8640592d0, pkt=0x7fd83cff8440) at ssl/statem/statem_clnt.c:1039
#8  0x7fd8cc275499 in read_state_machine (s=0x7fd8640592d0) at 
ssl/statem/statem.c:636
#9  0x7fd8cc274f15 in state_machine (s=0x7fd8640592d0, server=0) at 
ssl/statem/statem.c:434
#10 0x7fd8cc274a1b in ossl_statem_connect (s=0x7fd8640592d0) at 
ssl/statem/statem.c:250
#11 0x7fd8cc25b098 in SSL_do_handshake (s=0x7fd8640592d0) at 
ssl/ssl_lib.c:3599
#12 0x7fd8cc257199 in SSL_connect (s=0x7fd8640592d0) at 
ssl/ssl_lib.c:1653
#13 0x7fd8c957c934 in ssl_io_filter_handshake 
(filter_ctx=0x7fd85809a090) at ssl_engine_io.c:1243
#14 0x7fd8c957deca in ssl_io_filter_output (f=0x7fd85809a0e8, 
bb=0x7fd85406b8b0) at ssl_engine_io.c:1760

..

(gdb) bt
#0  tcache_get (tc_idx=0) at malloc.c:2934
#1  __GI___libc_malloc (bytes=16) at malloc.c:3042
#2  0x7fd8cc0961be in CRYPTO_malloc (num=16, file=0x7fd8cc159913 
"crypto/bio/bss_mem.c", line=115) at crypto/mem.c:222
#3  0x7fd8cc0961f1 in CRYPTO_zalloc (num=16, file=0x7fd8cc159913 
"crypto/bio/bss_mem.c", line=115) at crypto/mem.c:230
#4  0x7fd8cbf9ca0a in mem_init (bi=0x7fd860044130, flags=0) at 
crypto/bio/bss_mem.c:115
#5  0x7fd8cbf9cb3d in mem_new (bi=0x7fd860044130) at 
crypto/bio/bss_mem.c:138
#6  0x7fd8cbf9541a in BIO_new (method=0x7fd8cc204980 ) 
at crypto/bio/bio_lib.c:94
#7  0x7fd8cc2454a3 in ssl3_init_finished_mac (s=0x7fd8600a7be0) at 
ssl/s3_enc.c:322
#8  0x7fd8cc281eae in tls_setup_handshake (s=0x7fd8600a7be0) at 
ssl/statem/statem_lib.c:91
#9  0x7fd8cc274ea2 in state_machine (s=0x7fd8600a7be0, server=0) at 
ssl/statem/statem.c:419
#10 0x7fd8cc274a1b in ossl_statem_connect (s=0x7fd8600a7be0) at 
ssl/statem/statem.c:250
#11 0x7fd8cc25b098 in SSL_do_handshake (s=0x7fd8600a7be0) at 
ssl/ssl_lib.c:3599
#12 0x7fd8cc257199 in SSL_connect (s=0x7fd8600a7be0) at 
ssl/ssl_lib.c:1653
#13 0x7fd8c957c934 in ssl_io_filter_handshake 
(filter_ctx=0x7fd8580e8b78) at ssl_engine_io.c:1243
#14 0x7fd8c957deca in ssl_io_filter_output (f=0x7fd8580e8bd0, 
bb=0x55b212b0d518) at ssl_engine_io.c:1760

..

SSLv3 and TLS code path looked quite distinct to cause the same problem.
Based on info that SEGFAULTs are related to memory allocation in new 
libc and CPU performance I found

http://51.15.138.76/patch/17499/
where Wilco Dijkstra discuss some problems with tcache which "leads to 
various crashes in benchtests"


As workaround I tried to
export GLIBC_TUNABLES=glibc.malloc.tcache_count=0
in Apache startup script and I saw no SEGFAULT since.

I have coredumps but they contain production private keys for Apache 
which I can't share and to make things even worse they are 1,6GB each.


I understand this is heisenbug which you won't be able to reproduce. The 
CPU model dependency is beyond my comprehension.
I'm curious if you are familiar with the new tcache and if you think if 
the patch in discussion can help.
I'll try to build libc6 package with it to confirm final solution but 
I'm confused by the patch tree so far.


-- System Information:
Debian Release: Buster
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 
(2019-08-08) x86_64 GNU/Linux


diff --git a/malloc/malloc.c b/malloc/malloc.c
index 801ba1f499b566e677b763fc84f8ba86f4f7ccd0..4db7283cc27118cd7d39410febf7be8f7633780a 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -2915,10 +2915,12 @@ typedef struct tcache_entry
time), this is for performance reasons.  */
 typedef struct 

Bug#934751: RFP: linux-hardened - hardened Linux kernel

[Patrick Schleizer]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-ker...@lists.debian.org

* Package name: linux-hardened
  Version : 5.2
  Upstream Author : linux-hardened
* URL : https://github.com/anthraxx/linux-hardened
* License : GPL-2
  Programming Lang: C
  Description : Minimal supplement to upstream Kernel Self
Protection Project changes. Features already provided by SELinux + Yama
and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags
have stable history. Shared IRC channel with KSPP: irc.freenode.net
##linux-hardened

Maybe as an alternative, not replacement for the usual Debian linux kernel.

Bug#836699: Add dh --with-indep, for sequence addons pulled in through Build-Depends-Indep

[Niels Thykier]

Control: tags -1 patch

On Sun, 07 Jan 2018 18:45:00 + Niels Thykier  wrote:
> On Sun, 4 Sep 2016 15:57:55 -0400 (EDT) Anders Kaseorg 
> wrote:
> > Package: debhelper
> > Version: 9.20160814
> > 
> > It would be useful to have dh $@ --with-indep ADDON, an analogue of dh $@ 
> > --with ADDON that only loads the addon when Architecture: all packages are 
> > being built.
> > 
> > [...]
> > 
> > Anders
> > 
> > 
> 
> [...]

Hi,

An update on this (Helmut and Paul already heard some of this on IRC
yesterday).  I have written a possible solution to this problem in the
form of the following branch:

 * https://salsa.debian.org/debian/debhelper/tree/sequence-with-indep

I am hoping for testing/feedback on this before I merge it.

 => Notably, does this resolve your issues/needs in this area?




# From a add-on provider's perspective

Ensure the package that containing the add-on provides the
pseudo-package "dh-sequence-ADDON" where ADDON is the name of the
sequence add-on.  E.g. "dh-sequence-sphinxdoc" for sphinx.

The addon will be restricted to only adding commands and only when it
happens in the relevant sequence (*-indep for Build-Depends-Indep).
This is to ensure that the result is deterministic.  A notably
restriction is that it *cannot* alter the clean target (as the sequence
is not guaranteed to be available during clean as it is not an -indep
target).




# From a user/packager's perspective:

Use the dh-sequence-ADDON solely in Build-Depends-Indep.  Concrete
example being:

  Build-Depends-Indep: dh-sequence-sphinxdoc


Note that this can be combined with build-profiles a la:

  Build-Depends-Indep: dh-sequence-sphinxdoc 

Or

  Build-Depends-Indep: dh-sequence-dhpython 
  (Ditto for Build-Depends)

(Subject to spelling mistakes; I did not double check all the names)



# How come this and not --with-indep

We already supported dh-sequarence-ADDON in Build-Depends (admittedly it
is fairly new).  Adding Build-Depends-Indep is a reasonably declarative
and DRY to request a sequence only during -indep targets.  Furthermore,
it can also naturally support build-profiles and other optional
build-dependency markers without having the packager duplicate the logic
in d/rules (this has been done in the branch as well).

The downside is sphinxdoc and doxygen will need an upload to add a
provides for their sequence.  I think this is acceptable (in
particularly because doxygen will need an upload anyway to make
dh_doxygen work in this case any way as I understand #799543)


# End remarks

The Build-profile support can most likely be "extracted" and applied to
debhelper master *without* the rest if the other parts are not relevant.
 Though I am only considering this if we believe that the proposed
approach for handling indep-only add-on sequences is flawed or if the
work on this drags on.


Thanks,
~Niels

Bug#934746: RFS: shotwell/0.28.4-1

[Andrej Shadura]

Hi,

On Wed, 14 Aug 2019 at 13:39, Jörg Frings-Fürst  wrote:
>
> Package: sponsorship-requests
> Severity: normal [important for RC bugs, wishlist for new packages]
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "shotwell"
>
>Package name: shotwell
>Version : 0.30.4-2
>Upstream Author : Jens Georg 
>URL : https://wiki.gnome.org/Apps/Shotwell
>License : LGPL-2.1, CC-BY-SA-3.0, GPL-2+
>Section : gnome
>
>   It builds those binary packages:
>
>  shotwell- digital photo organizer
>  shotwell-common - digital photo organizer - common files
>
>   To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/shotwell
>
>
>   Alternatively, one can download the package with dget using this
> command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.4-2.dsc
>
> or from git
>
>   https://jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.30.4-2

Thanks!

Uploaded using dgit, you can fetch the debian/0.30.4-2 tag from this
remote: https://git.dgit.debian.org/shotwell


-- 
Cheers,
  Andrej

Bug#934750: python-pbr: autopkgtest regression

[Esa Peuha]

Source: python-pbr
Version: 5.1.3-3

As Debian CI logs [1] show, python-pbr 5.1.3-3 is consistently failing
its autopkgtest. This regression is blocking its migration to testing.
It looks like the test infrastructure is trying to run Python 2 tests,
even though Python 2 support was removed from the package.

[1] https://ci.debian.net/packages/p/python-pbr/testing/amd64

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

[Florian Weimer]

* Roman Savochenko:

>> Is there a way to reproduce your results easily?  Upstream, we're
>> looking for workloads which are difficult to handle for glibc's malloc
>> and its default settings, so that we hopefully can improve things
>> eventually.
>
> This way of the ready builds of the application and LiveDisks is
> simplest one for me, than writing a test application with simulation
> such sort complex load, so you can already install the application,
> start and observer.

I meant: Is there a reproduction recipe someone could use, without being
familiar with the application?

Thanks,
Florian

Bug#931684: libgit2 0.28 transition and libgit2-glib

[Pirate Praveen]

On Wed, 14 Aug 2019 07:17:28 +0900 Jongmin Kim  wrote:
> No error reported on chroot without ccache. When I tried with ccache
> installed chroot, following same issue was occurred:
> 
>   Compiler stderr:
>ccache: error: Failed to create directory
>   /sbuild-nonexistent/.ccache/tmp: Permission denied
> 
>   Checking if "libgit2 supports SSH" compiles: NO
> 
>   meson.build:148:2: ERROR: Assert failed: libgit2 ssh support was
>   requested, but not found. Use -Dssh=false to build without it.
> 
> The problem seems ccache was installed and its output path (CCACHE_DIR,
> default is $HOME/.ccache) is not writable. It seems Meson detects if
> ccache installed and use it [2]..

yes, I can confirm this finding. I was able to build it after removing
ccache from the chroot. And thanks for the MR, I merged it.

Bug#931692: gitg: libgit2 0.28 transition

[Pirate Praveen]

On Tue, 09 Jul 2019 19:30:24 +0900 Jongmin Kim  wrote:
Dear Maintainer,
> 
> libgit2 0.28 is now available in experimental. Please make sure your
> package is ready for this version by the time we upload this package to
> unstable in one to two weeks. The severity of this report will be
> raised to serious once libgit2 0.28 is uploaded to unstable.

I was able to build gitg with new version of libgit2-glib from
https://salsa.debian.org/praveen/libgit2-glib

Bug#934749: welle.io: some icons & widgets not displayed

[Fab Stz]

Package: welle.io
Version: 2.0~beta2-1
Severity: normal

Dear Maintainer,

When opening welle.io, the top left (menu - 3 horizontal bars) & top right
(options) icons are missing.

Loudspeaker (in service overview widget) icon is missing too

Same problem with the dropdown menu "Favorites" which is not displayed, as well
as the star icon and as well as vertical "3 dots" icon.

There is no such problem with the Appimage provided on the official website.



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (991, 'stable'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages welle.io depends on:
ii  libc6  2.28-10
ii  libfaad2   2.8.8-3
ii  libfftw3-single3   3.3.8-2
ii  libgcc11:8.3.0-6
ii  libmp3lame03.100-2+b1
ii  libmpg123-01.25.10-2
ii  libqt5charts5  5.11.3-2
ii  libqt5core5a   5.11.3+dfsg1-1
ii  libqt5gui5 5.11.3+dfsg1-1
ii  libqt5multimedia5  5.11.3-2
ii  libqt5multimedia5-plugins  5.11.3-2
ii  libqt5network5 5.11.3+dfsg1-1
ii  libqt5qml5 5.11.3-4
ii  libqt5quick5   5.11.3-4
ii  libqt5widgets5 5.11.3+dfsg1-1
ii  librtlsdr0 0.6-1
ii  libsoapysdr0.6 0.6.1-4+b1
ii  libstdc++6 8.3.0-6
ii  qml-module-qt-labs-settings5.11.3-4
ii  qml-module-qtquick-controls5.11.3-2
ii  qml-module-qtquick-controls2   5.11.3+dfsg-2
ii  qml-module-qtquick-dialogs 5.11.3-2
ii  qml-module-qtquick-layouts 5.11.3-4
ii  qml-module-qtquick-localstorage5.11.3-4
ii  qml-module-qtquick-privatewidgets  5.11.3-2
ii  qml-module-qtquick-templates2  5.11.3+dfsg-2
ii  qml-module-qtquick-window2 5.11.3-4
ii  qml-module-qtquick25.11.3-4

welle.io recommends no packages.

welle.io suggests no packages.

Bug#934748: lintian: package-name-doesnt-match-sonames shouldn't be reported against udebs

[Nicolas Braud-Santoni]

Package: lintian
Version: 2.17.0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Lintian maintainers,

While working on a new upload of haveged, I noticed that Lintian reports
package-name-doesnt-match-sonames against haveged-udeb.

This is technically correct (the non-udeb package which ships the so is
libhavege1), but I guess reporting this against udebs isn't the intended
behaviour.

If so, please add a check silencing that rule on udebs.


Best,

  nicoo


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

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

Versions of packages lintian depends on:
ii  binutils 2.32.51.20190727-1
ii  bzip21.0.6-9.2
ii  diffstat 1.62-1+b1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b1
ii  libarchive-zip-perl  1.64-1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b1
pn  libdigest-sha-perl   
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.79+repack-2
ii  man-db   2.8.6.1-1
ii  patchutils   0.3.4-2+b1
ii  perl 5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

- -- Configuration Files:
/etc/lintianrc changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1T9pERHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MvXGg//WDknMQFNJlyuV+ruv2h3GKdxkQebIa6k
6wrqFUZjTx2HWaLH9QlVAvT0DFcCBBqKUWnoU5PUgqWVoD9WKHQLpSQ9TY8qfu7p
oIfLt4Ig/7JF4Q8n/75hbN7rV5gRdkwXcXYAQBys+dEdJ+Ef/hwEQl9cXzEg6EL2
HqsFGY/EFsPBU/PoWi1dn8l7dcCzYJjwRzsXdXjo13sFt3rj8OujVJv2a6cRPYXo
RDttrd43PKCGbYTvM846698TBSeToJFwcnrt+eXSCSBnXkSAfQZyXPwS66T6uRYF
dssv+U8DNoIYHs82/fV4zUUuAo61zAfhTWMVSzSq5Qi1zNWVwTvmIbkvV7QIw1nA
E3fxus6ez2R/3A00AVWJGl1X16JJK4MIKEacLOe/h9fKely9kqs87gOZIoEtPAYI
Lc5eWoeIhUXSFxPynBWQauYdwXMu+5MnPlsyv9haxvY3SWG6sFlbaKJ7aBa4LeMx
SHEb7jmEei1RlGGROcXwuPTeQY6H85qgUr/O9cfNW/5yre+eHzVfb1gmo4V/wRLr
uu3SLBnTZcyeExCFhO2quirkV0FJcsLZZW1yqwXtuAQwofSxT9eS6C6AiVxv8014
sRWXFaIgYWBIbTaIHhUvs/FJfDJIgT+KYlh4cPzJrOF51iTsVSl+ZSD7dVq3o4wN
r3wppvOIabg=
=Nog7
-END PGP SIGNATURE-

Bug#934746: RFS: shotwell/0.28.4-1

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

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

   Package name: shotwell
   Version : 0.30.4-2
   Upstream Author : Jens Georg 
   URL : https://wiki.gnome.org/Apps/Shotwell
   License : LGPL-2.1, CC-BY-SA-3.0, GPL-2+
   Section : gnome

  It builds those binary packages:

 shotwell- digital photo organizer
 shotwell-common - digital photo organizer - common files

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.4-2.dsc

or from git
  
  https://jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.30.4-2
  



  Changes since the last upload:

  * Fix GoogleAuthenticator error handling (Closes: #934723):
- New debian/patches/0110-fix_GoogleAuthenticator.patch cherry-picked
  from upstream.


The build with sbuild and pdebuild and the tests with Lintain are ok.
Puiparts fails about "package purging left files on system" mostly from
a mime package. 

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 261884
Build-Time: 93
Distribution: sid
Host Architecture: amd64
Install-Time: 343
Job: /data/entwicklung/linux/debian/shotwell/shotwell_0.30.4-2.dsc
Lintian: info
Machine Architecture: amd64
Package: shotwell
Package-Time: 529
Piuparts: fail
Source-Version: 0.30.4-2
Space: 261884
Status: successful
Version: 0.30.4-2

Finished at 2019-08-14T11:02:46Z
Build needed 00:08:49, 261884k disk space

  Regards,
   Jörg Frings-Fürst

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

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

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


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

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


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



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

Bug#934747: /usr/bin/rtorrent: rtorrent crashes with error "Could not create download: Info hash already used by another torrent."

[Thomas Nemeth]

Package: rtorrent
Version: 0.9.7-1
Severity: grave
File: /usr/bin/rtorrent
Tags: upstream
Justification: renders package unusable

Hi,

for several weeks now, rtorrent crashes when I start it (no changes have
been made to either its configuration nor its torrents list for many
month).

Here is the log it produces:

8<8<8<8<8<
1565781738 N rtorrent main: Starting thread.
1565781738 N rtorrent scgi: Starting thread.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781747 E Could not create download: Info hash already used by another 
torrent.
1565781771 C Caught signal: 'Erreur de segmentation.
---DUMP---
Caught Segmentation fault, dumping stack:
rtorrent(+0x11e59) [0x4afe59]
linux-gate.so.1(__kernel_sigreturn+0) [0xb7f92d7c]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x31640) [0xb7e69640]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x328f2) [0xb7e6a8f2]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x2f7f7) [0xb7e677f7]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x30612) [0xb7e68612]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x30951) [0xb7e68951]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x33d5c) [0xb7e6bd5c]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x35205) [0xb7e6d205]
/usr/lib/i386-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x2f) [0xb7e6d3af]
rtorrent(+0xda370) [0x578370]
rtorrent(+0xda68c) [0x57868c]
rtorrent(+0x1341b) [0x4b141b]
/usr/lib/i386-linux-gnu/libtorrent.so.20(_ZN7torrent11thread_base10event_loopEPS0_+0x229)
 [0xb7d8ec89]
rtorrent(+0x10b7b) [0x4aeb7b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb77e7b41]
rtorrent(+0x1173b) [0x4af73b]

---END---
8<8<8<8<8<

I can't figure which torrent causes that message but it should not make
the program to segfault...


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

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

Versions of packages rtorrent depends on:
ii  libc6  2.28-10
ii  libcppunit-1.14-0  1.14.0-4
ii  libcurl4   7.65.1-1
ii  libgcc11:9.1.0-10
ii  libncursesw6   6.1+20190803-1
ii  libstdc++6 9.1.0-10
ii  libtinfo6  6.1+20190803-1
ii  libtorrent20   0.13.7-1
ii  libxmlrpc-core-c3  1.33.14-8+b1

rtorrent recommends no packages.

Versions of packages rtorrent suggests:
pn  screen | dtach  

-- no debconf information

Bug#933736: [pkg-uWSGI-devel] Bug#933736: uwsgi-plugin-php: Please include "for php7 return failures only on failure"

[Alexandre Rossi]

Hi,

> Should I push directly to master, send a patcht o the mailing list or propose
> a pull request in salsa, or other?

The fix has been pushed to master.

Any upload planned? Or should I prepare an upload on mentors.d.o?

Also, I'm pondering raising the severity of this bug. uwsgi-plugin-php
cannot run PHP applications that are using PHP sessions, basically most
applications that use some kind of login/password process. This fits
"a bug which has a major effect on the usability of a package, without
rendering it completely unusable to everyone". This would open the door
to a stable update. What do people think?

Thanks,

Alex

Bug#933752: luajit: Patch to add ppc64/ppc64el support breaks powerpc

[John Paul Adrian Glaubitz]

Package: src:luajit
Followup-For: Bug #933752
User: debian-powe...@lists.debian.org
Usertags: powerpc

Hi!

The attached patch was cherry-picked from [1] and fixes the problem
for me.

Could you include it for the next package upload to fix the problem
on Debian powerpc?

Thanks,
Adrian

> [1] 
> https://github.com/siddhesh/LuaJIT/commit/1b12bef3aa18701ceadbadad45fca993788979c5

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 1b12bef3aa18701ceadbadad45fca993788979c5 Mon Sep 17 00:00:00 2001
From: Siddhesh Poyarekar 
Date: Wed, 14 Aug 2019 14:24:55 +0530
Subject: [PATCH] [ppc] Fix typo

--- luajit-2.1.0~beta3+dfsg.orig/src/vm_ppc.dasc
+++ luajit-2.1.0~beta3+dfsg/src/vm_ppc.dasc
@@ -2774,7 +2774,7 @@ static void build_subroutines(BuildCtx *
   |
   |->vm_exit_handler:
   |.if JIT
-  |  addi sp, TMP0, sp, -(EXIT_OFFSET+32*8+32*PSIZE)
+  |  addi sp, sp, -(EXIT_OFFSET+32*8+32*PSIZE)
   |  saver 3 // CARG1
   |  saver 4 // CARG2
   |  saver 5 // CARG3

Bug#934745: FTBFS against evolution-data-server 3.33: error: 1 missing arguments for `bool E.BookClient.add_contact (E.Contact, uint32, GLib.Cancellable?, out string)'

[Iain Lane]

Package: src:folks
Version: 0.11.4-1
Severity: normal
Tags: patch
Control: block 933577 by -1

Hi there,

Folks needs updating for EDS 3.33, which is in experimental now. It's
fixed upstream and I filed an MR with the required fix:

  https://salsa.debian.org/telepathy-team/folks/merge_requests/1/diffs

(not a full package update which might be better, don't know)

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

Bug#934238: Update node-raw-loader dependency

[Pirate Praveen]

On Thu, 08 Aug 2019 19:39:08 +0530 Pirate Praveen
 wrote:
> Package: rainloop
> Version: 1.12.1-2
> Severity: important
> 
> I'd like to update node-raw-loader to 1.0.0 for gitlab and uploaded it 
> to experimental. Please confirm if this version is compatible with 
> rainloop so I can upload it to unstable.
> 
> 

I think I will go ahead with uploading node-raw-loader in unstable.
https://github.com/webpack-contrib/raw-loader/blob/master/CHANGELOG.md
lists breaking changes as only minimum version of webpack and nodejs
updated (both are fine in unstable).

Just in case you want older version of raw-loader still, you can embed
it in rainloop.

Bug#859122: 31 DLAs missing from the website

[Holger Levsen]

Hi Brian,

On Wed, Aug 14, 2019 at 05:16:46PM +1000, Brian May wrote:
> On Mon, Apr 15, 2019 at 12:06:35PM +, Holger Levsen wrote:
> > many thanks for all your fixes on this bug!
> Can you please rerun the command:
> ~/Projects/debian-www/webwml$ ../cron/parts/10-check-advisories --mode DLA

~/Projects/debian-www/webwml$ ../cron/parts/10-check-advisories --mode DLA  2>&1
ERROR: .data or .wml file missing for DLA 1885-1
ERROR: .data or .wml file missing for DLA 1884-1
ERROR: .data or .wml file missing for DLA 1879-1
ERROR: .data or .wml file missing for DLA 1877-1
ERROR: .data or .wml file missing for DLA 1871-1
ERROR: .data or .wml file missing for DLA 1846-2
ERROR: .data or .wml file missing for DLA 1833-2
ERROR: .data or .wml file missing for DLA 1784-1
ERROR: .data or .wml file missing for DLA 607-1
ERROR: .data or .wml file missing for DLA 567-1
ERROR: .data or .wml file missing for DLA 377-1
ERROR: .data or .wml file missing for DLA 267-1
ERROR: .data or .wml file missing for DLA 115-2
ERROR: .data or .wml file missing for DLA 145-2

> I am loosing track of which DLAs are still missing, and it looks like
> I can't run that command myself.

it's not merged into master but it's only in MR#1 for the cron.git repo
of debian-www...

Thanks for looking into this again!


-- 
cheers,
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

Bug#934218: Sort of fully working workaround

[Josep Guerrero]

Hi again,

Finally I've managed to install a fully working grub on the system. The grub 
installation process from the installer still fails, with the output attached 
to the previous message, but I found a way to install a fully functional grub 
in the system following these steps:

1) When the grub installation fails, I accepted installing grub in an external 
removable media (this, I think, makes the USB work a grub bootable device, but 
it's no longer functional as booting installer device. Since I can overwrite 
it again, it's not a big problem).

2) When booting from this new grub USB device, I only get to the grub prompt. 
I need to issue the following commands (with the right parameter values):

root=(lvm/dev/mapper/root-lvm-device)
linux /boot/vmlinuz-image-file root=/dev/mapper/root-lvm-device quiet
initrd /boot/initrd-file
boot

to boot the newly installed system.

3) First thing I did, after booting the system, was:

grub-install /dev/nvme0n1

which seemed to work and provided a new UEFI boot entry (which didn't require 
an external USB device), but still took me only to the grub prompt when 
booting the system.

4) After some googling and reading, I edited the file

/etc/default/grub

to include the line:

GRUB_DISABLE_OS_PROBER=false

and executed:

update-grub2

on the booted system. This finally provided a fully functional grub 
installation (it may be that adding the line in /etc/default/grub is not 
necessary, I didn't check if it worked without that).

Finally, I commented out the added line in /etc/default/grub.

I think that, in this particular case and for some reason, grub installation 
doesn't work when done from the installer (maybe I did something wrong?), but 
works if done from the newly installed system. Of course, you need to find a 
way to boot that system first.

Hope this information helps with the problem!

Josep Guerrero

Bug#934744: Installation of the boot loader to e.g. USB-Sticks is confusing and inconsistent.

[Michel Firholz]

Package: installation-reports

Version: Buster

Severity: important

Dear installation package maintainers,

the current installation procedure of Buster (but also the previous versions), 
manual and graphical,
uses an inconsistent wording and is highly confusing upon installing the boot 
loader to other targets as the main harddisk. e.g. USB Disks.

During the partitioning the partition are named by the SCSI name, device name, 
size and manufacturer name.

Based on that information you choose the target for the installation.

Once all the files are written on the disc, you come into the destination 
choice of the boot loader:

The default proposal is to install the boot loader on the hard disk, but if you 
don't want that and want to have the boot loader on the USB-stick you must 
choose between ... UUIDS.

At that stage, it is very likely that the user never had taken notice of the 
UUID, and the chances are very high, that the wrong target may be entered, 
ending up with a non booting usp stick.

Please make the process easier and please, please use the same terminology than 
during the partition process.

e.g. install the boot loader to SDB #1 [partition name], 29GB

It would also be a huge improvement to propose a list of choices to install the 
boot loader that way:

 a) on the hard disk to chose between operating systems

 b) to the partition that was just installed to make a bootable medium

 c) to another partition:

  [partition list using the terminology used during the partition 
procedure]]

Last but not least, it would be really useful to get the choice of only 
reinstalling the boot loader right from the live CD or live USB stick.

Thank you very much for considering my request

Regards

Bug#931873: texlive-bin: FTBFS on sparc64

[John Paul Adrian Glaubitz]

Hi!

On 7/29/19 11:49 PM, Hilmar Preuße wrote:
>> FWIW, we have another machine set up for sparc64 which is part of the gcc
>> compile farm [1]. If you request an account there, the answer should usually
>> not take more than 24 hours. Since I have admin rights on all of these
>> Linux/sparc64 machines, I can also install build dependencies if you need 
>> them.
>>
>> The machine used for the gcc compile farm is also much faster than kyoto.
>>
> My account was approved today. Logging in into that fine server however
> does not work: shortly after I reached the command prompt the connection
> terminates.

Try using a different host as jumphost. For some reason, I have connection
problems when connecting from but connecting from my work machine works
fine. We haven't found out yet what the problem is.

> Anyway: upstream is aware of the problem, hence I don't see any need to
> do something from my side for the time being.

Has there been any progress yet?

Adrian

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

Bug#934743: python-networkmanager: org.freedesktop.DBus.Error.ServiceUnknown if NetworkManager service restarts

[Simon McVittie]

On Wed, 14 Aug 2019 at 11:19:31 +0200, Ana Rodriguez Lopez wrote:
> If NetworkManager service restarts, it gets a new dbus unix process id.

The term you're looking for here is "D-Bus unique name".

> The parameter follow_name_owner_changes can be used in get_object()
> calls to prevent this.

FYI this is only valid if the proxy either doesn't remember the state
of the remote object, or forgets that state when the name owner's unique
name changes, which is why it isn't the default. (I don't know whether
NM's D-Bus API is stateful or stateless, so I can't say whether this
patch is correct or not.)

smcv

Bug#932540: epiphany-browser: Gmail doesn't work correctly in Epiphany in buster

[Alberto Garcia]

On Tue, Aug 13, 2019 at 08:33:41PM +0200, Gerardo Ballabio wrote:
> I ticked off everything: Try to block advertisements, Try to block
> web trackers, and even Try to block dangerous websites. Didn't work
> (sending this from Firefox).

If it still works with the MiniBrowser but not with Epiphany perhaps
you could try to open the web inspector console in both cases (right
click -> Inspect Element -> Console (on the right)) and compare the
messages that appear when you open and try to use GMail.

If both browsers behave differently then that could give us a clue.

Berto

Bug#934743: python-networkmanager: org.freedesktop.DBus.Error.ServiceUnknown if NetworkManager service restarts

[Ana Rodriguez Lopez]

Package: python3-networkmanager
Version: 2.1-2
Tags: patch
Forwarded: https://github.com/seveas/python-networkmanager/issues/66

If NetworkManager service restarts, it gets a new dbus unix process id.
The python-networkmanager remains with the old id. since this process
doesn't exist any more, a org.freedesktop.DBus.Error.ServiceUnknown
exception is thrown.

The parameter follow_name_owner_changes can be used in get_object()
calls to prevent this.

diff --git a/NetworkManager.py b/NetworkManager.py
index 3d137fe..00f0729 100644
--- a/NetworkManager.py
+++ b/NetworkManager.py
@@ -258,7 +258,7 @@ def __eq__(self, other):
 @property
 def proxy(self):
 if not self._proxy:
-self._proxy =
dbus.SystemBus().get_object(self.dbus_service, self.object_path)
+self._proxy =
dbus.SystemBus().get_object(self.dbus_service, self.object_path,
follow_name_owner_changes=True)
 self._proxy.created = time.time()
 elif self._proxy.created < self.last_disconnect:
 if self.is_transient:


https://github.com/anrodlo/python-networkmanager/commit/88f1b0e4531f80e17af3ffe00b5816800ebb4c1a.diff

Bug#934723: shotwell: Crash when opening google photo login page

[Jörg Frings-Fürst]

tags 934723 + pending
forwarded 934723 https://gitlab.gnome.org/GNOME/shotwell/issues/158
thanks


Hello,

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

I have forward this bug to upstream. He has fixed it, so that I prepare
a bugfix release.

CU
Jörg

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

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

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


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

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


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



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

Bug#934742: console-setup package not installed, causes keyboard not being set correctly at runtime

[Tomas Pospisek]

Package: live-build
Version: 1:20190311
Severity: normal

When building a live medium, the `console-setup` package will *not*
be installed in the live-medium by default.

The consequence is that keyboard configuration parameters passed via
live-config, as described in the manual:

  
https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-run-time-behaviours.de.html
  -> "Customizing locale and language"

will not get applied. So the user will always get the US keyboard.

I have not checked, but this *might* be a buster problem, since
I'm building a buster live medium under buster and the package
dependencies might have been relaxed there so that the
`console-setup` package doesn't get installed automatically
under buster.

Thanks,
*t

-- Package-specific info:

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

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

Versions of packages live-build depends on:
ii  debootstrap  1.0.114

Versions of packages live-build recommends:
ii  apt-utils   1.8.2
ii  bzip2   1.0.6-9.1
ii  cpio2.12+dfsg-9
ii  file1:5.35-4
ii  live-boot-doc   1:20190614
ii  live-config-doc 5.20190519
ii  live-manual-html [live-manual]  2:20151217.1
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages live-build suggests:
ii  e2fsprogs  1.44.5-1
pn  mtd-utils  
ii  parted 3.2-25

-- no debconf information

Bug#934741: stretch-pu: package glib2.0/2.50.3-2+deb9u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: stretch d-i
User: release.debian@packages.debian.org
Usertags: pu

glib2.0 in stretch has some minor security vulnerabilities for which
the security team have declined to issue DSAs: the most recent is also
pending review as a buster update (#933535) and the others were already
fixed before the buster release. I've prepared a backport of the fixes,
which is very similar to the delta between jessie and jessie-lts.

I have done some basic testing of this proposed update in a GNOME virtual
machine, but I no longer have physical access to any stretch desktops
that are in real use (the only stretch machines I'm responsible for
will be upgraded to buster when I next get physical access to them)
so additional testing by stretch users would be welcome, particularly
by users of GTK-based desktops like GNOME and XFCE. Test binaries are
available here: https://people.debian.org/~smcv/201908/

As with #933535, glib2.0 builds udebs for the graphical installer, so this
will need a d-i ack.

Thanks,
smcv
diffstat for glib2.0-2.50.3 glib2.0-2.50.3

 changelog   |   22 
+
 gbp.conf|   17 
+
 patches/gfile-Limit-access-to-files-when-copying.patch  |   54 

 patches/gmarkup-Avoid-reading-off-the-end-of-a-buffer-when-non-nu.patch |  115 
++
 patches/gmarkup-Fix-crash-in-error-handling-path-for-closing-elem.patch |   78 
++
 patches/gmarkup-Fix-unvalidated-UTF-8-read-in-markup-parsing-erro.patch |   86 
+++
 patches/keyfile-settings-Use-tighter-permissions.patch  |   48 

 patches/series  |5 
 8 files changed, 425 insertions(+)

diff -Nru glib2.0-2.50.3/debian/changelog glib2.0-2.50.3/debian/changelog
--- glib2.0-2.50.3/debian/changelog 2017-03-19 23:21:57.0 +
+++ glib2.0-2.50.3/debian/changelog 2019-08-13 10:46:20.0 +0100
@@ -1,3 +1,25 @@
+glib2.0 (2.50.3-2+deb9u1) stretch; urgency=medium
+
+  * Team upload
+  * d/gbp.conf: Add GNOME team configuration
+  * d/p/gfile-Limit-access-to-files-when-copying.patch:
+When copying files, give the temporary partial copy of the file
+suitably restrictive permissions (Closes: #929753; CVE-2019-12450)
+  * d/p/keyfile-settings-Use-tighter-permissions.patch:
+Create directory and file with restrictive permissions when using the
+GKeyfileSettingsBackend. Mitigation: in this version of GLib, the
+GKeyfileSettingsBackend can only be used explicitly by code, and is
+never selected automatically. (Closes: #931234; CVE-2019-13012)
+  * d/p/gmarkup-Fix-unvalidated-UTF-8-read-in-markup-parsing-erro.patch,
+d/p/gmarkup-Avoid-reading-off-the-end-of-a-buffer-when-non-nu.patch:
+Avoid buffer read overrun when formatting error messages for invalid
+UTF-8 in GMarkup (CVE-2018-16429)
+  * d/p/gmarkup-Fix-crash-in-error-handling-path-for-closing-elem.patch:
+Avoid NULL dereference when parsing invalid GMarkup with a malformed
+closing tag not paired with an opening tag (CVE-2018-16429)
+
+ -- Simon McVittie   Tue, 13 Aug 2019 10:46:20 +0100
+
 glib2.0 (2.50.3-2) unstable; urgency=medium
 
   * debian/patches/tests-gdatetime-Use-a-real-rather-than-invented-time.patch:
diff -Nru glib2.0-2.50.3/debian/gbp.conf glib2.0-2.50.3/debian/gbp.conf
--- glib2.0-2.50.3/debian/gbp.conf  1970-01-01 01:00:00.0 +0100
+++ glib2.0-2.50.3/debian/gbp.conf  2019-08-13 10:46:20.0 +0100
@@ -0,0 +1,17 @@
+[DEFAULT]
+pristine-tar = True
+debian-branch = debian/stretch
+upstream-branch = upstream/2.50.x
+upstream-vcs-tag = %(version)s
+
+[buildpackage]
+sign-tags = True
+
+[dch]
+multimaint-merge = True
+
+[import-orig]
+postimport = dch -v%(version)s New upstream release; git add debian/changelog; 
debcommit
+
+[pq]
+patch-numbers = False
diff -Nru 
glib2.0-2.50.3/debian/patches/gfile-Limit-access-to-files-when-copying.patch 
glib2.0-2.50.3/debian/patches/gfile-Limit-access-to-files-when-copying.patch
--- 
glib2.0-2.50.3/debian/patches/gfile-Limit-access-to-files-when-copying.patch
1970-01-01 01:00:00.0 +0100
+++ 
glib2.0-2.50.3/debian/patches/gfile-Limit-access-to-files-when-copying.patch
2019-08-13 10:46:20.0 +0100
@@ -0,0 +1,54 @@
+From: Ondrej Holy 
+Date: Thu, 23 May 2019 10:41:53 +0200
+Subject: gfile: Limit access to files when copying
+
+file_copy_fallback creates new files with default permissions and
+set the correct permissions after the operation is finished. This
+might cause that the files can be accessible by more users during
+the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
+files to limit access to those files.
+
+Bug: https://gitlab.gnome.org/GNOME/glib/merge_requests/876
+Bug-CVE: CVE-2019-12450
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929753
+Origin: 

Bug#917238: ndpi 2.2-1: FTBFS, alignment problem

[Gianfranco Costamagna]

control: severity -1 important

I asked to remove the package on armhf, to avoid this bug being RC.

G.

On Mon, 12 Aug 2019 16:27:47 +0200 Gianfranco Costamagna 
 wrote:
> control: forwarded -1 https://github.com/ntop/nDPI/issues/763
> 
> 
> updating forwarded tag.
> 
> G.
> 
> 

Bug#934739: RM: ndpi [armhf] -- RoQA; FTBFS

[Gianfranco Costamagna]

Package: ftp.debian.org
Severity: normal

Hello, looks like ndpi fails on armhf when built with a builder with an arm64 
kernel, because of some aligment issue.

I forwarded the issue to github [1] , but I propose for now to just drop armhf, 
and wait for an upstream fix

[1] https://github.com/ntop/nDPI/issues/763


G.

Bug#934740: nftables: broken on BE

[Gianfranco Costamagna]

Source: nftables
Version: 0.9.1-2
Severity: serious
Tags patch

Hello, after trying to understand why firewalld was completely broken on s390x, 
and discussing with nftables upstream, they found that a particular commit: 
142350f154c7
broke Big Endian machines.

this is the set of patches:
https://marc.info/?l=netfilter-devel=156572714605196=2


Also, please add docbook-xsl build dependency, on some systems, it might be not 
installed and then the build fail because of missing schema

e.g.

make[3]: Entering directory '/<>/doc'
a2x -L --doctype manpage --format manpage -D . nft.txt
a2x -L --doctype manpage --format manpage -D . libnftables-json.adoc
a2x -L --doctype manpage --format manpage -D . libnftables.adoc
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/<>/doc/libnftables.xml" 
returned non-zero exit status 5
make[3]: *** [Makefile:648: libnftables.3] Error 1
make[3]: *** Waiting for unfinished jobs
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/<>/doc/libnftables-json.xml" returned non-zero exit status 5
make[3]: *** [Makefile:651: libnftables-json.5] Error 1
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/<>/doc/nft.xml" 
returned non-zero exit status 5
make[3]: *** [Makefile:645: nft.8] Error 1
make[3]: Leaving directory '/<>/doc'
make[2]: *** [Makefile:484: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:393: all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: make -j4 returned exit code 2
make: *** [debian/rules:15: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2



You can grab patches from my Ubuntu upload
https://launchpad.net/ubuntu/+source/nftables/0.9.1-2ubuntu3

including the missing schema fix.

thanks
(I'm still testing them, but I prefer to open the RC bug in advance, I'll 
update in case something else is needed)

Gianfranco

Bug#891532: captagent FTBFS with shared libfl

[Gianfranco Costamagna]

and attached.
diff -Nru captagent-6.1.0.20/debian/changelog 
captagent-6.1.0.20/debian/changelog
--- captagent-6.1.0.20/debian/changelog 2017-01-15 21:09:31.0 +0100
+++ captagent-6.1.0.20/debian/changelog 2019-08-14 09:59:44.0 +0200
@@ -1,3 +1,11 @@
+captagent (6.1.0.20-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * debian/patches/shared-libfl.patch:
+- find shared libfl (Closes: #891532)
+
+ -- Gianfranco Costamagna   Wed, 14 Aug 2019 
09:59:44 +0200
+
 captagent (6.1.0.20-3) unstable; urgency=high
 
   * Update Build-Deps for default-libmysqlclient-dev. (Closes: #845827)
diff -Nru captagent-6.1.0.20/debian/patches/series 
captagent-6.1.0.20/debian/patches/series
--- captagent-6.1.0.20/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ captagent-6.1.0.20/debian/patches/series2019-08-14 09:59:43.0 
+0200
@@ -0,0 +1 @@
+shared-libfl.patch
diff -Nru captagent-6.1.0.20/debian/patches/shared-libfl.patch 
captagent-6.1.0.20/debian/patches/shared-libfl.patch
--- captagent-6.1.0.20/debian/patches/shared-libfl.patch1970-01-01 
01:00:00.0 +0100
+++ captagent-6.1.0.20/debian/patches/shared-libfl.patch2019-08-14 
09:59:44.0 +0200
@@ -0,0 +1,36 @@
+Description: AC_CHECK_LIB(fl, yywrap) doesn't work with shared libfl
+Author: Adrian Bunk 
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891532
+
+--- captagent-6.1.0.20.orig/configure.ac
 captagent-6.1.0.20/configure.ac
+@@ -153,6 +153,10 @@ AC_PROG_LEX
+ if test "$LEX" != "flex"; then
+   AC_MSG_ERROR([flex not found. Please install flex])
+ fi
++if test "x$LEXLIB" = "x"; then
++  AC_MSG_ERROR([captagent requires but cannot find libfl])
++fi
++
+ 
+ if test -z "`echo %%|$LEX -t|grep yypop_buffer_state`"; then
+   AC_MSG_ERROR([flex missing yypop_buffer_state - upgrade to version 
2.5.33 or later])
+@@ -181,8 +185,6 @@ echo "If it is in a different di
+ echo "the LDFLAGS to set its proper path.";
+ AC_MSG_ERROR([Fatal:  libjson not found.])])])
+ 
+-AC_CHECK_LIB(fl, yywrap, [ FLEX_LIBS="-lfl" ] , [AC_MSG_ERROR([captagent 
requires but cannot find libfl])])
+-
+ AC_SUBST(PTHREAD_LIBS)
+ AC_SUBST(DL_LIBS)
+ AC_SUBST(EXPAT_LIBS)
+--- captagent-6.1.0.20.orig/src/Makefile.am
 captagent-6.1.0.20/src/Makefile.am
+@@ -19,6 +19,6 @@ AM_CPPFLAGS = -DSYSCONFDIR='"$(sysconfdi
+ BUILT_SOURCES = capplan.tab.h
+ noinst_HEADERS = md5.h captagent.h conf_function.h
+ captagent_SOURCES = captagent.c conf_function.c log.c md5.c modules.c 
xmlread.c capplan.l capplan.tab.y
+-captagent_LDADD = ${PTHREAD_LIBS} ${EXPAT_LIBS} ${DL_LIBS} ${FLEX_LIBS}
++captagent_LDADD = ${PTHREAD_LIBS} ${EXPAT_LIBS} ${DL_LIBS} ${LEXLIB}
+ captagentconfdir = $(sysconfdir)/$(bin_PROGRAMS)
+ captagentconf_DATA = $(top_srcdir)/conf/$(bin_PROGRAMS).xml

Bug#891532: captagent FTBFS with shared libfl

[Gianfranco Costamagna]

control: tags -1 patch pending
On Mon, 26 Feb 2018 15:22:58 +0200 Adrian Bunk  wrote:
> Source: captagent
> Version: 6.1.0.20-3
> Severity: serious
> Tags: buster sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/captagent.html
> 
> ...
> checking whether make sets $(MAKE)... (cached) yes
> checking for flex... flex
> checking lex output file root... lex.yy
> checking lex library... -lfl
> checking whether yytext is a pointer... yes
> checking for bison... bison -y
> checking for pthread_create in -lpthread... yes
> checking for dlopen in -ldl... yes
> checking for XML_ParserCreate in -lexpat... yes
> checking for pcap_open_live in -lpcap... yes
> checking for json_object_get in -ljson... no
> checking for json_object_get in -ljson-c... yes
> checking for yywrap in -lfl... no
> configure: error: captagent requires but cannot find libfl
> 
> 
> Fix attached.

uploaded as NMU.

G.

Bug#934734: [Pkg-javascript-devel] Bug#934734: RM: libv8-3.14 -- ROM; outdated and useless library

[Jérémy Lal]

Seconded. It also provides libv8-dev and that confuses other packagers
because
the latest libv8-dev is provided by libnode-dev.

Le mer. 14 août 2019 à 09:15, Xavier Guimard  a écrit :

> Package: ftp.debian.org
> Severity: normal
>
> Hi all,
>
> libv8-3.14 is an outdated library with many security issue [1]. It had
> one reverse dependency which is ROM-RM also (#934243, done).
>
> Then I think it should be removed from Debian.
>
> Cheers,
> Xavier
>
> [1]:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=libv8-3.14
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#934738: gettext 0.20.1 available

[Sebastien Bacher]

Package: gettext
Version: 0.19.8.1-9

There is a new 0.20 version available, it would be nice to get it
uploaded to Debian
https://savannah.gnu.org/forum/forum.php?forum_id=9430

(in fact a .1 on https://ftp.gnu.org/pub/gnu/gettext/gettext-0.20.1.tar.xz)

Thanks,

Bug#934736: initramfs-tools: MODULES=dep fails when rootfs is zfs

[Aron Xu]

Package: initramfs-tools
Version: 0.130
Severity: normal
Tags: patch

Hi,

In hook-funtions, dep_add_modules_mount() wants a real mount point
while zfs only presents its mount point as a virtual one named by the
underlying dataset in /proc/mounts, this makes the function abort
claiming unable to detect the root device.

Such behavior breaks the installation of kdump-tools with zfs as
rootfs because it explictly generates a new initrd with MODULES=dep.

Attached patch makes dep_add_modules_mount() return upon detecting a
zfs rootfs. Because users who run zfs as rootfs are required to
install zfs-initramfs package, where a lot more details are handled,
there is no potential breakage for not handling zfs related kernel
modules here. If someday we have built-in support of zfs in
initramfs-tools package, this peice of code should be revisted,
though.

Regards,
Aron


0001-hook-funtions-return-from-dep_add_modules_mount-for-.patch
Description: Binary data

Bug#934737: cracklib 2.9.7 available

[Sebastien Bacher]

Package: cracklib2
Version: 2.9.6-2

There is a new version available upstream (include a CVE fix already
distro patch but also a buffer overflow fix) which would be nice to get
in Debian
https://github.com/cracklib/cracklib/releases/tag/v2.9.7

Thanks,

Bug#934721: sbuild: Lintian run via sbuild produces different output than running lintian manually with the same options

[Johannes Schauer]

Hi William,

Quoting William Blough (2019-08-14 02:52:00)
> To reproduce-
> 
> 1. For an arbitrary package (I used hello in my example), create a new
> debian/changelog entry with the distribution set to UNRELEASED.
> 
> 2. build with sbuild, specifying a target distribution, and enable lintian:
> sbuild -d unstable --run-lintian --lintian-opts=-v
> 
> 3. Note from the output/log that lintian *does not* emit the
> "unreleased-changes" tag.
> 
> 4. Find the .changes file produced by the sbuild build
> 
> 5. Run lintian against the changes file from 4, with the same options
> used for linitan in 2:
> lintian hello_2.10-2.1_amd64.changes -v
> 
> 6. Note that lintian *does* emit the "unreleased-changes" tag for the
> changes file produced by the earlier build with sbuild.
> 
> 
> Expected output:
> "unreleased-changes" tag emitted by lintian when run under sbuild and when 
> run manually
> 
> Observed output:
> "unreleased-changes" tag only emitted by linitan when run manually.  Tag
> not emitted when lintian run by sbuild
> 
> 
> I've attached a build log (with debug) for an example build, and a terminal
> session log for the related manual lintian run.
> 
> I've verified that this happens on both unstable and buster (inside
> chroots), with their respective versions of sbuild and lintian. I
> haven't tried earlier suites or versions.
> 
> 
> I'm not 100% certain that this is an sbuild issue, but I've done
> everything I can think of to rule out my configuration.  And since
> lintian seems to produce the correct behavior outside of sbuild, I
> thought this would be the logical place to start the bug report.
> 
> I'd appreciate any insight you can give, and would be happy to help
> test/troubleshoot further.

thanks a lot for your excellent bug report!

Unfortunately, the effect you are seeing is not a bug but a feature back from
the time before I started maintaining sbuild. To understand the situation, it
is important to know what the -d option that you are using above actually does.
>From the man page:

   -d, --dist=distribution
  Explicitly set the distribution for the package build. This will
  be  selecting  the correct chroot to use and also sets the value
  of the Distribution field in the created .changes file.  Setting
  this  option  is  necessary  when giving sbuild a .dsc file or a
  plain source package name to build. In the latter case it speci‐
  fies  the distribution the source package is fetched from.  This
  command line option sets the  DISTRIBUTION  configuration  vari‐
  able. See sbuild.conf(5) for more information.

As you can see, this will set the Distribution field and thus the value will
not be UNRELEASED anymore and thus lintian does not complain anymore. If you
look closely at the output of sbuild, you will see that the "Distribution"
value is highlighted in yellow. This is to indicate that the value was changed.

Usually you should *not* use the -d parameter but instead set up your schroot
config such that you don't need the -d parameter. This can be automated by
specifying --alias=UNRELEASED when running sbuild-createchroot. What that
option effectively does is to set aliases=UNRELEASED in the corresponding
config file in /etc/schroot/chroot.d/.

Do you see any way sbuild could improve to be less confusing?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#934735: dh-apparmor: please improve dh integration

[Andrej Shadura]

Package: dh-apparmor
Version: 2.13.2-9ubuntu6.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

It would be great if the integration with dh could be improved.

The first step would be to enable --with=apparmor support with a script
like this (/usr/share/perl5/Debian/Debhelper/Sequence/apparmor.pm):

#! /usr/bin/perl
# debhelper sequence file for dh_apparmor

use warnings;
use strict;
use Debian::Debhelper::Dh_Lib;

insert_after("dh_install", "dh_apparmor");

1

It would also require dh_apparmor to do some guesswork and not create
postinst scripts for binary packages not shipping anything
apparmor-related.

Please consider implementing this.

Thanks!

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl1TuicUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdJh0Qf/WJSl0gC+6DG9kMEwZxvX5shXGbXZ
n5RzwjOxzu8II3+otK+OzpZZIFjd7gjCX6SOd9ZAa/54mxtodhTameN5rOkJwXIE
5qfMxX3bwhFp+OhFHW2vSfj73UjMWqlc2wds3dDcg9qWDjNUGu2Wux8BVmwGXq6v
5CB0WKBq66h5UshyW+ZzPaRrYdAzbUchBmk4sdzzPb0tC+VLI8IK1CNNa0jZ2Htd
2coDjqqFiLH9IyKF0LdqH8r5uT6H2cq8aeZc0QKxgDNnO3l1uMKK4o4D5zUcGDYN
hodvihCEbrr/PQqMLfmn0+tT8N2LNMiiZzbCeLAIpdnYhvWOFXN8zbvhcQ==
=ar7M
-END PGP SIGNATURE-

Bug#859122: 31 DLAs missing from the website

[Brian May]

On Mon, Apr 15, 2019 at 12:06:35PM +, Holger Levsen wrote:
> many thanks for all your fixes on this bug!

Can you please rerun the command:

~/Projects/debian-www/webwml$ ../cron/parts/10-check-advisories --mode DLA

I am loosing track of which DLAs are still missing, and it looks like
I can't run that command myself.

Thanks
-- 
Brian May 

Bug#934657: apt: add interface between external downloaders (apt-offline/apt-zip) and apt

[Paul Wise]

On Tue, 2019-08-13 at 13:12 +0200, Julian Andres Klode wrote:

> I think it's the wrong solution though. The correct solution is to bundle
> the offline system's state (/var/lib/apt, /var/lib/dpkg/status, /etc/apt),
> copy it to the online system, and then calculate and download the
> update/upgrade there, and copy /var/lib/apt and /var/cache/apt back.

That means that you would basically have to port apt to various
platforms where users could conceivably want to do the downloading.
I'm assuming you aren't going to want to port apt to the BSDs, Windows,
macOS, Apple OS9, Solaris, Android, iOS, Symbian, Huawei HarmonyOS etc,
which could all conceivably be the downloader system for apt-offline.

OTOH, all of these systems probably have some sort of wget-like command
or other automatic way to download files (and maybe hash them). So if
apt could export the things that need downloading, then apt-offline
could convert that to the appropriate file formats and commands needed
for downloading from almost arbitrary downloader platforms.

> Hence I'd propose to have a bundle and an unbundle command or something.

I wouldn't object to having this feature in addition to the one I
propose, but I think bundle/unbundle is only going to be useful in
situations where the downloader is running Debian/Ubuntu, which is
probably rare in random Internet cafes in Pakistan for eg.

> update is not possible. we don't know which files we'll have to
> fetch, it depends on the server response.

Hmm, apt-offline manages to do that just fine, it uses --print-uris

> ugh, no. verification is pretty complex, we don't want people to
> reimplement it.

The verification would not be the final verification, that would be
done by apt on the offline system. The verification done on the
downloader system would mainly be a convenience, to avoid another
round-trip in the case of a corrupted download etc.

> Just stuff them into partial, and run install to make it recognize
> the files are already downloaded.

Does putting them into partial do verification?

I think just stuffing into partial is the cause of bug #871656.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#934734: RM: libv8-3.14 -- ROM; outdated and useless library

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi all,

libv8-3.14 is an outdated library with many security issue [1]. It had
one reverse dependency which is ROM-RM also (#934243, done).

Then I think it should be removed from Debian.

Cheers,
Xavier

[1]: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=libv8-3.14

Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging

[Philip Withnall]

On Tue, 2019-08-13 at 23:16 +, brian m. carlson wrote:
> On 2019-08-13 at 06:12:30, Philip Withnall wrote:
> > Hi,
> > 
> > I can’t speak for the Debian project, but as an upstream GLib
> > developer
> > I can say such an environment variable would not be welcome
> > upstream.
> > 
> > Hiding such warnings makes them less likely to be fixed. It’s a way
> > of
> > sweeping bugs under the carpet which I don’t want to encourage.
> > Each
> > warning emitted by GTK or GLib indicates a non-trivial bug in the
> > code
> > which is calling it, which should be fixed.
> 
> Unfortunately, it's often impossible to write code which works on
> multiple versions of GTK+ without warnings. I took a version of GVim
> which worked fine on Debian unstable with GTK+3 but produced copious
> warnings on CentOS 7. This makes it difficult for folks who would
> like
> to upgrade one single component on a system without rebuilding the
> entire GTK+ stack. In addition, an upgrade of GTK+ can cause
> previously
> working programs to produce errors where they did not before, causing
> problems for users.

I can believe that might be true in some cases, but I doubt it is
*often* the case. Regardless, I encourage you to ask specific questions
about the warnings you are encountering on https://discourse.gnome.org/
, and the GTK developers should be able to advise appropriately for
each case.

> In addition, Unix programs typically produce output to standard error
> to
> reflect a user-relevant error: something that the user has done wrong
> or
> that prevents the program from functioning in the way the user
> requested. These warnings are not user relevant: they reflect a
> developer error, not a problem that reflects a user-visible failure.
> From the user perspective, everything is functioning as intended, so
> output to standard error is not appropriate.
> 
> And finally, overwhelmingly, developers take a long time to fix
> warnings
> like this, if they get fixed at all. Perhaps they don't see the use
> case
> of running graphical programs like PDF viewers from the command line.
> More likely, they are overwhelmed with other issues and consider this
> low priority.
> 
> I appreciate that these reflect a defect in the program that should
> be
> fixed, but it isn't fair to force users to either fix these defects
> for
> themselves or deal with terminal junk. As a Git developer, I can tell
> you people would be extremely unhappy if libpcre or libcurl produced
> errors on their terminals when they ran Git, even if those were bugs
> in
> Git itself. I'm not sure why GLib should be different in this regard.

Sorry, I think you’re conflating two different types of programs here.
Command line applications like git have very different output
requirements on stderr/stdout from graphical programs. Command line
programs don’t normally use GTK, so shouldn’t see any of the warnings
you mention above. I would be very surprised if command line programs
using GLib (not GTK) emitted different warnings with different versions
of GLib. If they do, can you please provide me with concrete examples
and I can advise you about how to eliminate them.

GTK and GLib are separate libraries.

> Ultimately, I think it's most appropriate to let users decide for
> themselves if they would like to see non-user-visible issues on their
> terminal. I'm not even asking for this to be the default, just an
> option
> users can turn on.

If it’s not on by default, almost all users will never find out about
it. If your argument is that seeing the warnings is only useful for
developers, then such an option should be on by default and developers
would have to explicitly turn it off.

In every situation where I’ve seen warnings (compile time, or run time)
hidden from developers, those warnings have very rarely been fixed.
Making them visible has increased the number of warnings which have
been fixed.

Filing bugs against applications, which point out specific warnings
which need fixing is, I feel, a much better use of people’s time than
inventing new and innovative ways to hide those warnings.

Philip

Bug#933636: CVE-2019-14934

[Salvatore Bonaccorso]

Hi Francois,

[Important disclaimer: not part of the release team]

On Tue, Aug 13, 2019 at 11:29:55PM -0700, Francois Marier wrote:
> There is now an additional CVE that affects pdfresurrect in buster and
> stretch:
> 
>   https://security-tracker.debian.org/tracker/CVE-2019-14934
> 
> Neither this one or CVE-2019-14267 are deemed worthy of a DSA however.
> 
> If you approve the first upload I have prepared for buster and stretch, I
> will revise it to include the fix for this second CVE, but I will wait for
> your initial approval before putting any more work into this.

If you are confident with all of the changes that they would be
accepted, then you even can already proceeed. Important is though that
you provide the bugreport and a corresponding debdiff to the SRM.

See the announcement on the new workflow:
https://lists.debian.org/debian-devel-announce/2018/04/msg7.html

Hope this helps!

Regards,
Salvatore

Bug#934733: ITP: webots -- Webots is robot simulator providing a complete development environment to model, program and simulate robots, vehicles and biomechanical systems.

[Olivier Michel]

Package: wnpp
Severity: wishlist
Owner: Olivier Michel 

* Package name    : webots
  Version : R2019b
  Upstream Author : Olivier Michel 
* URL : https://github.com/omichel/webots
* License : Apache 2.0
  Programming Lang: C++
  Description : Webots is robot simulator providing a complete development 
environment to model, program and simulate robots, vehicles and biomechanical 
systems.

Webots is an open-source robot simulator.
It is widely used in industry, education and research.
The Webots project started in 1996, initially developed by Dr. Olivier Michel 
at the Swiss Federal Institute of
Technology (EPFL) in Lausanne, Switzerland.
Since December 2018, it is released under the Apache 2 license.

Webots uses a fork of the ODE (Open Dynamics Engine) for detecting of 
collisions and simulating rigid body dynamics.
The ODE library allows one to accurately simulate physical properties of 
objects such as velocity, inertia and friction.

A large collection of freely modifiable robot models comes in the software 
distribution.
In addition, it is also possible to build new models from scratch.
When designing a robot model, the user specifies both the graphical and the 
physical properties of the objects.
The graphical properties include the shape, dimensions, position and 
orientation, colors, and texture of the object.
The physical properties include the mass, friction factor, as well as the 
spring and damping constants.
Simple fluid dynamics is present in the software.

Webots includes a set of sensors and actuators frequently used in robotic 
experiments, e.g. proximity sensors,
light sensors, touch sensors, GPS, accelerometers, cameras, emitters and 
receivers, servo motors (rotational & linear),
position and force sensor, LEDs, grippers, gyros, compass, etc.

The robot controller programs can be written in C, C++, Python, ROS, Java and 
MATLAB using a simple API.

Webots offers the possibility to take PNG screen shots and to record the 
simulations as MPEG (Mac/Linux) and AVI
(Windows) movies. Webots worlds are stored in cross-platform .wbt files which 
format is based on the VRML language.
It is also possible to import and export Webots worlds or objects in the VRML 
format.
Another useful feature is that the user can interact with a running simulation 
at any time, i.e.,
it is possible to move the robots and other object with the mouse.
Webots can stream a simulation on web browsers using WebGL.

Webots is used in several online robot programming competitions including 
https://robotbenchmark.net

This package is useful as it is often recognized as the best tool for 
simulating mobile robots.
It is used by thousands of research labs worldwide in both academia and 
industry.
Another package providing a similar functionality is Gazebo.
Comparing to Gazebo, Webots is easier-to-use and more powerful on a large 
number of features:
3D rendering, sensor modeling, physics simulation acuracy, transfer to real 
robots, etc.

We plan to maintain it on the long term as we are receiving European funding 
for that purpose.
We do not need co-maintenainers, we would welcome volunteer :).
We need a sponsor to get into debian.

Bug#934732: RM: jscommunicator -- ROM; Orphaned upstream

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi all,

jscommunicator has been removed from testing 3 years ago. 26 issues are
opened upstream [1], but there is no changes for 4 years. jscommunicator
has no reverse dependencies.

That's why I think it should be removed from Debian.

Cheers,
Xavier

Bug#934731: uwsgi-emperor: Fails to stop due to too wide pidfile permissions

[matthijs]

Package: uwsgi-emperor
Version: 2.0.18-1
Severity: normal

Hi,

on my uwsgi-emperor setup, I've noticed that uwsgi-emperor fails to
stop or restart. e.g. when running `systemctl stop uwsgi-emperor`, I get
(in `systemctl status uwsgi-emperor`):

  systemd[1]: Stopping LSB: Start/stop uWSGI server instance(s)...
  uwsgi-emperor[11470]: start-stop-daemon: matching on world-writable pidfile 
/run/uwsgi-emperor.pid is insecure
  systemd[1]: uwsgi-emperor.service: Succeeded.

However, even though this says "Succeeded", uwsgi-emperor is still
running as before, so I suspect start-stop-daemon has refused to act.

Looking at the pidfile, I see indeed 666 permissions:

  -rw-rw-rw- 1 root root 6 aug 14 07:51 /run/uwsgi-emperor.pid

Manually clearing the permissions (`chmod o-rwx /run/uwsgi-emperor.pid`)
before running stopping indeed fixes both the message and makes the
emperor stop properly.

I found a mailing list post which suggests that
this is due to the --daemonize option, which sets the umask to 0:

http://lists.unbit.it/pipermail/uwsgi/2013-April/005803.html

I think this issue has started occurring after upgrading to Buster. I
suspect that maybe start-stop-daemon has become more strict in its
permission check, or maybe the permissions changed on the uwsgi side.

Adding `--umask 022` to the initscript fixed the permissions for my
setup, but I suspect this might actually change all kinds of permissions
for other files too, so this might not be ideal as a general solution.

It seems uwsgi does not currently have any option to set the permissions
of the pidfile, which might be the best solution. Doing a chmod from the
init script seems like a workaround, but AFAICS would leave a race
condition where the pidfile is writable for a short while.

I have only tested this on a configured production system, but I highly
suspect that this is not related to my setup, but also broken in a
default installation. I've included my emperor config below as an
indication.

Gr.

Matthijs

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (800, 'testing'), (700, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages uwsgi-emperor depends on:
ii  uwsgi-core  2.0.18-1

uwsgi-emperor recommends no packages.

uwsgi-emperor suggests no packages.

-- Configuration Files:
/etc/uwsgi-emperor/emperor.ini changed:
[uwsgi]
log-date = true
strict = true
set-placeholder = base-dir=/etc/uwsgi-emperor
emperor = glob://%(base-dir)/vassals/*/app-*.ini
emperor = glob://%(base-dir)/vassals/app-*.ini
vassals-include-before = vassal-defaults.ini
hook-as-vassal = callret:chdir %(base-dir)
show-config = 1

-- no debconf information

Bug#934730: RM: node-yawl -- ROM; orphaned upstream - FTBFS

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi all,

node-yawl never entered to testing due to FTBFS. Issue posted to
upstream [1], but nobody answers. node-yawl has no reverse dependencies.

That's why I propose to remove it from Debian

Cheers,
Xavier

[1]: https://github.com/andrewrk/node-yawl/issues/5

Bug#924519: closed by Dmitry Bogatov (Bug#924519: fixed in lsb 11.0.0)

[Didier 'OdyX' Raboud]

Excellent, thank you very much Dmitry!

I am really happy that src:lsb found a new home!

Cheers,
OdyX

13 août 2019 20:54 "Debian Bug Tracking System"  a écrit:
> This is an automatic notification regarding your Bug report
> which was filed against the wnpp package:
> 
> #924519: RFA: lsb -- Linux Standard Base init script functionality
> 
> It has been closed by Dmitry Bogatov .

Bug#933636: CVE-2019-14934

[Francois Marier]

There is now an additional CVE that affects pdfresurrect in buster and
stretch:

  https://security-tracker.debian.org/tracker/CVE-2019-14934

Neither this one or CVE-2019-14267 are deemed worthy of a DSA however.

If you approve the first upload I have prepared for buster and stretch, I
will revise it to include the fix for this second CVE, but I will wait for
your initial approval before putting any more work into this.

Francois

-- 
https://fmarier.org/

Bug#934723: Extra info

[Android Dev]

Compiling from source and running in gdb, the crash happens in
plugins/authenticator/shotwell/GoogleAuthenticator.vala:25
In line 24, the variable uri is defined as:
new Soup.URI(get_view().get_uri())
but get_view().get_uri() turns out to be null,

Running with logging (SHOTWELL_LOG=1 SHOTWELL_LOG_FILE=:console:), I get:
L 22817 2019-08-14 02:30:27 [DBG] PublishingPluginHost.vala:113:
ConcretePublishingHost.start_publishing( ): invoked.
L 22817 2019-08-14 02:30:27 [DBG] PhotosPublisher.vala:525:
GooglePhotos.Publisher: start() invoked.
L 22817 2019-08-14 02:30:27 [DBG] GoogleAuthenticator.vala:421:
ACTION: showing service welcome pane.
L 22817 2019-08-14 02:30:27 [DBG] PublishingUI.vala:542:
PublishingDialog: install_pane( ): invoked.
L 22817 2019-08-14 02:30:35 [DBG] GoogleAuthenticator.vala:427: EVENT:
user clicked 'Login' in welcome pane.
L 22817 2019-08-14 02:30:35 [DBG] GoogleAuthenticator.vala:167:
ACTION: running OAuth authentication flow in hosted web pane.
L 22817 2019-08-14 02:30:35 [DBG] PublishingPluginHost.vala:70:
Publishing.PluginHost: install_dialog_pane( ): invoked.
L 22817 2019-08-14 02:30:35 [DBG] PublishingUI.vala:542:
PublishingDialog: install_pane( ): invoked.
L 22817 2019-08-14 02:30:35 [DBG] PublishingUI.vala:545:
PublishingDialog: install_pane( ): a pane is already installed;
removing it.
Segmentation fault

Bug#886739: 886...@bugs.debian.org

[Gregor Riepl]

> And ubuntu is now shipping 1.0
> https://launchpad.net/ubuntu/+source/kubernetes/1.0

AFAIK there is no "Kubernetes 1.0".
Kubernetes has an almost extreme cadence of new releases; we're at 1.15.2
right now and the next major release (1.16) is already in alpha.

> May this be synced back to debian or is there any blocking dependencies ?

As the bug author has stated, it's a massive amount of work to release new
Kubernetes versions on Debian. Doing so in a timely manner would require more
maintainers.

That being said, I think dependency management for Go packages has improved a
lot in Debian, Go and the Kubernetes project thanks to Go modules, and it
should be possible to add a bit of automation there. It's still necessary to
do all the grunt work, checking licenses, verifying buildability, etc.

While I'm a bit disappointed that Debian does not maintain up to date
Kubernetes binaries, not even kubectl, I currently don't have the time to work
on them on my own.

I'd be glad to help, however, if someone wants to point me in the right
direction. Is there some sort of documentation, script or dpkg template for
easy Debian go-* packaging available? Ideally something that would also
produce packaging for dependencies as listed by go mod?

Bug#928640: tiger: This makes the cronjob fail noisily every hour on my laptop

[Francois Marier]

Package: tiger
Version: 1:3.2.4~rc1-1
Followup-For: Bug #928640

Every hour, I receive the following email from cron:

  /usr/sbin/tigercron: 127: /usr/lib/tiger/systems/default/config: expot: not 
found
  --ERROR-- [init001e] Don't have required command DIFF.

Attached is the patch I sent to the upstream developer. Note that there are
two typos ("expot => export" and "MAILE => MAILER").

Francois

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

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

Versions of packages tiger depends on:
ii  binutils   2.32.51.20190727-1
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.28-10
ii  net-tools  1.60+git20180626.aebd88e-1
ii  ucf3.0038+nmu1

Versions of packages tiger recommends:
ii  chkrootkit  0.52-3+b10
pn  john
ii  postfix [mail-transport-agent]  3.4.5-1
pn  tripwire | aide 

Versions of packages tiger suggests:
ii  lsof  4.91+dfsg-1+b1

-- debconf information:
* tiger/mail_rcpt: root
* tiger/policy_adapt:
>From 6ed09d5b458237c0cf43a06dec676e625c8e8059 Mon Sep 17 00:00:00 2001
From: Francois Marier 
Date: Tue, 13 Aug 2019 23:04:11 -0700
Subject: [PATCH] Fix tiger typos

This resolves the following error message:

/usr/sbin/tigercron: 127: /usr/lib/tiger/systems/default/config: expot: not found
--ERROR-- [init001e] Don't have required command DIFF.

---
 systems/default/config | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/systems/default/config b/systems/default/config
index e96a8bd..1912567 100644
--- a/systems/default/config
+++ b/systems/default/config
@@ -20,6 +20,7 @@
 # default/config - 04/15/2003 - jfs - Fixed typos and added necessary programs
 # default/config - 09/19/2003 - jfs - Added UUID and USERNAME
 # default/config - 02/10/2018 - jfs - Added MD5SUM. Export MAILER
+# default/config - 08/13/2019 - francois - Fixed typos
 #
 #-
 #
@@ -124,7 +125,7 @@ X=`$EGREP -s : /etc/passwd 2>&1 | $TAIL -1`
 export CAT LS LSGROUP LSLINK RM AWK GREP EGREP SGREP SED
 export SORT COMM TAIL MV TR JOIN GROUPSS FILECMD UNIQ BASENAME
 export CHMOD CHOWN LN PASTE ID CUT HEAD WC DIFF EXPAND LSOF
-expot  MAILE MD5SUM
+export MAILER MD5SUM
 #
 UNAME=`findcmd uname`
 HOSTNAME=`findcmd hostname`
-- 
2.23.0.rc1