Bug#972672: bash SIGSEGV related to locale

[Uoti Urpala]

On Thu, 22 Oct 2020 11:47:44 +0200 Thomas Schwinge  wrote:
> ..., that is, SIGSEGV, supposedly when bash tries to expand the last path
> component glob ('*'):

I also encountered this bug. After installing bash-dbgsym, gdb says it
crashes at glob.c line 487 in wdequote_pathname(). The immediate cause
of the crash there seems to be that wpathname is NULL.

I suspect that the bug is the "len" argument on the previous line
  n = wcsrtombs(pathname, (const wchar_t **), len, );

Here "len" is byte length obtained for the original string from
strlen(). But the call seems to expect the length of the wide character
version in wpathname which was obtained above with xdupmbstowcs(), and
so the code should use the return value of that function (in variable
n) instead of len. Using too long a length makes wcsrtombs() set the
pointer to NULL when it continues to a zero character.

Bug#964848: sagemath: Integer objects leak memory

[Uoti Urpala]

I investigated this more, and came to the conclusion that Sage is
incompatible with libgmp 6.2 due to the following commit:

https://gmplib.org/repo/gmp-6.2/rev/299ec6187305

This invalidates the assumptions Sage's rings/integer.pyx makes about
libgmp internals. The "global_dummy_Integer" object created there
without an explicit value will now be created using libgmp's new lazy
allocation, and Sage's fast_tp_new() forcibly changing the _mp_d member
of such an object to a new allocation will lead to an inconsistent
state (allocation size still set to 0, but non-dummy pointer set). This
causes libgmp to disregard the existing pointer and leak the memory
when setting a new value in the object.

I believe (haven't tested though) that a quick workaround would be to
change

global_dummy_Integer = Integer()
to 
global_dummy_Integer = Integer(1)
which would force the global default object to use non-lazy allocation.

Bug#964848: sagemath: Integer objects leak memory

[Uoti Urpala]

Package: sagemath
Version: 9.0-4+b1
Severity: normal

It seems the basic sagemath integer objects do not release memory
properly when freed. Quick way to reproduce:

while 1: x=divisors(factorial(15))

running the above line leaks memory at around 100 MB/s order of
magnitude.

A bit longer demonstration that shows the memory leak is about general
integer objects, not about the implementation of divisors() or
factorial():

i = 0
while 1:
a = []
for _ in range(1000):
a.append(i)
i += 1

This repeatedly creates 1000 integers at once, then frees them. If you drop the
number created at once below 100, it stops leaking memory. That limit of about
100 matches the pool size in
/usr/lib/python3/dist-packages/sage/rings/integer.pyx
which I believe shows the relevant Sage integer implementation. Once there are
enough freed integers that they do not fit in the pool, the code doing actual
allocation and release of new objects leaks memory. It seems to access GMP
internals, so the behavior might depend on libgmp version.



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

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

Versions of packages sagemath depends on:
ii  cysignals-tools   1.10.2+ds-4
ii  cython3   0.29.14-2
ii  ecl   16.1.3+ds-4
ii  eclib-tools   20190909-3
ii  fflas-ffpack  2.4.3-1
ii  flintqs   1:1.0-3+b1
ii  gap-atlasrep  2.1.0-2
ii  gap-dev   4.11.0-4
ii  gap-online-help   4.11.0-4
ii  gap-primgrp   3.4.0-1
ii  gap-smallgrp  1.4.1-1
ii  gap-table-of-marks1.2.9-1
ii  gap-transgrp  2.0.4-1
ii  gfan  0.6.2-2
ii  gmp-ecm   7.0.4+ds-5
ii  ipython3  7.16.1-1
ii  iso-codes 4.5.0-1
ii  jmol  14.6.4+2016.11.05+dfsg1-4
ii  lcalc 1.23+dfsg-11
ii  less  551-2
ii  libatlas3-base [libblas.so.3] 3.10.3-10
ii  libblas3 [libblas.so.3]   3.9.0-2
ii  libbraiding0  1.0-1+b1
ii  libbrial-groebner31.2.8-1
ii  libbrial3 1.2.8-1
ii  libc6 2.30-8
ii  libcdd-tools  094j-2
ii  libcliquer1   1.21-2
ii  libec520190909-3
ii  libecm1   7.0.4+ds-5
ii  libflint-2.5.22.5.2-23
ii  libflint-arb2 1:2.18.1-1
ii  libgap7   4.11.0-4
ii  libgcc-s1 10.1.0-4
ii  libgd32.3.0-2
ii  libgivaro94.1.1-2
ii  libglpk40 4.65-2
ii  libgmp10  2:6.2.0+dfsg-6
ii  libgmpxx4ldbl 2:6.2.0+dfsg-6
ii  libgomp1  10.1.0-4
ii  libgsl25  2.6+dfsg-2
ii  libhomfly01.02r5-1+b1
ii  libiml0   1.0.4-1+b2
ii  libjs-mathjax 2.7.8+dfsg-1
ii  libjs-three   111+dfsg1-1
ii  liblfunction0 1.23+dfsg-11
ii  liblrcalc11.2-2+b1
ii  libm4ri-0.0.20200125  20200125-1+b1
ii  libm4rie-0.0.20200125 20200125-1+b2
ii  libmpc3   1.1.0-1
ii  libmpfi0  1.5.3+ds-4
ii  libmpfr6  4.0.2-1
ii  libntl43  11.4.3-1+b1
ii  

Bug#944743: jupyter-notebook: systemd user unit enabled by default, despite per-system TCP port

[Uoti Urpala]

Package: jupyter-notebook
Version: 6.0.0-1
Severity: normal

The package now seems to enable the jupyter-notebook.service user unit
by default (I think this has changed?). Due to how Debian gdm3 is
packaged, this means also starting a server for the Debian-gdm user.

Since the service listens on a TCP port, the usefulness of this default
seems questionable at best. Only one server can use the default port,
and due to the GDM issue even machines with a single human user can
have two distinct user systemd sessions. If you can't rely on the port,
no static URL will work in a browser. If you add a method to query the
right port, you could just as well start the unit at that point.

Bug#923612: grub-pc: grub-install failure leaves package in unrecoverable broken state

[Uoti Urpala]

Package: grub-pc
Version: 2.02+dfsg1-11
Severity: normal

>From logs, the following events seem to have happened:

grub-pc was upgraded under unattended-upgrades. This was when the udev
bug changed disk path. Grub-pc appears to have tried installing in the
old nonexistent path; I assume this part depended on unattended-
upgrades not allowing it to use debconf to ask for a new path. Apt logs
only show "grub-install: error: cannot find a GRUB drive for ...".
After this, no core.img file existed on the machine. grub-pc.postinst
uses the existence of a core.img file to determine the kind of
installation the machine has; with it absent, the package entered a
permanently broken state where further upgrades or dpkg-reconfigure did
nothing.

There are at least two things here which can be considered bugs:

1. If there is no interactive debconf frontend available, the package
goes ahead and calls grub-install with known incorrect arguments.

2. Using the existence of core.img to determine the type of install is
too fragile when this file can be erased by a failed grub-install call,
and after this happens the package state can not be recovered by normal
means (I used a manual grub-install call to restore the file).


I haven't tried reproducing problem 1. Bug 2 can be mostly reproduced
by manually running "grub-install /dev/wtf"; after running that, you
can see that "dpkg-reconfigure grub-pc" no longer works.


BTW the grub-install manual page lists most options, then repeats the
"Install GRUB on your drive." description, and lists the same options
again.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Uoti Urpala]

On Sun, 24 Feb 2019 14:16:03 +0100 Johannes Schauer  wrote:
> I found that some important arguments are still missing. A recent mail by
> Guillem [1] nicely summarizes also many of my own thoughts. I'm going to paste
> the relevant content into this mail for convenience of the reader:

I think those have actually been addressed before, even if they're not
explicitly listed or refuted in the draft.

Guillem seems to accept moving away from current filesystem layout, but
also opposes the resulting layout used by other distributions (which
includes the /bin -> /usr/bin symlink). Do you share that view?

The main issue with Guillem's view is that in practice it would make
the transition more cumbersome and error-prone. If there is no
directory-level symlink, then migrating things requires either creating
individual symlinks for everything instead, or having a flag day to
make sure nothing references the old location any more. In practice
either of those is more problematic than a directory symlink.


> > 1) The merged-/usr-via-symlinks deployment method used by both
> >debootstrap and usrmerge, means that those systems will get
> >permanent filesystem aliasing problems, forever. Even when all
> >files might have been moved to their /usr counterparts in the
> >packages! This is due to the fact that different pathnames can
> >end up pointing (before any canonicalization!) to the same dentry.
> > 
> >This does not only affect dpkg (dpkg, dpkg-divert, dpkg-trigger,
> >etc), and update-alternatives (in a worse way), but any program
> >that uses pathanmes in the filesystem as keys in databases f.ex.

This has already been in use, both in Debian and in other
distributions, for quite some time. No major problems have been
reported. Arguing about "any program" is not useful when discussing
only Debian choices, because the layout is used by other distributions
in any case and programs have to cope.


> > 2) It bypasses the packaging system understanding of what is on the
> >filesystem and creates mismatches between what's on binary packages
> >and what's on disk.

This also has not caused major problems, but it can be solved
straightforwardly in dpkg if needed. Dpkg can special-case any legacy
/bin path contained in a package and internally change it to /usr/bin.


> > 3) Switching packages to the merged-/usr layout could have been
> >accomplished automatically via debhelper for a coverage of around
> >99% (?) of the archive. With something along the lines of:

This would just create a more cumbersome and error-prone migration.


> > 4) Due to having to support the broken merged-/usr-via-symlinks
> >deployment, when we want to move the contents of the binary
> >packages to the merged-/usr layout, we require now to include tons
> >of logic in (probably new) maintainer scripts, when we have been
> >trying to remove them altogether. :( With even more files untracked
> >by dpkg itself, bypassing the packaging system even more, when the
> >compat symlinks could have been shipped in the binary packages.

This seems to be based on questionable implicit assumptions. Namely
that the move would want to create an individual per-file compatibility
symlink in /bin for non-merged systems, and this is the part which
would cause problems. There seem to be neither technical reasons to
prefer non-merged systems for any use nor practical difficulties
migrating existing systems to the merged layout, so long-term it seems
OK to deal with this by just requiring merged-usr and not shipping any
individual compatibility links for non-merged systems. This allows the
simplest possible move - just install the files in /usr normally.


> > 5) Most new installations will not even benefit from this hacky and
> >rushed deployment, as long as they do not use a separate parition
> >for /usr!

Is there a point to this? Yes, migrating to merged /usr is mostly an
internal implementation detail for most users. But this does not
exactly give any argument against the migration, other than calling it
"hacky and rushed" while it seems to be the most practical way to do
things.


> > 6) The merged-/usr-via-symlinks deployment hack is irreversible right
> >now.

This is not a reason to avoid using the merged-usr layout.


> Just like Guillem, I'm personally not against merged-/usr but against how we
> implement it.

Not against, except for the directory symlinks being part of the
merged-usr layout?

Bug#907429: closed by Patrick Matthäi (Bug#907429: fixed in libphysfs 3.0.1-3)

[Uoti Urpala]

On Thu, 2018-11-29 at 14:57 +, Debian Bug Tracking System wrote:
>* Add upstream patch 02-fsync.

This patch file is completely broken:

> # Upstream patch to fix a performance problem.
> # Closes: #907429
> # URL: https://hg.icculus.org/icculus/physfs/rev/c17f025e7a92
> 
> diff -Naur libphysfs-3.0.1.orig/physfs.c libphysfs-3.0.1/physfs.c
> --- libphysfs-3.0.1.orig/physfs.c   1970-01-01 01:00:00.0
> +0100
> +++ libphysfs-3.0.1/physfs.c2018-11-29 15:05:50.430790919 +0100
> @@ -0,0 +1,44 @@
> +
> +diff -r ece6769c0676 -r c17f025e7a92 src/physfs.c
> +--- a/src/physfs.c Wed Oct 03 22:40:57 2018 -0400
>  b/src/physfs.c Tue Nov 27 23:53:33 2018 -0500
> +@@ -2669,7 +2669,6 @@
> + {

This adds a top-level file physfs.c (instead of modifying src/physfs.c)
which contains the text of what looks like the actual intended patch
for src/physfs.c. Obviously adding this new invalid .c file without any
build system changes is just ignored, and does not have any effect on
the build result.

Bug#912695: Bug#912970: fixed in apt-show-versions 0.22.9

[Uoti Urpala]

On Wed, 2018-11-07 at 09:25 +0100, Christoph Martin wrote:
> Am 07.11.18 um 00:30 schrieb Uoti Urpala:
> > Upgrade and reinstall still fail.
> 
> Please do some tests for me with the new apt-show-versions. I set a
> higher limit in line 271. The default value on amd64 is 8552. I set it
> to 65536. But the actual needed limit for your installation might be
> even higher.

Doubling the value to 131072 made it work.

> Do you have more than the usual list of sources in /etc/apt ?

The failures happened with these in sources.list:
unstable, unstable-debug, src:unstable, experimental, src:experimental,
all for [main contrib non-free].

Bug#912695: Bug#912970: fixed in apt-show-versions 0.22.9

[Uoti Urpala]

On Tue, 06 Nov 2018 11:34:18 + Christoph Martin  wrote:
>* set a higher limit for the hash stacksize in perl Storable (closes:
>  #912695, #912709, #912970, #898090)

Upgrade and reinstall still fail.

Bug#912695: Bug#912970: fixed in apt-show-versions 0.22.9

[Uoti Urpala]

On Tue, 06 Nov 2018 11:34:18 + Christoph Martin  wrote:
>* set a higher limit for the hash stacksize in perl Storable (closes:
>  #912695, #912709, #912970, #898090)

Upgrade and reinstall still fail.

Bug#907429: neverball: Constant fsync calls seriously degrade performance

[Uoti Urpala]

On Tue, 16 Oct 2018 11:32:34 -0400 "Ryan C. Gordon"  wrote:
> 
> Can someone humor me and make a quick change to Neverball for me?
> 
> In neverball/share/fs_physfs.c, there are three calls to 
> PHYSFS_setBuffer(). Just comment them out and rebuild Neverball with 
> PhysicsFS support and see if the problem goes away on the machine with 
> the slow disk.
> 
> I suspect I know what the problem is (which would be a bug in PhysicsFS, 
> not Neverball, to be clear), but this will confirm it for me.

I tried this and can confirm that removing setBuffer calls avoids the
fsyncs. I verified this with strace too, which should be doable on any
machine (just "strace -o /tmp/output ./neverball", and after playing
check that /tmp/output contains no fsync calls).

Bug#907057: neverball: Constant fsync calls seriously degrade performance

[Uoti Urpala]

On Wed, 2018-08-29 at 15:27 +0200, Markus Koschany wrote:
> Am 29.08.2018 um 15:08 schrieb Uoti Urpala:
> > If FPS stays sufficiently high that it's not a visible issue, you could
> > try running the binary under strace for example and verify that there
> > are lots of fsync calls while playing. (The calls probably aren't good
> > for the SSD either, even if they don't prevent playing the game.)
> > strace -e fsync -o /tmp/file neverball
> 
> My point is that it isn't something most players would experience as a
> serious performance penalty. The game hasn't changed in years, so either
> it is not perceived as something really serious by many or there is a
> recent regression in libphysfs. Then it should be fixed there.

I'm pretty sure it is a regression - years ago SSDs were not that
common. And even if "most players" use it on machines with an SSD
storing the save directory, the constant fsyncs likely increase SSD
wear, so it's not harmless there either.


> > > Not using libphysfs would be a workaround and not a fix. Hence I am
> > 
> > I'm not sure why you're saying this. Given that upstream Neverball has
> > also stopped defaulting to libphysfs use, it seems like a quite
> > reasonable solution.
> 
> Sure, not using your car when the tires are flat and instead going to
> work by train is a reasonable solution, if you don't want to be late.
> Most people will still want to fix the tires though because that's the
> issue at hand.

That comparison seems wrong. It assumes there are reasons you'd want to
go back to the car (physfs) eventually. Given that upstream has changed
the default, it's not an appropriate comparison here.


> > AFAIK the version currently in Debian can be built with libphysfs
> > disabled too. "Not actionable" seems like an exaggeration, even without
> > packaging a new non-release version.
> > 
> > I just ran a quick test, and building without libphysfs-dev worked with
> > "git checkout neverball-1.6.0; make -j 6 ENABLE_FS=stdio".
> 
> By not actionable I meant that upstream should do a proper release. This
> is not something Debian can do. When they did that, we and all other

However, changing the Neverball build configuration should be well
within what is actionable by Debian.

> distributions would package the new release. It is absolutely not clear
> whether they consider all there other changes as feature complete. In
> the worst case, we fix this bug but open a can of worms for other users.
> Yes, usually it is not as bad for games but surely for other software in
> the archive. There is also a good reason for using fsync. It protects
> you against data loss.

Cases where fsync() is the right tool are actually pretty rare. And
this absolutely isn't one of them (particularly the Neverball save file
case, but more generally physfs doing fsync() calls when the
application hasn't explicitly requested them is not right either).

Bug#907057: neverball: Constant fsync calls seriously degrade performance

[Uoti Urpala]

On Mon, 2018-08-27 at 23:13 +0200, Markus Koschany wrote:
> Am 27.08.2018 um 03:36 schrieb Uoti Urpala:
> > Neverball is broken so at least a bug blocked by a physfs bug would be
> > appropriate in any case, and I assume that the easiest way to fix the
> > problem would be to change the Neverball package to stop using
> > libphysfs.
> 
> I cannot confirm that Neverball is broken. I don't see any performance
> issues on my system which is a X230 Lenovo Laptop, not quite a gaming
> laptop but capable to play the game. However I cannot test whether there
> is a performance degradation on slower non-SSD hard disks. So this may
> or may not an issue for older hard disks. 

If FPS stays sufficiently high that it's not a visible issue, you could
try running the binary under strace for example and verify that there
are lots of fsync calls while playing. (The calls probably aren't good
for the SSD either, even if they don't prevent playing the game.)
strace -e fsync -o /tmp/file neverball

> Not using libphysfs would be a workaround and not a fix. Hence I am

I'm not sure why you're saying this. Given that upstream Neverball has
also stopped defaulting to libphysfs use, it seems like a quite
reasonable solution.

> going to clone and reassign this bug report to libphysfs. Upstream have
> not been released a new version for years. Perhaps I will try a recent
> Git snapshot in the future but this surely must be fixed upstream.
> Please ask the upstream developers of Neverball to investigate this
> issue and release a new version. This is not actionable by Debian itself.

AFAIK the version currently in Debian can be built with libphysfs
disabled too. "Not actionable" seems like an exaggeration, even without
packaging a new non-release version.

I just ran a quick test, and building without libphysfs-dev worked with
"git checkout neverball-1.6.0; make -j 6 ENABLE_FS=stdio".

Bug#907057: neverball: Constant fsync calls seriously degrade performance

[Uoti Urpala]

On Sun, 2018-08-26 at 17:59 +0200, Markus Koschany wrote:
> On Thu, 23 Aug 2018 17:56:01 +0300 Uoti Urpala 
> wrote:
> > Neverball automatically saves a replay of the latest run on disk while
> > playing. In the Debian package, the binary constantly calls fsync() on
> > this file, which very seriously degrades performance. If the issue is
> > not obvious when trying to reproduce, try on a machine with as slow a
> > spinning disk as possible.
> > 
> > This is likely a libphysfs issue. Neverball code contains no direct
> > fsync() calls. Neverball upstream has changed the default filesystem
> > backend to be stdio instead of libphysfs, and current upstream code
> > (with no physfs) does not display the problem.

> Why did you report this bug against neverball instead of libphysfs when
> all the issues you describe are related to libphysfs?

Neverball is broken so at least a bug blocked by a physfs bug would be
appropriate in any case, and I assume that the easiest way to fix the
problem would be to change the Neverball package to stop using
libphysfs.

Bug#907057: neverball: Constant fsync calls seriously degrade performance

[Uoti Urpala]

Package: neverball
Version: 1.6.0-8
Severity: important

Neverball automatically saves a replay of the latest run on disk while
playing. In the Debian package, the binary constantly calls fsync() on
this file, which very seriously degrades performance. If the issue is
not obvious when trying to reproduce, try on a machine with as slow a
spinning disk as possible.

This is likely a libphysfs issue. Neverball code contains no direct
fsync() calls. Neverball upstream has changed the default filesystem
backend to be stdio instead of libphysfs, and current upstream code
(with no physfs) does not display the problem.

In case this depends on precise libphysfs version, seen with
libphysfs1 3.0.1-2 on AMD64.

Bug#899998: nvidia-legacy-340xx-kernel-dkms: Dmesg output: "Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'nvidia_stack_t'"

[Uoti Urpala]

On Thu, 24 May 2018 09:14:34 -0500 Phil Miller  wrote:
> At present, this doesn't hurt functionality of a default configuration system,
> but it would prevent someone using the nvidia driver from enabling the 
> kernel's
> usercopy protections. In future kernel releases where those protections are
> enabled by default, this bug will become more serious.

Kernel package version 4.16.16-1 has this:
* hardening: enable FORTIFY_SOURCE, disable HARDENED_USERCOPY_FALLBACK

I think this means that the driver is broken with the current kernel in
unstable. Booting with the kernel commandline parameter
"slab_common.usercopy_fallback=Y" may work around the problem?

Bug#889793: lyx: python errors while building ngspice

[Uoti Urpala]

On Wed, 07 Feb 2018 01:12:57 +0100 Andreas Beckmann  wrote:
>   File "/usr/share/lyx/scripts/TeXFiles.py", line 112
> print(root.replace('\\', '/') + '/' + file, file=out)
> ^
> SyntaxError: invalid syntax

That error is a bit surprising as it's legal Python 3. I guess the
problem was that the Python sources were converted to be Python 3
compatible, but the lyx binary (implemented in C++) starts an explicit
Python binary in a child process rather than relying on shebang lines?
That was not updated to call Python 3, so Python 2 failed when trying
to process the version 3 compatible source.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

On Sat, 10 Dec 2016 06:54:17 +1030 Ron  wrote:
> You then had the gall to angrily insist that while you thought he might
> be a better maintainer than me, it was still my responsibility to do the
> work to fix all the obvious things that others had missed in their fork
> (which he hadn't contributed anything to either).  I'm afraid that's not
> how encouraging volunteers to contribute their time for you works ...
> sorry if this is news to you.

It was perfectly reasonable to ask that if you have any pretense at all
of actually doing the work expected of your maintainer position, you'd
contribute to creating packaging for the new upstream version, instead
of only attacking the people working on it.


> things.  But because the increasingly ill-named technical committee has once
> again refused to stick its collective necks out to actually offer technical
> advice when explicitly asked to.  We chopped some heads off the hydra, but

> Explaining things in careful detail has had every appearance of being a
> complete waste of my time whichever way this might have ended up.  The only

The fundamental problem with most of your technical arguments was that
they were arguments about upstream development, not about packaging.
Even if they were 100% true, they still would not justify how you have
handled the Debian package. If you disagree with upstream that way, you
should try to convince them, and if that fails and you care enough,
create a new upstream fork.

Instead, you turned the Debian packaging into a practical fork. That's
not the right place for hosting a new fork. You also obviously did a
bad job of maintaining your fork (given the complete lack of
development). Your attitude seems to have been that you insist on
keeping the original GLOBAL out of Debian, do no development at all
yourself, and if anyone has problems with your fork you insist that
they do the work of developing it. That's not reasonable at all.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

On Mon, 21 Nov 2016 17:16:34 +1030 Ron  wrote:
> If we run with your proposal, what are you actually suggesting we tell
> the people who'd be upset by the loss of htags without notice in Stretch?
> Because I don't really see how you've addressed that here.
> 
> AFAICS, there's just either an implicit "Sucks to be you", or an
> implication that this is a simple "regression" which might be fixed
> by sending patches upstream.

Assuming the htags functionality really can't be supported with a newer
upstream version: tell people that the functionality is no longer
available in current GLOBAL. If someone - including you - thinks this
is a major problem and wants to provide an alternative, a fork
providing this functionality can be packaged. Under a name other than
"global".


> FWIW, I actually agree with a lot of the general rules of thumb that
> you outlined here, about how things should work in the normal case.
> But this isn't really a "normal" case, if it was we wouldn't be talking
> about this here at all.  What to do would be obvious to everyone.

There's nothing particularly "abnormal" about disagreeing with upstream
decisions. What is unusual, and is the reason why this has been
escalated here, is how badly you have handled the situation in your
packaging.


> The group complaining loudly now have basically squandered the entire
> release cycle by not reporting actionable bugs about what they need,
> and haven't sent any patches to remedy that.  And they are proposing

If anyone has "squandered the release cycle", it's you. You already
knew, or should have known, that the package was in an untenable state.
You've failed to fix the situation for years. You don't get to blame
other people for that.

> 

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

On Tue, 8 Nov 2016 15:33:32 +1030 Ron  wrote:
> On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote:
> > It seems you're only interested in impartial and non-partisan voices
> > when they happen to back your position. I am impartial and non-partisan,
> > and formed my opinion by reading the bugs and your emails.
> 
> And "your opinion" still hasn't said even a single word to show that you
> understand the technical problem here, or to offer any solution to it.
> The problem which doesn't just magically go away regardless of who might
> implement it.

Even if your technical concerns were correct, they do not justify your
handling of the package. Saying that your actions have been wrong, and
the package needs to be handled differently, does not require
addressing the technical CGI issues in any way. You have no basis to
insist that people care about the CGI issue or try to solve it before
commenting on other handling of the package.


> > If you indeed welcome opinions from people like me, your statements
> > above are a little odd.
> 
> I think you missed the bit about "comprehending the problem and building
> consensus on solutions" - because if this is all you have to offer then
> no, "opinions" from people "like you" are neither helpful nor welcome.
> Even if they 100% agree with me.  They are just a toxic symptom of people
> still ignoring the hard technical problem.

"The problem" here is the way you've blocked the package at an ancient
version. Fixing this does not require creating a perfect CGI framework
or in any other way fixing all upstream issues and making the software
perfect. Maybe _you_ really care about the CGI issue. But if nobody -
including you - cares enough to create a perfect solution, then it'll
be broken. Too bad, but even if you're really disappointed, holding the
package indefinitely at an obsolete version is not an acceptable
response. Again, that nobody has created a perfect upstream does not
justify your handling of the package, and you don't get to blame others
or call their behavior "toxic" because of that.


> details of _what_ we ought to do.  If we don't solve that, then who does
> it is kind of irrelevant, there'll still be a Hard Problem that someone
> won't be happy with.

You keep talking about Hard Problems and how others must solve them to
be allowed to criticize your actions or actually do anything to change
the status quo that you've failed to improve for several years. That's
bullshit. If someone packages a new upstream without solving those
issues, that'll be perfectly acceptable. Fixing software to be perfect
is not a requirement for packaging, and creating a package that lacks
some desired functionality when upstream lacks it is OK. The way you've
handled the package is not OK.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

Note: this is written as an outsider who doesn't have any direct stake
in the issue.

On Sun, 6 Nov 2016 05:00:12 +1030 Ron  wrote:
> > And I think the latter is basically what the "just ship multiple
> versions and hope the future gets clearer" option boils down to.
> All it really does is take the pressure off of everyone but me
> to have any interest at all in actually trying to resolve the
> genuinely Hard part of this.  And it does that by making an even

I don't think the others have any obligation to try to resolve any
technical issues, and it is 100% reasonable of them to insist that
Debian just ship a new upstream version (as long as the packaging is
not otherwise unacceptably bad; but simply disabling any functionality
that is not secure or otherwise OK upstream is a valid answer).

Based on what I've seen in this thread, I think I can say you're
clearly in the wrong. And that does not require considering any of the
technical issues with the software. The software now shipped in Debian
as "global" is simply too outdated compared to upstream. That you have
technical objections to something in the newer versions could be a
reason for you to create a new fork. But you have not properly done
that, and abusing your Debian packager position to indefinitely hold
back the package is not an appropriate answer to any technical issues,
regardless of the validity of the technical objections.

To properly create a fork, you'd need to either pick a new name for
your fork, or contest whose version has the right to the name "GLOBAL".
You have obviously not chosen a new name. You don't seem to be claiming
to be the overall upstream maintainer of GLOBAL either, and claiming
that would be totally inappropriate if you're only shipping your
version in Debian. As such, you have no business shipping your version
under the "global" package name. Either ship the upstream version -
even if flawed and causing problems for some users - or use another
package name.

Bug#830978: Browserified javascript and DFSG 2

[Uoti Urpala]

On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands <p...@hands.com> wrote:
> Uoti Urpala <uoti.urp...@pp1.inet.fi> writes:
> 
> > In what sense couldn't everyone modify the concatenated form?
> 
> Perhaps if I frame my question from:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90
> 
> in another way, I'll get an answer.

Isn't this the separate issue Ansgar already mentioned in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#45

Bug#830978: Browserified javascript and DFSG 2

[Uoti Urpala]

On Mon, 18 Jul 2016 09:02:08 +1000 Ben Finney <ben+deb...@benfinney.id.
au> wrote:
> On 17-Jul-2016, Uoti Urpala wrote:

> > If you want to argue "upstream convenience" as a reason for the
> > second,
> 
> Maybe if that were the only justification offered. That's not the case
> though.
> 
> 
> Reading the discussion on debian-devel, and even reading the
> discussion in this bug report, the argument for the source form of the
> work rests on *whether* the form of the work allows modification on an
> equal basis with upstream.
> 
> Neil Williams puts it well in this same bug report:
> 
> Where one format can be modified by every user and another format
> can only be modified by some users, then the format which can be
> modified by everyone *must* be the accepted format or the package
> fails DFSG. When the second format is actually generated from the
> first format and cannot exactly regenerate the first from the
> second, it is obvious that the second format is not the source
> code in terms of the DFSG as changes to the second would be lost
> when the first is updated and the second gets regenerated.
> 
> <URL:https://bugs.debian.org/830978#95>;
> 
> Nothing about “upstream convenience” there.

That's exactly the post I was replying to, and it does spend a lot of
time talking about ability to get the changes upstream - both from
upstream point of view and ability of the person doing the changes to
get them there.

As for this particular quote, the terminology of "a format that can be
modified by every user" is not clear at all to me. In what sense
couldn't everyone modify the concatenated form?

And if you get too picky about preferred format, then that's a git
repo, not a tarball. If I want to make upstreamable changes to some
software in Debian, then first I clone the upstream git; that's the
form I prefer for doing modifications, and the single-version tarball
exports Debian distributes are a distinctly inferior form generated
from that.

> It's about equal access,
> for all recipients of the work, to make and share their own build from
> the source form of the work.
> 
> That entails receiving the work in such a form, and with all necessary
> build scripts, to make modifications (or choose not to modify) and
> build the work themselves to get the same result. That is, in brief,
> the source form of the work.
> 
> Without the form of the work that is the *input* to the build tools,
> and the build tools and script themselves as free software in Debian,
> then the recipient cannot be said to have what they need to exercise
> DFSG freedoms.

You're not really saying anything meaningful here IMO. The recipients
would be able to make modifications to a concatenated form and build
the work themselves to get the same result. They would have all the
necessary build scripts etc to do the work. So what you're talking
about here does not in any way imply they wouldn't have the source. Of
course, if you've already declared that what they have isn't source
then there's a problem - but unless you _start_ from that assumption,
what you write above does not give any criteria which could be used to
arrive to that conclusion.

Bug#830978: Browserified javascript and DFSG 2

[Uoti Urpala]

On Sat, 16 Jul 2016 00:02:55 +0100 Neil Williams 
wrote:
> On Fri, 15 Jul 2016 23:45:01 +0530
> Pirate Praveen  wrote:
>> If this argument is accepted, we will not be able to package a fork
>> because the original upstream won't accept a patch against the fork.
>> Similarly we'd be able to package only HEAD of the vcs as they
>> usually accept patched only against HEAD. Porting patches is an
>> essential part of packaging. By choosing to maintain this source, I
>> accept this challenge. If I cannot keep the package rc bug free
>> otherwise, it will be removed any way.

I think the part about packaging only VCS HEAD is an excellent point,
and really needs to be addressed by people who want to argue that
concatenating files should be an RC bug.


> Where do you get this crazy and fanciful notion that upstream are
> somehow second-class community members? Upstream are users of the

I don't think he was saying that at all. If I consider this from an
upstream point of view, I'd say that the packaging being behind latest
upstream version is a more significant issue than the packaging using
source transformations like concatenating files. People who want to
make large, complex changes are likely to use upstream files directly
anyway, so that limits the extra work caused by working around such
transformations. Packaging old versions causes similar issues for
patches based on outdated code, and additionally several other issues,
like preventing upstream from getting timely feedback about changes and
causing upstream to receive complaints about already fixed bugs.

In essence, my central point is that you cannot consistently believe
BOTH of these:
* packaging not being up to date with latest upstream is just a
  wishlist bug
* packaging concatenating source files is such a horrible bug that the
  package should be removed from Debian

If you want to argue "upstream convenience" as a reason for the second,
then you must also accept that being behind latest upstream is a lot
more serious than wishlist.

If the TC wants to make a statement against concatenating files, then I
hope any such statement also mentions that being behind latest upstream
should be considered an equally serious bug. If the TC is not willing
to consider such an addition, then they should IMO also reconsider
whether it's really valid to use upstream preferences as a
justification for such a statement at all.

Bug#799953: gcc-4.9: incorrect double to integer conversion on i386

[Uoti Urpala]

On Tue, 17 Nov 2015 13:47:29 +0100 Miroslav Urbanek  
wrote:
> > What's the result type of float * int ? Definitively not double, but
> > float. (Just the intermediate result in the x87 fpu has extended
> > precision.)
> 
> True, according to C11 standard, section 6.3.1.8, the result type of
> float * int is float.

You seem to misunderstand the consequences of this fact.


> > So I don't think the compiler is wrong considering d and g to
> > contain the same information, since the same *float* value was

> I think the compiler is wrong. C11 standard, section 6.5.1, says:
> 
> "The type of an assignment expression is the type the left operand
> would have after lvalue conversion."

This is true, but you don't seem to understand what it actually means.
Yes, the type of the assignment expression is double. But it's a value
converted from float, and the calculation in floats may already have or
have not lost precision prior to that conversion.

 
> I couldn't find any GNU extensions that change arithmetic conversion
> rules.

The switch you failed to find is likely -fexcess-precision ("enabled by
default for C if a strict conformance option such as -std=c99 is
used").


> The bug PR323 is caused by excess precision of some
> values. Here, it's the opposite case. Value in d is double, but in the
> expression "int i = d", GCC uses a floating approximation to this
> value, which has obviously lower precision. I think it's clearly a
> bug.

No, it is not in any sense "opposite". Your test code calculates
"f*atoi(argv[1])" at float precision. That any following calculation
based on that value may use more precision than a standard float is an
example of excess precision, exactly the known issue in PR323.

In summary: I don't think there is anything new or unexpected here.
Overall this behavior is just another example of the well-known excess
precision issue. This bug report should likely be closed without any
other action.

Bug#797733: Please support dynamically disabling audio pitch correction

[Uoti Urpala]

The following keybinding should do this:
cycle options/audio-pitch-correction

With "cycle" this will switch between on and off.

Bug#787950: mdadm: checkarray doesn't work with dash

[Uoti Urpala]

This is a kernel/dash issue. In kernel 4.0, the md sysfs implementation
does not work with partial reads from /sys/block/md0/md/sync_action;
the read syscall returns the entire contents of the file even if you
try to read less. Dash has an inefficient implementation which reads
input one byte at a time, and fails when it hits the kernel
misbehavior.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#770504: systemd: log all members of cyclic dependencies (loops)

[Uoti Urpala]

On Fri, 21 Nov 2014 20:20:45 + Simon McVittie s...@debian.org wrote:
 dependency: systemd logs that there was a loop, and which arbitrary point
 it tried to use to break it. However, it does not log (an example of) the
 whole path around the loop before it started trying to break it.

IIRC it does log that. If you don't see it, make sure that is not caused
by visible log level issues or such.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763489: fixed in openjdk-7 7u71-2.5.3-1

[Uoti Urpala]

On Thu, 23 Oct 2014 17:36:15 + Matthias Klose d...@ubuntu.com wrote:
* Change B-D to libjpeg-dev to finish the transition to libjpeg-turbo
  (Ondřej Surý). Closes: #763489.

openjdk-7-jre-headless version 7u71-2.5.3-1 depends on libjpeg8 AND
libjpeg62-turbo. I assume this isn't right...


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765784: systemd: Very slow boot time (4 Minutes).

[Uoti Urpala]

On Wed, 22 Oct 2014 18:23:54 +1100 Marc Bonnor ma...@iprimus.com.au wrote:
 The command ls -l /tmp also blocks ...

That pretty much confirms that it is a filesystem problem not directly
related to systemd.

 The line before the lines shown in the file extract has an odd looking
 path //tmp, do you think this may be problem ?

No, that works the same as /tmp.

 The st_size=117604352 looks very large, is this normal, does it
 represent free disk space?

st_size means the disk space used for the directory data. That is a very
large amount. Most likely you've had a huge number of files in /tmp at
some point, and the directory keeps a large size even after the files
have been deleted. Whether this behavior of making later access very
slow should be considered a bug is a question better asked from
kernel/filesystem maintainers.

You can probably work around the problem by deleting the directory
(preferably when the system is not fully up and using the contents) and
creating or letting tmpfiles (after reboot) create a new one.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765784: systemd: Very slow boot time (4 Minutes).

[Uoti Urpala]

Marc Bonnor wrote:
 I have run the strace command as suggested and attached the output.

 18:58:28 open(/tmp, 
 O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = 4
 18:58:28 fstat(4, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=117604352, ...}) = 0
 18:58:28 fcntl(4, F_GETFL)  = 0x78800 (flags 
 O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME)
 18:58:28 fcntl(4, F_SETFD, FD_CLOEXEC)  = 0
 18:58:28 getdents(4, /* 10 entries */, 32768) = 336
 19:02:25 openat(4, .X11-unix, 
 O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = 5

Well that's quite weird. Basically the tmpfiles process is doing the
equivalent of ls /tmp, and the kernel is taking 4 minutes to return
the result, even though there are only 8 files/directories there (plus
'.'/'..' for total 10). This looks more like a filesystem issue than a
tmpfiles issue or any systemd-related issue.

To verify this, try running ls -l /tmp in the debug shell while the
tmpfiles job is running. I expect that the ls will also block for as
long as tmpfiles does.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Uoti Urpala]

On Mon, 20 Oct 2014 10:06:31 -0400 Martin Pitt mp...@debian.org wrote:
 I'll leave this to the Debian maintainers, as I'm mostly responsible
 for the Ubuntu side, haven't really discussed this with the two
 Michaels/Tollef/Marco, and I don't feel qualified to speak for the
 Debian systemd team.
 
 My personal opinion: Given how close we are to the release and how
 many regression reports we still get, it seems prudent to not change
 the currently running init systems for upgrades for Jessie yet, but
 only set up systemd for new installs. I know this is not really in the
 spirit of the TC decision to make systemd the default init system, but
 at this point in time it might be the pragmatic compromise.
 
 The systemd package gets literally swamped with bug reports (of all
 kinds of usefulness/quality), and there's simply not enough
 maintainers to keep up with the flood. Many of those are indeed not
 actual bugs in systemd, but bugs in other packages, local

That swamped with bug reports does not match my impression of reading
the systemd packaging list. As far as I can tell, this is not the view
of the Debian maintainers either.

My impression from the bug reports is that systemd-shim does not work
particularly reliably. So automatically installing systemd-shim does not
seem any safer than automatically installing systemd from the view of
avoiding breaking old systems.


 The other direction (running sysvinit or upstart with -shim) has not
 been so unproblematic though, as systemd-shim's bug list shows. This
 definitively needs some love, but then again we've run this for a fair
 while in Ubuntu (even in our 14.04 LTS) without too many problems. So
 my feeling is that we can certainly stabilize -shim by the jessie
 release. (We need to do that anyway, as we need to support sysvinit
 regardless of what we do on upgrades/new installs.)

Is there some reason to believe that there would be _more_ success with
this than with resolving the remaining integration issues with systemd?
And shouldn't work on the latter be higher priority?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765784: systemd: Very slow boot time (4 Minutes).

[Uoti Urpala]

Marc Bonnor wrote:
 I have also poked around in the debug shell during boot and there is almost no
 cpu activity and the systemd-tmpfiles command has statuts 'D' uniteruptable
 sleep.
 
 I used iotop to view io activity during the boot and this 'Executing: /bin
 /systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev' accounts for
 all io activity, about 99.9%. The command is reading only and the accumalated
 read size gets into the mulitple megabytes ...

If iotop shows it reading, that sounds like systemd-tmpfiles is actually
doing something then. What do you mean by accumulated read size
though? iotop shows no such column? If you really mean that the read
speed is well below 1 MB/s and the total read size only reaches
megabytes over time, that sounds like a very slow read speed for a
program reading at the maximum speed the system allows, even if it's
doing seek-heavy directory traversal rather than linear reads.

Try to strace the process to see what kind of activity it is doing. The
most likely guess I can think of is that tmpfiles somehow ends up
traversing some large directory tree on your machine, and spends the
time waiting for its contents to be read.

If that is what actually happens, getting a full strace log from the
start of the process could help determine what causes this. One way to
capture this would be to change systemd-tmpfiles-setup.service from
ExecStart=/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
to something like
ExecStart=/usr/bin/strace -D -o /straceout.txt /bin/systemd-tmpfiles --create 
--remove --boot --exclude-prefix=/dev
which will write the output to /straceout.txt.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762522: \2d showing up in journalctl

[Uoti Urpala]

Marco d'Itri wrote:
 On Sep 23, 積丹尼 Dan Jacobson jida...@jidanni.org wrote:
  Why the \x2d in one 'slice' but not the other?
 Because one contains / and the other does not.

2d hex is '-', not '/'. The actual reason is that '-' in slice names has
a special meaning to separate hierarchical components, and '-' within
component names is escaped. system-systemd\x2dfsck.slice means
subslice systemd-fsck of system slice, and it's printed that way to
distinguish it from a 3-level hierarchy system, systemd, fsck.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Uoti Urpala]

On Thu, 2014-09-18 at 17:14 -0700, Cameron Norman wrote:
 On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett j...@joshtriplett.org wrote:
  Personally, in this case, I'd argue that the desirable dependency (which
  we can't easily express) would be sysvinit-core ? systemd-shim :
  systemd-sysv.
 
 To be more precise, it would be !systemd-sysv ? systemd-shim :
 systemd-sysv so that other alternate inits are treated equally.
 
 As you hopefully can see, this can be condensed to systemd-sysv ?
 systemd-sysv : systemd-shim AKA systemd-shim | systemd-sysv :)

You completely missed the point, which was to distinguish between
systems that have explicitly installed the new use-sysvinit-as-init
package and systems that only use sysvinit because they have not yet
upgraded to the new default. Neither of those have systemd-sysv
installed, thus your version does not work.


From another mail:
 If the transition is already happening, why have the dependency be
 like it is anyway? User's systems will be switched regardless, so
 there is no use in having a second pass at changing the init.

For partial upgrades.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762041: systemd: upgrading systemd results in /run/user/uid being emptied

[Uoti Urpala]

I checked that this did not happen on a system I just updated from 204
to 215; contents of /run/user/1000 remained unchanged after the upgrade.

Are you sure that the upgrade actually *removed* contents? A possibly
relevant change is that logind started to mount a per-user tmpfs
in /run/user/* (for per-user size limits). If something on your system
triggered a mount of a new tmpfs over the existing directory, that could
give similar symptoms.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Uoti Urpala]

On Thu, 2014-09-18 at 12:23 -0700, Steve Langasek wrote:
 On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
  I agree completely that it doesn't make sense for the transition from
  sysvinit to systemd to take place via libpam-systemd rather than via
  some core package like init,
 
 And yet you are arguing that the libpam-systemd dependency should not be
 inverted, for political (not technical) reasons.

He did give *technical* reasons to not invert the dependency. I also
agree that it's suboptimal if the init system changes as a side effect
of upgrading/installing some other, seemingly unrelated, package.
However, that does not make it a good idea to install shim as a side
effect instead. At least the case where you do partial upgrades of
packages that now add a libpam-systemd dependency is one where
systemd-sysv first seems technically correct (more below).

When doing partial upgrades, I think the ideal user experience would be
to inform the user that he should do the migration to systemd at this
point before proceeding to update certain individual packages to newer
versions.


 If we decide that init *should* be automatically changed on upgrade, then
 the ordering of the dependencies on libpam-systemd is immaterial except in
 the specific case that someone has upgraded to (or newly installed) jessie,
 selected an init system other than the default, and subsequently installed a
 desktop environment on a system that didn't initially have one.  In this
 case, installing the DE *definitely* should not override the user's
 explicit selection of init system.

It is also relevant if someone does a partial upgrade to current
unstable from an older system that still uses sysvinit for legacy
reasons only (and is expected to switch to systemd at *some* point in
any case). Installing shim would make the user waste effort dealing with
shim's problems, while still requiring them to deal with any
incompatibilities from the systemd transition at a later point.
Deferring some issues in this way while increasing the amount of overall
work and problems could be a valid choice in particular cases, but I do
not thing it should be the default behavior.


 If the bugs in systemd-shim are too severe to allow it to be used with
 logind (a claim that I do not agree with - and I think you and Michael are
 moving the goalposts by using the existence of bugs in
 cgmanager+systemd-shim /in general/ as a justification for delaying the
 change in dependency order), then those bugs should be marked as
 release-critical, and the determination should be made by the usual means
 whether systemd-shim should be included in the release.  But it is not for

There is a difference between a package that's functional enough to be
useful for people who know what they're doing, and a package that's
suitable to be automatically installed just because people do partial
upgrades in a particular order. And it seems that systemd-shim falls in
the first camp (though I have not followed it closely myself). It may
not be RC-buggy, but not RC-buggy is not a sufficient quality
criterion to install it automatically if a user just wants newer GNOME
packages for example.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752259: systemd: User interaction regarding Ordering cycle found: D-Bus System Message Bus Socket

[Uoti Urpala]

 Then I have learned (by browsing the logs) that systemd basically
 unsupported on a system using /usr as a separate mount. I am sure
 (pre|post)inst haven't mentioned that.

Systemd does support setups where /usr is a separate partition, but such
setups require an initramfs which mounts both / and /usr together. I'm
not sure if the systemd package could easily detect whether the setup is
OK or not to warn about it at install time. At least any actual fixes
belong in other packages.


 It should not keep breaking the _same_ loop infinite times.

The attached patch to systemd could help. I haven't tried running it at
all, but at least the existing code looks suspicious, so if correct the
patch could fix the same issue.

From 6d575f18437dd5bfd02c4736dbd3e6a8a1286ab2 Mon Sep 17 00:00:00 2001
From: Uoti Urpala uau@glyph.nonexistent.invalid
Date: Mon, 23 Jun 2014 08:14:22 +0300
Subject: [PATCH] core/transaction: fix cycle break attempts outside
 transaction

transaction_verify_order_one() considers jobs/units outside current
transaction when checking whether ordering dependencies cause cycles.
It would also incorrectly try to break cycles at these jobs; this
could not work, as the break action is to remove the job from the
transaction, which is a no-op if the job isn't part of the transaction
to begin with. The unit_matters_to_anchor() test also looks like it
would not work correctly for non-transaction jobs. Add a check to
verify that the unit is part of the transaction before considering a
job a candidate for deletion.
---
 src/core/transaction.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/core/transaction.c b/src/core/transaction.c
index d23a45c..805d40a 100644
--- a/src/core/transaction.c
+++ b/src/core/transaction.c
@@ -381,7 +381,7 @@ static int transaction_verify_order_one(Transaction *tr, Job *j, Job *from, unsi
   Found dependency on %s/%s,
   k-unit-id, job_type_to_string(k-type));
 
-if (!delete 
+if (!delete  hashmap_get(tr-jobs, k-unit) 
 !unit_matters_to_anchor(k-unit, k)) {
 /* Ok, we can drop this one, so let's
  * do so. */
-- 
1.7.6.561.g3822

Bug#750683: systemd: oneshot services get started more than once

[Uoti Urpala]

Ed Swierk wrote:
 I found that adding RemainAfterExit=yes to the service file prevents
 this from happening. But nothing in the systemd documentation (nor in
 the code, to the extent I understand it) indicates that this is
 necessary for oneshot services.

This has been a known issue for some services, and has been fixed for at
least some of them upstream by adding RemainAfterExit. Without
RemainAfterExit, when another service is started and depends on the
oneshot service (directly or indirectly, typically by depending on
something like basic.target which depends on the oneshot), systemd will
not consider the oneshot to be already active if it has finished
executing and exited, and it will thus be started again.

Is this really v208? systemd-random-seed.service in v208 DOES have
RemainAfterExit=yes. The version in v204 did trigger this issue, but
it's set up differently and the part which could trigger is named
systemd-random-seed-load.service.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739337: FTBFS with libav10

[Uoti Urpala]

On Sat, 2014-03-08 at 13:11 -0500, Reinhard Tartler wrote:
 On Sat, Mar 1, 2014 at 7:05 AM,  an...@khirnov.net wrote:
 
  Hi,
  the attached patch should fix this bug.
 
 Thanks for providing this patch for the debian mplayer2 packages.
 Unfortunately, it does not apply cleanly against the upstream version
 6c87a98. Would you mind having another look at it?
 
 For reference, the debian package bases on:
 
 commit 6c87a981baa4972fd71c25dfddea017b5a972e89


I pushed some old not-quite-finished changes which replace lavcresample
with lavrresample. While that had some remaining things to fix, it
should be much better than just dropping lavcresample as in the patch.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738585: [insserv] insserv rejects script header

[Uoti Urpala]

Petter Reinholdtsen wrote:
 [Ferdinand Thommes]
  I tried to install the package ddclient, that relies on a sysvinit
  script. The install was interupterd by an error:
  update-rc.d: warning: start and stop actions are no longer supported; 
  falling 
  back to defaults
  insserv: Loop detected during expanding system facilities in the 
  insserv.conf 
  file(s): systemd-udev-trigger systemd-sysctl
  update-rc.d: error: insserv rejected the script header
 
 Can you let us know if such dependency loop exist?  If it does,
 insserv is correct.  If it does not, we need more information to be
 able to figure out why insserv believe such dependency loop exist.

Those services are systemd-only. Why should insserv even try to read
them or handle them in any way? As far as I know, everything needed to
set up systemd services when installing Debian packages is done by tools
other than insserv. Thus any attempts to handle .service files in
insserv during package install operations should be at best useless, and
harmful if they actually have any effect beyond wasting resources (like
here).

Is there some use case where running any systemd integration logic in
insserv during Debian package install would not be a bug to begin with?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system decision-making concerns

[Uoti Urpala]

On Sat, 2014-02-08 at 22:52 +1100, Dmitry Smirnov wrote:
 Also I'd like to notice that shopping for most feature-rich init system 
 might be not our goal after all. OpenRC may be the safest choice that might 
 satisfy majority of developers as it appears to have the least number of 
 objections. I have impression that OpenRC have far less passionate opponents 
 than Systemd.

That there are less passionate opponents is likely only because OpenRC
changes, and achieves, less. Passionate opposition typically occurs
when things change, even for the better. I don't think that is a good
metric to choose a system. I don't believe a majority of developers
would actually believe OpenRC to be a particularly good choice either.
More likely the lesser number of public objections to OpenRC is
explained by two other reasons. First, fewer developers have looked at
it enough to have even a superficial idea they could object to. Second,
it already seems to be a near consensus that OpenRC is not a top choice,
so people don't see a reason to argue against it. Using the criterion of
least objections, there are even less objections to the alternative of
creating and using a new port of launchd. But if it actually looked
plausible that this alternative might win, a lot more people would voice
their objections.


 Finally I'm sure everybody is already getting exhausted by long debates 
 about this topic. At this point it might be tempting to approach on 
 decision, any decision, to put this to end. This is a way to make mistakes 
 of judgement. Unless there is a rush we all need to slow down and perhaps 
 even take a break for several weeks to clear our heads and make a balanced, 
 well thought decision. Taking break may be beneficial for the quality of 
 decision making.

It doesn't look likely to me that delaying the decision would have
beneficial effects, at least not greater than the cost of the delay
itself. If the CTTE could find 5 members willing to vote systemd is the
default init for Jessie (and nothing more) above FD, and do that within
a day, I'm pretty sure that would have a better outcome than any
improvement they would plausibly make after waiting for weeks more.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: Processed: block 726763 with 727708

[Uoti Urpala]

On Tue, 2014-02-04 at 16:53 +, Colin Watson wrote:
 On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote:
  You mean, like installing the systemd-sysv package?
 
 Indeed; but people earlier in this thread have said that this isn't the
 preferred approach, so I was arguing that this *should* be the preferred
 approach in Debian if systemd is selected as the default, rather than
 having helper packages that have to wander around fiddling with the
 configuration of half a dozen different boot loaders to point them to
 the right place.
 
 If the people whose comments I was reading weren't accurately reflecting
 the position of the Debian systemd maintainers, then I apologise for
 misunderstanding.

The main issue is that systemd-sysv conflicts with sysvinit-core, while
the systemd package doesn't. If you do the first install of systemd with
systemd-sysv, this doesn't only change the default, but forces the
removal of the whole sysvinit implementation. This can be compared to a
kernel package install that forces the removal of all previously
installed kernels before you can boot to the new one.

So the systemd-sysv route has the clear technical disadvantage that it
does not support parallel installation of sysvinit and systemd. I think
the ability to easily switch back to sysvinit for troubleshooting if you
encounter issues does have some value. Of course, it would be possible
to switch /sbin/init while both are installed.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: TC resolution revised draft

[Uoti Urpala]

On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
 Sébastien Villemot writes (Bug#727708: TC resolution revised draft):
  P1: DT  UT  DL  UL
  P2: DL  UL  DT  UT
  P3: UT  UL  DL  DT
  P4: UT  UL  DL  DT
 
 This is a nice example which actually demonstrates why these questions
 need to be voted on in a single ballot.
 
 If one votes on T-vs-L before U-vs-D, P3 and P4 don't know how to vote
 on T-vs-L until they know how the vote on U-vs-D will turn out.

I believe that part was just a typo in the message you're replying to,
and it should be UT  UL  DT  DL for P3 and P4. He wouldn't have
written about relative importance of these two questions if he had
intended the answer to one question to change depending on the answer to
the other.

So his example was one where the D/U and L/T choices were independent
for every voter, but combining them into a single ballot produced a
result different from the expected result of voting on each independent
question separately.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: Processed: block 726763 with 727708

[Uoti Urpala]

On Sat, 2014-02-01 at 15:24 -0800, Steve Langasek wrote:
 While I think the Depends: systemd should be dropped (via a split of the
 systemd package), that's not required for fixing the present problem.  That
 can be addressed by having gnome-settings-daemon Depends: systemd,
 systemd-shim | systemd-sysv.
 
 Would the GNOME maintainers be willing to upload such a change?  Or would
 they be ok with me NMUing gnome-settings-daemon for it?

I have the impression that systemd-shim diverts systemd files and you
don't want to have it installed if you're actually booting with systemd.
If this is accurate (I didn't check), then such a dependency change
would not be appropriate - the recommended way to install systemd is
still to NOT use systemd-sysv, while the above dependency would either
force installation of systemd-sysv or would incorrectly install
systemd-shim on systemd-booting systems.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: call for votes on default Linux init system for jessie

[Uoti Urpala]

On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote:
 On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
  On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
   On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
The former. So :

   Where feasible, software should interoperate with non-default init
   systems; maintainers are encouraged to accept technically sound
   patches to enable interoperation, even if it results in degraded
   operation while running under the non-default init.
  
   Maybe I'm dense...
   
   Scenario: Let's say that OpenRC is the new default init and in the
   meanwhile, Gnome has gained a dependency on systemd. A patch to
   support Upstart in Gnome is posted that partially breaks the
   functionality under systemd.
   
   By your wording, maintainers are encouraged to accept the patch.
  
  No. This was precisely the ambiguity which Neil (correctly) pointed out.
  Simply put, patches which reduced existing functionality while running
  under the default init (say, systemd), would not be technically sound.
  
  Instead, maintainers are encouraged to accept the patch even if it
  results in reduced functionality while running under the non-default
  init (say, upstart) in comparison to the default init (say, systemd).
 
 That's a different case.
 
 Zbigniew was talking about a package that has a dependency on a
 *non*default init system.
 
 And for that the first question is whether such a dependency on a 
 *non*default init would be allowed at all.

Not really. What Zbigniew was talking about was whether the above
wording would allow a patch enabling operation with system A to degrade
existing functionality with *another* system B (whether B is actually a
strict dependency does not seem that important). This depends on how
you interpret the non-default init; Don obviously meant this to refer
to the same init as the patch is for.

I think this kind of possible ambiguity could be avoided by phrasing
like even if the patch only implements a degraded mode of operation
under this system, to make it clear that the degrade does not refer
to any functionality that existed _before_ the patch.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: On diversity

[Uoti Urpala]

On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote:
 Uoti Urpala uoti.urp...@pp1.inet.fi writes:
  I think the divergence has gone too far in things like non-Linux ports.
  They have had an overall negative effect on people working on Linux
  within Debian and people creating derivatives.
 
 I have to take exception to this.  There has been a great deal of
 *concern* from people over the past two years that the non-Linux ports
 *might* have a negative effect on Linux in the context of this particular
 discussion.

I consider the effect on the init system decision process so far to
already be an example of actual negative effects. Even if it does not
ultimately lead to an inferior system being chosen for Linux (which
would be a major harm), the portion of discussion that has been about
non-Linux ports has been completely out of proportion compared to their
potential benefit/importance, has made the decision process harder, and
has made it more difficult for anyone else to follow the discussion or
form an informed opinion based on it.

   But, in the meantime, the non-Linux porters have been
 first-class Debian contributors over the years.  They have not
 substantially gotten in the way of Debian's processes, certainly no more
 than any Linux port to a more obscure architecture,

I don't have any numbers, but I would be surprised if that no more
than were true. The kernel and compiler already abstract away most of
hardware differences, and ignoring toolchain issues, I'd expect most of
hardware-specific failures to be things that could be considered general
bugs in the software even on platforms where it works. By comparison,
changes required by kernel differences are generally not positive on
other platforms.

  and they have
 contributed a great many improvements to our software.
 
 For example, I think special thanks should go to the Hurd porters for
 extended, thankless work on removing static buffers from the code in the
 archive.  They were doing so because some of the constants used to size
 those buffers are not portable to the Hurd, but using static buffers to
 store paths and related strings is often incorrect regardless of its
 portability, and can even be a security issue depending on how the code is
 written.  The Hurd porters have provided reasonable patches that can go
 back to upstream and result in objectively more robust software.  I have

Those are probably among the most useful patches, but I think they're
still very minor, and not worth the maintainer work adding distro-
specific patches in Debian (as opposed to letting it become part of
upstream code). Most changes will not be useful on other kernels.

There are also other costs. For example, kFreeBSD issues have prevented
testing migration of packages. Even if systemd is chosen as Linux init,
will everyone packaging daemons or other software interacting with init
for Debian be expected to remember guidelines or even do things
differently because of issues that only matter for non-Linux?

zgrep -i kfreebsd /usr/share/doc/*/changelog.Debian.gz shows over 1000
different matches just on this machine. Of course some of those packages
could be maintained by people who personally really wanted to work on
kFreeBSD regardless of its value, but I doubt the majority is. IMO
justifying that amount of work, and claiming that kFreeBSD has not had a
negative effect, requires showing some concrete benefit.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: On diversity

[Uoti Urpala]

On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote:
 Uoti Urpala wrote:
  Even the upstart proponents do not seem to have significant arguments
  about upstart having better functionality, and there don't seem to be
  all that many people who would have a reasonably informed opinion that
  upstart would be technically better even for just their particular use.
 
 I followed the discussion from the beginning and I'd like to comment on that.
 My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still
 fresh in my memory.

Your comparison does not look very informed, see below.


 1. upstart is a highly configurable init system, while systemd hardcodes
 most of the nuts and bolts in the 32 shipped executables. I spent one days

Your hardcodes is wrong: systemd ships with helper executables and a
default boot setup which uses those, but they're not hardcoded and you
can use something else if you have a reason to.

 So here you go. The advantage of the upstart, is that if you need to tweak the
 boot of your system, you can do it right there, with the text editor, by
 changing the .conf files or the shell scripts. While with the systemd, you 
 have

I strongly disagree that using shell more as an implementation language
would be a good thing. But out of the things in your post I think this
is the closest to a not-factually-incorrect personal preference someone
could have for upstart: some people could prefer working in shell only.
However, this isn't really a comparison of the init systems themselves
so much as a comparison of the default boot setups shipped with the
inits. Even if you decide that almost every program running on your
system should be implemented in shell only, you could still use systemd
to start those programs, though you'd need to change more of the default
configuration if you wanted to avoid starting anything non-shell at
boot.


 2. upstart was not designed or intended to be a SMF (service management
 facility), while systemd was.
 
 I think it is insincere of upstart proponents to even advertise it as such. On

 On the other side of the fence. As I see it, it is only a coincidence that
 systemd is also an init system. To me it was clearly designed from ground up
 as SMF: boot and initialization were only afterthought. That's why the magic
 binaries, because the initialization, an event driven process, simply doesn't
 fit into the systemd everything is a service model.

This is nonsense. Technically, the choice of implementation language for
the binaries/scripts and the event/dependency model are completely
orthogonal. This means your last sentence is completely wrong. It's also
not plausible as a historical fact that boot would have been an
afterthought.


 3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20
 VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed
 flat 0m35s. That was pretty dumbfounding realization, especially after finding

Other people have Fedora booting a lot faster. There are lots of reasons
that could make boot slow other than inherent problems with the init
system, so if you haven't done any analysis of the causes of the
slowness, this does not really tell anything.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: Init system resolution open questions

[Uoti Urpala]

On Thu, 2014-01-16 at 19:12 +, Ian Jackson wrote:
 AFAICT we are all agreed that:

 * Applications which aren't part of the init system must not require a
   particular init to be pid 1.  (So in particular a desktop
   environment may not require a particular pid 1.)

I read the log, and I don't see common agreement with that, at least not
agreement with not allowing it as an effective requirement (as in GNOME
can require interfaces which are only available with systemd as PID 1,
though this might be expressed in ways other than a direct what is PID
1 dependency and it would at least in theory be possible that something
else would provide the interfaces sometime in the future).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: On diversity

[Uoti Urpala]

On Thu, 2014-01-16 at 17:52 +, Ian Jackson wrote:
 * Debian is a forum for cooperation and technical development.

 * Debian, as a piece of software, tries to be all things to all
   people (within reason).

 This flexibility and tolerance for divergence has made Debian an
 extremely attractive target for everyone to work within, work on, and
 derive from.  I think it has been key to the success of the project.

I think the divergence has gone too far in things like non-Linux ports.
They have had an overall negative effect on people working on Linux
within Debian and people creating derivatives.


 I passionately believe that we need to retain this aspect of our
 community, even if that causes us extra work; and even if it causes
 friction with those who would like to make the world nice and simple
 by only supporting certain goals, certain use cases, or certain
 software.
 
 
 Now let me apply that to init systems:

Even if you start from the assumption that diversity is positive, you
can't justify support for any particular system without analyzing costs
and possible alternative goals. Is support for multiple init systems
more important than having a good SELinux policy for each package? Being
able to compile packages with several different compilers? Just fixing
more known bugs in existing packages? You could come up with hundreds of
possible goals that would all have at least some positive effect; just
saying that diversity is good can't allow you to pick some and reject
others.


 If you think that the difference between upstart and systemd, or
 between either of those and systemd, is not important, then perhaps
 you could conclude that it was OK to impose a particular decision on
 all of our users and all of our downstreams.

I think there are important differences: upstart is significantly worse
than systemd in several areas.

 But I think the differences /are/ important.

Do you actually believe that upstart has some nontrivial technical
advantages over systemd, such that it would be a noticeably better
alternative even when considering only some specific use case? IIRC you
did not identify any when saying you preferred upstart earlier, and
mainly based your opinion on the assumption that upstart would be more
likely to get ported.

Even the upstart proponents do not seem to have significant arguments
about upstart having better functionality, and there don't seem to be
all that many people who would have a reasonably informed opinion that
upstart would be technically better even for just their particular use.
To me it looks like the main reason Upstart is still alive at all is
that Ubuntu don't want to pay the cost of the conversion to the better
system and don't want to admit that their alternative was inferior.

If the differences are mainly just it's worse rather than tradeoffs
where each software has clear technical advantages, it's unlikely
diversity would give any significant benefits.


 That means that we need to be the venue where systemd proponents, and
 upstart proponents, and openrc proponents, can make the best system
 they can.

I do not believe it is possible to create such a venue. The result of
the kind of everything must be supported policies you seem to favor
would be a venue where nobody is able to create a system they would be
happy with. Or possibly only sysvinit/openrc proponents would be happy
with, if everything is dumbed down to the level where those systems can
handle it.

 Naturally that will involve some compromises.  That's an unavoidable
 cost of trying to be the best place for everyone to pursue their own
 goals.

The best place for everyone to pursue their own goals is
self-contradictory. You need to choose whose goals matter most; if you
don't, it'll require so many compromises that it's not only not the
best place for most, it outright sucks. Everyone can maintain their own
leaf package, but not everyone can design how boot and service
management should work.

 I think in this case those compromises are absolutely essential.  Not
 just from a technical point of view because of the advantages of one
 system over another.  But also to ensure that Debian continues to be
 the place where serious and dynamic people come to do their stuff.

Debian has been successful in some ways, but I don't think it is the
place where serious and dynamic people come to do their stuff. For
example, none of the newer init systems come from Debian itself; I think
that reflects how hard it is to create the kind of progress I'd
associate with the word dynamic within Debian. Debian mainly
integrates serious new developments long after they've been used
elsewhere.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732008: massive CPU hog as of late

[Uoti Urpala]

Now this broken version is in unstable too. It keeps looping on poll()
to read from socketpair status fd from child; the child closes its side
when exec()ing the actual command to run, so the socket is readable due
to EOF. There seems to no code whatsoever to stop further reading
attempts at EOF (even though the code even logs EOF status)...

The triggering change was probably this:

Use SOCK_STREAM for socketpair, not SOCK_DGRAM so we get consistent
semantics when the other end closes. This should make the conversion
to poll() less problematic.

SOCK_DGRAM probably didn't signal EOF when the other side closes, while
SOCK_STREAM does.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734951: systemd: somehow starts LSB stuff in the wrong order

[Uoti Urpala]

Christoph Anton Mitterer wrote:
 I tried it with log level debug now...
 
 As you can see from there... systemd actually schedules
 iptables-persistend first... but it seems that this get's only executed
 much later (i.e. after fail2ban).

I think the log shows your conclusions were (and are) wrong: this is not
about ordering.

 Jan 14 17:42:53 heisenberg systemd[1]: Got D-Bus request: 
 org.freedesktop.systemd1.Manager.StopUnit() on /org/freedesktop/systemd1
 Jan 14 17:42:53 heisenberg systemd[1]: Trying to enqueue job 
 fail2ban.service/stop/replace
 Jan 14 17:42:53 heisenberg systemd[1]: Job fail2ban.service/start finished, 
 result=canceled

Something on your system is explicitly stopping fail2ban, by calling
systemctl stop fail2ban.service or something which maps to that such
as invoke-rc.d. Under sysvinit stopping the service before it has
actually been started would have no noticeable effect, but under systemd
it cancels the queued start action.

If you don't remember adding such a script yourself, you could grep for
fail2ban under /etc or add a long sleep and log output to fail2ban init
script (which should show the issue under sysvinit too).

BTW there's still the ordering cycle caused by broken setserial.


 What I really fear are systems that heavily depend for their security on
 some service being _fully_ started _before_ some others are run.

In general, if you want to make sure that a service cannot start unless
another has been successfully started, add the Requires or Requisite
field to the unit.


 How can we make sure that these things continue to work safely?
 And I mean this very bug shows, that they don't... fail2ban may not be
 strictly required for other serivces to work... but potentially even the

IMO this is based on wrong assumptions. Nothing needs to be done for
things to continue working at least as safely as they did under sysvinit
(which was not particularly safe); switching to systemd makes things
safer overall. A service such as fail2ban could fail to start under
sysvinit too, and under sysvinit it would be much harder to express that
you don't want certain other services to start in that case.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734951: systemd: somehow starts LSB stuff in the wrong order

[Uoti Urpala]

Christoph Anton Mitterer wrote:
 Now since I switched to systemd, it tries to start fail2ban before 
 iptables-persistent,
 thus the rules are missing and thus starting fail2ban fails.

Is there any reason to believe that there actually is an issue with
wrong order? I don't see any in the given log files, and assume this
is false.

Note that the log contains a warning about an ordering cycle, which
might cause problems (though I don't know why they would be specific to
fail2ban). That cycle is caused by setserial, which has a bad
chkconfig: header in its init script (which Debian-specific tools
probably don't parse, but which more cross-distro systemd code does).
Try removing setserial and see if that has any effect.

My guess is that there is some event which causes fail2ban.service to be
stopped after the job has been queued but before it actually starts, but
the log does not contain enough detail to tell what this might be. Try
booting with systemd.log_level=debug on kernel command line and check
the journalctl -b output from that.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Uoti Urpala]

On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
 Ian Jackson ijack...@chiark.greenend.org.uk writes:
  | 3. At least in jessie, unless a satisfactory compatibility approach is
  |developed and deployed (see paragraph 10), packages must continue
  |to provide sysvinit scripts.  Lack of a sysvinit script (for a
  |daemon which contains integration with at least one other init
  |system) is an RC bug in jessie.
 
 
 As said elsewhere, I think there should be a paragraph about packages
 that depend on a specific init system for reasons other than service
 startup, e.g.

Even restricted to just service startup, I think that's a rather strict
limitation. Suppose an upstream releases a new daemon that is intended
to be used with systemd using socket activation, and as such does not
contain any code to do double-forking or open listening sockets. Would
it be forbidden to package this daemon in Debian unless the maintainers
are willing to add forking, other startup and socket code as Debian-
specific patches? If it would, how much functionality would the
maintainers need to add for a minimal accepted version - for example
would they need to add new options to specify which port to listen on,
or is opening a hard-coded default port enough for the added socket
code? Adding support for everything that systemd socket activation
automatically supports would not be realistic.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Uoti Urpala]

On Fri, 2014-01-03 at 16:40 -0800, Russ Allbery wrote:
 Ian Jackson ijack...@chiark.greenend.org.uk writes:
  I've written a version of Niklaus's rule about dependencies:
 
 Likewise, packages must not Depend on or Recommend (directly or
 indirectly) a specific init(1).  Violations of this are also an RC
 bug in jessie.
 
  And:
 
 Theses rules do not apply to machinery which itself forms part of
 the implementation of one or more init systems.
 
  That seems to be the clearest way to put the matter.
 
 This seems fine to me, at least for right now.  I'm doing a bit of
 additional research right now to be sure that I understand the
 implications of this and may end up asking for any problems that anyone is
 aware of with this approach, just to be sure we're not missing something.

Packages could functionally depend on systemd - one example would be
systemd-ui (though it seems to be mostly abandoned, and comes from the
same source; it's not really part of the machinery forming the
implementation though). OTOH this doesn't have to be a package-level
dependency; probably programs from such packages could just fail with an
error if you try to run them after booting with sysvinit, and this would
probably be the best option as switching init as a side effect of
installing such a package would be questionable.

One case to consider is what should happen with GNOME if it requires
interfaces that nobody has implemented for sysvinit. Is it OK to show a
screen saying you need to boot with systemd to use GNOME and expect
GNOME users to manually install systemd? Or should there be more
user-friendly automation for installing it? Or would you expect to find
someone to create GNOME packages without such dependencies?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Uoti Urpala]

On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
 Clint Adams cl...@debian.org writes:
  On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
  or alternatively   
  
  4. Packages may, however, depend on a specific init system (which may
 not be the default init) for features that are not related to daemon
 startup. Such packages will only be installable on systems running a
 non-default init, but are permitted in the archive.
 
  As loath as I am to participate in this discussion, I have to ask
  if your intent is to suddenly outlaw all the packages which depend
  on runit.
 
 Are you asking me personally? No, that's not my intent. I merely think
 that a CTTE solution should spell out precisely to what extent a package
 must be compatible with the default init (i.e., if it must be fully
 working with the default init, or if it only has to provide daemon
 startup/supervision/shutdown for the default init). This is why I
 explicitly listed two conflicting, alternative wordings.

There are two different kinds of dependencies: dependencies expressed in
package metadata, and functional dependencies (as in whether the package
does anything useful with another init). Your earlier wording sounds
like it was talking about the former (installable) and Ian's proposal
definitely was (explicitly mentioning package fields), but the fully
working you use now sounds like it's about the latter.

As the systemd-ui example shows, there could be packages which in no way
can be reasonably expected to work with another init. So I think a
blanket ban on functional dependencies would be wrong (which you also
seem to be saying). I don't see such obvious problems with banning
package-level dependencies (requiring the packages to just fail at
runtime instead), and such dependencies could cause problems such a
unexpectedly switching init as a side effect of installing/upgrading an
unrelated package or forcing uninstall of packages if you even
temporarily try booting with another init.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system thoughts

[Uoti Urpala]

On Thu, 2014-01-02 at 12:31 +, Colin Watson wrote:
 On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
  You can simply not install any of these additional services if you don't
  want them. This is completely trivial to do.
 
 It is indeed technically trivial, but I invite you to review your own

 It's also not, in general, trivial to do something if it involves a
 massive argument, even if the patch would end up being a one-liner.
 Social costs are costs too.

So your position is essentially systemd may be a technically better
init, but it would allow maintainers to choose services I do not like,
so I'll try to pre-empt that by choosing upstart? The obvious
alternative, and IMO correct choice, would be to decide the init on
technical merits and handle choice of services separately (if needed).


  the _best_ way to handle the situation: B thinks that gaining
  compatibility with other distributions is a bigger plus, and that

 Perhaps this is the fundamental disagreement.  I do not necessarily
 consider compatibility as an end in itself.  Where Debian is already

Maybe that's a basic disagreement in discussions concerning specific
services, but certainly not for init system choice. What I view as the
basic reasons I find your given rationale for choosing upstart
completely unsatisfactory:

* I don't think it's appropriate to use the init decision to push your
views on the service choice question, when the latter could be decided
independently regardless.
* Your initial posting of the rationale represented it as a technical
issue. Now you say it's a social one (pre-empting future arguments), but
you still haven't given any real analysis to support your view. No
mention of the obvious alternatives, no estimation of how common service
disagreements would be, almost nothing at all. Basically you've only
mentioned two discussions you didn't like; there's a gap from that to
and therefore this should be resolved by choosing a different init.

I also do not consider it plausible that disagreements over which
services to use could be so bad that they would override all other
concerns in choosing an init system.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system thoughts

[Uoti Urpala]

On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
 On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
  Colin Watson cjwat...@debian.org writes:
   Basically, systemd would be more compelling to me if it tried to do
   less.  I don't expect to persuade systemd advocates of this, as I think
   it amounts to different basic views of the world, but the basic approach
   here is probably the single biggest factor influencing my position.
  
  On the other hand even when using upstart as an init replacement, we'll
  continue to use large chunks of systemd (logind, other dbus
  services). I personally think less is more would only be a convincing
  argument if we actually would not need the aditional features.

I think this counterargument, while valid, misses the major flaw in the
would be more compelling if it tried to do less claim:

You can simply not install any of these additional services if you don't
want them. This is completely trivial to do. Using systemd as init in no
way requires using them. Thus their existence cannot cause any technical
problems for the use of systemd in Debian (beyond possibly needing to do
the trivial disabling).

If some other components that Debian does want to use start to depend on
those services, such that disabling them is not easy, then this problem
would exist regardless of the chosen init, and is again not a reason for
favor upstart.

 I'm referring to features that I don't think we'll need, not to logind
 et al.  So far I feel that the debates about those seem to be a bit
 circular and go something like this:
 
   A: This feature of systemd conflicts with something else; I'd rather
  we didn't use it.
   B: You can disable that, you know.
   A: OK, let's disable it.
   B: But you shouldn't disable it because that would make Debian systemd
  less compatible with systemd on other distributions.
   A: ...

Here B first correctly points out that the feature can be disabled if
desired, and thus the situation cannot be worse than with upstart - you
can do at least as well with systemd as you could with upstart. Then you
(A) have a disagreement with B about whether disabling the feature is
the _best_ way to handle the situation: B thinks that gaining
compatibility with other distributions is a bigger plus, and that
changing to the systemd way is an actual win over current situation,
rather than just neutral like the the upstart and disabling with systemd
cases.

There is no technical reason to prefer upstart here. Given your
preferences, systemd can do at least as well (after disabling the
service). Given B's preferences, systemd can do better (after enabling
the service). The only benefit that choosing upstart would give you here
is that it'd let you automatically win your argument with B: we already
chose upstart, so enabling the systemd service is not an available
choice any more.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system other points, and conclusion

[Uoti Urpala]

On Mon, 2013-12-30 at 18:58 +, Ian Jackson wrote:
 Also, I get the impression me that the integration of much of this
 functionality into the systemd source package has been done for
 political rather than technical reasons.  Indeed to the extent that
 there is a problematically tight technical coupling between these
 components, I find it difficult to avoid doubting the good faith of
 the people making those decisions.  At the very least, I worry that
 the systemd project as a whole is far too willing to impose decisions
 of all kinds on its downstreams.

Your own expressed preference for upstart appeared to be very much
driven by political rather than technical considerations. Using the same
terminology you do, would it not be entirely fair to say that your
decision to support upstart was made in bad faith?


  3.3. Project Momentum
 
 I don't see the outlook here the same way as you do.
 
 Furthermore, I am much less worried about Debian going it alone
 (although, of course, it's not alone) than you seem to be.  We have
 historically been entirely unafraid to do our own better things, even
 if it is more work and takes us longer.
 
 I felt that way when Debian was very much a minority interest.  That's
 far from the case nowadays; I've heard it asserted that Debian-based
 distros now account for a majority of traditional distro installs.  I
 guess numbers on that are all speculative but it is certainly true
 that we have a thriving ecosystem of our own.
 
 We have got where we are by doing things the way we think is best, not
 by simply following the herd.

Who would actually do the work? Getting the amount of development there
is for systemd is not easy. Do you really believe that a Debian decision
in favor of upstart would create that many interested developers working
on it, when that has not happened while it's been used in Ubuntu?

Working on things that they believe to be better than existing ones does
motivate people. But how many Debian developers actually share your
extreme views about portability to the extent that they would be happy
to work on another system motivated by that, when systemd already works
better on Linux? I doubt that group is large enough to create
significant momentum.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system thoughts

[Uoti Urpala]

On Tue, 2013-12-31 at 02:55 +, Colin Watson wrote:
 My main concerns with systemd relate to its broad scope regarding units
 it provides for system initialisation tasks currently performed by other
 packages, and the potential for that to interfere with past and future
 work elsewhere in Debian.  I can understand why the systemd authors felt

 The two examples which I've run across so far, both ones I was inclined
 to look at since I'm familiar with the territories, are:
 
   #716812 (binfmt-support)

   #608457 (console-setup)

 Basically, systemd would be more compelling to me if it tried to do
 less.  I don't expect to persuade systemd advocates of this, as I think
 it amounts to different basic views of the world, but the basic approach
 here is probably the single biggest factor influencing my position.

I think this is absolutely ridiculous as a rationale for choosing
upstart. If you have done any investigation, you should know that it's
trivial to disable any of those components if Debian decides it's better
off without them. Yet you really seriously present their existence as
the biggest factor influencing your position? In what kind of scenario
could their existence possibly cause noticeable problems for Debian
systemd use?

I can imagine some kind of extrapolated arguments about project scope
issues that would not be completely laughable, but you haven't really
presented any of those. As is, what you're saying just does not form an
argument that could be taken seriously at all.


 The criticisms of Upstart's event model in the systemd position
 statement simply do not make sense to me.  Events model how things
 actually happen in reality; dependencies are artificial constructions on
 top of them, and making them work requires the plethora of different
 directives in systemd (e.g. Wants, which is sort of a non-depending
 dependency) to avoid blocking the boot process on a single failing
 service.

Dependencies are the natural way to express what people know about the
system and what they need. Events are the internal implementation
details of what the machine does to make it happen.

I want task X started, and it needs task Y is what people express.
Start Y, and when Y is ready, start X are the compiled
implementation instructions to achieve the higher-level goal.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: upstart and upgrading from sysvinit scripts

[Uoti Urpala]

On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote:
 However, I think this gets to the heart of why upstart upstream has avoided
 ever recommending the use of socket-based activation.  There are some fairly
 fundamental problems that basically halted development of socket-based
 activation in upstart (beyond merging of Scott's original implementation,
 which is rudimentary, as has been noted), and a look at systemd usage on
 Fedora led me to believe that systemd had not overcome these problems at
 all.

As far as I can see, what you're saying here is 100% based on
misconceptions only, and has no connection to any real issues
whatsoever.


 If I'm not mistaken (no references to hand - sorry), systemd upstream has
 claimed in the course of discussions on debian-devel that lazy activation is
 not the purpose of socket-based activation, and that using socket-based
 activation does not require you to pay the service startup penalty at the
 time of first connection.

Yes, this is true. If you have a daemon configured to always start, and
then add a .socket unit for socket activation, this does not in any way
STOP the daemon from starting!

Any mechanism that directly starts a .service will continue to do so
regardless of the existence of a .socket. What a .socket adds is that
you can have the socket active while the service is inactive, and in
this state an incoming connection to the active socket will trigger
start of the service. Other services which make requests through the
socket can depend on the .socket only (as opposed to directly depending
on the .service) to allow this state.


 On Fedora 20, after enabling the sshd and rsync service+socket units (both
 installed but disabled by default on Fedora per their policies on running
 services out-of-the-box) and rebooting, I find that both port 22 and port
 873 are bound by pid 1.  Only upon connecting to the socket does systemd
 actually spawn the server (in the case of sshd, it spawns it as 'sshd
 -i', so has to start up the server anew on each connection; in the case of
 rsyncd, the .service definition is completely incompatible with socket-based
 activation and any attempt to connect results in the rsyncd.socket unit
 landing in a 'failed' state).

Assuming this is an accurate description, it sounds like an intentional
decision for ssh and a bug in rsyncd (as Josselin already said).


 If what one is trying to accomplish here is to provide a replacement for
 inetd, then this is perfectly sufficient.  But if one is trying to use
 socket-based activation for the claimed purpose of ensuring service startup
 ordering without the need to declare explicit dependencies, then you must
 accept the penalty of lazy activation - which is almost never acceptable in
 a server context (where the purpose of the machine is to run the services
 that you have configured, and they should therefore not be started lazily),
 and suboptimal even in a client context (since not starting services that
 are on the critical path for boot until the client requests them will
 potentially lead to a significant boot-time slowdown, if all the services
 are doing this).

As above, your belief that systemd would force lazy activation has no
basis in reality that I can see.


 As far as I've been able to tell, the only solutions that would allow
 non-lazy socket-based-activation of services in systemd all introduce
 significant boot-time races, whereby it is no longer assured that systemd
 will bind to the socket (and passing the socket information via the
 environemnt) before starting the service.  Indeed, when I looked at this
 problem on an earlier version of Fedora, I found what I believe to be a
 latent security problem in the cups units, because it was nondeterministic
 whether the service would start with sockets passed from systemd, or a
 different set of sockets as defined in the cups config!
 
 When I mentioned this to Lennart at DebConf this year, his response was that
 cups was special.  Well, after further investigation, I don't think it's
 true that cups is special.  I think systemd socket-based activation is snake
 oil, that does not do what was promised without introducing hidden
 trade-offs which no one has been forced to acknowledge because too few
 developers are making use of this feature today to expose the integration
 problems.

If foo.service has Requires=foo.socket, then on general principles it
would sound like a very obvious bug if the service ever starts without
foo.socket active. I'd like to hear of some evidence of such a bug
before taking it seriously. And even if such a bug somehow existed,
fixing it should be a straightforward bugfix.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: upstart and upgrading from sysvinit scripts

[Uoti Urpala]

On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote:
 It's quite possible that I am doing something wrong, but I don't think this
 is it.  Each of the .service units in question already had
 'WantedBy=multi-user.target', and each of the .socket units had
 'WantedBy=sockets.target'; on Fedora these were all disabled by default (to
 avoid any open ports by default), but upon enabling both the service and
 socket units, I get the behavior described.
 
 I was seeing the same behavior with the lbcd package in Debian, but it turns
 out this is due to the 'mutli-user' typo in lbcd.service.  Once I've fixed
 this (and created the proper 'enabled' symlink), I do see the lbcd process
 being started at boot.  So that much does seem to work as described, on
 Debian.  I'm not sure what to make of the Fedora setup, then, because other
 services that are linked into /etc/systemd/system/multi-user.target.wants do
 start up at boot, but neither sshd nor rsyncd is started when the .socket is
 enabled.

Enabling .socket is only supposed to start the socket, and the daemon
only if a connection arrives. If you want the daemon to start
unconditionally, you should enable the .service, not just the .socket.

   In that case, my concern is a different one - how can anyone claim
 that systemd's socket activation is ready for prime time if even a service
 as important as sshd hasn't been debugged in Fedora, one of the flagship
 adopters of systemd?

What makes you think it is buggy? So far I have seen no clear indication
of any bugs, only use of per-connection daemon instances which you
didn't like. And even if there were bugs, it is fairly easy to imagine
how an ssh maintainer could break it in one release independent of any
systemd issues.


   (BTW, there's also both an sshd.service and an
 sshd@.service here, adding to the confusion.  I've attached all of the sshd
 units in case you want to look at them.)

Those look like there are alternative units for a persistent daemon and
a per-connection daemon used with an Accept=true socket. The
sshd.service one is persistent and does not use socket activation. The
sshd@.service is a per-connection one instantiated for each connection
to sshd.socket. You're probably supposed to enable either sshd.socket
(for per-connection daemons) or sshd.service (for a persistent daemon).


 This still leaves the concern I have about start-time races.  According to
 systemd.unit(5), using 'Requires=', as Uoti suggested to Russ, does *not*
 guarantee ordering:

but as I said at the end of
https://lists.debian.org/debian-ctte/2013/12/msg00206.html
there's an automatic Before: dependency created from sockets to
identically named services. So it shouldn't be necessary to give it
explicitly.

 In my earlier investigations (which were on Fedora 17, IIRC), I definitely
 found races where a service configured with a corresponding .socket would
 *sometimes* start at boot time before the socket is bound, causing it to
 fall back to its own config file and binding to its own sockets... which

I'm not sure if some parts of the behavior have differed before. At
least the code setting the default dependencies has not stayed exactly
the same; I didn't try to find out whether the behavior has actually
changed.

Even with current systemd you could probably produce such behavior with
suitable configuration - at least if you do NOT add a Requires= and
create an early boot service that can run before sockets.target.

 diligently keeping the two implementations in sync.  Since
 LISTEN_FDS/LISTEN_PID is the defined API for systemd passing the socket
 information to the service, for systemd to ever fail to pass this socket
 information, resulting in the service deciding that it's not *actually*
 running under systemd and should fall back to a different mode, is
 potentially a very serious problem.

If you want to make sure your service never tries to start without
socket activation, it should have Requires=foo.socket; none of the
default relations are strong enough to strictly prohibit starting
without a socket. I think at least the case where creating the socket
fails and admin manually says systemctl start foo.service would always
start the service without a socket otherwise.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd vs. binfmt-support

[Uoti Urpala]

On Sun, 2013-12-29 at 14:02 +, Colin Watson wrote:
 I was referring more to Tollef's position, really.  Debian systemd
 maintenance ought to take into account matters of Debian integration,
 which includes whether it fits well into best-of-breed Debian practice.
 
 If it's easy enough to override, then given that we have a better
 implementation in Debian then we should simply continue to use it.

I think Tollef's post was a reasonable first reaction at least -
minimizing Debian-specific code (even if it's used somewhere else,
Tollef was apparently not aware of that).


  I think this has been proven false by experience - systemd has innovated
  a lot in things where smaller projects were stagnant. And there's a
  fairly clear reason why this would be so: something like binfmt-support
  is too small a unit for independent development, both to design
  independently and to sell to every user individually.
 
 It's simply not true that it's too small a unit for independent
 development (what on earth gives you the authority to pronounce on this,

  Binfmt support is not that complex a task in itself. In practice, a lot
  of the usability will depend on consistency with other system parts.
  Designing APIs for it only is too narrow a view; you need to consider
  other tools, and if you can do better, then it's quite likely you should
  change the other tools too (things like adding udev rules etc).
 
 However, I've been thinking about this for rather a long time, and I'm
 actually quite familiar with the design issues.  binfmt-support is
 specifically designed to be suitable for distributions (not just Debian)
 shipping binfmt integration; in particular I have put much more effort
 than systemd has into how it fits into packaging.

I'm not saying that it would be too small to do anything useful with.
But is it really different enough from other cases of setting kernel
parameters to justify a completely unique approach? My gut feeling is
that either binfmt-support should be closer to other tools, or the other
tools should be changed to take into account lessons from
binfmt-support.


  Convincing every distro builder out there individually that your binfmt
  support code is best wastes effort, both yours and theirs. It's more
  efficient to have systemd upstream decide what is a reasonable default
  implementation, and then have only people with specific needs or
  opinions change it.
 
 This sounds very much like an argument from authority, and I'm afraid I
 don't subscribe to it.  I don't consider my effort wasted, and I don't

It's not an argument from authority - I'm not saying that
implementation is best, because systemd upstream chose it; in fact I
was not trying to argue the benefits of any implementation. What I meant
was that I think it's beneficial to have default choices, and that
choices made by systemd upstream are more likely to be correct than the
collective average of people who would make such choices individually
(plus everyone making individual choices would use more effort).
Accepting this as true does not require accepting systemd upstream as an
authority whose opinion would automatically decide an issue.

It's also beneficial to use shared standard methods as much as possible,
and systemd upstream is probably about as close as you'll get to a
shared standard in an actively developing area in practice (I certainly
don't believe that any committee could do better). I think avoiding
unnecessary deviations from the shared code has benefits similar to
doing things according to POSIX when possible; that does not mean that I
would consider POSIX authors to be authorities who could dictate how
things should be done.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd vs. binfmt-support

[Uoti Urpala]

On Thu, 2013-12-26 at 21:42 +, Colin Watson wrote:
 On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
  In this particular case, as you write, I hadn't really given it any
  consideration before, but what I think would make sense is to extend
  systemd to support the same interface as binfmt-support and then people
  who don't use systemd can use binfmt-support and those who use systemd
  (on Debian or elsewhere) can use systemd-binfmt.  I'm guessing the

 afraid it leaves me rather cold, though.
 
 The first reason is, I suppose, rather selfish: I've been working on
 this on and off for fourteen years and it seems a bit rude for systemd
 to turn up and declare that it's now the standard on the strength of an
 underpowered implementation, without even mentioning it to me (I'll
 accept that this is irrational since the systemd authors probably
 weren't aware of the prior art, but it's certainly my gut reaction).  I

I don't think systemd authors have made any declarations about binfmt in
particular. The only thing they've actually done is add a very simple
implementation (src/binfmt/binfmt.c, less than 200 lines of code, much
of it argument parsing). I consider having a basic implementation to be
a useful batteries included feature: systemd supports lots of
different setups from embedded to desktop, and it's useful to have at
least a basic implementation ready when building a system. It's easy
enough to override if you want something different. Thus I consider any
opinions saying systemd should not include a tool for setting binfmt, or
that adding it was somehow objectionable behavior, to be wrong. Whether
it would be preferable for the tool to support more complex
functionality is another question.


 suppose I'm concerned what the incentive is for people to innovate on
 this sort of thing in the future (and binfmt-support absolutely was
 innovative in terms of making the packaging of the underlying kernel
 technology trivially accessible) if they can be steamrollered at any
 time; in the long term I have more faith in the flexibility of many
 small projects than one big one.

I think this has been proven false by experience - systemd has innovated
a lot in things where smaller projects were stagnant. And there's a
fairly clear reason why this would be so: something like binfmt-support
is too small a unit for independent development, both to design
independently and to sell to every user individually.

Binfmt support is not that complex a task in itself. In practice, a lot
of the usability will depend on consistency with other system parts.
Designing APIs for it only is too narrow a view; you need to consider
other tools, and if you can do better, then it's quite likely you should
change the other tools too (things like adding udev rules etc).

Convincing every distro builder out there individually that your binfmt
support code is best wastes effort, both yours and theirs. It's more
efficient to have systemd upstream decide what is a reasonable default
implementation, and then have only people with specific needs or
opinions change it.


 The second is that it seems like makework for the sake of aggrandising
 systemd.  systemd isn't bringing anything new to the table here; right
 now it's just exposing the raw underlying kernel interface in the form
 that's existed since 1997, and in a way that (AIUI) only works properly
 at boot time rather than doing sensible things when packages are
 installed or removed.  Of course you can put all the pieces together,
 but that was the point of binfmt-support.  This is straight
 wheel-reinvention and it seems like a total waste of everyone's time.

As above, I certainly disagree about including binfmt code being a waste
of time; having to look at a separate project to get any support at all
for something so simple would be a waste of time. Most likely supporting
more features from binfmt-support would be an improvement, but that
doesn't make having the current code a negative thing.

I'm not sure whether including exact binfmt-support functionality would
have been a reasonable option for systemd (GPL vs LGPL probably
precludes code copy). At least the API would not be very consistent with
other tools.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: upstart and upgrading from sysvinit scripts

[Uoti Urpala]

On Sat, 2013-12-28 at 17:24 -0800, Russ Allbery wrote:
 * systemd synchronization support added via sd_notify.
 * systemd socket activation support.

Does sd_notify() actually give any positive effect compared to just
using type=simple, given that you already have socket activation? The
UDP socket should buffer packets until the daemon reads them. Explicit
notify does have the negative effect that depending services can not be
started in parallel.

Or do you want to support running it as a systemd service but without
using socket activation (would seem rather pointless)? You ship
a .socket file by default, so it doesn't explain the use of type=notify
in the provided file at least.

I think the .service file should have a Requires= on the socket to make
the service fail in case the socket could not be opened (probably
doesn't matter otherwise). There's a typo mutli-user.target.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: upstart and upgrading from sysvinit scripts

[Uoti Urpala]

On Sat, 2013-12-28 at 21:29 -0800, Russ Allbery wrote:
 Uoti Urpala uoti.urp...@pp1.inet.fi writes:
  Does sd_notify() actually give any positive effect compared to just
  using type=simple, given that you already have socket activation? The
  UDP socket should buffer packets until the daemon reads them. Explicit
  notify does have the negative effect that depending services can not be
  started in parallel.
 
  Or do you want to support running it as a systemd service but without
  using socket activation (would seem rather pointless)? You ship a
  .socket file by default, so it doesn't explain the use of type=notify in
  the provided file at least.
 
 The thought was the latter, combined with the intent to fully explore the
 whole systemd interface.  Also, there are situations where I believe that
 systemd will start the service without using socket activation even when
 socket activation is configured.  For example, if I disable both lbcd and
 lbcd.socket, and then manually start lbcd.service, lbcd.socket is not
 started, which I suspect means that socket activation is not used.

Adding the mentioned Requires=lbcd.socket line should ensure that the
service is never started without the socket running. I'm quite sure that
daemons intended to run under systemd should have no need to implement
any socket-opening code themselves (unless they do something special
like opening a socket in the middle of operation); anything which would
contradict that should be a misunderstanding or a bug.


  I think the .service file should have a Requires= on the socket to make
  the service fail in case the socket could not be opened (probably
  doesn't matter otherwise).
 
 I think I misunderstood something I read in systemd.service(5) and thought
 it said not to do that, but it was talking about something different.
 That would probably also get rid of the case that I mentioned above.
 However, daemon(7) does say:
 
 It is recommended to place a WantedBy=sockets.target directive in the
 [Install] section, to automatically add such a dependency on
 installation of a socket unit.  Unless DefaultDependencies=no is set
 the necessary ordering dependencies are implicitly created for all
 socket units.  For more information about sockets.target see
 systemd.special(7).  It is not necessary or recommended to place any
 additional dependencies on socket units (for example from
 multi-user.target or suchlike) when one is installed in
 sockets.target.
 
 I'm not entirely sure whether any additional dependencies on socket
 units is meant to imply that lbcd.service should not depend on
 lbcd.socket, or if that's just talking about the [Install] section of the
 socket file itself.

That wording really is unclear. I think it must mean the latter to make
sense. Looking at the code, it seems that sockets automatically get a
Before: dependency on identically named services, and the rarer
explicit Sockets: in a .service file also adds Wants:. So ordering
should work by default, but a Requires: dependency must be explicit.
I couldn't find where the automatic dependencies would be documented.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732940: Breaks ssh: OpenSSL version mismatch. Built against 1000105f, you have 10001060

[Uoti Urpala]

Josh Triplett wrote:
 I upgraded OpenSSL and OpenSSH stopped working.  Since the SONAME didn't
 change, kinda by definition this seems like a bug in OpenSSL, not
 OpenSSH.

That by definition only holds if you assume all applications are
perfect software with no bugs whatsoever, and use libraries strictly
according to their formal API only (however badly that API is often
defined in practice). In reality it's quite common for perfectly
ABI-compatible updates to break other software (or perhaps that should
be phrased make the brokenness of other software have visible
effects).

In this case the breakage seems to be caused by an explicit version
check in OpenSSH. There's this code in entropy.c:

 * OpenSSL version numbers: MNNFFPPS: major minor fix patch status
  * We match major, minor, fix and status (not patch) for 1.0.0.
  * After that, we acceptable compatible fix versions (so we
  * allow 1.0.1 to work with 1.0.0). Going backwards is only allowed
  * within a patch series.
  */
 u_long version_mask = SSLeay() = 0x100f ?  ~0x0L : ~0xff0L;
 if (((SSLeay() ^ OPENSSL_VERSION_NUMBER)  version_mask) ||
 (SSLeay()  12)  (OPENSSL_VERSION_NUMBER  12))
 fatal(OpenSSL version mismatch. Built against %lx, you 
 have %lx, (u_long)OPENSSL_VERSION_NUMBER, SSLeay());

For some weird reason the last byte status is not masked out of the
comparison. This libssl update changed the version from 1.0.1e release
to 1.0.1f beta0, and the release-beta0 (f to 0) change in last byte
triggers the check.

The OpenSSH Debian package has this changelog entry:
openssh (1:5.9p1-4) unstable; urgency=low

  * Disable OpenSSL version check again, as its SONAME is sufficient
nowadays (closes: #664383).

but apparently it was either not really disabled or was enabled again
for some reason; I see no changelog entry for that.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Uoti Urpala]

On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote:
 Tollef Fog Heen tfh...@err.no writes:
  sd-daemon.c is also intentionally designed to not have dependencies on
  the rest of the systemd source and to be portable to non-linux
  architectures too (but basically just stubs then) just so people can put
  the file in their source and not have to fiddle with checking for
  libraries and such if they find that tedious.
 
 I agree with Ian's dislike of this approach.  We try to avoid embedded
 code copies, and I'm not sure why this would be an exception.  Yes, the
 code is fairly simple and hopefully doesn't contain (for example) security
 vulnerabilities, but it's possible to find bugs in just about anything.
 Updating numerous copies of that code is not appealing.

I don't see why that should be considered a particularly significant
downside though. Copies are usually worse than shared code, but not
really worse than everything having a custom implementation. At least
implementing sd_notify() support with a code copy should be considered a
significant improvement over a daemon that always runs custom
double-forking code.

BTW it's worth noting that in the typical daemon case where readiness
means the listening socket is ready to accept requests, the right way to
convert the daemon to a new API is to use socket activation, which
removes the need for separate start-up completion notification. Thus the
need to use sd_notify() for this purpose should be the exception rather
than the rule. This means that daemons which would use libsystemd-daemon
for startup notification and nothing else (and would thus be potential
candidates to abuse SIGSTOP) should be rare.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd jessie - jessie+1 upgrade problems

[Uoti Urpala]

On Fri, 2013-12-20 at 07:53 -0800, Steve Langasek wrote:
 On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
  Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
   ecosystem.  This needs to be resolved before logind v205 can reasonably be
   adopted, because it's broken by design and needs to be worked around.
 
  The new logind is not “broken by design”. Using the cgroups tree is the
  most correct and secure way to identify which processes are permitted to
  access specific devices or services. You might disagree with the idea of
  a single cgroups manager or prefer a less secure mechanism in order to
  handle corner cases (that have yet to be described), but that doesn’t
  make the design less correct.
 
 The design which claims this role for systemd-as-pid-1, and which does not
 adequately address use cases of other existing cgroups consumers in the
 ecosystem (lmctfy, lxc) is broken by design.
 
 Having a single cgroup writer in userspace is fine.  Coupling it to systemd
 in this manner is not.

You're still not saying what would actually be broken about this. On one
hand you say that you don't disagree with single cgroup writer[1], but
on the other hand you talk about existing cgroups consumers like lxc.
You certainly can't expect lxc to be the only cgroup user on the system.
Thus the old lxc would not work in the new model in any case, and has to
be modified to use other APIs instead. Given that, what's wrong with
systemd being the one to provide those APIs? If you want to criticize
some specifics of the APIs it provides at the moment, that's mostly
irrelevant to the general design decision in logind to depend on
systemd.

The arguments for using systemd as the cgroup manager given at
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
are much better than any you've given against it.


[1] The plan still seems to be to eventually deprecate direct kernel
tree read access too, not only write access; Josselin's cgroups
manager is more accurate.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732584: Want documentation for cgroup persistence implications

[Uoti Urpala]

This setting was removed in systemd v205 as a part of the control group
rework. Improving documentation of what it did in v204 is likely not
worth the effort.

My guess is that it did not have effects like result in all descendants
of the main service daemon to be killed, but only mattered if you did
(now deprecated) direct access to the cgroup tree.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd jessie - jessie+1 upgrade problems

[Uoti Urpala]

On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
 On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
  I'm confused, when I hear you say that this risk is unique to the
  systemd option and not shared by other options.  I would understand that
  statement if we thought we could avoid systemd entirely.  It sounds like
  we may be able to avoid systemd as pid 1 but systemd is very likely to
  play an important role in the Debian desktop storpy even if we adopt
  another pid 1.

 Thanks for the explanation, and apologies to Josselin and Russ that
 I completely misread their point regarding udev:
 
 I was misreading that as referring to the headaches udev had caused in 
 the past for Debian upgrades, not that the systemd udev might be the 
 cause of future upgrade headaches.
 
 But I do not buy this We already switched to systemd as upstream of 
 udev, so we also have swallow the rest of it:
 
 When not using systemd as pid 1, that risk would be confined to the 
 parts of systemd Debian would be using (currently only udev).

I think you still misread the argument: IMO it's clear that it
considered more than udev as likely to be required, even if udev is the
only one in current Debian. So if you disagree, you should at least
address the question of why you believe udev will stay the only one.


  At some level, we also need to be community players.  Since upgrade
  stability is important to us, we should advocate for it in open-source
  projects that we depend on.  On the flip side, if enough of the rest of
  the community after having carefully considered our arguments decides
  that our desire for stability is too expensive, perhaps we need to
  reconsider our position.  I hope we don't need to do that, but sometimes
  when enough of the rest of the world disagrees with you, you need to
  move on.


 systemd upstream only reluctantly supports the option to have a separate
 /usr (as currently mandated by Debian policy), and I would not be 
 surprised if that gets dropped any time if it becomes an obstacle
 for development of any part of systemd.

You're mixing two separate issues (or at least not clearly indicating
which one you're talking about). Systemd fully supports having a
separate /usr partition, and that is in no way deprecated AFAIK. What
has changed compared to old practice is that /usr needs to be mounted
together with root (requiring initramfs if you have a separate /usr;
where you had mount / before you now have mount / and /usr). Whether
the old way of later /usr mounting could keep working with any other
init either is questionable.

Then there is the move of binaries from /bin to /usr/bin, which does
have some backwards compatibility logic for different paths in systemd.
This is not directly connected to /usr being a separate partition or not
(but having everything in /usr/bin obviously requires /usr mounted
early). Does someone in Debian seriously oppose this move as a long term
goal?


 And now you bring up the point that Debian should reconsider the 
 lenght of it's release cycles if systemd upstream decides to not
 support upgrades between distribution releases as far apart as Debian's. [3]

I don't think anyone said that. Nobody talked about long release cycles
not being supported, and nobody said that upgrades would not be
supported either. However, supporting upgrade from the old release
does not equal things like being able to run the new userland on the 3+
year old kernel from the previous release.

A development model where you have to wait 3+ years before you can have
hard dependencies on the new features you write now is obviously very
problematic. IMO such restraints should never be taken for granted;
upgrade schemes should always be planned to at least make it possible to
have newer dependencies without too much trouble.

In the kdbus case, systemd upstream already mentioned the possibility of
shipping kdbus as a new module for older kernels. More generally, you
can have solutions like applying some upgrades at boot rather than
trying to switch parts from under a fully live system. This does still
count as fully supporting upgrades.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd jessie - jessie+1 upgrade problems

[Uoti Urpala]

On Wed, 2013-12-18 at 16:27 +0100, Josselin Mouette wrote:
 Such stances are untenable whenever the kernel is concerned. We need to
 be able to use a kernel from the previous stable distribution, or from
 the next one, to support proper chroots. This part of the support for
 upgrades is needed for our own infrastructure as well as for many of our
 users.
 
 It is possible to handle the situation with udev or with systemd,
 because they do not make sense in a chroot environment, but they are the
 exception, not the rule. And unless things go hectic, we *will* be able
 to treat them normally and provide an upgrade path that doesn’t force
 users to do locked upgrades.
 
 All of this looks very far away from the init system discussion,
 though. 

I agree this is moving away from init discussion, but I want to address
the part about locked upgrades. Just depending on new kernel features
is not the same as lockstep as in needing to upgrade everything
together (like the case where old udev didn't work with new kernel _and_
new kernel didn't work with old udev). If you upgrade to a kernel with
backported features, that obviously should not cause any special issues.
And the kernel typically tries fairly hard to keep old userspace
working, so even upgrading to a completely new kernel version doesn't
mean you have to upgrade the whole userspace. If running the next
release in a chroot on your stable machine requires an upgraded kernel
package with backported features, or even a completely new kernel
version, that's much less of a problem than needing to upgrade the whole
OS.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd socket activation protocol rationale

[Uoti Urpala]

On Sat, 2013-12-14 at 21:45 +, Ian Jackson wrote:
 I've just been reading sd_listen_fds(3).  It's vaguely similar to
 upstart's socket activation protocol.  It supports multiple sockets
 (which is obviously important).
 
 But I have a few questions about the details:
 
 Why do only some of the environment variables start SD_ ?
 We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.

You misread it: there is no environment variable SD_LISTEN_FDS_START.
The API defines the start value as the constant 3. There is a
corresponding #define in sd-daemon.h, but it is not communicated at
runtime.


 What is the rationale behind the use of the LISTEN_PID variable and
 the pid check ?  It seems to me that at the very least this might make
 it hard to wrap up a socket-activated daemon in a shell script.

To ensure that the environment values are never accidentally inherited
by any child process.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd (security) bugs

[Uoti Urpala]

On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote:
 On Tue, 03 Dec 2013, Josselin Mouette wrote:
  Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : 
   Josselin Mouette j...@debian.org writes:
   
There are two implied assumptions here: 
  * that the same people are developing all components; 
  * that develolpers have the same attention to code quality and
security in all components they work on.
   
I don’t think either of them applies to systemd.
   
   Right, this succinctly captures one of my biggest concerns about systemd.
  
  Could you please elaborate on this concern? Is it about the large number
  of developers, or about the fact they treat important pieces of code
  more carefully?
 
 Projects which have multiple components, each of which has different
 security/interface surfaces without stable defined interfaces, can lead
 to problems when one set of developers doesn't understand the security
 implications of the parts that they do not work on.
 
 The combination of components into a single monolith is sometimes
 necessary, but it's not clear that it is so in the case of systemd.

IMO single monolith is bad terminology - to me that sounds something
like everything in a single process, while the systemd components are
quite modular.

Not clear it's necessary seems like an overly negative attitude. There
doesn't seem to be much disagreement about the fact that many of the
systemd components are very useful and would be used even with a
different init. The above security considerations seem purely
theoretical, with no sign that they'd be an issue with systemd in
practice. And IIRC no other actual technical problems resulting from
developing the components together have been brought up in this thread
either. So why should it be done any differently, when this way appears
highly successful?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]

[Uoti Urpala]

On Fri, 2013-11-29 at 12:37 +, Ian Jackson wrote:
 Uoti Urpala writes (Bug#727708: systemd (security) bugs (was: init system 
 question)):
  My guess is that most people do not consider that exciting or really
  care - thinking of system states in terms of runlevels is mostly
  obsolete, and the flaws do not bother many people in the cases where
  backwards compatibility is still needed.
 
 Statements like this are part of what make me think this might be a
 fundamental problem.  When a systemd proponent tells me that a
 particular use pattern is unimportant or wrongheaded, I tentatively
 infer that systemd cannot support it properly.

At least here this logic led you to the wrong conclusion, so you might
want to reconsider it.

 It seems to me that the difficulties with the runlevel emulation are
 likely to affect other similar use patterns too.  The problems don't
 seem specific to the nature of runlevels.  Perhaps they are specific
 to the way runlevels are emulated by systemd but in that case that
 emulation should surely be fixed.

The issue was legacy runlevel changes being simply mapped to isolate
new_runlevel, which does not have quite the same semantics as sysvinit
runlevel changes (most importantly, it stops everything not in the
new_runlevel target, without limiting to only things that were part of
original runlevel target). There's no reason why the set of services to
stop could not be calculated in a way closer to sysvinit semantics. But
there's little reason to deal with runlevels at all when using
systemd, and it seems most people don't. So while the backwards
compatibility support could be improved (probably rather easily), I
think it's clear why this has not been a priority for either developers
or users.


 More importantly it is one which is exploitable only as a consequence
 of the questionable design decision to expose pid 1 to ordinary users.

I think there are good reasons to allow querying status directly. One
sanity check that IMO should be kept in mind for perspective when
considering any even one DoS issue in PID 1 is a catastrophe arguments
is that Debian will always require running a kernel, and there have been
lots of DoS or worse issues there. Unless you expect the majority of
Debian users to move to minimal microkernels in the near future, there
is little basis to demand an absolutely minimal init process when the
kernel contains much more code in a more critical role.

The same applies to this:
 and is being touted as the single systemwide manager for security
 features like cgroups !

Parts of the implementation for this are on the kernel side, parts on
the systemd side. I see no reason to think that the systemd side would
be the more problematic one.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: systemd (security) bugs (was: init system question)

[Uoti Urpala]

Ian Jackson wrote:
 It isn't always 100% clear to me from reading these which of them
 apply to systemd's init replacement.  But reading the systemd debate
 page makes it clear that the other components in the systemd upstream
 package are seen by systemd proponents as part of their offering, and
 indeed reasons to pick systemd.

Yes, the other tools that systemd provides and enables are part of its
usefulness, so it is appropriate to look into their quality.


 I should say that it is hard to write code with no security bugs at
 all.  But I think our benchmark for security bugs in our init system
 ought to be very few, particularly if we are making a specific
 implementation effectively mandatory.  And I don't think I would like
 to accept justifications (for a large bug count) along the lines of
 but systemd does so much more; I think the security bugs that come
 with a large codebase, or having more functionality exposed to
 ordinary users, are a direct and very relevant downside to such a
 large codebase or large attack surface.

But this, I think, is completely wrong. You shouldn't count bugs from
other tools included with systemd against its core init functionality or
vice versa. If for example systemd and coreutils came from the same
source package, that should be allowed as many bugs as the current two
separate source packages, not less.

Most of the separate functionality is optional. It's likely that Debian
would want to use it, but then Debian would want that functionality with
other init systems too (or miss it). The most appropriate comparison is
whether it's possible to have similar functionality with less bugs
(whether provided with init system or completely independently). As far
as I can see, for most functionality there are no such alternatives.

At least Upstart, and likely other alternatives to systemd also, would
still use forked versions of at least logind and possibly other tools
originating from systemd. Such forks are worse for security than using
the original systemd one. Thus the fact that logind is developed with
systemd should count in favor of systemd, not against it.

Also, systemd is the system under the most intense scrutiny for security
and other issues, so it's not easy to compare bug counts with
alternatives - alternatives likely have a significantly larger portion
of issues undetected.


 Here are a couple of exciting snippets:

 https://bugzilla.redhat.com/show_bug.cgi?id=708537
 
   Problems with runlevel emulation doing mad things.  It isn't clear
   to me whether this bug is a symptom of a fundamental problem with
   systemd's state-based dependency model, or whether it's simply a

I think it's completely obvious that there is no fundamental problem.
I wonder what could make you consider it a possible symptom of one.

   missing feature or perhaps even wrong default configuration.  But
   the bug has been open for some time.

My guess is that most people do not consider that exciting or really
care - thinking of system states in terms of runlevels is mostly
obsolete, and the flaws do not bother many people in the cases where
backwards compatibility is still needed.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707653: Grub 2.00-14 upgrade from 1.99 failed to run update-grub

[Uoti Urpala]

I encountered this bug, though the system still booted successfully with
some error messages.

grub-install /dev/sda and update-grub fixed the problem.

'dpkg-reconfigure grub-pc' was NOT useful.

I think grub-pc.postinst failed to run any of the code paths that would
run update-grub. The script seems to use existence of stage2 file as a
trigger for update path from legacy grub and existence of core.img as
a trigger for new grub. Before running the above commands, my system had
neither a file named stage2 nor one named core.img, so the script
did nothing.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702533: mplayer2: continue from pause not working

[Uoti Urpala]

This is most likely caused by misbehaving audio output. Especially
PulseAudio is known to have bugs which cause such problems. However,
you're using the mplayer2 version from experimental which has
workarounds for those PulseAudio issues and should work for most people
(unfortunately, Debian unstable still ships a version which is known to
cause problems for a significant portion of users).

Do you have PulseAudio active on your system? If you do, which audio
output API are you using in mplayer2 - ao_pulse or ao_alsa? In the
default Debian PulseAudio configuration, applications outputting sound
with the ALSA API are redirected to PulseAudio, and this redirection
mode is even more buggy than the native PulseAudio API (note that this
applies only to the default ALSA device; if you configure mplayer2 to
use an ALSA hardware device, that works fine and will not be
redirected).

In any case you can verify that the issue is caused by audio output by
using --nosound or --ao=null (the latter is closer to normal playback
with audio; it decodes audio but only outputs it with a dummy driver).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688800: mplayer2: can not seek wvc1 videos

[Uoti Urpala]

On Wed, 2012-09-26 at 07:21 +0200, Reinhard Tartler wrote:
  wvc1 videos are unseekable in mplayer2. For example if I try to seek 10 
  seconds
  forward using right key, then the video freezes. A sample video is here:
 
  http://ftyps.com/unrelated/vc1_in_wmv.wmv
 
 I can reproduce the problem with the default libavformat demuxer:
 
 mplayer -demuxer lavfpref vc1_in_wmv.wmv
 
 But not with the internal asf demuxer:
 
 mplayer -demuxer asf vc1_in_wmv.wmv
 
 Interestingly, avplay does not have any problems with seeking:
 
 avplay vc1_in_wmv.wmv
 
 This doesn't mean that libavformat was bugfree, this may as well
 indicate a problem in the way how mplayer2 drives libavformat.
 
 Uoti, can you have a look at this? Thanks!

This is a bug in the libavcodec VC-1 decoder. It outputs a frame from
the old position after a seek flush. Actually, the codec object in
vc1dec.c seems to be completely missing the needed .flush field entry.

That it happens to work closer to normal with the internal demuxer is
just a side effect of a different timing mode used with the old demuxer;
the decoder misbehavior does not have the same effects in that case.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#432017: Aptitude forgets about automatically installed status on upgrade.

[Uoti Urpala]

Another thing which seems to reliably lose state:
- setup apt-listchanges to show changelogs and prompt for confirmation
- start an upgrade which would remove some now unused packages
- answer 'n' to the apt-listchanges prompt

The packages that would have been removed have now lost automatic
status, and will not be removed if you restart the upgrade.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674145: mplayer2: mplayer does not stop after playing a file

[Uoti Urpala]

On Thu, 2012-05-24 at 13:47 +0200, Martin Ziegler wrote:
 mplayer said that the output device was pulse:
 
 AO: [pulse]
 
 Wenn I use mplayer with the option -ao alsa everything 
 works fine. Thanks!

This is most likely a Pulseaudio bug then.


 It might be interesting that the version of mplayer in the 
 package mplayer does not hit this bug. It works also with 
 the option -ao pulse.

The old code in MPlayer 1 exits the main play loop after all audio has
been buffered, regardless of the amount of audio not actually played yet
(a flush all buffered audio operation is performed later). So it's
expected that this Pulseaudio bug does not have the same effect. The
problem with the old code is that the player can become unresponsive for
relatively long periods during the flush operation, even with audio
output drivers that function perfectly.

It would be possible to add some workarounds on the player side for this
bug. But I'm not sure whether that would be worth it, as there are so
many bugs in Pulseaudio, and 2.0 broke more things again. Trying to work
around just this bug feels somewhat pointless in this situation. The
current situation where Pulseaudio has become the standard sound output
method but seems to lack developers to fix even fairly blatant bugs in
basic functionality is unfortunate.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673820: mplayer2: -ao pulse does not work

[Uoti Urpala]

The issue in the log is due to the file being so short (0.5 seconds).
This is the same as
http://devel.mplayer2.org/ticket/166

The total amount of audio is not enough to trigger automatic start of
playback. However, for some weird reason setting that amount lower
triggered yet another Pulseaudio bug (it has a LOT of bugs), so mplayer2
doesn't currently do that.

Unfortunately Pulseaudio 2.0 seems to be yet buggier again than previous
versions - now seeking is _always_ buggy regardless of whatever else you
do on my machine at least (after calling pa_stream_flush() it takes a
long time before audio playback from the new position starts working
right, leading to stopped audio and frozen video until then). So perhaps
this issue could be fixed; OTOH that'd mean seeking would be broken with
all Pulseaudio versions, even the older ones where it worked before.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674145: mplayer2: mplayer does not stop after playing a file

[Uoti Urpala]

Are you using Pulseaudio output (or ALSA redirected through Pulseaudio)?
My first guess is that you're hitting one of Pulseaudio's numerous bugs,
where it keeps falsely reporting that there's still a significant amount
of unplayed audio left; the player keeps waiting for the audio to finish
playing.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material

[Uoti Urpala]

On Sat, 2012-05-12 at 12:52 +0200, Kurt Roeckx wrote:
 On Sun, Apr 15, 2012 at 07:17:34PM +0300, Uoti Urpala wrote:
  This is expected behavior with ALSA dmix. It has a fixed hardware output
  frequency, in your case 48000 Hz.
 
 As far as I know this is just a default and has nothing at all to
 do with what the hardware supports, it's just a value in a config
 file.

I meant it's fixed for each dmix instance; when ALSA dmix is using a
hardware frequency of 48000 Hz, everything will be resampled to that.
You can configure dmix to use a different frequency, but it won't adapt
based on source audio.


 I know all this.  That doesn't mean things can't be improved.

Well, it certainly sounded like you didn't know all this; if you did, I
can't see why you wrote The problem now is that mplayer does this in
libao2/ao_alsa.c: in the original message, or reported this against
mplayer2 at all (in addition to libasound2). What could be improved in
mplayer2?




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671934: ABI changes without SONAME change

[Uoti Urpala]

ff_codec_wav_tags is not part of the ABI (all symbols with ff_ prefix in
Libav are internal and may not be used in outside applications).

MPlayer1 is designed to be compiled with an embedded copy of FFmpeg
rather than use shared libraries for libavformat etc. It does not stay
within the API exported by the libraries. Try using mplayer2.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671362: mplayer2 crashes when trying to connect to remote pulseaudio server

[Uoti Urpala]

Fixed upstream in bb908027178fe8bfd7d6e3fc255dea8c5051cd4a.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#667470: systemd: breaks sudo

[Uoti Urpala]

If I've understood the issue correctly, the current forwarded tag on
this bug is wrong, in the sense that the fundamental underlying problem
is in sudo, and so any possible forwarding waiting for upstream fix
should point to a sudo bug.

AFAIK this problem with libpam-systemd is caused by the same sudo bug as
#648066 (and others). sudo incorrectly forks a child process, does the
open side of pam authentication there, runs the command to execute in
that child, and then runs the close side in the parent (which never
saw anything about the open, so lacks the state stored from that!).
The specific problem this behavior causes in the libpam-systemd case is
that the fd received during the open phase (which is part of the pam
session state) is closed on exec, terminating the session.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670236: mplayer2: can't play video with resolution of 2542x1080

[Uoti Urpala]

This is a limitation reported by libXv. It's likely due to limitations
of your graphics hardware. You can try other output methods such as gl,
but it's likely they won't work well either on such hardware.

Using --xy=0.5 won't help, because that will try to do the scaling in
hardware, but the limitation is about hardware input image size. You can
force software scaling on CPU with options like --vf=scale=1920:-2.
This would add a filter to do software scaling to a width of 1920 and a
height that keeps the original aspect ratio, which should fit within the
limitations of your hardware. You may want to adjust the value of 1920
if you have a monitor smaller or larger than that.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material

[Uoti Urpala]

As far as I can see there is no bug.

This is expected behavior with ALSA dmix. It has a fixed hardware output
frequency, in your case 48000 Hz. Anything played through dmix will be
resampled to 48000 Hz. mplayer2 could feed data to ALSA at 44100 Hz if
it left ALSA resampling enabled, but the only difference that would make
is that the resampling would happen on the ALSA side rather than on the
mplayer2 side.

There's no way hardware would support everything in the 4000-4294967295
range. That range only tells which rates ALSA is willing to resample to
48000 Hz. The values reported for the hw device, 44100 48000 96000
192000, are the ones your hardware can actually play without
resampling. If you select the hw device then you should be able to play
these rates without resampling (note that in contrast to dmix, using the
hw device directly reserves the device and no other audio source can
play at the same time).

The only thing here that could potentially be improved would be to allow
dmix to change the hardware playback rate depending on input streams, so
it could switch the hardware rate to 44100 Hz if that's the rate of the
only stream being played. But this would be nontrivial - what happens if
another stream is opened at a different frequency, etc.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems

[Uoti Urpala]

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.general as well.

Reinhard Tartler siretart at tauware.de writes:
 Package: wnpp
 Severity: wishlist
 Owner: Reinhard Tartler siretart at tauware.de
 
 * Package name: mplayer2
   Version : 2.0beta1
   Upstream Author : Uoti Urpala uoti.urpala at pp1.inet.fi
 * URL : http://www.mplayer2.org/
 * License : GPL
   Programming Lang: C
   Description : next generation movie player for Unix-like systems
 
MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV,
QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files,
supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. It
can also play VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies.
 
Another big feature of MPlayer is the wide range of supported output
drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, DirectFB,

 The text above is copied from the existing mplayer package. It is

The long description really needs a rewrite.

 basically a well-known and quite popular fork of mplayer. TBH, I'm a bit
 unsure what to do with it. From the first look, it seems that mplayer2
 is better suited for being included in a distro release, but not (yet)
 in its current form. Currently, it includes a copy of ffmpeg-mt, a

I'm not sure if you've misunderstood something or just phrased things
inaccurately, but I think this description is at least misleading for people who
aren't already familiar with the setup.

The player itself does not include a copy of any FFmpeg version, and can be
compiled against any external library versions. However, using FFmpeg-mt is the
best choice for the majority of users. Since there aren't packaged versions
available for most distros (and it's not really suited for a systemwide install
in its current form due to some API issues), the alternative recommended for
most users is to statically link against a custom-compiled FFmpeg-mt. The build
wrapper exists to make it easy to do this without needing separate manual
library building steps. However, use of the wrapper is in no way forced, and
users/packagers are free to choose what form of FFmpeg libraries to compile
against.

 well-known fork of the ffmpeg package, which features multithreaded h264
 decoding and actually is already in debian as part of the
 chromium-browser package. While ffmpeg-mt is currently being
 integrated/merged into ffmpeg upstream, mplayer2's future is not that
 certain.

If by future you mean the possibility of a merge with MPlayer 1, I think it's
pretty certain that won't happen. It's possible that at some point MPlayer 1
will die and be completely replaced by MPlayer2, but any other kind of merge
seems unlikely.


 Having this in mind, I intend to maintain the package under the
 pkg-multimedia umbrella. mplayer2 shoudl go to experimental for now,
 including ffmpeg-mt. Help and ideas with that is more than welcome!

I think having a package using FFmpeg-mt available is good, as it's a
substantial performance improvement over anything available in Debian today.
However as above this isn't directly forced by MPlayer2 itself.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org