Bug#916578: ITP: goofys -- a high-performance, POSIX-ish Amazon S3 file system written in Go

[Ilya Konstantinov]

Package: wnpp
Severity: wishlist
Owner: Ilya Konstantinov 

* Package name: goofys
  Version : 0.19.0+git20181015.635cbfe-1
  Upstream Author : Ka-Hing Cheung
* URL : https://github.com/kahing/goofys
* License : Apache-2.0
  Programming Lang: Go
  Description : a high-performance, POSIX-ish Amazon S3 file system written 
in Go

 Goofys is a high-performance, POSIX-ish Amazon S3
 (https://aws.amazon.com/s3/) file system written in Go
 .
 It's a Filey System instead of a File System because goofys strives
 for performance first and POSIX second. Particularly things that
 are difficult to support on S3 or would translate into more than one
 round-trip would either fail (random writes) or faked (no per-file
 permission). Goofys does not have an on disk data cache, and
 consistency model is close-to-open.
 

Bug#911380: Adjust server/Debian/share/ltsp/ltsp-build-client-functions

[Vagrant Cascadian]

On 2018-12-10, Wolfgang Schweer wrote:
> On Sat, Dec 08, 2018 at 03:08:22PM +0100, Vagrant Cascadian wrote:
>> On 2018-12-07, Vagrant Cascadian wrote:
>> But it's also possible to have some mirrors include a file:/// url
>> that's trusted and some that are not... so it needs to be specified on a
>> per-mirror basis.
>
> Just another try w/ conditionally added trust; the attached patch seems 
> to work for me, please check.

> Wolfgang
> From 7106088bcbd7d0a0a49144b66ab10ab2f943e9d6 Mon Sep 17 00:00:00 2001
> From: Wolfgang Schweer 
> Date: Mon, 10 Dec 2018 11:02:26 +0100
> Subject: [PATCH] Debian: ltsp-build-client: Trust file:/ mirrors that point to
>  /media/cdrom to be able to use a CDROM now that file:/// mirrors are no
>  longer trusted by default. https://bugs.debian.org/911380

This seems too fragile; if /media/cdrom changes yet again, it will
break. But the code I committed to ltsp upstream doesn't work either for
a wide variety of reasons... this is turning out to be very messy...

I'm now thinking of passing an option --trust-file-mirrors or something
like that. Then the trust is explicit, consistent with apt behavior
requiring to explicitly trust it. It wouldn't allow different levels of
trust for different file mirror types, but it will at least be simpler
to code...


It's also hard to invest in ltsp-build-client at this point;
ltsp-build-client should be deprecated entirely, as it's already not the
recommended way to install LTSP... but there's a lot of work left to do
to really drop it.


live well,
  vagrant

Bug#916577: dahdi: DAHDI spantype detection fails in Buster kernel

[John Lines]

Package: dahdi
Version: 1:2.11.1-3
Severity: important

Dear Maintainer,

Some kernel version - possibly 4.13.0, changed the name of the spantype 
attribute from
spantype to dahdi_spantype.

This breaks dahdi_span_assignments, dahdi_genconf, dahdi_span_types and 
possibly others

Asterisk reference to the same issue at 
https://issues.asterisk.org/jira/browse/DAHTOOL-80

Simple fix for dahdi_span_assignments is

159,160c159
< # for local_spanno in `cut -d: -f1 "$device/spantype"`
<   for local_spanno in `cut -d: -f1 "$device/dahdi_spantype"`
---
>   for local_spanno in `cut -d: -f1 "$device/spantype"`

Thank you


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

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

Versions of packages dahdi depends on:
ii  dahdi-linux 1:2.11.1.0.20170917~dfsg-5
ii  fxload  0.0.20081013-1+b2
ii  libc6   2.27-8
ii  libnewt0.52 0.52.20-8
ii  libtonezone2.0  1:2.11.1-3
ii  libusb-1.0-02:1.0.22-2
ii  perl5.28.1-1
ii  procps  2:3.3.15-2
ii  usbutils1:007-4+b1

dahdi recommends no packages.

dahdi suggests no packages.

-- no debconf information

Bug#911559: kicad: pcbnew crashes on reading a eeschema generated netlist

[Carsten Schoenert]

Control: tags -1 pending

Hello Seth,

On Wed, Nov 07, 2018 at 11:45:18AM -0500, Seth Hillbrand wrote:
> > Seth, I guess the root for this report will be fixed with the upcoming
> > release 5.0.2 of Kicad?
> 
> Yes.  The issue was a build flag that needed to be included for i386
> machines.  The default flags are fixed for 5.0.2 but I know that they get
> modified by the debian build, so you may check that that it keeps the extra
> -ffloat-store for 32-bit builds.

I'm working here on the preparation for the upload of 5.0.2 after I've
got some time for this. :-) Should go out of the door as today.

While doing a test build for i386 I can confirm this flag is vissible in
the build log without additional needed modification of the build.

BTW: Debian is only adding some compile options so e.g. hardening is turned
on, also turning on verbose mode for easier debugging.

Regards
Carsten

Bug#916021: lintian: Please check for references to build directory

[Dmitry Bogatov]

[2018-12-13 16:14] Chris Lamb 
> Fixed in Git, pending upload:
> 
>   
> https://salsa.debian.org/lintian/lintian/commit/4aaab6b1c5dd2f4e6da498d15713180e4aa68c76

Severity: wishlist
Certanity: possible

What about excluding some trivial build paths, like "/" or "/build", which
are too short to be useful, and raise both Certanity=certain
and Severity=Error?

PS. Any chance to configure your fine gitlab auto-notifier to send
not only diffstat, but whole diff too?

Bug#916095: lintian: False positive: license-problem-gfdl-invariants

[Dmitry Bogatov]

[2018-12-13 07:10] Chris Lamb 
> Hi Dmitry,
> 
> > > As I understand it, I don't believe this is a false-positive as it is
> > > missing "no bad sections".
> > 
> > What is "bad sections"?  In General Resolution [^1], they are not
> > mentioned.
> 
> Sorry, I am not terribly knowledgable about this license; I am merely
> repeating what is stated elsewhere.
> 
> If you can do some research into this I would be very happy to update
> the description for this tag in order to educate others. :)

Neither I am lawer.

But according to current description of
`license-problem-gfdl-invariants' tag and discussions I had what I
packaged GNU Complexity a while ago, current consensus is that GFDL-1.2+
is fine, as long there is no

 + invariant sections
 + invariant back cover text
 + invariant front cover text

cflow=1.4 had invariant front cover with text "GNU manual", so it was
considered non-dfsg, but cflow=1.5 removed this front cover clause.

Actually, taking look at source code, I found problem:
Lintian expects(cruft.pm:1379) matches first, but not second:

with no invariant sections, no Front-Cover and no Back-Cover texts
with no Invariant Sections, no Front-Cover andBack-Cover texts

Wording in cflow manual miss second `no' word. I believe regex in
Lintian could be relaxed a bit.

Bug#912201: RFS: manticore/2.7.3 [ITP]

[Dmitry Bogatov]

> Added a debian/watch, not sure why mentor lintian doesn't see it, uscan
> doesn't report any error, it should get our official tar.gz release for
> github.

You run `lintian -EvIL +pedantic', don't you? Missing `debian/watch'
considered low-severity issue

> Fixed the overrides and indentation.

Nice. It builds. I found at least following issues.

 * no manpage for wordbreaker. You will not pass NEW without it.
 * whitespace errors in debian/rules, debian/copyright, ...
 * missing years in some entries in debian/copyright
 * your documentation should be in /usr/share/doc/manticore, not MANTICORE
 * I believe you install not all available documentation. You may want
   to create bin:manticore-doc for it.
 * I doubt usefullness for end-user of internal-coding-standard.txt
 * lists in descriptions in `debian/control' are usually indented
   by one space
 * `manticore' system user seems to not get removed on package purge
 * What is the point of 'foo || exit $?' construct with `set -e' set?
 * chown manticore:manticore /etc/sphinxsearch is strage. Files in /etc
   are not meant to be edited by someone, but root. Ideally, you should
   assume /etc is mounted read-only.
 * What are relations with bin:sphinxsearch? Are they co-installable?

I will stop here for now. I am sorry to see you use analytics. Your
right as upstream, sure, but it must not appear in html files, provided
by debian.

Also, I remind you that new packages have only one changelog entry, with
revision -1 and single line "Initial release (Closes: #ITP-number)"

Bug#573763: file-rc is no more

[Dmitry Bogatov]

I believe this bug can be closed, since file-rc is no longer
(unfortunately) in Archives. Dear co-maintainers, objections?


pgpy1fjhMkZgH.pgp
Description: PGP signature

Bug#573571: insserv fails if cwd inaccessible by root

[Dmitry Bogatov]

control: tags -1 +upstream +confirmed

[2010-03-12 14:21] Ben Harris 
> wraith:/tmp# insserv -n
> insserv: warning: current stop runlevel(s) (0 1 6) of script `ntp' overwrites 
> defaults (empty).
> insserv: warning: current stop runlevel(s) (0 1 6) of script `nethack-common' 
> overwrites defaults (empty).
> insserv: dryrun, not creating .depend.boot, .depend.start, and .depend.stop
> 
> I don't think insserv has any reason to look at my home directory, so it
> should succeed even in the current directory is inaccessible.

I can reproduce this bug even simplier:

 $ mkdir /tmp/test
 $ cd /tmp/test
 $ rmdir /tmp/test
 $ sudo insserv -n
 insserv: pushd() can not change to directory /etc/init.d: No such file or 
directory

Jesse, can you please take a look?

Bug#556455: insserv: cannot symlink atd

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2009-11-16 10:42] Karsten Hilbert 
> part   text/plain2161
> Package: insserv
> Version: 1.12.0-14
> Severity: normal
> 
> apt-get upgrade yielded this:
> 
> Richte hal ein (0.5.13-4) ...
> Reloading system message bus config...done.
> insserv: warning: script 'K20xfree86-common' missing LSB tags and overrides
> insserv: warning: script 'S40netenv' missing LSB tags and overrides
> insserv: script S51ntpdate provides system facility $time, skipped!
> insserv: warning: script 'S71xserver-xorg' missing LSB tags and overrides
> insserv: warning: script 'S25libdevmapper1.02' missing LSB tags and overrides
> insserv: warning: script 'libdevmapper1.02' missing LSB tags and overrides
> insserv: warning: script 'netenv' missing LSB tags and overrides
> insserv: warning: script 'xfree86-common' missing LSB tags and overrides
> insserv: script ntpdate provides system facility $time, skipped!
> insserv: warning: current stop runlevel(s) (0 1 6) of script `cpufrequtils' 
> overwrites defaults (empty).
> insserv: warning: script 'xserver-xorg' missing LSB tags and overrides
> insserv: warning: current stop runlevel(s) (0 1 6) of script `tpconfig' 
> overwrites defaults (empty).
> insserv: warning: current stop runlevel(s) (0 1 6) of script `athcool' 
> overwrites defaults (empty).
> insserv: can not symlink(../init.d/atd, ../rc0.d/K01atd): File exists
> insserv: can not symlink(../init.d/atd, ../rc1.d/K01atd): File exists
> insserv: can not symlink(../init.d/atd, ../rc6.d/K01atd): File exists
> Starting Hardware abstraction layer: hald.
> merkur:~/bin#
> 
> While the first few lines are probably obsolete-but-not-purged (?)
> packages the last 3 seem somewhat worrisome.

Dear submitter, can you reproduce issue on modern system?
Also, please set LC_ALL=C.UTF-8 to avoid localization.

Bug#619409: insserv: /etc/init.d/.depend.* represent state, not configuration; please move to /lib

[Dmitry Bogatov]

[2011-03-23 09:33] Josh Triplett 
> insserv generates makefile snippets in /etc/init.d/.depend.* with
> dependency information for init scripts.  This doesn't represent
> configuration information, nor can the user modify it.  Thus, it should
> go somewhere else on the root filesystem, such as /lib/insserv/depend.*
> ..  That would avoid the need to ignore them in etckeeper, or care about
> the differences between successive versions.

Sounds reasonable.

Jesse, would it be hard to implement and would it cause painful
transition?

Bug#575759: Deviations from LSB

[Dmitry Bogatov]

control: tags -1 +moreinfo

Seems things changed during last 8 years. Dear submitter, do you
consider information in manpage of insserv-1.18 sufficent to warrant bug
closing? (quoted below)

   insserv  is  a  low  level  tool  used  by update-rc.d which enables an
   installed system init script (`boot script')  by  reading  the  comment
   header of the script, e.g.:

 ### BEGIN INIT INFO
 # Provides:  boot_facility_1 [ boot_facility_2 ...]
 # Required-Start:boot_facility_1 [ boot_facility_2 ...]
 # Required-Stop: boot_facility_1 [ boot_facility_2 ...]
 # Should-Start:  boot_facility_1 [ boot_facility_2 ...]
 # Should-Stop:   boot_facility_1 [ boot_facility_2 ...]
 # X-Start-Before:boot_facility_1 [ boot_facility_2 ...]
 # X-Stop-After:  boot_facility_1 [ boot_facility_2 ...]
 # Default-Start: run_level_1 [ run_level_2 ...]
 # Default-Stop:  run_level_1 [ run_level_2 ...]
 # X-Interactive: true
 # Short-Description: single_line_description
 # Description:   multiline_description
 ### END INIT INFO

   and  calculating the dependencies between all scripts. It is not recom‐
   mended to execute insserv directly unless you know exactly what  you're
   doing, doing so may render your boot system inoperable.  update-rc.d is
   the recommended interface for managing init scripts.  Please  be  aware
   that the line

 # Required-Stop:  boot_facility_1 [ boot_facility_2 ...]

   declares facilities which must be available during shutdown of the ser‐
   vice declared in the Provides tag.  Same holds true for

 # Should-Stop:boot_facility_1 [ boot_facility_2 ...]

   which declares facilities which should be available during shutdown  of
   the service declared in the Provides tag. In both cases the script sys‐
   tem should avoid stopping services which are declared by these two Stop
   tags until the script including these tags is stopped.

   The  optional  X-Interactive keyword implies that the script using this
   keyword should be started alone  in  a  concurrent  boot  configuration
   because  it  interact  with  the  user  at the console.  Only the value
   `true' is recognised.  All other are ignored.

   The optional X-Start-Before keyword implies that the script using  this
   keyword  should be started before the specified service names.  Whereas
   the optional X-Stop-After keyword implies that the  script  using  this
   keyword  should  be  stopped  after  the  specified service names. Both
   implies that those services now depend on the specifying script.   With
   known dependencies and runlevel(s) insserv sets and reorders the corre‐
   sponding symbolic links of the concerned runlevels directories.

   insserv  scans  for  System  Facilities  in  the   configuration   file
   /etc/insserv.conf  and each file in the directory /etc/insserv.conf.d/.
   Each line which begins with $ and a following  name  defines  a  system
   facility  accordingly  to  the Linux Standard Base Specification (LSB),
   All names followed by such a system facility will declare the  required
   dependenciesofthe   facility.Here   is   an   example   for
   /etc/insserv.conf:

 # All local filesystems are mounted
 # (done during boot phase)
 $local_fs   boot

 # Low level networking
 $networknetwork route

 # Named is operational
 $named  named

 # All remote filesystems are mounted
 # (in some cases /usr may be remote).
 $remote_fs  $local_fs nfs

 # System logger is operational
 $syslog syslog

 # All network daemons are running (This was removed in LSB 1.2)
 $netdaemons portmap inetd

 # Services which need to be interactive
boot.crypto

   Names starting with a `+' sign are marked as optional.  If the  service
   with  the name after the plus sign is available it will be used, if not
   available it is ignored silently.  Words beginning with  <  and  ending
   with  > are keywords.  Currently  is the only know keyword
   for marking a service as an  interactive  one,  e.g.  a  service  which
   requires a passphrase or password input during boot or runlevel change.
   The special facility $null is used to enforce an  empty  dependency  in
   case of Should-Stop and Required-Stop.

   In  addition to the defined System Facilities in the configuration file
   /etc/insserv.conf, insserv also knows the special facility $all.   This
   facility  indicates that a service should be inserted at the end of all
   services at starting and at the very beginning  at  stopping.   Clearly
   all  

Bug#916461: kicad: Keyboard shortcuts from main Place menu don't match actually working shortcuts

[Carsten Schoenert]

Hello Daniel,

Am 14.12.18 um 18:52 schrieb Daniel Reichelt:
> Hi,
> 
> on a clean installation (i.e. rm -rf ~/.config/kicad) all the keyboard
> shortcuts in the main menu "Place" are shown as [Shift]+[], i.e.
> [Shift]+[A] for "Place symbol". However, none of them work. What actually 
> works
> is just pressing the letter key, without shift.

I can reproduce this behavior in testing with Gnome3 and X11 in 5.0.1-1 too.
What Desktop Environment do you use?

-- 
Regards
Carsten Schoenert

Bug#909465:

[Andrew Bartlett]

On Fri, 2018-11-30 at 09:38 -0200, Andreas Hasenack wrote:
> I filed this bug upstream for the time being, since the mailing list
> threads about this topic all died with no clear solution:
> 
> https://bugzilla.samba.org/show_bug.cgi?id=13697

I've raised the priority on the bug and hopefully we can get a fix.

I don't really understand what is going on here and why our tests don't
notice this.

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba

Bug#916576: pbdagcon: FTBFS pbdata/Types.h: No such file or directory

[Andreas Beckmann]

Source: pbdagcon
Version: 0.3+20161121+ds-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

pbdagcon FTBFS in a current pbuilder sid environment
https://buildd.debian.org/status/package.php?p=pbdagcon=unstable

g++ -g -O2 -fdebug-prefix-map=/<>/pbdagcon-0.3+20161121+ds=. 
-fstack-protector-strong -Wformat -Werror=format-security -O3 -std=c++11 -Wall 
-Wuninitialized -pedantic -Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MP 
-I/<>/pbdagcon-0.3+20161121+ds/DAZZ_DB 
-I/<>/pbdagcon-0.3+20161121+ds/DALIGNER 
-I/usr/include/pbseq/alignment -I/usr/include/pbseq/pbdata 
-I/usr/include/pbseq/hdf -isystem.//third-party  -c -o main.o main.cpp
In file included from main.cpp:23:
/usr/include/pbseq/alignment/tuples/TupleMetrics.hpp:4:10: fatal error: 
pbdata/Types.h: No such file or directory
 #include 
  ^~~~
compilation terminated.
make[2]: *** [: main.o] Error 1


Andreas

Bug#915889: freeplane FTBFS: Could not resolve javax.servlet:javax.servlet-api:3.1.

[Felix Natter]

hi Adrian,

thank you for this bug report.

The problem is that the javax.servlet:javax.servlet-api:3.1 artifact
(src:tomcat8/bin:libservlet3.1-java) does not install a
debian/javax.servlet-api-debian.pom, so the resolution fails during
freeplane compilation.

I do not know why this worked previously. In stretch, fop's javax.servlet-api 
artifact was scope:provided, which
would explain why it works in stretch. But I published freeplane-1.7.2 on 
2018-11-24, and back then there
was no problem.

One solution would be to install a correct(?) debian pom for 
javax.servlet:javax.servlet-api:3.1.
I see that tomcat8 uses maven-repo-helper, so I do not understand why that is 
not already the
case?

Markus Koschany reminded me on #debian-java that Emmanuel is in the
process of preparing a new javax-servlex package (#916354), which might
fix this issue. So I will wait for this.

Cheers and Best Regards,
-- 
Felix Natter
debian/rules!

Bug#916575: sweethome3d-textures-editor: depends on obsolete icedtea-netx-common

[Andreas Beckmann]

Package: sweethome3d-textures-editor
Version: 1.5-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid due to the dependency on icedtea-netx-common.

The icedtea-netx-common package is gone, the former contents have been
merged into icedtea-netx. Please update your (build-)dependencies.


Cheers,

Andreas

Bug#916574: sweethome3d-furniture-editor: depends on obsolete icedtea-netx-common

[Andreas Beckmann]

Package: sweethome3d-furniture-editor
Version: 1.23-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid due to the dependency on icedtea-netx-common.

The icedtea-netx-common package is gone, the former contents have been
merged into icedtea-netx. Please update your (build-)dependencies.


Cheers,

Andreas

Bug#916573: sweethome3d: build-depends on cruft icedtea-netx-common

[Andreas Beckmann]

Source: sweethome3d
Version: 6.0+dfsg-1
Severity: serious
Justification: fails to build from source

Hi,

The icedtea-netx-common package is gone, the former contents have been
merged into icedtea-netx. Please update your (build-)dependencies.


Cheers,

Andreas

Bug#916572: mauve-aligner: (build-)depends on obsolete icedtea-netx-common

[Andreas Beckmann]

Package: mauve-aligner
Version: 2.4.0+4736-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid due to the dependency on icedtea-netx-common.

The icedtea-netx-common package is gone, the former contents have been
merged into icedtea-netx. Please update your (build-)dependencies.


Cheers,

Andreas

Bug#916571: jmol: (build-)depends on obsolete icedtea-netx-common

[Andreas Beckmann]

Package: jmol
Version: 14.6.4+2016.11.05+dfsg1-3.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid due to the dependency on icedtea-netx-common.

The icedtea-netx-common package is gone, the former contents have been
merged into icedtea-netx. Please update your (build-)dependencies.


Cheers,

Andreas

Bug#916570: jaligner: build-depends on cruft icedtea-netx-common

[Andreas Beckmann]

Source: jaligner
Version: 1.0+dfsg-5
Severity: serious
Justification: fails to build from source

Hi,

The icedtea-netx-common package is gone, the former contents have been
merged into icedtea-netx. Please update your (build-)dependencies.


Cheers,

Andreas

Bug#858974: Closing old bug

[Pirate Praveen]

This is not an issue now.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#916569: geogebra: (build-)depends on obsolete icedtea-netx-common

[Andreas Beckmann]

Package: geogebra
Version: 4.0.34.0+dfsg1-6
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid due to the dependency on icedtea-netx-common.

The icedtea-netx-common package is gone, the former contents have been
merged into icedtea-netx. Please update your (build-)dependencies.


Cheers,

Andreas

Bug#916568: libbiojava4.0-java: depends on obsolete icedtea-netx-common

[Andreas Beckmann]

Package: libbiojava4.0-java
Version: 4.2.11+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

The icedtea-netx-common package is gone, the former contents have
been merged into icedtea-netx. Please update your dependencies.


Cheers,

Andreas

Bug#866653: RFS: thawab 4.1-1 [UPDATE]

[Ahmed El-Mahmoudy]

On Thu, Nov 29, 2018 at 04:46:10AM -0500, Jeremy Bicha wrote:
> Is the new license finished? I'm curious what it says.
---end quoted text---

Sorry for the late reply.
The Arabic (which is the authoritative) version is done:
https://github.com/ojuba-org/waqf/2.0/AR

I am almost done with the english translation:
https://github.com/ojuba-org/waqf/2.0/EN
but I am not sure my efforts in translation are precise from legal point 
of view.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#916034: sl-modem-dkms: module FTBFS for 4.18.0-3-amd64, 4.9.0-8-amd64

[أحمد المحمودي]

On Wed, Dec 12, 2018 at 01:56:11PM +0100, Andreas Beckmann wrote:
> linux-headers-4.18.0-3-amd64 is installed, but maybe it has changed its
> layout?

This shoul pull linux-headers-4.18.0-3-common which contains the 
header files that are reported missing.

> You you get the compile flags from Kbuild, or do you reinvent them on
> your own?

As far as I recall, they are from kbuild

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#916567: golang-github-juju-testing-dev: depends on the removed golang-github-juju-utils-dev

[Andreas Beckmann]

Package: golang-github-juju-testing-dev
Version: 0.0~git20170608.2fe0e88-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

The following packages have unmet dependencies:
 golang-github-juju-testing-dev : Depends: golang-github-juju-utils-dev but it 
is not installable

golang-github-juju-utils-dev was recently removed from sid.


Cheers,

Andreas

Bug#821111: nginx: Failure to remove socket due to Debian's method of stopping

[James Renken]

This bug is still present for me in version 1.14.1-1~bpo9+1.

Bug#916566: dansguardian: logrotate exits with error after package removal

[Andreas Beckmann]

Package: dansguardian
Version: 2.10.1.1-5.1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package's logrotate
configuration causes logrotate to exit with an error after the package
has been removed (*) or when logrote is run but no logfile exists.

Usually the solution is to specify 'missingok' in the logrotate
configuration.

*) logrotate configuration files remain installed and executed after a
package has been removed, they only get removed when the package is
purged.

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

0m38.7s ERROR: Command failed (status=1): ['chroot', 
'/srv/piuparts/tmp/tmplN4r2K', '/usr/sbin/logrotate', 
'/etc/logrotate.d/dansguardian']
  error: stat of /var/log/dansguardian failed: No such file or directory


cheers,

Andreas


dansguardian_2.10.1.1-5.1+b4.log.gz
Description: application/gzip

Bug#916565: libopenmpi3,openmpi-{common,doc}: fails to remove: post-removal script subprocess returned error exit status 1

[Andreas Beckmann]

Followup-For: Bug #916565

While testing the mpqc-openmpi package, there was some more error output:

  Removing libopenmpi3:amd64 (3.1.3-5) ...
  rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such 
file or directory
  rm: cannot remove 'End': No such file or directory
  rm: cannot remove 'automatically': No such file or directory
  rm: cannot remove 'added': No such file or directory
  rm: cannot remove 'section': No such file or directory
  dpkg: error processing package libopenmpi3:amd64 (--remove):
   installed libopenmpi3:amd64 package post-removal script subprocess returned 
error exit status 1

  Removing openmpi-common (3.1.3-5) ...
  rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such 
file or directory
  rm: cannot remove 'End': No such file or directory
  rm: cannot remove 'automatically': No such file or directory
  rm: cannot remove 'added': No such file or directory
  rm: cannot remove 'section': No such file or directory
  dpkg: error processing package openmpi-common (--remove):
   installed openmpi-common package post-removal script subprocess returned 
error exit status 1


Andreas

Bug#916565: libopenmpi3,openmpi-{common,doc}: fails to remove: post-removal script subprocess returned error exit status 1

[Andreas Beckmann]

Package: libopenmpi3,openmpi-common,openmpi-doc
Version: 3.1.3-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to remove.

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

  Removing libopenmpi3:amd64 (3.1.3-5) ...
  dpkg: error processing package libopenmpi3:amd64 (--remove):
   installed libopenmpi3:amd64 package post-removal script subprocess returned 
error exit status 1

  Removing openmpi-common (3.1.3-5) ...
  dpkg: error processing package openmpi-common (--remove):
   installed openmpi-common package post-removal script subprocess returned 
error exit status 1

  Removing openmpi-doc (3.1.3-5) ...
  dpkg: error processing package openmpi-doc (--remove):
   installed openmpi-doc package post-removal script subprocess returned error 
exit status 1


cheers,

Andreas


libopenmpi3_3.1.3-5.log.gz
Description: application/gzip

Bug#791814: sasl2-bin: fails to start saslauthd

[Roberto C . Sánchez]

package sasl2-bin
tag 791814 + moreinfo unreproducible
thanks

On Thu, Jul 09, 2015 at 01:42:37AM +0900, yamasita wrote:
> 
>* What led up to the situation?
> 
> I was if it was normal installation.
> (apt-get install sasal2-bin)
> It failed to start.
> service saslauthd start
> or
> /etc/init.d/saslauthd start
> or
> systemctl start saslauthd.service
> 
>* What exactly did you do (or not do) that was effective (or ineffective)?
> 
> I was editing the /etc/default/saslauthd.
> It was changed to "START=yes".
> 
>* What was the outcome of this action?
> 
> saslauthd did not start.
> 
>* What outcome did you expect instead?
> 
> saslauthd is wanted to start.
> 

I have attempted to reproduce this in a stretch Docker.  After starting
the container, I ran 'apt-get update && apt-get install -y sasl2-bin'.

After that, this is the result:

root@9fb09a55b38d:~# /etc/init.d/saslauthd status
[FAIL] Checking SASL Authentication Daemon: saslauthd (not running) failed!
root@9fb09a55b38d:~# /etc/init.d/saslauthd start
[warn] To enable saslauthd, edit /etc/default/saslauthd and set START=yes ... 
(warning).
root@9fb09a55b38d:~# sed -i 's/START=no/START=yes/' /etc/default/saslauthd
root@9fb09a55b38d:~# /etc/init.d/saslauthd start
[ ok ] Starting SASL Authentication Daemon: saslauthd.

Here is the same sequence in an unstable Docker:

root@1b23b77be2b2:~# /etc/init.d/saslauthd status
[FAIL] Checking SASL Authentication Daemon: saslauthd (not running) failed!
root@1b23b77be2b2:~# /etc/init.d/saslauthd start
[warn] To enable saslauthd, edit /etc/default/saslauthd and set START=yes ... 
(warning).
root@1b23b77be2b2:~# sed -i 's/START=no/START=yes/' /etc/default/saslauthd
root@1b23b77be2b2:~# /etc/init.d/saslauthd start
[ ok ] Starting SASL Authentication Daemon: saslauthd.


Can you try again to see if you can reproduce this problem.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

Bug#916564: python-pyte: new upstream version: 0.8.0

[Robbie Harwood]

Package: python3-pyte
Version: 0.4.8-1
Severity: normal

Dear Maintainer,

Currently pyte is on version 0.4.8 - which was released in January of 2014.
Please update to something newer, like the 0.8.0 that was released in April of
this year.

Thanks,
--Robbie

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (600, 'testing-debug'), (600, 'testing'), (400, 
'unstable-debug'), (400, 'unstable'), (200, 'experimental-debug'), (200, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python3-pyte depends on:
ii  python3  3.6.7-1

python3-pyte recommends no packages.

Versions of packages python3-pyte suggests:
pn  python-pyte-doc  

-- no debconf information

Bug#913377: python-louvain: FTBFS (No module named 'networkx')

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Build-depend on python3-networkx to fix FTBFS.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-louvain-0.0+20181013git3fc1f575/debian/control 
python-louvain-0.0+20181013git3fc1f575/debian/control
--- python-louvain-0.0+20181013git3fc1f575/debian/control   2018-10-15 
15:12:11.0 -0400
+++ python-louvain-0.0+20181013git3fc1f575/debian/control   2018-12-15 
23:00:43.0 -0500
@@ -5,7 +5,7 @@
 Build-Depends: debhelper (>= 11),
  dh-python,
  python3-all, python3-setuptools,
- python3-nose
+ python3-nose, python3-networkx
 Standards-Version: 4.2.1
 Homepage: https://github.com/taynaud/python-louvain
 Vcs-Browser: https://salsa.debian.org/debian/python-louvain

Bug#916563: UnDinaruLight.ttf says "it's UnDinaru-Bold" (of course, wrong)

[Hideki Yamane]

package: fonts-unfonts-core
severity: wishlist

Hi,

 UnDinaruLight.ttf says "it's UnDinaru-Bold" (of course, wrong).

$ otfinfo UnDinaruBold.ttf
UnDinaru-Bold
$ otfinfo UnDinaruLight.ttf
UnDinaru-Bold


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#914410: ruby-validate-url FTBFS: test failure

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Build-depend on ruby-activerecord to fix FTBFS.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ruby-validate-url-1.0.2+git/debian/control 
ruby-validate-url-1.0.2+git/debian/control
--- ruby-validate-url-1.0.2+git/debian/control  2018-11-22 06:50:13.0 
-0500
+++ ruby-validate-url-1.0.2+git/debian/control  2018-12-15 21:53:53.0 
-0500
@@ -6,6 +6,7 @@
 Build-Depends: debhelper (>= 9~),
gem2deb,
ruby-activemodel,
+   ruby-activerecord,
ruby-addressable,
ruby-diff-lcs,
ruby-rspec,

Bug#914358: schroedinger-maeparser: FTBFS (cmake: not found)

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Build-depend on cmake, libboost-dev and libboost-test-dev to fix FTBFS.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru schroedinger-maeparser-1.0.1/debian/control 
schroedinger-maeparser-1.0.1/debian/control
--- schroedinger-maeparser-1.0.1/debian/control 2018-12-06 09:00:18.0 
-0500
+++ schroedinger-maeparser-1.0.1/debian/control 2018-12-15 17:26:12.0 
-0500
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Debian Science Team 

 Uploaders: Steffen Moeller 
-Build-Depends: debhelper (>= 11)
+Build-Depends: debhelper (>= 11), cmake, libboost-dev, libboost-test-dev
 Standards-Version: 4.2.1
 Section: libs
 Homepage: https://www.schrodinger.com/maestro
@@ -39,4 +39,4 @@
   * Ligand-based search applications, such as Phase and Phase Shape
   * Quantum Mechanics applications, such as Jaguar
   * Protein-Protein Docking applications
-  * ... many other backends used in both Life and Material Sciences
\ No newline at end of file
+  * ... many other backends used in both Life and Material Sciences

Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201

[Ben Hutchings]

On Sat, 2018-12-15 at 23:59 +0100, Sebastian Andrzej Siewior wrote:
> On 2018-12-15 22:21:52 [+0100], Cyril Brulebois wrote:
> > regular bugfixes; we seem to have missed this regression on gen4/gen5,
> > so I've started checking whether the upstream fix was being queued for
> > linux-4.18.y, and moved to trying to get a work around once I've noticed
> 
> that bug is a bummer. I reverted that one patch myself for my needs. v4.18
> isn't maintained anymore so I'm unsure if this gets fixed in the stable tree.
> Debian wise I *think* they will move to v4.19 soon.

That's correct - the next upload to unstable will be based on 4.19.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.




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

Bug#915187: netfilter-persistent: Updating netfilter-persistent results in error

[gustavo panizzo]

Hello

On Mon, Dec 10, 2018 at 06:46:11PM +0100, Nico Haase wrote:

Hi there,
I wanted to check if there are some news. Through removing the saved 
rules files, the update has succeeded. But still, I think that this is 
not solved: after the update went through, I've tried to dump the 
rules through the following command:


ip6tables-save > /etc/iptables/rules.v6

This created the following dump:

# Generated by xtables-save v1.8.2 on Mon Dec 10 18:40:39 2018
*filter
:OUTPUT ACCEPT [64:15232]
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [64:15232]
COMMIT
# Completed on Mon Dec 10 18:40:39 2018

Afterwards, I tried to restore the rules that I've just dumped, and 
that threw the same message as before:


ip6tables-restore v1.8.2 (nf_tables):
line 3: CHAIN_UPDATE failed (No such file or directory): chain OUTPUT
line 4: CHAIN_UPDATE failed (No such file or directory): chain FORWARD
line 5: CHAIN_UPDATE failed (No such file or directory): chain INPUT

I understand that there might be some things that could work in 
another way due to a legacy version, but still: how could saving the 
rules with the current version result in a file that the current 
version cannot parse?



Is not a parsing problem, the CHAINs do not exists.
You need to check your setup. Check where the ip6*tables* symlinks
points to and make it consistent.

Also remove the legacy rules before applying new rules.

if ip{,6}tables-save and ip{,6}tables-restore dont work in your system,
netfilter-persistent won't work either (is just a wrapper around them to
start the firewall at boot time)


--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Bug#916561: ripit: Need to be updated to work with current libwebservice-musicbrainz-perl for --md to work

[Elimar Riesebieter]

Hi Petter,

* Petter Reinholdtsen  [2018-12-16 00:26 +0100]:

> Package: ripit
> Version: 4.0.0~beta20140508-1
> 
> The current ripit code fail to work with --md because the code in
> question require an older version of libwebservice-musicbrainz-perl than
> the one in testing at the moment.
> 
> The current ripit code expect WebService::MusicBrainz::Release to exist,
> and it is no longer provided by the WebService::MusicBrainz library from
> libwebservice-musicbrainz-perl version 1.0.4-2.  This code then fail:

I found http://www.ripit.pl/ but don't rely really on it.
http://www.suwald.com/ ==> upstream is dead and I don't got any
announcement from Felix Suwald. If there is fork or a take over I
need to know where to find it...

Elimar
-- 
  Experience is something you don't get until
  just after you need it!


signature.asc
Description: PGP signature

Bug#833608: unfix 833608

[Matt Kraai]

unarchive 833608
notfixed 833608 2.5.90
thanks

Hi,

I don't think this bug is fixed.  If I apply the following patch to
the test case, which seems to match the original report, it generates
the following error:

```  running tests   mkdir -p "/tmp/lintian/debian/test-out"
t/runtests -k t "/tmp/lintian/debian/test-out" version-substvars
ENV[PATH]=/home/kraai/.cargo/bin:/home/kraai/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
S tests::version-substvars-general: diff -u
/tmp/lintian/t/tests/version-substvars-general/tags
/tmp/lintian/debian/test-out/tests/version-substvars-general/tags.version-substvars-general
--- /tmp/lintian/t/tests/version-substvars-general/tags 2018-12-15
16:38:52.579289278 -0800 +++
/tmp/lintian/debian/test-out/tests/version-substvars-general/tags.version-substvars-general
2018-12-15 16:41:52.185728852 -0800 @@ -4,4 +4,5 @@
 E: version-substvars-general source: not-binnmuable-any-depends-any 
program-utils -> program-bin
 E: version-substvars-general source: version-substvar-for-external-package 
program-data -> foreign-pkg
 E: version-substvars-general source: version-substvar-for-external-package 
program-data -> other-foreign-pkg
+E: version-substvars-general source: version-substvar-for-external-package 
program-data -> provided-package
 X: version-substvars-general source: maybe-not-arch-all-binnmuable program-bin 
-> program-data-extra
fail tests::version-substvars-general: output differs!

Skipped/disabled tests:
  [tests]
version-substvars-obsolete: Unmet test dependencies: dpkg (<< 1.17.2)

Failed tests (1)
tests::version-substvars-general
make: *** [debian/rules:51: runtests] Error 1
```

-- 
Matt

diff --git a/t/tests/version-substvars-general/debian/control.in 
b/t/tests/version-substvars-general/debian/control.in
index eff741f68..5baf439cd 100644
--- a/t/tests/version-substvars-general/debian/control.in
+++ b/t/tests/version-substvars-general/debian/control.in
@@ -11,7 +11,7 @@ Architecture: any
 Depends: $\{shlibs:Depends\}, $\{misc:Depends\},
  program-data (= $\{binary:Version\}),
  program-data-extra (= $\{source:Version\})
-Provides: provided-package
+Provides: provided-package (= $\{binary:Version\})
 Description: {$description}
  This is a test package designed to exercise some feature or tag of
  Lintian.  It is part of the Lintian test suite and may do very odd

Bug#781895: avrdude: writing fuse from file does not work

[Milan Kupcevic]

> Package: avrdude
> Version: 6.1-2
> Severity: normal
> 
> Before I noticed the "m" format to set fuses from immediate
> commandline values, I tried to set them (using an Arduino-as-ISP) from
> a binary file obtained by reading them (-U hfuse:r:hfuse.dump:b).
> Using "-U hfuse:w:hfuse.dump:b" just fails:
> 
> $ avrdude -p m32u4 -c stk500v1 -b 19200 -P 
> /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Uno_6493534323335151A211-if00
>  -U hfuse:w:hfuse.dump:b


Please file a bug report at:

http://savannah.nongnu.org/bugs/?func=additem=avrdude

and work with the upstream on the issue.


Milan

Bug#916562: libc6: fputs(), fputc(), and fwrite() do not fail on write error

[Asher Gordon]

On Saturday, December 15, 2018 7:02 PM, Samuel Thibault  
wrote:

> Hello,
>
> Asher Gordon, le sam. 15 déc. 2018 18:51:19 -0500, a ecrit:
>
> > If I use fputs(3), fputc(3), or fwrite(3) to write to a file that can
> > be opened for writing but cannot be written to (e.g /dev/full), the
> > functions return 1 rather than the expected EOF (or 0 in the case of
> > fread()).
>
> Well, that is not surprising since these functions are buffered. You
> need to call fflush() to make sure that no error happened on the actual
> underlying write.
>
> Samuel

You're right. I tried it with fflush() and it gave expected results. I guess we 
can close this bug now.

Bug#916562: libc6: fputs(), fputc(), and fwrite() do not fail on write error

[Samuel Thibault]

Hello,

Asher Gordon, le sam. 15 déc. 2018 18:51:19 -0500, a ecrit:
> If I use fputs(3), fputc(3), or fwrite(3) to write to a file that can
> be opened for writing but cannot be written to (e.g /dev/full), the
> functions return 1 rather than the expected EOF (or 0 in the case of
> fread()).

Well, that is not surprising since these functions are buffered. You
need to call fflush() to make sure that no error happened on the actual
underlying write.

Samuel

Bug#916562: libc6: fputs(), fputc(), and fwrite() do not fail on write error

[Asher Gordon]

Package: libc6
Version: 2.27-8
Severity: normal
Tags: upstream

Dear Maintainer,

If I use fputs(3), fputc(3), or fwrite(3) to write to a file that can
be opened for writing but cannot be written to (e.g /dev/full), the
functions return 1 rather than the expected EOF (or 0 in the case of
fread()). On the other hand, write(2) returns -1 and sets errno to
ENOSPC an expected.

Expected results:
The functions fputs() and fputc() should return EOF and fwrite()
should return 0. All the functions should set errno to ENOSPC (for
/dev/full).

Actual results:
The functions return 1 (an indication of success) and leave errno
unchanged.

Steps to reproduce:
Compile the attached program (the compiler flag `-fno-builtin' does
not change anything, nor does -O0):
$ gcc -o write write.c

Run the program with /dev/full as the output file:
$ ./write hello /dev/full
fputs() returned 1 and errno is 0 (Success).
fputc() returned 104 (h) and errno is 0 (Success).
fwrite() returned 5 (the length of "hello" is 5) and errno is 0 (Success).
write() returned -1 (the length of "hello" is 5) and errno is 28 (No space left 
on device).

The expected output is:
fputs() returned EOF (-1) and errno is 28 (No space left on device).
fputc() returned EOF (-1) and errno is 28 (No space left on device).
fwrite() returned 0 (the length of "hello" is 5) and errno is 28 (No space left 
on device).
write() returned -1 (the length of "hello" is 5) and errno is 28 (No space left 
on device).


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

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

Versions of packages libc6 depends on:
ii  libgcc1  1:8.2.0-9

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.69
pn  glibc-doc  
ii  libc-l10n  2.27-8
ii  locales2.27-8

-- debconf information:
* glibc/restart-services: cups cron
  glibc/kernel-too-old:
  glibc/kernel-not-supported:
  glibc/restart-failed:
  glibc/upgrade: true
  glibc/disable-screensaver:
* libraries/restart-without-asking: false
#include 
#include 
#include 
#include 

int main(int argc, char **argv) {
  int ret;
  size_t string_len;
  FILE *output_file;
  
  if (argc != 3) {
fprintf(stderr, "Usage: %s STRING FILE\nWrite STRING to FILE.\n", argv[0]);
return 1;
  }

  /* Open the file */
  if (!(output_file = fopen(argv[2], "w"))) {
fprintf(stderr, "%s: could not open %s: %m\n", argv[0], argv[2]);
return 1;
  }

  /* Now try to write to the file using fputs() */
  errno = 0;
  ret = fputs(argv[1], output_file);
  /* `ret' should be EOF if an error occured (see fputs(3)) */
  printf ("fputs() returned ");
  if (ret == EOF)
printf("EOF (%d)", ret);
  else
printf("%d", ret);
  printf(" and errno is %d (%m).\n", errno);

  /* This happens with fputc() too */
  errno = 0;
  ret = fputc(argv[1][0], output_file);
  printf("fputc() returned ");
  if (ret == EOF)
printf("EOF (%d)", ret);
  else
printf("%d (%c)", ret, (char)ret);
  printf(" and errno is %d (%m).\n", errno);

  string_len = strlen(argv[1]);

  /* This happens with fwrite() too */
  errno = 0;
  printf("fwrite() returned %lu (the length of \"%s\" is %lu) ",
 fwrite(argv[1], 1, string_len, output_file), argv[1], string_len);
  printf("and errno is %d (%m).\n", errno);

  /* write() gives us expected results */
  errno = 0;
  printf("write() returned %ld (the length of \"%s\" is %lu) ",
 write(fileno(output_file), argv[1], string_len), argv[1], string_len);
  printf("and errno is %d (%m).\n", errno);

  return 0;
}

Bug#916561: ripit: Need to be updated to work with current libwebservice-musicbrainz-perl for --md to work

[Petter Reinholdtsen]

Package: ripit
Version: 4.0.0~beta20140508-1

The current ripit code fail to work with --md because the code in
question require an older version of libwebservice-musicbrainz-perl than
the one in testing at the moment.

The current ripit code expect WebService::MusicBrainz::Release to exist,
and it is no longer provided by the WebService::MusicBrainz library from
libwebservice-musicbrainz-perl version 1.0.4-2.  This code then fail:

   eval { require WebService::MusicBrainz::Release } if($mb == 1);

-- 
Happy hacking
Petter Reinholdtsen

Bug#878504: libmp3-tag-perl: MP3/Tag.pm line 2611 produces a deprecated warning

[Petter Reinholdtsen]

[E Harris 2017-10-14]
> When using MP::Tag, the current version of perl shipped with Debian stretch
> produces a deprecation warning about a regex in Tag.pm:
> 
> Unescaped left brace in regex is deprecated, passed through in regex; marked 
> by <-- HERE in m/(\\%(?:\\=)?(\w|\\{ <-- HERE 
> (?:\w|\\[^\w\\{}]|\\[\\{}])*\\}|\\\W))/ at /usr/share/perl5/MP3/Tag.pm 
> line 2611.

I see this too when using ripit with the --mb option.

Any hope to have the code fixed in time for Buster?
-- 
Happy hacking
Petter Reinholdtsen

Bug#915537: MongoDB SSPL v1 license and the DFSG

[Chris Lamb]

Adrian Bunk wrote:

> Please elaborate what is the relevant difference that makes the AGPL 
> DFSG-free but SSPL v1 not.

I understand the motivation behind this request but as this has been
somewhat discussed ad-nauseum elsewhere on the internet and I would
not wish to condescend Hideki, Apollon or yourself by repeating and
rehashing the arguments here yet again.

> This might also be useful input for upstream how to make their licence
> DFSG-compliant

I would agree that providing good feedback would be extremely helpful.
However, these conversations are happening elsewhere so I don't think
this bug report would be a good venue to provide that feedback to
Eliot and his counsel.


Regards,

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

Bug#301953: retry mostly works now

[Vincent McIntyre]

Version: 1:1.3.4-2.1

nfs-common version 1:1.3.4-2.1
kernel linux-image-4.9.0-8-amd64 4.9.130-2 

It takes a little longer than the advertised 60s.
It tries 10 times and gives up.

% /usr/bin/time -p sudo mount - -t nfs -o vers=3,retry=1 192.168.30.1:/blah 
/mnt
mount.nfs: timeout set for Sat Dec 15 21:04:10 2018
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
imount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: Connection timed out
Command exited with non-zero status 32
real 65.87
user 0.02
sys 0.04

Same for vers=2
% /usr/bin/time -p sudo mount - -t nfs -o vers=2,retry=1 192.168.30.1:/blah 
/mnt
mount.nfs: timeout set for Sat Dec 15 21:05:58 2018
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: Connection timed out
Command exited with non-zero status 32
real 65.77
user 0.02
sys 0.04


Setting retry=2 does indeed double the time to timeout.

% /usr/bin/time -p sudo mount - -t nfs -o vers=3,retry=2 192.168.30.1:/blah 
/mnt
mount.nfs: timeout set for Sat Dec 15 21:09:13 2018
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed 

Bug#916560: opensm: logrotate exits with error after package removal

[Andreas Beckmann]

Package: opensm
Version: 3.3.21-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package's logrotate 
configuration causes logrotate to exit with an error after the package 
has been removed (*) or when logrote is run but no logfile exists.

Usually the solution is to specify 'missingok' in the logrotate 
configuration.

*) logrotate configuration files remain installed and executed after a 
package has been removed, they only get removed when the package is 
purged.

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

0m26.0s ERROR: Command failed (status=1): ['chroot', 
'/srv/piuparts/tmp/tmpQ7ySyS', '/usr/sbin/logrotate', '/etc/logrotate.d/opensm']
  error: stat of /var/log/opensm*.log failed: No such file or directory


cheers,

Andreas


opensm_3.3.21-1.log.gz
Description: application/gzip

Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201

[Sebastian Andrzej Siewior]

On 2018-12-15 22:21:52 [+0100], Cyril Brulebois wrote:
> regular bugfixes; we seem to have missed this regression on gen4/gen5,
> so I've started checking whether the upstream fix was being queued for
> linux-4.18.y, and moved to trying to get a work around once I've noticed

that bug is a bummer. I reverted that one patch myself for my needs. v4.18
isn't maintained anymore so I'm unsure if this gets fixed in the stable tree.
Debian wise I *think* they will move to v4.19 soon.

> Cheers,

Sebastian

Bug#916484: closed by Thomas Goirand (Re: Bug#916484: python3-oslo.config has circular Depends on python3-oslo.log)

[Bill Allombert]

On Sat, Dec 15, 2018 at 10:42:03PM +, Debian Bug Tracking System wrote:
> Date: Sat, 15 Dec 2018 23:39:09 +0100
> From: Thomas Goirand 
> To: 916484-d...@bugs.debian.org
> Subject: Re: Bug#916484: python3-oslo.config has circular Depends on
>  python3-oslo.log
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
>  Thunderbird/60.3.0
> 
> On 12/14/18 11:07 PM, Bill Allombert wrote:
> > Package: python3-oslo.config
> > Version: 1:6.4.1-1
> > Severity: important
> > 
> > Hello Debian OpenStack,
> > 
> > There is a circular dependency between python3-oslo.config and 
> > python3-oslo.log:
> > 
> > python3-oslo.config :Depends: python3-oslo.log (>= 3.36.0)
> > python3-oslo.log:Depends: python3-oslo.config (>= 1:5.2.0)
> 
> There's unfortunately nothing I can do at my level. Upstream must take
> care of this.

So did you report it upstream ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#916559: python3-ow{,net}: fails to install: SyntaxError in File "/usr/lib/python3/dist-packages/ow/__init__.py", line 346

[Andreas Beckmann]

Package: python3-ow,python3-ownet
Version: 3.2p3+dfsg1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Setting up python3-ow (3.2p3+dfsg1-1) ...
File "/usr/lib/python3/dist-packages/ow/__init__.py", line 346
  raise AttributeError, name
  ^
  SyntaxError: invalid syntax
  
  dpkg: error processing package python3-ow (--configure):
   installed python3-ow package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.28-2) ...
  Errors were encountered while processing:
   python3-ow


  Setting up python3-ownet (3.2p3+dfsg1-1) ...
File "/usr/lib/python3/dist-packages/ownet/__init__.py", line 251
  raise AttributeError, name
  ^
  SyntaxError: invalid syntax
  
File "/usr/lib/python3/dist-packages/ownet/connection.py", line 227
  raise exInvalidMessage, msg
^
  SyntaxError: invalid syntax
  
  dpkg: error processing package python3-ownet (--configure):
   installed python3-ownet package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.28-2) ...
  Errors were encountered while processing:


cheers,

Andreas


python3-ow_3.2p3+dfsg1-1.log.gz
Description: application/gzip

Bug#909573: avrdude: Doesn't recognise ATtiny2313A

[Milan Kupcevic]

On 9/25/18 9:44 AM, Paul "LeoNerd" Evans wrote:
> Package: avrdude
> Version: 6.3-4+b1
> Severity: normal
> 
> The ATtiny2313A chip has the same programming details and signature as
> the ATtiny2313, but is not recognised by avrdude:
> 
>   $ avrdude -p attiny2313a ...
>   avrdude: AVR Part "attiny2313a" not found.
> 
> This can be easily remidied:
> 
>   part parent "t2313"
>   id   = "t2313a";
>   desc = "ATtiny2313A";
>   ;
> 
> This may not seem important, but I find it very useful that `avrdude -p`
> takes the same names for the chips as `avr-gcc -mmcu=`, and my Makefiles
> are built on this idea. It has worked up until the ATtiny2313A (whose
> libc header files I need to use as they contain some bugfixes and better
> names for registers, on an otherwise-identical chip).
> 
> Likewise while I'm here, the ATtiny84A has an identical problem,
> similarly fixed by
> 
>   part parent "t84"
>   id   = "t84a";
>   desc = "ATtiny84A";
>   ;
> 
> There are likely to be many more "A" variants that should be aliased
> like these.
> 



Please file a bug report at:

http://savannah.nongnu.org/bugs/?func=additem=avrdude

and work with the upstream on the issue.


Milan

Bug#916509: apt-listbugs: French po translation update

[Francesco Poli]

On Sat, 15 Dec 2018 10:53:51 +0300 Jean-Baka Domelevo Entfellner wrote:

[...]
> Please find attached the French PO templates update, proofread by the
> debian-l10n-french mailing list contributors.

Hello Jean-Baka,
thanks for sending the updated translation.

I will soon push the new .po file to the public git repository; it will
be included in the next upload.

> 
> Francesco: apologies for stepping over the deadline by a little bit.

That's OK, your contribution is appreciated.
Bye.

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


pgp56QUwczVLX.pgp
Description: PGP signature

Bug#916558: mosquitto: fails to install: chown: cannot access '/var/log/mosquitto/mosquitto.log': No such file or directory

[Andreas Beckmann]

Package: mosquitto
Version: 1.5.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Setting up mosquitto (1.5.5-1) ...
  chown: cannot access '/var/log/mosquitto/mosquitto.log': No such file or 
directory
  dpkg: error processing package mosquitto (--configure):
   installed mosquitto package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.28-2) ...
  Errors were encountered while processing:
   mosquitto


cheers,

Andreas


mosquitto_1.5.5-1.log.gz
Description: application/gzip

Bug#916557: usbrelay: FTBFS with ld --as-needed

[Logan Rosen]

Package: usbrelay
Version: 0.4-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

usbrelay currently fails to build from source with ld --as-needed, which
is enabled by default in Ubuntu. This linker option requires that
libraries be placed after the files that need them.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/ld-as-needed.patch: Add libraries to LIBS instead of LDFLAGS to fix
FTBFS with ld --as-needed.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru usbrelay-0.4/debian/patches/ld-as-needed.patch 
usbrelay-0.4/debian/patches/ld-as-needed.patch
--- usbrelay-0.4/debian/patches/ld-as-needed.patch  1969-12-31 
19:00:00.0 -0500
+++ usbrelay-0.4/debian/patches/ld-as-needed.patch  2018-12-15 
17:17:46.0 -0500
@@ -0,0 +1,16 @@
+--- a/Makefile
 b/Makefile
+@@ -1,11 +1,11 @@
+ CFLAGS += -O2 -Wall
+ HIDAPI = hidraw
+-LDFLAGS += -lhidapi-$(HIDAPI)
++LIBS += -lhidapi-$(HIDAPI)
+ 
+ all: usbrelay
+ 
+ usbrelay: usbrelay.c
+-  $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $<
++  $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBS)
+ 
+ clean:
+   rm -f usbrelay
diff -Nru usbrelay-0.4/debian/patches/series usbrelay-0.4/debian/patches/series
--- usbrelay-0.4/debian/patches/series  2018-10-21 11:21:09.0 -0400
+++ usbrelay-0.4/debian/patches/series  2018-12-15 17:17:16.0 -0500
@@ -1 +1,2 @@
 0001-make-CFLAGS-LDFLAGS-and-CPPFLAGS-customizable.patch
+ld-as-needed.patch

Bug#902228: ITP: ffcvt -- ffmpeg convert wrapper tool

[Tong Sun]

Starting again...

Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201

[Cyril Brulebois]

Hi Russel and others,

Russel Winder  (2018-11-29):
> It is also perhaps worth noting that whilst this new kernel reboots
> fine on a Lenovo X1, on the T500 and X201 rebooting just locks the
> laptops up requiring a forced power button shutdown.

There's a pending patch upstream (at least in drm-intel) for this bug:
  https://patchwork.freedesktop.org/patch/265653/

but it doesn't seem to apply cleanly on v4.18.20:
| Changes to be committed:
| 
|   modified:   drivers/gpu/drm/i915/i915_drv.h
|   modified:   drivers/gpu/drm/i915/i915_gpu_error.c
| 
| Unmerged paths:
|   (use "git add ..." to mark resolution)
| 
|   both modified:   drivers/gpu/drm/i915/i915_gem.c
|   both modified:   drivers/gpu/drm/i915/intel_engine_cs.c
|   both modified:   drivers/gpu/drm/i915/intel_lrc.c
|   both modified:   drivers/gpu/drm/i915/intel_ringbuffer.c
|   both modified:   drivers/gpu/drm/i915/intel_ringbuffer.h

with things like:
| diff --cc drivers/gpu/drm/i915/intel_ringbuffer.h
| index 010750e8ee44,72edaa7ff411..
| --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
| +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
| @@@ -415,7 -436,9 +415,13 @@@ struct intel_engine_cs 
|   
| struct intel_hw_status_page status_page;
| struct i915_ctx_workarounds wa_ctx;
| ++<<< HEAD
|  +  struct i915_vma *scratch;
| ++===
| +   struct i915_wa_list ctx_wa_list;
| +   struct i915_wa_list wa_list;
| +   struct i915_wa_list whitelist;
| ++>>> 517974992593... drm/i915: Allocate a common scratch page
|   
| u32 irq_keep_mask; /* always keep these interrupts */
| u32 irq_enable_mask; /* bitmask to enable ring interrupt 
*/

I might have missed it, but I wasn't able to spot this commit's
being advertised on stable@ anyway, at least by manually checking:
  https://www.spinics.net/lists/stable/

(hence Chris Wilson in copy.)

Since that doesn't look like things I can fix on my own, I took
inspiration from a bug reporter[1], trying to simply revert the
offending patch (which is said to be fixed by the commit message
of 5179749925933575a67f9d8f16d0cc204f98a29f[2]).

 1. https://bugs.freedesktop.org/show_bug.cgi?id=108984
 2. 
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next=5179749925933575a67f9d8f16d0cc204f98a29f

I'm attaching a patch against the sid branch of the debian packaging,
implementing this revert; and packages built from this updated sid
branch can be found in this repository (also available over https://):

  deb http://apt.debamax.com/bug-914980/ sid main

This repository is signed with my work key (itself signed by my Debian
key), to make it clear it's an independent effort at trying to get this
bug worked around for the time being, rather than something official
from the debian-kernel team. In any case, this repository will only be
kept online while this issue isn't fixed in unstable.

Test reports welcome!


For context, Tails usually tracks the Linux kernel from sid to get
regular bugfixes; we seem to have missed this regression on gen4/gen5,
so I've started checking whether the upstream fix was being queued for
linux-4.18.y, and moved to trying to get a work around once I've noticed
that wasn't the case yet. We might end up temporarily downgrading the
kernel in Tails instead, though.

  https://redmine.tails.boum.org/code/issues/16224


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
commit 6b1dd9475806fa55283f9e934b2bec5fbc6e60af
Author: Cyril Brulebois 
Date:   Sat Dec 15 16:47:55 2018 +0100

Fix gen4/gen5 regression from 4.18.19 by reverting this upstream commit (Closes: #914980):

- drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5

diff --git a/debian/changelog b/debian/changelog
index b3b84dda0311..095551bac297 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,13 @@
 linux (4.18.20-3) UNRELEASED; urgency=medium
 
+  [ Vagrant Cascadian ]
   * debian/config/config: Enable Z3FOLD as a module.
 
+  [ Cyril Brulebois ]
+  * Fix gen4/gen5 regression from 4.18.19 by reverting this upstream
+commit (Closes: #914980):
+- drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5
+
  -- Vagrant Cascadian   Sun, 25 Nov 2018 20:31:40 -0800
 
 linux (4.18.20-2) unstable; urgency=medium
diff --git a/debian/patches/bugfix/all/Revert-drm-i915-ringbuffer-Delay-after-EMIT_INVALIDA.patch b/debian/patches/bugfix/all/Revert-drm-i915-ringbuffer-Delay-after-EMIT_INVALIDA.patch
new file mode 100644
index ..1c6e111381d8
--- /dev/null
+++ b/debian/patches/bugfix/all/Revert-drm-i915-ringbuffer-Delay-after-EMIT_INVALIDA.patch
@@ -0,0 +1,104 @@
+From 8d4bf1ce648ab1b16eca14baf778cc39756afbeb Mon Sep 17 00:00:00 2001
+From: Cyril Brulebois 
+Date: Sat, 15 Dec 2018 16:34:38 +0100
+Subject: [PATCH] Revert "drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for
+ gen4/gen5"
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8

Bug#909550: possible conflict over the /usr/bin/ia namespace

[Chris Lamb]

Antoine Beaupré wrote:

> >From what I can tell, both were:
> 
> https://tracker.debian.org/news/989684/accepted-python-duckduckgo2-0242git20151019-2-source-amd64-into-unstable/

Neat, thanks. I've just processed python-internetarchive 1.8.1-1 in
NEW.


Regards,

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

Bug#916499: autopkgtest: Something™ in autopkgtest 5.7 breaks something™ in at least libhtml-formfu-perl's autopkgtests

[gregor herrmann]

On Sat, 15 Dec 2018 21:53:54 +0200, Niko Tyni wrote:

> > autopkgtest [03:29:08]: ERROR: "chmod -R go+rwX -- 
> > /tmp/autopkgtest.ES3bLl/autopkgtest-satdep.deb" failed with stderr 
> > "/bin/chmod: cannot access 
> > '/tmp/autopkgtest.ES3bLl/autopkgtest-satdep.deb': No such file or directory
> 
> I see this with both autopkgtest 5.6 and 5.7 on libhtml-formfu-perl
> 2.06000-2 from the archive.

Just for the records:
I had the same error today once, with 5.6, and a different package
(libtext-markup-perl).
 
Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Ludwig Hirsch: Grüß Gott, Salzburg


signature.asc
Description: Digital Signature

Bug#916365: apt-listbugs: [INTL:nl] Dutch po file for the apt-listbugs package

[Francesco Poli]

On Sat, 15 Dec 2018 01:01:39 +0100 Frans Spiesschaert wrote:

[...]
> Francesco Poli schreef op vr 14-12-2018 om 21:43 [+0100]:
[...]
> > Out of curiosity, why so many changes with respect to the previous
> > update (sent back on June 2018)?
[...]
>
> It's indeed about Dutch l10n style guidelines. We try to be in line
> with the Dutch translation team at translationproject.org where most of
> GNU software translation is taken care of. As a guideline they use the
> infinitive for the translation of man pages and commands. I noticed
> that the old translation of apt-listbugs was using the imperative
> instead, so I switched to the infinitive. That explains why the
> translation got altered that much.

Ah, interesting: that explains everything.
Thanks for your reply!

Bye.


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


pgp5haaGZoRXx.pgp
Description: PGP signature

Bug#916552: Anyone interested to work on AMDVLK?

[Alexandre Viau]

Hello!

I have created an RFP bug requesting for AMDVLK, AMD's open source
driver for Vulkan. (#916552)

AMDVLK shares code with AMD's Windows drivers so it allows AMD to join
efforts with the other platforms that they maintain. It also gets
day-one support for new cards as AMD developers have access to the cards
in advance so they are able to prepare patches before release.

It would be great to have AMDVLK in Debian, it would bring true first
class support for AMD cards (we already have very good support with Mesa!).

If there are people interested in working on this, I would like to help.
That would be my first contribution to the X team so I would prefer that
somebody work on this with me but I intend to do it myself if there are
no interest from the team.

For a quick explanation of AMD's current Linux graphics stack, this
FOSDEM talk is a good reference:
 - https://archive.fosdem.org/2018/schedule/event/amd_graphics/

CC-ing the RFP so that we can gather all discussions about this in one
place.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#916556: qtbase-opensource-src: Upstream no longer uses name "qtbase-opensource-src" since 5.10

[Kai Pastor]

Source: qtbase-opensource-src
Severity: normal

Dear Maintainer,

I noticed that debian/copyright for the latest qtbase-opensource-src starts
with:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: qtbase-opensource-src
Source: https://download.qt.io/official_releases/qt/*/submodules/


However, since Qt 5.10, the upstream source tarballs are called qtbase-
everywhere-src-... (and similar for the other modules).
(There are qt-opensource-... binaries, but qtbase-opensource-src seems to no
longer be a "name upstream uses for the software".

In addition, while the given "Source" will work at the time of the release, the
"official release" is just a temporary place.
The permanent location is https://download.qt.io/archive/qt/*/submodules/

Regards,
Kai





-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#916555: RFP: llpc - LLVM-Based Pipeline Compiler

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: llpc
  Upstream Author : AMD
* URL : https://github.com/GPUOpen-Drivers/llpc
* License : Expat
  Programming Lang: C/C++
  Description : LLVM-Based Pipeline Compiler

This is needed for AMDVLK

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#916554: RFP: pal - Platform Abstraction Library

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: pal
  Upstream Author : AMD
* URL : https://github.com/GPUOpen-Drivers/pal
* License : Expat
  Programming Lang: C/C++
  Description :  hardware and OS abstractions for Radeon™ (GCN+)
user-mode 3D graphics drivers

This is needed for AMDVLK

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#916553: RFP: xgl - translates Vulkan API commands into PAL commands

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: amdvlk
  Upstream Author : AMD
* URL : https://github.com/GPUOpen-Drivers/xgl
* License : Expat
  Programming Lang: C/C++
  Description : AMD Open Source Driver For Vulkan

This is needed for AMDVLK

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#916552: RFP: AMDVLK: AMD Open Source Driver For Vulkan

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: amdvlk
  Version : 0.0~git20181212
  Upstream Author : AMD
* URL : https://github.com/GPUOpen-Drivers/AMDVLK
* License : Expat
  Programming Lang: C/C++
  Description : AMD Open Source Driver For Vulkan

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#916551: gnome-settings-daemon FTCBFS: meson refuses running gsd-power-enums-update

[Helmut Grohne]

Source: gnome-settings-daemon
Version: 3.30.1.2-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gnome-settings-daemon fails to cross build from source, because
gsd-power-enums-update cannot be run. The build system wants to run it,
but it is not marked as native. It's not installed anywhere, so marking
it native is feasible. The attached patch implements that and makes
gnome-settings-daemon cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru gnome-settings-daemon-3.30.1.2/debian/changelog 
gnome-settings-daemon-3.30.1.2/debian/changelog
--- gnome-settings-daemon-3.30.1.2/debian/changelog 2018-12-10 
17:42:34.0 +0100
+++ gnome-settings-daemon-3.30.1.2/debian/changelog 2018-12-15 
19:10:49.0 +0100
@@ -1,3 +1,10 @@
+gnome-settings-daemon (3.30.1.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: gsd-power-enums-update should be native.
++ It therefore needs libglib2.0-dev:native.
+
+ -- Helmut Grohne   Sat, 15 Dec 2018 19:10:49 +0100
+
 gnome-settings-daemon (3.30.1.2-2) unstable; urgency=medium
 
   [ Iain Lane ]
diff --minimal -Nru gnome-settings-daemon-3.30.1.2/debian/control 
gnome-settings-daemon-3.30.1.2/debian/control
--- gnome-settings-daemon-3.30.1.2/debian/control   2018-12-10 
17:42:34.0 +0100
+++ gnome-settings-daemon-3.30.1.2/debian/control   2018-12-15 
19:10:31.0 +0100
@@ -21,6 +21,7 @@
libgeoclue-2-dev (>= 2.3.1),
libgeocode-glib-dev (>= 3.10.0),
libglib2.0-dev (>= 2.53.0),
+   libglib2.0-dev:native (>= 2.53.0),
libgnome-desktop-3-dev (>= 3.11.1),
libgtk-3-dev (>= 3.16),
libgudev-1.0-dev [linux-any],
diff --minimal -Nru gnome-settings-daemon-3.30.1.2/debian/patches/cross.patch 
gnome-settings-daemon-3.30.1.2/debian/patches/cross.patch
--- gnome-settings-daemon-3.30.1.2/debian/patches/cross.patch   1970-01-01 
01:00:00.0 +0100
+++ gnome-settings-daemon-3.30.1.2/debian/patches/cross.patch   2018-12-15 
19:10:49.0 +0100
@@ -0,0 +1,14 @@
+--- gnome-settings-daemon-3.30.1.2.orig/plugins/power/meson.build
 gnome-settings-daemon-3.30.1.2/plugins/power/meson.build
+@@ -54,9 +54,8 @@
+ gsd_power_enums_update = executable(
+   'gsd-power-enums-update',
+   sources,
+-  include_directories: top_inc,
+-  dependencies: deps,
+-  c_args: cflags
++  dependencies: [dependency('gobject-2.0', native: true)],
++  native: true
+ )
+ 
+ if enable_gudev
diff --minimal -Nru gnome-settings-daemon-3.30.1.2/debian/patches/series 
gnome-settings-daemon-3.30.1.2/debian/patches/series
--- gnome-settings-daemon-3.30.1.2/debian/patches/series1970-01-01 
01:00:00.0 +0100
+++ gnome-settings-daemon-3.30.1.2/debian/patches/series2018-12-15 
19:10:43.0 +0100
@@ -0,0 +1 @@
+cross.patch

Bug#916499: autopkgtest: Something™ in autopkgtest 5.7 breaks something™ in at least libhtml-formfu-perl's autopkgtests

[Niko Tyni]

On Sat, Dec 15, 2018 at 03:52:58AM +0100, gregor herrmann wrote:
> Package: autopkgtest
> Version: 5.7
> Severity: normal

> autopkgtest [03:29:08]: ERROR: "chmod -R go+rwX -- 
> /tmp/autopkgtest.ES3bLl/autopkgtest-satdep.deb" failed with stderr 
> "/bin/chmod: cannot access '/tmp/autopkgtest.ES3bLl/autopkgtest-satdep.deb': 
> No such file or directory

I see this with both autopkgtest 5.6 and 5.7 on libhtml-formfu-perl
2.06000-2 from the archive.

It looks to me like a race where the TempPath destructor for
autopkgtest-satdep.deb gets run after the next test has created a new
TempPath object for the same filename.

It's not clear to me at all why the destructor gets run in the middle
of Testbed.copydown(). Maybe a change in Python 3.7 garbage collecting
or something like that?
-- 
Niko

Bug#909465:

[Andreas Hasenack]

Same here, samba 4.9.x is blocked in Ubuntu until this is resolved, one way
or another.

Bug#916550: ITP: trollimage -- Pytroll imaging library

[Antonio Valentino]

Package: wnpp
Severity: wishlist
Owner: Antonio Valentino 

* Package name: trollimage
  Version : 1.5.7
  Upstream Author : Martin Raspaud 
* URL : https://github.com/pytroll/trollimage
* License :   Programming Lang: Python
  Description : Pytroll imaging library

Binary package names: python-trollimage

Bug#916549: cl-rss: compilation error after issuing the command (require 'rss) in slime

[Antoine Finch]

Package: cl-rss
Version: 0.9.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

 running slime in emacs, issuing "(require 'rss)" in slime.

   * What was the outcome of this action?
 
 ASDF could not load rss because COMPILE-FILE-ERROR while compiling
 #4.10
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages cl-rss depends on:
ii  cl-aserve   1.2.42+cvs.2010.02.08-dfsg-2
ii  cl-kmrcl1.109-1
ii  cl-ptester  20160829.gitfe69fde-1
ii  cl-xmls 1.7.1-2

cl-rss recommends no packages.

cl-rss suggests no packages.

-- no debconf information

-- 


signature.asc
Description: PGP signature

Bug#915825: [G-I] installer completely broken for Gujarati, missing font --- temporary workaround

[Holger Wansing]

Hi,

following mail from Kartik says, the screenshot from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911705#55
are all fine, while Noto Serif Gujarati is the best:



== snip =
Date: Fri, 7 Dec 2018 19:30:56 +0530
From: Kartik Mistry 
To: hwans...@mailbox.org
Subject: Re: [debian-installer] Gujarati not usable, font broken or missing


On Fri, Dec 7, 2018 at 7:12 PM Holger Wansing  wrote:
> may I get your attention on bug #915825:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915825.

Hi,

Sorry for ignoring this long time and thanks a lot for your work on
this! I was suppose to reply this and then had to move home in hurry
:/

> As I wrote there, I cannot see any difference on the three fonts
> "Noto Sans Gujarati", "Noto Sans Gujarati UI" and "Noto Serif Gujarati" in
> those screenshots.
> Can you?
> If yes, which one is best?

You can go ahead with any of these. All seems working fine. However,
Noto Serif Gujarati seems the best.

Thanks again!

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
== snap ==




So, I sent a patch here, how to build an image with working Gujarati font.
It's only a workaround though, since the image size is increased massively
by this.

In case we want this solution to become permanent, Jonas volunteered to add
the needed font to fonts-noto-hinted-udeb (instead of the
fonts-noto-unhinted-udeb used in this patch).

Hint: fonts-noto-unhinted-udeb version 20181130-1 is needed for this patch
to work.


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/src/usr/bin/gtk-set-font b/src/usr/bin/gtk-set-font
index 9e7cd89..1631340 100644
--- a/src/usr/bin/gtk-set-font
+++ b/src/usr/bin/gtk-set-font
@@ -41,6 +41,10 @@ case "$language" in
 	FONT_NAME="Tibetan Machine Uni"
 	FONT_SIZE=$(($FONT_SIZE + 2))
 	;;
+gu)
+	FONT_NAME="Noto Serif Gujarati"
+	FONT_SIZE=$(($FONT_SIZE + 2))
+	;;
 ja)
 	FONT_NAME="VL Gothic"
 	;;
@@ -75,7 +79,7 @@ case "$language" in
 zh*)
 	FONT_NAME="AR PL ShanHeiSun Uni"
 	;;
-bn|gu|hi|ml|mr|ne)
+bn|hi|ml|mr|ne)
 	FONT_SIZE=$(($FONT_SIZE + 2))
 	;;
 esac
diff --git a/build/pkg-lists/gtk-common b/build/pkg-lists/gtk-common
index 69bfbc2e2..55f433962 100644
--- a/build/pkg-lists/gtk-common
+++ b/build/pkg-lists/gtk-common
@@ -21,6 +21,8 @@ fonts-telu-udeb
 fonts-sil-abyssinica-udeb
 # For Sinhala
 fonts-noto-hinted-udeb
+# Workaround for Gujarati
+fonts-noto-unhinted-udeb
 fonts-lao-udeb
 fonts-ukij-uyghur-udeb
 fonts-sil-padauk-udeb

Bug#916548: python3.7: Version constraint in pyzo breaks is too strict

[Adrian Bunk]

Package: python3.7
Version: 3.7.2~rc1-1
Severity: important

The following packages have unmet dependencies:
 python3.7 : Breaks: pyzo (< 4.6) but 4.4.3-1.1 is to be installed

The Breaks should be lowered to
  pyzo (<< 4.4.3-1.1~)

Bug#916431: fixed in ublock-origin 1.17.0+dfsg-3

[Markus Koschany]

FTR: I just came across

https://bugs.debian.org/827517

which points to

https://bugzilla.mozilla.org/show_bug.cgi?id=1286634

Apparently this issue is a Firefox bug which was marked as "wontfix".
Relative symlinks in Firefox extensions are not supported.

The proposed fix is to use absolute symlinks. I will try this when I
package the next upstream release of ublock-origin.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#916547: r-cran-knitr: autopkgtest regression: no package called 'rmarkdown'

[Paul Gevers]

Source: r-cran-knitr
Version: 1.21+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Control: affects -1 src:texlive-extra
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of r-cran-knitr the autopkgtest of r-cran-knitr
fails in testing when that autopkgtest is run with the binary packages
of r-cran-knitr from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
r-cran-knitr   from testing1.21+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
to testing [1] and on top of that, also the migration of texlive-extra.
Can you please investigate the situation and fix it? If needed, please
change the bug's severity.

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

Paul

[1] https://qa.debian.org/excuses.php?package=r-cran-knitr

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-knitr/1515163/log.gz

autopkgtest [09:23:20]: test run-unit-test: [---

R version 3.5.1 (2018-07-02) -- "Feather Spray"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(testit)
> test_pkg("knitr")
Error from tryCatchList(expr, classes, parentenv, handlers)
Error in loadNamespace(name) : there is no package called 'rmarkdown'
Calls: test_pkg ... tryCatch -> tryCatchList -> tryCatchOne -> 
In addition: Warning message:
In kable_markdown(x, padding = padding, ...) :
  The table should have a header (column names)
Execution halted
autopkgtest [09:23:24]: test run-unit-test: ---]




signature.asc
Description: OpenPGP digital signature

Bug#913858: iwd: does not restart after crashing

[Andreas Henriksson]

Hello Felipe,

On Thu, Nov 15, 2018 at 10:00:09PM -0300, Felipe Sateler wrote:
> Package: iwd
> Version: 0.10-1
> Severity: normal
> 
> Hi,
> 
> Today iwd crashed, and it didn't restart. This left me with no wifi
> until I restarted it manually.

:(

> 
> I'm using NetworkManager, so it is possibly NM's fault. If so, please
> reassign there.

I'm not sure what's correct here, maybe you can tell me?

First off, iwd can be used in two different modes:
 - standalone (you manually start the service, expect it to run forever
   and then you run your favourite dhcp client on the interface.)
 - dbus activated (which AIUI is the way NetworkManager does it)

If iwd was simply a normal 'standalone' service, then using
Restart=on-failure or similar would be a no-brainer. I'm not sure
where the responsibility lies with dbus-activated stuff though.  I guess
atleast Restart=on-abnormal could be used there, but at the same time no
matter if the dbus-activated service exists because it's 'done for now'
or crashes, the overlying activator is the one who knows if it's useful
for the dbus-activated service to run at all. Maybe thus it's the
activators responsibility to keep track and dbus-activate again? I don't
know. I'm not sure but I atleast don't think it's common for
dbus-activated services to have their own Restart= setting

Your input on how the responsibilities should be divided would be
appreciated.

Regards,
Andreas Henriksson

Bug#911324: ITP?

[gregor herrmann]

Control: block -1 with 916544
Control: tag -1 + pending

On Tue, 11 Dec 2018 15:50:30 +0100, Cyrille Bollu wrote:

> Do you think I should go ahead and create packages for the missing
> dependencies?
> Shall I send ITP before?

Oops, looks like I missed this mail.

Anyway, I just created and uploaded to NEW the new packages.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#916313: perl: open "|command" does not set up child process's stdin correctly on perl 5.28 (5.24 is OK)

[Dominic Hargreaves]

Control: tags -1 + confirmed
Control: forwarded -1 https://rt.perl.org/Ticket/Display.html?id=133726

On Wed, Dec 12, 2018 at 04:54:22PM -0500, Zygo Blaxell wrote:
> Dear Maintainer,
> 
> The following one-line perl script fails:
> 
>   perl -e 'close(STDIN); open(CHILD, "|wc -l")'
> 
> On Debian stable (5.24.1-3+deb9u5) it produces:
> 
>   $ perl -e 'close(STDIN); open(CHILD, "|wc -l")'
>   0
> 
> but on Debian testing/unstable (5.28.1-1, 5.28.1-3) it produces:
> 
>   $ perl -e 'close(STDIN); open(CHILD, "|wc -l")'
>   wc: 'standard input': Bad file descriptor
>   0
>   wc: -: Bad file descriptor
> 
> Other variants of open to a command
> (e.g. open(CHILD, "-|") || exec ...) are similarly broken if STDIN is closed.
> 
> This wreaks havoc on Perl filter scripts that pass data between child
> shell commands: the commands unexpectedly get EBADF when reading from
> stdin, or they unexpectedly use one of the other files they open as
> their stdin.

Thanks for the report! After some investigation, I forwarded the report
upstream, and I believe a patch should be available shortly.

Best,
Dominic.

Bug#916546: RM: multipartposthandler/testing -- ROM; obsoleted package

[Georges Khaznadar]

Package: ftp.debian.org
Severity: normal

The only package which depdned on multipartposthandler is
uicilibris, which has been removed now from testing and
unstable (after my previous request).

As this package is no longer maintained upstream, and
was never adapted for Python3, it should be removed now from
testing and from unstable

Bug#916545: git-buildpackage: gbp pq import fails to import patches with no headers

[James Cowgill]

Package: git-buildpackage
Version: 0.9.11
Severity: normal

Hi,

As a result of the fix applied to gbp to fix #912426, gbp pq import can
no longer import patches containing no headers. This in turn causes dgit
to fail to clone at least glibc (where I originally saw this bug).

For example, running gbp pq import on glibc 2.28-2 gives:
> gbp:info: Trying to apply patches at 
> '56686caf41f17b97b32401a4b12ce45a22d80f37'
> gbp:warning: Patch 'git-updates.diff' has no authorship information, using 
> 'GNU Libc Maintainers '
> gbp:warning: Patch 'check-unknown-symbols.diff' has no authorship 
> information, using 'GNU Libc Maintainers '
> gbp:warning: Patch 'locale-print-LANGUAGE.diff' has no authorship 
> information, using 'GNU Libc Maintainers '
> gbp:warning: Patch 'LC_IDENTIFICATION-optional-fields.diff' has no authorship 
> information, using 'GNU Libc Maintainers '
> gbp:error: Failed to apply 
> '/home/jcowgill/me-workspace/glibc/glibc/debian/patches/localedata/local-all-no-archive.diff':
>  Failed to read patch header of 
> '/home/jcowgill/me-workspace/glibc/glibc/debian/patches/localedata/local-all-no-archive.diff':
>  b"error: empty patch: '/dev/null'\n"
> gbp:error: Couldn't apply patches

The first line of "local-all-no-archive.diff" is simply "---" to mark
that the patch contains no header. Since the above fix ignores anything
after encountering a "---", an empty file gets passed to git mailinfo
which barfs.

Reverting the fix from #912426 seems to fix this.

James



signature.asc
Description: OpenPGP digital signature

Bug#916544: ITP: libmenlo-legacy-perl -- legacy internal and client support for Menlo

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmenlo-legacy-perl
  Version : 1.9022
  Upstream Author : Tatsuhiko Miyagawa 
* URL : https://metacpan.org/release/Menlo-Legacy
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : legacy internal and client support for Menlo

Menlo::Legacy is a package to install Menlo::CLI::Compat which is a
compatibility library that implements the classic version of cpanminus
internals and behaviors. This is so that existing users of cpanm and API
clients such as Carton, Carmel and App::cpm can rely on the stable features
and specific behaviors of cpanm.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#916543: php7.2: obsoleting php7.2 in favour of php7.3 breaks nextcloud

[james.bottom...@hansenpartnership.com]

Package: php7.2-common
Version: 7.2.9-1
Severity: important

It looks like several php 7 requiring web applications have not successfully
migrated from 7.2 to 7.3, among them being nextcloud.  It definitely still
fails with 7.3 (nextcloud latest production 14.0.4).  Unreleased nextcloud 15
is targetted for php 7.3

In the meantime upgrading php-defaults removes php7.2-gd which is what
caused nextcloud to fail (the rest of libapache2-mod-php7.2 remains
installed but would likely begin losing pieces as well)


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

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

Versions of packages php7.2 depends on:
ii  libapache2-mod-php7.2  7.2.9-1
ii  php7.2-common  7.2.9-1

php7.2 recommends no packages.

php7.2 suggests no packages.

Versions of packages php7.2-common depends on:
ii  libc6   2.27-8
ii  libssl1.1   1.1.1a-1
ii  php-common  2:68
ii  ucf 3.0038

-- no debconf information

Bug#916542: ITP: libmenlo-perl -- CPAN client backend

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmenlo-perl
  Version : 1.9019
  Upstream Author : Tatsuhiko Miyagawa 
* URL : https://metacpan.org/release/Menlo
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : CPAN client backend

Menlo is a backend for cpanm 2.0, developed with the goal to replace cpanm
internals with a set of modules that are more flexible, extensible and easier
to use.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#916541: ITP: trollsift -- String parser/formatter

[Antonio Valentino]

Package: wnpp
Severity: wishlist
Owner: Antonio Valentino 

* Package name: trollsift
  Version : 0.3.1
  Upstream Author : Panu Lahtinen 
* URL : https://github.com/pnuu/trollsift
* License :   Programming Lang: Python
  Description : String parser/formatter for PyTroll packages

Binary package names: python3-trollsift

Bug#916540: ITP: prometheus-xmpp-alerts -- web hook that forwards prometheus alerts over XMPP

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: prometheus-xmpp-alerts
  Version : 0.1
  Upstream Author : Jelmer Vernooij 
* URL : https://github.com/jelmer/prometheus-xmpp-alerts
* License : apachev2
  Programming Lang: Python 
  Description : web hook that forwards prometheus alerts over XMPP

 This package provides a web hook for the prometheus alertmanager
 that can deliver alerts from prometheus over XMPP (Jabber).

Bug#916539: ITP: libcpan-common-index-perl -- common library for searching CPAN modules, authors and distributions

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcpan-common-index-perl
  Version : 0.010
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/CPAN-Common-Index
* License : Apache-2.0
  Programming Lang: Perl
  Description : common library for searching CPAN modules, authors and 
distributions

CPAN::Common::Index provides a common library for working with a variety of
CPAN index services. It is intentionally minimalist, trying to use as few
non-core modules as possible.

CPAN::Common::Index is an abstract base class that defines a common API.
Individual backends deliver the API for a particular index.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#916538: [btrfs-progs] btrfsck segfaults with -E and --subvol-extents

[Bruno Kleinert]

Package: btrfs-progs
Version: 4.19.1-1
Severity: normal

--- Please enter the report below this line. ---
Hi,

btrfsck --help includes:
   -E|--subvol-extents 
   print subvolume extents and sharing state

btrfsck -E and btrfsck -E  /dev/something always segfault, see
attached backtraces in 'btrfsck -E.txt' and 'btrfsck -E 263 dev-
sdc1.txt'.

Running btrfsck --subvol-extents  /dev/something prints some
messages and then segfaults, see attached backtrace 'btrfsck --subvol-
extents 263 dev-sdc1.txt'.

The used input /dev/sdc1 and subvolume id 263 are valid in my test
setup, and I unmounted the filesystem before running btrfsck.

I'm aware that btrfsck is under development. However, I'd still expect
it to print useful error message instead of just crashing.

Cheers - Bruno

--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-3-amd64

Debian Release: buster/sid
  500 unstable-debug  deb.debian.org 
  500 unstabledeb.debian.org 
1 experimental-debug deb.debian.org 
1 experimentaldeb.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-=
libblkid1  (>= 2.17.2) | 2.33-0.2
libc6 (>= 2.8) | 2.28-2
liblzo2-2  | 2.10-0.1
libuuid1 (>= 2.16) | 2.33-0.2
zlib1g(>= 1:1.2.0) | 1:1.2.11.dfsg-1


Package's Recommends field is empty.

Suggests(Version) | Installed
=-+-===
duperemove| 





(0)fuddl@flutschi:~$ sudo gdb btrfsck core
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from btrfsck...Reading symbols from 
/usr/lib/debug/.build-id/be/495c9f9b35a2174fb0fa5151a765bcc608da48.debug...done.
done.

warning: core file may not match specified executable file.
[New LWP 29034]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `btrfsck -E'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f008e6462c6 in __GI_strtoul_l_internal (nptr=nptr@entry=0x0, 
endptr=endptr@entry=0x7ffe0cc1a5c0, base=base@entry=0, 
group=group@entry=0, loc=0x7f008e7c6560 <_nl_global_locale>) at 
../stdlib/strtol_l.c:283
283 ../stdlib/strtol_l.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x7f008e6462c6 in __GI_strtoul_l_internal (nptr=nptr@entry=0x0, 
endptr=endptr@entry=0x7ffe0cc1a5c0, base=base@entry=0, 
group=group@entry=0, loc=0x7f008e7c6560 <_nl_global_locale>) at 
../stdlib/strtol_l.c:283
#1  0x7f008e645d22 in __strtoul (nptr=nptr@entry=0x0, 
endptr=endptr@entry=0x7ffe0cc1a5c0, base=base@entry=0)
at ../stdlib/strtol.c:106
#2  0x56479a8ec8a3 in arg_strtou64 (str=0x0) at utils-lib.c:25
#3  0x56479a8d02c4 in cmd_check (argc=2, argv=0x7ffe0cc1aa08) at 
check/main.c:9596
#4  0x56479a88ee03 in main (argc=2, argv=0x7ffe0cc1aa08) at btrfs.c:302
(gdb) bt full
#0  0x7f008e6462c6 in __GI_strtoul_l_internal (nptr=nptr@entry=0x0, 
endptr=endptr@entry=0x7ffe0cc1a5c0, base=base@entry=0, 
group=group@entry=0, loc=0x7f008e7c6560 <_nl_global_locale>) at 
../stdlib/strtol_l.c:283
negative = 
cutoff = 
cutlim = 
i = 
s = 0x0
c = 
save = 
end = 
overflow = 
cnt = 
current = 
thousands = 0x0
thousands_len = 0
grouping = 0x0
j = 
jmax = 
__res = 
__c = 
__res = 
__c = 
__res = 
__c = 
#1  0x7f008e645d22 in __strtoul (nptr=nptr@entry=0x0, 
endptr=endptr@entry=0x7ffe0cc1a5c0, base=base@entry=0)
at ../stdlib/strtol.c:106
No locals.
#2  0x56479a8ec8a3 in arg_strtou64 (str=0x0) at utils-lib.c:25
value = 
ptr_parse_end = 0x0
#3  0x56479a8d02c4 in cmd_check (argc=2, argv=0x7ffe0cc1aa08) at 
check/main.c:9596
long_options = {{name = 0x56479a918506 "super", has_arg = 1, flag = 
0x0, val = 115}, {name = 0x56479a91469b "repair", 
has_arg = 0, flag = 0x0, val = 257}, {name = 0x56479a90968e 
"readonly", has_arg = 0, flag = 0x0, val = 261}, {
name = 0x56479a9146a2 "init-csum-tree", has_arg = 0, flag = 0x0, 
val = 258}, {name = 0x56479a9146b1 

Bug#916537: ITP: libhttp-tinyish-perl -- HTTP::Tiny compatible HTTP client wrappers

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libhttp-tinyish-perl
  Version : 0.15
  Upstream Author : Tatsuhiko Miyagawa
* URL : https://metacpan.org/release/HTTP-Tinyish
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : HTTP::Tiny compatible HTTP client wrappers

HTTP::Tinyish is a wrapper module for HTTP client modules LWP, HTTP::Tiny and
HTTP client software curl and wget.

It provides an API compatible to HTTP::Tiny, and the implementation has been
extracted out of App::cpanminus. HTTP::Tinyish can be useful in a restrictive
environment where you need to be able to download CPAN modules without an
HTTPS support in built-in HTTP library.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#847488: closed by Joao Eriberto Mota Filho (Bug#847488: fixed in unhide 20130526-2)

[Eriberto]

Em qui, 13 de dez de 2018 às 04:12, Helmut Grohne  escreveu:
>
> Control: reopen -1
>
> On Wed, Dec 12, 2018 at 06:09:12PM +, Debian Bug Tracking System wrote:
> >* d/rules: Use triplet-prefixed CC, thanks to Helmut Grohne, closes: 
> > #847488.
>
> You only applied half of my patch. It uses $(CC) rather than gcc now,
> but $(CC) still isn't initialized properly.

Hi Helmut,

Sorry. The patch was commited by other team member in Salsa and I do
not verified it. So, I was missing too.

Re-uploading. Thanks for your help.

Cheers,

Eriberto

Bug#916536: squid FTCBFS: multiple reasons

[Helmut Grohne]

Source: squid
Version: 4.4-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

squid fails to cross build from source for a number of reasons. The
immediate failure is with the g++ build dependency as that conflicts
with the build architecture g++. For properly expressing the dependency,
we'd need "toolchain dependency translation", which isn't a thing yet.
However, the relevant dependencies are always satisfied since stretch.
Therefore, we can simply drop them.

During a amd64 -> arm64 cross build, somehow the -m64 flag leaks into
CFLAGS. Unfortunately, the arm64 cross compiler doesn't like that flag
and the build fails. It turns out that the flag originates from getconf,
which is called while figuring out LFS flags. By passing
--with-build-environment=default, we bypass getconf and tell squid to
simpy use _FILE_OFFSET_BITS and that always works on Debian.

Lateron, running cf_gen fails, because it was built with the wrong
compiler. squid's configure doesn't correctly figure out the build
architecture compiler, so it needs to be told explicitly via BUILDCXX.

The attached patch fixes all of these problems and makes squid cross
buildable. Please consider applying it.

Helmut
diff --minimal -Nru squid-4.4/debian/changelog squid-4.4/debian/changelog
--- squid-4.4/debian/changelog  2018-10-30 14:57:15.0 +0100
+++ squid-4.4/debian/changelog  2018-12-15 15:00:46.0 +0100
@@ -1,3 +1,14 @@
+squid (4.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Drop compiler Build-Depends: always satisfied since stretch.
++ Pass --with-build-environment=default to ./configure to avoid leaking
+  getconf results into CFLAGS.
++ Pass BUILDCXX to ./configure.
+
+ -- Helmut Grohne   Sat, 15 Dec 2018 15:00:46 +0100
+
 squid (4.4-1) unstable; urgency=high
 
   * Urgency high due to security fixes
diff --minimal -Nru squid-4.4/debian/control squid-4.4/debian/control
--- squid-4.4/debian/control2018-10-30 14:57:15.0 +0100
+++ squid-4.4/debian/control2018-12-15 15:00:46.0 +0100
@@ -8,8 +8,6 @@
 Vcs-Git: https://salsa.debian.org/squid-team/squid.git
 Vcs-Browser: https://salsa.debian.org/squid-team/squid
 Build-Depends: ed, libltdl-dev, pkg-config
-   , g++ (>= 4.9) | clang (>= 3.7)
-   , gcc (>= 4.9) | clang (>= 3.7)
, cdbs, debhelper (>=10), dpkg-dev (>= 1.17.11~), lsb-release
, libcppunit-dev
, libcap2-dev [linux-any]
diff --minimal -Nru squid-4.4/debian/rules squid-4.4/debian/rules
--- squid-4.4/debian/rules  2018-10-30 14:57:15.0 +0100
+++ squid-4.4/debian/rules  2018-12-15 15:00:46.0 +0100
@@ -11,6 +11,8 @@
 
 export DEB_BUILD_PARALLEL = yes
 include /usr/share/dpkg/buildflags.mk
+-include /usr/share/dpkg/buildtools.mk
+CXX_FOR_BUILD ?= $(CXX)
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
@@ -24,6 +26,7 @@
 BUILDINFO := $(shell lsb_release -si 2>/dev/null)
 
 DEB_CONFIGURE_EXTRA_FLAGS := BUILDCXXFLAGS="$(CXXFLAGS) $(CPPFLAGS) 
$(LDFLAGS)" \
+   BUILDCXX=$(CXX_FOR_BUILD) \
--enable-build-info="$(BUILDINFO) $(DEB_HOST_ARCH_OS)" \
--datadir=/usr/share/squid \
--sysconfdir=/etc/squid \
@@ -57,6 +60,7 @@
--with-pidfile=/var/run/squid.pid \
--with-filedescriptors=65536 \
--with-large-files \
+   --with-build-environment=default \
--with-default-user=proxy \
--with-gnutls
 

Bug#916236: golang-golang-x-net-dev: FTBFS on s390x - rawconn.go undefined: getsockopt

[Martín Ferrari]

Tobias,

On 14/12/2018 21:54, Dr. Tobias Quathamer wrote:
> Am 14.12.2018 um 14:28 schrieb Martín Ferrari:
>> Tobias: I see you did the latest upload, but you did not follow the git
>> workflow I had started, and instead of following git commits, you merged
>> a snapshot.. I will need to rewrite git history now :(
> 
> Hi Martín,
> 
> I'm really sorry that I messed up your workflow and caused you extra
> work. That was certainly not my intention.

I am sure of that!

Sorry for my frustrated message, I have fixed it now and it was not a
big deal. But you will need to re-clone or reset all your local branches
now.


-- 
Martín Ferrari (Tincho)

Bug#916535: ITP: libtie-handle-offset-perl -- module to provide tied handle that hides the beginning of a file

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtie-handle-offset-perl
  Version : 0.004
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/Tie-Handle-Offset
* License : Apache-2.0
  Programming Lang: Perl
  Description : module to provide tied handle that hides the beginning of a 
file

Tie::Handle::Offset provides a file handle that hides the beginning of a
file. After opening, the file is positioned at the offset location. "seek()"
and "tell()" calls are modified to preserve the offset.

For example, "tell($fh)" will return 0, though the actual file position is at
the offset. Likewise, "seek($fh,80,0)" will seek to 80 bytes from the offset
instead of 80 bytes from the actual start of the file.

The included Tie::Handle::SkipHeader module automatically hides an
email-style message header. After opening the file, it reads up to a blank or
white-space-only line and sets the offset to the next byte.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#914549: Flatpak version of Totem

[antistress]

Hi,

I've also tried the flatpak version of Totem (from FlatHub) that I've 
installed and launched from Gnome Software.


I've managed to play the 2 test files without crashes, but only sound 
was played, with no video (black screen within Totem).


Thanks

Bug#916534: ITA: gadmin-samba -- GTK+ configuration tool for samba

[Marek Mosiewicz]

Package: wnpp
Severity: normal

Hello,

What is status of gadmin tools in Debian ? Is there any replacement for them ?
Is upstream maintianed ? I think they were good tool for people who did not
know too much internals of config files. Maybe I could help if there is
interest
in them.

The package description is:
 gadmin-samba is an easy to use GTK+ frontend for the SAMBA file and print
 server. It features multiple local and remote user and group imports, on the
 fly share creation and user handling, including randomization of usernames and

Bug#916200: script: does not reap signaled children any more, deadlocks until SIGKILL

[Bernhard Übelacker]

Control: fixed 916200 1:2.30.2-0.3
Control: found 916200 1:2.31.1-0.1


Dear Maintainer,
I noticed this behaviour too and found last version that
normally exits is 2.30.2.

I did a git bisect that points to the upstream commit [1] below.

Kind regards,
Bernhard


[1] 
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=2e7a92270114cc652ea090251a374e917adb7a72


# git bisect good
2e7a92270114cc652ea090251a374e917adb7a72 is the first bad commit
commit 2e7a92270114cc652ea090251a374e917adb7a72
Author: Karel Zak 
Date:   Fri Sep 8 09:48:29 2017 +0200

script: support sig{stop/cont}

* call wait() only when child exited
* suspend all session (including script master process) when child get
  SIGSTOP and send SIGCONT to child when master process resume

This allows to suspend all session and later use "fg" shell command to
resume.

$ ps af
14722 pts/1Ss 0:00 bash
 4870 pts/1S+ 0:00  \_ ./script
 4871 pts/6Ss+0:00  \_ bash -i

$ kill -SIGSTOP 4871

and script session on another terminal:

$ script
Script started, file is typescript
$ 
[1]+  Stopped ./script

$ fg 1
./script

... session again usable ...
^D
Script done, file is typescript

Signed-off-by: Karel Zak 

:04 04 5f6d5eb332f5db3c41cb095d39efdca5be5baf6e 
cdc08b6da0bc5f5a93be049c1a80f0b0620a9417 M  term-utils



# buster amd64 qemu VM


apt update
apt dist-ugprade
apt build-dep util-linux


apt install bsdutils git


script -c "vi"
kill $(pidof vi)
kill -9 $(pidof script)


wget 
https://snapshot.debian.org/archive/debian/20170322T211511Z/pool/main/u/util-linux/bsdutils_2.29.2-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20180117T154752Z/pool/main/u/util-linux/bsdutils_2.30.2-0.3_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20180308T040556Z/pool/main/u/util-linux/bsdutils_2.31.1-0.5_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20180210T101430Z/pool/main/u/util-linux/bsdutils_2.31.1-0.1_amd64.deb



bsdutils  1:2.29.2-1ends
bsdutils  1:2.30.2-0.3  ends
bsdutils  1:2.31.1-0.1  hangs
bsdutils  1:2.31.1-0.5  hangs
bsdutils  1:2.32.1-0.1  hangs



git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
git checkout v2.30.2
./autogen.sh
./configure
make -j8
./script -c "vi"
make clean
git checkout v2.31.1
...



git checkout v2.30.2# ends
git checkout v2.31.1# hangs




root@debian:~/util-linux# git bisect start
root@debian:~/util-linux# git bisect good v2.30.2
root@debian:~/util-linux# git bisect bad v2.31.1
binäre Suche: eine Merge-Basis muss geprüft werden
[dd9bae58ae4bc3bded2acf743981bbc8c06f468a] build-sys: release++ (v2.30)
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 315 Commits zum Testen übrig (ungefähr 8 Schritte)
[5264aebb4f822fa9147ee576562a4961ca97261d] lib/randutils: improve getrandom() 
usage
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 157 Commits zum Testen übrig (ungefähr 7 Schritte)
[6b28328255aa1248931947a4d1521288bde01837] su: properly clear child PID
root@debian:~/util-linux# git bisect bad
binäre Suche: danach noch 71 Commits zum Testen übrig (ungefähr 6 Schritte)
[d17fb726b562a69e8f174d46fa6cf794abc129cd] rfkill: merge rfkill.8 project to 
util-linux
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 35 Commits zum Testen übrig (ungefähr 5 Schritte)
[2e7a92270114cc652ea090251a374e917adb7a72] script: support sig{stop/cont}
root@debian:~/util-linux# git bisect bad
binäre Suche: danach noch 17 Commits zum Testen übrig (ungefähr 4 Schritte)
[24f9dde539777417325d6039e2f2387d792afe96] build-sys: remove unused rfkill.py
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 8 Commits zum Testen übrig (ungefähr 3 Schritte)
[5b8e46f7e7710e2bb88ff8e763997830c9494df2] hwclock: close hwaudit_fd 
unconditionally
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 4 Commits zum Testen übrig (ungefähr 2 Schritte)
[3184afa529de5efc77c4ea1f0574276a6f482f7e] uuidgen: add more details to man page
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 2 Commits zum Testen übrig (ungefähr 1 Schritt)
[08e3c9e6620232aa5433d102d3f8ac28bbae01b0] hwclock: update usage()
root@debian:~/util-linux# git bisect good
binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt)
[e12364cdfb2c8046bfe34f18af9583f1dcf934c9] lsblk: small man page change in 
return codes description
root@debian:~/util-linux# git bisect good
2e7a92270114cc652ea090251a374e917adb7a72 is the first bad commit
commit 2e7a92270114cc652ea090251a374e917adb7a72
Author: Karel Zak 
Date:   Fri Sep 8 09:48:29 2017 +0200

script: support sig{stop/cont}

* call wait() only when child exited
* suspend all 

Bug#916476: axel: autopkgtest regression

[Eriberto]

Em sáb, 15 de dez de 2018 às 04:49, Paul Gevers  escreveu:
>
> Forgot one thing.
>
> On 15-12-2018 01:25, Eriberto Mota wrote:
>
> > Seems a temporary issue in Debian infrastructure.
>
> By the way, try to be robust against that. On netwerk errros, retry at
> least a couple of times with some time in between. And consider marking
> your test as skippable and exit with exit code 77 if after several
> retries the network errors persist.
>
> Paul

Hi Paul,

Initially, thanks for your help.

Axel have not retry option.

I found the problem in tests 5-6: the CI machine isn't resolving IPv6.
Test2 needs a -k.

I will set skippable for tests 2-6, adding exit 77, add -k to 2 and
re-upload. If all right, I will fix the test for lime-forensics-dpkg
package.

Thanks!!

Cheers,

Eriberto

Bug#916460: wpasupplicant 2.6 breaks WPA-Enterprise authentication

[Gabriel]

Il 2018-12-15 13:44 Andrej Shadura ha scritto:

On Sat, 15 Dec 2018 at 01:39, Gabriel  wrote:


Il 2018-12-14 22:12 Andrej Shadura ha scritto:
No, it doesn't.


Could you please try wpa-supplicant 2.7 from experimental with a
downgraded libssl1.1?


I installed these packages from stable and experimental:
openssl 1.1.0f-3+deb9u2
wpasupplicant 2:2.7-1

As soon as I'll be back in my University I'll report the result.