Bug#916747: kdesudo: Windows open through kdesudo do not support multiple keyboard layouts

[Shai Berger]

Package: kdesudo
Version: 3.4.2.4-2+b1
Severity: normal
Tags: l10n

Dear Maintainer,

I use multiple system users for my work on different projects,
and I use kdesudo in order to open a terminal (and from it,
other apps) for my separate users, within my "main" user's
desktop.

I also use multiple keyboard layouts -- us and il.

But the windows opened via kdesudo do not seem to be aware of this.
Whenever I enter one of these windows, I am "stuck" in the us
layout, and cannot switch layouts; neither via the switch-layout
shortcut, nor by clicking the system-tray icon.

This may be related to input methods -- I know very little of these,
and am not using anything non-default, at least not intentionally.

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

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

Versions of packages kdesudo depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  kde-runtime4:17.08.3-2
ii  libc6  2.28-2
ii  libgcc11:8.2.0-12
ii  libkdecore54:4.14.38-3
ii  libkdeui5  4:4.14.38-3
ii  libqt4-dbus4:4.8.7+dfsg-17
ii  libqt4-svg 4:4.8.7+dfsg-17
ii  libqtcore4 4:4.8.7+dfsg-17
ii  libqtgui4  4:4.8.7+dfsg-17
ii  libstdc++6 8.2.0-12
ii  sudo   1.8.26-2

kdesudo recommends no packages.

kdesudo suggests no packages.

-- debconf information:
  kdesudo/kdesu: false

Bug#916748: dicod: typo in dicodconfig.8

[David Paul]

Package: dicod
Version: 2.3-2
Severity: minor

Dear Maintainer,

In dicodconfig.8 in the tarball
http://deb.debian.org/debian/pool/main/d/dico/dico_2.3-2.debian.tar.xz
line 39 reads
```
``#include /var/lib/dictd/dictorg-db.list''
```
but should instead read
```
``#include /var/lib/dicod/dictorg-db.list''
```
.

This typo is also present in the newer tarball
http://deb.debian.org/debian/pool/main/d/dico/dico_2.7-1.debian.tar.xz


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 2.0 (ascii)
Release:2.0
Codename:   ascii

Architecture: x86_64

Kernel: Linux 4.18.9-gnu (SMP w/16 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dicod depends on:
ii  adduser3.115
ii  libc6  2.27-6
ii  libdico1   2.3-2
ii  libgsasl7  1.8.0-8+b2
ii  libldap-2.4-2  2.4.44+dfsg-5+deb9u1
ii  libltdl7   2.4.6-2
ii  libpam0g   1.1.8-3.6
ii  libpcre3   2:8.39-9
ii  lsb-base   4.1+devuan2
ii  m4 1.4.18-1
ii  zlib1g 1:1.2.8.dfsg-5

dicod recommends no packages.

Versions of packages dicod suggests:
ii  dico-doc  2.3-2

-- no debconf information

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

[Pirate Praveen]

[adding -devel to cc]

On 12/3/18 8:11 PM, Dominik George wrote:
>> well, Debian is using gitlab!!! so this sentence has no sense. The
>> problem here
>> is that is a complex software that depends of a lot of pieces and it's
>> not
>> easy/possible to fit the definition. So, maybe we should create another
>> category
>> of software.
> 
> Yes, and that Debian officially uses GitLab, from a foreign source, without 
> being able to support it in Debian, does make me feel ashamed for the project.
> 
>> maybe creating another kind of repo. debian-contributuions
>> debian-blabla, whatever.
>>
> 
> We had volatile, which, redefined properly, could help. I am trying to draft 
> such a definition.

Did you get a chance to work on it?

I think it has to be an extension of backports with dependencies that
fall within the backports criteria being maintained in backports and
only packages that cannot be in backports maintained in volatile.

Original definition of volatile from https://www.debian.org/volatile/:
"Some packages aim at fast moving targets, such as spam filtering and
virus scanning, and even when using updated data patterns, they do not
really work for the full time of a stable release. The main goal of
volatile is allowing system administrators to update their systems in a
nice, consistent way, without getting the drawbacks of using unstable,
even without getting the drawbacks for the selected packages. So
debian-volatile will only contain changes to stable programs that are
necessary to keep them functional."

Proposed definition:
"Some packages aim at fast moving targets, such as complex web based
software with very small release cycles and new dependencies, they do
not receive security support or bug fixes for the full time of a stable
release. This means backporting targeted fixes are impossible.  The main
goal of volatile is allowing system administrators to update their
systems in a nice, consistent way, without getting the drawbacks of
using unstable, even without getting the drawbacks for the selected
packages. New dependencies introduced can be maintained in backports
repository. So debian-volatile will be an extension of debian-backports,
with dependencies that fall within the criteria maintained in
debian-backports."





signature.asc
Description: OpenPGP digital signature

Bug#916720: upgrade-reports: stretch to buster upgrade graphics fail, ok with old kernel 4.9

[Max]

On Mon, 17 Dec 2018 at 22:48, Niels Thykier  wrote:

> Control: tags -1 moreinfo
>
> max:
> > Package: upgrade-reports
> > Severity: important
> >
> > Dear Maintainer,
> >
> > upgraded to buster via apt-get upgrade, apt-get dist-upgrade, all worked
> well up to here.
> > Booting gave black screen.
> > Reboot with old kernel 4.9 --> all is well.
> > Set system to go into multi-user (without graphics): Same effect.
> > Thus it must be related to the framebuffer screen setting at boot,
> rather than xserver-xorg.
> > Will attach working and non-working X.org.log below
> >
> > Max
> >
> > [...]
>
> Hi Max,
>
> Could you try to see if version 4.18.0-2 of the Debian Linux kernel
> works?  You can install it from snapshot.debian.org.
>
> I have seen some reports of 4.18.0-3 being broken or causing issues with
> graphics in certain circumstances (#916510, #916134, #914967) which may
> be related to your issue.
>
> Thanks,
> ~Niels
>
>
Another amendment here:
4.18.0-2 does indeed work as expected. 4.18.0-3 does not work.
I tried this on Dell Latitude D630 and Dell Latitude E6400 notebooks.

How can this be forwarded to the kernel maintainers?

Best regards,
Max

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

[Alexander Wirt]

On Tue, 18 Dec 2018, Pirate Praveen wrote:

> [adding -devel to cc]
> 
> On 12/3/18 8:11 PM, Dominik George wrote:
> >> well, Debian is using gitlab!!! so this sentence has no sense. The
> >> problem here
> >> is that is a complex software that depends of a lot of pieces and it's
> >> not
> >> easy/possible to fit the definition. So, maybe we should create another
> >> category
> >> of software.
> > 
> > Yes, and that Debian officially uses GitLab, from a foreign source, without 
> > being able to support it in Debian, does make me feel ashamed for the 
> > project.
> > 
> >> maybe creating another kind of repo. debian-contributuions
> >> debian-blabla, whatever.
> >>
> > 
> > We had volatile, which, redefined properly, could help. I am trying to 
> > draft such a definition.
> 
> Did you get a chance to work on it?
> 
> I think it has to be an extension of backports with dependencies that
> fall within the backports criteria being maintained in backports and
> only packages that cannot be in backports maintained in volatile.
> 
> Original definition of volatile from https://www.debian.org/volatile/:
> "Some packages aim at fast moving targets, such as spam filtering and
> virus scanning, and even when using updated data patterns, they do not
> really work for the full time of a stable release. The main goal of
> volatile is allowing system administrators to update their systems in a
> nice, consistent way, without getting the drawbacks of using unstable,
> even without getting the drawbacks for the selected packages. So
> debian-volatile will only contain changes to stable programs that are
> necessary to keep them functional."
> 
> Proposed definition:
> "Some packages aim at fast moving targets, such as complex web based
> software with very small release cycles and new dependencies, they do
> not receive security support or bug fixes for the full time of a stable
> release. This means backporting targeted fixes are impossible.  The main
> goal of volatile is allowing system administrators to update their
> systems in a nice, consistent way, without getting the drawbacks of
> using unstable, even without getting the drawbacks for the selected
> packages. New dependencies introduced can be maintained in backports
> repository. So debian-volatile will be an extension of debian-backports,
> with dependencies that fall within the criteria maintained in
> debian-backports."
I don't think that -backports is the right suite. It should be something new,
with a new team.

Alex



signature.asc
Description: PGP signature

Bug#916749: systemd-cron: Tries to launch unreachable commands

[Erwan David]

Package: systemd-cron
Version: 1.5.14-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

I just switched from cron to systemd cron. I now have every 5 mintes following 
email :

* cron-dma-root-0.service - [Cron] "*/5 * * * * root [ -x /usr/sbin/dma ] && 
/usr/sbin/dma -q1"
   Loaded: loaded (/etc/cron.d/dma; generated)
   Active: failed (Result: exit-code) since Tue 2018-12-18 09:10:03 CET; 74ms 
ago
 Docs: man:systemd-crontab-generator(8)
  Process: 8569 ExecStart=/bin/sh /run/systemd/generator/cron-dma-root-0.sh 
(code=exited, status=1/FAILURE)
 Main PID: 8569 (code=exited, status=1/FAILURE)

Dec 18 09:10:03 ot-fixe-008 systemd[1]: Starting [Cron] "*/5 * * * * root [ -x 
/usr/sbin/dma ] && /usr/sbin/dma -q1"...
Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Main process 
exited, code=exited, status=1/FAILURE
Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Failed with 
result 'exit-code'.
Dec 18 09:10:03 ot-fixe-008 systemd[1]: Failed to start [Cron] "*/5 * * * * 
root [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1".
Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Triggering 
OnFailure= dependencies.

/usr/sbin/dma does not exist, thus the action should not be executed.


-- Package-specific info:
-- output of systemd-delta

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

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

Versions of packages systemd-cron depends on:
ii  libc6 2.28-2
ii  python3   3.6.7-1
ii  systemd-sysv  239-15

Versions of packages systemd-cron recommends:
ii  postfix [mail-transport-agent]  3.3.2-1

systemd-cron suggests no packages.

-- Configuration Files:
/etc/anacrontab changed:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/root
LOGNAME=root
START_HOURS_RANGE=4-6
1   5   cron.daily  run-parts --report /etc/cron.daily
7   10  cron.weekly run-parts --report /etc/cron.weekly
@monthly15  cron.monthlyrun-parts --report /etc/cron.monthly


-- no debconf information

Bug#905254: Status of libphp-phpmailer

[Xavier]

Le 14/12/2018 à 09:17, Chris Lamb a écrit :
> Chris Lamb wrote:
> 
>> Vincent Danjean wrote:
>>
>>>   However, the git does not seem to have been moved to salsa.
>>
>> I fixed a number of CVEs recently and I would love to push my changes
>> to suitable branches. Can the PEAR maintainers please migrate this
>> repo ASAP?
> 
> Any update on getting this into Git...?
> 
> Regards,

Hi all,

it seems difficult to migrate libphp-phpmailer to version 6.x before
buster freeze. However, ocsinventory-server is affected by some CVEs [1]
which are fixed on version 2.5 which embeds PHPMailer 6.x.

So my question is could I embed PHPMailer-6 in ocsinventory-server ?

Cheers,
Xavier

[1] https://bugs.debian.org/905396

Bug#916750: lighttpd: reorganize lighttpd binary packages to reduce dependencies (ldap/mysql) and package count

[Helmut Grohne]

Source: lighttpd
Version: 1.4.52-1

It has come up that lighttpd's binary packages are organized
suboptimally. I'm creating this bug report to discuss a better
organization and have X-Debbugs-Cced some interested parties. Please
forward the bug to other interested parties that you may know of.

Problem #1:

Some upload since stretch added the mod_vhostdb_* modules including
mod_vhostdb_ldap.so and mod_vhostdb_mysql.so. Therefore lighttpd now
depends on libldap and libmariadbclient. That produces an unreasonable
installation size for embedded uses. Multiple people (including Stefan
Bühler, Glenn Strauss and myself) have requested to shrink this.

Problem #2:

lighttpd presently produces 11 binary packages. That's quite many for an
otherwise small package. Adding binary packages has a metadata cost to
the Debian archive that affects everyone (not just lighttpd users). We
should seek to reduce the package count.

Are there more problems?

Fixing the first problem likely involves making the second problem
worse. We should seek to avoid that.

With regard to fixing this my first proposal builds on the existing
practise to put mod_foo.so into lighttpd-mod-foo: Let every binary
package build from src:lighttpd have Provides for the modules that it
ships. For the present lighttpd-mod-* packages, no Provides are needed.
Only the main lighttpd package needs a pile of provides. A README.Debian
should explain that you should use these virtual packages in Depends
rather than e.g. "Depends: lighttpd (>=
$version_that_introduced_mod_foo)".

Given that lighttpd modules are comparatively small (some tens of KB), I
suggest that grouping them by their main dependency would make sense.
The fairly obvious consequences would be:
 * lighttpd-modules-mysql: mod_authn_mysql, mod_mysql_vhost,
   mod_vhostdb_mysql
 * lighttpd-modules-ldap: mod_authn_ldap, mod_vhostdb_ldap
 * lighttpd (base package): mod_access, mod_accesslog, mod_alias,
   mod_auth, mod_authn_file, mod_cgi, mod_dirlisting, mod_evasive,
   mod_evhost, mod_expire, mod_extforward, mod_fastcgi,
   mod_flv_streaming, mod_indexfile, mod_proxy, mod_redirect,
   mod_rewrite, mod_rrdtool, mod_scgi, mod_secdownload, mod_setenv,
   mod_simple_vhost, mod_sockproxy, mod_ssi, mod_staticfile, mod_status,
   mod_uploadprogress, mod_userdir, mod_usertrack, mod_vhostdb,
   mod_wstunnel
 * The modules mod_authn_gssapi, mod_cml, mod_geoip, mod_magnet,
   mod_trigger_b4_dl and mod_webdav presently have their own binary
   packages and they each have significant library piles. Maybe it is
   best to leave these as is.
 * The remaining modules are mod_compress, mod_deflate and mod_openssl.
   These pull zlib1g, libbz2-1.0 and libssl1.1. At least the first two
   are transitively essential already and mod_openssl seems to be very
   popular, so it likely is best to leave them with the main binary
   package.

Resulting changes:
 * Merge lighttpd-mod-authn-mysql and lighttpd-mod-mysql-vhost together
   into lighttpd-modules-mysql.
 * Rename lighttpd-mod-auth-ldap to lighttpd-modules-ldap.
 * Add 3 transitional dummy packages for the removed/renamed packages.
 * Move mod_vhostdb_mysql and mod_vhostdb_ldap to the new packages.

-> mysql and ldap depends removed from lighttpd
-> +2 binary packages for buster
-> -3 binary packages for bullseye
-> Due to Provides (see above), rdeps don't have to change.

Then Stefan and Glenn proposed adding new modules:
 * mod_vhostdb_dbi
 * mod_vhostdb_pgsql
 * mod_authn_pam
 * mod_authn_sasl

Here it is less clear how to organize them. mod_cml and
mod_trigger_b4_dl each use libsasl2 (via libmemcached).
mod_vhostdb_pgsql is likely the only module that links postgres, so
likely it'll deserve a binary package.

How bad would it be to simply not ship these four packages in buster (as
is presently the case) and add them for bullseye? Which ones do we
really need for buster? Did I miss anything?

Please reply in a timely manner to allow implementing as much of the
changes as possible before the buster release.

Helmut

Bug#913635: php7.3-common: Repeatable segfault in php7.3 when running Cacti poller since upgrade to 7.3

[Jarno Paananen]

No change unfortunately:

[Tue Dec 18 11:05:02 2018] php[9750]: segfault at 7f202cc005cc ip
5623a9a38dda sp 7ffcbeeeb7b0 error 4 in php7.3[5623a9891000+25f000]

-- 

// Jarno

Bug#874487: Debian mirror mirrors.gigenet.com: missing-tracefile, syncscript

[Peter Palfrader]

ping?

On Tue, 11 Dec 2018, Peter Palfrader wrote:

> On Mon, 10 Dec 2018, Scott Ehas wrote:
> 
> > We performed an entirely new sync, and I haven't found any errors within
> > the ftpsync logs.  Can you confirm everything is correct?
> 
> http://mirrors.gigenet.com/debian/project/trace/mirrors.gigenet.com
> says it's from Saturday, December 8.
> 
> So the file has the right name now, but the sync is not happening
> regularly (every 6 hours, 4 times a day).
> 
> Further:
> - looking at your arch list, you might want to move from an architecture
>   EXCLUDE configuration to an INCLUDE configuration.
> - You should probably not sync off an ftp.*.debian.org alias and
>   probably not of a DNS rotation of several mirrors.  Pick one upstream.
> 
> 
> Also cf
>  - 
> https://mirror-master.debian.org/status/mirror-info/mirrors.gigenet.com.html
> Cheers,
> 
> > > I started writing a new howto/guidelines in case that's helpful:
> > >   https://etherpad.wikimedia.org/p/debian-mirror
> -- 
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#916751: [20181218] debian.tu-bs.de: unreachable

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi!

it seems
http://debian.tu-bs.de/debian/
is unreachable:
https://mirror-master.debian.org/status/mirror-info/debian.tu-bs.de.html

Please investigate.

Cheers,

Bug#916752: graphicsmagick: CVE-2018-20189

[Salvatore Bonaccorso]

Source: graphicsmagick
Version: 1.3.31-1
Severity: important
Tags: patch security upstream
Forwarded: https://sourceforge.net/p/graphicsmagick/bugs/585/

Hi,

The following vulnerability was published for graphicsmagick.

CVE-2018-20189[0]:
| In GraphicsMagick 1.3.31, the ReadDIBImage function of coders/dib.c has
| a vulnerability allowing a crash and denial of service via a dib file
| that is crafted to appear with direct pixel values and also
| colormapping (which is not available beyond 8-bits/sample), and
| therefore lacks indexes initialization.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20189
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20189
[1] https://sourceforge.net/p/graphicsmagick/bugs/585/
[2] http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/648e2b406589

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#916753: Stop recommending s6

[Laurent Bigonville]

Package: apt-listbugs
Version: 0.1.26
Severity: normal

Hi,

I'm not too sure why you want to use s6-setuidgid (that requires an
extra package to be installed) when you have runuser tool that exists
precisely for this reason. runuser is available in the util-linux
package for quite some times already.

Kind regards,

Laurent Bigonville

https://salsa.debian.org/frx-guest/apt-listbugs/commit/60fe655dad963804290228a3886406016a3a82ee

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

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

Versions of packages apt-listbugs depends on:
ii  apt 1.8.0~alpha2
ii  ruby1:2.5.1
ii  ruby-debian 0.3.9+b8
ii  ruby-gettext3.2.9-1
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b9
ii  ruby-xmlparser  0.7.3-3+b2

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-1
pn  s6   

Versions of packages apt-listbugs suggests:
ii  firefox [www-browser]  64.0-1
ii  lynx [www-browser] 2.8.9rel.1-2
ii  reportbug  7.5.1
ii  sensible-utils 0.0.12
ii  xdg-utils  1.1.3-1

-- no debconf information

Bug#916754: [20181218] debian.gtisc.gatech.edu: broken DNS

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi!

it seems we cannot resolve debian.gtisc.gatech.edu currently.
https://mirror-master.debian.org/status/mirror-info/debian.gtisc.gatech.edu.html

The problem appears to be a broken DNS configuration that puts all of
the nameservers for gtisc.gatech.edu in the same AS.

Please fix.

| ;; AUTHORITY SECTION:
| gtisc.gatech.edu.   86400   IN  NS  b.ns.gtisc.gatech.edu.
| gtisc.gatech.edu.   86400   IN  NS  a.ns.gtisc.gatech.edu.
| 
| ;; ADDITIONAL SECTION:
| b.ns.gtisc.gatech.edu.  300 IN  A   143.215.130.242
| a.ns.gtisc.gatech.edu.  300 IN  A   143.215.130.241

(Also, one of the nameservers for the parent zone (168.24.2.35) replies with
SERVFAIL when asked about gtisc.gatech.edu.)

Cheers,

Bug#916468: Conflict over /usr/bin/dune

[Stéphane Glondu]

Hi,

It has been brought to my attention that both packages "whitedune" and
"dune" provide the binary "/usr/bin/dune" (#916468).

The situation falls directly under section 10.1 of the Policy:

https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries

> Two different packages must not install programs with different
> functionality but with the same filenames.

The solution proposed by the policy is to rename one or both of the
packages, after a discussion here:

> [...] try to find a consensus about which program will have to be
> renamed. If a consensus cannot be reached, both programs must be
> renamed.

The "dune" package (of which I am the maintainer) is a popular build
system for OCaml projects. It is pretty recent, has strong upstream
support, and more and more projects are switching to it, which is a
reason to have it in Debian.

It was previously named jbuilder, but has been renamed due to a conflict
with another software. Upstream is reluctant to rename it again.

The "whitedune" package is a graphical VRML97/X3D viewer, editor, 3D
modeller and animation tool. It has existed in Debian since 2007 and its
last upload to Debian (an NMU) dates back to March 2016. The version in
Debian is 0.30.10 while the last upstream version [1] seems to be
0.99pl1234. The source tarball seems to date back to December 2018, so
the upstream project seems well alive. In the "whitedune" package,
"/usr/bin/dune" is a symbolic link to "whitedune".

[1] http://wdune.ourproject.org/

Due to its nature, the build system (a command line tool) is more likely
(IMHO) to be invoked as "dune" by third-parties than the desktop
application. Moreover, the existence of the symlink suggests that the
preferred way to call the application is through "whitedune" (and a menu
entry exists). Therefore, I propose that the "whitedune" package drops
the "/usr/bin/dune" symlink altogether.


Cheers,

-- 
Stéphane

Bug#916498: bumpversion: Maybe switch from unmaintained project to the maintained fork?

[Michael Fladischer]

Hi Lars,

Am 15.12.2018 um 03:21 schrieb Lars Kruse:

The maintained fork published seven releases (as of 2018), including
support for signed git tags (certainly a good thing).  The fork is a
drop-in replacement and keeps a compatibility link for the original
command ("bumpversion").

Maybe you want to consider packaging this fork in the future?


thank you for this suggestion and you are right, upstream looks dead to 
me. I will check if it makes sense to just switch the source tarball to 
bump2version and upload it to experimental.


I'll most likely remove the bump2version script entry point if the fork 
works as a drop-in replacement.


Expect an upload this week.

Regards,
Michael

Bug#914524: Forwarded upstream

[Jordi Mallach]

I have forwarded this upstream, here:

https://sogo.nu/bugs/view.php?id=4625

-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/


signature.asc
Description: PGP signature

Bug#916675: tracker.debian.org: Please show info from ftp.debian.org bugs

[Raphael Hertzog]

On Tue, 18 Dec 2018, Uwe Kleine-König wrote:
> > This is already the case. Here's a current example:
> > https://tracker.debian.org/pkg/janest-core
> > 
> > => «  RM: This package has been requested to be removed. »
> 
> then I wonder why it didn't show up for linux-igd. Even 12h after the RM
> request it wasn't notice

Distro Tracker fetches the data every 3 hours from
https://qa.debian.org/data/bts/wnpp_rm and that file seems to be updated
every hour.

The script data/bts/bts-wnpp_rm uses Devscripts::Debbugs::select to fetch
bug data.

In short, I have no idea what went wrong for this case. It might have been
a delay somewhere or Devscripts::Debbugs::select having a cache ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#916755: libcgroup1: cgrulesengd is not moving all threads to the configured cgroup

[Georgi Nikolov]

Package: libcgroup1
Version: 0.41-8+deb9u1
Severity: important

Dear Maintainer,

The cgrulesengd is moving only the thread with the same PID/TID to the
cgroup set on /etc/cgrules.conf. That is a problem because
the process is not completely moved to a cgroup, but only the fisrt thread
of the process.

There is same bug in redhat, which is resolved - 
https://bugzilla.redhat.com/show_bug.cgi?id=1284495.
I build package with redhat patch and seems to move all threads to 
configured cgroup. See attached patch.

Would you include provided patch in debian version of package.

Regards,
-- Georgi Nikolov
>From c9d651cfd532da6494dab03190c0a207cdf7289c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nikola=20Forr=C3=B3?= 
Date: Mon, 23 Jul 2018 17:38:26 +0200
Subject: [PATCH] api.c: always move all tasks of a process to a cgroup

---
 src/api.c | 40 ++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/api.c b/src/api.c
index 803ff35..a2cf981 100644
--- a/src/api.c
+++ b/src/api.c
@@ -3184,7 +3184,12 @@ int cgroup_change_cgroup_path(const char *dest, pid_t pid,
 const char *const controllers[])
 {
 	int ret;
+	int nr;
 	struct cgroup cgroup;
+	DIR *dir;
+	struct dirent *task_dir = NULL;
+	char path[FILENAME_MAX];
+	pid_t tid;
 
 	if (!cgroup_initialized) {
 		cgroup_warn("Warning: libcgroup is not initialized\n");
@@ -3195,11 +3200,42 @@ int cgroup_change_cgroup_path(const char *dest, pid_t pid,
 	ret = cg_prepare_cgroup(&cgroup, pid, dest, controllers);
 	if (ret)
 		return ret;
-	/* Add task to cgroup */
+	/* Add process to cgroup */
 	ret = cgroup_attach_task_pid(&cgroup, pid);
-	if (ret)
+	if (ret) {
 		cgroup_warn("Warning: cgroup_attach_task_pid failed: %d\n",
 ret);
+		goto finished;
+	}
+
+	/* Add all threads to cgroup */
+	snprintf(path, FILENAME_MAX, "/proc/%d/task/", pid);
+	dir = opendir(path);
+	if (!dir) {
+		last_errno = errno;
+		ret = ECGOTHER;
+		goto finished;
+	}
+
+	while ((task_dir = readdir(dir)) != NULL) {
+		nr = sscanf(task_dir->d_name, "%i", &tid);
+		if (nr < 1)
+			continue;
+
+		if (tid == pid)
+			continue;
+
+		ret = cgroup_attach_task_pid(&cgroup, tid);
+		if (ret) {
+			cgroup_warn("Warning: cgroup_attach_task_pid failed: %d\n",
+	ret);
+			break;
+		}
+	}
+
+	closedir(dir);
+
+finished:
 	cgroup_free_controllers(&cgroup);
 	return ret;
 }
-- 
2.17.1

Bug#727170: closed by Bart Martens (closing RFP: lua-alien -- Pure Lua extensions)

[Mattia Rizzolo]

On Thu, Dec 06, 2018 at 08:27:09PM +0100, Axel Beckert wrote:
> Bart, when do you finally stop messing around with bug reports you
> have no idea of (and probably have never read)?!?

Well, I'm often quite glad those cronjob exists, as they have closed a
ton of totally stalled requests over the years.

They might need some tuning, but they are mostly sane, IMHO.  In this
particular case, it closed a RFP that had no messages over 5 years,
which is fine IMHO.

> This time Cc'ing the MIA team since you haven't reacted on _any_ of my
> probably dozens of complaints in the past few years

He already is in the MIA list of people to poke at…

> MIA team: In case Bart doesn't reply at all (what I expect given my
> experience so far) and gets removed, please make sure that _all_ his
> obviously unmonitored-running cron-jobs on qa.debian.org get
> deactivated rather quickly. TIA!

I think that if that was going to happen I would be taking over those
cron jobs, so you might want to instaed state your case better.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#916756: geeqie: fullscreen spanning multiuple monitors does not work

[Jiri Bohac]

Package: geeqie
Version: 1:1.3-1+b1
Severity: important
Tags: patch upstream

Dear Maintainer,

geeqie support for fullscreen spanning all monitors is broken since
jessie.

I reported the bug upstream and provided a patch.
https://github.com/BestImageViewer/geeqie/issues/650

Trouble is the patch only works if geeqie is compiled with GTK3, so for
Debian, either a GTK2 backport of the patch would be needed or geeqie
would have to be switched to GTK3 (bug 904976).

We use geeqie for stereoscopic projections with two projectors and
without working multi-monitor fullscreen, geeqie is unusable.

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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.3-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u3
ii  libcairo21.14.8-1
ii  libexiv2-14  0.25-3.1+deb9u1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libjpeg62-turbo  1:1.5.1-2
ii  liblcms2-2   2.8-4+deb9u1
ii  liblirc-client0  0.9.4c-9
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libstdc++6   6.3.0-18+deb9u1
ii  libtiff5 4.0.8-2+deb9u4

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.1-8+deb9u2
ii  exiftran 2.10-2+b3
ii  exiv20.25-3.1+deb9u1
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u6
ii  librsvg2-common  2.40.16-1+b1
ii  ufraw-batch  0.22-1.1
ii  zenity   3.22.0-1+b1

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.8.18-1+deb9u1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.1-2
pn  ufraw
pn  xpaint   

-- no debconf information

Bug#916757: [20181218] mirror.sjc02.svwh.net: sync script

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi!

it seems mirror.sjc02.svwh.net is not using the recommended sync script
to mirror debian, ftpsync.

This causes an inconsistent mirror during updates, please start using
ftpsync.

  http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz


Using a modern ftpsync ensures updates are done in the correct order so
apt clients don't get confused.   In particular, it processes
translations, contents, and more files that have been added to the
archive in recent years in the correct stage.  It also should produce
trace files that contain more information that is useful for us and
helps downstream mirrors sync better.

Also, please don't use a round-robin-rotation as upstream mirror and
instead pick a good, fixed one.

Also see https://etherpad.wikimedia.org/p/debian-mirror

Cheers,

Bug#911610: eldav: files missing after upgrade from stretch: /usr/share/emacs/site-lisp/eldav/{,vc-}eldav.el

[Tatsuya Kinoshita]

Control: notfound -1 10.8+0.20120427-16
Control: found -1 10.8+0.20120427-17

On December 17, 2018 at 11:22PM +0100, anbe (at debian.org) wrote:
> Followup-For: Bug #911610
> Control: found -1 10.8+0.20120427-16
>
> I've also observed this behavior (i.e. lost files in some package, e.g.
> eldav) in stretch, so it's probably apel there, too.

I think apel 10.8+0.20120427-16 in stretch is fine, because the
`emacs` flavor is skipped in the emacsen-install script.

The problem is caused when unversioned emacs flavor (emacs >=
1:25.2+1-7) and apel 10.8+0.20120427-17 or -18 are installed.

Please tell me the details if you really think apel
10.8+0.20120427-16 is problematic.

Thanks,
--
Tatsuya Kinoshita


pgpAqpsqjaj8E.pgp
Description: PGP signature

Bug#916758: emacs: please add transitional packages for emacs21{,-nox},emacs22{,-gtk,-nox}

[Andreas Beckmann]

Source: emacs
Version: 1:25.2+1-11
Severity: normal

These were additional emacs variants available in lenny that may have
survived upgrading on a long-grown system.

I'm doing piuparts tests simulating such long grown systems locally and
would expect to find some ancient packages that break once a modern
emacs gets installed. So we would generate a list of Breaks against
cruft packages that would need to be added to the appropriate modern
emacs package.


Andreas

Bug#916759: RM: emacs25 -- RoM; superseded by src:emacs

[Andreas Beckmann]

Source: emacs25
Version: 25.2+1-6
Severity: normal

Hi,

src:emacs25 seems to be a cruft package that should be removed from
unstable. If you agree, please reassign this bug to ftp.debian.org

anbe@coccia:~$ dak rm -Rn  emacs25
Will remove the following packages from unstable:

   emacs25 |   25.2+1-2 | source
   emacs25 |   25.2+1-6 | source
emacs25-bin-common |   25.2+1-2 | hurd-i386
emacs25-bin-common | 25.2+1-6+b2 | arm64, kfreebsd-amd64, kfreebsd-i386
emacs25-bin-common | 25.2+1-6+b3 | amd64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
emacs25-common |   25.2+1-2 | all
emacs25-common |   25.2+1-6 | all
emacs25-dbg |   25.2+1-2 | hurd-i386
emacs25-dbg | 25.2+1-6+b2 | arm64, kfreebsd-amd64, kfreebsd-i386
emacs25-dbg | 25.2+1-6+b3 | amd64, armel, armhf, i386, mips, mips64el, mipsel, 
ppc64el, s390x
emacs25-el |   25.2+1-2 | all
emacs25-el |   25.2+1-6 | all
emacs25-lucid-dbg |   25.2+1-2 | hurd-i386
emacs25-lucid-dbg | 25.2+1-6+b2 | arm64, kfreebsd-amd64, kfreebsd-i386
emacs25-lucid-dbg | 25.2+1-6+b3 | amd64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x
emacs25-nox-dbg |   25.2+1-2 | hurd-i386
emacs25-nox-dbg | 25.2+1-6+b2 | arm64, kfreebsd-amd64, kfreebsd-i386
emacs25-nox-dbg | 25.2+1-6+b3 | amd64, armel, armhf, i386, mips, mips64el, 
mipsel, ppc64el, s390x

Please take a look at the bugs filed against emacs25-common and 
emacs25-el and reassign them to the corresponding packages from
src:emacs if they are still relevant.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=emacs25


Andreas

Bug#916762: ITP: ruby-raabro -- A very dumb PEG parser library

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name: ruby-raabro
  Version : 1.1.6
  Upstream Author : John Mettraux 
* URL : https://github.com/floraison/raabro
* License : Expat
  Programming Lang: Ruby
  Description : A very dumb PEG parser library

Raabro is a very dumb PEG parser library, with a horrible interface.
It is a son to aabro, grandson to neg, grand-grandson to parslet.

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

Thanks,
Utkarsh Gupta

Bug#915509: scala ftbfs: The repository system could not be initialized

[Emmanuel Bourg]

Control: reassign -1 libaether-ant-tasks-java
Control: affects -1 src:scala
Control: severity -1 important

This is actually an issue with libaether-ant-tasks-java, the classpath
of aether-ant-tasks.jar is missing slf4j-api.jar. This issue was
probably triggered by the update of Maven to the version 3.6.

Emmanuel Bourg

Bug#916761: deepin-icon-theme: fails to install: update-alternatives: error: alternative path /usr/share/icons/deepin/cursor.theme doesn't exist

[Andreas Beckmann]

Package: deepin-icon-theme
Version: 15.12.67-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 deepin-icon-theme (15.12.67-1) ...
  update-alternatives: error: alternative path 
/usr/share/icons/deepin/cursor.theme doesn't exist
  dpkg: error processing package deepin-icon-theme (--configure):
   installed deepin-icon-theme package post-installation script subprocess 
returned error exit status 2
  Errors were encountered while processing:
   deepin-icon-theme


cheers,

Andreas


deepin-icon-theme_15.12.67-1.log.gz
Description: application/gzip

Bug#916760: emacs: please enable systemd socket activation support

[Ansgar Burchardt]

Package: emacs
Version: 1:26.1+1-1
Severity: normal

Hi,

emacs26 added support for systemd socket activation (which I'm looking
forward to use).  However looking at the buildd log it seems this
isn't enabled:

+---
|   Does Emacs use -lsystemd?   no
+---[ 
https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=amd64&ver=1%3A26.1%2B1-1&stamp=1545095253&raw=0
 ]

It might be enough to just add a build-dep on libsystemd-dev.

(It's fine for me to not ship systemd units for this, but I would like
to at least not have to rebuild emacs.)

Ansgar

Bug#913921: Please consider linking against prce2

[Laurent Bigonville]

On Sat, 17 Nov 2018 02:22:59 +0100 Michael Biebl  wrote:
>
> Hi,
>
> pcre2 is the successor of pcre.
> Afaics, libselinux allows linking against pcre2 instead of pcre.
> Please consider switching it over to the newer version of the library.
>
> Build-tested patch is attached.

Would that means that you'll enable regex support in journald :)

That would made pcre2 pseudo-essential, note that the last essential 
package to use pcre (version 1) is grep. Also, libpcre2 libraries are 
located in /usr/lib and not /lib, debian is not supporting late mounting 
/usr for a few releases but that still needs to be noted somewhere.


We also need to keep in mind that the compiled file context files will 
not be architecture agnostic anymore, but libselinux should be smart 
enough to ignore these files if their architecture is not matching (ie. 
in multi-arch case). Unlike on RHEL/Fedora, these files are generated on 
the machine instead of shipped in a (noarch/arch:all) package so I don't 
think we need to change anything on how they are handled. (See: 
https://janzarskyblog.wordpress.com/2017/09/06/why-we-dont-need-to-ship-file_contexts-bin-with-selinux-policy/). 
So for me that should be fine.


I'll still try to do some benchmarking

Bug#904976: fullscreen bug with gtk3-only fix

[Jiri Bohac]

I now reported the above-mentioned fullscreen bug
(where only a GTK3 fix is available so far):
#916756

-- 
Jiri Bohac 
e-mail/jabber: j...@boha.cz

Bug#905342: it seems new kernel solved the problem

[Ivan Sergio Borgonovo]

Hi,

just updated the kernel (4.19.9-1) and it seems services start much 
faster now.


thanks

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#913635: php7.3-common: Repeatable segfault in php7.3 when running Cacti poller since upgrade to 7.3

[Ondřej Surý]

In that case, I would advise you to fill a bug directly with upstream 
developers at bugs.php.net.

I can do it for you, but usually it’s better if the person affect education by 
the bug do the filling for more swift communication.

Please report the PHP bug number back here.

Ondřej 
--
Ondřej Surý 

> On 18 Dec 2018, at 10:08, Jarno Paananen  wrote:
> 
> No change unfortunately:
> 
> [Tue Dec 18 11:05:02 2018] php[9750]: segfault at 7f202cc005cc ip
> 5623a9a38dda sp 7ffcbeeeb7b0 error 4 in php7.3[5623a9891000+25f000]
> 
> -- 
> 
> // Jarno
> 

Bug#911610: eldav: files missing after upgrade from stretch: /usr/share/emacs/site-lisp/eldav/{,vc-}eldav.el

[Andreas Beckmann]

On 2018-12-18 10:57, Tatsuya Kinoshita wrote:
>> I've also observed this behavior (i.e. lost files in some package, e.g.
>> eldav) in stretch, so it's probably apel there, too.
> 
> I think apel 10.8+0.20120427-16 in stretch is fine, because the
> `emacs` flavor is skipped in the emacsen-install script.
> 
> The problem is caused when unversioned emacs flavor (emacs >=
> 1:25.2+1-7) and apel 10.8+0.20120427-17 or -18 are installed.
> 
> Please tell me the details if you really think apel
> 10.8+0.20120427-16 is problematic.
OK, I'll rerun some tests and check again. Maybe repeat this after apel
migrated to testing.


Andreas

Bug#913921: Please consider linking against prce2

[Michael Biebl]

Am 18.12.2018 um 11:28 schrieb Laurent Bigonville:
> On Sat, 17 Nov 2018 02:22:59 +0100 Michael Biebl  wrote:
>>
>> Hi,
>>
>> pcre2 is the successor of pcre.
>> Afaics, libselinux allows linking against pcre2 instead of pcre.
>> Please consider switching it over to the newer version of the library.
>>
>> Build-tested patch is attached.
> 
> Would that means that you'll enable regex support in journald :)

I don't want two libprcre libraries in the essential set. So if we
switch libselinux, then yes, I have no objections to enable regex
support in journald.

> That would made pcre2 pseudo-essential, note that the last essential
> package to use pcre (version 1) is grep. 

Simon has done some bug filing here. I guess you are aware of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907652
Santiago, what's the state of this bug report?

Also, libpcre2 libraries are
> located in /usr/lib and not /lib, debian is not supporting late mounting
> /usr for a few releases but that still needs to be noted somewhere.

That late-mounting /usr is no longer supported has already been
documented in the (stretch I think) release notes.


Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#916689: systemd: login at console hangs after "Last login..." displayed, ssh hangs as well

[Raphael Manfredi]

Quoting Michael Biebl:
: What happens if you boot into emergency mode (add emergency to the
: kernel command line)?
: This will start a very minimal system without any networking or started
: services. Can you successfully login?
: 
: What happens if you boot into rescue mode (add rescue to the kernel
: command line)?
: This will boot into a minimal system with a few services like
: networking.service enabled.
: 
: What's the output of "ip a" in this case?

In emergency mode, no network, as expected:

$ cat /root/ip.a-emergency
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether 74:d0:2b:9d:5e:e4 brd ff:ff:ff:ff:ff:ff

In resue mode, NO NETWORK!

$ cat /root/ip.a-rescue
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether 74:d0:2b:9d:5e:e4 brd ff:ff:ff:ff:ff:ff

I understand this is not the expected situation, but how is systemd
configuring my network?  Who handles the /etc/network/interfaces file?

My /etc/default/networking file (as processed by /etc/init.d/networking
with sysvinit) is:

$ cat /etc/default/networking
# Configuration for networking init script being run during
# the boot sequence

# Set to 'no' to skip interfaces configuration on boot
#CONFIGURE_INTERFACES=yes

# Don't configure these interfaces. Shell wildcards supported/
#EXCLUDE_INTERFACES=

# Set to 'yes' to enable additional verbosity
#VERBOSE=no

So, under systemd, how is network configuration in "rescue" mode
achieved?  If indeed my system is misconfigured, this could explain
the lockups with automount failing to access /usr/local.

And why, when booting is finished, is the network up correctly?

I see in "journactl -xb" output:

Dec 18 11:53:30 nice systemd[1]: Started Raise network interfaces.
-- Subject: Unit networking.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit networking.service has finished starting up.
-- 
-- The start-up result is done.
Dec 18 11:53:30 nice systemd[1]: Reached target Network.
-- Subject: Unit network.target has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit network.target has finished starting up.
-- 
-- The start-up result is done.

I did not check whilst in rescue mode what was the output of that,
unfortunately.  But the network "target" is properly configuring
the network here, this is what I understand.

Raphael

Bug#916640: Changes to GAP necessary for sagemath

[Tobias Hansen]

On 12/17/18 10:28 PM, Bill Allombert wrote:
>
>>> Does that answer your questions ?
>>>
 +  * Install libgap to /usr/lib/triplet.
>>> Do you need this now ? When the interface to libgap has stabilized, then
>>> probably we will split libgap from gap-dev and move it to
>>> /usr/lib/triplet, but as long as it is an experimental feature it is
>>> best to keep it in a subdirectory.
>> I would prefer not having to apply yet another workaround to find this
>> library. It is possible though.
> Part of the issue is that we can little afford to go to the NEW queue to add
> extra binary packages if we want to be ready before the freeze.
> What do you suggest ?

If that saves us from going through NEW, I'm ok with leaving libgap in 
usr/lib/triplet/gap for now (assuming that we can get it to work that way).

>> Would you be ok with applying these two patches?
> I do not like the idea of applying SAGE-specific patches to /usr/bin/gap.
>
> However if we arrange for the patch to be applied only to libgap, then I
> am ready to apply whatever you need.
>
> Cheers,

Apart from libgap-api.h the two patches also add some lines to error.h, 
gapstate.h and gasman.h. How can we proceed? By adding a second copy of all 
headers to /usr/include/libgap in gap-dev?

Best,

Tobias

Bug#916689: systemd: login at console hangs after "Last login..." displayed, ssh hangs as well

[Michael Biebl]

Am 18.12.2018 um 12:09 schrieb Raphael Manfredi:
> Quoting Michael Biebl:
> : What happens if you boot into emergency mode (add emergency to the
> : kernel command line)?
> : This will start a very minimal system without any networking or started
> : services. Can you successfully login?
> : 
> : What happens if you boot into rescue mode (add rescue to the kernel
> : command line)?
> : This will boot into a minimal system with a few services like
> : networking.service enabled.
> : 
> : What's the output of "ip a" in this case?
> 
> In emergency mode, no network, as expected:
> 
>   $ cat /root/ip.a-emergency
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
> default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host 
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc noop state DOWN group default 
> qlen 1000
> link/ether 74:d0:2b:9d:5e:e4 brd ff:ff:ff:ff:ff:ff
> 
> In resue mode, NO NETWORK!
> 
>   $ cat /root/ip.a-rescue
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
> default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host 
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc noop state DOWN group default 
> qlen 1000
> link/ether 74:d0:2b:9d:5e:e4 brd ff:ff:ff:ff:ff:ff
> 
> I understand this is not the expected situation, but how is systemd
> configuring my network?  Who handles the /etc/network/interfaces file?

systemd is not configuring your network, ifupdown is in your case.
You use a type auto interface, so networking.service should be
responsible for that.
systemctl status networking.service should give you the state of this
service.

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



signature.asc
Description: OpenPGP digital signature

Bug#916764: znc-backlog: overly strict dependency on znc?

[Andreas Beckmann]

Package: znc-backlog
Version: 0.20170713-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

do you really need a dependency on the exact binary version of znc
available at the build time of znc-backlog? I.e., every time znc
gets uploaded *or binNMUed*, a binNMU of znc-backlog is needed, too.
Wouldn't a dependency computed from the upstream version be sufficient?
E.g. znc (>= ${znc:upstreamversion}), znc (<< ${znc:upstreamversion}+)


Andreas

Bug#916763: php-defaults: PHP 7.2 extensions no longer available

[Marek Dědič]

Source: php-defaults
Version: 68
Severity: important

Dear Maintainer,

I've recently tried to use a PHP application on my Debian Testing system, only
to find the PHP SOAP extension missing. I tried to install it as php7.2-soap,
which isn't available, and as php-soap, which forces me to install php 7.3.
After some digging I've found bug #911673 which I believe to be the cause of
this.

Does this mean that only 7.0 and 7.3 is now provided by debian (stable and
testing respectively)? Because one of them is EOL and the other one is 12 days
old as of writing this message - may I ask (as a complete novice to debian
development...), why should there be no middle ground between obsolete and
bleeding edge?

Many PHP packages are not yet ready for 7.3 (I know it shouldn't break
anything, but packages are packages...), so that forces people to use 7.0,
which isn't supported anymore...

Thanks,
Marek Dědič

P.S.: I am new to the Debian bug tracker, if I reported this to the wrong
package or somehow did it improperly, please do tell me.



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

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

Bug#915061: Why does Debian even change the version compared to upstream?

[Max Horn]

Hi,

I am one of the GAP developers, and just saw this report; and I'd like to ask 
something that has bothered me for a while: why does Debian change the upstream 
version at all? Why not use 4.9.3 as we use upstream, instead if 4r9r3? Note 
that GAP versions always used dots; it is true that years ago, the filenames of 
our tarballs used "r" instead of dots, but I don't see why that'd be a reason 
to keep using a version that is different from what GAP itself reports, what 
our documentation and websites use etc.

AFAICT, in Debian, 4r9 < 4.9 and so changing this wouldn't even require a new 
epoch.

Cheers,
Max

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Brian Potkin]

Package: cups-browsed
Version: 1.21.6-2
Severity: normal
Tags: upstream



cups-browsed.conf and a log are attached.

Whilst taking another look at #908573 the service fails to restart
when the only uncommented line for BrowseFilter has "pdl postscript".
journalctl shows

Dec 18 11:21:22 test systemd[1]: Started Make remote CUPS printers available 
locally.
Dec 18 11:21:22 test cups-browsed[1029]: double free or corruption (fasttop)
Dec 18 11:21:22 test systemd[1]: cups-browsed.service: Main process exited, 
code=killed, status=6/ABRT
Dec 18 11:21:22 test systemd[1]: cups-browsed.service: Failed with result 
'signal'.

I am fairly sure that I tested this BrowseFilter line when doing #908573
and it was working.

Regards,

Brian.
Tue Dec 18 11:21:22 2018 main() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 cups-browsed: Creating http connection to local CUPS 
daemon: /var/run/cups/cups.sock:631
Tue Dec 18 11:21:22 2018 update_netifs() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 network interface lo: Local host name/address: 
127.0.0.1
Tue Dec 18 11:21:22 2018 network interface lo: Local host name/address: 
localhost
Tue Dec 18 11:21:22 2018 network interface eth1: Local host name/address: 
192.168.7.66
Tue Dec 18 11:21:22 2018 network interface eth1: Local host name/address: 
test.lan
Tue Dec 18 11:21:22 2018 Network interface eth1 at 192.168.7.66 for legacy CUPS 
browsing/broadcasting
Tue Dec 18 11:21:22 2018 network interface lo: Local host name/address: ::1
Tue Dec 18 11:21:22 2018 network interface eth1: Local host name/address: 
fe80::219:d1ff:fe4d:2a70
Tue Dec 18 11:21:22 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
IPP-Create-Subscription
Tue Dec 18 11:21:22 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
subscription ID=626
Tue Dec 18 11:21:22 2018 cups-browsed (/var/run/cups/cups.sock): cupsEnumDests
Tue Dec 18 11:21:22 2018 Could not determine system default printer!
Tue Dec 18 11:21:22 2018 find_previous_queue() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 find_previous_queue() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Using signal handler SIGACTION
Tue Dec 18 11:21:22 2018 Avahi server connection got available, setting up 
service browsers.
Tue Dec 18 11:21:22 2018 listening
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'realq @ desktop' of type 
'_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'LaserJet-300 @ desktop' 
of type '_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'xxx @ desktop' of type 
'_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 
'josiecopierbackroom-duplex-booklet @ desktop' of type '_ipp._tcp' in domain 
'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 
'josiecopierbackroom-duplex-A4 @ desktop' of type '_ipp._tcp' in domain 'local' 
on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'CustomisedPrinting @ 
desktop' of type '_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'ENVY4500' of type 
'_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'Scanner on desktop' of 
type '_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'CustomisedPrinting @ 
desktop' of type '_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 
'josiecopierbackroom-duplex-A4 @ desktop' of type '_ipp._tcp' in domain 'local' 
on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 
'josiecopierbackroom-duplex-booklet @ desktop' of type '_ipp._tcp' in domain 
'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'LaserJet-300 @ desktop' 
of type '_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -1232143808
Tue Dec 18 11:21:22 2018 Avahi Browser: NEW: service 'realq @ desktop' of type 
'_ipp._tcp' in domain 'local' on interface 'eth1'
Tue Dec 18 11:21:22 2018 browse_callback() in THREAD -123214

Bug#916766: libucto3: missing Breaks+Replaces: libucto2

[Andreas Beckmann]

Package: libucto3
Version: 0.14-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Selecting previously unselected package libucto3:amd64.
  Preparing to unpack .../libucto3_0.14-1_amd64.deb ...
  Unpacking libucto3:amd64 (0.14-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libucto3_0.14-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/ucto/textcat.cfg', which is also in package 
libucto2:amd64 0.9.6-1+b1
  Errors were encountered while processing:
   /var/cache/apt/archives/libucto3_0.14-1_amd64.deb


cheers,

Andreas


libucto2=0.9.6-1+b1_libucto3=0.14-1.log.gz
Description: application/gzip

Bug#916767: python-dmidecode-data: missing Breaks+Replaces: python-dmidecode (<< 3.12.2-5)

[Andreas Beckmann]

Package: python-dmidecode-data
Version: 3.12.2-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../python-dmidecode-data_3.12.2-5_all.deb ...
  Unpacking python-dmidecode-data (3.12.2-5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-dmidecode-data_3.12.2-5_all.deb (--unpack):
   trying to overwrite '/usr/share/python-dmidecode/pymap.xml', which is also 
in package python-dmidecode 3.12.2-4
  Errors were encountered while processing:
   /var/cache/apt/archives/python-dmidecode-data_3.12.2-5_all.deb


cheers,

Andreas


python-dmidecode=3.12.2-4_python-dmidecode-data=3.12.2-5.log.gz
Description: application/gzip

Bug#916640: [Debian-science-sagemath] Status of sagemath?

[Tobias Hansen]

On 12/18/18 12:34 PM, E. Madison Bray wrote:
>
> Regarding the status of porting Sage to use GAP 4.10, I have been
> working on that, so here is a brief status update:  The port is almost
> ready from the Sage end of things, but it still required a number of
> patches to GAP.  I am working with the GAP developers to hopefully
> release a GAP 4.10.1 containing those patches, hopefully as soon as
> this week.  If/when that gets done, GAP 4.10.1 should be considered
> the first release with a truly "usable" libgap API, as what was
> available in 4.10.0 was not really ready for non-trivial use.
>
> If for some reason that release can't be made in time for Debian, the
> necessary patches can still applied to the Debian package for GAP if
> necessary.  I'm not sure exactly what the policy is on that, but these
> are not Sage-specific patches or anything like that, but rather they
> fix real bugs and shortcomings that made the libgap API not very
> usable.
>
> On the Sage end of things, Sage 8.5 will be released very soon, and
> will *not* contain support for GAP 4.10.  I will push Volker to try to
> release a Sage 8.6 soon focused just on the GAP stuff; otherwise it
> will have to be applied to Sage 8.5 as a patch which I find
> unfortunate.  I'm going to see if I can push the Sage 8.5 release back
> but knowing Volker that might be impossible :(

Hi,

I followed the ticket. Thanks a lot for making this a priority for us! That was 
certainly a bunch of work.

I already applied your patches to gap 4.10 and sage 8.4 to do test builds and 
it works fine. At the moment we are discussing with the gap package maintainer 
Bill Allombert how we can get the patches to gap available in Debian in time 
for the freeze. See the bug report [1] which is also in CC. If gap 4.10.1 would 
have the patches and would come in time that would be great!

Can you comment on whether the writeandcheck.patch is strictly required? We 
didn't have it before and without it I don't get any additional test failures 
in sage.

Best,

Tobias

[1] https://bugs.debian.org/916640

Bug#916768: libelogind-dev-doc: missing Breaks+Replaces: libelogind-dev (<< 239.1+20181115-1)

[Andreas Beckmann]

Package: libelogind-dev-doc
Version: 239.3-3+debian1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../libelogind-dev-doc_239.3-3+debian1_all.deb ...
  Unpacking libelogind-dev-doc (239.3-3+debian1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libelogind-dev-doc_239.3-3+debian1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man3/sd-bus.3.gz', which is also in 
package libelogind-dev:amd64 239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libelogind-dev-doc_239.3-3+debian1_all.deb


cheers,

Andreas

PS: please use a normal debian revision in the version, i.e. only number


libelogind-dev=239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1_libelogind-dev-doc=239.3-3+debian1.log.gz
Description: application/gzip

Bug#916769: mmdebstrap: fails cleanup when making a buster chroot from a stretch system

[Helmut Grohne]

Package: mmdebstrap
Version: 0.3.0-10
Severity: wishlist

Hi Josch,

If you backport mmdebstrap to stretch (yes, that's relatively easy after
downgrading debhelper compatibility and dependency), you can observe the
following interaction:

# grep VERSION_ID /etc/os-release 
VERSION_ID="9"
# mmdebstrap buster /target
I: automatically chosen mode: root
I: chroot architecture amd64 is equal to the host's architecture
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
I: cleaning package lists and apt cache...
done
Reading package lists...
W: Problem unlinking the file auxfiles - Clean (21: Is a directory)
apt-get --option Dir::Etc::SourceList=/dev/null update failed at
/usr/bin/mmdebstrap line 569.
# echo $?
1
#

I guess this is due to some interaction between stretch's apt and
buster's apt. The resulting chroot looks like it works otherwise. If you
don't want to diagnose this, please just close it as wontfix. I can
fully understand that.

Helmut

Bug#916770: biometric-auth: unowned files after purge (policy 6.8, 10.8): /etc/biometric-auth/biometric-drivers.conf

[Andreas Beckmann]

Package: biometric-auth
Version: 0.9.61-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-removal-and-or-configuration-purging

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

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

0m55.1s ERROR: FAIL: Package purging left files on system:
  /etc/biometric-auth/biometric-drivers.conf not owned


cheers,

Andreas


biometric-auth_0.9.61-2.log.gz
Description: application/gzip

Bug#906098: kde-telepathy-text-ui: Invisible characters in the chat window: File not found error message (html url encoded) in textbox.

[Vassilis Virvilis]

Hi this bug is apparently fixed in 18.0.4
See here:https://bugs.kde.org/show_bug.cgi?id=397369

Is there any idea when Debian will upgrade to 18.0.4 ?

Is something blocking it?

-- 
Vassilis Virvilis

Bug#916772: pkg-config: missing Depends: dpkg-dev

[Helmut Grohne]

Package: pkg-config
Version: 0.29-4+b1
Severity: serious
Justification: missing dependency

# i686-linux-gnu-pkg-config --libs libssl
Package libssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `libssl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libssl' found
# ls /usr/lib/i386-linux-gnu/pkgconfig/libssl.pc 
/usr/lib/i386-linux-gnu/pkgconfig/libssl.pc
# apt -y install dpkg-dev
...
# i686-linux-gnu-pkg-config --libs libssl
-lssl
#

In this case, i686-linux-gnu-pkg-config is a symlink to
/usr/share/pkg-config-crosswrapper and that script has the following
line:

  multiarch="`dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH 
2>/dev/null`"

It calls dpkg-architecture (which is in dpkg-dev) and igores all errors.
In the absence of dpkg-architecture, the result will be empty and
pkg-config doesn't work.

If adding dpkg-dev to Depends is not desired, the cross-wrapper could be
extended to give a useful error message in case $multiarch is empty:

--- /usr/share/pkg-config-crosswrapper
+++ /usr/share/pkg-config-crosswrapper
@@ -11,6 +11,10 @@
   triplet="${basename%-pkg-config}"
   # Normalized multiarch path if any, e.g. i386-linux-gnu for i386
   multiarch="`dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH 
2>/dev/null`"
+  if test "$?" != 0; then
+echo "Please apt install dpkg-dev to use this program." 1>&2
+exit 1
+  fi
   # Native multiarch path
   native_multiarch="$(cat /usr/lib/pkg-config.multiarch)"
 

dpkg-dev should be added to Recommends in that case.

Helmut

Bug#916771: radicale: systemd unit proposal

[Francisco Romero]

Source: radicale
Version: 1.1.1+20160115-4
Severity: normal

Package: radicale
Version: 1.1.1+20160115-4

I have created a systemd unit for radicale that works in debian stretch.

This is my proposal:

[Unit]
Description=A simple CalDAV (calendar) and CardDAV (contact) server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/radicale
WorkingDirectory=/etc/radicale
Restart=on-failure
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=multi-user.target

I needed a log file to work: /var/log/radicale/radicale.log.



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

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

Bug#915781: closed by Thomas Goirand (Bug#915781: fixed in openstack-cluster-installer 15)

[Andreas Beckmann]

Control: found -1 15

On 2018-12-12 14:09, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the openstack-cluster-installer package:
> 
> #915781: openstack-cluster-installer: unowned directories after purge: 
> /etc/openstack-cluster-installer/hiera/*/, /var/lib/oci/*/

/var/log/oci/ is still there ...


Andreas

Bug#916640: [Debian-science-sagemath] Status of sagemath?

[E. Madison Bray]

On Tue, Dec 18, 2018 at 1:12 PM Tobias Hansen  wrote:
>
> On 12/18/18 12:34 PM, E. Madison Bray wrote:
> >
> > Regarding the status of porting Sage to use GAP 4.10, I have been
> > working on that, so here is a brief status update:  The port is almost
> > ready from the Sage end of things, but it still required a number of
> > patches to GAP.  I am working with the GAP developers to hopefully
> > release a GAP 4.10.1 containing those patches, hopefully as soon as
> > this week.  If/when that gets done, GAP 4.10.1 should be considered
> > the first release with a truly "usable" libgap API, as what was
> > available in 4.10.0 was not really ready for non-trivial use.
> >
> > If for some reason that release can't be made in time for Debian, the
> > necessary patches can still applied to the Debian package for GAP if
> > necessary.  I'm not sure exactly what the policy is on that, but these
> > are not Sage-specific patches or anything like that, but rather they
> > fix real bugs and shortcomings that made the libgap API not very
> > usable.
> >
> > On the Sage end of things, Sage 8.5 will be released very soon, and
> > will *not* contain support for GAP 4.10.  I will push Volker to try to
> > release a Sage 8.6 soon focused just on the GAP stuff; otherwise it
> > will have to be applied to Sage 8.5 as a patch which I find
> > unfortunate.  I'm going to see if I can push the Sage 8.5 release back
> > but knowing Volker that might be impossible :(
>
> Hi,
>
> I followed the ticket. Thanks a lot for making this a priority for us! That 
> was certainly a bunch of work.
>
> I already applied your patches to gap 4.10 and sage 8.4 to do test builds and 
> it works fine. At the moment we are discussing with the gap package 
> maintainer Bill Allombert how we can get the patches to gap available in 
> Debian in time for the freeze. See the bug report [1] which is also in CC. If 
> gap 4.10.1 would have the patches and would come in time that would be great!

Thanks, that's great that you're on top of it.

> Can you comment on whether the writeandcheck.patch is strictly required? We 
> didn't have it before and without it I don't get any additional test failures 
> in sage.

I believe it is necessary but I will double-check.  It's not that
there is specific functionality in Sage that depends on it, but it is
a pretty bad bug that I know can impact Sage.  However, there are some
problems with the current form of the patch as discussed here:
https://github.com/gap-system/gap/pull/3102

I have an idea for a much simpler version of the patch which has fewer
problems that I will try to post shortly.

Bug#916699: Run minissdpd debconf question insufficiently detailed for an advanced user to answer it

[Julien Cristau]

Control: severity -1 serious

On Mon, Dec 17, 2018 at 10:37:05AM -0500, Sam Hartman wrote:
> package: minissdpd
> version: 1.5.20180223-3
> 
> Hi.  Minissdpd got pulled in on an upgrade from stretch to buster by
> something--I haven't bothered to check why.  I have my debconf priority
> set to medium and I got asked whether I wanted to start minissdpd
> automatically.
> That's fine: I asked for more questions and I got them.
> However, the question didn't explain what minissdpd was, why I might
> want it, and on a typical system what the consequences of not running it
> might be.
> 
> You need to write debconf questions targeted both at someone who
> explicitly asks for your package and that roughly knows what it is as
> well as for someone who gets a package pulled in by someone else.  I'm a
> fairly advanced user; I know what UPNP is c.  So, I'm not asking you to
> make a medium/low priority question something a novice user could
> answer, but I am asknig you to include enough detail that I can probably
> answer it and definitely know what to google.
> It wasn't even clear that the question was from the minissdpd package.
> 
It looks like minissdpd is installed on a default stretch desktop
(presumably because it was then recommended by libminiupnpc10 /
miniupnpc).  Then on upgrade, the new version asks questions at high
priority that very much don't belong there.

Upgrading severity as this needs to be fixed before buster ships, by
reducing the priority and/or rewording to make it understandable (I
would say at least the former, and preferrably both).

Cheers,
Julien

Bug#916773: r-base: CRAN packages fail to install.

[Emmanuel Charpentier]

Package: r-base
Version: 3.5.1.20181215-1
Severity: important

Dear Maintainer,

Please note that I report this bug against r-base because this is where I got
the symptoms. However, I am almost certain that the problem is somewhere
in glibc (see below "Further note").

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

   * What led up to the situation?

On a Debian testing system, routine update of systemwide hand-installed CRAN
packages :
  - sudo -i
  - R
* > setRepositories() ## I use CRAN and BioC software
* > update.packages(ask=FALSE, checkBuilt=TRUE, lib="/usr/lib/R/library/")
* > update.packages(ask=FALSE, checkBuilt=TRUE, lib="/usr/lib/R/site-
library/")
* > update.packages(ask=FALSE, checkBuilt=TRUE)"

This one fails, with a reproducible error :

I can reproduce this failure by removing the stale lock file and retrying
to install brms :
---
> install.packages("brms")
Installation du package dans ‘/usr/local/lib/R/site-library’
(car ‘lib’ n'est pas spécifié)
essai de l'URL 'https://cloud.r-project.org/src/contrib/brms_2.7.0.tar.gz'
Content type 'application/x-gzip' length 3818402 bytes (3.6 MB)
==
downloaded 3.6 MB

* installing *source* package ‘brms’ ...
** package ‘brms’ correctement décompressé et sommes MD5 vérifiées
** R
terminate called after throwing an instance of 'std::runtime_error'
  what():  Mutex creation failed
Aborted

Les packages source téléchargés sont dans
‘/tmp/RtmpRf29DO/downloaded_packages’
Warning message:
In install.packages("brms") :
  l'installation du package ‘brms’ a eu un statut de sortie non nul
---


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

  - Retrying the installation
  - Upgrading from r-base-3.5.1-2 (IIRC) to 3.5.1-20181215 from unstable

   * What was the outcome of this action?

Both attempts were ineffective.

   * What outcome did you expect instead?

A normal upgrade of brms.

Further note :
==

Googling for "R  what():  Mutex creation failed" gives a raft of bug
reports in various distributions and source Github repositories issues,
which have in common to point, after various discussions, to glibc 2.28...
which happens to be the current version in testing. Some of them also point
to C++ 11 functionality of gcc (but I am out of my depth here and do not really
understand this part of the issue).

Ouch.

I found no usable suggestion of workaround. Such a suggestion would be welcome
:
  - brms is the bread and butter of Bayesian regression models. Missing it
is seriously annoying
  - this failure seems to be much more general than R, and may impact other
vital
functionality.



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

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

Versions of packages r-base depends on:
ii  r-base-core3.5.1.20181215-1
ii  r-recommended  3.5.1.20181215-1

Versions of packages r-base recommends:
ii  r-base-html  3.5.1-2
ii  r-doc-html   3.5.1.20181215-1

Versions of packages r-base suggests:
pn  ess 
ii  r-doc-info  3.5.1.20181215-1

-- no debconf information

Bug#916774: linux-perf metapackage fails to upgrade due to file conflict between linux-perf-4.18 & linux-perf-4.19

[Paul Wise]

Package: linux-perf-4.19
Version: 4.19.9-1
Severity: serious

I had the linux-perf metapackage fail to upgrade due to a file conflict
between linux-perf-4.18 & linux-perf-4.19:

$ sudo apt install -t unstable linux-perf
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-perf-4.18
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  linux-perf-4.19
Suggested packages:
  linux-doc-4.19
The following NEW packages will be installed:
  linux-perf-4.19
The following packages will be upgraded:
  linux-perf
1 upgraded, 1 newly installed, 0 to remove and 338 not upgraded.
Need to get 0 B/1,491 kB of archives.
After this operation, 6,614 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Reading changelogs... Done
Selecting previously unselected package linux-perf-4.19.
(Reading database ... 456870 files and directories currently installed.)
Preparing to unpack .../linux-perf-4.19_4.19.9-1_amd64.deb ...
Unpacking linux-perf-4.19 (4.19.9-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/linux-perf-4.19_4.19.9-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/perf/examples/bpf/5sec.c', which is also in 
package linux-perf-4.18 4.18.20-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../linux-perf_4.19+101_all.deb ...
Unpacking linux-perf (4.19+101) over (4.18+100) ...
Errors were encountered while processing:
 /var/cache/apt/archives/linux-perf-4.19_4.19.9-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

$ echo $?
100

$ sudo dpkg --force-all --purge linux-perf-4.18
(Reading database ... 456869 files and directories currently installed.)
Removing linux-perf-4.18 (4.18.20-2) ...
Processing triggers for man-db (2.8.4-3) ...

$ sudo apt --fix-broken install -t unstable 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  linux-perf-4.19
Suggested packages:
  linux-doc-4.19
The following NEW packages will be installed:
  linux-perf-4.19
0 upgraded, 1 newly installed, 0 to remove and 338 not upgraded.
1 not fully installed or removed.
Need to get 0 B/1,484 kB of archives.
After this operation, 6,614 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Selecting previously unselected package linux-perf-4.19.
(Reading database ... 45 files and directories currently installed.)
Preparing to unpack .../linux-perf-4.19_4.19.9-1_amd64.deb ...
Unpacking linux-perf-4.19 (4.19.9-1) ...
Setting up linux-perf-4.19 (4.19.9-1) ...
Processing triggers for man-db (2.8.4-3) ...
Setting up linux-perf (4.19+101) ...

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages linux-perf-4.19 depends on:
ii  libbabeltrace1  1.5.6-2
ii  libc6   2.28-2
ii  libdw1  0.175-1
ii  libelf1 0.175-1
ii  liblzma55.2.2-1.3
ii  libnuma12.0.12-1
ii  libperl5.28 5.28.1-3
ii  libpython3.73.7.2~rc1-1
ii  libslang2   2.3.2-1+b1
ii  libunwind8  1.2.1-8
ii  perl5.28.1-3
ii  python3 3.6.7-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages linux-perf-4.19 recommends:
ii  linux-base  4.5

Versions of packages linux-perf-4.19 suggests:
pn  linux-doc-4.19  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#874487: Debian mirror mirrors.gigenet.com: missing-tracefile, syncscript

[Scott Ehas]

Hello Peter,

We have updated the ftpsync.conf, and have reconfigured the cronjob.  I'll
check in a few hours to see if the sync has finished.

00 03 * * * /opt/debiansync/bin/ftpsync sync:all
00 06 * * * /opt/debiansync/bin/ftpsync sync:all
00 12 * * * /opt/debiansync/bin/ftpsync sync:all
00 21 * * * /opt/debiansync/bin/ftpsync sync:all

[root@MSRV001 log]# cat ../etc/ftpsync.conf
MIRRORNAME="mirrors.gigenet.com"
TO="/volume0/mirrors/debian"
RSYNC_PATH="debian"
RSYNC_HOST=debian.csail.mit.edu
LOGDIR="${BASEDIR}/log"
EXCLUDE=""
ARCH_INCLUDE="armhf source amd64 i386 all"

On Tue, Dec 18, 2018 at 4:09 AM Peter Palfrader  wrote:

> ping?
>
> On Tue, 11 Dec 2018, Peter Palfrader wrote:
>
> > On Mon, 10 Dec 2018, Scott Ehas wrote:
> >
> > > We performed an entirely new sync, and I haven't found any errors
> within
> > > the ftpsync logs.  Can you confirm everything is correct?
> >
> > http://mirrors.gigenet.com/debian/project/trace/mirrors.gigenet.com
> > says it's from Saturday, December 8.
> >
> > So the file has the right name now, but the sync is not happening
> > regularly (every 6 hours, 4 times a day).
> >
> > Further:
> > - looking at your arch list, you might want to move from an architecture
> >   EXCLUDE configuration to an INCLUDE configuration.
> > - You should probably not sync off an ftp.*.debian.org alias and
> >   probably not of a DNS rotation of several mirrors.  Pick one upstream.
> >
> >
> > Also cf
> >  -
> https://mirror-master.debian.org/status/mirror-info/mirrors.gigenet.com.html
> > Cheers,
> >
> > > > I started writing a new howto/guidelines in case that's helpful:
> > > >   https://etherpad.wikimedia.org/p/debian-mirror
> > --
> > |  .''`.   ** Debian **
> >   Peter Palfrader   | : :' :  The  universal
> >  https://www.palfrader.org/ | `. `'  Operating System
> > |   `-https://www.debian.org/
> >
>
> --
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
>

Bug#916775: mrtrix3: broken symlink: /usr/share/man/man1/mrview.1.gz -> mrtrix.1.gz

[Andreas Beckmann]

Package: mrtrix3
Version: 3.0~rc3+git86-g4b523b413-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m48.3s ERROR: FAIL: Broken symlinks:
  /usr/share/man/man1/mrview.1.gz -> mrtrix.1.gz (mrtrix3)


cheers,

Andreas


mrtrix3_3.0~rc3+git86-g4b523b413-1.log.gz
Description: application/gzip

Bug#916773: r-base: CRAN packages fail to install.

[Dirk Eddelbuettel]

On 18 December 2018 at 14:21, Emmanuel Charpentier wrote:
| Package: r-base
| Version: 3.5.1.20181215-1
| Severity: important
| 
| Dear Maintainer,
| 
| Please note that I report this bug against r-base because this is where I got
| the symptoms. However, I am almost certain that the problem is somewhere
| in glibc (see below "Further note").
| 
| *** Reporter, please consider answering these questions, where appropriate ***
| 
|* What led up to the situation?
| 
| On a Debian testing system, routine update of systemwide hand-installed CRAN
| packages :
|   - sudo -i
|   - R
| * > setRepositories() ## I use CRAN and BioC software
| * > update.packages(ask=FALSE, checkBuilt=TRUE, lib="/usr/lib/R/library/")
| * > update.packages(ask=FALSE, checkBuilt=TRUE, lib="/usr/lib/R/site-
| library/")
| * > update.packages(ask=FALSE, checkBuilt=TRUE)"
| 
| This one fails, with a reproducible error :
| 
| I can reproduce this failure by removing the stale lock file and retrying
| to install brms :
| ---
| > install.packages("brms")
| Installation du package dans ‘/usr/local/lib/R/site-library’
| (car ‘lib’ n'est pas spécifié)
| essai de l'URL 'https://cloud.r-project.org/src/contrib/brms_2.7.0.tar.gz'
| Content type 'application/x-gzip' length 3818402 bytes (3.6 MB)
| ==
| downloaded 3.6 MB
| 
| * installing *source* package ‘brms’ ...
| ** package ‘brms’ correctement décompressé et sommes MD5 vérifiées
| ** R
| terminate called after throwing an instance of 'std::runtime_error'
|   what():  Mutex creation failed
| Aborted
| 
| Les packages source téléchargés sont dans
| ‘/tmp/RtmpRf29DO/downloaded_packages’
| Warning message:
| In install.packages("brms") :
|   l'installation du package ‘brms’ a eu un statut de sortie non nul
| ---
| 
| 
|* What exactly did you do (or not do) that was effective (or
|  ineffective)?
| 
|   - Retrying the installation
|   - Upgrading from r-base-3.5.1-2 (IIRC) to 3.5.1-20181215 from unstable
| 
|* What was the outcome of this action?
| 
| Both attempts were ineffective.
| 
|* What outcome did you expect instead?
| 
| A normal upgrade of brms.
| 
| Further note :
| ==
| 
| Googling for "R  what():  Mutex creation failed" gives a raft of bug
| reports in various distributions and source Github repositories issues,
| which have in common to point, after various discussions, to glibc 2.28...
| which happens to be the current version in testing. Some of them also point
| to C++ 11 functionality of gcc (but I am out of my depth here and do not 
really
| understand this part of the issue).
| 
| Ouch.
| 
| I found no usable suggestion of workaround. Such a suggestion would be welcome
| :
|   - brms is the bread and butter of Bayesian regression models. Missing it
| is seriously annoying
|   - this failure seems to be much more general than R, and may impact other
| vital
| functionality.

There is nothing I can do for you here. If it is upstream in R, it is
upstream in R.

I didn't do anything R to prevent brms from working.

Dirk
 
 
 
| -- System Information:
| Debian Release: buster/sid
|   APT prefers testing
|   APT policy: (650, 'testing'), (60, 'unstable'), (50, 'stable')
| Architecture: amd64 (x86_64)
| Foreign Architectures: i386
| 
| Kernel: Linux 4.18.0-3-amd64 (SMP w/8 CPU cores)
| Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
| Shell: /bin/sh linked to /bin/dash
| Init: systemd (via /run/systemd/system)
| LSM: AppArmor: enabled
| 
| Versions of packages r-base depends on:
| ii  r-base-core3.5.1.20181215-1
| ii  r-recommended  3.5.1.20181215-1
| 
| Versions of packages r-base recommends:
| ii  r-base-html  3.5.1-2
| ii  r-doc-html   3.5.1.20181215-1
| 
| Versions of packages r-base suggests:
| pn  ess 
| ii  r-doc-info  3.5.1.20181215-1
| 
| -- no debconf information

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#916776: ITS: python-pyocr

[Thomas Perret]

Package: python-pyocr
Version: 0.3.0-1
Severity: important

Dear Paul,

I intent to take over and salvage python-pyocr according to Debian's
Developer's Reference chapter 5.12. 
I wrote you a few mails to ask if you're still interested in maintaining
this package but didn't got any reply.
There is a serious bug (#886306) which hasn't got any reply and since you're 
only
maintaining this package and you didn't had anyactivity in the last 3
years, I am also CCing Debian MIA team.
Several new versions have been released upstream and the upstream
repository has changed from github to GNOME's gitlab instance.
This package is one of the dependencies of a package I intent to package
(#721287).

According to the ITS process, I will wait for any objections during 21
days before uploading a new package into the DELAYED queue.

Best regards,
Thomas Perret


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

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

Versions of packages python-pyocr depends on:
ii  python  2.7.15-3
ii  python-pil  5.3.0-1

Versions of packages python-pyocr recommends:
ii  cuneiform  1.1.0+dfsg-7
ii  tesseract-ocr  4.0.0-1+b1

python-pyocr suggests no packages.

-- no debconf information

Bug#916777: activemq: broken symlinks: /usr/share/activemq/lib/{geronimo-jacc_1.1_spec,optional/{commons-httpclient,stax-api}}.jar

[Andreas Beckmann]

Package: activemq
Version: 5.15.8-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m53.7s ERROR: FAIL: Broken symlinks:
  /usr/share/activemq/lib/geronimo-jacc_1.1_spec.jar -> 
../../java/geronimo-jacc_1.1_spec.jar (activemq)
  /usr/share/activemq/lib/optional/stax-api.jar -> ../../../java/stax-api.jar 
(activemq)
  /usr/share/activemq/lib/optional/commons-httpclient.jar -> 
../../../java/commons-httpclient.jar (activemq)

Given that one .jar file is not marked as optional, I set the severity
to serious, since there seems to be a dependency missing.

Should activemq Recommends/Suggests the packages providing the optional
.jar files?


cheers,

Andreas


activemq_5.15.8-1.log.gz
Description: application/gzip

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

[Rhonda D'Vine]

Hey,

* Pirate Praveen  [2018-12-18 09:34:46 CET]:
> On 12/3/18 8:11 PM, Dominik George wrote:
> >> well, Debian is using gitlab!!! so this sentence has no sense. The
> >> problem here
> >> is that is a complex software that depends of a lot of pieces and it's
> >> not
> >> easy/possible to fit the definition. So, maybe we should create another
> >> category
> >> of software.
> > 
> > Yes, and that Debian officially uses GitLab, from a foreign source, without 
> > being able to support it in Debian, does make me feel ashamed for the 
> > project.
> > 
> >> maybe creating another kind of repo. debian-contributuions
> >> debian-blabla, whatever.
> >>
> > 
> > We had volatile, which, redefined properly, could help. I am trying to 
> > draft such a definition.
> 
> Did you get a chance to work on it?

 Yes, it looks very much that the shutting down of volatile made wishes
appear for backports to cover it - while it wasn't (and shouldn't) be
the scope for it.  It would make it indistinguishable which packages
within backports are following the regular rules and which would be
those fast moving targets without any useful tracking or upgrade
features in the regular sense.

 (Part of that was btw. also the creation of a seperate sloppy pocket
for backports from oldstable+2 releases, to make it clear what to expect
in there)

 And yes, I'm with Alexander, the volatile maintenance can't be dumped
on the backports team.  It's a different workflow anyway.

 Good luck,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#916771: radicale: systemd unit proposal

[Jonas Smedegaard]

Quoting Francisco Romero (2018-12-18 13:44:54)
> I have created a systemd unit for radicale that works in debian stretch.

Thanks!

> [Service]
> Type=simple
> ExecStart=/usr/bin/radicale
> WorkingDirectory=/etc/radicale
> Restart=on-failure
> StandardOutput=syslog
> StandardError=syslog
> 
> [Install]
> WantedBy=multi-user.target

Did you see the systemd unit at https://radicale.org/setup/ ?

I would appreciate reflections on reasons to deviate from that.

E.g. WorkingDirectory looks odd to me...


> I needed a log file to work: /var/log/radicale/radicale.log.

Right.

Reason that is not created during package install is to leave open 
different uses of the package (including as a regular user).

I might introduce more specific packages - radicale-systemd and 
radicale-uwsgi depending on daemon tools, and radicale-user which 
includes registration in XDG menu system.  Help with that appreciated.


NB! The package in stable is too stable to get this kind of change.

It would be quite helpful if you are able to test the package now in 
unstable, and propose improvements to that.


 - Jonas

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

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


signature.asc
Description: signature

Bug#916760: emacs: please enable systemd socket activation support

[Ansgar Burchardt]

Hi,

I got around to rebuild emacs with libsystemd-dev installed.  That is
enough for socket activation to work (with custom emacs.socket file):

+---
| run/user/[...]/emacs [...] 
users:(("emacs",pid=26360,fd=3),("systemd",pid=2487,fd=23)) <->
+---( from ss output )

Ansgar

Bug#916375: apache2: Segmentation fault when mod_perl.so is loaded

[Hans-Georg Thien]

Thanks Niko,

it seems that you where right regarding libmariadbclient18 ...

downgrading libmariadbclient18 fixed the issue :-)

    dpkg -i libmariadbclient18_10.1.26-0+deb9u1_amd64.deb



Niko Tyni wrote:

On Thu, Dec 13, 2018 at 06:44:32PM +0100, h.thien wrote:

Package: apache2
Version: 2.4.25-3+deb9u6
Severity: grave
Tags: patch
Justification: renders package unusable
gdb> Thread 1 "/opt/otrs/bin/cgi-bi" received signal SIGSEGV, 
Segmentation fault.
gdb> bt
#0  0x7fffdcd290c7 in free_defaults () from 
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
We are using unattended upgrades (security only), and we suspect that 
an automatic system update has installed a new Perl version that now causes 
these problems.

Have you ruled out the MariaDB update? That one seems the most
likely to have triggered this regression.

   https://www.debian.org/security/2018/dsa-4341

(Not sure how reliably you got the list of loaded shared libraries;
you seem to be running the prefork mpm so presumably only some of your
apache processes will have the libraries loaded by the actual Perl
application.)




--
Hans-Georg Thien | Software Engineer
callas software GmbH | Schoenhauser Allee 6/7 | 10119 Berlin | Germany
Tel +49.30.4439031-0 | Fax +49.30.4416402 | www.callassoftware.com
Amtsgericht Charlottenburg, HRB 59615
Geschäftsführung: Olaf Drümmer, Ulrich Frotscher, Dietrich von Seggern

Bug#916778: cylc: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: src:cylc
Version: 7.8.0-3
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster with dpkg-buildpackage -A but it failed:


[...]
dh  binary-indep --with python2
   dh_testroot -i
   dh_prep -i
   dh_installdirs -i
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
# Don't support gpanel. Requires gnome2's gnomeapplet.
rm -rf  bin/cylc-gpanel conf/gpanel
mkdir -p debian/tmp/usr/bin
mkdir -p debian/tmp/etc/cylc/gcylcrc
cp bin/cylc debian/tmp/usr//bin/cylc
cp etc/gcylc.rc.eg debian/tmp/etc/cylc/gcylcrc/gcylc.rc
cp etc/global-tests.rc.eg debian/tmp/etc/cylc/gcylcrc/global-tests.rx
cp etc/gcylc-themes.rc debian/tmp/etc/cylc/gcylcrc
find . -name '*.t' -exec chmod +x {} \;
find . -name test_header -exec chmod +x {} \;
chmod +x bin/*
install -d -m 0755 
/<>/debian/cylc-el/usr/share/emacs/site-lisp/cylc
install-m 0644 etc/syntax/cylc-mode.el \
   
/<>/debian/cylc-el/usr/share/emacs/site-lisp/cylc/cylc-mode.el
# Do this part if full build (not just arch-dependent)
make[1]: Leaving directory '/<>'
   dh_install -i
   dh_installdocs -i
   dh_installchangelogs -i
   dh_installexamples -i
dh_installexamples: Cannot find (any matches for) "examples/*" (tried in .)

   dh_python2 -i
E: dh_python2 dh_python2:408: no package to act on (python-foo or one with 
${python:Depends} in Depends)
   dh_perl -i
   dh_link -i
   dh_strip_nondeterminism -i
   dh_compress -i
   debian/rules override_dh_fixperms
make[1]: Entering directory '/<>'
# Delete after install. Use packages instead.
for p in Pyro cherrypy markupsafe jinja2 ; do \
rm -rf debian/python-cylc/usr/lib/python2.7/dist-packages/$p ; \
done
# shipped separately
find debian/python-cylc -name glyphicons-halflings-regular.ttf -delete
find: 'debian/python-cylc': No such file or directory
make[1]: *** [debian/rules:38: override_dh_fixperms] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:5: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The usual recipe is to split override_dh_foo into override_dh_foo-arch
and override_dh_foo-indep, but in this case it seems a little bit strange
that you are deleting things in the fixperms target (which is usually
for fixing perms).

Also, please consider uploading in source-only form (dpkg-buildpackage -S)
so that this kind of bugs do not propagate to testing and we have official
build logs for the arch:all autobuilder, currently missing here:

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

Thanks.

Bug#874487: Debian mirror mirrors.gigenet.com: missing-tracefile, syncscript

[Julien Cristau]

On 12/18/18 2:26 PM, Scott Ehas wrote:
> Hello Peter,
> 
> We have updated the ftpsync.conf, and have reconfigured the cronjob. 
> I'll check in a few hours to see if the sync has finished.
> 
> 00 03 * * * /opt/debiansync/bin/ftpsync sync:all
> 00 06 * * * /opt/debiansync/bin/ftpsync sync:all
> 00 12 * * * /opt/debiansync/bin/ftpsync sync:all
> 00 21 * * * /opt/debiansync/bin/ftpsync sync:all
> 
Are you sure about that schedule?  That has a 3 hour interval and a 9
hour one, instead of all 6.

Cheers,
Julien

Bug#916773: r-base: CRAN packages fail to install.

[Emmanuel Charpentier]

Le mardi 18 décembre 2018 à 07:34 -0600, Dirk Eddelbuettel a écrit :
> On 18 December 2018 at 14:21, Emmanuel Charpentier wrote:
> > Package: r-base
> > Version: 3.5.1.20181215-1
> > Severity: important
> > 

[ Snip... ]

> There is nothing I can do for you here. If it is upstream in R, it is
> upstream in R.
> 
> I didn't do anything R to prevent brms from working.

This I'm aware of. But my filing of a bug was more along the lines of
"Against *wtah* should I file a bug ? ".

A couple bugs against glibc *"look like"* this bug, but none is exactly
this one. Would you recommend filing a *new* bug againts the glibc
source ?

In other words, how should I report this informatin in order to be
efficient ?

--
Emmanuel Charpentier

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Tim Ruehsen]

Package: libc6-armhf-cross
Version: 2.28-2cross2
Severity: normal

Dear Maintainer,

currently strerror(-3) sets errno unexpectedly to ENOMEM (12).

The expected errno value would be either EINVAL or not touching errno
at all.

This behavior is relatively new and causes some CI cross builds to fail.
The failing test is a gnulib test (test-strerror.c).

The behavior is not seen on an i368 cross build, while on all our other cross 
builds,
which are arm-linux-gnueabihf, mips-linux-gnu, aarch64-linux-gnu.

Here is a small reproducer:
include 
#include 
#include 

int main(void)
{
errno=0;
char *msg=strerror(-3);
printf("errno=%d, msg=%s\n",errno,msg);

return 0;
}

Test it with:
$ arm-linux-gnueabihf-gcc -Wextra x.c -o x
$ ./x
errno=12, msg=Unknown error -3

You need the binfmt/qemu stuff set up to execute the cross-compiled binary.

Regards, Tim

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

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

Bug#916780: aircrack-ng: Fix building against hwloc

[Samuel Thibault]

Package: aircrack-ng
Version: 1:1.4-3
Severity: normal

Hello,

aircrack-ng build-depends on hwloc, but that is not enough to get hwloc
support for performance boost, see configure result:

  Hwloc:   no

libhwloc-dev should be used instead.

Samuel

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

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

Versions of packages aircrack-ng depends on:
ii  ethtool   1:4.19-1
ii  hwloc 1.11.12-1
ii  iw4.14-1
ii  libc6 2.27-8
ii  libgcc1   1:8.2.0-9
ii  libgcrypt20   1.8.4-4
ii  libnl-3-200   3.4.0-1
ii  libnl-genl-3-200  3.4.0-1
ii  libpcap0.81.8.1-6
ii  libpcre3  2:8.39-11
ii  libsqlite3-0  3.25.3-2
ii  libstdc++68.2.0-9
ii  rfkill2.33-0.2
ii  usbutils  1:007-4+b1
ii  wireless-tools30~pre9-13
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages aircrack-ng recommends:
ii  ieee-data  20180805.1

aircrack-ng suggests no packages.

-- no debconf information

-- 
Samuel
 I hated the Mighty Mouse in the Apple Store every time I played with it. I 
hated the Mighty Mouse at work whenever I set up a Mac for somebody.
 I decided to give it one last chance when I set up my new Mac
 And golly, I like it at home.
 Maybe mine is defective in a way that makes it good.

Bug#916773: r-base: CRAN packages fail to install.

[Dirk Eddelbuettel]

On 18 December 2018 at 15:17, Emmanuel Charpentier wrote:
| Le mardi 18 décembre 2018 à 07:34 -0600, Dirk Eddelbuettel a écrit :
| > On 18 December 2018 at 14:21, Emmanuel Charpentier wrote:
| > > Package: r-base
| > > Version: 3.5.1.20181215-1
| > > Severity: important
| > > 
| 
| [ Snip... ]
| 
| > There is nothing I can do for you here. If it is upstream in R, it is
| > upstream in R.
| > 
| > I didn't do anything R to prevent brms from working.
| 
| This I'm aware of. But my filing of a bug was more along the lines of
| "Against *wtah* should I file a bug ? ".

I know, and I _really_ appreciate it as we are before R 3.5.2.  I was just
about to head to work when I mailed and had to be brief.
 
| A couple bugs against glibc *"look like"* this bug, but none is exactly
| this one. Would you recommend filing a *new* bug againts the glibc
| source ?
| 
| In other words, how should I report this informatin in order to be
| efficient ?

Let's see if we can drill it down. You did the right thing by starting with
install.packages.  But based on personal experience I suspect that this will
go away if we reinstall Rcpp and other build-dependencies of brms. Recall
that brms also works at CRAN on Kurt's Debian system.

So maybe reinstall Rcpp, rstan, rstantools, ...   Maybe one by one?
Maybe write down the old directory date so that we get an if it was glibc or
the C++ library changing.  You could well have packages built with an older
g++ on your box too and those things sometimes bite...

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#916781: slack-desktop: Segmentation fault

[Eric Taylor]

Package: slack-desktop
Version: 3.3.3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   When trying to run slack I recive a segmentation fault.
   It seems to be related to libnode. I ran valgrind slack and get:
==14607== Process terminating with default action of signal 11 (SIGSEGV)
==14607==  Bad permissions for mapped region at address 0xDBF060
==14607==at 0xDBF060: ??? (in /usr/lib/slack/slack)
==14607==by 0x710F071: 
node::http2::Http2Session::Callbacks::Callbacks(bool) (in 
/usr/lib/slack/libnode.so)
==14607==by 0x710F134: ??? (in /usr/lib/slack/libnode.so)
==14607==by 0x5853399: call_init.part.0 (dl-init.c:72)
==14607==by 0x5853495: call_init (dl-init.c:118)
==14607==by 0x5853495: _dl_init (dl-init.c:119)
==14607==by 0x58450C9: ??? (in /lib/x86_64-linux-gnu/ld-2.28.so)




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

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

Versions of packages slack-desktop depends on:
pn  apt-transport-https  
ii  gconf-service3.2.6-5
ii  gconf2   3.2.6-5
ii  gvfs-bin 1.38.1-1
ii  libappindicator1 0.4.92-7
ii  libcurl4 7.62.0-1
ii  libgcrypt20  1.8.4-4
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-3
ii  libnss3  2:3.41-1
ii  libsecret-1-00.18.6-3
ii  libudev1 239-15
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  python   2.7.15-3
ii  xdg-utils1.1.3-1

slack-desktop recommends no packages.

slack-desktop suggests no packages.

-- debconf-show failed

Bug#573571: Potential fix for cwd bug

[Dmitry Bogatov]

[2018-12-16 12:35] Jesse Smith 
> I did some poking around and believe I've found the issue with isserv
> jumping out whenever the current working directory (cwd) is not accessible.
> 
> Basically, in the pushd() function there are two checks - one to see if
> we can save the cwd, and another check to see if we can change to
> /etc/init.d. If either of these checks failed, insserv would bail out.
> The only important check is the second one (moving to /etc/init.d), but
> both were treated as the same, fatal error and resulted in the same
> error message being printed.
> 
> The attached patch fixes this situation so the two errors are handled
> separately. The first check (saving cwd) will fail gracefully with an
> error to stderr. The second check, moving to /etc/init.d, will fail with
> a fatal error.
> 
> This patch also addresses some potential segfault issues in popd().
> These probably would not happen in any practical environment, but the
> extra checks should avoid crashes in the future if a directory gets
> removed while insserv is running.
> 
> This fix will appear in upstream version 1.19.0 in the new year. This
> patch should address the issue in 1.18.0 and earlier releases.

> diff --git a/Makefile b/Makefile
> index cf84e66..5556965 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -76,7 +76,7 @@ endif
>  TODO =   insserv insserv.8
>  
>  all: $(TODO)
> - ln -s ../insserv tests/insserv
> + $(LINK) ../insserv tests/insserv

Improvements of style in Makefile are not strictly part of
resolution of this issue, aren't they?

> diff --git a/insserv.c b/insserv.c
> index e109341..4df4cdc 100644
> --- a/insserv.c
> +++ b/insserv.c
> [...]

I am not familiar with code, but why insserv need to save current
directory in first place? But otherwise patch works for me.

Any chance to something like insserv-1.18.1 release?

Bug#916782: harfbuzz: fails to build on s390x and mips

[Jeremy Bicha]

Source: harfbuzz
Version: 2.2.0-1
Severity: serious
Tags: ftbfs

harfbuzz fails to build on the release architectures s390x and mips.
The new version fails to build on several non-release architectures
too.

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

Thanks,
Jeremy Bicha

Bug#619409: Moving .depend. files

[Dmitry Bogatov]

[2018-12-16 12:48] Jesse Smith 
> I think moving these files in insserv itself would be fairly straight
> forward. I haven't looked into it in any detail yet, but I'm going to
> guess this could be done by changing a few path names in the code.
> 
> However, there is a bit of a domino effect because startpar is hardwired
> to look for the .depend.* files in /etc/init.d/ which means startpar
> needs to be updated too.
> 
> Changing both programs should be fairly trivial, but since at least
> these two programs need to change to use the new path, it means we need
> to carefully consider the migration so we don't prevent a system from
> booting if insserv gets updated before startpar on existing systems.
> 
> What we could probably do, in the short term, is set startpar to look in
> /lib/insserv/depend.* first and, if that fails, fall back to the old way
> of using /etc/init.d/.depend.* Then it won't matter if the user is
> running the current version of insserv or the future/fixed version.
> 
> Thoughts on this approach?

Sounds reasonable. Probably even add a warning, if .depend.* files are
found under /etc.

Bug#838480: Next revision, suggestion accounted

[Dmitry Bogatov]

[2018-12-17 12:56] Michael Biebl 
> Am 04.12.18 um 00:26 schrieb Dmitry Bogatov:
> > 
> > [2018-11-28 18:48] Dmitry Bogatov 
> >> I am worried: freeze is coming, and nothing is happening. I am not going
> >> to miss another release.
> > 
> > Hereby I inform you, that I uploaded NMU into DELAYED/15. Feel free to
> > cancel it, providing rationale why it is not "reasonable".

> For the record, given Martin's latest review I'm not ok with this NMU
> and I would kindly ask you to cancel the upload until it has been
> figured why it is failing. I feel uncomfortable adding a package as a
> supported alternative in this state.

I politely refuse. Either you (I mean all of bin:init maintainers)
/actively/ take part in debugging issue you consider blocker, or you
step aside and let me deal with incoming stream of bugs.

I remind you, that you do not have veto right. The very fact, that
`init' is meta-package, not virtual package, is technical solution, not
instrument of power for bin:init maintainers.

> It's clear that you are unhappy with the situation, so am I.
> Maybe we should involve the CTTE and have them work out and define the
> criteria and interfaces an alternative /sbin/init needs to provide and
> what behaviour can be expected or not (and have an automated test suite
> which tests all this).

Sure. I will write draft summary of disagreement in a week or so into
this bug.

But until and unless CTTE overrules my decision, `runit-init' will be
installable without uninstalling essential packages, either as
pre-dependency of bin:init or as package, that provides `init'.

Bug#916658: RFS: apt-listbugs/0.1.26

[Dmitry Bogatov]

[2018-12-17 00:21] "Francesco Poli (wintermute)" 
> Hello everybody!
> 
> I prepared a new version of the apt-listbugs package (0.1.26):
> it is ready to be uploaded to Debian unstable.
> Could someone please build the package from commit
> [c04fcb88ed8ba0f87c62d5711f394dd455231754], and sponsor its upload to
> sid?
> 
> [c04fcb88ed8ba0f87c62d5711f394dd455231754]: 
>  d5711f394dd455231754>
> 
> The changes since the last upload are:
> 
>   * fixed "executes xdg-open as root user": implemented a way to drop root
> privileges when invoking querybts or a browser, if we can figure out
> which regular user became root (via "su -", "sudo", ...) and if
> package s6 is installed (Closes: #910122)
>   * added xdg-open to the list of possible ways to invoke an appropriate
> web browser
>   * enhanced interface consistency regarding external program (querybts
> and web browser) invocation
>   * enhanced error handling consistency regarding external program invocation
>   * converted README.Debian into README.md (in markdown syntax) and
> improved the document a bit
>   * created FAQ.md by taking some parts from README.md
>   * updated German translation, thanks to Chris Leick! (Closes: #914703)
>   * updated Russian translation, thanks to Sergey Alyoshin! (Closes: #915374)
>   * updated Portuguese translation, thanks to Miguel Figueiredo!
> (Closes: #915802)
>   * updated Italian translation, thanks to Luca Monducci!
>   * updated Dutch translation, thanks to Frans Spiesschaert! (Closes: #916365)
>   * updated Danish translation, thanks to Morten Bo Johansen! (Closes: 
> #916384)
>   * updated French translation, thanks to Jean-Baka Domelevo Entfellner!
> (Closes: #916509)

Uploaded. You are not DM yet, aren't you?


pgpWoSPo5Kvk1.pgp
Description: PGP signature

Bug#573571: Potential fix for cwd bug

[Jesse Smith]

On 12/18/18 9:18 AM, Dmitry Bogatov wrote:
> [2018-12-16 12:35] Jesse Smith 
>> I did some poking around and believe I've found the issue with isserv
>> jumping out whenever the current working directory (cwd) is not accessible.
>>
>> Basically, in the pushd() function there are two checks - one to see if
>> we can save the cwd, and another check to see if we can change to
>> /etc/init.d. If either of these checks failed, insserv would bail out.
>> The only important check is the second one (moving to /etc/init.d), but
>> both were treated as the same, fatal error and resulted in the same
>> error message being printed.
>>
>> The attached patch fixes this situation so the two errors are handled
>> separately. The first check (saving cwd) will fail gracefully with an
>> error to stderr. The second check, moving to /etc/init.d, will fail with
>> a fatal error.
>>
>> This patch also addresses some potential segfault issues in popd().
>> These probably would not happen in any practical environment, but the
>> extra checks should avoid crashes in the future if a directory gets
>> removed while insserv is running.
>>
>> This fix will appear in upstream version 1.19.0 in the new year. This
>> patch should address the issue in 1.18.0 and earlier releases.
>> diff --git a/Makefile b/Makefile
>> index cf84e66..5556965 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -76,7 +76,7 @@ endif
>>  TODO=   insserv insserv.8
>>  
>>  all:$(TODO)
>> -ln -s ../insserv tests/insserv
>> +$(LINK) ../insserv tests/insserv
> Improvements of style in Makefile are not strictly part of
> resolution of this issue, aren't they?

The edit to the Makefile is not really related to this issue. Though it
is a good idea to have the change in place to avoid compile-time errors.

>
>> diff --git a/insserv.c b/insserv.c
>> index e109341..4df4cdc 100644
>> --- a/insserv.c
>> +++ b/insserv.c
>> [...]
> I am not familiar with code, but why insserv need to save current
> directory in first place? But otherwise patch works for me.

I haven't dug into it, to be honest. I know there are a handful of
places in the code where insserv jumps to different directories and then
traces back, but I haven't looked into why it needs the trail of
breadcrumbs.

> Any chance to something like insserv-1.18.1 release?

Probably not, at least not in the next six weeks.

Bug#916782: harfbuzz: fails to build on s390x and mips

[Julien Cristau]

On Tue, Dec 18, 2018 at 09:42:55AM -0500, Jeremy Bicha wrote:
> Source: harfbuzz
> Version: 2.2.0-1
> Severity: serious
> Tags: ftbfs
> 
> harfbuzz fails to build on the release architectures s390x and mips.
> The new version fails to build on several non-release architectures
> too.
> 
> https://buildd.debian.org/status/package.php?p=harfbuzz
> 
Specifically it seems to fail tests on all big-endian archs.

Cheers,
Julien

Bug#916783: command-not-found unable to open database file

[Andrew]

Package: command-not-found
Version: 18.04.5-1

When trying to execute a non-existent command, command-not-found crashes

$ not-a-command
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.6.8 candidate 1
Distributor ID: Debian
Description:Debian GNU/Linux buster/sid
Release:testing
Codename:   buster
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, 
in crash_guard

callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir, do_raise=True)
  File 
"/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
86, in __init__

self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 
12, in __init__

self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file
$

Here are the permissions of the database file at the time:
$ ls -l /var/lib/command-not-found
total 2776
-rw-r- 1 root root 2834432 Dec 18 05:25 commands.db
-rw-r- 1 root root4712 Dec 18 05:25 commands.db.metadata
$

I ran update-command-not-found and no change. I then removed the files 
and ran update-command-not-found again. The files were recreated with 
the same permissions.


As a workaround, I gave read permissions to all users for both files and 
it seems to work fine now.

$ sudo chmod o+r /var/lib/command-not-found/commands.db*

--
Andrew

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

[Pirate Praveen]

On 2018, ഡിസംബർ 18 7:14:14 PM IST, Rhonda D'Vine  wrote:
> And yes, I'm with Alexander, the volatile maintenance can't be dumped
>on the backports team.  It's a different workflow anyway.

My proposal for backports is to have only the dependencies of packages in 
volatile that fall in the current definition of backports kept there, ie,

1. They are already in testing and
2. will be part of next stable.

And use volatile only for packages that cannot fit this criteria. I'd be happy 
to join the backports team to help with the extra load. I hope others will join 
too.

But if that is not possible, volatile as a separate archive is also fine. It is 
just that many packages will have to be in both archives and that is a lot of 
extra work, which I think can be avoided.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#916784: [20181218] debian.gnu.gen.tr: broken DNS

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi!

it seems we cannot resolve debian.gnu.gen.tr currently.
https://mirror-master.debian.org/status/mirror-info/debian.gnu.gen.tr.html

The problem appears to be a broken DNS configuration that puts all of
the nameservers for gnu.gen.tr in the same AS.

Please fix.

Cheers,

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

[Holger Levsen]

On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote:
> But if that is not possible, volatile as a separate archive is also fine. 

instead of volatile we need PPAs.


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Bug#916785: [20181218] ftp.linux.org.tr: broken DNS

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi!

it seems we cannot resolve ftp.linux.org.tr currently.
https://mirror-master.debian.org/status/mirror-info/ftp.linux.org.tr.html

The problem appears to be a broken DNS configuration that puts all of
the nameservers for linux.org.tr in the same AS.

Please fix.

Cheers,

Bug#916751: AW: Bug#916751: [20181218] debian.tu-bs.de: unreachable

[Hans-Peter Mohr]

Hi Peter,

the service has been restored. 

Kind Regards,
Hans-Peter Mohr


-Ursprüngliche Nachricht-
Von: Peter Palfrader  
Gesendet: Dienstag, 18. Dezember 2018 10:15
An: sub...@bugs.debian.org
Betreff: Bug#916751: [20181218] debian.tu-bs.de: unreachable

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi!

it seems
http://debian.tu-bs.de/debian/
is unreachable:
https://mirror-master.debian.org/status/mirror-info/debian.tu-bs.de.html

Please investigate.

Cheers,

Bug#915061: Why does Debian even change the version compared to upstream?

[Bill Allombert]

On Tue, Dec 18, 2018 at 11:54:29AM +0100, Max Horn wrote:
> Hi,
> 
> I am one of the GAP developers, and just saw this report; and I'd like
> to ask something that has bothered me for a while: why does Debian
> change the upstream version at all? Why not use 4.9.3 as we use
> upstream, instead if 4r9r3? Note that GAP versions always used dots;
> it is true that years ago, the filenames of our tarballs used "r"
> instead of dots, but I don't see why that'd be a reason to keep using
> a version that is different from what GAP itself reports, what our
> documentation and websites use etc.
> 
> AFAICT, in Debian, 4r9 < 4.9 and so changing this wouldn't even require a new 
> epoch.

Hello Max,

The issue is that I never got the official decision to move to 4.x.y.
The decision to use 4rxpy predate my involvement with gap in Debian,
so maybe it is an historical misunderstanding.
GAP used 4rxpy as version number for a long time.
Not so long ago, the upstream achive I based the packcage on was named
gap4r8p9_nopackages.zip.

As you say I can change to 4.9 without requiring an epoch, however I cannot
change back, and this might cause problem with some versionned depends.

So if the GAP consensus is that I should change to 4.x.y, I will do it
fo GAP 4.11 but I consider this is a minor issue compared to the
potential for breakage.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#916786: 916750

[Glenn Strauss]

Source: lighttpd
Version: 1.4.52-1

> Problem #2:
>
> lighttpd presently produces 11 binary packages. That's quite many for an
> otherwise small package. Adding binary packages has a metadata cost to
> the Debian archive that affects everyone (not just lighttpd users). We
> should seek to reduce the package count.

IMHO, it appears that the origin of these issues is the metadata cost,
and not that lighttpd is modular.  It appears the metadata costs are
the tail wagging the dog for package design decisions.  That is most
unfortunate.

> How bad would it be to simply not ship these four packages in buster (as
> is presently the case) and add them for bullseye? Which ones do we
> really need for buster? Did I miss anything?

The previous Debian lighttpd maintainers did a pretty poor job following
upstream.  Just about everything that you're doing is an improvement, so
thank you.

Perhaps for Buster, all the new packages should be removed, except
those split from existing lighttpd core (mod_openssl) and from mod_auth
(mod_authn_file, mod_authn_ldap).  Hopefully, Debian will address the
metadata cost scaling issue in a future Debian release.

I still think it reflects poorly on Debian that lighttpd in Debian
will be crippled due to Debian packaging scaling limitations.

While I would like to see mod_openssl as its own package for the
future, no such requirement exists at the moment, and other parts of
lighttpd link against libcrypto (not libssl).  The lighttpd build
would have to be modified if lighttpd were to provide some algorithms
with the core (e.g. SHA1), rather than obtaining them from libcrypto,
and then mod_openssl built separately.  So for now, let's not do
mod_openssl as a separate package.

As you proposed, we might proceed with creating lighttpd-modules-mysql
and lighttpd-modules-ldap to start the transition, as that makes sense
to group the modules depending on the database so that a future Debian
release can remove those dependencies from the core.

.

tl;dr:

I agree with your proposal for lighttpd-modules-mysql and
lighttpd-modules-ldap, though I might suggest lighttpd-modules-mariadb
instead of lighttpd-modules-mysql.

I agree with your proposal to avoid adding new modules to the lighttpd
base package which would increase the dependency footprint of the
lighttpd base package.

I propose leaving the -dev build dependencies in debian/rules so that
others could more easily build dpkgs of the additional modules, and
install those modules themselves.

Bug#899058: building for Raspbian on a Debian stretch host

[Daniel Pocock]

Here are the steps I followed to build Domoticz for Raspbian stretch
using a Debian workstation

Trying to compile on the Raspberry Pi fails due to insufficient RAM. 
The workstation has more RAM and cores for a much faster compile.




sudo apt install sbuild ubuntu-dev-tools qemu-user-static binfmt-support
aufs-dkms


If the aufs-dkms module fails to build with dkms, obtain it from Git. 
For example, if running a backports kernel 4.17:


mkdir -p ~/ws/aufs && cd ~/ws/aufs
git clone https://salsa.debian.org/janluca-guest/aufs-debian
git checkout debian/4.17+20180827-1
dpkg-buildpackage -rfakeroot -i.git -j24 -b --no-sign
sudo dpkg -i ../aufs-dkms_4.17+20180827-1_amd64.deb


Now the tools are ready:


mk-sbuild --arch=armhf --debootstrap-no-check-gpg
--debootstrap-mirror=http://archive.raspbian.org/raspbian stretch
su - $USER
mk-sbuild --arch=armhf --debootstrap-no-check-gpg
--debootstrap-mirror=http://archive.raspbian.org/raspbian stretch


mkdir -p ~/ws/domoticz
cd ~/ws/domoticz
wget https://archive.raspbian.org/raspbian.public.key
wget https://github.com/domoticz/domoticz/archive/4.9700.tar.gz
ln -s 4.9700.tar.gz domoticz_4.9700.orig.tar.gz
git clone https://gitlab.com/dpocock/domoticz-debian-raspbian/
cd domoticz-debian-raspbian
git checkout debian/backports/stretch
sbuild -A -d stretch-armhf --host=armhf --build=armhf
--extra-repository-key=`readlink -f ../raspbian.public.key`
--no-apt-update --no-apt-distupgrade -j24 .



To install the package on the Pi:

scp ../domoticz_4.9700-1_armhf.deb raspberrypi:/root
ssh pi@raspberrypi
sudo dpkg -i /root/domoticz_4.9700-1_armhf.deb




To install the Zigate plugin on the Pi:


sudo rm /usr/sbin/plugins
sudo ln -s /usr/lib/domoticz/plugins /usr/sbin/plugins   (Bug
workaround, or use the patch mentioned above)
cd /usr/lib/domoticz/plugins
git clone https://github.com/sasu-drooz/Domoticz-Zigate
cd Domoticz-Zigate
git checkout stable


Regards,

Daniel


--
Debian Developer
https://danielpocock.com

Bug#916750:

[Glenn Strauss]

> Problem #2:
>
> lighttpd presently produces 11 binary packages. That's quite many for an
> otherwise small package. Adding binary packages has a metadata cost to
> the Debian archive that affects everyone (not just lighttpd users). We
> should seek to reduce the package count.

IMHO, it appears that the origin of these issues is the metadata cost,
and not that lighttpd is modular.  It appears the metadata costs are
the tail wagging the dog for package design decisions.  That is most
unfortunate.

> How bad would it be to simply not ship these four packages in buster (as
> is presently the case) and add them for bullseye? Which ones do we
> really need for buster? Did I miss anything?

The previous Debian lighttpd maintainers did a pretty poor job following
upstream.  Just about everything that you're doing is an improvement, so
thank you.

Perhaps for Buster, all the new packages should be removed, except
those split from existing lighttpd core (mod_openssl) and from mod_auth
(mod_authn_file, mod_authn_ldap).  Hopefully, Debian will address the
metadata cost scaling issue in a future Debian release.

I still think it reflects poorly on Debian that lighttpd in Debian
will be crippled due to Debian packaging scaling limitations.

While I would like to see mod_openssl as its own package for the
future, no such requirement exists at the moment, and other parts of
lighttpd link against libcrypto (not libssl).  The lighttpd build
would have to be modified if lighttpd were to provide some algorithms
with the core (e.g. SHA1), rather than obtaining them from libcrypto,
and then mod_openssl built separately.  So for now, let's not do

mod_openssl as a separate package.

As you proposed, we might proceed with creating lighttpd-modules-mysql
and lighttpd-modules-ldap to start the transition, as that makes sense
to group the modules depending on the database so that a future Debian
release can remove those dependencies from the core.


tl;dr:

I agree with your proposal for lighttpd-modules-mysql and
lighttpd-modules-ldap, though I might suggest lighttpd-modules-mariadb
instead of lighttpd-modules-mysql.

I agree with your proposal to avoid adding new modules to the lighttpd
base package which would increase the dependency footprint of the
lighttpd base package.

I propose leaving the -dev build dependencies in debian/rules so that
others could more easily build dpkgs of the additional modules, and
install those modules themselves.

Bug#915061: Why does Debian even change the version compared to upstream?

[Max Horn]

Hi Bill,

>> Am 18.12.2018 um 16:49 schrieb Bill Allombert :
>> 
>> On Tue, Dec 18, 2018 at 11:54:29AM +0100, Max Horn wrote:
>> Hi,
>> 
>> I am one of the GAP developers, and just saw this report; and I'd like
>> to ask something that has bothered me for a while: why does Debian
>> change the upstream version at all? Why not use 4.9.3 as we use
>> upstream, instead if 4r9r3? Note that GAP versions always used dots;
>> it is true that years ago, the filenames of our tarballs used "r"
>> instead of dots, but I don't see why that'd be a reason to keep using
>> a version that is different from what GAP itself reports, what our
>> documentation and websites use etc.
>> 
>> AFAICT, in Debian, 4r9 < 4.9 and so changing this wouldn't even require a 
>> new epoch.
> 
> Hello Max,
> 
> The issue is that I never got the official decision to move to 4.x.y.
> The decision to use 4rxpy predate my involvement with gap in Debian,
> so maybe it is an historical misunderstanding.

It would seem so...

> GAP used 4rxpy as version number for a long time.

I can not find any evidence supporting this. Even GAP 2 and 3 used x.y.z, as 
can be seen e.g. here:  or here 
.

As fas as I know, the only place the r and p were ever used was in the archive 
names. And I am pretty sure the reason for this was that on the Atari ST, the 
TOS file system (which essentially was FAT) restricted file names to 8.3 
format, with no periods allowed in the filename, other than for the file 
extension. Hence the substitution, eg to gap3r4p4.zoo which fits exactly into 
the 8.3 limit.

> Not so long ago, the upstream achive I based the packcage on was named
> gap4r8p9_nopackages.zip.

True, but that still was not the version, even back then.

> 
> As you say I can change to 4.9 without requiring an epoch, however I cannot
> change back, and this might cause problem with some versionned depends.
> 
> So if the GAP consensus is that I should change to 4.x.y,

Not sure what to reply to this. Do you really need us to formally confirm that 
yes, our version convention is the same as it was for the past 30+ years? I'd 
rather say the burden of proof is the other way around... *shrug*

> I will do it
> fo GAP 4.11 but I consider this is a minor issue compared to the
> potential for breakage.

Sure, it's not that I mind whatever version Debian used much either; so far I 
simply chalked this up as "yet another thing that's weird about the GAP package 
in Debian". But seeing this report, I just had to ask :-).

Cheers,
Max

> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 
> 

Bug#916788: qtwebkit-opensource-src FTCBFS: python/ruby interpreter dependencies not satisfiable/installable

[Helmut Grohne]

Source: qtwebkit-opensource-src
Version: 5.212.0~alpha2-17
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

qtwebkit-opensource-src fails to cross build from source, because its
interpreter dependencies on python and ruby are not installable. The
dependencies request the host architecture interpreters, but
qtwebkit-opensource-src only needs to run them during build, so the
build architecture interpreters are needed. After annotating them with
:native, qtwebkit-opensource-src cross builds successfully. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru qtwebkit-opensource-src-5.212.0~alpha2/debian/changelog 
qtwebkit-opensource-src-5.212.0~alpha2/debian/changelog
--- qtwebkit-opensource-src-5.212.0~alpha2/debian/changelog 2018-10-16 
16:48:46.0 +0200
+++ qtwebkit-opensource-src-5.212.0~alpha2/debian/changelog 2018-12-17 
13:18:03.0 +0100
@@ -1,3 +1,10 @@
+qtwebkit-opensource-src (5.212.0~alpha2-17.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate interpreter dependencies with :native. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 17 Dec 2018 13:18:03 +0100
+
 qtwebkit-opensource-src (5.212.0~alpha2-17) unstable; urgency=medium
 
   * Update symbols files from buildds’ logs.
diff --minimal -Nru qtwebkit-opensource-src-5.212.0~alpha2/debian/control 
qtwebkit-opensource-src-5.212.0~alpha2/debian/control
--- qtwebkit-opensource-src-5.212.0~alpha2/debian/control   2018-10-16 
16:48:46.0 +0200
+++ qtwebkit-opensource-src-5.212.0~alpha2/debian/control   2018-12-17 
13:18:02.0 +0100
@@ -35,12 +35,12 @@
ninja-build,
pkg-config,
pkg-kde-tools (>= 0.6.4),
-   python-minimal,
-   python2.7,
+   python-minimal:native,
+   python2.7:native,
qtbase5-private-dev (>= 5.11.2+dfsg~),
qtdeclarative5-private-dev (>= 5.11.2~),
qtpositioning5-dev (>= 5.11.2+dfsg~),
-   ruby,
+   ruby:native,
xauth ,
xvfb 
 Build-Depends-Indep: qtbase5-doc-html (>= 5.11.2+dfsg~) ,

Bug#916787: mark lua-dkjson Multi-Arch: foreign

[Helmut Grohne]

Package: lua-dkjson
Version: 2.5-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:prosody

prosody fails to cross build from source, because its transitive
dependency on lua-dkjson is unsatisfiable. In general, Architecture: all
packages can never satisfy cross Build-Depends unless marked Multi-Arch:
foreign. In this case, such a marking is correct, because lua-dkjson
practically is a data package with no maintainer scripts or dependencies
that could induce any architecture-dependence. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru lua-dkjson-2.5/debian/changelog 
lua-dkjson-2.5/debian/changelog
--- lua-dkjson-2.5/debian/changelog 2016-06-23 01:03:40.0 +0200
+++ lua-dkjson-2.5/debian/changelog 2018-12-17 15:14:48.0 +0100
@@ -1,3 +1,10 @@
+lua-dkjson (2.5-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark lua-dkjson Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 17 Dec 2018 15:14:48 +0100
+
 lua-dkjson (2.5-2) unstable; urgency=medium
 
   * Update Standards-Version to 3.9.8, no changes needed
diff --minimal -Nru lua-dkjson-2.5/debian/control lua-dkjson-2.5/debian/control
--- lua-dkjson-2.5/debian/control   2016-06-23 01:03:40.0 +0200
+++ lua-dkjson-2.5/debian/control   2018-12-17 15:14:47.0 +0100
@@ -10,6 +10,7 @@
 
 Package: lua-dkjson
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Recommends: lua-lpeg
 Provides: ${lua:Provides}

Bug#916789: nslcd: Proposal Of Systemd NSLCD

[Kevin Ariza]

Package: nslcd
Version: 0.9.7-2+deb9u1
Severity: normal


I have one proposal to solve the problem for add systemd .service file, which
is the following:

Create one file on the directory "/lib/systemd/system/", with the name yo want.

nano /lib/systemd/system/nslcd.service

Add the following lines to be displayed:

[Unit]
Description=NSLCD Systemd Unit Debian
After=multi-user.target

[Service]
ExecStart=/usr/sbin/nslcd
Restart=on-failure
KillSignal=SIGQUIT
Type=forking
StandardError=syslog
StandardOutput=syslog
WorkingDirectory=/var/run/nslcd
NotifyAccess=all
RuntimeDirectory=nslcd

[Install]
WantedBy=multi-user.target

Run the following commands for activate the service nslcd in systemd:

root@debian-systemd:/home/vagrant# systemctl enable nslcd.service
root@debian-systemd:/home/vagrant# systemctl daemon-reload
root@debian-systemd:/home/vagrant# systemctl start nslcd.service

Show the status of the service nslcd:

root@debian-systemd:/home/vagrant# systemctl status nslcd.service
● nslcd.service - NSLCD Systemd Unit Debian
   Loaded: loaded (/lib/systemd/system/nslcd.service; enabled; vendor preset:
enabled)
   Active: active (running) since Tue 2018-12-18 12:19:41 GMT; 8min ago
  Process: 422 ExecStart=/usr/sbin/nslcd (code=exited, status=0/SUCCESS)
 Main PID: 424 (nslcd)
Tasks: 6 (limit: 4915)
   CGroup: /system.slice/nslcd.service
   └─424 /usr/sbin/nslcd

Dec 18 12:19:41 debian-systemd systemd[1]: nslcd.service: Failed with result
'exit-code'.
Dec 18 12:19:41 debian-systemd systemd[1]: Starting NSLCD Systemd Unit
Debian...
Dec 18 12:19:41 debian-systemd nslcd[424]: version 0.9.7 starting
Dec 18 12:19:41 debian-systemd nslcd[424]: accepting connections
Dec 18 12:19:41 debian-systemd systemd[1]: Started NSLCD Systemd Unit Debian.
root@debian-systemd:/home/vagrant#

As you can see, the service is running in systemd mode.

If you want to check that the service runs on systemd when you boot your
computer, restart the computer and run the command systemctl status
nslcd.service, and you can see that the service runs on Systemd



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

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

Versions of packages nslcd depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libldap-2.4-2  2.4.44+dfsg-5+deb9u2
ii  lsb-base   9.20161125

Versions of packages nslcd recommends:
ii  bind9-host [host]  1:9.10.3.dfsg.P4-12.3+deb9u4
ii  ca-certificates20161130+nmu1+deb9u1
ii  ldap-utils 2.4.44+dfsg-5+deb9u2
pn  libnss-ldapd | libnss-ldap 
pn  libpam-ldapd | libpam-ldap | libpam-krb5 | li  
pn  nscd   
pn  nslcd-utils

Versions of packages nslcd suggests:
pn  kstart  

Bug#916790: ITP: openliberty -- Installs openliberty full package onto Debian and Ubuntu systems

[Michael Zhang]

Package: wnpp
Severity: wishlist

Package name: openliberty
Version: 18.0.0.2
Url: https://openliberty.io/downloads/
License: EPL
Description: Debian package to install openliberty on Ubuntu and Debian 
systems. This package contains the full openliberty package.

Openliberty allows users to build cloud-native apps and microservices while 
running only what you need. It is the most flexible server runtime available to 
Java developers.

Bug#916536: squid FTCBFS: multiple reasons

[Helmut Grohne]

Hi Amos,

On Tue, Dec 18, 2018 at 04:45:28PM +1300, Amos Jeffries wrote:
> Could you supply a patch with those changes for me to test?

I'm attaching a patch with a comment and the profiles only (as you
already applied the rest). I hope you can work it out to your liking.
Refer to man 5 deb-src-control for the use of comments and build
profiles.

Helmut
diff --minimal -Nru squid-4.4/debian/control squid-4.4/debian/control
--- squid-4.4/debian/control	2018-10-30 14:57:15.0 +0100
+++ squid-4.4/debian/control	2018-12-18 17:15:16.0 +0100
@@ -8,8 +8,9 @@
 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)
+# The compiler dependencies are relevant for backporting.
+	, 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]

Bug#916442: qemu: CVE-2018-20123

[Salvatore Bonaccorso]

Control: severity -1 minor

PVRDMA support is actually not enabled, so src:qemu only affected at
the source package level so far.

Still trying to keep track of a fix.

Regards,
Salvatore

Bug#916791: firewalld: nftables backend not happy with --set-log-denied={unicast,broadcast,multicast}

[Sam Morris]

Package: firewalld
Version: 0.6.3-4
Severity: normal

firewalld doesn't seem to be happy with any log setting other than 'all'
and 'off'.

# firewall-cmd --set-log-denied=unicast
# journalctl -u firewalld -e
...
Dec 18 16:06:46 firewalld[576]: ERROR: Failed to apply rules. A firewall reload 
might solve the issue if the firewall has been modified using ip*tables or 
ebtables.
Dec 18 16:06:46 firewalld[576]: ERROR: 'nftables' object has no attribute 
'_log_denied'
Dec 18 16:06:47 firewalld[576]: ERROR: Failed to apply rules. A firewall reload 
might solve the issue if the firewall has been modified using ip*tables or 
ebtables.
Dec 18 16:06:47 firewalld[576]: ERROR: '/usr/sbin/nft add rule inet firewalld 
raw_PREROUTING_ZONES goto raw_PRE_public' failed: Error: Could not process 
rule: No such file or directory
add rule inet firewalld raw_PREROUTING_ZONES 
goto raw_PRE_public

^
Dec 18 16:06:47 firewalld[576]: ERROR: Failed to apply rules. A firewall reload 
might solve the issue if the firewall has been modified using ip*tables or 
ebtables.
Dec 18 16:06:47 firewalld[576]: ERROR: '/usr/sbin/nft insert rule inet 
firewalld raw_PREROUTING_ZONES iifname wlp2s0 goto raw_PRE_public' failed: 
Error: Could not process rule: No such file or directory
insert rule inet firewalld raw_PREROUTING_ZONES 
iifname wlp2s0 goto raw_PRE_public

^^^

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (570, 'testing-debug'), (570, 'testing'), (540, 
'unstable-debug'), (540, 'unstable'), (1, 'experimental')
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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firewalld depends on:
ii  dbus 1.12.12-1
ii  gir1.2-glib-2.0  1.58.2-1
ii  init-system-helpers  1.56
ii  iptables 1.8.2-2+b1
ii  policykit-1  0.105-23
ii  python3  3.6.7-1
ii  python3-dbus 1.2.8-2+b1
ii  python3-gi   3.30.4-1
ii  python3-slip-dbus0.6.5-2

Versions of packages firewalld recommends:
ii  ebtables  2.0.10.4-5
ii  ipset 6.38-1

firewalld suggests no packages.

-- Configuration Files:
/etc/firewalld/firewalld.conf [Errno 13] Permission denied: 
'/etc/firewalld/firewalld.conf'
/etc/firewalld/lockdown-whitelist.xml [Errno 13] Permission denied: 
'/etc/firewalld/lockdown-whitelist.xml'

-- no debconf information

Bug#916792: plymouth: should update-initramfs on all kernels on removal

[Julian Gilbey]

Source: plymouth
Version: 0.9.4-1
Severity: important
Tags: patch

As far as I can tell, when plymouth is removed, update-initramfs
should be run on all installed kernels, using the -k all option.
Otherwise old kernels, which might be needed for emergency purposes,
may not boot.

But if I'm wrong, please feel free to close this bug report.

Best wishes,

   Julian

Bug#916793: ITP: puppet-module-heini-wait-for -- Puppet module for waiting for something

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-heini-wait-for
  Version : 2.0.1
  Upstream Author : Dirk Heinrichs 
* URL : https://github.com/heini/puppet-wait-for
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for waiting for something

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 A Puppet resource type that enables you to wait for certain conditions. You
 can use shell commands to query arbitrary things and either react on the exit
 code or match the output of the command against a regular expression.

Note: This package is used by openstack-cluster-installer to wait for the
Galera cluster status.

Bug#916750: lighttpd: reorganize lighttpd binary packages to reduce dependencies (ldap/mysql) and package count

[Helmut Grohne]

Hi Glenn,

On Tue, Dec 18, 2018 at 11:12:30AM -0500, Glenn Strauss wrote:
> > Problem #2:
> >
> > lighttpd presently produces 11 binary packages. That's quite many for an
> > otherwise small package. Adding binary packages has a metadata cost to
> > the Debian archive that affects everyone (not just lighttpd users). We
> > should seek to reduce the package count.
> 
> IMHO, it appears that the origin of these issues is the metadata cost,
> and not that lighttpd is modular.  It appears the metadata costs are
> the tail wagging the dog for package design decisions.  That is most
> unfortunate.

Yes, it is the metadata cost. A number of people have tried fixing it,
but unfortunately that proved to be difficult. So yes, we are now
working around that. We'll have to find some trade-off.

> Perhaps for Buster, all the new packages should be removed, except
> those split from existing lighttpd core (mod_openssl) and from mod_auth
> (mod_authn_file, mod_authn_ldap).  Hopefully, Debian will address the
> metadata cost scaling issue in a future Debian release.

Removing packages does not make much sense as those are already there.
My question was aiming at which of the new modules (pam, pgsql, dbi,
etc.) we should add. If the answer is "all", so be it.

I doubt that anyone will fix the metadata cost issue anytime soon.

> I still think it reflects poorly on Debian that lighttpd in Debian
> will be crippled due to Debian packaging scaling limitations.

There's no hard rule on the package count. I'm just trying to figure out
a reasonable trade-off and push back on blindly adding many packages. If
we end up increasing the package count for sound technical reasons, so
be it.

> While I would like to see mod_openssl as its own package for the

Why do you want to split off mod_openssl? Is it the size? libssl1.1 has
about 4MB. That can be a reason.

> future, no such requirement exists at the moment, and other parts of
> lighttpd link against libcrypto (not libssl).  The lighttpd build
> would have to be modified if lighttpd were to provide some algorithms
> with the core (e.g. SHA1), rather than obtaining them from libcrypto,
> and then mod_openssl built separately.  So for now, let's not do
> mod_openssl as a separate package.

Splitting will become easier once we have the Provides as consumers will
then know that they should Depends: lighttpd-mod-openssl. They won't
have to know whether that's a virtual or real package.

> As you proposed, we might proceed with creating lighttpd-modules-mysql
> and lighttpd-modules-ldap to start the transition, as that makes sense
> to group the modules depending on the database so that a future Debian
> release can remove those dependencies from the core.

I'd not have lighttpd depend on lighttpd-modules-ldap. Yes, that reduces
functionality and might break users' installations, but we can explain
that in NEWS. A transitional Recommends might be an option.

> I agree with your proposal for lighttpd-modules-mysql and
> lighttpd-modules-ldap, though I might suggest lighttpd-modules-mariadb
> instead of lighttpd-modules-mysql.

I called it mysql, because the modules have that in their name. Is
upstream going to rename the modules?

> I propose leaving the -dev build dependencies in debian/rules so that
> others could more easily build dpkgs of the additional modules, and
> install those modules themselves.

If people actually want those modules, then we should simply build and
package them now.

I sense that we'll be adding 7 new packages (ldap, mysql/mariadb,
openssl?, pgsql, dbi, pam, sasl) soon. Not nice for metadata, but at
least we gave it some thought.

Are more pgsql modules on the horizon? (e.g. mod_authn_pgsql? Should we
call the package lighttpd-mod-vhostdb-pgsql or lighttpd-modules-pgsql?)
Also same question for sasl and dbi.

Helmut