from:"Andreas Henriksson"

Bug#828747: libarchive: Add CPE IDs in upstream/metadata

2016-06-27 Thread Andreas Henriksson

Hello again,

On Mon, Jun 27, 2016 at 02:30:18PM +0200, Petter Reinholdtsen wrote:
> 
> Package: src:libarchive
> Version: 3.2.1-1
> Severity: wishlist
> Tags: patch
> 
> Hi.  I've been working for a while on a system to make it easier to
> track security issues in Debian by mapping packages to the CPE IDs used
> to identify affected packages for individual CVEs.  Would you be willing
> to add the relevant CPE IDs to the source package using the following
> patch?

I don't see how this could hurt in any way. Please do feel
free to push changes to the git repo. Even better if you're
interested in becoming co-maintainer. ;)
(... or even adopt the package and remove me completely. :P)

Regards,
Andreas Henriksson

Bug#821347: libsecret porting for s390x

2016-06-26 Thread Andreas Henriksson

Hello Debian s390x porters!

I'd like to ask for your help with looking at the problems building
libsecret on s390x. It's currently the only (release-)architecture
not building and blocking testing migration for a long time. :(

It seems the testsuite somehow gets stuck on your arch/buildd

https://buildd.debian.org/status/fetch.php?pkg=libsecret=s390x=0.18.5-1=1462961523
https://tracker.debian.org/pkg/libsecret
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821347

Regards,
Andreas Henriksson

Bug#731634: libarchive 3.2.1 needs newer (non-alpha) xz-utils to compile

2016-06-26 Thread Andreas Henriksson

Hello!

Sorry to be adding another "me too", but you asked "Is there a package
depending on this behavior, ..." so I have to add that the new
upstream release of libarchive 3.2.1 fixes several security related
issues and other critical fixes, but unfortunately it doesn't build
with the alpha-releases of xz-utils. An update would be appreciated
or atleast a status update on what the maintenance status is.
Should this package be orphaned so others can take care of it?
I might get some time to look at this during debconf so would
appreciate feedback ASAP.

Regards,
Andreas Henriksson

Bug#828633: mount in testing/unstable should conflict with old bash-completion

2016-06-26 Thread Andreas Henriksson

Control: tags -1 = moreinfo

Hello!

Apparently I'm stressing this too much as well being short on time
currently...

On Sun, Jun 26, 2016 at 08:12:26PM +0200, Sven Joachim wrote:
> On 2016-06-26 23:22 +1000, Russell Coker wrote:
> 
> > Below is the results of "apt-get dist-upgrade" to upgrade from Jessie to
> > testing.  If I manually upgrade bash-completion first then mount can be
> > upgraded without problems.
> >
> > Preparing to unpack .../mount_2.28-5_amd64.deb ...
> > Unpacking mount (2.28-5) over (2.27.1-3.1) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/mount_2.28-5_amd64.deb (--unpack):
> >  trying to overwrite '/usr/share/bash-completion/completions/mount', which 
> > is also in package bash-completion 1:2.1-4.3
> 
> How could that happen, considering that bash-completion 1:2.1-4.3 is
> precisely the version which dropped the file in question, and there is
> not even a newer version in the archive?  Did you have a local
> bash-completion package with the same version as the official one and
> different contents installed?

I also find this peculiar when looking closer at it. That version
of bash-completion should not have the mount completion file.

> 
> On 2016-06-26 19:01 +0200, Sven Joachim wrote:
> 
> > On 2016-06-26 18:42 +0200, Andreas Henriksson wrote:
> >
> >> Thanks for your bug report. I apparently forgot to bump the version
> >> of the already existing Breaks/Replaces statements in previous upload.
> >> Fixed in git, will be part of next upload.
> >
> > The fix in git is wrong (at least not sufficient), though.
> 
> Or at least unrelated, since changes to the util-linux package will not
> fix file conflicts in the mount package.

Thanks for catching my mistake. I pushed a revert

> 
> > You bumped the Breaks/Replaces combination in util-linux, but really
> > it needs to be changed in mount, removing the spurious tilde:
> >
> > --8<---cut here---start->8---
> > diff --git a/debian/control b/debian/control
> > index cef4980..61f66ba 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -78,8 +78,8 @@ Section: admin
> >  Pre-Depends: ${misc:Pre-Depends}, ${shlibs:Depends}
> >  Depends: ${misc:Depends}
> >  Suggests: nfs-common (>=1:1.1.0-13)
> > -Breaks: bash-completion (<< 1:2.1-4.3~)
> > -Replaces: bash-completion (<< 1:2.1-4.3~)
> > +Breaks: bash-completion (<< 1:2.1-4.3)
> > +Replaces: bash-completion (<< 1:2.1-4.3)

This change makes no sense to me. When declaring relationships against
specific debian revisions including a trailing tilde is recommended
to enable backports for example.

> >  Multi-Arch: foreign
> >  Description: tools for mounting and manipulating filesystems
> >   This package provides the mount(8), umount(8), swapon(8),
> > --8<---cut here---end--->8---
> 
> Scratch that, this does not make any sense.  I should not comment on bug
> reports during football half-time breaks.

I guess we agree. not sure what change is needed here really.

Russel could you please enlighten us how this could happen?

(I'll try to find time during debconf to set up a chroot and test upgrade
to verify..)

Regards,
Andreas Henriksson

Bug#828633: mount in testing/unstable should conflict with old bash-completion

2016-06-26 Thread Andreas Henriksson

Control: tags -1 + pending
Control: severity -1 serious

Hello!

Thanks for your bug report. I apparently forgot to bump the version
of the already existing Breaks/Replaces statements in previous upload.
Fixed in git, will be part of next upload.

Regards,
Andreas Henriksson

Bug#824451: libarchive: FTBFS on kFreeBSD: tar/test/test_option_older_than.c:70: File should exist

2016-06-25 Thread Andreas Henriksson

Hello Petter Reinholdtsen.

(Adding debian-bsd list to CC...)

Thank you very much for looking into this issue!

On Sat, Jun 25, 2016 at 11:59:07AM +0200, Petter Reinholdtsen wrote:
> Control: tags -1 + patch
> 
> [Simon McVittie]
> > As already reported to debian-bsd by the libarchive maintainer,
> > libarchive 3.2.0 fails to build from source on kFreeBSD due to this
> > test failure:
> > 
> >  40: test_option_older_than
> >  tar/test/test_option_older_than.c:70: File should exist: a/b/old.txt
> >  tar/test/test_option_older_than.c:83: File should exist: a/b/old.txt
> 
> I had a look at this, and tracked it down to an access() call reporting
> "No such file or directory", for no apparent reason.  The files are present
> when I have a look in the directory after the test run fail.  Look like some
> race condition.
> 
> This made me wonder if perhaps the problem was the kFreeBSD kernel file
> system caching, and I tested to run fsync() when the files are created
> to ensure the data make it to disk.  This solved the problem when I
> tested it on amd64 kFreeBSD.  The attached patch fixes the test failure.

In my ears this sounds pretty much like we're either:

a/ working around a really serious potential data loss bug in kfreebsd
b/ hiding a race in the testsuite by making it less likely to trigger

Neither really sounds like we're getting the correct fix, but maybe
I'm wrong.

Could you please advice on what your ideas about the patch is/was?
Just suggesting where the problem might be and provide a workaround or
do you consider the patch the correct fix for the problem?

Your feedback would be much appreciated!

Would also be great if someone with good kfreebsd knowledge could
confirm that we're not doing a/.


> -- 
> Happy hacking
> Petter Reinholdtsen

> Description: Fix test failure on kFreeBSD
>   Use fsync() in test suite when creating a file, to ensure it is
>   available when access() look for it shortly after the creation.
> 
>   Add more error reporting when the access() call fail to get
>   more information in the future when such failure happen.
> Author: Petter Reinholdtsen <p...@falla.debian.org>
> Bug-Debian: https://bugs.debian.org/824451
> Forwarded: no
> Reviewed-By: 
> Last-Update: 
> 
> --- libarchive-3.2.0.orig/tar/test/main.c
> +++ libarchive-3.2.0/tar/test/main.c
> @@ -920,7 +920,7 @@ assertion_file_exists(const char *filena
>   if (!access(f, F_OK))
>   return (1);
>  #endif
> - failure_start(filename, line, "File should exist: %s", f);
> + failure_start(filename, line, "File should exist: %s (%s)", f, 
> strerror(errno));
>   failure_finish(NULL);
>   return (0);
>  }
> @@ -1644,6 +1644,7 @@ assertion_make_file(const char *file, in
>   return (0);
>   }
>   }
> + fsync(fd);
>   close(fd);
>   return (1);
>  #endif

Regards,
Andreas Henriksson

Bug#796625: [PATCH] clvm: ship native systemd units in debian package

2016-06-14 Thread Andreas Henriksson

Hello Bastian Blank.

Thanks for finally giving some feedback on this bug report.

On Tue, Jun 14, 2016 at 07:47:56PM +0200, Bastian Blank wrote:
> On Mon, Jun 13, 2016 at 01:31:49PM +0200, Andreas Henriksson wrote:
> > Hope this helps. Would be much appreciated if we could resolve this
> > bug report (very) soon. I'd like to avoid NMUing this package but
> > if progress is blocked on this bug report I'll go ahead if there's
> > no feedback by then.
> 
> Did you at least test it once?  My gut say: no.

Then your gut is misleading you. I've tested this as best as I could.
I don't have access to a cluster so could not fully test it
but I've done my best to verify it should run thing similarly
to how the init script starts things. I was hoping that was
not completely broken but maybe I made a mistake.

> 
> > --- lvm2-2.02.153/debian/patches/clvm-systemd-unit-debian-adaptions.patch   
> > 1970-01-01 01:00:00.0 +0100
> > +++ lvm2-2.02.153/debian/patches/clvm-systemd-unit-debian-adaptions.patch   
> > 2016-06-13 13:05:16.0 +0200
> 
> There is already a patch for systemd modifications, use it.

Could you please give some details? I've obviously not found it
otherwise I wouldn't have wasted so much of my time on this.

Why not use the upstream units? Why has this patch not been
referenced in this bug report? How are people going to
find out about it if we don't use the bug tracking system
to record information on what's going on?

Please feel free to post regular (weekly?) status updates
to this bug report about progress you're making on this issue
including all the details that could help avoid duplicate work
and wasted time.

> 
> > +--- a/scripts/lvm2_clvmd_systemd_red_hat.service.in
> >  b/scripts/lvm2_clvmd_systemd_red_hat.service.in
> > +@@ -1,9 +1,10 @@
> > + [Unit]
> > + Description=Clustered LVM daemon
> > + Documentation=man:clvmd(8)
> > +-After=dlm.service corosync.service
> > ++After=cman.service corosync.service
> 
> Where did you find a cman.service?  The package does not even build cman
> support.

I found cman in the (Debian) init script. It's referenced under
Should-Start. This LSB header maps to the After= and Wants= systemd
unit directives. This is a loose "best effort" relationship, contrary
to the Requires-Start LSB header which would map to the stricter
"Requires=" (and After=) systemd unit directives which actually requires
the unit to successfully start up.
As the aim is to mask the init script with a matching service it should
really describe basically the same things.

If you have specific pointers about what's wrong I'd like to hear them,
otherwise I can't really do much else than trust whats written in the
init script. I have no better description of what the service really
wants and how to write its dependencies/relationships than that.

As was mentioned in the initial bug report there are people willing
to help you out if you reach out and describe what it is that your
service actually needs/wants/depends-on/provides, but lacking that
information the best we can do to help is to try to interpret your
init script and assume that's correct (but there are several signs
of it not being, including lintian even detecting outstanding issues
automatically, but without any other information it's not easy to
try to help you out. At the current state I don't see much I can
do at all to improve the situation further so rely on your cooperation.
An alternative approach would be to simply drop building the clvm
binary from src:lvm2 for now given it seems, which you already
acknowledged, need a complete overhaul to get in shape and restore
it once there's someone interested in giving it the maintenance
work it needs/lacked).

Fwiw, This bug in clvm is actually breaking users systems and gets
"random" services removed from the startup breaking their systems. I'm
inclined to raise the severity to grave because of this.
from upstream which did not have the issue at all).

Regards,
Andreas Henriksson

Bug#803232: [PATCH] irqbalance: ship upstream systemd unit (and environment file and other fixes).

2016-06-14 Thread Andreas Henriksson

Control: tags -1 + patch

Hello!

Please see the attached patch which updates the packaging to ship the
upstream systemd unit file included in the sources.  While doing so I
also installed the upstream enviroment file and added conversion from
the old format previously used by the package. Potential improvement
would be to also auto- convert OPTIONS to IRQBALANCE_ARGS. (The init
script takes both into consideration but upstream/systemd unit only
takes IRQBALANCE_ARGS into consideration currently.)
While doing this I also got rid of the "ENABLED in /etc/default/foo"
anti-pattern, which was quite more complicated than expected because of
debconf prompting for enable/disabled state. The maintainer script would
be much less complicated if removing this debconf prompt and simply
relying on the maintainer running update-rc.d after the package
installation, so please consider dropping debconf question for enabled.

Hopefully the patch should cover all the install/upgrade/reconfigure
cases, but someone might want to run this through piuparts to verify I
haven't screwed up my manual testing. Both under systemd and sysvinit.
Both with ENABLE=1 or 0 or update-rc.d irqbalance enable or disable.

Regards,
Andreas Henriksson
diff -Nru irqbalance-1.1.0/debian/changelog irqbalance-1.1.0/debian/changelog
--- irqbalance-1.1.0/debian/changelog   2016-01-09 11:24:25.0 +0100
+++ irqbalance-1.1.0/debian/changelog   2016-06-14 17:44:46.0 +0200
@@ -1,3 +1,33 @@
+irqbalance (1.1.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Ship upstreams misc/irqbalance.env as /etc/default/irqbalance
+- this means it'll automatically become a conffile (Closes: #710942)
+  * Add dh-exec build-dependency used in debian/irqbalance.install
+for the above file rename.
+  * Override dh_clean in debian/rules to make debian/irqbalance.install
+executable as needed when using dh-exec.
+  * Add debian/irqbalance.preinst to save existing /etc/default/irqbalance
+settings on upgrades to this version which ships it as a conffile.
+  * Modify debian/irqbalance.config to take old saved default file into
+consideration when preseeding the debconf answers.
+  * Modify debian/irqbalance.postinst to convert the saved default file
+and append any remaining parts of it to the new /etc/default/irqbalance
+if needed.
+  * Add dh-systemd build-dependency an use --with systemd in debian/rules
+  * Ship upstreams misc/irqbalance.service (Closes: #803232)
+  * Add debian/patches/debian-systemd-service-adaptions.patch
+- set EnvironmentFile path to /etc/default/irqbalance
+  * debian/irqbalance.init: Drop ENABLED anti-pattern and update for
+conversion to use upstream environment variable names.
+  * Create flag files in debian/irqbalance.preinst to tell
+if we're upgrading or installing, since debian/irqbalance.config has
+no way to tell by itself.
+  * Add debian/irqbalance.lintian-overrides to silence "duplicate update-rc.d
+calls" lintian warning until dh_installinit support --no-enable.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Tue, 14 Jun 2016 17:44:40 +0200
+
 irqbalance (1.1.0-2) unstable; urgency=medium
 
   * Fix FTBFS on arm64
diff -Nru irqbalance-1.1.0/debian/control irqbalance-1.1.0/debian/control
--- irqbalance-1.1.0/debian/control 2015-10-21 13:03:40.0 +0200
+++ irqbalance-1.1.0/debian/control 2016-06-14 11:03:05.0 +0200
@@ -2,7 +2,7 @@
 Section: utils
 Priority: extra
 Maintainer: Anibal Monsalve Salazar <ani...@debian.org>
-Build-Depends: dpkg-dev (>= 1.16.1~), debhelper (>= 9.20130604), pkg-config, 
libglib2.0-dev (>= 2.28), xutils-dev, libcap-ng-dev, libnuma-dev [!hurd-any 
!kfreebsd-any !armel !armhf !s390x]
+Build-Depends: dpkg-dev (>= 1.16.1~), debhelper (>= 9.20130604), dh-systemd 
(>= 1.5), dh-exec, pkg-config, libglib2.0-dev (>= 2.28), xutils-dev, 
libcap-ng-dev, libnuma-dev [!hurd-any !kfreebsd-any !armel !armhf !s390x]
 Standards-Version: 3.9.6
 Homepage: https://github.com/Irqbalance/irqbalance
 
diff -Nru irqbalance-1.1.0/debian/irqbalance.config 
irqbalance-1.1.0/debian/irqbalance.config
--- irqbalance-1.1.0/debian/irqbalance.config   2012-04-20 04:39:38.0 
+0200
+++ irqbalance-1.1.0/debian/irqbalance.config   2016-06-14 17:38:11.0 
+0200
@@ -6,16 +6,56 @@
 db_version 2.0
 
 CONF=/etc/default/irqbalance
+CONFCONVERT=/etc/default/irqbalance.dpkg-needs-convert
+# config has no way to detect upgrade vs fresh installs,
+# so preinst hands us a flag files.
+UPGRADE_FLAG_FILE=/run/irqbalance.dpkg-upgrade
+INSTALL_FLAG_FILE=/run/irqbalance.dpkg-install
 
-if test -e $CONF; then
-. $CONF || true
-
-if [ "$ENABLED" = "1" ]; then
-db_set irqbalance/enable true
+is_irqbalance_enabled() {
+# See https://bugs.debian.org/705254 but lets try ourselves for now...
+if [ -e /run/systemd/system ]; then
+if systemctl -

Bug#827225: util-linux FTBFS on hppa architecture

2016-06-13 Thread Andreas Henriksson

Control: tags -1 + upstream

Hello Helge Deller.

On Mon, Jun 13, 2016 at 11:48:31PM +0200, Helge Deller wrote:
[...]
> The attached patch fixes it.
> Can you please apply it?
> I tested it on hppa/parisc.
[...]

Thanks for your patch! Could you please send it upstream first?
I'm trying hard to avoid getting stuck with a pile of patches
which needs constant rebasing. The upstream procedure is
documented at:
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/Documentation/howto-contribute.txt

Note the Signed-off-by paragraph.

Once it's merged upstream I'll happily cherry-pick the commit
and upload a rushed new debian revision if that helps your
porting efforts.

Regards,
Andreas Henriksson

Bug#796687: [PATCH] scsitools: mask init scripts under systemd and related fixes

2016-06-13 Thread Andreas Henriksson

Control: tags -1 + patch

Hello!

Please see the attached patch wish simply masks the two init scripts
when running under systemd. They don't seem to be useful on
a modern system... possibly the init scripts themselves
should be dropped as well because even the sysvinit bootup
process has likely changed more than these scripts have kept up with.

While at it I made some other minor house-keeping.
Also note that using debian source format '3.0 (quilt)' there's no
need to build-dep on and explicitly use quilt in debian/rules if
you want to do futher easy cleanup.

Regards,
Andreas Henriksson
diff -Nru scsitools-0.12/debian/changelog scsitools-0.12/debian/changelog
--- scsitools-0.12/debian/changelog 2013-10-28 12:30:00.0 +0100
+++ scsitools-0.12/debian/changelog 2016-06-13 19:51:55.0 +0200
@@ -1,3 +1,20 @@
+scsitools (0.12-2.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/scsitools.links to create symlinks masking the
+scsitools.sh and scsitools-pre.sh init scripts under systemd.
+- these scripts are likely not useful at all on modern systems.
+(Closes: #796687)
+  * Add dh_link command to debian/rules for the above.
+  * Demote tk to a Suggests instead of Recommends to avoid pulling in
+X11 when installing these otherwise low-level tools.
+- the tools should already handle and give useful help/output
+  when run and tk/wish is missing.
+  * Drop util-linux versioned dependency as the version are already
+new enough since ages and util-linux is Essential: yes anyway.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Mon, 13 Jun 2016 19:41:12 +0200
+
 scsitools (0.12-2.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru scsitools-0.12/debian/control scsitools-0.12/debian/control
--- scsitools-0.12/debian/control   2013-10-01 10:56:07.0 +0200
+++ scsitools-0.12/debian/control   2016-06-13 19:46:07.0 +0200
@@ -7,9 +7,9 @@
 
 Package: scsitools
 Architecture: any
-Depends: ${shlibs:Depends}, util-linux (>= 2.11b-3), sg3-utils (>= 1.24), 
${misc:Depends}
+Depends: ${shlibs:Depends}, sg3-utils (>= 1.24), ${misc:Depends}
 Conflicts: hwtools (<< 0.6)
-Recommends: tk
+Suggests: tk
 Description: Collection of tools for SCSI hardware management
  This package is a collection of tools for manipulating SCSI hardware:
  .
diff -Nru scsitools-0.12/debian/rules scsitools-0.12/debian/rules
--- scsitools-0.12/debian/rules 2011-01-21 22:39:27.0 +0100
+++ scsitools-0.12/debian/rules 2016-06-13 19:50:48.0 +0200
@@ -37,6 +37,7 @@
dh_testroot
dh_prep
dh_installdirs sbin lib usr/sbin usr/lib/scsitools usr/lib/scsi 
usr/share/doc/scsitools etc/init.d usr/share/lintian/overrides
+   dh_link
install -m 755 -p debian/scsitools-pre.sh debian/$(p)/etc/init.d/
install -m 755 -p debian/scsitools.sh debian/$(p)/etc/init.d/
cd scsiinfo && $(MAKE) install DESTDIR=../debian/$(p)
diff -Nru scsitools-0.12/debian/scsitools.links 
scsitools-0.12/debian/scsitools.links
--- scsitools-0.12/debian/scsitools.links   1970-01-01 01:00:00.0 
+0100
+++ scsitools-0.12/debian/scsitools.links   2016-06-13 19:40:29.0 
+0200
@@ -0,0 +1,3 @@
+/dev/null /lib/systemd/system/scsitools-pre.service
+/dev/null /lib/systemd/system/scsitools.service
+

Bug#796628: [PATCH] atm-tools: add native systemd unit and related fixes

2016-06-13 Thread Andreas Henriksson

Control: tags -1 + patch

Hello!

Please see the attached debdiff which adds a native systemd unit file
and does other related fixes. Please see the added debian/changelog
entries for further details.

I'm wondering if the next upload should also orphan the package given
there has been no maintainer upload in over 10 years?

Regards,
Andreas Henriksson
diff -Nru linux-atm-2.5.1/debian/atm-tools.atm 
linux-atm-2.5.1/debian/atm-tools.atm
--- linux-atm-2.5.1/debian/atm-tools.atm2012-09-22 16:18:14.0 
+0200
+++ linux-atm-2.5.1/debian/atm-tools.atm2016-06-13 18:18:40.0 
+0200
@@ -16,6 +16,8 @@
 
 test -f $DAEMON || exit 0
 
+. /lib/lsb/init-functions
+
 OPTIONS='-l syslog'
 START_DAEMON='yes'
 
diff -Nru linux-atm-2.5.1/debian/atm-tools.atm.service 
linux-atm-2.5.1/debian/atm-tools.atm.service
--- linux-atm-2.5.1/debian/atm-tools.atm.service1970-01-01 
01:00:00.0 +0100
+++ linux-atm-2.5.1/debian/atm-tools.atm.service2016-06-13 
19:03:22.0 +0200
@@ -0,0 +1,21 @@
+[Unit]
+Documentation=man:atmarpd(8)
+Description=Start/stop the atm daemon(s).
+DefaultDependencies=no
+Before=sysinit.target
+Before=networking.service
+After=local-fs.target
+ConditionCapability=CAP_NET_ADMIN
+
+[Service]
+#Environment=OPTIONS=-l syslog
+## The EnvironmentFile line only included for backwards/sysvinit compat,
+## but using the file to configure is discuraged!
+## Instead use 'systemctl edit atm.service' and override the
+## Environment or ExecStart lines directly.
+#EnvironmentFile=-/etc/default/atm
+ExecStart=/sbin/atmarpd $OPTIONS
+Restart=on-abort
+
+[Install]
+WantedBy=sysinit.target
diff -Nru linux-atm-2.5.1/debian/changelog linux-atm-2.5.1/debian/changelog
--- linux-atm-2.5.1/debian/changelog2012-09-22 16:18:14.0 +0200
+++ linux-atm-2.5.1/debian/changelog2016-06-13 19:00:33.0 +0200
@@ -1,3 +1,20 @@
+linux-atm (1:2.5.1-1.6) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add atm.service masking the atm init script (Closes: #796628)
+  * Build-depend on dh-systemd and use dh_systemd_{enable,start}
+in debian/rules for the above.
+  * Source LSB init function in atm init script
+- this it possible for systemd LSB hook to properly redirect
+  direct invocations of the init script to systemctl.
+  * Add an explicit Depends on lsb-base because of the above.
+  * Drop build-dependency on initscripts package.
+- the original intention was likely to have this as a dependency
+  rather than build-dependency, but either way should no longer
+  be needed so just drop it.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Mon, 13 Jun 2016 18:18:44 +0200
+
 linux-atm (1:2.5.1-1.5) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru linux-atm-2.5.1/debian/control linux-atm-2.5.1/debian/control
--- linux-atm-2.5.1/debian/control  2012-09-22 16:18:14.0 +0200
+++ linux-atm-2.5.1/debian/control  2016-06-13 18:58:11.0 +0200
@@ -2,13 +2,14 @@
 Section: net
 Priority: optional
 Maintainer: Peter De Schrijver (p2) <p...@mind.be>
-Build-Depends: debhelper (>> 8.1.3~), bison, flex, autoconf, automake, 
libtool, perl, initscripts (>= 2.88dsf-13.3)
+Build-Depends: debhelper (>> 8.1.3~), dh-systemd (>= 1.5),
+ bison, flex, autoconf, automake, libtool, perl
 Standards-Version: 3.9.2
 
 Package: atm-tools
 Architecture: linux-any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: lsb-base, ${shlibs:Depends}, ${misc:Depends}
 Description: Base programs for ATM in Linux, the net-tools for ATM
  This package provides all the basic programs needed for setting up,
  monitoring and tuning ATM networks. Such as:
diff -Nru linux-atm-2.5.1/debian/rules linux-atm-2.5.1/debian/rules
--- linux-atm-2.5.1/debian/rules2012-09-22 16:18:14.0 +0200
+++ linux-atm-2.5.1/debian/rules2016-06-13 18:38:13.0 +0200
@@ -76,7 +76,9 @@
debian/libatm1-dev/usr/lib/libatm.so
 
dh_installdocs --link-doc=libatm1
+   dh_systemd_enable --name=atm
dh_installinit --init-script=atm -- start 39 S .
+   dh_systemd_start --name=atm
dh_installman
dh_installchangelogs ChangeLog
dh_link

Bug#796625: [PATCH] clvm: ship native systemd units in debian package

2016-06-13 Thread Andreas Henriksson

Control: tags -1 + patch

Hello!

The attached patch updates the packaging to ship (modified versions of)
the upstream/redhat native systemd units in the clvm package.
I don't have possibility to test this myself, so hopefully this is
good enough result. I've compared checks in the init script but
they seem pretty obsolete. eg. the check for /etc/cluster/cluster.conf
which the lvm2 sources doesn't have any references to (anymore?).
Given this I opted to NOT enable/start the new
lvm2-cluster-activation.service by default. This creates a problem
on upgrades where people will manually need to enable it, thus
I also added a debian/NEWS entry to mention that.

In essence, clvm init script is masked replaced by two new services:
lvm2-cluster-activation.service and lvm2-clvmd.service
The lvm2-clvmd.service is not something you can manually handle at all
so all admin tasks should be against lvm2-cluster-activation.service
(which will start/stop lvm2-clvmd.service).

Hope this helps. Would be much appreciated if we could resolve this
bug report (very) soon. I'd like to avoid NMUing this package but
if progress is blocked on this bug report I'll go ahead if there's
no feedback by then.

Ulf Norberg it would be very appreciated if you could test building
a package with the patch attached and report back on status.

Regards,
Andreas Henriksson
diff -Nru lvm2-2.02.153/debian/changelog lvm2-2.02.153/debian/changelog
--- lvm2-2.02.153/debian/changelog  2016-05-09 16:45:32.0 +0200
+++ lvm2-2.02.153/debian/changelog  2016-06-13 13:16:07.0 +0200
@@ -1,3 +1,25 @@
+lvm2 (2.02.153-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+- This upload is targeted at and below changes closes: #796625
+  * Add debian/patches/clvm-systemd-unit-debian-adaptions.patch
+- this among other things makes lvm2-cluster-activation.service
+  take the LVM_VGS from /etc/default/clvm into consideration, but
+  ignores other things like CLVMDTIMEOUT from the same file.
+  Use systemctl edit lvm2-cluster-activation.service to override
+  settings instead of the /etc/default/clvm file which should be
+  considered deprecated under systemd.
+  See patch header for more details.
+  * Add debian/clvm.links masking clvm init script under systemd
+in favour of lvm2-{clvmd,cluster-activation}.service
+  * debian/rules: use systemd dh tools on lvm2-cluster-activation.service
+- no start on installation. Use systemctl enable lvm2-cluster-activation
+  once the cluster has been configured!
+  * debian/NEWS: Add a note about enabling lvm2-cluster-activation.service
+for people upgrading from previous versions.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Fri, 10 Jun 2016 17:06:54 +0200
+
 lvm2 (2.02.153-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru lvm2-2.02.153/debian/clvm.links lvm2-2.02.153/debian/clvm.links
--- lvm2-2.02.153/debian/clvm.links 1970-01-01 01:00:00.0 +0100
+++ lvm2-2.02.153/debian/clvm.links 2016-06-10 17:07:30.0 +0200
@@ -0,0 +1 @@
+dev/null lib/systemd/system/clvm.service
diff -Nru lvm2-2.02.153/debian/NEWS lvm2-2.02.153/debian/NEWS
--- lvm2-2.02.153/debian/NEWS   1970-01-01 01:00:00.0 +0100
+++ lvm2-2.02.153/debian/NEWS   2016-06-13 13:11:39.0 +0200
@@ -0,0 +1,9 @@
+lvm2 (2.02.153-1.1) UNRELEASED; urgency=medium
+
+  * This version introduces native systemd units to replace /etc/init.d/clvm
+Please note that "lvm2-cluster-activation.service" is NOT enabled by
+default as local system administrator will need to configure the
+cluster first. Use "systemctl enable lvm2-cluster-activation.service"
+to have clvm enabled under systemd. (The old clvm init script is masked.)
+
+ -- Andreas Henriksson <andr...@fatal.se>  Mon, 13 Jun 2016 13:09:37 +0200
diff -Nru lvm2-2.02.153/debian/patches/clvm-systemd-unit-debian-adaptions.patch 
lvm2-2.02.153/debian/patches/clvm-systemd-unit-debian-adaptions.patch
--- lvm2-2.02.153/debian/patches/clvm-systemd-unit-debian-adaptions.patch   
1970-01-01 01:00:00.0 +0100
+++ lvm2-2.02.153/debian/patches/clvm-systemd-unit-debian-adaptions.patch   
2016-06-13 13:05:16.0 +0200
@@ -0,0 +1,54 @@
+From: Andreas Henriksson <andr...@fatal.se>
+Subject: Debian adaptions of upstream/redhat systemd units
+
+The following adaptions where made to make the upstream redhat-specific
+units work under Debian:
+ * Import environment file /etc/default/clvm instead of sysconfig/clvmd
+   - This makes LVM_VGS available to the activation script but ignores
+ the CLVMDTIMEOUT in /etc/default/clvm ... use systemctl edit
+ to override instead.
+   - replace dlm.service with cman.service in unit dependencies/ordering
+   - demote cman.service from Requires= to Wants= as it's only Recommends
+ (and not Depends) in the Debian package.
+   - use /usr/sbin/clvmd in unit file to match where upstream build system
+

Bug#804703: gnome-keyring: The race with SessionManager initialization

2016-06-13 Thread Andreas Henriksson

Control: tags -1 = confirmed upstream

Hello!

On Mon, Jun 13, 2016 at 02:46:33PM +0900, OGAWA Hirofumi wrote:
> Jeremy Bicha <jbi...@linux.com> writes:
> 
> > Control: tags -1 moreinfo
> >
> > Please update to gnome-keyring 3.20.0-1 and report back whether this
> > fixes your bug.

I was struck by this issue pretty consistently while using 3.20.0-1 (but
did not run into it in earlier versions, classical race issue it seems).

The problems went away for me when applying the patch in this bug
report.

> >
> > gnome-keyring 3.20 fixed https://bugzilla.gnome.org/738205
> > (Despite the bug title, it wasn't limited to just Wayland sessions).
> 
> At least for now, this bug is not reproduced. So it would be better to
> close the bug.  If reproduced, I will re-open.

I've been trying to get a hold off stefw to discuss your patch but
haven't succeded reaching him. This issue (and the patch) should
be forwarded to the upstream bugzilla.

Regards,
Andreas Henriksson

Bug#796627: live-tools NMU uploaded to DELAYED/2

2016-06-09 Thread Andreas Henriksson

Hello Iain R. Learmonth

I've just uploaded an NMU of live-tools to DELAYED/2 as previously
agreed on over IRC. Please see attached updated debdiff which
also includes the init script fix, spotted by Felipe.

Regards,
Andreas Henriksson
diff -Nru live-tools-20151214/debian/changelog 
live-tools-20151214+nmu1/debian/changelog
--- live-tools-20151214/debian/changelog2015-12-14 17:14:10.0 
+0100
+++ live-tools-20151214+nmu1/debian/changelog   2016-06-09 16:07:49.0 
+0200
@@ -1,3 +1,19 @@
+live-tools (1:20151214+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a native live-tools.service unit (Closes: #796627)
+  * Add dh-systemd build-dependency and use "--with systemd" for above.
+  * Source /lib/lsb/init-functions in init script
+- fixes lintian warning: init.d-script-does-not-source-init-functions
+  which means if someone directly invokes the init script under
+  systemd then the systemd LSB hooks will redirect to systemctl.
+  * Add lsb-base dependency because of the above.
+  * Fix up path in init script to make it actually do something
+(/bin/live-media-eject -> /bin/live-medium-eject)
+Thanks to Felipe Sateler for spotting this.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Thu, 09 Jun 2016 16:07:07 +0200
+
 live-tools (1:20151214) unstable; urgency=medium
 
   [ Carlos Zuferri ]
diff -Nru live-tools-20151214/debian/control 
live-tools-20151214+nmu1/debian/control
--- live-tools-20151214/debian/control  2015-12-14 17:11:28.0 +0100
+++ live-tools-20151214+nmu1/debian/control 2016-06-09 16:04:35.0 
+0200
@@ -5,6 +5,7 @@
 Uploaders: Iain R. Learmonth <i...@debian.org>
 Build-Depends:
  debhelper (>= 9),
+ dh-systemd (>= 1.5),
 Standards-Version: 3.9.6
 Homepage: https://debian-live.alioth.debian.org/live-tools/
 Vcs-Browser: http://anonscm.debian.org/cgit/debian-live/live-tools.git
@@ -13,6 +14,7 @@
 Package: live-tools
 Architecture: all
 Depends:
+ lsb-base,
  initramfs-tools,
  ${misc:Depends},
 Suggests:
diff -Nru live-tools-20151214/debian/live-tools.init 
live-tools-20151214+nmu1/debian/live-tools.init
--- live-tools-20151214/debian/live-tools.init  2015-12-14 17:09:42.0 
+0100
+++ live-tools-20151214+nmu1/debian/live-tools.init 2016-06-09 
16:06:49.0 +0200
@@ -16,11 +16,13 @@
 # X-Interactive:   true
 ### END INIT INFO
 
+. /lib/lsb/init-functions
+
 case "${1}" in
stop)
-   if [ -e /bin/live-media-eject ]
+   if [ -e /bin/live-medium-eject ]
then
-   /bin/live-media-eject ${@}
+   /bin/live-medium-eject ${@}
fi
;;
 
diff -Nru live-tools-20151214/debian/live-tools.service 
live-tools-20151214+nmu1/debian/live-tools.service
--- live-tools-20151214/debian/live-tools.service   1970-01-01 
01:00:00.0 +0100
+++ live-tools-20151214+nmu1/debian/live-tools.service  2016-06-09 
16:04:35.0 +0200
@@ -0,0 +1,14 @@
+[Unit]
+Documentation=man:live-tools(7)
+Description=live-tools - System Support Scripts
+DefaultDependencies=no
+Before=shutdown.target
+Conflicts=shutdown.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStop=/bin/live-medium-eject
+
+[Install]
+WantedBy=multi-user.target
diff -Nru live-tools-20151214/debian/rules live-tools-20151214+nmu1/debian/rules
--- live-tools-20151214/debian/rules2015-12-14 17:09:08.0 +0100
+++ live-tools-20151214+nmu1/debian/rules   2016-06-09 16:04:35.0 
+0200
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-   dh ${@} --parallel
+   dh ${@} --parallel --with systemd
 
 override_dh_auto_install:
dh_auto_install

Bug#796589: [pkg-apparmor] Bug#796589: apparmor: Has init script in runlevel S but no matching service file

2016-06-09 Thread Andreas Henriksson

Hello Seth Arnold.

On Mon, Jun 06, 2016 at 05:03:43PM -0700, Seth Arnold wrote:
[...]
> Is there a strong enough reason to ship the wrapping-the-sysv .service
> file? That feels like an odd step to take.

Apart from the reasons already mentioned by Felipe we're getting close
to eliminating the final blockers which means Debian systemd package
might very soon drop its patch for rcS support. This means the init
scripts in rcS will not be run at all!

The information I have is that canonical people are working
on proper AppArmor integration in systemd, similar to selinux,
which should AIUI make the init (and any native (wrapper) unit)
obsolete. This sounds like a good long-term idea, but until
that exists we'll need to use the stop-gap wrapper unit.

Would be nice to see this bug report resolved quite soon!

Please tell me if there's anything I can help out with to
get this resolved ASAP.

Regards,
Andreas Henriksson

Bug#796705: [PATCH] zfs-fuse: systemd service unit wrapping the init script

2016-06-09 Thread Andreas Henriksson

Hello Asias He.

On Thu, May 26, 2016 at 07:48:06AM +0800, Asias He wrote:
> Thanks Andreas!
> 
> On Thu, May 26, 2016 at 3:52 AM, Andreas Henriksson <andr...@fatal.se>
> wrote:
> 
> > Control: tags -1 + patch
> >
> > Hello!
> >
> > The attached debdiff implements the simples possible solution to this
> > bug report, namely a wrapper unit around the init script.
> >
> > It would be quite simple to improve on this and create a real native
[...]
> > PPS. The init scripts (but does not use) the "/etc/default ENABLE_FOO"
> > anti-
> > pattern. It should really be dropped in favour of letting the sysadmin
> > run "update-rc.d zfs-fuse disable" if they want the service disabled.

Do you have any plans to update the package fixing this bug report soon?
Are you interested in further assistance in further improving the
package (as mentioned/suggested above)? Would you prefer to see an NMU
to help out updating the package with a fix?

We're currently getting quite close to resolving all blockers which
means the Debian systemd package might drop it's patch for rcS
scripts very soon. Would be good to have as much fixes as possible
uploaded before that...

Regards,
Andreas Henriksson

Bug#796689: pidentd nmu uploaded to delayed/5

2016-06-08 Thread Andreas Henriksson

Hello!

The attached diff was just uploaded as an NMU to delayed/5
given the lack of response on this bug report.

HTH

Regards,
Andreas Henriksson
diff -Nru pidentd-3.0.19.ds1/debian/changelog pidentd-3.0.19.ds1/debian/changelog
--- pidentd-3.0.19.ds1/debian/changelog	2011-12-08 03:03:44.0 +0100
+++ pidentd-3.0.19.ds1/debian/changelog	2016-06-08 22:51:36.0 +0200
@@ -1,3 +1,19 @@
+pidentd (3.0.19.ds1-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/pidentd.tmpfile and debian/pidentd.links (Closes: #796689)
+- create runtimedirectory using tmpfiles.d instead of via init-script.
+  * Source LSB init-functions in pidentd init script
+- this allows systemd LSB hook to redirect direct init script
+  invocations to use systemctl instead. Caught by lintian.
+  * Drop explicit bzip2 compression in debian/rules and use default
+- these days default (xz for source format > 1.0) is better
+  and this avoids lintian error about bzip2 being deprecated.
+  * Include dpkg buildflags.mk to export hardening flags
+- fixes missing hardening options in built binaries as caught by lintian.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Wed, 08 Jun 2016 22:39:15 +0200
+
 pidentd (3.0.19.ds1-7) unstable; urgency=low
 
   * Fix update-rc.d error
diff -Nru pidentd-3.0.19.ds1/debian/pidentd.init pidentd-3.0.19.ds1/debian/pidentd.init
--- pidentd-3.0.19.ds1/debian/pidentd.init	2011-12-02 23:05:10.0 +0100
+++ pidentd-3.0.19.ds1/debian/pidentd.init	2016-06-08 22:42:57.0 +0200
@@ -11,6 +11,8 @@
 
 [ -x /usr/sbin/identd ] || exit 0
 
+. /lib/lsb/init-functions
+
 case "$1" in
 	start|restart|reload|force-reload)
 		mkdir -p /var/run/identd
diff -Nru pidentd-3.0.19.ds1/debian/pidentd.links pidentd-3.0.19.ds1/debian/pidentd.links
--- pidentd-3.0.19.ds1/debian/pidentd.links	1970-01-01 01:00:00.0 +0100
+++ pidentd-3.0.19.ds1/debian/pidentd.links	2016-06-08 22:39:12.0 +0200
@@ -0,0 +1 @@
+/dev/null /lib/systemd/system/pidentd.service
diff -Nru pidentd-3.0.19.ds1/debian/pidentd.tmpfile pidentd-3.0.19.ds1/debian/pidentd.tmpfile
--- pidentd-3.0.19.ds1/debian/pidentd.tmpfile	1970-01-01 01:00:00.0 +0100
+++ pidentd-3.0.19.ds1/debian/pidentd.tmpfile	2016-06-08 22:39:12.0 +0200
@@ -0,0 +1 @@
+d /var/run/identd 0755 identd nogroup - -
diff -Nru pidentd-3.0.19.ds1/debian/rules pidentd-3.0.19.ds1/debian/rules
--- pidentd-3.0.19.ds1/debian/rules	2011-12-08 03:01:29.0 +0100
+++ pidentd-3.0.19.ds1/debian/rules	2016-06-08 22:50:52.0 +0200
@@ -10,6 +10,10 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
+# export hardening flags
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
 package := pidentd
 
 configure: configure-stamp
@@ -103,7 +107,7 @@
 	dh_shlibdeps
 	dh_gencontrol
 	dh_md5sums
-	dh_builddeb -- -Zbzip2 -z9
+	dh_builddeb
 
 # Build architecture-independent files here.
 binary-indep: install

Bug#826215: init-d-script as default skeleton (was: Re: Bug#826215: SysV init scripts using ...)

2016-06-07 Thread Andreas Henriksson

Hello.

On Fri, Jun 03, 2016 at 11:54:02PM +0200, Petter Reinholdtsen wrote:
> [Michael Biebl]
> > Petter, do you have any preference regarding those two proposals or do
> > you have another suggestion how we could address this?
> 
> I wrote
>  http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
>  >
> to explain the background for the init-d-script setup.
> 
> The goal is to avoid code in the individual init.d scripts that is not
> _required_ to get them working, to make it possible to fix bugs in many
> scripts by modifying one file.  Moving code from init-d-script to the
> individual init.d scripts thus seem like a step backwards.
[...]

Maybe I'm going further off-topic here, but have to ask something...

While I think that in theory init-d-script is a good idea, I have
some practical concerns about it being the default skeleton for now.

I agree that it would feel like a step backwards to revert to
the old skeleton, but at the same time as more packages pick up the
new skeleton they run into issues and there's no maintainer

The only good thing I have to add about the old style is that atleast
it's well proven Personally I'd prefer if also init scripts where
something included in upstream collaboration, and wondering if that's
even possible with init-d-script (which I guess is only available in
Debian(-derivates))? There's also the question on where things should
live to avoid having all packages shipping an init script need to
depend on sysvinit. Also I doubt there will be any effort to convert
existing init scripts over to the new format so that it actually
gets the practical benefits of being able to fix many packages at once.
It's also risking becoming a situation where noone dares to touch the
"one place" (init-d-script itself) which affects all packages because
there's always something which breaks and given enough breakages people
will just move away from it. Having a good test-suite is as I see it
basically a requirement for doing these central backend code efforts,
cf. cdbs vs dh. People will quickly start relying on bug-compatibility
and implementation details when they need a solution to their problem
and there's noone around to quickly fix up the backend to work as
expected, see #825870 for a recent example of where I myself is guilty
of misleading someone into relying on implementation details
instead of using the (non-working) documented correct solution.

Each of these issues might be no big deal on their own but at the same
time it feels like there's bigger picture to be seen by someone thinking
about this system and how it would fit in both in Debians
multi-init-system world and how it would fit into upstream project
collaboration. That's not something that should be dealt with through
targeted NMUs in my opinion.

Until there's someone actively maintaining sysvinit (and init-d-script
in particular) I'd prefer we revert the skeleton back to the old version
for now. Opinions/Comments?

Regards,
Andreas Henriksson

Bug#826609: gnome-calendar: does not start at all

2016-06-07 Thread Andreas Henriksson

Hello!

On Tue, Jun 07, 2016 at 12:57:59AM +0200, Michael Biebl wrote:
> Am 07.06.2016 um 00:41 schrieb Andreas Hilboll:
[...]
> >(gnome-calendar:4888): GLib-GIO-ERROR **: Settings schema 
> > 'org.gnome.shell.calendar' is not installed
> 
> That schema is provided by gnome-shell-common
> 
> We either need to add that as a dependency or (better) make
> gnome-calendar handle it gracefully if the schema doesn't exist.

The attached patch might help, but I also noticed that in the 3.21 series
gnome-calendar (and gnome-shell) has been migrated to use the
gsettings-desktop-schemas org.gnome.desktop.calendar schema instead.
I guess that makes it less interesting to gracefully handle missing
schema in favour of just adding a versioned dependency on
gsettings-desktop-schemas.

I guess we could just carry the patch until we update to 3.21.x/3.22
if someone verifies it actually works... Could you test rebuilding
the gnome-calendar package with the attached patch and see if it
solves your issue Andreas?

Regards,
Andreas Henriksson
From: Andreas Henriksson <andr...@fatal.se>
Subject: make gnome-calendar start even if gnome-shell schemas are missing

Bug-Debian: https://bugs.debian.org/826609

--- a/src/gcal-year-view.c
+++ b/src/gcal-year-view.c
@@ -1483,6 +1483,26 @@
   gtk_widget_class_set_css_name (widget_class, "calendar-view");
 }
 
+/* bind GNOME Shell' show week numbers property to GNOME Calendar's one */
+static void
+gcal_bind_gnome_shell_week_numbers_to_gcal (GcalYearView *self)
+{
+  GSettingsSchemaSource *defsrc;
+
+  /* bail out early if gnome-shell schema is not available. */
+  defsrc = g_settings_schema_source_get_default ();
+  if (!defsrc || g_settings_schema_source_lookup (defsrc,
+  "org.gnome.shell.calendar",
+  TRUE) == NULL) {
+self->shell_settings = NULL;
+return;
+  }
+
+  self->shell_settings = g_settings_new ("org.gnome.shell.calendar");
+  g_settings_bind (self->shell_settings, "show-weekdate", self, "show-week-numbers", G_SETTINGS_BIND_DEFAULT);
+  g_signal_connect_swapped (self->shell_settings, "changed::show-weekdate", G_CALLBACK (gtk_widget_queue_draw), self);
+}
+
 static void
 gcal_year_view_init (GcalYearView *self)
 {
@@ -1501,10 +1521,7 @@
   self->end_selected_date = g_new0 (icaltimetype, 1);
   self->end_selected_date->zone = e_cal_util_get_system_timezone ();
 
-  /* bind GNOME Shell' show week numbers property to GNOME Calendar's one */
-  self->shell_settings = g_settings_new ("org.gnome.shell.calendar");
-  g_settings_bind (self->shell_settings, "show-weekdate", self, "show-week-numbers", G_SETTINGS_BIND_DEFAULT);
-  g_signal_connect_swapped (self->shell_settings, "changed::show-weekdate", G_CALLBACK (gtk_widget_queue_draw), self);
+  gcal_bind_gnome_shell_week_numbers_to_gcal (self);
 
   gtk_list_box_set_header_func (GTK_LIST_BOX (self->events_sidebar), update_sidebar_headers, self, NULL);
   gtk_list_box_set_sort_func (GTK_LIST_BOX (self->events_sidebar), sidebar_sort_func, NULL, NULL);

Bug#826328: util-linux: losetup -d disfunctional for cloop and similar loop-compatible block devices

2016-06-06 Thread Andreas Henriksson

Hello Klaus Knopper.

Thanks for your bug report.

On Sat, Jun 04, 2016 at 05:35:43PM +0200, Klaus Knopper wrote:
[...]
> Losetup was able to setup compressed loopback (cloop) devices, which
> have a similar ioctl API, until recently the code in sys-utils/losetup.c
> and lib/loopdev.c was changed to only accept devices with loopbacks
> major device id.
[...]
> Suggestion: Remove the check for
> 
>   major(st.st_rdev) == LOOPDEV_MAJOR);
> 
> in is_loopdev() in lib/loopdev.c.

Could you please raise your issue on the upstream mailing list
on vger.kernel.org directly?

Regards,
Andreas Henriksson

Bug#826208: util-linux: ionice: clarify documentation of -n,--classdata option

2016-06-03 Thread Andreas Henriksson

Hello Daniel Shahaf.

On Fri, Jun 03, 2016 at 10:29:12AM +, Daniel Shahaf wrote:
[...]
> The attached patch adds that information to the option description too,
> which is where users would expect to find it.
[...]

Could you please submit this patch upstream (either as a github
pull request or via vger.kernel.org mailing list) please?

For detailed instructions please see:
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/Documentation/howto-contribute.txt
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/Documentation/howto-pull-request.txt

(Primarily you'd need to sign off on your changes.)

Regards,
Andreas Henriksson

Bug#825937: sysvinit-utils: Please drop startpar dependency

2016-05-31 Thread Andreas Henriksson

Hello Sven Joachim.

On Tue, May 31, 2016 at 05:16:43PM +0200, Sven Joachim wrote:
> Package: sysvinit-utils
> Version: 2.88dsf-59.4
> Severity: wishlist
> 
> With the "init" package no longer Essential, it is possible to remove
> init, sysvinit-core, sysv-rc, initscripts and insserv from minimal
> chroots.  However, startpar remains because sysvinit-utils depends on
> it.

... and sysvinit-utils is (still) Essential.

This is in my opinion where the focus for changing things should be.
(Making sysvinit-utils non-essential, which means noone cares if
it depends on startpar. You might even discover people have been
working on a plan how that could be implemented.)

> 
> Could you please drop the dependency which AFAICS was only necessary for
> smooth upgrades from Wheezy to Jessie?  It seems sufficient that sysv-rc
> depends on startpar.

Interesting. Could you please share pointers to back up this claim?

The sysvinit-utils dependency on startpar makes startpar
quasi-Essential.  This means anything in the archive can always count on
it being available without a dependency. Given the massive amounts of
(false?) hits on codesearch.debian.net regarding startpar I'd be very
worried to make that change myself.
If you're absolutely confident that dropping this dependency is not
problematic at all, then you should be aware that sysvinit has no Debian
maintainers currently so you could always NMU this change. better
think (more than) twice about it being safe though before going ahead.

Mainly I don't think it's worth attacking this problem so fine-grained
rather than thinking about the bigger picture.

Regards,
Andreas Henriksson

Bug#825870: sysvinit-utils: Second stop command does not use process matchers name and pidfile

2016-05-31 Thread Andreas Henriksson

Hello Steven Roose.

On Tue, May 31, 2016 at 02:15:10AM +0200, Steven Roose wrote:
[...]
> The daemon does not make it's own pidfile, so I added following relevant 
> variables:
> PIDFILE=/pidfile
> START_ARGS=" --make-pidfile"
> STOP_ARGS=" --remove-pidfile"
[...]
> --- a/debian/init-d-script
> +++ b/debian/init-d-script
> @@ -95,7 +95,7 @@ do_stop_cmd() {
>   # sleep for some time.
>   start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 \
>   $STOP_ARGS \
> - --exec $DAEMON
> + ${PIDFILE:+--pidfile ${PIDFILE}} --name $NAME --exec $DAEMON  
>   [ "$?" = 2 ] && return 2
>   # Many daemons don't delete their pidfiles when they exit.
>   rm -f $PIDFILE
[...]

While I think your patch looks good please note that there's no
point in using STOP_ARGS=" --remove-pidfile" given the last quoted
line above which will unconditionally remove any pidfile.

The workaround for your issue is thus very simple. Just drop
STOP_ARGS=" --remove-pidfile"

Hope this helps.

Regards,
Andreas Henriksson

Bug#817168: [PATCH] add/remove-shell: also add/remove shells real path

2016-05-30 Thread Andreas Henriksson

Hello Clint Adams.

Sorry for the late followup but would be good to see some
progress on this issue so my reply can spark some life into this.

On Fri, Mar 25, 2016 at 04:25:17AM +, Clint Adams wrote:
> On Thu, Mar 24, 2016 at 12:32:53PM +0100, Andreas Henriksson wrote:
> > This should solve the "debootstrapped with merged usr" case (see
> > #810301) and Marco has already implemented the upgrade case in
> > usrmerge 11.
> 
> > Please review attached patch.
> 
> I am not thrilled by the idea of duplicating every shell
> in /etc/shells.  Is this the only solution?

I see this as the most/only practical solution and other options as more
theoretical ones.

Marcos reply already mentions one option I consider quite theoretical
and very unpractical.

Personally I don't see the point in supporting non-merged-usr in the
future. On the other hand I don't want to be the one announcing we'll
unconditionally switch to only supporting merged-usr to the angry
mob
Dropping support for non-merged-usr and just convert /etc/shells over on
upgrades would also solve this issue I guess.

So in my view this boils down to a decision for you to make:
1/ can you live with the ugliness in /etc/shells?
2/ do you want to be the one standing on the barricades for making the
   usrmerge package Essential: yes and that the optional non-usrmerge
   alternative in #810301 should be ripped out of the patch forcing new
   debootstraps to always be merged usr?

I think the ugliness is quite minor and would certainly go for 1 myself,
but I'd also envy you if you managed to go the route of 2/ and manage to
get everyone to agree on it in time for stretch release!

As far as I know this is one of few (possibly the only) remaining
blockers for having debootstrap do merged usr by default, so
would be nice to know which way we want to go here...

Regards,
Andreas Henriksson

Bug#825305: hints on the gthumb gconf2->gsettings convertion issue

2016-05-29 Thread Andreas Henriksson

Hello Herbert Fortes.

Hopefully I can help out with the information you need.

The debian pkg gthumb-data built from src:gthumb contains the convertion
file:
https://sources.debian.net/src/gthumb/3:3.4.3-1/data/gthumb.convert/

Among other things this file specifies the gconf2 key called
"show-thumbnails" should be mapped to "org.gnome.gthumb.browse
show-thumbnails" gsettings schema key.

The gsettings schema for gthumb on the other hand also shipped declares
that no such key exists in the schema, see:
https://sources.debian.net/src/gthumb/3:3.4.3-1/data/org.gnome.gthumb.gschema.xml.in/#L48

My guess is that it has simply been removed and the convertion mapping
forgotten to be upgraded when doing so...
This suspicion was quickly confirmed by looking at your git history:
https://anonscm.debian.org/cgit/collab-maint/gthumb.git/commit/data/org.gnome.gthumb.gschema.xml.in?id=485570d6cbd5cbc5a9026acc31ba9f108e9e998b

I'd strongly suggest you simply stop shipping the (outdated/broken)
gconf2 convertion file in the debian pkg since all users of old gthumb
versions using gconf2 should have been uograded and converted over to
gsettings long ago already.
I'd also urge you to contact gthumb uostream to have them remove the
convertion file (or fix it if they think there are still remaining users
that need to be converted).

Hope thus helps clear out the confusion.

Regards,
Andreas Henriksson

Bug#796627: [PATCH] live-tools: add native live-tools.service unit

2016-05-26 Thread Andreas Henriksson

Control: tags -1 + patch

Hello!

Please see attached debdiff for my attempt at fixing this bug report
as well as fixing up basic LSB compatibility of the init script.

I'm not a user of live-tools so don't really know how it should work,
but as I understood the init script I saw no point for it to be run
in rcS as it does *nothing* on start. The only purpose for it is
to run the live-media-eject command before shutdown, right?!
I thus severely lowered the dependencies in live-tools.service
and installed it in multi-user.target rather than sysinit.target.
The only requirement left is that it's run before shutdown(.target).

Feedback on the above would be much appreciated.

Regards,
Andreas Henriksson
diff -Nru live-tools-20151214/debian/changelog 
live-tools-20151214+nmu1/debian/changelog
--- live-tools-20151214/debian/changelog2015-12-14 17:14:10.0 
+0100
+++ live-tools-20151214+nmu1/debian/changelog   2016-05-26 10:47:22.0 
+0200
@@ -1,3 +1,14 @@
+live-tools (1:20151214+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a native live-tools.service unit (Closes: #796627)
+  * Add dh-systemd build-dependency and use "--with systemd" for above.
+  * Source /lib/lsb/init-functions in init script
+- fixes lintian warning: init.d-script-does-not-source-init-functions
+  * Add lsb-base dependency because of the above.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Thu, 26 May 2016 10:37:09 +0200
+
 live-tools (1:20151214) unstable; urgency=medium
 
   [ Carlos Zuferri ]
diff -Nru live-tools-20151214/debian/control 
live-tools-20151214+nmu1/debian/control
--- live-tools-20151214/debian/control  2015-12-14 17:11:28.0 +0100
+++ live-tools-20151214+nmu1/debian/control 2016-05-26 10:46:55.0 
+0200
@@ -5,6 +5,7 @@
 Uploaders: Iain R. Learmonth <i...@debian.org>
 Build-Depends:
  debhelper (>= 9),
+ dh-systemd (>= 1.5),
 Standards-Version: 3.9.6
 Homepage: https://debian-live.alioth.debian.org/live-tools/
 Vcs-Browser: http://anonscm.debian.org/cgit/debian-live/live-tools.git
@@ -13,6 +14,7 @@
 Package: live-tools
 Architecture: all
 Depends:
+ lsb-base,
  initramfs-tools,
  ${misc:Depends},
 Suggests:
diff -Nru live-tools-20151214/debian/live-tools.init 
live-tools-20151214+nmu1/debian/live-tools.init
--- live-tools-20151214/debian/live-tools.init  2015-12-14 17:09:42.0 
+0100
+++ live-tools-20151214+nmu1/debian/live-tools.init 2016-05-26 
10:41:52.0 +0200
@@ -16,6 +16,8 @@
 # X-Interactive:   true
 ### END INIT INFO
 
+. /lib/lsb/init-functions
+
 case "${1}" in
stop)
if [ -e /bin/live-media-eject ]
diff -Nru live-tools-20151214/debian/live-tools.service 
live-tools-20151214+nmu1/debian/live-tools.service
--- live-tools-20151214/debian/live-tools.service   1970-01-01 
01:00:00.0 +0100
+++ live-tools-20151214+nmu1/debian/live-tools.service  2016-05-26 
10:36:24.0 +0200
@@ -0,0 +1,14 @@
+[Unit]
+Documentation=man:live-tools(7)
+Description=live-tools - System Support Scripts
+DefaultDependencies=no
+Before=shutdown.target
+Conflicts=shutdown.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStop=/bin/live-medium-eject
+
+[Install]
+WantedBy=multi-user.target
diff -Nru live-tools-20151214/debian/rules live-tools-20151214+nmu1/debian/rules
--- live-tools-20151214/debian/rules2015-12-14 17:09:08.0 +0100
+++ live-tools-20151214+nmu1/debian/rules   2016-05-26 10:36:42.0 
+0200
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-   dh ${@} --parallel
+   dh ${@} --parallel --with systemd
 
 override_dh_auto_install:
dh_auto_install

Bug#796705: [PATCH] zfs-fuse: systemd service unit wrapping the init script

2016-05-25 Thread Andreas Henriksson

Control: tags -1 + patch

Hello!

The attached debdiff implements the simples possible solution to this
bug report, namely a wrapper unit around the init script.

It would be quite simple to improve on this and create a real native
unit file which does not rely on invoking the init script at all. This
would have the added benefit of real monitoring of the started daemon,
which could be automatically restarted if it crashed, etc.
To accomplish this one would have to split out the
upgrade_zpool_cache_location() function from the init script into a
separate helper program (script).

Regards,
Andreas Henriksson


PS. I've checked and fedora also does a unit wrapping a script helper
although they're not identical to the debian init script:
http://pkgs.fedoraproject.org/cgit/rpms/zfs-fuse.git/tree/


PPS. The init scripts (but does not use) the "/etc/default ENABLE_FOO" anti-
pattern. It should really be dropped in favour of letting the sysadmin
run "update-rc.d zfs-fuse disable" if they want the service disabled.


diff -Nru zfs-fuse-0.7.0/debian/changelog zfs-fuse-0.7.0/debian/changelog
--- zfs-fuse-0.7.0/debian/changelog 2015-06-27 04:28:34.0 +0200
+++ zfs-fuse-0.7.0/debian/changelog 2016-05-25 21:22:05.0 +0200
@@ -1,3 +1,19 @@
+zfs-fuse (0.7.0-13.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/zfs-fuse.service (Closes: #796705)
+- this is a simple wrapper around the init script with room for
+  improvement. Mostly copied from the by systemd-sysv-generator
+  autogenerated unit with minor modifications. Future work would be
+  to split out the program parts of the init script
+  (upgrade_zpool_cache_location(), et.al.), run that from
+  ExecStartPre= and turn the rest into a real native unit file
+  supporting monitoring/restarting of the daemon, etc.
+   * Add dh-systemd build-dependency and --with systemd to debian/rules.
+ - to activate helpers that takes care of the above unit file.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Wed, 25 May 2016 21:08:21 +0200
+
 zfs-fuse (0.7.0-13) unstable; urgency=medium
 
   * Fix ""zfs list -t snapshot" missing entries" (Closes: #780308)
diff -Nru zfs-fuse-0.7.0/debian/control zfs-fuse-0.7.0/debian/control
--- zfs-fuse-0.7.0/debian/control   2014-06-28 02:34:47.0 +0200
+++ zfs-fuse-0.7.0/debian/control   2016-05-25 21:08:19.0 +0200
@@ -2,7 +2,7 @@
 Section: otherosfs
 Priority: optional
 Maintainer: Asias He <as...@debian.org>
-Build-Depends: debhelper (>= 7.0.50~), scons, libfuse-dev (>= 2.8.7-2), 
zlib1g-dev, libaio-dev, libssl-dev, libattr1-dev, autotools-dev
+Build-Depends: debhelper (>= 7.0.50~), dh-systemd (>= 1.5), scons, libfuse-dev 
(>= 2.8.7-2), zlib1g-dev, libaio-dev, libssl-dev, libattr1-dev, autotools-dev
 Standards-Version: 3.9.2
 Homepage: http://zfs-fuse.net
 Vcs-Git: git://git.debian.org/collab-maint/zfs-fuse.git
diff -Nru zfs-fuse-0.7.0/debian/rules zfs-fuse-0.7.0/debian/rules
--- zfs-fuse-0.7.0/debian/rules 2014-06-28 02:41:32.0 +0200
+++ zfs-fuse-0.7.0/debian/rules 2016-05-25 21:08:01.0 +0200
@@ -35,4 +35,4 @@
dh_installinit --no-start -- start 38 S . stop 39 0 6 .
 
 %:
-   dh $@
+   dh $@ --with systemd
diff -Nru zfs-fuse-0.7.0/debian/zfs-fuse.service 
zfs-fuse-0.7.0/debian/zfs-fuse.service
--- zfs-fuse-0.7.0/debian/zfs-fuse.service  1970-01-01 01:00:00.0 
+0100
+++ zfs-fuse-0.7.0/debian/zfs-fuse.service  2016-05-25 21:07:44.0 
+0200
@@ -0,0 +1,22 @@
+[Unit]
+Documentation=man:zfs-fuse(8)
+Description=Daemon for ZFS support via FUSE
+DefaultDependencies=no
+Before=sysinit.target
+Before=shutdown.target
+After=remote-fs.target
+Conflicts=shutdown.target
+
+[Service]
+Type=forking
+Restart=no
+TimeoutSec=0
+IgnoreSIGPIPE=no
+KillMode=process
+GuessMainPID=no
+RemainAfterExit=yes
+ExecStart=/etc/init.d/zfs-fuse start
+ExecStop=/etc/init.d/zfs-fuse stop
+
+[Install]
+WantedBy=sysinit.target

Bug#796602: will upload the attached ebtables debdiff to delayed

2016-05-25 Thread Andreas Henriksson

Hello!

I'm going to upload the attached ebtables NMU diff to the delayed
queue shortly to resolve this bug report.

Regards,
Andreas Henriksson
diff -Nru ebtables-2.0.10.4/debian/changelog ebtables-2.0.10.4/debian/changelog
--- ebtables-2.0.10.4/debian/changelog  2016-02-07 21:46:35.0 +0100
+++ ebtables-2.0.10.4/debian/changelog  2016-05-25 20:37:15.0 +0200
@@ -1,3 +1,13 @@
+ebtables (2.0.10.4-3.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add native systemd unit file ebtables.service (Closes: #796602)
+- this is basically just a wrapper around the init script.
+  * Add dh-systemd (>= 1.5) build dependency for the above.
+- accompanying cdbs versioned dependency was already new enough.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Wed, 25 May 2016 20:34:14 +0200
+
 ebtables (2.0.10.4-3.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ebtables-2.0.10.4/debian/control ebtables-2.0.10.4/debian/control
--- ebtables-2.0.10.4/debian/control2016-02-05 02:05:14.0 +0100
+++ ebtables-2.0.10.4/debian/control2016-05-25 20:28:54.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Jochen Friedrich <joc...@scram.de>
 Uploaders: William Dauchy <wdau...@gmail.com>
 Standards-Version: 3.9.6
-Build-Depends: debhelper (>= 9), cdbs (>= 0.4.127)
+Build-Depends: debhelper (>= 9), cdbs (>= 0.4.127), dh-systemd (>= 1.5)
 Homepage: http://ebtables.sourceforge.net
 
 Package: ebtables
diff -Nru ebtables-2.0.10.4/debian/ebtables.service 
ebtables-2.0.10.4/debian/ebtables.service
--- ebtables-2.0.10.4/debian/ebtables.service   1970-01-01 01:00:00.0 
+0100
+++ ebtables-2.0.10.4/debian/ebtables.service   2016-05-25 20:32:15.0 
+0200
@@ -0,0 +1,19 @@
+[Unit]
+Description=ebtables ruleset management
+DefaultDependencies=no
+Before=network-pre.target
+Wants=network-pre.target
+After=local-fs.target
+# n.b. use below if we want to tear down rules before shutting down.
+#Before=shutdown.target
+#Conflicts=shutdown.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=/etc/init.d/ebtables start
+ExecStop=/etc/init.d/ebtables stop
+ExecReload=/etc/init.d/ebtables reload
+
+[Install]
+WantedBy=multi-user.target

Bug#791907: [Pkg-sysvinit-devel] Bug#791907: bootlogd RC bug now on my radar.

2016-05-25 Thread Andreas Henriksson

Hello!

On Mon, May 23, 2016 at 08:50:55PM +0200, Petter Reinholdtsen wrote:
[...]
> The approach look good to me. :)

Thanks for looking at this! I've pushed the changes to pkg-sysvinit git.
Hopefully someone comes along and does an upload soon, but otherwise
I might just go ahead with a NMU after a while to get these bug reports
off my RC bug radar

Regards,
Andreas Henriksson

Bug#791907: [Pkg-sysvinit-devel] Bug#791907: bootlogd RC bug now on my radar.

2016-05-23 Thread Andreas Henriksson

Control: tags -1 + patch

Hello all.

On Thu, May 12, 2016 at 07:01:43PM +0200, Petter Reinholdtsen wrote:
> 
> I agree that the description update might be a good solution.  bootlogd
> solve a real problem with sysvinit, where it become possible to know
> what happened during boot because the log messages are available after
> boot, and also on headless boot.

Thanks for the information that it's still useful.

> This problem do not exist with systemd, so bootlogd do not have any
> purpose with systemd, as I see it.
> It do not do any harm, but it do not really solve anything either.
> Making this clear for the user should solve the RC bug, I believe.

I'm not a fan of saying RC bugs are solved by package description
updates as in my experience few people read those anyway, but possibly
this bug should not have RC severity to begin with...

Anyway, I've spent some time looking into this and would like to hear
comments on the attached patch. I've already discussed with pkg-systemd
about them dropping bootlogd.service masking for full effect once this
is uploaded Please see patch header for further information.
Hopefully the patch is simple enough while still leaving no user
in doubt about where to find the boot information.

Help with testing on a sysvinit system would also be much appreciated.

Regards,
Andreas Henriksson
>From 17a229641fb1acd3b11000ae528dac54deedd191 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 23 May 2016 17:10:15 +0200
Subject: [PATCH] bootlogd: mention it won't do anything under systemd

Update package description as well as the initial log file that's
created under /var/log/boot to indicate that system console messages
aren't universally available.

Also make the main bootlogd init script writes a message to
/var/log/boot suggesting journalctl instead when starting.
This should avoid outdated and confusing boot logs lingering for
systems upgraded from wheezy or for people switching back and
forth between init systems.
Note that systemd package will need to drop the mask of bootlogd.service
for this to work. Also note that systemd package might not be carrying
the rcS support patch for much longer which means this script will
not be executed at all under systemd in the future.

Closes: #791907
---
 debian/bootlogd.postinst| 2 +-
 debian/control  | 4 
 debian/src/bootlogd/etc/init.d/bootlogd | 8 
 debian/src/bootlogd/etc/init.d/stop-bootlogd| 1 +
 debian/src/bootlogd/etc/init.d/stop-bootlogd-single | 1 +
 5 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/debian/bootlogd.postinst b/debian/bootlogd.postinst
index cc0dedb..eddd421 100644
--- a/debian/bootlogd.postinst
+++ b/debian/bootlogd.postinst
@@ -18,7 +18,7 @@ for F in /var/log/boot
 do
 	if [ ! -f "$F" ] && touch "$F" >/dev/null 2>&1
 	then
-		echo "(Nothing has been logged yet.)" >| "$F"
+		echo "(Nothing has been logged yet. If you're still seeing this message your current init system might not write bootup messages to the system console at all.)" >| "$F"
 		chown root:adm "$F"
 		chmod 640 "$F"
 	fi
diff --git a/debian/control b/debian/control
index f9efc03..7add446 100644
--- a/debian/control
+++ b/debian/control
@@ -153,3 +153,7 @@ Breaks: sysvinit-utils (<< 2.88dsf-17), initscripts (<< 2.88dsf-17)
 Description: daemon to log boot messages
  bootlogd logs all messages printed to the system console during system boot,
  and records those messages to a logfile.
+ .
+ Note that not all init systems print messages to the system console,
+ so that the logfile may remain empty; this is the case with systemd
+ (the default init system). Try "journalctl -b" instead.
diff --git a/debian/src/bootlogd/etc/init.d/bootlogd b/debian/src/bootlogd/etc/init.d/bootlogd
index 3460b2d..3615eb2 100644
--- a/debian/src/bootlogd/etc/init.d/bootlogd
+++ b/debian/src/bootlogd/etc/init.d/bootlogd
@@ -35,6 +35,14 @@ case "$0" in
 	;;
 esac

+if [ -d /run/system/system ]; then
+	if [ "$ACTION" = start ] && [ -f /var/log/boot ]; then
+		echo "(Booted up using systemd which doesn't write logs to system console. Please check 'journalctl -b' instead.)" > /var/log/boot
+	fi
+	log_daemon_msg "Skipping $NAME while running systemd"
+	exit 0
+fi
+
 case "$ACTION" in
   start)
   	# PATH is set above
diff --git a/debian/src/bootlogd/etc/init.d/stop-bootlogd b/debian/src/bootlogd/etc/init.d/stop-bootlogd
index 1797b7d..7c17328 100644
--- a/debian/src/bootlogd/etc/init.d/stop-bootlogd
+++ b/debian/src/bootlogd/etc/init.d/stop-bootlogd
@@ -13,6 +13,7 @@ NAME=stop-bootlogd
 DAEMON=/sbin/bootlogd

 [ -x "$DAEMON" ] || exit 0
+[ -d /run/systemd/system ] && exit 0

 case "$1"

Bug#810018: procps-base: some additional init-d-script info in the quest...

2016-05-21 Thread Andreas Henriksson

Hello!

This information is not directly related to procps, but it is
kind of related to the reason why we'd want to introduce procps-base
as there's no big point in doing it if we can't also make sysvinit-utils
non-essential. Also we don't really have a good tracking bug so posting
here to archive the information somewhere before I forget about it

I've looked closer at the users of /lib/init/init-d-script which was
mentioned in a previous post that some packages init script unconditionally
sources. Apparently "new school" init scripts as generated by current
dh-make and as visible in /etc/init.d/skeleton is the reason for these
unconditional sourcing of the file which causes problems if we downgrade
sysvinit-utils (which ships /lib/init/init-d-script) to non-essential.

Given this style of init script is apparently the currently recommended
form, I assume we can see the number of packages using it rise over
time...
The problem should be (partially?) less problematic if the package
using "new school" init script also ships a native systemd unit
file, which should avoid the init script being executed at all...
(Though some people still manually execute init scripts even under
systemd out of old habits and this only works because systemd
ships an LSB hook that catches this and issues systemctl seamlessly.)



a) packages shipping an init script that uses /lib/init/init-d-script according 
to codesearch.d.n
b) if it's not a big practical issue, because the init script will not be used 
under systemd.

pkg has masking systemd unit file

sddmyes
coquelicot  yes
open-iscsi  yes
graphite-apiyes
apache2 no! (only partial snippet to extend 
autoconverted script)
batmand yes
netplan no! (but carries own fallback copy of 
init-d-script!)
courier-authdaemon  yes
uwsgi-emperor   no!
opendnssec-signer   yes
kxd yes
lvm2yes
waagent yes
prometheus  yes
dbabyes (also carries own fallback copy of 
init-d-script!)
prometheus-pgbouncer-exporter   yes
shairport-sync  yes
freeipmi-ipmiseld   no!
knot-resolver   yes
prometheus-mysqld-exporter  yes
hhvmyes
prometheus-pushgateway  no!
courier-mta yes
prometheus-node-exporterno!


The investigation was done using (so might very well be incomplete):

for pkg in  ; do
apt-file show $pkg | grep -e 'init.d' -e 'systemd/system'
done

TODO: Investigate what happens if executing such an init script directly
under systemd where normally systemd-installed LSB hooks would override
it and use systemctl...


Regards,
Andreas Henriksson

Bug#804966: procps: heads up on dropping initscripts dependency

2016-05-21 Thread Andreas Henriksson

Hello!

Just a little heads up, as I noticed this bug was tagged pending.
I recently dropped the (indirect) initscripts dependency from util-linux
and ran into some issues, which I'm now carrying a workaround for in
util-linux:
http://sources.debian.net/src/util-linux/2.28-5/debian/util-linux.postinst/#L15

The problem is that when dropping the dependency you're also dropping
the ordering of which packages might become configured.  This means
debootstrap might decide to configure your package before it configures
initscripts (which is still installed in default installations even if
noone depends on it because of it's priority field). If your package
becomes configured it'll call out (indirectly) to insserv which does not
like to configure things which has LSB header dependencies on other
things which has not yet been run over by insserv.  Only very few
packages will likely run into this issue but I think it might be worth
to know about for procps A generic solution is in the works, see
https://bugs.debian.org/824804

Hopefully procps is not affected by this, but might be worth stalling
the next upload until 824804 is fixed (and bump versioned dependency
on init-system-helpers to the fixed version?!).

Regards,
Andreas Henriksson

Bug#824793: mount.8: refers to package nfs-utils

2016-05-20 Thread Andreas Henriksson

Control: tags -1 + wontfix

On Thu, May 19, 2016 at 04:11:11PM -0400, Greg Wooledge wrote:
> Package: mount
> Version: 2.25.2-6
> Severity: normal
> 
> In the "Mount options for nfs and nfs4" section, the mount(8) man page
> says "nfs-utils package must be installed".  It should say nfs-common
> instead.

While I do understand that this can easily be confusing...
... The (Debian!) nfs-common package is built from the nfs-utils source.
We ship the upstream manpages and there is no "nfs-common" in the
upstream world. Splitting nfs-utils apart in different parts is
a Debian thing. Please see:

https://tracker.debian.org/pkg/nfs-utils

Thus such a patch would not be useful upstream and maintaining it
downstream is not in my interest.

Potentially there's room for making the wording less confusing in a
Debian context upstream, like eg. using "suite" instead of "package".
Please feel free to submit a patch to upstream! If you're not
familiar with the procedure please feel free to ask me for guidance.

Regards,
Andreas Henriksson

Bug#824677: aiccu: please depend on iproute2 instead of iproute transitional package

2016-05-18 Thread Andreas Henriksson

Hello Jeroen Massar.

Thanks for your quick reply.

On Wed, May 18, 2016 at 09:49:45PM +0200, Jeroen Massar wrote:
> Would love to update this, but unfortunately we do not get commit-alike
> access..

We should solve this. I'm sure we can work something out. Having the
package unmaintained isn't optimal for anyone.

> 
> Thus please do a NMU for that simple fix, as no Debian Developer is
> currently assigned to the aiccu package... ;(
> 
> If somebody can sponsor uploads though, we would love to know about that.

I should be able to sponsor, but I'm not a very good mentor because
of lack of time. AIUI getting sponsored is now a more formalized process
where you can actually file a bug report about needing a sponsor...

Please see [1] and [2].

[1] 
https://wiki.debian.org/DebianMentorsFaq#What_happens_if_I_can.27t_find_a_sponsor.3F
[2] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;dist=unstable

Regards,
Andreas Henriksson

Bug#824677: aiccu: please depend on iproute2 instead of iproute transitional package

2016-05-18 Thread Andreas Henriksson

Package: aiccu
Version: 20070115-15.3
Severity: normal

Dear Maintainer,

Please update the aiccu package dependencies to use 'iproute2' instead
of the transitional package 'iproute'.

The transition from the old iproute package name to iproute2 happened in
Debian Jessie, so the transitional package are now ready to be removed.
If your package is not updated by then it'll become uninstallable (and
thus RC-buggy).

Regards,
Andreas Henriksson

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

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

Bug#824681: sitesummary-client: please recommend iproute2 instead of iproute transitional package

2016-05-18 Thread Andreas Henriksson

Package: sitesummary-client
Version: 0.1.20
Severity: normal

Dear Maintainer,

Please update your package recommends to use 'iproute2' instead
of the transitional package 'iproute'.

The transition from the old iproute package name to iproute2 happened in
Debian Jessie, so the transitional package are now ready to be removed.
If your package is not updated by then installs of it will be missing
recommended parts.

Regards,
Andreas Henriksson

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

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

Bug#824680: mysql-mmm-agent: please depend on iproute2 instead of iproute transitional package

2016-05-18 Thread Andreas Henriksson

Package: mysql-mmm-agent
Version: 2.2.1-1.1
Severity: normal

Dear Maintainer,

Please update the mysql-mmm-agent package dependencies to use 'iproute2'
instead of the transitional package 'iproute'.

The transition from the old iproute package name to iproute2 happened in
Debian Jessie, so the transitional package are now ready to be removed.
If your package is not updated by then it'll become uninstallable (and
thus RC-buggy).

Regards,
Andreas Henriksson

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

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

Bug#824682: vpnc: please recommend iproute2 instead of iproute transitional package

2016-05-18 Thread Andreas Henriksson

Package: vpnc
Version: 0.5.3r550-2+b1
Severity: normal

Dear Maintainer,

Please update your package recommends to use 'iproute2' instead
of the transitional package 'iproute'.

The transition from the old iproute package name to iproute2 happened in
Debian Jessie, so the transitional package are now ready to be removed.
If your package is not updated by then installs of it will be missing
recommended parts.

Regards,
Andreas Henriksson

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

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

Versions of packages vpnc depends on:
ii  dpkg  1.18.7
ii  libc6 2.22-7
ii  libgcrypt20   1.7.0-2
ii  libgnutls30   3.4.11-4
ii  perl  5.22.2-1
ii  vpnc-scripts  0.1~git20150318-1

Versions of packages vpnc recommends:
ii  iproute  1:4.3.0-1

Versions of packages vpnc suggests:
ii  resolvconf  1.78

-- Configuration Files:
/etc/vpnc/default.conf [Errno 13] Permission denied: u'/etc/vpnc/default.conf'

-- no debconf information

Bug#824679: ipkungfu: please depend on iproute2 instead of iproute transitional package

2016-05-18 Thread Andreas Henriksson

Package: ipkungfu
Version: 0.6.1-6.1
Severity: normal

Dear Maintainer,

Please update the ipkungfu package dependencies to use 'iproute2' instead
of the transitional package 'iproute'.

The transition from the old iproute package name to iproute2 happened in
Debian Jessie, so the transitional package are now ready to be removed.
If your package is not updated by then it'll become uninstallable (and
thus RC-buggy).

Regards,
Andreas Henriksson

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

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

Bug#824678: arno-iptables-firewall: please depend on iproute2 instead of iproute transitional package

2016-05-18 Thread Andreas Henriksson

Package: arno-iptables-firewall
Version: 2.0.1.f-1
Severity: normal

Dear Maintainer,

Please update the arno-iptables-firewall package dependencies to use
'iproute2' instead of the transitional package 'iproute'.

The transition from the old iproute package name to iproute2 happened in
Debian Jessie, so the transitional package are now ready to be removed.
If your package is not updated by then it'll become uninstallable (and
thus RC-buggy).

Regards,
Andreas Henriksson

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

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

Bug#797074: libical2 transition now ready to start!

2016-05-17 Thread Andreas Henriksson

On Mon, May 16, 2016 at 09:29:00PM +0200, Emilio Pozuelo Monfort wrote:
> libical is already in testing.

Oh!

[...]

> From your side it's all done now, so you can stop worrying about this. :)

Great, thanks! :)

Regards,
Andreas Henriksson

Bug#824358: ITP: freerdp2 -- RDP client/server for Windows Terminal Services

2016-05-16 Thread Andreas Henriksson

Hello Mike Gabriel.

Thanks for looking at packaging a newer freerdp snapshot! I have
some questions and doubts below...

On Sun, May 15, 2016 at 12:53:07AM +0200, Mike Gabriel wrote:
[...]
> * Package name: freerdp2
>   Version : 2.x (Git snapshot)
[...]
>  The new major upstream version (well, upstream is not tagging versions,
>  but we have one upstream dev on the packaging team who recommends Git
>  snapshots) provides new ABI/API. This new source will supercede the
>  currently available Debian source package "freerdp".

With new API/ABI a transition is needed (and hopefully upstream properly
handles SONAME despite not doing releases), but renaming the source
package is not normally how you do a transition.

>  .
>  From now on, upstream will support parallel installations of multiple
>  major upstream releases.

This bit is quite confusing as you just said upstream doesn't do releases.

>  So shipping both FreeRDP versions in Debian unstable for a while is
>  possible.

Given the lack of followup on existing bug reports do you really
think you have the resources to support multiple versions?!

Please explain a bit more about how you intend to support multiple
versions? For example how do you intend to handle the naming
of pkg-config files, rename or make the -dev packages conflict?

>  However, only freerdp2 will be made available in Debian 9.

Apparently not and you seem to underestimate the amount of work
needed to get something removed from the archive! Are you sure
you'll manage to get down to only one version again before the
stretch release? How?
As mentioned renaming the source package is not how you normally do a
transtion (only when you want to support multiple versions which you
apparently don't want). Please consider handling this like a normal
transition.

>  .
>  Packages depending on FreeRDP shared libraries should start migrating
>  their packages to the new ABI/API for FreeRDP 2.x.

Again, please share some information on how you intend to package
to make it possible to prepare. Likely you're creating extra work
here when not following the normal transition workflow.

>  .
>  A transition bug will be file for monitoring this change-over,
>  once the freerdp2 src:package has landed in unstable.

An automatic tracker would be available on
https://release.debian.org/transitions/
if you followed the normal transition workflow which would be
even better.

Looking forward to hearing more details about your plans to be able to
prepare for the transition.

Regards,
Andreas Henriksson

Bug#823893: libarchive: CVE-2016-1541

2016-05-16 Thread Andreas Henriksson

Hello Simon McVittie.

On Mon, May 16, 2016 at 10:12:19AM +0100, Simon McVittie wrote:
[...]
> uploaded to DELAYED/5. Diff attached, or available here:
> ssh://alioth.debian.org/srv/home/users/smcv/public_git/libarchive.git
> 
> If you would like it accelerated or cancelled, please let me know; or

Please feel free to go ahead with NMU without delay (as already mentioned
to Salvatore)!

> if you decide to go ahead with 3.2.0 or a 3.1.2-12 maintainer upload
> in unstable so that my NMU is superseded and rejected, that's also fine
> of course.

I'll focus on 3.2.0 myself which means I'll likely just ignore your NMU
if you base it on 3.1.2 when I feel 3.2.0 is ready to go to unstable
(unless you have strong opinions on having your NMU changelog entry
merged).

> 
> I'll open a separate bug for the test failure. Since you are the
> libarchive maintainer, you get to decide whether you consider failures on
> the non-release kFreeBSD architectures to be RC. Because the kFreeBSD
> architectures aren't release architectures, I believe out-of-date
> binaries on those architectures don't slow down testing migration,
> so fixing the security vulnerability on Linux doesn't need to block on
> fixing the tests on kFreeBSD.

Thanks. I don't consider kfreebsd a "real" blocker as this bug should
not be RC, but given that AFAIK libarchive has a pretty exploding
reverse dependency chain many important parts of the archive could
quickly become unbuildable I thought it would be nice to give the
kfreebsd porters a chance to reply to
https://lists.debian.org/debian-bsd/2016/05/msg00032.html
before proceeding. Not that I have super high hopes of getting a reply
and I'll certainly not wait forever... just giving them a chance (so
in another week or a bit more maybe I'll just upload).

Regards,
Andreas Henriksson

PS. Help maintaining libarchive welcome!

Bug#797074: libical2 transition now ready to start!

2016-05-16 Thread Andreas Henriksson

Hello release team!

On Tue, May 10, 2016 at 01:44:36PM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 06/05/16 09:44, Andreas Henriksson wrote:
> > Control: tags -1 =
> > 
> > The libical testsuite/FTBFS bugs should now be fixed in experimental
[...]
> Go ahead.

A quick followup from me to summarize where I think we are now:

The new libical was uploaded and Emilio triggered binNMU for the packages
which was suitable for that. They've now all built on all architectures.
Some sourceful uploads where done despite the ongoing transition, for
example gnome-todo, gnome-calendar. Also the required sourceful uploads
of citadel and webcit just happened. All of these might be useful to age.
The remaining problematic packages which should be possible to handle
via temporary removal from testing are syncevolution (#824426) and
ical2html (#822565).

If I've not made any mistakes as far as I see it you should now with
some force be able to push things into testing and finalize the
transition.

Regards,
Andreas Henriksson

Bug#824426: FTBFS against libical2

2016-05-16 Thread Andreas Henriksson

Hello!

Some information below which might be useful

On Sun, May 15, 2016 at 09:37:24PM +0200, Michael Biebl wrote:
> Source: syncevolution
> Version: 1.4.99.4-5
> Severity: serious
> 
> Hi,
> 
> during the libical transition [1], your package syncevolution was
> rebuilt and it now FTBFS:
[...]
> src/syncevo/.libs/libsyncevolution.so: undefined reference to
> `ical_tzid_prefix'
[...]

I've quickly looked into this issue since it was discovered
(sorry I missed spotting it before the transition started).

The global variable referenced above is indeed gone (in general
libical seems to be moving away from global variables in 2.0.0
in favour of accessor methods). The new accessor function to
get the value is called icaltimezone_tzid_prefix(). See:
http://sources.debian.net/src/libical/2.0.0-0.4/src/libical/icaltimezone.c/?hl=150#L150

I looked upstream but there seemed to be very little activity in recent time.
Possibly there's some bug tracker or mailing list post somewhere, but I
didn't search that far.

The libical2 transition has already been done in fedora so for comparison
they're patching their syncevolution, see:
http://pkgs.fedoraproject.org/cgit/rpms/syncevolution.git/tree/syncevolution-1.5.1-libical2.patch

IMNSHO the fedora patch is an ugly hack since duplicating the information
instead of using accessor method isn't nice IMO. OTOH I've looked at
syncevolutions usage of the global variable and if we're going to replace
it we see it in two places. The one failing the build above + in the
syncevolution homebrew/duplicated evolution(-data-server?) API.
That one looks too scary to touch for me who has no way to test this
so I sympathize with fedoras patch and maybe it's better to go that
route. Also, the get accessor seems to be missing from the libical2.symbols
for some reason so might need fixes on the libical side to be properly
exported....

Regards,
Andreas Henriksson

Bug#824092: [Pkg-xfce-devel] Bug#824092: orage: FTBFS on amd64, i386, arm64, armel, armhf buildds

2016-05-12 Thread Andreas Henriksson

Hello Yves-Alexis Perez.

Thanks for your quick followup. Some additional information from
me below which maybe I should have remembered to include in
my initial mail. Not sure how useful it is though...

On Thu, May 12, 2016 at 05:05:30PM +0200, Yves-Alexis Perez wrote:
> On jeu., 2016-05-12 at 09:49 +0200, Andreas Henriksson wrote:
> > It seems since the last sourceful upload (4.12.1-2) the package started
> > failing to build from source on some architectures.
> > 
> > See https://buildd.debian.org/status/package.php?p=orage
> 
> I've checked the log for amd64, and it seems that the error is:
> 
> checking for gtk+-2.0 >= 2.14.0... not found
> *** The required package gtk+-2.0 was not found on your system.
> *** Please install gtk+-2.0 (atleast version 2.14.0) or adjust
> *** the PKG_CONFIG_PATH environment variable if you
> *** installed the package in a nonstandard prefix so that
> *** pkg-config is able to find it.
>   "tail -v -n +0 config.log"
> 
> Which doesn't make sense considering libgtk2.0-dev (>= 2.10.1) is in build-
> depends.

I've also quickly looked at the build logs and the sources to confirm
that the gtk+-2.0 development packages seems to be successfully installed
during the build and should be findable via pkg-config.

My gut feeling is rather that there might be something wrong with the
home-brew m4 macros, since searching for gtk+2.0 is just the first time
the home-brew macro is used in the configure script
Move searching for gtk+-2.0 further down and I'd assume you'll instead
see an error for something else which would then be the first thing
search for using the home-brew macro XDT_CHECK_PACKAGE ...
Makes me wonder why the normal PKG_CHECK_MODULES macros doesn't suffice?

http://sources.debian.net/src/orage/4.12.1-2/configure.in/#L84
http://sources.debian.net/src/orage/4.12.1-2/aclocal.m4/#L10810

> 
> I think we need to reschedule the builds, I'll ask that, but I don't think the
> problem lies in the package.

If I'm not mistaken there where recent binNMU attempts because of the
ongoing libical transition.

Regards,
Andreas Henriksson

Bug#791907: bootlogd RC bug now on my radar.

2016-05-12 Thread Andreas Henriksson

Hello Vincent Lefevre.

On Thu, May 12, 2016 at 03:56:43PM +0200, Vincent Lefevre wrote:
> On 2016-05-12 14:56:38 +0200, Andreas Henriksson wrote:
> > Also, it's still unknown /why/ bootlogd doesn't work with systemd!
> > Apparently bootlogd relies on some facitily not provided by systemd.
> 
> Well, the bootlogd description says:
> 
>   bootlogd logs all messages printed to the system console during
>   system boot, and records those messages to a logfile.
> 
> However, with systemd, nothing seems to be written to the system console
> (well, nothing appears, but I don't know whether something is printed
> but hidden or nothing is printed). This may be the cause.

Thanks for this useful information.

> 
> If a conflict is not possible (at least, bootlogd doesn't seem to hurt),
> I think that having a clear description would be sufficient. Something
> like:
> 
> Description: daemon to log boot messages printed to the system console
>  bootlogd logs all messages printed to the system console during system boot,
>  and records those messages to a logfile.
>  Note that not all init systems print messages to the system console,
>  so that the logfile may remain empty; this is the case with systemd.

While a package description update certainly would be an improvement I'm
not personally totally convinced that would be enough to consider this
bug adressed. On the other hand I really don't have an opinion on how
this is dealt with I'm just interested in getting this bug report off
the RC radar.

> 
> Someone might also want to add a systemd unit file that writes a
> message saying that bootlogd does nothing with systemd, which has
> its own logging system (systemd journal).

If it's possible to create a systemd unit which causes such a message to
be written and logged by bootlogd when booting under systemd would be
possibly the best solution and definitely adress atleast the RC part
of this issue.

Would be great if you're willing to implement your above mentioned
suggestion (either one or both). If needed I could do review
and sponsorship once there's a debdiff available.

Would also be very much appreciated if you wanted to check with
other participants in this bug report (and its duplicate) to verify
they're in agreement on you solution being something they consider
solving it in their view.

Regards,
Andreas Henriksson

Bug#791907: bootlogd RC bug now on my radar.

2016-05-12 Thread Andreas Henriksson

Hello!

This RC bug report has started appearing on my "Maintainer dashboard"
( https://udd.debian.org/dmd/ ) since my sysvinit NMU.

While at first look it seemed simple to get out of the way by just
declaring a package relationship, on second thought it's not that
easy...

bootlogd conflicting with systemd-sysv isn't sufficient since people can
boot with systemd even without having systemd-sysv installed.
Also what would apt do if this relation is there and someone tries to
install bootlogd?  I guess apt might try to satisfy the relation by
removing systemd-sysv and installing some other init system which seems
like a horrible thing to do to users who aren't paying attention and
blindly trusts apt (which many seems to do according to my experience
with bug triaging and user interaction).

Declaring a conflicts against systemd package would also not be right
since it's quite likely people will have that package installed even
when they're using another init system.

(I've also asked systemd maintainers for advice on the above but
they wanted to avoid getting involved in this and said it's up to
bootlogd maintainers.)

Also, it's still unknown /why/ bootlogd doesn't work with systemd!
Apparently bootlogd relies on some facitily not provided by systemd. The
relation should likely be described as a Depends against whatever
provides the required facility, rather than a conflicts against systemd!

Last but not least, this is from the bootlogd source:

> * *NOTE* *NOTE* *NOTE*
> * This is a PROOF OF CONCEPT IMPLEMENTATION

http://sources.debian.net/src/sysvinit/2.88dsf-59.4/src/bootlogd.c/#L28

We should probably not ship something just because it compiles, specially
not when it contains an explicit warning about its status.

I'm thus leaning towards simply stop shipping the bootlogd package
by disabling the Package: bootlogd part of sysvinit debian/control
if solving this RC bug is left up to me.
(There are no reverse dependencies of bootlogd package in stretch or sid.)

Regards,
Andreas Henriksson

Bug#824092: orage: FTBFS on amd64, i386, arm64, armel, armhf buildds

2016-05-12 Thread Andreas Henriksson

Package: orage
Version: 4.12.1-2
Severity: serious
Justification: FTBFS on official buildds
Control: block 797074 by -1

Dear Maintainer,

It seems since the last sourceful upload (4.12.1-2) the package started
failing to build from source on some architectures.

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

I've tried to reproduce the problem locally (building in pbuilder) but
there the package built successfully. :/

FYI, given that orage is part of the currently ongoing libical
transition this issue is quite urgent.
https://release.debian.org/transitions/html/auto-libical.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797074

Your help in resolving this issue as soon as possible would be
very much appreciated!

Regards,
Andreas Henriksson

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

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

Bug#821347: libsecret testsuite failures on mipsel

2016-05-11 Thread Andreas Henriksson

Hello Aurelien Jarno.

Thanks for so quickly and thoroughly investigating these issues!

On Wed, May 11, 2016 at 05:39:08PM +0200, Aurelien Jarno wrote:
[...]
> A workaround might be to always build libsecret on the octeon build
> daemons. Currently that means the package might stay much longer in
> the build queue before being built, but we should deploy more of such
> machines in the next weeks. Otherwise it needs a deeper investigation
> which will take more time, as one has to understand the code to be
> able to debug it.

I think taking the longer build times is something we can definitely
live with given the current circumstances, since it would ofcourse
be a big improvement over not getting the builds through at all!

Regards,
Andreas Henriksson

Bug#823984: libarchive13/unstable is older than libarchive13/stable

2016-05-11 Thread Andreas Henriksson

Hello Vincent Lefevre.

On Wed, May 11, 2016 at 09:34:56AM +0200, Vincent Lefevre wrote:
> On 2016-05-11 06:41:43 +0200, Salvatore Bonaccorso wrote:
> > Please see #823893 for why this has not yet seen as well an update in
> > unstable.
> 
> OK, but a decision should be made quickly. If 3.2.0 is not ready yet
> for unstable due to potential regressions, then a patched 3.1.2 should
> be uploaded to unstable (basically with the same as patch as stable,
> since the current version is exactly the same as the stable version
> before the security update). IMHO, this latter solution is probably
> better for testing; and if users see a regression in 3.2.0, they will
> be able to downgrade to the patched 3.1.2.

The decision to support multiple architectures and treat them all
equally (meaning all users will have to suffer if there is problem on
only one of them) has already been made long ago in the Debian project
and I don't see it up for discussion, no matter how much I'd also like
to see it change.
See the infamous Vancouver meeting for the results of the discussion
when this came up last time!

The only way to get this more quickly resolved is getting your hands
dirty by helping out the kfreebsd porters and dig into investigating
the issue there.
See https://lists.debian.org/debian-bsd/2016/05/msg00032.html

It might be so that we simply ignore the problem on kfreebsd
and moves on without them, given that kfreebsd-* hasn't
qualified for being a release architecture but I'd like
feedback on the above from porters if possible first.

Now get busy solving the problem instead of annoying people
via the bts!

Regards,
Andreas Henriksson

Bug#821347: libsecret testsuite failures on mipsel

2016-05-10 Thread Andreas Henriksson

Hello mipsel porters!

The libsecret package currently suffers from FTBFS on mipsel
because of two testsuite failures and your help fixing these
would be much appreciated so we can move on elsewhere.

The problem is tracked in debian bug #821347 (CCed).

>From 
>https://buildd.debian.org/status/fetch.php?pkg=libsecret=mipsel=0.18.5-1=1461171471
> :

FAIL: test-session 4 /session/ensure-async-aes

FAIL: test-collection 18 /collection/delete-sync


Please note that the second failure also happens on s390x.
I've only contacted you in hope that your fixes might positively
effect the s390x build, but you might want to contact and join
forces with the s390x porters.

Thanks in advance.

Regards,
Andreas Henriksson

Bug#817848: libpeas with python2 loader split out just passed through NEW.

2016-05-10 Thread Andreas Henriksson

Control: retitle 817852 liferea: Please add libpeas-1.0-python2loader to Depends
Control: retitle 817936 roger-router: Please add libpeas-1.0-python2loader to 
Depends
Control: retitle 817848 gtranslator: Investigate adding 
libpeas-1.0-python2loader to Recommends/Suggests
Control: severity 817852 serious
Control: severity 817936 serious
Control: severity 817848 minor

Hello!

The new libpeas with python2 loader split out has just passed through the
binary-NEW queue. Please note the new package name which you'll need
to add a dependency on: libpeas-1.0-python2loader
It is ofcourse preferred that you port your package over to using
python3 since python2 will be deprecated, but adding the dependency
on libpeas-1.0-python2loader is an intermediate way to keep your
package functional. Please note that libpeas-1.0-python2loader is
is section oldlibs and is considered obsolete. It will be removed
in the future.

Specific to gtranslator is that adding a dependency is questionable
because:
a) upstream gtranslator git has completely removed support for plugins
b) only one or two very obscure plugins actually needs python2
c) usage of plugins with gtranslator is likely very uncommon
d) the plugins only seemed partially functional when I tested them
   so since they seem unmaintained having them *not* loaded might
   even be considered an improvement. ;)
I've thus retitled to investigate adding a Recommends/Suggests
and lowered the severity since gtranslator itself should stay
functional without the python2 loader.

Regards,
Andreas Henriksson

Bug#822569: libical 2.0.0-0.4 uploaded to unstable

2016-05-10 Thread Andreas Henriksson

Control: severity -1 serious

Hello!

The new libical 2.0.0-0.4 was just uploaded to unstable since we
got the green light on starting the transition (see Bug#797074).
This means your package will now FTBFS in sid and you should
upload a new version incorporating the previously supplied patch
(or fix the issue by other means) as soon as possible.

The release teams handling of transitions is a very scarce resource
so to avoid blocking things longer then necessary I'll go ahead
and NMU your package if I don't hear anything back very soon.
(Alternatively your package might get removed.)
Please speak up if you'll be able to handle the upload of
your package in a timely fashion or not!

Regards,
Andreas Henriksson

Bug#823893: libarchive: CVE-2016-1541

2016-05-10 Thread Andreas Henriksson

Hello Salvatore,

On Tue, May 10, 2016 at 10:38:27AM +0200, Salvatore Bonaccorso wrote:
> Hi Andreas,
[...]
> Makes sense then to wait for moving 3.2.0 to experimental. Thanks for
> the ack on NMU'ing. I might then as well fix unstable with the
> upstream patch.

FYI I just sent a mail to inquiry about help from kfreebsd porters and
get their view on if we should delay the upload of 3.2.0 to unstable.
The only blocker is kfreebsd as I see it, otherwise I'm ready to put it
in unstable.

https://lists.debian.org/debian-bsd/2016/05/msg00032.html

Hoping for feedback on the above to help me determine when we can get
3.2.0 uploaded to unstable. Hopefully they say it's not a big problem
for them to get out of date so I can proceed to upload....

Regards,
Andreas Henriksson

Bug#823856: util-linux mount -o move (vs mount --move)....

2016-05-10 Thread Andreas Henriksson

Hello Ben.

Thanks for your bug report.

On Mon, May 09, 2016 at 05:55:55PM +0100, Ben Hutchings wrote:
[...]
> In particular, this mount command now invokes util-linux's mount.  That
> refuses to perform a move if the source filesystem was not mounted from
> a block device.  There is no good reason for this and obviously it
> works with busybox and klibc's implementations of mount.

I mentioned this to Karel Zak (util-linux upstream maintainer) who said:
the "mount -o move" has never been supported by util-linux

He also mentioned the correct (for util-linux) syntax would be:
mount --move 

Does that satisfy your needs?

Regards,
Andreas Henriksson

Bug#823893: libarchive: CVE-2016-1541

2016-05-10 Thread Andreas Henriksson

Hello Salvatore Bonaccorso.

On Tue, May 10, 2016 at 08:12:48AM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Tue, May 10, 2016 at 06:34:05AM +0200, Salvatore Bonaccorso wrote:
> > Source: libarchive
> > Version: 3.1.2-11
> > Severity: grave
> > Tags: security upstream fixed-upstream
> > Justification: user security hole
> > Control: fixed -1 3.2.0-1
[...]
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

I'll make sure to include this in the 3.2.0-1 entry in debian/changelog
in future uploads.

[...]
> Attached is the debdiff I prepared for jessie-security, but the same
> patch would apply for unstable as well unless planning to move to
> 3.2.0-1 anyway.
[...]

Thanks! Please feel free to NMU at once as I'd prefer not having to touch
stable updates.

I'm torn on uploading 3.2.0 to unstable now because of regressing on
kfreebsd where we now have test failures because of FTBFS. Feel free to
NMU to unstable as well if you think it's urgent to get it fixed and
don't want to wait for giving kfreebsd porters time to look at the
regression.

Regards,
Andreas Henriksson

Bug#823884: mount crashes via fstab entry

2016-05-09 Thread Andreas Henriksson

Control: reassign -1 src:linux

Hello Gene S.

Thanks for your bug report. It seems your kernel is crashing
and then all bets are off what happens in userspace.

Reassigning this bug report

Regards,
Andreas Henriksson

On Mon, May 09, 2016 at 05:22:37PM -0700, Gene S wrote:
> Package: mount
> Version: 2.25.2-6
> Severity: important
> 
> Dear Maintainer,
> 
> -- System Information:
> Debian Release: 8.4
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.7-ckt9-5 (SMP w/4 CPU cores)
> Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages mount depends on:
> ii  libc6  2.19-18+deb8u4
> ii  libmount1  2.25.2-6
> ii  libselinux12.3-2
> ii  libsmartcols1  2.25.2-6
> 
> mount recommends no packages.
> 
> Versions of packages mount suggests:
> pn  nfs-common  
> 
> -- no debconf information
> 
> "mount /dvd" crashes, with the following line in /etc/fstab
>   /dev/sr0  /dvd  udf,iso9660  user,noauto  0  0
> where /dev/sr0 is a cd/dvd drive.
> 
> A command of the form "mount /dev/sr0 /mnt" works O.K.
> 
> Debug output to /var/log/kernlog follows, see below...
> 
> After the mount error exit, an attempt to "mount /dev/sr0 /mnt"
> fails with "/dev/sr0 already mounted" message.  A "umount /dev/sr0"
> fails with "/dev/sr0 not mounted" message.  The sr0 device is now
> unreachable/unusable until after a system reboot.
> 
> kernlog (relevant lines) >>>
> 
> May  9 11:40:51 gene64 vmunix: [326817.943679] BUG: unable to handle kernel 
> paging request at 
> May  9 11:40:51 gene64 vmunix: [326817.943785] IP: [] 
> udf_get_last_session+0x0/0x40 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.943860] PGD c01ef067 PUD 0 
> May  9 11:40:51 gene64 vmunix: [326817.943958] Oops: 0002 [#1] SMP 
> May  9 11:40:51 gene64 vmunix: [326817.944055] Modules linked in: udf 
> nvidia_uvm(PO) cp210x usbserial joydev nvidia(PO) ohci_pci ohci_hcd
> May  9 11:40:51 gene64 vmunix: [326817.944373] CPU: 2 PID: 16969 Comm: mount 
> Tainted: P   O  3.16.7-ckt9-5 #5
> May  9 11:40:51 gene64 vmunix: [326817.944423] Hardware name: BIOSTAR Group 
> TA970/TA970, BIOS 4.6.4 01/14/2013
> May  9 11:40:51 gene64 vmunix: [326817.944465] task: 8802250e1890 ti: 
> 8800c012 task.ti: 8800c012
> May  9 11:40:51 gene64 vmunix: [326817.944515] RIP: 0010:[] 
>  [] udf_get_last_session+0x0/0x40 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.944596] RSP: 0018:8800c0123d70  
> EFLAGS: 00010246
> May  9 11:40:51 gene64 vmunix: [326817.944637] RAX:  RBX: 
> 8801e97a0580 RCX: 0428
> May  9 11:40:51 gene64 vmunix: [326817.944686] RDX:  RSI: 
>  RDI: 880209cc2000
> May  9 11:40:51 gene64 vmunix: [326817.944735] RBP: 880209cc2000 R08: 
>  R09: 8801e97a0580
> May  9 11:40:51 gene64 vmunix: [326817.944784] R10: 5540 R11: 
> 01ea R12: 
> May  9 11:40:51 gene64 vmunix: [326817.944833] R13: 0001 R14: 
> a0867e50 R15: 880226049a40
> May  9 11:40:51 gene64 vmunix: [326817.944882] FS:  7f65bf9a6840() 
> GS:88022ed0() knlGS:f7707740
> May  9 11:40:51 gene64 vmunix: [326817.944931] CS:  0010 DS:  ES:  
> CR0: 8005003b
> May  9 11:40:51 gene64 vmunix: [326817.944972] CR2:  CR3: 
> 16fab000 CR4: 000407a0
> May  9 11:40:51 gene64 vmunix: [326817.945021] Stack:
> May  9 11:40:51 gene64 vmunix: [326817.945059]  a0868238 
> 880226049b08 a0867e50 880226049a40
> May  9 11:40:51 gene64 vmunix: [326817.945226]  811c95e9 
> 8802 8800c0123df0 8800c0123d00
> May  9 11:40:51 gene64 vmunix: [326817.945396]   
>   0428
> May  9 11:40:51 gene64 vmunix: [326817.945563] Call Trace:
> May  9 11:40:51 gene64 vmunix: [326817.945605]  [] ? 
> udf_fill_super+0x3e8/0x630 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.945648]  [] ? 
> udf_load_vrs+0x3c0/0x3c0 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.945692]  [] ? 
> snprintf+0x39/0x40
> May  9 11:40:51 gene64 vmunix: [326817.945735]  [] ? 
> udf_load_vrs+0x3c0/0x3c0 [udf]
> May  9 11:40:51 gene64 vmunix: [326817.945778]  [] ? 
> mount_bdev+0x1a9/0x1e0
> May  9 11:40:51 gene64 vmunix: [326817.945820]  [] ? 
> mount_fs+0xc/0xc0
> May  9 11:40:51 gene64 vmunix: [326817.945863]  [] ? 
> vfs_kern_

Bug#823684: util-linux: FTBFS[!linux]: missing uuidd

2016-05-07 Thread Andreas Henriksson

Control: tags -1 + confirmed

Hello Steven Chamberlain.

Thanks for your bug report and patch! Very timely as I just spotted
the failure and that it's now a very big problem since sysvinit upload in
sid for non-linux.

I was pondering either your solution (not shipping uuidd in the uuid-runtime
package) or mark the entire uuid-runtime package as linux-any (instead
of any).
As I see it the main point of uuid-runtime package is to provide uuidd
(which is of debatable usefulness I guess), but maybe there's a point
in providing only the uuidgen utility on its own (it does not strictly
require uuidd).

Is there any particular reason you opted to only stop shipping uuidd only?

I don't have a clear convincing argument either way but when I try
to come up with arguments these are the one I can find:

 - uuidgen might be useful to have around on all archs?
 - not touching the debian/control file means I won't risk ending up in NEW.
 - maybe some day someone does upstream porting work on uuidd and then it's
   easy to start shipping it again.
 - still having uuid-runtime package around means it can satisfy the
   Recommends relation in libuuid1, while it's not really satisfying the
   reason for the relation - with is uuidd.

Neither are very convincing arguments but if you can't present any better
then I'll likely go with your patch given I assume it's atleast
somewhat tested and gets the FTBFS problem out of the way.

Either way, thanks for your input so far...

Regards,
Andreas Henriksson

Bug#823660: initscripts: Restore locked root account access by using sulogin --force

2016-05-07 Thread Andreas Henriksson

Package: initscripts
Version: 2.88dsf-59.3
Severity: important

Dear Maintainer,

Since sysvinit-utils/util-linux package versions shipped in Debian Stretch
the sulogin program is now provided by util-linux (replacing previously
supplied sulogin implementation from sysvinit-utils).

The Debian sysvinit package used to carry a (buggy) patch against sulogin
which allowed people to log in as root even when the root account is locked.
(Neither sysvinit or util-linux upstreams for sulogin never supported it.)
This patch was not carried over to the util-linux package when switching
to util-linux sulogin implementation in Debian for various reasons primarily:
 - the patch had serious bugs
 - unconditionally handing out root shells where considered questionable
   for some usecases (eg. kiosk mode).

After discussions with util-linux upstream a compromise was found to allow
handing out root shell even with locked root account *only* when the
--force (-e) option is specified.

As far as I've been told the Debian installer creates a locked root account
when people just press enter (without giving a password) at the root
password prompt, which seems reasonably common among users.
That means users has no way to be let in even when following instructions
given by sulogin. The systemd package has been updated to pass the --force
flag. The initscripts package (src:sysvinit) needs equivalent changes to
restore the old status quo (and thus ignoring potential kiosk mode usecase
problems -- kiosk mode users should alter their init scripts and remove
the --force flag to be secure).

Regards,
Andreas Henriksson

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

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

Versions of packages initscripts depends on:
ii  coreutils   8.25-2
ii  debianutils 4.7
ii  lsb-base9.20160110
ii  mount   2.28-1
ii  sysv-rc 2.88dsf-59.3
ii  sysvinit-utils  2.88dsf-59.3

Versions of packages initscripts recommends:
ii  e2fsprogs  1.43~WIP.2016.03.15-2
ii  psmisc 22.21-2.1+b1

initscripts suggests no packages.

-- no debconf information

Bug#756023: init: Move "Essential: yes" from init to init-system-helpers

2016-05-06 Thread Andreas Henriksson

Hello all.

On Thu, May 05, 2016 at 03:49:57PM +0200, Ansgar Burchardt wrote:
> Felipe Sateler writes:
[...]
> > The util-linux maintainer is very much trying to get rid of that
> > dependency (I can't find an online reference, but discussed on IRC),
> > and it is not done only because apt currently does not deal
> > particularly well with versioned Breaks "loops" involving essential
> > packages.
> 
> Hmm, then alternatives include:
> 
>   - Make "sysvinit-utils" essential (not so nice IMHO).
>   - Have "init-system-helpers" depend on it. This makes sure it stays
> quasi-essential for now.

As already mentioned on IRC but following up here for the record,
sysvinit-utils is actually already Essential: yes.

(Irrelevant, but I've now filed #823569 for switching util-linux
Depends on sysvinit-utils to a Breaks.)

Please also note that I'd like to see sysvinit-utils become
non-essential in a potential soon future. My investigations seems to
suggest that pidof is the only really widely used part of current
(>= stretch) sysvinit-utils, so I've filed #810018 where tracking of
potentially providing procps pidof as an essential package (eg.
procps-base). Other work needed to be able to demote sysvinit-utils to
non-essential are also mentioned in that bug report. (Hopefully
long-term we can even make pidof non-essential as mostly init scripts is
where it's widespead usage comes from, but I don't see those going away
any time soon.)

Regards,
Andreas Henriksson

Bug#797074: libical2 transition now ready to start!

2016-05-06 Thread Andreas Henriksson

Control: tags -1 =

The libical testsuite/FTBFS bugs should now be fixed in experimental
and everything should be ready to go thus unsetting the morinfo
tag. Please tell me once we ready to kick off this transition.

(Sourceful uploads for the blocker bugs to experimental has not happened
as fas as I'm aware, but as the patches are so trivial I think we
can go straight to unstable with those.)

Regards,
Andreas Henriksson

Bug#823569: sysvinit-utils: switch sysvinit-utils/util-linux Breaks/Depends around

2016-05-05 Thread Andreas Henriksson

Package: sysvinit-utils
Version: 2.88dsf-59.3
Severity: normal

Dear Maintainer,

I'm considering a NMU to switch around the inverted Breaks/Depends
relationship between sysvinit-utils and util-linux (which is/was
a bi-product of the previous but no longer existing dependency
cycle via initscripts, which util-linux no longer depends on).

Doing this means we need a coordinated upload of sysvinit and util-linux.
I suspect since I've seen no actual activity from the prospective
sysvinit adopters that I'll have to NMU sysvinit myself to get this
done. Please speak up ASAP if there's anyone willing to handle this
upload on the sysvinit side or if there's anyone who sees any problems
with the attached patches.
I will proceed very soon, so please speek up if it's just to give you
more time and to give me a sign someone out there is listening.

(The matching util-linux patches has also been included for anyone
interested. Put them in a tarball to keep them separated and avoid
mixing up with actual sysvinit patches.)

Regards,
Andreas Henriksson

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

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

Versions of packages sysvinit-utils depends on:
ii  init-system-helpers  1.31
ii  libc62.22-7
ii  startpar 0.59-3

sysvinit-utils recommends no packages.

Versions of packages sysvinit-utils suggests:
pn  bootlogd  
pn  sash  

-- no debconf information
>From 0864dd5eafc8edca3e044841dc5976e16d78ee1f Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Fri, 6 May 2016 05:48:00 +0200
Subject: [PATCH 1/3] sysvinit-utils: move util-linux back to Depends (instead
 of Breaks)

- that's where it belonged and can be put now that the cyclic-dep
  (via initscripts pkg) workaround is no longer needed.
- also bump util-linux version to the one with the matching change.

Closes: #-1
Git-Dch: Full
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 530a23a..f9efc03 100644
--- a/debian/control
+++ b/debian/control
@@ -59,9 +59,9 @@ Conflicts: last, sysvconfig, chkconfig (<< 11.0-79.1-2), startpar (<< 0.58-2)
 Replaces: last, sysvinit (<= 2.86.ds1-65)
 Depends: ${shlibs:Depends}, ${misc:Depends}, init-system-helpers (>= 1.25~)
  , startpar
-Breaks: upstart (<< 1.5-0ubuntu5), systemd (<< 215)
 # sulogin, last, lastb and mesg was moved to the util-linux package
- , util-linux (<< 2.26.2-3)
+ , util-linux (>> 2.28-2~)
+Breaks: upstart (<< 1.5-0ubuntu5), systemd (<< 215)
 Suggests: bootlogd, sash
 Description: System-V-like utilities
  This package contains the important System-V-like utilities.
-- 
2.8.1

>From 55201541b3d534c165987436340ea15dbe7ca7ed Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Fri, 6 May 2016 06:07:53 +0200
Subject: [PATCH 2/3] Add a basic debian/gbp.conf with debian/upstream branch
 names

---
 debian/gbp.conf | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 debian/gbp.conf

diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..60ce09b
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,3 @@
+[DEFAULT]
+debian-branch = master
+upstream-branch = upstream/2.88dsf
-- 
2.8.1

>From 1420326055960274cd927facb9b3b1409dfcec07 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Fri, 6 May 2016 05:55:55 +0200
Subject: [PATCH 3/3] Update debian/changelog

---
 debian/changelog | 17 +
 1 file changed, 17 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 2492ab2..13d98c2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+sysvinit (2.88dsf-59.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Petter Reinholdtsen ]
+  * Fix typo in init-d-script(5) reported by Eric S. Raymond.
+
+  [ Andreas Henriksson ]
+  * sysvinit-utils: move util-linux back to Depends (instead of Breaks)
+- that's where it belonged and can be put now that the cyclic-dep
+  (via initscripts pkg) workaround is no longer needed.
+- also bump util-linux version to the one with the matching change.
+Closes: #-1
+  * Add a basic debian/gbp.conf with debian/upstream branch names
+
+ -- Andreas Henriksson <andr...@fatal.se>  Fri, 06 May 2016 05:55:46 +0200
+
 sysvinit (2.88dsf-59.3) unstable; urgency=medium
 
   * Non-maintainer upload.
-- 
2.8.1



ul-patches.tar
Description: Unix tar archive

Bug#797074: libical2 transition ftbfs bugs now filed

2016-04-25 Thread Andreas Henriksson

Control: block -1 by 822565 822569 822572

Hello!

The FTBFS bugs for the libical2 transition has now been filed
including trivial patches for all of them.

(Waiting for libical to get through binary-NEW and then likely
follow up with an arm build fix before removing the moreinfo tag.)

Regards,
Andreas Henriksson

Bug#822572: citadel: FTBFS against new libical 2.0.0

2016-04-25 Thread Andreas Henriksson

Source: citadel
Version: 9.01-1
Severity: normal
Tags: patch

Dear Maintainer,

Initial plans has been started for transitioning to libical 2.0.0
(currently stuck in NEW).

Your package fails to build from source with the new version.
Please see attached patches which are on top of the citadel
git packaging repo. (Please replace the bug report number in the
first commit message with whatever number this bug report gets
and replace the forth/last patch with a fresh "gbp dch --auto"
run.)

(See also #797074 if you're interested in current transition planning.)

Regards,
Andreas Henriksson
>From 695d48e311e0e1463afc98537cd05f9e3684cc4a Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 15:32:33 +0200
Subject: [PATCH 1/4] Add debian/patches/icalerror_errors_are_fatal.patch

- fixes building against libical 2.0.0

Git-Dch: Full
Closes: #-1
---
 debian/patches/icalerror_errors_are_fatal.patch | 22 ++
 debian/patches/series   |  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 debian/patches/icalerror_errors_are_fatal.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/icalerror_errors_are_fatal.patch b/debian/patches/icalerror_errors_are_fatal.patch
new file mode 100644
index 000..a31ff6f
--- /dev/null
+++ b/debian/patches/icalerror_errors_are_fatal.patch
@@ -0,0 +1,22 @@
+From: Andreas Henriksson <andr...@fatal.se>
+Subject: Fix building with libical 2.0.0
+
+Use new helper function since the global variable was removed.
+
+See https://github.com/libical/libical/commit/6e5534a979b3ab4d28e5a32f5
+
+Note that this unconditionally uses the new function as the macro
+ICAL_CHECK_VERSION was not added in 2.0.0 yet. Maybe it can be
+utilized in the future
+
+--- a/modules/calendar/serv_calendar.c
 b/modules/calendar/serv_calendar.c
+@@ -2586,7 +2586,7 @@
+ 	{
+ 
+ 		/* Tell libical to return errors instead of aborting if it gets bad data */
+-		icalerror_errors_are_fatal = 0;
++		icalerror_set_errors_are_fatal(0);
+ 
+ 		/* Use our own application prefix in tzid's generated from system tzdata */
+ 		icaltimezone_set_tzid_prefix("/citadel.org/");
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..baceaf6
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+icalerror_errors_are_fatal.patch
-- 
2.8.0.rc3

>From f73ea4c74c73a2d8ee67613a5c7393ab14fa2f57 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 15:33:37 +0200
Subject: [PATCH 2/4] Bump libical-dev build-dependency to >= 2.0.0

- see previously added patch header

Git-Dch: Full
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 6ca9737..4030dd4 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: extra
 Maintainer: Debian Citadel Team <pkg-citadel-de...@lists.alioth.debian.org>
 Uploaders: Wilfried Goesgens <w.goesg...@outgesourced.org>, Michael Meskes <mes...@debian.org>, Alexander Wirt <formo...@debian.org>
 Build-Depends: debhelper (>= 7.0.50~), po-debconf, bison, autotools-dev, 
- libdb-dev, libexpat1-dev, libical-dev (>=0.43), libldap2-dev, libncurses5-dev,
+ libdb-dev, libexpat1-dev, libical-dev (>= 2.0.0), libldap2-dev, libncurses5-dev,
  libpam0g-dev, libsieve2-dev, libssl-dev, libcitadel-dev (>= 9.01),
  libcurl4-openssl-dev (>> 7.25), zlib1g-dev, libev-dev (>= 4.0), libc-ares-dev (>= 1.7.2)
 Standards-Version: 3.9.6
-- 
2.8.0.rc3

>From c3d0ece3d0919e06956885c1d963d088c4074641 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 15:34:55 +0200
Subject: [PATCH 3/4] Add build-dependency and use quilt sequencer to apply
 debian/patches

---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 4030dd4..30bbb00 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: mail
 Priority: extra
 Maintainer: Debian Citadel Team <pkg-citadel-de...@lists.alioth.debian.org>
 Uploaders: Wilfried Goesgens <w.goesg...@outgesourced.org>, Michael Meskes <mes...@debian.org>, Alexander Wirt <formo...@debian.org>
-Build-Depends: debhelper (>= 7.0.50~), po-debconf, bison, autotools-dev, 
+Build-Depends: debhelper (>= 7.0.50~), po-debconf, quilt, bison, autotools-dev, 
  libdb-dev, libexpat1-dev, libical-dev (>= 2.0.0), libldap2-dev, libncurses5-dev,
  libpam0g-dev, libsieve2-dev, libssl-dev, libcitadel-dev (>= 9.01),
  libcurl4-openssl-dev (>> 7.25), zlib1g-dev, libev-dev (>= 4.0), libc-ares-dev (>= 1.7.2)
diff --git a/debian/rules b/debian/rules
index d510c35..6e80075 100755
--- a/debian/rules
+++ b/debian/rules
@@ -101,5 +101,5 @@ override_dh_strip:
 	dh_strip --dbg-p

Bug#822569: webcit: FTBFS with new libical 2.0.0

2016-04-25 Thread Andreas Henriksson

Source: webcit
Version: 9.01-dfsg-1
Severity: normal
Tags: patch

Dear Maintainer,

Initial plans has been started for transitioning to libical 2.0.0
(currently stuck in NEW).

Your package fails to build from source with the new version.
Please see attached patches which are on top of the webcit
git packaging repo. (Please replace the bug report number in the
first commit message with whatever number this bug report gets
and replace the forth/last patch with a fresh "gbp dch --auto"
run.)

(See also #797074 if you're interested in current transition planning.)

Regards,
Andreas Henriksson
>From f6c395f53a8760823a8665f53fcb09948b1882e3 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 15:09:26 +0200
Subject: [PATCH 1/4] Add debian/patches/icalerror_errors_are_fatal.patch

- fixes building against libical 2.0.0

Git-Dch: Full
Closes: #-1
---
 debian/patches/icalerror_errors_are_fatal.patch | 22 ++
 debian/patches/series   |  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 debian/patches/icalerror_errors_are_fatal.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/icalerror_errors_are_fatal.patch b/debian/patches/icalerror_errors_are_fatal.patch
new file mode 100644
index 000..c0b2163
--- /dev/null
+++ b/debian/patches/icalerror_errors_are_fatal.patch
@@ -0,0 +1,22 @@
+From: Andreas Henriksson <andr...@fatal.se>
+Subject: Fix building against libical 2.0.0
+
+Use new helper function since the global variable was removed.
+
+See https://github.com/libical/libical/commit/6e5534a979b3ab4d28e5a32f5
+
+Note that this unconditionally uses the new function as the macro
+ICAL_CHECK_VERSION was not added in 2.0.0 yet. Maybe it can be
+utilized in the future
+
+--- a/webserver.c
 b/webserver.c
+@@ -274,7 +274,7 @@
+ 	}
+ 
+ 	/* Tell libical to return an error instead of aborting if it sees badly formed iCalendar data. */
+-	icalerror_errors_are_fatal = 0;
++	icalerror_set_errors_are_fatal(0);
+ 
+ 	/* Use our own prefix on tzid's generated from system tzdata */
+ 	icaltimezone_set_tzid_prefix("/citadel.org/");
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..baceaf6
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+icalerror_errors_are_fatal.patch
-- 
2.8.0.rc3

>From 8527cade9a93771fdef3b8b9ca109088ece0b377 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 15:10:16 +0200
Subject: [PATCH 2/4] Bump libical-dev build-dependency to >= 2.0.0

- see previously added patch header

Git-Dch: Full
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 9f0b9f7..e5985e3 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: web
 Priority: extra
 Maintainer: Debian Citadel Team <pkg-citadel-de...@lists.alioth.debian.org>
 Uploaders: Wilfried Goesgens <w.goesg...@outgesourced.org>, Michael Meskes <mes...@debian.org>, Alexander Wirt <formo...@debian.org>
-Build-Depends: debhelper (>= 7.0.50~), po-debconf, libical-dev (>=0.43), gettext, locales,
+Build-Depends: debhelper (>= 7.0.50~), po-debconf, libical-dev (>= 2.0.0), gettext, locales,
  libcitadel-dev (>= 9.01), autotools-dev, libssl-dev, libexpat1-dev, libmarkdown2-dev
 Standards-Version: 3.9.6
 Vcs-Git: git://anonscm.debian.org/pkg-citadel/webcit.git
-- 
2.8.0.rc3

>From 1c41c0ee57a0e6489a32bd2c62ae785d8fd68141 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 15:20:20 +0200
Subject: [PATCH 3/4] Build-depend on and use quilt sequencer to apply
 debian/patches

---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index e5985e3..1f1fa69 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: web
 Priority: extra
 Maintainer: Debian Citadel Team <pkg-citadel-de...@lists.alioth.debian.org>
 Uploaders: Wilfried Goesgens <w.goesg...@outgesourced.org>, Michael Meskes <mes...@debian.org>, Alexander Wirt <formo...@debian.org>
-Build-Depends: debhelper (>= 7.0.50~), po-debconf, libical-dev (>= 2.0.0), gettext, locales,
+Build-Depends: debhelper (>= 7.0.50~), po-debconf, quilt, libical-dev (>= 2.0.0), gettext, locales,
  libcitadel-dev (>= 9.01), autotools-dev, libssl-dev, libexpat1-dev, libmarkdown2-dev
 Standards-Version: 3.9.6
 Vcs-Git: git://anonscm.debian.org/pkg-citadel/webcit.git
diff --git a/debian/rules b/debian/rules
index fe18965..998a28e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,7 +31,7 @@ ifneq (,$(findstring urldebug,$(DEB_BUILD_OPTIONS)))
 endif
 
 %:
-	dh ${@} --with autotools-dev
+	dh ${@} --with autotools-dev,quilt
 
 override_dh_auto_configure: 
 	dh_testdir
-

Bug#822565: ical2html: FTBFS against new libical 2.0.0

2016-04-25 Thread Andreas Henriksson

Package: ical2html
Version: 2.1-1
Severity: normal
Tags: patch

Dear Maintainer,

Initial plans has been started for transitioning to libical 2.0.0
(currently stuck in NEW).

Your package fails to build from source with the new version.
Please see attached patches which are on top of the ical2html
git packaging repo. (Please replace the bug report number in the
first commit message with whatever number this bug report gets
and replace the third/last patch with a fresh "gbp dch --auto"
run.)

(See also #797074 if you're interested in current transition planning.)

Regards,
Andreas Henriksson
>From 2589e7ef569e5511a2df08b2ffaf681e7abd0c94 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 14:54:49 +0200
Subject: [PATCH 1/3] Add debian/patches/icalerror_errors_are_fatal.patch

- fixes build against libical >= 2.0.0

Git-Dch: Full
Closes: #-1
---
 debian/patches/icalerror_errors_are_fatal.patch | 48 +
 debian/patches/series   |  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 debian/patches/icalerror_errors_are_fatal.patch

diff --git a/debian/patches/icalerror_errors_are_fatal.patch b/debian/patches/icalerror_errors_are_fatal.patch
new file mode 100644
index 000..60dc962
--- /dev/null
+++ b/debian/patches/icalerror_errors_are_fatal.patch
@@ -0,0 +1,48 @@
+Fix build against libical 2.0.0
+
+Global variable was changed to a setter/getter function, also use
+helper to clear errno everywhere.
+
+See https://github.com/libical/libical/commit/6e5534a979b3ab4d28e5a3
+
+This breaks building on libical < 2.0.0 as the ICAL_CHECK_VERSION
+was not included in the 2.0.0 release. Maybe it can be used in
+the future.
+
+--- a/ical2html.c
 b/ical2html.c
+@@ -474,7 +474,7 @@
+   int starts_on_monday = 0;
+ 
+   /* We handle errors ourselves */
+-  icalerror_errors_are_fatal = 0;
++  icalerror_set_errors_are_fatal(0);
+   icalerror_clear_errno();
+ 
+   /* icaltimezone_set_tzid_prefix("/kde.org/Olson_20080523_1/"); */
+--- a/icalfilter.c
 b/icalfilter.c
+@@ -97,8 +97,8 @@
+   icalproperty *p;
+ 
+   /* We handle errors ourselves */
+-  icalerror_errors_are_fatal = 0;
+-  icalerrno = 0;
++  icalerror_set_errors_are_fatal(0);
++  icalerror_clear_errno();
+ 
+   /* Read commandline */
+   while ((c = getopt_long(argc, argv, OPTIONS, options, NULL)) != -1) {
+--- a/icalmerge.c
 b/icalmerge.c
+@@ -258,8 +258,8 @@
+   icalcomponent *newset;
+ 
+   /* We handle errors ourselves */
+-  icalerror_errors_are_fatal = 0;
+-  icalerrno = 0;
++  icalerror_set_errors_are_fatal(0);
++  icalerror_clear_errno();
+ 
+   /* Read commandline */
+   while ((c = getopt_long(argc, argv, OPTIONS, options, NULL)) != -1) {
diff --git a/debian/patches/series b/debian/patches/series
index 5519355..894d2d2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 1001_week_starts_monday.patch
+icalerror_errors_are_fatal.patch
-- 
2.8.0.rc3

>From ff6fbf71c1976b1b9be5d31bdcc64406aa03c116 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 14:55:31 +0200
Subject: [PATCH 2/3] debian/rules: bump libical-dev build-dependency to >=
 2.0.0

- see previously added patch header.

Git-Dch: Full
---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index bb02a15..3e1e6bf 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: cdbs (>= 0.4.123~),
  autoconf,
  debhelper,
  dh-buildinfo,
- libical-dev,
+ libical-dev (>= 2.0.0),
  help2man
 Vcs-Git: git://git.debian.org/git/collab-maint/ical2html.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/ical2html.git
diff --git a/debian/rules b/debian/rules
index c5abf4f..737e32a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -37,7 +37,7 @@ DEB_UPSTREAM_TARBALL_MD5 = bf0bb0e590aef266694b66a741d86191
 CDBS_BUILD_DEPENDS_rules_debhelper_v9 = debhelper
 
 # Needed by upstream build process
-CDBS_BUILD_DEPENDS += , libical-dev
+CDBS_BUILD_DEPENDS += , libical-dev (>= 2.0.0)
 
 DEB_UPSTREAM_CRUFT_MOVE = Makefile.in aclocal.m4 missing depcomp install-sh configure config.h.in
 
-- 
2.8.0.rc3

>From 5f918eea2a1befc5cc1a77302436fe8c299902c6 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Mon, 25 Apr 2016 14:57:07 +0200
Subject: [PATCH 3/3] Update debian/changelog

---
 debian/changelog | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 779fb1a..9c77356 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+ical2html (2.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/icalerror_errors_are_fatal.patch
+- fixes build against libical >= 2.0.0
+Closes: #-1
+  * debian/rules: bump libical-dev build-dependency to >= 2.0.0
+- see pre

Bug#796583: [Pkg-kbd-devel] Bug#796583: How are people supposed to deal with the missing setterm calls?

2016-04-22 Thread Andreas Henriksson

Hello again.

On Wed, Apr 20, 2016 at 10:31:47AM +0200, Andreas Henriksson wrote:
> Hello Marga Manterola.
[...]
> > if [ "$setterm_args" ]; then
> > setterm $setterm_args
> > fi
[...]

Replying to myself as I should probably point out one of the most
important flaws of the above quoted script...

The setterm utility is a local administator utitily. It is supposed
to be run in an *interactive* terminal. It will not work when run
under a sanitized environment (e.g. stdin and stdout are not an
open tty). This means the script has never worked under our default
init system since Jessie, and who knows what else nowadays.
Noone was interested in fixing it up for the jessie release and
I doubt anyone will volunteer in the future either.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771161
for problem description and a workaround.

I've already discussed with util-linux upstream about potentially adding
a --tty flag to setterm and open fds to operate on when specified rather
than using stdin/stdout, which was acked as an ok idea.
I've not yet found the chance to implement this simple piece of code and
send a patch to util-linux upstream during my copious free time. Anyone
should feel free to implement this since it's pretty trivial and should
be doable by anyone who has access to a simple "getting started with C
programming" tutorial which there will be plenty of on the web.
Alternatively if you consider this feature extremely important you could
ofcourse consider paying me to implement it for you

I hope I've shared enough information for interesting people to see
what needs doing, so roll up your sleeves and get busy!

Regards,
Andreas Henriksson

Bug#797074: libical2 transition

2016-04-20 Thread Andreas Henriksson

Control: retitle -1 transition: libical2

Hello release-team!

A new upstream release of libical is out -> 2.0.0. This version comes
with a new so name. I'm repurposing this old bug report, initially
filed for the unfortunate and unexpected ABI breakage in 1.0.1,
for the new version. A transition to newer libical is needed for
updating evolution-data-server, et.al.

Since I've heard no feedback since my last NMU, I've gone ahead and
uploaded a package of the new version towards experimental.
It's currently stuck in (binary-)NEW.

I've build-tested reverse dependencies and came up with the following
results:

FAIL -- will need sourceful uploads.
==

ical2html-2.1
webcit-9.01-dfsg
citadel-9.01

SUCCESS -- should be binNMUable.
==

jana-0.0.0+git20091215.9ec1da8a
libsynthesis-3.4.0.47.5+syncevolution-1.5.1
orage-4.12.1
osmo-0.2.14
gnome-shell-3.20.1
gnome-todo-3.18.1
gnome-panel-3.18.2
gnome-calendar-3.20.1
gnokii-0.6.30+dfsg
cairo-dock-plug-ins-3.4.0
bluez-5.36
bijiben-3.20.0
asterisk-13.7.2~dfsg
almanah-0.11.1
agenda.app-0.42.2
syncevolution-1.4.99.4
abiword-3.0.1
evolution-ews-3.18.5
evolution-data-server-3.18.5
kdepimlibs-4.14.10
evolution-3.18.5.1
kmymoney-4.6.6

Build logs available at:
https://people.debian.org/~ah/libical-transition/

(All three seems to fail on the same thing which hopefully
means it's easy to fix:
error: 'icalerror_errors_are_fatal' undeclared (first use in this
function)
  icalerror_errors_are_fatal = 0;
)

Once libical has cleared the NEW queue I'll file the bugs
against the failing packages, set them as blockers for this bug
and remove the moreinfo tag when it looks like we're ready to
start the transition. Consider this a heads up warning.

Regards,
Andreas Henriksson

Bug#796583: [Pkg-kbd-devel] Bug#796583: How are people supposed to deal with the missing setterm calls?

2016-04-20 Thread Andreas Henriksson

Hello Marga Manterola.

On Tue, Apr 19, 2016 at 02:37:23PM +, Marga Manterola wrote:
> The NEWS.Debian file says that users should move to console-setup instead
> of kbd, which would be fine if console-setup provided the same
> functionality.  For certain things, it doesn't. Look at this snippet from
> the old init script:
> 
> # screensaver stuff
> setterm_args=""
> if [ "$BLANK_TIME" ]; then
> setterm_args="$setterm_args -blank $BLANK_TIME"
> fi
> if [ "$BLANK_DPMS" ]; then
> setterm_args="$setterm_args -powersave $BLANK_DPMS"
> fi
> if [ "$POWERDOWN_TIME" ]; then
> setterm_args="$setterm_args -powerdown $POWERDOWN_TIME"
> fi
> if [ "$setterm_args" ]; then
> setterm $setterm_args
> fi
> 
> As far as I can see, there's nothing in console-setup that provides this
> functionality.  At all.

ACK.

> 
> Is each and every user of kbd expected to now write their own init script
> that calls setterm with the right arguments?

If running setterm is important to you, yes then you could write your
own init script (or other mechanism) to do that.

> 
> Why was this dropped without providing an alternative?

Primarily because very few users are expected to ever care about that
specific part of the init script and obviously noone stepped up to carry
the maintenance burden of keeping it around.
Also this Debian-specific snippet breaks distro-agnostic and more
efficient ways of handling this IIRC. e.g. passing kernel commandline
options. (Maybe that was some other bit of this init scripts though.
My memory is vague since you're joining the party quite late on this
discussion.)
Please also note that Ubuntu was disabling this part for a long time
since they considered it harmful. Please give us the benefit of the
doubt when you jump to the conclution that this was done without careful
consideration.

Why should kbd package ship an init script for a utility that's not part
of kbd in the first place? 
Why should we have duplicate configurations for the same settings?
Why should the burden of carrying this exotic feature be put on the
scarse maintenance resources rather than on the few potential users?
Why should I be required to provide support for people who doesn't
want to do their own research and thinks the bug tracking system
is a support forum?

All above rethorical questions ofcourse... please feel free to not
answer them.

Please feel free to close and archive this bug report again.

Regards,
Andreas Henriksson

Bug#820843: tail'ing a file in a script session hangs

2016-04-13 Thread Andreas Henriksson

Control: tags -1 + upstream fixed-upstream
Control: forwarded -1 
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=b2bff0666101213d5ce9fc4166d8fc5b17581f57

Hello Simon Deziel.

On Tue, Apr 12, 2016 at 08:12:56PM -0400, Simon Deziel wrote:
> Package: util-linux
> Version: 2.27.1-6
> 
> Hello,
> 
> I noticed a regression after upgrading from 2.26.2 to 2.27.1. Here are
> the steps to reproduce:
> 
> 1) Start script session (same issue when script is saving to /dev/null)
> script # or: script /dev/null
> 2) Tail a file
> tailf /var/log/syslog
> 3) Press "Enter" 2 times
> 4) Notice the script process taking 100% CPU
> 
> This regression was introduced upstream by this commit:
> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=54c6611d6f7b73609a5331f4d0bcf63c4af6429e

Thanks for your exemplary bug report. I mentioned it to upstream which
promptly answered that it's now fixed in
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=b2bff0666101213d5ce9fc4166d8fc5b17581f57

Please feel free to notify upstream directly in the future if you find
any similar issues.

Regards,
Andreas Henriksson

PS. Please note that tailf is deprecated. Use tail -f

Bug#819979: libgit2 transition pending, now in experimental.

2016-04-13 Thread Andreas Henriksson

Hello all again!

On Mon, Apr 11, 2016 at 05:34:59PM +0200, Andreas Henriksson wrote:
> Hello Dmitry, Pirate.
> 
> The new libgit2 0.24.0 has just cleared NEW and should soon be available
> in the archive. If it has not yet reached your mirror I've put a copy of
> it at https://people.debian.org/~ah/libgit2/ for your convenience.
> 
> It would be great if you could do an upload of your packages
[...]

Thanks to quick actions from Dmitry and Pirate everything is now available
in experimental.

I've just uploaded the new libgit2 to unstable kicking off this transition!

Release team, please spin up the binNMUs for everything except
libgit2-glib and ruby-rugged which will have sourceful uploads.

(Please also note that geany-plugins FTBFS has just been fixed
and have not yet transitioned to testing yet.)

Dmitry, Pirate please upload your packages to unstable at your convenience.

The auto tracker is now also available at:
https://release.debian.org/transitions/html/auto-libgit2.html

Regards,
Andreas Henriksson

Bug#819871: libgit2-glib symbols file

2016-04-12 Thread Andreas Henriksson

Hello again.

On Tue, Apr 12, 2016 at 02:26:42PM +0200, Andreas Henriksson wrote:
> Hello Dmitry.
> 
> Thanks for quick upload of libgit2-glib 0.24.0!
> 
> I've tested building the latest gnome-builder against the new stack in
> experimental now and noticed that I end up with a dependency like:
> libgit2-glib-1.0-0 (>= 0.23.4)
> 
> This results in a runtime segfault when gnome-builder runs with an
> older (from unstable/testing) libgit2-glib.
> 
> Could you please consider bumping the version of all symbols in
> the libgit2-glib symbols file to 0.24.0 to make sure when building
> against libgit2-glib-dev-1.0-dev (>= 0.24.0) you'll also end up with
> a runtime dependency >= 0.24.0 ?

It was mentioned to me that the better solution would be to simply
use a Build-Depends-Package field in the symbols file.
Please see man deb-symbols for additional information.

Regards,
Andreas Henriksson

Bug#819871: libgit2-glib symbols file

2016-04-12 Thread Andreas Henriksson

Hello Dmitry.

Thanks for quick upload of libgit2-glib 0.24.0!

I've tested building the latest gnome-builder against the new stack in
experimental now and noticed that I end up with a dependency like:
libgit2-glib-1.0-0 (>= 0.23.4)

This results in a runtime segfault when gnome-builder runs with an
older (from unstable/testing) libgit2-glib.

Could you please consider bumping the version of all symbols in
the libgit2-glib symbols file to 0.24.0 to make sure when building
against libgit2-glib-dev-1.0-dev (>= 0.24.0) you'll also end up with
a runtime dependency >= 0.24.0 ?

Regards,
Andreas Henriksson

Bug#819979: libgit2 transition pending, now in experimental.

2016-04-11 Thread Andreas Henriksson

Hello Dmitry, Pirate.

The new libgit2 0.24.0 has just cleared NEW and should soon be available
in the archive. If it has not yet reached your mirror I've put a copy of
it at https://people.debian.org/~ah/libgit2/ for your convenience.

It would be great if you could do an upload of your packages
libgit2-glib / ruby-rugged for the new libgit2 targeted at experimental
so we know all pieces are ready for the transition which is about to
start. (We've got a go from the release team already!)

For additional information the geany-plugins package FTBFS was just
fixed and I tested it builds successfully against the new libgit2.
This means all other packages affected by the libgit2 transition should
be ready for binNMU once we kick off the transition by uploading libgit2
to unstable.

If you need any help with getting your package ready please just shout!

If you've got any suggestions for additional improvements of the libgit2
package please mention them. The NMU which Dmitry spotted was missed
has now been incorporated with additional fixes. Your feedback is
appreciated.

Regards,
Andreas Henriksson

Bug#820212: iproute2: Colons in ethernet names under /sbin/ifconfig and /sbin/ip are not being recognized in Stretch

2016-04-06 Thread Andreas Henriksson

Hello Justin McZeal.

On Wed, Apr 06, 2016 at 11:31:01AM -0500, Justin McZeal wrote:
> Package: iproute2
> Version: 4.3.0-1+b1
> Severity: normal
> 
> Dear Maintainer,
> I'm using Stretch packages and I see a fundamental difference in
> ifconfig/ip between Debian 8 and Debian 9. There are extra colons
> being put in after the interface using /sbin/ifconfig and /sbin/ip.
> I'm using a third party firewall agent that is unable to grab the
> network interfaces correctly through /sbin/ip because of the colon not
> being recognized on an interface. I need to know if this is fixable or
> if there's a workaround. Or, is this the intended action? I've tried
> the same procedures below on a Debian 8 system and they report back
> the interface just fine.
[...]

Unfortunate... but the "fake" "foo:X" interfaces has been deprecated
for I guess soon almost 20 years now. It's not a real interface
and there's absolutely no reason to use that syntax with ip(route2).

The iproute2 suite has been designed from the start to properly
handle multiple ip-addresses on the same interface. You can add
and remove addresses on the fly as you go. No need to bring up
extra fake interfaces for that.

You should really stop using that syntax and any software who still
relies on the syntax (and screen-scraping the output of tools rather
than using the netlink interface) is likely quite out of date so you
should probably consider moving to a more modern alternative.

Regards,
Andreas Henriksson

Bug#820107: RFP: cockpit -- makes it easy to administer your server via a web browser

2016-04-05 Thread Andreas Henriksson

Package: wnpp
Severity: wishlist

* Package name: cockpit
  Version : 0.99
  Upstream Author : Stef Walter <st...@redhat.com>, et.al.
* URL : http://cockpit-project.org/
* License : LGPL-2.1+
  Programming Lang: C
  Description : makes it easy to administer your server via a web browser

Hello!

Cockpit is a framework for doing Administrator tasks via an interactive
web based interface. The implementation sits on top of a websockets bridge
over dbus. It communicate with standard system components over dbus to
reuse their capabilities instead of reimplementing them. It also
leverages dbus activating capabilities to avoid having things running
when they're not used.

I'm filing this borderline RFP, ITP, RFH, RFA. Packaging work has
already been done and are available from:
https://anonscm.debian.org/cgit/collab-maint/cockpit.git

The initial packaging work was done by Michael Biebl and I've recently
updated it. Neither of us have enough time to properly maintain this in
Debian, so I'm posting this to hopefully find someone who has.

While the current package when built from the above repo should be
functional there's some remaining work to be done before it is
ready to be uploaded for NEW review. Lintian helpfully detects
some licensing issues w.r.t. for example javascript "evil" license
as well as usage of bundled libraries. Suggesting solutions for this in
cooperation with upstream is likely needed. Upstream is very interested
in seeing cockpit included in Debian. Further work needed would also
be for a designer to create a "branding" (theme) for cockpit suitable
for Debian deployments.

Please also see storaged RFA bug: #820099

If you're interested in working on and maintaining cockpit in Debian
then please get in touch. I'm personally willing to act as a co-maintainer
and I guess so is Michael. Initial focus would be to get the package
ready for NEW review and once that milestone have been reached I'm willing
to sponsor uploads if you're not already a Debian Developer.

Regards,
Andreas Henriksson

Bug#820099: RFA: storaged -- Disk Manager

2016-04-05 Thread Andreas Henriksson

Package: wnpp
Severity: normal

Hello!

This is a borderline RFA/RFH. I've already packaged storaged, which is
a fork of udisks2 but more targeted at supporting advanced "enterpricy"
storage solutions. It's currently sitting in experimental, since I don't
have time to properly maintain it myself and thus shouldn't upload it
targeted at testing/stretch.
Many backends are currently disabled since their dependencies are
currently not available in Debian.
I've also not properly tested that it's functional, but TTBOMK it is.

Further information can be found at:
https://tracker.debian.org/pkg/storaged

Like the packaging vcs at:
https://anonscm.debian.org/cgit/collab-maint/pkg-storaged.git

There's also interest from upstream to see Debian support and their
bug tracker has an issue for this, see:
https://github.com/storaged-project/storaged/issues/41#issuecomment-205769607

Upstream has packaged the dependencies which are not available in Debian
in separate Ubuntu PPAs and updated the storaged package in an Ubuntu PPA
to enable the new backends, which should serve as a very good base for
someone willing to maintain these in Debian!

If you'd like to see storaged (which is an optional but quite central
dependency of cockpit-project.org) in a future stable Debian release,
then this is your chance to help out!

Get in touch if you'd like to be the primary maintainer of storaged
in Debian. I'm willing to assist as a co-maintainer and can also sponsor
you if you're not already a Debian Developer.

Regards,
Andreas Henriksson

Bug#798338: libgit2: #798338 Please package 0.24.0 available upstream

2016-04-05 Thread Andreas Henriksson

Hello Dmitry.

On Tue, Apr 05, 2016 at 06:22:32AM +1000, Dmitry Smirnov wrote:
> Hi guys,
> 
> Please make sure that NMU is acknowledged:
[...]

Thanks for the reminder. I've now mangled the diff to incorporate it
and committed the result to the new libgit2 collab-maint repo.
Should be part of next upload.

Regards,
Andreas Henriksson

Bug#819975: Fails to start

2016-04-04 Thread Andreas Henriksson

Hello!

On Mon, Apr 04, 2016 at 03:30:12PM +0200, Michael Biebl wrote:
> Package: gnome-characters
> Version: 3.20.0-1
> Severity: grave
> 
> Since the upgrade to 3.20.0, gnome-characters fails to start.
> There is no output on stdout/stderr, but in the journal I get:
[...]

I tested in a sid chroot and got an even longer error (see below).

This was solved by installing libgtk+-3-0/experimental, which also
dragged in:

The following additional packages will be installed:
  adwaita-icon-theme libgtk-3-common
Suggested packages:
  gvfs
The following NEW packages will be installed:
  libgtk-3-0-dbg
The following packages will be upgraded:
  adwaita-icon-theme libgtk-3-0 libgtk-3-common
3 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

The error message before I installed was:

# gnome-characters 

(org.gnome.Characters:4319): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"

(org.gnome.Characters:4319): Gjs-WARNING **: JS ERROR: Gtk.CssProviderError: 
application.css:65:19'-gtk-key-bindings' is not a valid property name
loadStyleSheet@resource:///org/gnome/Characters/js/util.js:49
MyApplication<.vfunc_startup@resource:///org/gnome/Characters/js/main.js:82
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
main@resource:///org/gnome/Characters/js/main.js:112
run@resource:///org/gnome/gjs/modules/package.js:192
@/usr/bin/gnome-characters:6

(org.gnome.Characters:4319): Gjs-WARNING **: JS ERROR: TypeError: Main.settings 
is null
CharacterListView<._init@resource:///org/gnome/Characters/js/characterList.js:369
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
MainView<._createCharacterList@resource:///org/gnome/Characters/js/window.js:295
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
MainView<._init@resource:///org/gnome/Characters/js/window.js:273
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
MainWindow<._init@resource:///org/gnome/Characters/js/window.js:107
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
MyApplication<.vfunc_activate@resource:///org/gnome/Characters/js/main.js:99
wrapper@resource:///org/gnome/gjs/modules/lang.js:178
main@resource:///org/gnome/Characters/js/main.js:112
run@resource:///org/gnome/gjs/modules/package.js:192
@/usr/bin/gnome-characters:6

Regards,
Andreas Henriksson

Bug#819871: libgit2-glib-1.0-0: New upstream release v0.24.0

2016-04-04 Thread Andreas Henriksson

Hello again.

Forgot to mention the most important part

Russell Sim, the maintainer of libgit2, is very busy at the moment and
would appreciate help. I'll help out getting over the current hurdle
with the new upstream release and the transition, but maybe you
as the maintainer of libgit2-glib which is closely related to libgit2
would consider helping Russell out on the longer term by becoming a
libgit2 co-maintainer? The repo was just moved to collab-maint

See https://bugs.debian.org/798338 for more background info.

Regards,
Andreas Henriksson

Bug#819871: libgit2-glib-1.0-0: New upstream release v0.24.0

2016-04-04 Thread Andreas Henriksson

Hello Dmitry Smirnov.

Thanks for your very quick reply.

On Sun, Apr 03, 2016 at 10:01:16PM +1000, Dmitry Smirnov wrote:
> On Sunday, 3 April 2016 12:52:05 PM AEST Andreas Henriksson wrote:
> > Please consider updating to latest upstream stable release of libgit2-glib
> > v0.24.0 as soon as possible.
> 
> "libgit2-glib" is held by "libgit2" library.

As you might have noticed I've set up the bts to track this information.

> 
> 
> > Please tell me if you're busy and would like me to help out with a NMU.
> 
> I'll take care of "libgit2-glib" is you could kindly help with "libgit2".

After discussion with the libgit2 maintainer and other stakeholders at
the libgit2 bug report I've now uploaded a new libgit2 to experimental
as this will require a transition (which you should have just received
a copy of my bug report for transition slot).

Would be very welcome if you could follow up with a libgit2-glib upload
also targeted at experimental as soon as libgit2 clears the NEW queue.

Regards,
Andreas Henriksson

Bug#819979: transition: libgit2

2016-04-04 Thread Andreas Henriksson

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: Russell Sim , Pirate Praveen 
, Dmitry Smirnov 

Hello release team!

I'd like to request a transition slot for libgit2.

I've tested building reverse dependencies:
birdfont cargo geany-plugins golang-git2go kate libgit2-glib python-pygit2
ruby-rugged

geany-plugins already has a FTBFS bug reported at #819889 but I don't
consider it a transition blocker as it has no reverse dependencies and
could simply get temporarily removed from testing.

The following failed to build with the new version and needs sourceful uploads:

* libgit2-glib - I assumed this would simply be fixed by sourceful uploading
  of matching libgit2-glib v0.24.0, see #819871
 * ruby-rugged - Pirate Praveen reported success with the new version he's
 prepared.

So to summarize:
RM geany-plugins
sourceful uploads: libgit2-glib, ruby-rugged
binNMU: birdfont, cargo, geany-plugins, golang-git2go, kate, python-pygit2

The new upstream release 0.24.0 was just uploaded to(wards) experimental
(now stuck in NEW ofcourse) so an automatic tracker should be available soon.

Ben file:

title = "libgit2";
is_affected = .depends ~ "libgit2-23" | .depends ~ "libgit2-24";
is_good = .depends ~ "libgit2-24";
is_bad = .depends ~ "libgit2-23";


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

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

Bug#798338: update to 0.24.0

2016-04-04 Thread Andreas Henriksson

Hello Russell Sim.

Thanks for your quick followup! Your feedback is much appreciated!

On Mon, Apr 04, 2016 at 10:32:13PM +1000, Russell Sim wrote:
> Hey,
> 
> My apologies,  I am still here, but yes I have totally fallen behind.  I'll
> can take a look at updating it tomorrow night.  Or if you like your welcome
> to move this package to collab and take it over.  Either way I don't mind.
> Sorry my situation has changed and I don't have the time to commit like I
> did previously hence the delay.  Anyway let me know what you would like me
> to do.

Your past contributions are very appreciated and you should not see it
as a chain around your ancle for the future. It's totally ok if you
don't have much time to spare at the moment and I think everyone
here would like to see your continued involvement when/if you find
any time to spare. We're just asking if it's ok that we help you
out while you're busy with other things without going through a big
procedure for getting your acknowledgement for every little change.

I'll move the project to collab-maint and handle the immediate outstanding
work as previously mentioned on this bug report w.r.t. new upstream and
transition. All debian-developers and then some more have commit access
to collab-maint. If you don't (yet) have that Russell we'll make sure
the alioth admins give it to you. Just contact the the alioth admins
and give me as a reference (or someone else in this bug report I guess).

I'm only going to help out get over the current hurdle, so I urge anyone
who wants to co-maintain libgit2 with Russel to add themselves to the
Uploaders field in the upcoming collab-maint repo.

Regards,
Andreas Henriksson

Bug#798338: update to 0.24.0

2016-04-03 Thread Andreas Henriksson

Hello Pirate Praveen.

On Sun, Apr 03, 2016 at 09:25:03PM +0530, Pirate Praveen wrote:
> On Sun, 3 Apr 2016 15:41:03 +0200 Andreas Henriksson <andr...@fatal.se>
> wrote:
> >  * ruby-rugged - Pirate Praveen indicated he has prepared a new upstream
> >  release which I assume fixes this. Pirate, please confirm
> >  there's nothing preventing taking care of this once
> >  potentially a libgit2 transition starts.
> 
> Hi Andreas,
> 
> I have not tested, I was waiting for a new libgit2 version. Can you push
> it to collab-maint, so I can build locally and test? A personal repo
> would also do, if that is easier for you. Once we hear from Russel we
> can switch officially.
> 

I've made my changes available /temporarily/ at
https://github.com/andhe/pkg-libgit2

Regards,
Andreas Henriksson

Bug#819889: FTBFS: autoreconf fails: error: m4_copy: won't overwrite ...

2016-04-03 Thread Andreas Henriksson

Source: geany-plugins
Version: 1.27+dfsg-1
Severity: serious
Justification: fails to build from source

Dear Maintainer,

The package currently fails to build (which was detected while planning
a potential future transition of libgit2 which would require a rebuild
of reverse dependencies, but the failure has been confirmed to not
be related to the upcoming libgit2 version).

Please see attached build log for an attempt to (re)build geany-plugins
in a current Debian sid chroot.

(Unless this issue is fixed I would assume the release team would deal
with this transition blocker by temporarily remove geany-plugins from
testing as it has no reverse dependencies and let it migrate back in
once fixed. Thus not markings this bug as a blocker for #798338)

Regards,
Andreas Henriksson

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
I: using pbuilder as pbuilder
dpkg-checkbuilddeps: error: Unmet build dependencies: geany (>= 1.26~) 
libgtk2.0-dev (>= 2.16) libenchant-dev (>= 1.3) libgtkspell-dev liblua5.1-dev 
libctpl-dev (>= 0.3) python-docutils libwebkitgtk-dev (>= 1.1.18) | 
libwebkit-dev (>= 1.1.18) libgdk-pixbuf2.0-dev (>= 2.0) libgpgme11-dev 
libvte-dev (>= 1:0.24) libwnck-dev (>= 2.10.0) libgconf2-dev (>= 2.6.0) 
libmarkdown2-dev libgit2-dev python-gtk2-dev
W: Unmet build-dependency in source
dpkg-buildpackage: source package geany-plugins
dpkg-buildpackage: source version 1.27+dfsg-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Chow Loong Jin <hyper...@debian.org>
 dpkg-source --before-build geany-plugins-1.27+dfsg
 fakeroot debian/rules clean
dh clean --with=autoreconf --parallel
   dh_testdir
   dh_auto_clean
   dh_autoreconf_clean
   dh_clean
 dpkg-source -b geany-plugins-1.27+dfsg
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building geany-plugins using existing 
./geany-plugins_1.27+dfsg.orig.tar.gz
dpkg-source: info: building geany-plugins in 
geany-plugins_1.27+dfsg-1.debian.tar.xz
dpkg-source: info: building geany-plugins in geany-plugins_1.27+dfsg-1.dsc
 dpkg-genchanges -S >../geany-plugins_1.27+dfsg-1_source.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build geany-plugins-1.27+dfsg
dpkg-buildpackage: full upload (original source is included)
I: using fakeroot in build.
I: Current time: Sun Apr  3 15:51:57 CEST 2016
I: pbuilder-time-stamp: 1459691517
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/base.tgz]
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /var/cache/pbuilder/mirror
I: policy-rc.d already exists
W: no hooks of type H found -- ignoring
I: Obtaining the cached apt archive contents
I: Installing the build-deps
I: user script /var/cache/pbuilder/build/2970/tmp/hooks/D01experimental starting
$ENABLE_EXP not set, not adding experimental to sources.list
$ENABLE_UNSTABLE not set, not adding unstable to sources.list
$ENABLE_INCOMING not set, not adding incoming to sources.list
I: user script /var/cache/pbuilder/build/2970/tmp/hooks/D01experimental finished
I: user script /var/cache/pbuilder/build/2970/tmp/hooks/D02local-packages 
starting
$ENABLE_LOCAL not set, not adding local packages to sources.list
I: user script /var/cache/pbuilder/build/2970/tmp/hooks/D02local-packages 
finished
W: execute priv not set on file D03ftp-debian-org, not executing.
I: user script /var/cache/pbuilder/build/2970/tmp/hooks/D04translations starting
I: user script /var/cache/pbuilder/build/2970/tmp/hooks/D04translations finished
I: user script /var/cache/pbuilder/build/2970/tmp/hooks/D05apt-get-update 
starting
I: user script /var/cache/pbuilder/build/2970/tmp/hooks/D05apt-get-update 
finished
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team <pbuilder-ma...@lists.alioth.debian.org>
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), dh-autoreconf (>= 4), 
autotools-dev, intltool (>= 0.35), geany (>= 1.26~), libgtk2.0-dev (>= 2.16), 
libglib2.0-dev (>= 2.18), libenchant-dev (>= 1.3), libgtkspell-dev, 
liblua5.1-dev, libctpl-dev (>= 0.3), python-docutils, libxml2-dev (>= 2.6.27), 
libsoup2.4-dev (>= 2.4.0), libwebkitgtk-dev (&g

Bug#798338: update to 0.24.0

2016-04-03 Thread Andreas Henriksson

Hello again.

On Sun, Apr 03, 2016 at 03:04:15PM +0200, Andreas Henriksson wrote:
[...]
> FTR, the new upstream release has a new so version which means
> a transition that needs to be coordinated with the release team.
[...]

FYI, I've tested rebuilding the reverse dependencies against updated libgit2:
birdfont cargo geany-plugins golang-git2go kate libgit2-glib python-pygit2
ruby-rugged

The following failed:
 * geany-plugins - unrelated to libgit2 transition. FTBFS bug should be filed.
   has no reverse dependencies so from transition POV could
   probably temporarily be removed from testing.
 * libgit2-glib - I assumed this would simply be fixed by sourceful uploading
  of matching libgit2-glib v0.24.0, see #819871
 * ruby-rugged - Pirate Praveen indicated he has prepared a new upstream
 release which I assume fixes this. Pirate, please confirm
 there's nothing preventing taking care of this once
 potentially a libgit2 transition starts.

Regards,
Andreas Henriksson

Bug#798338: update to 0.24.0

2016-04-03 Thread Andreas Henriksson

Hello all!

On Sat, Apr 02, 2016 at 09:29:43PM +0530, Pirate Praveen wrote:
[...]
> Zigo, Boutil,
> 
> I have not heard from Russel for 2 weeks for now. Can we create a new
> team and update it?
> 

This is via a dependency chain now also blocking gnome-builder 3.20
and thus RC bug: #819538

I think it would be good if libgit2 moves to a collab-maint project
where more people can help out with maintenance of this package.
I've personally prepared an updated package locally and can push
it if everyone agrees about this. Russel, any objections?

FTR, the new upstream release has a new so version which means
a transition that needs to be coordinated with the release team.

Given this is becoming an increasing blocker I'd like to go ahead
very soon, so Russel please give us any feedback as soon as possible.

Regards,
Andreas Henriksson

Bug#819548: gnome-maps fails to start

2016-04-03 Thread Andreas Henriksson

Hello again!

mlundblad mentioned to me on IRC that he has identified the culprit
as gjs in testing not being new enough. Please confirm that upgrading
to gjs from unstable fixes the problem for you.

(This issue has been fixed upstream in gnome-maps at:
https://git.gnome.org/browse/gnome-maps/commit/?id=f735490a47afbf
and I'll add the equivalent dependency to the debian package shortly.)

Regards,
Andreas Henriksson

Bug#819871: libgit2-glib-1.0-0: New upstream release v0.24.0

2016-04-03 Thread Andreas Henriksson

Package: libgit2-glib-1.0-0
Severity: wishlist

Dear Maintainer,

Please consider updating to latest upstream stable release of libgit2-glib
v0.24.0 as soon as possible.

(This version is required by gnome-builder 3.20 git plugin fwiw)

Please tell me if you're busy and would like me to help out with a NMU.

Regards,
Andreas Henriksson

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

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

Bug#819863: libgegl-0.3-0: please build with libraw enabled

2016-04-03 Thread Andreas Henriksson

Package: libgegl-0.3-0
Version: 0.3.6-1
Severity: wishlist

Dear Maintainer,

Currently GEGL seems to be built with a number of features disabled.
Among these are the support for using libraw.

It would be nice if GEGL could be built with libraw enabled and I
suspect just adding libraw-dev as a build-dependency would accomplish
that.

The reason I'm asking is because gnome-photos needs the feature (and in
3.20 it explicitly checks for it and refuses to start without it).
Updating gnome-photos is a requirement for the grilo-0.3 transition,
which is the only transition needed before gnome 3.20 core can
reach unstable.

Thanks for your consideration.

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgegl-0.3-0 depends on:
ii  libbabl-0.1-00.1.16-1
ii  libc62.22-5
ii  libcairo21.14.6-1
ii  libgcc1  1:5.3.1-13
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libglib2.0-0 2.48.0-1
ii  libilmbase12 2.2.0-11
ii  libjasper1   1.900.1-debian1-2.4+deb8u1
ii  libjpeg62-turbo  1:1.4.2-2
ii  libjson-glib-1.0-0   1.2.0-1
ii  libopenexr22 2.2.0-10
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpng12-0   1.2.54-4
ii  librsvg2-2   2.40.13-3
ii  libsdl1.2debian  1.2.15+dfsg1-4
ii  libstdc++6   5.3.1-13
ii  libumfpack5.7.1  1:4.4.6-1

libgegl-0.3-0 recommends no packages.

libgegl-0.3-0 suggests no packages.

-- no debconf information

Bug#819548: gnome-maps fails to start

2016-04-03 Thread Andreas Henriksson

Hello Jean-Marc and gpe92.

Thanks for the bug report.

On Wed, Mar 30, 2016 at 12:18:18PM +0200, Jean-Marc wrote:
> Package: gnome-maps
> Version: 3.20.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I just upgraded to gnome-maps 3.20 and it failed to start.
> 
> $ gnome-maps
> 
> (org.gnome.Maps:1990): Gjs-WARNING **: JS ERROR: TypeError:
> GObject.ParamSpec.override is not a function
> @resource:///org/gnome/Maps/js/mapMarker.js:44
[...]

Running gnome-maps works for me and apparently also for mfv.
This ofcourse doesn't mean there's no problem though.
Personally I have many packages installed from experimental
and even some not yet uploaded. I'm guessing mfv might have
updated some package as well to make it work for him. I think
there's a good chance thus that gnome-maps simply misses
a (versioned) dependency somewhere to guarantee another component
is upgraded when gnome-maps is. If you could please look at the
dependencies of gnome-maps and check if there's a package in
experimental you can upgrade too, do each upgrade separately
and test gnome-maps at each step, likely you'll then find the
culprit and we've identified the missing dependency.

Your help would be very welcome.

Regards,
Andreas Henriksson

Bug#819846: gnome-music: python-gi crashing gnome-music upon launch

2016-04-03 Thread Andreas Henriksson

Hello Marc J. Driftmeyer.

Thanks for your bug report.

On Sat, Apr 02, 2016 at 05:22:15PM -0700, Marc J. Driftmeyer wrote:
> Package: gnome-music
> Version: 3.20.0-1
> Severity: normal
[...]
> mdriftmeyer@horus:~$ gnome-music
> /usr/lib/python3/dist-packages/gi/module.py:178: Warning: 
> g_array_append_vals: assertion 'array' failed
>   g_type = info.get_g_type()
> /usr/lib/python3/dist-packages/gi/module.py:178: Warning: 
> g_hash_table_lookup: assertion 'hash_table != NULL' failed
>   g_type = info.get_g_type()
[...]

Did gnome-music work for you in a previous version? Did downgrading
again fix the problem for you?

Fwiw, it works for me (and a small unrelated to your issue bug fix
has been committed to svn already - namely depend on grilo-plugins-0.3,
so make sure you have that package installed as well).

I searched google and ran into someone having similar problems at:
https://bbs.archlinux.org/viewtopic.php?id=193754
That discussion happened way before gnome-music 3.20 was released so
likely you have some kind of general issue with gnome-music (possibly
related to tracker data, but the discussions on the forum is quite vague).
It looks to me like someone (who can reproduce the issue?) might have
to get their hands dirty and debug this. If you could please investigate
if there's any upstream bug report for this issue otherwise please file
one....

Regards,
Andreas Henriksson

Bug#815727: multiarchify the library packages

2016-04-02 Thread Andreas Henriksson

Control: tags -1 = moreinfo

Hello Matthias Klose.

Thanks for the bug report and patch!

On Wed, Feb 24, 2016 at 06:47:56AM +0100, Matthias Klose wrote:
> Package: src:libpeas
> Version: 1.16.0-1
> Tags: patch
> User: d...@debian.org
> Usertags: multiarch
> 
> please multiarchify the library packages, patch attached (the .install files
> using dh-exec need to be made executable).

The patch was discussed on #debian-gnome as ricotz brought it up and we
have a few questions if you could please inform us.

First minor issue, why dh-exec instead of just using a wildcard in path?

But more importantly, the loaders isn't in a multi-arch directory and
judging by the comment you add in debian/rules that seems to be on
purpose. How's that supposed to work? If you install both :amd64 and
:i386 these files will collide, won't they?
In other words, arch-specific files in non-multiarch path.

Your feedback would be much appreciated.

Regards,
Andreas Henriksson

Bug#819242: Post-install script for uuid-runtime fails to properly create and configure uuidd group

2016-03-25 Thread Andreas Henriksson

Control: tags -1 + moreinfo

Hello Alexander Stein.

Thanks for your bug report.

On Fri, Mar 25, 2016 at 04:34:05PM +0300, Alexander Stein wrote:
> Package: uuid-runtime
[...]
>  I was encountered with the output below:
> 
>The following partially installed packages will be configured:
>uuid-runtime
>No packages will be installed, upgraded, or removed.
>0 packages upgraded, 0 newly installed, 0 to remove and 0 not
>upgraded.
>Need to get 0 B of archives. After unpacking 0 B will be used.
>Setting up uuid-runtime (2.25.2-6) ...
>Adding group `uuidd' (GID 122) ...
>groupadd: failure while writing changes to /etc/group
[...]

So why is it that writing to /etc/group fails or your system?
Are you having filesystem problems and your filesystem became
remounted read-only? Can you open (as root) /etc/group and write
to it? What's the status and permissions on /etc/group on your
system?

This seems more like a general system problem on your end rather
than a bug in the package.

Regards,
Andreas Henriksson

Bug#817168: [PATCH] add/remove-shell: also add/remove shells real path

2016-03-24 Thread Andreas Henriksson

Hello!

This should solve the "debootstrapped with merged usr" case (see
#810301) and Marco has already implemented the upgrade case in
usrmerge 11.

Please review attached patch.

Regards,
Andreas Henriksson
>From 12794e2c3c8d04677f8f0a3395a48e3674560484 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson <andr...@fatal.se>
Date: Thu, 24 Mar 2016 12:17:42 +0100
Subject: [PATCH] add/remove-shell: also add/remove shells real path

In the case of usr merged systems we want the shells to also
be listed with their real paths, eg. /usr/bin/bash, in addition
to their specified path in /etc/shells

(While at it also fix mixed tab/spaces indentation of help texts
and trailing whitespace.)

The mixture of dirname/realpath/basename is to avoid expanding
the filename, only the directory part of the path.
This is to avoid /bin/sh being expanded to /usr/bin/dash
rather than /usr/bin/sh. Maybe we want to add both in
such a case?

Closes: #817168
---
 add-shell| 16 ++--
 remove-shell | 14 +-
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/add-shell b/add-shell
index 4c91015..2fc54bf 100755
--- a/add-shell
+++ b/add-shell
@@ -2,8 +2,8 @@
 
 if test $# -eq 0
 then
-	echo usage: $0 shellname [shellname ...]
-	exit 1
+echo usage: $0 shellname [shellname ...]
+exit 1
 fi
 
 file=/etc/shells
@@ -25,10 +25,14 @@ fi
 
 for i
 do
-if ! grep -q "^${i}$" $tmpfile
-then
-echo $i >> $tmpfile
-fi
+REALDIR="$(dirname $(realpath -m $i))/$(basename $i)"
+for j in "$i" "$REALDIR"
+do
+if ! grep -q "^${j}$" $tmpfile
+then
+echo $j >> $tmpfile
+fi
+done
 done
 
 chmod --reference=$file $tmpfile
diff --git a/remove-shell b/remove-shell
index 1e6b739..15eca39 100755
--- a/remove-shell
+++ b/remove-shell
@@ -2,8 +2,8 @@
 
 if test $# -eq 0
 then
-	echo usage: $0 shellname '[shellname ...]' 1>&2
-	exit 1
+echo usage: $0 shellname '[shellname ...]' 1>&2
+exit 1
 fi
 
 file=/etc/shells
@@ -14,7 +14,7 @@ otmpfile=${file}.tmp2
 set -o noclobber
 
 trap "rm -f $tmpfile $otmpfile" EXIT
-
+
 if ! cat $file > $tmpfile
 then
 cat 1>&2 < $otmpfile || true
-	mv $otmpfile $tmpfile
+REALDIR="$(dirname $(realpath -m $i))/$(basename $i)"
+for j in "$i" "$REALDIR"
+do
+grep -v "^${j}$" $tmpfile > $otmpfile || true
+mv $otmpfile $tmpfile
+done
 done
 
 chmod --reference=$file $tmpfile
-- 
2.7.0

Bug#818964: fonts-cantarell: new upstream release

2016-03-22 Thread Andreas Henriksson

Package: fonts-cantarell
Version: 0.0.21-1
Severity: wishlist

Dear Maintainer,

Please consider packaging the new upstream release 0.0.24
(I'm running into pango1.0 test failures which others have reported
can be related to cantarell fonts, so my hope is that new upstream
might have an effect on it - see https://bugzilla.gnome.org/755733 ).

-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  fontconfig 2.11.0-6.3   amd64generic font configuration librar
ii  libfreetype6:a 2.6.3-3  amd64FreeType 2 font engine, shared li
ii  libfreetype6:i 2.6.3-3  i386 FreeType 2 font engine, shared li
ii  libxft2:amd64  2.3.2-1  amd64FreeType-based font drawing libra
ii  libxft2:i386   2.3.2-1  i386 FreeType-based font drawing libra

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

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

Versions of packages fonts-cantarell depends on:
ii  fontconfig  2.11.0-6.3

fonts-cantarell recommends no packages.

fonts-cantarell suggests no packages.

-- no debconf information

Bug#818464: libvirt-glib: new upstream release 0.2.3

2016-03-19 Thread Andreas Henriksson

Source: libvirt-glib
Version: 0.2.2-1
Severity: wishlist

Dear Maintainer,

It's this time of year again... A new upstream release is out and
is needed by gnome-boxes as one example.

Please see attached diff which updates the packaging.
Please speak up if you're going to upload soon or if you'd
appreciate me NMUing. Seeing the new version in the archive
ASAP would be useful.

Regards,
Andreas Henriksson


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -uriNp ../libvirt-glib-0.2.2/debian/changelog debian/changelog
--- ../libvirt-glib-0.2.2/debian/changelog	2015-07-29 11:57:11.0 +0200
+++ debian/changelog	2016-03-16 21:11:14.344648361 +0100
@@ -1,3 +1,15 @@
+libvirt-glib (0.2.3-1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release
+  * Bump build-dependencies according to configure.ac changes:
+- libvirt-dev (>= 1.1.1)
+- libglib2.0-dev (>= 2.36.0)
+- gobject-introspection (>= 1.36.0)
+  * Update debian/libvirt-glib-1.0-0.symbols with added symbols.
+
+ -- Andreas Henriksson <andr...@fatal.se>  Wed, 16 Mar 2016 21:06:02 +0100
+
 libvirt-glib (0.2.2-0.1) unstable; urgency=medium
 
   * Non-maintainer upload with maintainer permission.
diff -uriNp ../libvirt-glib-0.2.2/debian/control debian/control
--- ../libvirt-glib-0.2.2/debian/control	2015-07-28 21:20:26.0 +0200
+++ debian/control	2016-03-16 21:05:18.798126062 +0100
@@ -5,8 +5,8 @@ Maintainer: Guido Günther <agx@sigxcpu.
 Build-Depends: debhelper (>= 7.0.50~), 
  intltool,
  pkg-config,
- libvirt-dev (>= 0.10.2), libglib2.0-dev (>= 2.36),
- libxml2-dev, libgirepository1.0-dev, gobject-introspection,
+ libvirt-dev (>= 1.1.1), libglib2.0-dev (>= 2.36.0),
+ libxml2-dev, libgirepository1.0-dev, gobject-introspection (>= 1.36.0),
 # when building from git:
   automake, autoconf, libtool, libtool-bin,
 # for vala bindings
diff -uriNp ../libvirt-glib-0.2.2/debian/libvirt-glib-1.0-0.symbols debian/libvirt-glib-1.0-0.symbols
--- ../libvirt-glib-0.2.2/debian/libvirt-glib-1.0-0.symbols	2015-07-28 21:53:18.0 +0200
+++ debian/libvirt-glib-1.0-0.symbols	2016-03-16 21:10:56.592122690 +0100
@@ -12,6 +12,7 @@ libvirt-gconfig-1.0.so.0 libvirt-glib-1.
  *@LIBVIRT_GCONFIG_0.2.0 0.2.2~
  *@LIBVIRT_GCONFIG_0.2.1 0.2.2~
  *@LIBVIRT_GCONFIG_0.2.2 0.2.2~
+ *@LIBVIRT_GCONFIG_0.2.2 0.2.3~
  gvir_config_capabilities_cpu_add_feature@LIBVIRT_GCONFIG_0.1.0 0.1.2~
  gvir_config_capabilities_cpu_feature_get_name@LIBVIRT_GCONFIG_0.0.9 0.1.2~
  gvir_config_capabilities_cpu_feature_get_type@LIBVIRT_GCONFIG_0.0.9 0.1.2~
@@ -526,6 +527,9 @@ libvirt-gobject-1.0.so.0 libvirt-glib-1.
  gvir_domain_save_to_file_finish@LIBVIRT_GOBJECT_0.0.8 0.0.8~
  gvir_domain_screenshot@LIBVIRT_GOBJECT_0.0.8 0.0.8~
  gvir_domain_set_config@LIBVIRT_GOBJECT_0.0.8 0.0.8~
+ gvir_domain_set_time@LIBVIRT_GOBJECT_0.2.3 0.2.3~
+ gvir_domain_set_time_async@LIBVIRT_GOBJECT_0.2.3 0.2.3~
+ gvir_domain_set_time_finish@LIBVIRT_GOBJECT_0.2.3 0.2.3~
  gvir_domain_shutdown@LIBVIRT_GOBJECT_0.0.8 0.0.8~
  gvir_domain_shutdown_flags_get_type@LIBVIRT_GOBJECT_0.1.1 0.1.2~
  gvir_domain_snapshot_create_flags_get_type@LIBVIRT_GOBJECT_0.1.1 0.1.2~

Bug#818252: swap.target: Job swap.target/start failed with result 'dependency'.

2016-03-18 Thread Andreas Henriksson

Hello Roderich Schupp.

On Fri, Mar 18, 2016 at 11:26:19AM +0100, Roderich Schupp wrote:
> On Tue, 15 Mar 2016 12:48:19 +0100 Andreas Henriksson <andr...@fatal.se>
> wrote:
> > Control: tags -1 + upstream fixed-upstream
> > Control: forwarded -1
> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=12f5cbe15940bfb94d31a1b898084aa5f0e5fa10
> 
> FYI, that commit does NOT fix the bug, the error message now is
> 
> #  swapon -a
> swapon: sys-utils/swapon.c:651: parse_options: Assertion `ctl->options'
> failed.
> 
> The reason is that the mount options read from /etc/fstab never make it
> into the ctl struct (see sys-utils/swapon.c around line 940).

Thanks for the feedback. I've notified upstream about your feedback
and it's being investigated.

FWIW, Please feel free to communicate things like this directly to
upstream without me as a middle man.

Regards,
Andreas Henriksson

Bug#818252: swap.target: Job swap.target/start failed with result 'dependency'.

2016-03-15 Thread Andreas Henriksson

Control: tags -1 + upstream fixed-upstream
Control: forwarded -1 
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=12f5cbe15940bfb94d31a1b898084aa5f0e5fa10

Hello Dan Jacobson.

Thanks for your help testing the new release candidate!

Mentioned the problem on irc and forwarding the following greeting:

11:40 < kzak> swapon fixed and pushed

See above, will be part of next experimental upload.

Regards,
Andreas Henriksson

< 8 9 10 11 12 13 14 15 16 17 >

1201 - 1300 of 2994 matches

Mail list logo