Bug#939119: closed by Yavor Doganov (Bug#939119: fixed in gnustep-base 1.26.0-5)

[Alan Jenkins]

On 19/09/2019 13:09, Yavor Doganov wrote:

Control: reopen -1
Control: found -1 1.26.0-5

Alan Jenkins wrote:

But now I can see the code laid out, I'm not sure the newly added
preinst is doing anything.

You are right that it does nothing :-(

Oddly enough, I've been investigating this on a buster machine
(upgraded from stretch) where all symlinks were K.  It is quite
possible that I've disabled it manually with update-rc.d and I just
don't remember.  However, on a stretch machine not yet upgraded to
buster:

yavor@bogdana:~$ find /etc/rc?.d -name \*gdomap
/etc/rc0.d/K01gdomap
/etc/rc1.d/K01gdomap
/etc/rc2.d/S18gdomap
/etc/rc3.d/S18gdomap
/etc/rc4.d/S18gdomap
/etc/rc5.d/S18gdomap
/etc/rc6.d/K01gdomap
yavor@bogdana:~$ grep ^ENABLED /etc/default/gdomap
ENABLED=no


We only reset the symlinks - i.e. disable the init script - when the
[S]tart symlink does not exist - i.e. the init script is already
disabled?

Stupid me.


You weren't the first person to suggest testing /etc/rc2.d/S??gdomap 
:-). I always think this stuff is confusing.  The important thing is to 
ask for people to test it :-).





If we don't have an ENABLED= line, because we already hit this bug,
then I think we just don't have the information.  We have to make the
choice.

Right.  And the default choice should be to disable the daemon.


Either preserve the current enabled status, as I do above. Or
check we don't have ENABLED=yes, then guess the user was in the
"99.5%", and force the service to be disabled.

I prefer the latter.


1. My hopes had been raised to see something for this issue in Debian 
10.x.  Even if it was basically limited to documentation in NEWS and the 
release notes.  This would raise the question, would you use this 
approach for a backport for 10.x?  Or would that require something 
different?


umm, and if we do disable in 10.x, I have a bonus question.  Would we 
need some code to make sure we didn't disable a second time on upgrade 
to 11.x?



2. For my sake, I am very happy to see gdomap disabled on the next 
upgrade :-).


Our defaults already mean that if you rely on gdomap, you need to know 
that, and enable it. (And if you want network features, change 
GDOMAP_ARGS.  In a way, I think the docs make that sound like more 
hassle than it is).


My only caveat is if you backported this approach to 10.x, I don't know 
enough to guess exactly how many people will be annoyed.


I had another look regarding a clever automatic check we could use in 
the preinst script.  But I didn't come up with anything



3. Disclosure: I think this argument is not very strong:


IOW, if the user wants the daemon running, chances are that he has
already changed the default to ENABLED=yes and although it does
nothing from the buster version onwards, it seems likely that he has
preserved his modification to the /etc/default/gdomap file.


If you choose to see a three-way diff, and see the package wants to 
remove ENABLED=, I think it's just as plausible you would have let the 
package do that.


There might be a way to be really clever, although I do not advocate it 
at all. Provide an upgrade prompt, that checks ENABLED= but otherwise 
defaults to disabling gdomap.  If a gdomap user tends to do upgrades 
Fedora/PackageKit style, i.e. accept all the default prompts, that means 
they will likely have preserved the ENABLED=yes :-).  Non-gdomap users 
will get it disabled again.  At the cost of inflicting one more upgrade 
prompt on a lot of people.



4. The implementation might be improved.


How about this:

if [ "$1" = "upgrade" ]; then
 if dpkg --compare-versions "$2" lt 1.26.0-6; then
 if [ -f /etc/default/gdomap ]; then
 . /etc/default/gdomap
 if [ "$ENABLED" != "yes" ]; then
 find /etc/rc?.d -name "*gdomap" -delete
 fi
 fi
 fi
fi


I guess you did not prefer my super-cautious approach, sourcing the 
config file inside brackets so it uses a sub-shell, and does not import 
arbitrary variables from the file e.g. LD_PRELOAD= :-).


Anyway, in this more aggressive policy, I think it should remove the 
links even if /etc/default/gdomap does not exist.  I think that makes it -


if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-6; then
ENABLED=no
    if [ -f /etc/default/gdomap ]; then
   ENABLED="$( . /etc/default/gdomap && echo "$ENABLED")"
fi
    if [ "$ENABLED" != "yes" ]; then
   find /etc/rc?.d -name "*gdomap" -delete
fi
fi
fi

# or without using a subshell

if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-6; then
ENABLED=no
    if [ -f /etc/default/gdomap ]; then
   . /etc/default/gdomap
fi
    if [ "$ENABLED" != "yes" ]; then
   find /etc/rc?.d -name "*gdomap" -delete
fi
fi
fi


Thanks again for your hard work
Alan

Bug#939119: closed by Yavor Doganov (Bug#939119: fixed in gnustep-base 1.26.0-5)

[Alan Jenkins]

On 18/09/2019 22:21, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the gnustep-base-runtime package:

#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap 
network service to become enabled


It has been closed by Yavor Doganov .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Yavor Doganov 
 by

replying to this email.


[resend: try to fix non-html formatting]

Thanks Yavor, and everyone else. But now I can see the code laid out, 
I'm not sure the newly added preinst is doing anything.


# Upgrades from stretch to buster have made the gdomap daemon enabled
# by default which is undesirable. Explicitly delete the symlinks and
# let update-rc.d recreate them in postinst. See #939119.
# Remove after bullseye is released.
if [ "$1" = "upgrade" ]; then
    if dpkg --compare-versions "$2" lt 1.26.0-5; then
        if [ ! -h /etc/rc2.d/S*gdomap ]; then
            find /etc/rc?.d -name "*gdomap" -delete
        fi
    fi
fi


We only reset the symlinks - i.e. disable the init script - when the 
[S]tart symlink does not exist - i.e. the init script is already disabled?


Shouldn't it look like the below? (I've bumped the package version here :)

if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-6; then
if [ -f /etc/default/gdomap ]; then
if ( . /etc/default/gdomap; [ "$ENABLED" = "no" ]); then
 find /etc/rc?.d -name "*gdomap" -delete
fi
 fi
fi
fi


If we don't have an ENABLED= line, because we already hit this bug, then 
I think we just don't have the information.  We have to make the 
choice.  Either preserve the current enabled status, as I do above. Or 
check we don't have ENABLED=yes, then guess the user was in the "99.5%", 
and force the service to be disabled.


Warm regards
Alan

Bug#939119: closed by Yavor Doganov (Bug#939119: fixed in gnustep-base 1.26.0-5)

[Alan Jenkins]

On 18/09/2019 22:21, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the gnustep-base-runtime package:

#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network 
service to become enabled

It has been closed by Yavor Doganov .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Yavor Doganov 
 by
replying to this email.


Thanks Yavor, and everyone else. But now I can see the code laid out, 
I'm not sure the newly added preinst is doing anything.


# Upgrades from stretch to buster have made the gdomap daemon enabled
# by default which is undesirable. Explicitly delete the symlinks and
# let update-rc.d recreate them in postinst. See #939119.
# Remove after bullseye is released.
if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-5; then
if [ ! -h /etc/rc2.d/S*gdomap ]; then
find /etc/rc?.d -name "*gdomap" -delete
fi
fi
fi


We only reset the symlinks - i.e. disable the init script - when the 
[S]tart symlink does not exist - i.e. the init script is already disabled?


Shouldn't it look like the below? (I've bumped the package version here :)

if [ "$1" = "upgrade" ]; then
if dpkg --compare-versions "$2" lt 1.26.0-6; thenif [ -f 
/etc/default/gdomap ]; then if ( . /etc/default/gdomap; [ "$ENABLED" = 
"no" ]); then find /etc/rc?.d -name "*gdomap" -delete fi fi fi


If we don't have an ENABLED= line, because we already hit this bug, then 
I think we just don't have the information.  We have to make the 
choice.  Either preserve the current enabled status, as I do above. Or 
check we don't have ENABLED=yes, then guess the user was in the "99.5%", 
and force the service to be disabled.


Warm regards
Alan

Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled

[Alan Jenkins]

On 01/09/2019 12:52, Michael Biebl wrote:

On 01.09.19 13:24, Alan Jenkins wrote:

Package: gnustep-base-runtime
Version: 1.26.0-4
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

I had "gnustep-base-runtime" installed on my system, probably as a
dependency of "unar".

When I upgrade from Debian 9 to Debian 10 (and reboot), there is a
network server "gdomap".  I did not see this server on Debian 9.
"gdomap" is not wanted.  It is supposed to be disabled by default
since 2013, i.e. in Debian 8.[1]

[1] #717773 "/usr/bin/gdomap: please split out gdomap or disable it by default"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773

The problem is due to this code change:

"Disable gdomap via defaults-disabled as per Policy 9.3.3.1."
https://salsa.debian.org/gnustep-team/gnustep-base/commit/e0da63fa9e341a38a9a493a615c2c36b8f9d418f

Salvatore Bonaccorso analyzed this for me:


Install a fresh stretch installation and install gnustep-base-runtime
in it. gdomap is not started by default, because gdomap init honours
the ENABLED=no setting in /etc/default/gdomap. Now update the host to
buster.

During this update /etc/default/gdomap is updated according to the
above. Unless the admin has modified it, where then it will be
noticed and admin asked for a decision. As formerly the init was
enabled, and the code to handle the ENABLED setting is removed this
might be the problem. The postinst calls update-rc.d gdomap
defaults-disabled [...]

"update-rc.d" does not do anything in this case.  The man page says


If any files named /etc/rcrunlevel.d/[SK]??name already exist then
update-rc.d does nothing.  The program was written this way so that
it will never change an existing configuration, which may have been
customized by the system administrator.  The program will only
install links if none are present, i.e., if it appears that the
service has never been installed before.

I guess gnustep-base-runtime explicitly needs to remove the existing
/etc/rc?.d/???gdomap symlinks on upgrades in preinst (possibly guarded
by a check which reads the old /etc/default/gdomap and tests if
ENABLED=NO) so they can be properly re-created (and disabled) by
"update-rc.d defaults-disabled"

That said, I find the severity vastly exagerated, but that's just me.


Thanks.  In general I don't know what to do with the severity field 
:-).  I maybe used it once before, and that's it.


IMO this bug is release-relevant.  Then it should be "serious" or above.

#717773 points out that "unar" was installed by default, e.g. in Debian 
7 Desktop. "unar" is not removed on upgrade, even after "apt 
autoremove".  Because "file-roller" still has "Suggests: unar".


#717773 was tagged "security", but the severity was "normal".  The 
current issue is slightly different to #717773, in the sense that it is 
a regression.


The above is post-hoc.  At the time, I just noticed that "reportbug 
--mode=standard" didn't offer me the "security" tag if I filed at 
severity "normal".  And gdomap doesn't run as root, so it's not a root 
bug ("critical").


Alan

Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled

[Alan Jenkins]

Package: gnustep-base-runtime
Version: 1.26.0-4
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

I had "gnustep-base-runtime" installed on my system, probably as a
dependency of "unar".

When I upgrade from Debian 9 to Debian 10 (and reboot), there is a
network server "gdomap".  I did not see this server on Debian 9.
"gdomap" is not wanted.  It is supposed to be disabled by default
since 2013, i.e. in Debian 8.[1]

[1] #717773 "/usr/bin/gdomap: please split out gdomap or disable it by default"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773

The problem is due to this code change:

"Disable gdomap via defaults-disabled as per Policy 9.3.3.1."
https://salsa.debian.org/gnustep-team/gnustep-base/commit/e0da63fa9e341a38a9a493a615c2c36b8f9d418f

Salvatore Bonaccorso analyzed this for me:

> Install a fresh stretch installation and install gnustep-base-runtime
> in it. gdomap is not started by default, because gdomap init honours
> the ENABLED=no setting in /etc/default/gdomap. Now update the host to
> buster.
>
> During this update /etc/default/gdomap is updated according to the
> above. Unless the admin has modified it, where then it will be
> noticed and admin asked for a decision. As formerly the init was
> enabled, and the code to handle the ENABLED setting is removed this
> might be the problem. The postinst calls update-rc.d gdomap
> defaults-disabled [...]

"update-rc.d" does not do anything in this case.  The man page says

> If any files named /etc/rcrunlevel.d/[SK]??name already exist then
> update-rc.d does nothing.  The program was written this way so that
> it will never change an existing configuration, which may have been
> customized by the system administrator.  The program will only  
> install links if none are present, i.e., if it appears that the 
> service has never been installed before.

It is unfortunate that "Policy 9.3.3.1" does not have an explicit
warning about this potential security problem.

So this is a problem with upgrades.  It does not happen on a fresh
install of Debian 10.

Salvatore also suggested

> I think it's best handled though in a bugreport accordngly, and once
> fixed in unstable, to schedule a fix as well via a buster point
> release.

$ sudo netstat -l -p
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
...
udp0  0 0.0.0.0:gdomap  0.0.0.0:*   
57/gdomap

$ ps aux | grep gdomap
nobody  57  0.0  0.0   2736  2052 ?Ss   11:16   0:00 
/usr/bin/gdomap -I /var/run/gdomap.pid -p -j /var/run/gdomap

$ dpkg-query -S gdomap
gnustep-base-runtime: /usr/share/man/man8/gdomap.8.gz
gnustep-base-runtime: /etc/default/gdomap
gnustep-base-runtime: /usr/bin/gdomap
gnustep-base-runtime: /etc/init.d/gdomap


[Report sent from a systemd-nspawn container, which I used to reproduce the 
issue]

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

Kernel: Linux 5.2.9-200.fc30.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnustep-base-runtime depends on:
ii  gnustep-base-common  1.26.0-4
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgnustep-base1.26  1.26.0-4
ii  libobjc4 8.3.0-6
ii  lsb-base 10.2019051400

gnustep-base-runtime recommends no packages.

gnustep-base-runtime suggests no packages.

-- no debconf information

Bug#930476: exim4 is no longer installed by default

[Alan Jenkins]

Package: installation-guide
Version: 20170614

> 8.5.1. Default E-Mail Configuration
>
> [...] For this reason the packages exim4 and mutt will be installed 
by default (provided you did not unselect the “standard” task during the 
installation).


I have been told by several people, exim4 is no longer installed by 
default :-).


In Debian 9 and above, exim4-daemon-light has been downgraded from 
"Priority: standard" to "optional".


Thanks
Alan

Bug#928888: On debian 9, /etc/init.d/hostapd shows [ ok ], when actually hostapd failed to start

[Alan Jenkins]

Package: hostapd
Version: 2.4-1+deb9u3

https://salsa.debian.org/debian/wpa/blob/debian/2%252.4-1+deb9u2/debian/hostapd.init

log_daemon_msg "Starting $DESC" "$NAME"
start-stop-daemon --start --oknodo --quiet --exec "$DAEMON_SBIN" \
--pidfile "$PIDFILE" -- $DAEMON_OPTS >/dev/null
log_end_msg "$?"

I.e. it fails to pass on the exit status from start-stop-daemon.  As a
result, *** when this specific version of hostapd is used with systemd
*** , "[ ok ]" is shown even if hostapd failed :

> # /etc/init.d/hostapd start
> [ ok ] Starting hostapd (via systemctl): hostapd.service.
> ...
> The error in journalctl -b -u hostapd is:
> Starting advanced IEEE 802.11 management: hostapd failed!

The above is taken from the user report / support request at
https://unix.stackexchange.com/questions/518466/hostapd-hotspot-not-running

In Debian buster, this problem with systemd will be entirely solved,
because we now have hostapd.service, a native systemd service.  Yay!

However there is still this bug in the init script.  Other init
systems are available. These may rely on the old-style init.d scripts,
and may or may not give similarly confusing results.  So it would
still be nice to fix this bug.

I searched for a standard template for a Debian init script.  It turns
out /etc/init.d/skeleton went away, because simple scripts should now
be written using `init-d-script` .  There is a man page for it.  The
current man page is missing a lot of critical information, e.g.
forgets to mention how to pass arguments to the daemon :-( .  The
answers are in the source code, e.g. you can set DAEMON_ARGS.

The hack with "sleep 8" should be easy to re-create if necessary by
defining do_restart_override() and do_force_reload_override() .  I
guess that you are still finding it necessary, seeing as you have
defined RestartSec=2 in the systemd service.

source code link:
https://salsa.debian.org/debian/sysvinit/commit/fbf700964e86953d2c573229c39482db0b9e1eb7

---

There's a similar example showing how this init script incorrectly
shows "active" instead of "failed" in "systemctl status" :
https://github.com/raspberrypi/firmware/issues/1117 :

# service hostapd status
hostapd.service - LSB: Advanced IEEE 802.11 management daemon
   Loaded: loaded (/etc/init.d/hostapd; generated; vendor preset: enabled)
   Active: active (exited) since Wed 2019-02-27 21:05:29 UTC; 3s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 2177 ExecStop=/etc/init.d/hostapd stop (code=exited,
status=0/SUCCESS)
  Process: 2212 ExecStart=/etc/init.d/hostapd start (code=exited,
status=0/SUCCESS)

Feb 27 21:05:29  systemd[1]: Starting LSB: Advanced IEEE
802.11 management daemon...
Feb 27 21:05:29  hostapd[2212]: Starting advanced IEEE
802.11 management: hostapd failed!
Feb 27 21:05:29  systemd[1]: Started LSB: Advanced IEEE
802.11 management daemon.

Bug#928270: PFilePattern change needed for Fedora 29 and 30

[Alan Jenkins]

Package: apt-cacher-ng
Version: 2-2

Hi

I have to use the following extra pattern for Fedora 29 and 30.
Something told me I should send this in.

PfilePatternEx:
[a-f0-9]+-modules.yaml.gz|[a-f0-9]+-(primary|filelists|comps-[^.]*.[^.]*|updateinfo|prestodelta).xml(|.gz|.xz|.zck)

To be honest I started using the modules.yaml pattern a while ago for
Fedora 29.  I think I looked at submitting a patch to
acfg_defaults.cc, but then I got too scared or bored by it.

The second pattern is needed for the shiny new "zchunk"
compression/sync format, that Fedora started using just now.

Thanks for many years saving my bandwidth :-)
Alan

Bug#731656: Please disable securetty by default

[Alan Jenkins]

On Thu, 19 Jan 2017 18:20:17 +0100 Balint Reczey 
 wrote:

> Control: tags -1 confirmed
>
> Hi Josh,
>
> On Sat, 07 Dec 2013 15:13:28 -0800 Josh Triplett 
> wrote:
> > Package: login
> > Version: 1:4.1.5.1-1
> > Severity: wishlist
> >
> > securetty dates back to the days when people still logged into systems
> > via telnet and rlogin. These days, remote access occurs via SSH, which
> > has its own configuration mechanism to determine whether to allow root
> > logins (including more flexible approaches such as disallowing root
> > logins by password but allowing them by key). And any local TTY should
> > be considered a securetty by definition. Thus, I don't think securetty
> > has any value anymore as part of the default configuration of login. I
> > would suggest removing it by default.
>
> I will look into that in the Buster cycle, this change would be too
> intrusive now.
>
> Cheers,
> Balint

Hi

I recently ran a stretch->unstable upgrade, and noticed some 
modification to securetty (conffile conflict v.s. my deletion of 
/etc/securetty).


Can I ask if we've missed the boat for Buster, or is it still a 
possibility to get securetty removed from the pam config?


I understand making any change to PAM configs can be pretty 
nerve-wracking :).


Thanks
Alan

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

On 16/10/17 16:44, Michael Biebl wrote:

Am 16.10.2017 um 12:40 schrieb Alan Jenkins:


I suspect this would end up with Debian carrying the patch to the
systemd generator.  But all it needs to do is test for
`/var/lib/update-rc.d/${script}.removed` and then skip ${script}.

Alan

I'm not very enthusiastic of keeping and maintaining (yet another) state
directory/file which could potentially get out-of-sync .

A much simpler idea could be, to remove the -x bit from the SysV init
script on remove (and reapply it on re-install). Afair, the
sysv-generator already ignores such init scripts. So nothing would have
to change on the systemd side.

dh_installinit (shipped by debhelper) would have to be updated to
generate maintainer scripts code to remove and (re)add the executable bit.

Still, we'd have to consider that we have upgraded systems which have
not been rebuilt with the new debhelper so we can't just remove the
current logic which masks uninstalled-but-not-purged init scripts.

Maybe in two or three releases we could revisit that.

Removing the -x bit of removed-but-not-purged init scripts would have
the nice side effect, that those are also not executed under
sysvinit/startpar.

Are you interested in working on a patch for debhelper?


Sorry.  I thought I should report my annoyance once I'd found the root 
cause for it.  But I don't think I can commit to writing patch(es) now.


Maybe you have the right idea about clobbering the executable bit. I 
didn't like it because the reason for this annoyance was just such a 
clobbering (v.s. systemctl mask).


It was already frustrating to prevent a Debian network service starting 
before you'd configured it.[1]  `systemctl mask` provides a way to do 
it.  For sysvinit, presumably assigning -x with `dpkg-statoverride` 
would be an equivalent.  Perhaps not a well-documented one.  Such 
procedures could be silently defeated if the install script applies +x.


[1] 
https://unix.stackexchange.com/questions/321621/configuring-my-sshd-securely-with-automation/321622


> we can't just remove the current logic which masks 
uninstalled-but-not-purged init scripts


Ouch, I'd forgotten about the transition issue.  Yep, I guess wait for 
long enough and then explain it in a release note.   (Or write an even 
more magic package script to apply the mask to residual conffiles in 
/etc/rc.d).


Alan

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

On 14/10/17 13:27, Michael Biebl wrote:

On Fri, 4 Aug 2017 22:12:08 +0100 Alan Jenkins
 wrote:
Can you please explain how #714903 can be fixed differently so masking
is not needed?


> There were two reasons `mask` was used here.
>
> 1. Removing a package naturally deletes most of its files, including 
deleting the systemd service unit. However the system V init script is 
preserved, because it might include user changes. This can work OK under 
system V init, but systemd also picks up the initscript, and will show 
it as a started service in messages, logs, `systemctl list-units` etc.


I believe the solution (which may or not be politically practical) is:

Implement an equivalent feature to masking for system V init scripts, 
which is dedicated to handle removed packages only.


This only strictly needs to be respected by the systemd generator, which 
converts init scripts to systemd services.


Probably the init scripts want to include the same feature themselves.  
(Around the same point where they decide whether to dispatch to 
`systemctl start` instead).  I think that would also allow removing some 
less regular weirdness from init scripts. Debian would no longer have a 
special requirement that init scripts silently succeed if the daemon 
binary does not exist.  And I think the dnsmasq package (as opposed to 
dnsmasq-core?) has even more special handling, which could go away.


I suspect this would end up with Debian carrying the patch to the 
systemd generator.  But all it needs to do is test for 
`/var/lib/update-rc.d/${script}.removed` and then skip ${script}.


Alan

Bug#874527: live-build: Live installer creates duplicate sources: sources.list and sources.list.d/base.list

[Alan Jenkins]

On 07/09/2017, Michael .  wrote:
> Did you use the official Debian Live iso image or did you make your own?
> The reason I ask is if you used the official image it would have been built
> with Live-Wrapper not Live-Build.

Thanks!  I used the official image.

> On 7 September 2017 at 08:06, Alan Jenkins <
> alan.christopher.jenk...@gmail.com> wrote:
>
>> Package: live-build
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> I just installed Debian from the Live image for 9.1.0.
>> I ended up with duplicate sources, which show up when apt-get downloads.
>> I'm not familiar with the live-build chain, hopefully this is a sensible
>> place
>> to report it.

Bug#874527: live-build: Live installer creates duplicate sources: sources.list and sources.list.d/base.list

[Alan Jenkins]

Package: live-build
Severity: normal

Dear Maintainer,

I just installed Debian from the Live image for 9.1.0.
I ended up with duplicate sources, which show up when apt-get downloads.
I'm not familiar with the live-build chain, hopefully this is a sensible place
to report it.

I believe base.list is created by vmdebootstrap.

I very much like having the deb.debian.org line on the running live image.
But maybe it needs to be moved to /etc/apt/sources.list, so debian-installer
will overwrite it and avoid annoying duplicates?  Maybe it's not so simple
though, I dunno.

Thanks
Alan


$ sudo apt-get update
Ign:1 http://ftp.uk.debian.org/debian stretch InRelease
Ign:2 http://deb.debian.org/debian stretch InRelease
...

$ cat /etc/orig.apt/sources.list.d/base.list
deb http://deb.debian.org/debian/ stretch main
#deb-src http://deb.debian.org/debian/ stretch main

$ cat /etc/orig.apt/sources.list
#

# deb cdrom:[Official Debian GNU/Linux Live 9.1.0 gnome 2017-07-23T01:42]/
stretch main

#deb cdrom:[Official Debian GNU/Linux Live 9.1.0 gnome 2017-07-23T01:42]/
stretch main

deb http://ftp.uk.debian.org/debian/ stretch main
deb-src http://ftp.uk.debian.org/debian/ stretch main

deb http://security.debian.org/debian-security stretch/updates main
deb-src http://security.debian.org/debian-security stretch/updates main

# stretch-updates, previously known as 'volatile'
deb http://ftp.uk.debian.org/debian/ stretch-updates main
deb-src http://ftp.uk.debian.org/debian/ stretch-updates main



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

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

Versions of packages live-build depends on:
pn  debootstrap  

Versions of packages live-build recommends:
ii  apt-utils   1.4.7
ii  cpio2.11+dfsg-6
pn  live-boot-doc   
pn  live-config-doc 
pn  live-manual-html | live-manual  
ii  wget1.18-5

live-build suggests no packages.

Bug#874525: vmdebootstrap: Please update Vcs-Git / Vcs-Browser links

[Alan Jenkins]

Package: vmdebootstrap
Version: 1.7-1
Severity: normal

Hi Maintainers.

I noticed the Git link onhttps://packages.qa.debian.org/v/vmdebootstrap.html
points to a tree which doesn't have the current version 1.7-1.


debian/control

-Vcs-Git:https://anonscm.debian.org/git/vmdebootstrap/vmdebootstrap.git
-Vcs-Browser:https://anonscm.debian.org/cgit/vmdebootstrap/vmdebootstrap.git/
+Vcs-Git:http://git.liw.fi/vmdebootstrap
+Vcs-Browser:http://git.liw.fi/vmdebootstrap/


Though if Lars wants to look at Let's Encrypt and switch the URL back to HTTPS,
that would be really good too :-P.

Regards
Alan


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

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

Versions of packages vmdebootstrap depends on:
pn  debootstrap 
pn  kpartx  
pn  libjs-sphinxdoc 
ii  parted  3.2-17
ii  python  2.7.13-2
pn  python-cliapp   
pn  python-distro-info  
ii  python2.7   2.7.13-2
pn  qemu-utils  

Versions of packages vmdebootstrap recommends:
ii  dosfstools4.1-1
pn  extlinux  
ii  grub2-common  2.02~beta3-5
pn  python-guestfs
pn  qemu-system   
pn  qemu-user-static  
pn  squashfs-tools

Versions of packages vmdebootstrap suggests:
pn  cmdtest  
pn  mbr  
pn  pandoc   
pn  u-boot   

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

On 04/08/17 20:52, Michael Biebl wrote:

On Fri, 09 Jun 2017 17:48:59 +0100 Alan Jenkins

There were two reasons `mask` was used here.

1. #722521.  Removing a package naturally deletes most of its files, including
deleting the systemd service unit.  However the system V init script is
preserved, because it might include user changes.  This can work OK under
system V init, but systemd also picks up the initscript, and will show it
as a started service in messages, logs, `systemctl list-units` etc.

#722521 seems perfectly possible to resolve, without resorting to masking.

How?



You snipped my point 2, which also referred to #722521.  Sadly this was 
a typo. Point _2_ is the easy one to resolve.  Point 1 should have 
referred to #714903; I think it is the more fundamental issue.


Sorry!
Alan

Bug#865350: icinga2-ido-mysql: fails to create features-enabled/ido-mysql.conf

[Alan Jenkins]

Package: icinga2-ido-mysql
Version: 2.6.3-1
Severity: normal

Dear Maintainer,

postinst is clearly trying to set ido-mysql to be enabled in icinga2,
if the user selects "yes" when asked whether to enable it, at install
time.  (If they do not, it tries to disable it).

This doesn't seem to work for me, even after purging both icinga2-ido-mysql
and icinga2-common, removing /etc/icinga2, and trying again.

dbconfig creates the database ok, but the code to enable the feature
doesn't seem to be reached:

dbconfig-common: flushing administrative password
[master 163fc8f] committing changes in /etc after apt run
 Author: alan-sysop 
 2 files changed, 17 insertions(+)
 create mode 100644 icinga2/features-available/ido-mysql.conf
Scanning processes...

(The subsequent lines are from hooks installed by etckeeper
and needrestart).

There's supposed to be lines there saying ido-mysql is either
being enabled, *or disabled*, *and* then icinga2 is being reloaded.

I also notice even though I selected "yes", that's not what is
recorded in debconf.  debconf-show icinga2-ido-mysql shows
that icinga2-ido-mysql/enable is "false".  (It is marked as "*"
for "seen" though).

If I run dpkg-reconfigure, the prompt to enable IDO has the
correct effect (regardless of whether I recreate the database
or not).


Sidenote: there's a minor problem when I purged the packages,
they seem to use the wrong order.  Maybe it needs a special kind of
dependency??  This is why I had to rmdir the features-available
and icinga2 directories.

Purging configuration files for icinga2-common (2.6.0-2) ...
dpkg: warning: while removing icinga2-common, directory 
'/etc/icinga2/features-available' not empty so not removed
Purging configuration files for icinga2-ido-mysql (2.6.0-2) ...

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.5-200.fc25.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages icinga2-ido-mysql depends on:
ii  dbconfig-common 2.0.8
ii  debconf [debconf-2.0]   1.5.61
ii  icinga2-bin 2.6.3-1
ii  icinga2-common  2.6.3-1
ii  libboost-atomic1.62.0   1.62.0+dfsg-4
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11
ii  libgcc1 1:6.3.0-18
ii  libicinga2  2.6.3-1
ii  libmariadbclient18  10.1.24-3
ii  libssl1.1   1.1.0f-3
ii  libstdc++6  6.3.0-18
ii  libyajl22.1.0-2+b3
ii  ucf 3.0036

Versions of packages icinga2-ido-mysql recommends:
ii  mariadb-client-10.1 [virtual-mysql-client]  10.1.23-9+deb9u1

Versions of packages icinga2-ido-mysql suggests:
pn  default-mysql-server | mysql-server  

Also installed:

ii  mariadb-server-10.1  10.1.23-9+deb9u1

Bug#749400: [debhelper-devel] dh_installinit: disable init scripts on removal of package

[Alan Jenkins]

On 09/06/17 18:55, Niels Thykier wrote:

Alan Jenkins:

On Thu, 24 Dec 2015 00:34:22 -0300 Felipe Sateler 
wrote:

[...]


Hi Alan,



Why don't we use `update-rc.d FOO remove` on package removal?  This
would simply remove all the symlinks. [...]


As I read the "update-rc.d" manpage, the symlinks are a part of the
customization that a admin can do.  So if we remove them, then we remove
configuration during "remove" (which must only be done during "purge").
Note this paragraph in update-rc.d(1):

"""
A  common  system administration error is to delete the links with the
thought that this will "disable" the service, i.e., that this will
prevent the service from being started.  However, if all links have been
deleted then the next time the package is upgraded,  the  package's
postinst  script  will  run update-rc.d  again  and  this will reinstall
links at their factory default locations.  The correct way to disable
services is to configure the service as  stopped in all runlevels in
which it is started by default.  In the System V init system this means
renaming the service's symbolic links from S to K.
"""


Thanks,
~Niels


:-(.  I guess my hope was, this bug report showed some sort of 
precedent, that policy did not prevent the idea.  Otherwise, this bug 
would have been shut down earlier on.


I.e. the code running `update-rc.d FOO disable` at removal, would surely 
overwrite the customization done by the admin, but that didn't stop that 
code being pushed to unstable.  (And it's not the reason it was reverted).


Huh, even more confusing: if the package script runs `update-rc.d FOO 
disable` at removal, and then you install the package again and it runs 
`update-rc.d FOO defaults`, I think the init script would stay 
disabled?!  I probably need to stop making assumptions from the history 
of this issue.


It suggests, this proposal would also need to save the enabled state(s) 
at package removal and be able to restore them later... but that's more 
than I'd be willing to implement.


However I can imagine saving a "mask" under /var/lib/update-rc.d/, which 
has a similar disabling effect to a systemd mask. Implementing this in 
/etc/init.d/rc.  And patching the systemd-sysv-generator to match it.


For native systemd services... I would then be able to simply remove all 
the `mask` code in dh_systemd_enable, to solve my issue (described in 
#864504)


Alan

Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

Package: debhelper
Version: 10.4
Severity: wishlist

Dear Maintainer,

dh_systemd_enable switched from `disable` (on package removal) to `mask` in
2013-09[1].

I noticed[2] each such removed service causes a warning at boot time.
`rsync.service: Cannot add dependency job, ignoring: Unit rsync.service is
masked`.  I think boot warnings like this are undesirable.

`mask` is intended as one of those "big hammers" for users, when the system
doesn't do what they want and they're happy to take responsibility for any
resulting messes.[3]  This would explain why systemd considers its use
suspicious, and logs such a message at boot time.

Other advantages:

* Fix #796884 dh_systemd: should preserve static masks between remove and purge
* No other confusion about why /etc/systemd/system/FOO.service exists when the
  package has been removed.
* No confusion about why /etc/systemd/system/multi-user.target.wants/FOO.service
  exists when the package has been removed.
* No user confusion about why 
/etc/systemd/system/multi-user.target.wants/FOO.service
  exists but points to a non-existent file.
* No user confusion about why one removed service is unmasked when the package
  is reinstalled, but another is not.

Disadvantage:

* User `disable` of a service does not persist across package remove+reinstall.
  This behaviour would become consistent with init scripts - assuming #749400
  is implemented - see below (last paragraph).

There were two reasons `mask` was used here.

1. #722521.  Removing a package naturally deletes most of its files, including
   deleting the systemd service unit.  However the system V init script is
   preserved, because it might include user changes.  This can work OK under
   system V init, but systemd also picks up the initscript, and will show it
   as a started service in messages, logs, `systemctl list-units` etc.

2. #722521.  Disabling services on package removal also requires some extra
   care when the package is re-installed.  At the time, the re-install failed
   to re-enable the service.  (It was treated as if it was an upgrade where
   the service had been enabled by the user).

#722521 seems perfectly possible to resolve, without resorting to masking.

#714903 seems more fundamental.  Then I noticed there was an attempt to
disable system V initscripts on package removal: #749400.  If that could
be resolved - which I have posted a suggestion for - there would be no
problem.

Regards
Alan

[1] 
https://anonscm.debian.org/git/collab-maint/init-system-helpers.git/commit/autoscripts/postrm-systemd?id=34f1de71a363168bb62161f9796eb727df8ab797
[2] Longer transcript at 
https://unix.stackexchange.com/questions/369713/removing-debian-package-automatically-masks-systemd-service-causes-a-systemd-w/369745#369745
[3] https://github.com/systemd/systemd/issues/5750#issuecomment-296662267


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

Kernel: Linux 4.11.3-202.fc25.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
pn  autotools-dev
pn  binutils 
pn  dh-autoreconf
pn  dh-strip-nondeterminism  
ii  dpkg 1.18.24
pn  dpkg-dev 
ii  file 1:5.30-1
pn  libdpkg-perl 
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-3
pn  po-debconf   

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

Bug#749400: dh_installinit: disable init scripts on removal of package

[Alan Jenkins]

On Thu, 24 Dec 2015 00:34:22 -0300 Felipe Sateler  
wrote:


> > On Mon, 26 May 2014 18:23:20 -0007 Cameron Norman
> >  wrote:
> > > Package: debhelper
> > >
> > > Greetings,
> > >
> > > It would be much cleaner to disable init scripts when the package is
> > > uninstalled, so that a bunch of shell scripts that just run "[ -x
> > > $DAEMON ] || exit 0" are not slowing down the boot.

> > > I think it would just be overall cleaner to disable the init
> > > configuration on removal of the package with a "update-rc.d disable
> > > $daemon".
> > >
> > > Thank you,
> > > --
> > > Cameron Norman
> >
> > Hi,
> >
> > Unfortunately, our attempt to solve this bug as caused a severe
> > regression (please see #806276) and had to be reverted.
> >
> > Apparently it is *not* safe to call "update-rc.d #SCRIPT# disable"
> > unconditionally. It is not entirely clear to me why/when it would work
> > / not work, so I will put this on hold until further notice.
>
> The problem seems to be that update-rc.d bails out when Default-Start
> is empty. For example, the mdadm-waitidle init script has no
> Default-Start (only Default-Stop). Update-rc.d has the following
> check:
>
> ($start_lvls, $stop_lvls) = parse_def_start_stop($lsb_header);
> @toggle_lvls = @$start_lvls;
> if ($#toggle_lvls < 0) {
> error("$name Default-Start contains no runlevels, aborting.");
> }
>
> And indeed on mdadm-waitidle neither enable or disable work. It seems
> to me this is just an oversight, and update-rc.d should consider both
> start and stop runlevels. I'm now CCing the sysvinit maintainers and
> Andreas Hendriksson (which expressed interest in update-rc.d earlier)

Thanks for the analysis on this bug!  I'd like to see it progress.

I want to avoid a boot-time warning, which is caused by how 
`dh_systemd_enable` handles package removal.  I can see a clear path, 
but only if we can get `dh_installinit` to disable init scripts on 
package removal.


Why don't we use `update-rc.d FOO remove` on package removal?  This 
would simply remove all the symlinks.  (The manpage says we also need to 
pass `-f` if the init script itself will still exist, but the manpage is 
wrong).


#808887 should not block this bug IMO.  Extending `update-rc.d` so it 
can disable mdadm-waitidle etc doesn't seem like a great idea to me.  I 
notice `chkconfig FOO off` (used in RPM scripts) has the same design 
limitation.


Regards
Alan

Bug#863135: ifupdown: man interfaces: network-manager *does* now support source-directory

[Alan Jenkins]

Package: ifupdown
Version: 0.8.19
Severity: normal

Dear Maintainer,

`man interfaces` mentions that network-manager does not
support `source-directory`.  This limitation was fixed in
 
https://github.com/NetworkManager/NetworkManager/commit/ada6b96de94b97df57f321372736f66725676065

The commit is in 1.5.2-dev, and hence network-manager 1.6.
network-manager in stretch is now at version 1.6.2.
Therefore we can remove this caveat from the manual page.

Thanks
Alan


-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 8
-rwxr-xr-x 1 root root 1015 Apr 13  2015 avahi-autoipd
-rwxr-xr-x 1 root root  332 Jan  6  2013 upstart
lrwxrwxrwx 1 root root   32 Feb 20 10:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 4
lrwxrwxrwx 1 root root   23 Jan 23 08:41 avahi-daemon -> ../if-up.d/avahi-daemon
-rwxr-xr-x 1 root root 1409 Mar 24  2016 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 20 10:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 12
-rwxr-xr-x 1 root root  344 Sep 22  2014 ethtool
-rwxr-xr-x 1 root root 4178 Mar 24  2016 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 20 10:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 28
-rwxr-xr-x 1 root root  923 Apr 13  2015 avahi-autoipd
-rwxr-xr-x 1 root root  484 Apr 13  2015 avahi-daemon
-rwxr-xr-x 1 root root 1685 Sep 22  2014 ethtool
-rwxr-xr-x 1 root root 4958 Apr  6  2015 mountnfs
-rwxr-xr-x 1 root root  972 Mar 30 11:18 openssh-server
-rwxr-xr-x 1 root root 1483 Jan  6  2013 upstart
lrwxrwxrwx 1 root root   32 Feb 20 10:55 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


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

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

Versions of packages ifupdown depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  iproute2 4.9.0-1
ii  libc62.24-10
ii  lsb-base 9.20161125

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.5-3

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-1+4
pn  rdnssd  

-- no debconf information

Bug#862857: vim: LOG_ALERT unable to open gpm console, check your /dev filesystem!

[Alan Jenkins]

On 18/05/17 02:33, James McCoy wrote:

Control: reassign -1 gpm 1.20.4-6.2
Control: merge 775443 -1

On Wed, May 17, 2017 at 05:12:55PM +, Alan Jenkins wrote:

This happens when running `vi` inside a systemd-nspawn container.
`vi` is able to run, but each time it logs three lines in
attention-getting RED (loglevel alert) in the system log.


strace shows that vi looks for /dev/vc/0 and /dev/tty0.
Neither of these exist in /dev, this is expected in a container.

This is triggered by some debian-enabled configuration.

Actually, it's triggered by the lack of a user configuration, so Vim
loads defaults.vim, which does "set mouse=a".  Since you're in a
console, that's handled by gpm.



May 17 16:55:36 unstable vim[761]: unable to open gpm console, check your /dev 
filesystem!
May 17 16:55:36 unstable vim[761]: *** err
May 17 16:55:36 unstable vim[761]: Oh, oh, it's an error! possibly I die!

Which are all emitted by gpm[0].  It looks like this has already been
reported[1] against gpm ... over 2 years ago.

[0]: https://codesearch.debian.net/search?q=Oh%2C+oh%2C+it%27s+an+error
[1]: https://bugs.debian.org/775443

Cheers,


Thanks for that.  I just saw /etc/vim/vimrc referring to default.vim, I 
overlooked that default.vim was from upstream.


I'm not sure what you mean by a console. The tty is `/dev/pts/0` (the 
other end is `machinectl login` on the host system).


#775443 says it goes away when removing gpm, so it's not exactly the 
same.  I had never installed gpm on my nspawn container.  vi does pull 
in libgpm though.


The specific error I saw comes from here:
https://github.com/telmich/gpm/blob/1.20.4/src/lib/liblow.c#L213

"what's with the lib??? ... making this piece of code work has been a 
real hassle ..."



Regards
Alan

Bug#862857: vim: LOG_ALERT unable to open gpm console, check your /dev filesystem!

[Alan Jenkins]

Package: vim
Version: 2:8.0.0197-4
Severity: normal

Dear Maintainer,

This happens when running `vi` inside a systemd-nspawn container.
`vi` is able to run, but each time it logs three lines in
attention-getting RED (loglevel alert) in the system log.


strace shows that vi looks for /dev/vc/0 and /dev/tty0.
Neither of these exist in /dev, this is expected in a container.

This is triggered by some debian-enabled configuration.
Running `vim -u NORC -U NORC -N` does not triger it.

That said, I think it's a bug in the code:
I don't understand why vi thinks it's a good idea to try and
open some specific physical device, when vi might be running
inside a multiplexer like screen or tmux which implements a
windowing system.


The log messages are:

May 17 16:55:36 unstable vim[761]: unable to open gpm console, check your /dev 
filesystem!
May 17 16:55:36 unstable vim[761]: *** err
May 17 16:55:36 unstable vim[761]: Oh, oh, it's an error! possibly I die!
 

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: armel
 (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vim depends on:
ii  libacl1  2.2.52-3+b1
ii  libc62.24-10
ii  libgpm2  1.20.4-6.2+b1
ii  libselinux1  2.6-3+b1
ii  libtinfo56.0+20161126-1
ii  vim-common   2:8.0.0197-4
ii  vim-runtime  2:8.0.0197-4

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#862840: needrestart: terminated itself by restarting apt-daily.service (when the script is updated)

[Alan Jenkins]

Package: needrestart
Version: 2.11-2
Severity: normal

Dear Maintainer,

The script for apt-daily.service was recently modified by an update.
When this update was installed by `unattended-upgrades`, `needrestart`
restarted the service.  I.e. needrestart terminates unattended-upgrades,
and hence itself.  This causes a few lines of log noise (below), and
does not quite seem desirable.

Technically this could happen to *any* script triggered by a systemd
timer.  At a guess, the behaviour would be similar to if the timer fired
just before someone shuts the system down, so we shouldn't worry *too*
much about this general case.

So either apt-daily.service could be treated specially, or needrestart
could ignore all Type=oneshot services.

The latter raises questions about a longer-running oneshot service
which is security-sensitive...  So I think the simplest solution is
treat apt-daily.service specially.

apt-daily-upgrade.service should also be treated the same way,
because it also runs unattended-upgrades.

I think unattended-upgrades.service should also be treated
the same way, because this is the service that runs unattended-upgrades
on shutdown (if enabled).


May 17 02:48:40 unstable apt.systemd.daily[3046]: Restarting services...
May 17 02:48:40 unstable apt.systemd.daily[3046]:  systemctl restart 
apt-daily.service
May 17 02:48:40 unstable systemd[1]: apt-daily.service: Main process exited, 
code=killed, status=15/TERM
May 17 02:48:40 unstable systemd[1]: Stopped Daily apt download activities.
May 17 02:48:40 unstable systemd[1]: apt-daily.service: Unit entered failed 
state.
May 17 02:48:40 unstable systemd[1]: apt-daily.timer: Adding 11h 58min 
38.111766s random time.
May 17 02:48:40 unstable systemd[1]: apt-daily.service: Failed with result 
'signal'.


-- Package-specific info:
needrestart output:



-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: armel
 (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages needrestart depends on:
ii  dpkg   1.18.23
ii  gettext-base   0.19.8.1-2
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.23-1
ii  libproc-processtable-perl  0.53-2
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.37-1
ii  perl   5.24.1-2
ii  xz-utils   5.2.2-1.2+b1

Versions of packages needrestart recommends:
ii  libpam-systemd  232-23

Versions of packages needrestart suggests:
pn  needrestart-session | libnotify-bin  

-- Configuration Files:
/etc/needrestart/needrestart.conf changed:
$nrconf{restart} = 'a';
$nrconf{blacklist} = [
# ignore sudo (not a daemon)
qr(^/usr/bin/sudo(\.dpkg-new)?$),
# ignore DHCP clients
qr(^/sbin/(dhclient|dhcpcd5|pump|udhcpc)(\.dpkg-new)?$),
# ignore apt-get (Debian Bug#784237)
qr(^/usr/bin/apt-get(\.dpkg-new)?$),
];
$nrconf{override_rc} = {
# DBus
qr(^dbus) => 0,
# display managers
qr(^gdm) => 0,
qr(^kdm) => 0,
qr(^nodm) => 0,
qr(^sddm) => 0,
qr(^wdm) => 0,
qr(^xdm) => 0,
qr(^lightdm) => 0,
qr(^slim) => 0,
qr(^lxdm) => 0,
# networking stuff
qr(^network-manager) => 0,
qr(^NetworkManager) => 0,
qr(^wpa_supplicant) => 0,
qr(^openvpn) => 0,
qr(^quagga) => 0,
qr(^tinc) => 0,
# gettys
qr(^getty@.+\.service) => 0,
# systemd --user
qr(^user@\d+\.service) => 0,
# misc
qr(^zfs-fuse) => 0,
qr(^mythtv-backend) => 0,
qr(^xendomains) => 0,
qr(^lxcfs) => 0,
# workaround for broken systemd-journald
# (see also Debian Bug#771122 & #771254)
qr(^systemd-journald) => 0,
# more systemd stuff
# (see also Debian Bug#784238 & #784437)
qr(^emergency\.service$) => 0,
qr(^rescue\.service$) => 0,
# don't restart systemd-logind, see #798097
qr(^systemd-logind) => 0,
};
$nrconf{override_cont} = {
};
$nrconf{blacklist_interp} = [
# ignore temporary files
qr(^/tmp/),
qr(^/var/),
qr(^/run/),
];
$nrconf{blacklist_mappings} = [
# special device paths
qr(^/(SYSV$|drm$|dev/)),
# aio(7) mapping
qr(^/\[aio\]),
# Oil Runtime Compiler's JIT files
qr(/orcexec\.[\w\d]+( \(deleted\))?$),
];
$nrconf{skip_mapfiles} = (-d '/proc/sys/kernel/grsecurity' ? -1 : 0);
if(-d q(/etc/needrestart/conf.d)) {
  foreach my $fn (sort ) {
  print STDERR "$LOGPREF eval $fn\n" if($nrconf{verbose});
  eval do { local(@ARGV, $/) = $fn; <>};
  die "Error parsing $fn: $@" if($@);
  }
}


-- no debconf information

Bug#862567: [PATCH] apt.systemd.daily: fix error from locking code

[Alan Jenkins]

Error:

pkgs that look like they should be upgraded:
Error in function stop
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 240,
in stop
apt_pkg.size_to_str(self.current_cps))).rstrip("\n"))
  File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 51,
in _write
self._file.write("\r")
AttributeError: 'NoneType' object has no attribute 'write'
fetch.run() result: 0

Caused by:

LOCKFD=3
unattended_upgrades $LOCKFD>&-

Unfortunately this code does not work, it is equivalent to

unattended_upgrades 3 >&-

I.e. it left fd 3 open, but closed stdout!
---
 debian/apt.systemd.daily | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/debian/apt.systemd.daily b/debian/apt.systemd.daily
index 22cbbded6..d2a0bfbed 100755
--- a/debian/apt.systemd.daily
+++ b/debian/apt.systemd.daily
@@ -294,12 +294,22 @@ debug_echo()
 
 # Maintain a lock on fd 3, so we can't run the script twice at the same
 # time.
-LOCKFD=3
-eval $(apt-config shell StateDir Dir::State/d)
-exec 3>${StateDir}/daily_lock
-if ! flock -w 3600 $LOCKFD; then
-echo "E: Could not acquire lock" >&2
-exit 1
+
+if [ "$1" = "lock_is_held" ]; then
+shift
+else
+LOCKFD=3
+eval $(apt-config shell StateDir Dir::State/d)
+exec 3>${StateDir}/daily_lock
+if ! flock -w 3600 $LOCKFD; then
+echo "E: Could not acquire lock" >&2
+exit 1
+fi
+
+# We hold the lock.  Rerun this script as a child process, which
+# can run without propagating an extra fd to all of its children.
+"$0" lock_is_held "$@" 3>&-
+exit $?
 fi
 
 if test -r /var/lib/apt/extended_states; then
@@ -433,9 +443,9 @@ if [ "$1" = "update" -o -z "$1" ] ; then
 DOWNLOAD_UPGRADEABLE_STAMP=/var/lib/apt/periodic/download-upgradeable-stamp
 if [ $UPDATED -eq 1 ] && check_stamp $DOWNLOAD_UPGRADEABLE_STAMP 
$DownloadUpgradeableInterval; then
if [ $Debdelta -eq 1 ]; then
-   debdelta-upgrade >/dev/null 2>&1 $LOCKFD>&- || true
+   debdelta-upgrade >/dev/null 2>&1 || true
fi
-   if  eval apt-get $XAPTOPT -y -d dist-upgrade $XSTDERR $LOCKFD>&-; then
+   if  eval apt-get $XAPTOPT -y -d dist-upgrade $XSTDERR; then
update_stamp $DOWNLOAD_UPGRADEABLE_STAMP
debug_echo "download upgradable (success)"
else
@@ -446,7 +456,7 @@ if [ "$1" = "update" -o -z "$1" ] ; then
 fi
 
 if which unattended-upgrade >/dev/null 2>&1 && check_stamp 
$DOWNLOAD_UPGRADEABLE_STAMP $UnattendedUpgradeInterval; then
-   if unattended-upgrade -d $XUUPOPT $LOCKFD>&-; then
+   if unattended-upgrade -d $XUUPOPT; then
update_stamp $DOWNLOAD_UPGRADEABLE_STAMP
debug_echo "unattended-upgrade -d (success)"
else
@@ -461,7 +471,7 @@ if [ "$1" = "install" -o -z "$1" ] ; then
 # auto upgrade all upgradeable packages
 UPGRADE_STAMP=/var/lib/apt/periodic/upgrade-stamp
 if which unattended-upgrade >/dev/null 2>&1 && check_stamp $UPGRADE_STAMP 
$UnattendedUpgradeInterval; then
-   if unattended-upgrade $XUUPOPT $LOCKFD>&-; then
+   if unattended-upgrade $XUUPOPT; then
update_stamp $UPGRADE_STAMP
debug_echo "unattended-upgrade (success)"
else
-- 
2.11.0

Bug#862567: apt.systemd.daily always fails - 'NoneType' object has no attribute 'write' (self._file)

[Alan Jenkins]

Package: apt
Version: 1.4.3
Severity: important

I have a patch which fixes this error; I will attach it forthwith.

apt.systemd.daily fails every time.  Errors are shown in the system journal.

The error is from unattended-upgrades, so to reproduce this bug
you must have installed and enabled unattended-upgrades.

Then, remove `/var/lib/apt/periodic/download-upgradeable-stamp`
to force an update.

The error message can then be reproduced by running
`/usr/lib/apt/apt.systemd.daily update`:

Initial blacklisted packages: 
Initial whitelisted packages: 
Starting unattended upgrades script
Allowed origins are:
['origin=Debian,codename=stretch,label=Debian-Security',
'o=Debian,a=unstable']
pkgs that look like they should be upgraded: 
Error in function stop
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 240, in stop
apt_pkg.size_to_str(self.current_cps))).rstrip("\n"))
  File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 51, in _write
self._file.write("\r")
AttributeError: 'NoneType' object has no attribute 'write'
fetch.run() result: 0
...


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^linux-headers-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^.*-modules-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: 
"^linux-backports-modules-.*-4\.10\.14-200\.fc25\.x86_64$";
APT::NeverAutoRemove:: "^linux-tools-4\.10\.14-200\.fc25\.x86_64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma:

Bug#862435: [PATCH] debian: `Recommends: rsync` is outdated

[Alan Jenkins]

Git no longer supports rsync (2016 change).  Remove `Recommends: rsync`
from the `git` package.

See git commit 0d0bac67ce3b3f2301702573f6acc100798d7edd.

Also, it looks like git-archimport calls rsync.
git-archimport is split out into a separate package `git-arch`.
Add `Depends: rsync` to `git-arch`.

Signed-off-by: Alan Jenkins 
---
 debian/changelog | 8 
 debian/control   | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 76a88ff..483419f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+git (1:2.11.0-4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * git: remove Recommends: rsync (closes #862435)
+* git-arch: Depends: rsync
+
+ -- Alan Jenkins   Sat, 13 May 2017 
11:48:48 +0100
+
 git (1:2.11.0-3) unstable; urgency=high
 
   * Do not allow git helpers run via git-shell to launch a pager
diff --git a/debian/control b/debian/control
index eca6c87..81474d8 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,7 @@ Multi-Arch: foreign
 Depends: ${misc:Depends}, ${shlibs:Depends}, perl, liberror-perl,
  git-man (>> ${source:Upstream-Version}), git-man (<< 
${source:Upstream-Version}-.)
 Pre-Depends: ${misc:Pre-Depends}
-Recommends: patch, less, rsync, ssh-client
+Recommends: patch, less, ssh-client
 Suggests: gettext-base, git-daemon-run | git-daemon-sysvinit,
  git-doc, git-el, git-email, git-gui, gitk, gitweb,
  git-arch, git-cvs, git-mediawiki, git-svn
@@ -117,7 +117,7 @@ Description: fast, scalable, distributed revision control 
system (documentation)
 Package: git-arch
 Architecture: all
 Multi-Arch: foreign
-Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< 
${source:Upstream-Version}-.), tla
+Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< 
${source:Upstream-Version}-.), tla, rsync
 Suggests: git-doc
 Description: fast, scalable, distributed revision control system (arch 
interoperability)
  Git is popular version control system designed to handle very large
-- 
2.9.3

Bug#862435: git: Please fix 'Recommends: rsync'

[Alan Jenkins]

On 12/05/17 19:20, Jonathan Nieder wrote:

Hi Alan,

Alan Jenkins wrote:


The `git` package recommends the `rsync` package.
I'm sure this is wrong, because git no longer supports rsync (2016 change).

https://git.kernel.org/pub/scm/git/git.git/commit/?id=0d0bac67ce3b3f2301702573f6acc100798d7edd

I checked the upstream source.  There are references to rsync in git-archimport.
However, git-archimport is split out into a separate package `git-arch`.
The `git-arch` package should surely depend on (not just recommend) rsync,
I think that should be fixed at the same time.

Good catch.  Thank you.

Patches welcome.  I also notice that the URL mentioned in README.source
uses a self-signed certificate --- I better fix that, too.  You can get
the source at git://repo.or.cz/git/debian.git, branch debian-sid.

If you don't provide a patch, that's fine and I'll still fix it --- a
patch is just faster. :)

Thanks,
Jonathan


I don't think I've tried this before, I hope the debian/changelog entry 
I wrote makes sense.  (See previous email).


Thanks
Alan

Bug#855919: libwrap recommends tcpd

[Alan Jenkins]

On Thu, 23 Feb 2017 15:01:09 +0100 m...@linux.it (Marco d'Itri) wrote:
> On Feb 23, cgzones  wrote:
>
> > libwrap0 recommends tcpd and as recommend packages are by default
> > annexed, tcpd will be installed e.g. for the packages openssh-server
> > or auditd.
> > Could you consider to lower the bonding to suggests?
> I see no reason at all to keep even a Suggests at this point.

?

Complete removal sounds fine to me.

Alan

Bug#862435: git: Please fix 'Recommends: rsync'

[Alan Jenkins]

Package: git
Version: 1:2.11.0-3
Severity: normal

Hi maintainer!

The `git` package recommends the `rsync` package.
I'm sure this is wrong, because git no longer supports rsync (2016 change).

https://git.kernel.org/pub/scm/git/git.git/commit/?id=0d0bac67ce3b3f2301702573f6acc100798d7edd

I checked the upstream source.  There are references to rsync in git-archimport.
However, git-archimport is split out into a separate package `git-arch`.
The `git-arch` package should surely depend on (not just recommend) rsync,
I think that should be fixed at the same time.

https://github.com/git/git/search?utf8=%E2%9C%93&q=rsync&type=

Thanks
Alan

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armel
 (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git depends on:
ii  dpkg 1.18.23
ii  git-man  1:2.11.0-3
ii  libc62.24-10
ii  libcurl3-gnutls  7.52.1-5
ii  liberror-perl0.17024-1
ii  libexpat12.2.0-2
ii  libpcre3 2:8.39-3
ii  perl 5.24.1-2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages git recommends:
ii  less 481-2.1
ii  openssh-client [ssh-client]  1:7.4p1-10
ii  patch2.7.5-1+b2
ii  rsync3.1.2-2

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-2
pn  git-arch  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#815006: Renaming Iceweasel to Firefox

[Alan Jenkins]

On Sat, 20 Feb 2016 00:21:44 +0100 Moritz Muehlenhoff  
wrote:

> On Fri, Feb 19, 2016 at 09:46:59PM +0900, Mike Hommey wrote:
> > For clarity, do you mean you're fine with a iceweasel->firefox-esr
> > transition in stable(jessie) when we upgrade to 45? (which will be 
by 45.2,

> > at the beginning of June)
>
> It's likely a lot easier on your side if we do that, right?
>
> It might actually even also be simpler for us, since we wouldn't need 
to track two

> different source package names for several years.
>
> If the respective transition packages are in place, that seems acceptable
> to me (after all we had a in comparison more drastic UI change 
between ESR24

> and ESR31).

I found this thread while checking when I should expect weasel-ESR31 to 
go (and when to worry if it doesn't).


I'm fine with this idea in principle.  However, some users will be 
surprised by transitional packages _within_ a stable release. Upgrading 
to a transitional package does not happen when "apt-get upgrade" is used.


I _think_ it'll be ok for many people because PackageKit does 
"dist-upgrade".  PK may prompt about installing additional packages 
(which is sub-optimal, but about par for Debian on the desktop). 
Unfortunately there *are* some setups which will fail this.


---

It looks like `unattended-upgrades` uses `apt-get update`. 
`unattended-upgrades` does include modes designed for desktop systems.


[1] 
http://askubuntu.com/questions/251303/how-to-automatically-install-updates-before-shutdown


I get paranoid about this, because my experience is both Debian 7 and 8 
installs lack working update notifications.


[2] 
http://blog.tenstral.net/2015/09/update-notifications-in-debian-jessie.html


This means a) I notice some desktop QA problem, so I should try to 
contribute to it; b) some desktops which _do_ have working update 
notifications will have been randomly hacked until they seemed to work.  
E.g. using unattended-upgrades as per the first link above :(.


I don't have a suggestion, other than strongly recommend PK & making 
sure it's working.  Just sharing the pain that flared up again when 
reading your words :-P.  Fortunately Stretch fixes gnome update 
notifications, at least when I last tested.


---

There was eventually a recommended backport (apt-config-auto-update), as 
a good hack to make PK work (about as well as update-manager used to).  
So that would be fine for transitional packages.  Other users may have 
switched back to update-manager.  I _hope_ that's ok due to coming from 
Ubuntu, where they assume "dist-upgrade" is used e.g. to get kernel updates.


Synaptic is also installed by default, and does not `dist-update`. It 
does not provide a prompt, but it does warn.  Apparently the warning 
includes the package names, so it should be _relatively_ obvious.


It looks like "apt-get update" is also used by the example configuration 
for `cron-apt`.  (Whereas apticron looks to use dist-upgrade).  If 
either of these kick off while Firefox is running, Firefox will crash.  
(The Chrome people have a whole rant about this :D).  So I don't expect 
updates-from-cron to be too common on desktops.


Regards
Alan

Bug#812795: fakeroot opens a tcp socket which is open to the internet

[Alan Jenkins]

On 26/01/2016, Clint Adams  wrote:
> On Tue, Jan 26, 2016 at 04:43:58PM +0000, Alan Jenkins wrote:
>> Fix: replace htonl(INADDR_ANY) in fakerootd.c with htonl(INADDR_LOOPBACK).
>>  Not tested, but libfakeroot already connects to INADDR_LOOPBACK.  I'm not
>> aware of anything else this would break.
>
> I believe there were people connecting across VMs at one point,
> but I guess they can file a bug to request an option.

I think they must have already been patching communicate.c, to
connect() to a different address.  Or forwarding the port somehow.  So
I think that's very reasonable.


Dammit: I copied the suggested fix from my earlier email, but there's
a logic bug in it.  If port is not set explicitly with `--port`, that
change won't do anything.

  if (port > 0) {
memset((char *) &addr, 0, sizeof (addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(port);

if (bind(sd, (struct sockaddr *) &addr, sizeof (addr)) < 0)
  fail("bind");
  }

Fix: additionally, make the bind unconditional & then it will work
correctly.  The kernel understands "port 0" to mean "I don't care,
just pick one".  Still not tested, except for prototyping the system
calls from python.

Thanks again
Alan

Bug#812795: fakeroot opens a tcp socket which is open to the internet

[Alan Jenkins]

Package: fakeroot
Version: 1.20.2-1
Severity: normal

Dear Maintainer,

I noticed fakeroot-tcp binds a tcp socket to INADDR_ANY.  This seems worrying, 
even if we don't know about specific  vulnerabilities.  I haven't disclosed 
this observation elsewhere.

Triage: I'm not sure how predictable the port number is.  Many invocations of 
fakeroot will be short-lived.  So you would need to catch the right port at the 
right time.  The Debian fakeroot package uses fakeroot-sysv by default.

However I believe Debian is also acting as upstream, and other distributions 
(Fedora) do default to fakeroot-tcp.  Also fakeroot-tcp is necessary for 
multi-threaded programs (see the README).  fakeroot is sometimes used in 
package building...

I hope there aren't any major build servers compromised by this :(.

Fix: replace htonl(INADDR_ANY) in fakerootd.c with htonl(INADDR_LOOPBACK).  Not 
tested, but libfakeroot already connects to INADDR_LOOPBACK.  I'm not aware of 
anything else this would break.

Thanks to you all
Alan

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fakeroot depends on:
iu  libc62.19-18+deb8u2
ii  libfakeroot  1.20.2-1

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information

Bug#803177: apache2: [PATCH] secondary-init-script fails (status 3) despite starting apache daemon

[Alan Jenkins]

Package: apache2
Version: 2.4.10-10+deb8u3
Severity: normal

Dear Maintainer,

I set up a second instance of Apache using
`/usr/share/doc/apache2/examples/setup-instance`.
The init script starts apache sucessfully, but returns exit status 3.

It's probably an old bug, but now we have systemd we actually notice it.
Systemd treats this as a failed service which is pretty bad
(systemctl shows "degraded", and systemctl won't stop the daemon
if you ask it to).  More evidence below.

Debugging init scripts under systemd is awkward, but I noticed
secondary-init-script does "set -e".  Normally the primary script doesn't
run with "set -e" (which treats command errors as immediately fatal).

It seems clear we need to remove "set -e" from secondary-init-script.
I removed it and my problem was resolved.  Please apply :).

Thanks
Alan


# systemctl status apache2-syncthing
● apache2-syncthing.service - LSB: Start/stop apache2 web server (config 
/etc/apache2-syncthing)
   Loaded: loaded (/etc/init.d/apache2-syncthing)
   Active: failed (Result: exit-code) since Tue 2015-10-27 17:00:10 GMT; 6s ago
  Process: 29322 ExecStart=/etc/init.d/apache2-syncthing start (code=exited, 
status=3)

Oct 27 17:00:10 brick apache2-syncthing[29322]: Starting web server: 
apache2AH00558: apache2: Could not reliably determine the ser...message
Oct 27 17:00:10 brick systemd[1]: apache2-syncthing.service: control process 
exited, code=exited status=3
Oct 27 17:00:10 brick systemd[1]: Failed to start LSB: Start/stop apache2 web 
server (config /etc/apache2-syncthing).
Oct 27 17:00:10 brick systemd[1]: Unit apache2-syncthing.service entered failed 
state.

# ps -ax|grep apache
ps -ax|grep apache
 2949 ?Ss 0:00 /usr/sbin/apache2 -d /etc/apache2-syncthing -k start
 2950 ?S  0:00 /usr/sbin/apache2 -d /etc/apache2-syncthing -k start
 2951 ?S  0:00 /usr/sbin/apache2 -d /etc/apache2-syncthing -k start
 3038 pts/1S+ 0:00 grep apache
24023 ?Ss 0:00 /usr/sbin/apache2 -k start
24026 ?S  0:00 /usr/sbin/apache2 -k start
24028 ?S  0:13 /usr/sbin/apache2 -k start


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

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

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


-- Package-specific info:

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apache2 depends on:
ii  apache2-bin2.4.10-10+deb8u3
ii  apache2-data   2.4.10-10+deb8u3
ii  apache2-utils  2.4.10-10+deb8u3
ii  dpkg   1.17.25
ii  lsb-base   4.1+Debian13+nmu1
ii  mime-support   3.58
ii  perl   5.20.2-3+deb8u1
ii  procps 2:3.3.9-9

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.35

Versions of packages apache2 suggests:
ii  apache2-doc  2.4.10-10+deb8u3
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx-cur [www-browser]   2.8.9dev1-2+deb8u1
ii  w3m [www-browser]0.5.3-19

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.1-3
ii  libaprutil1  1.5.4-1
ii  libaprutil1-dbd-sqlite3  1.5.4-1
ii  libaprutil1-ldap 1.5.4-1
ii  libc62.19-18+deb8u1
ii  libldap-2.4-22.4.40+dfsg-1+deb8u1
ii  liblua5.1-0  5.1.5-7.1
ii  libpcre3 2:8.35-3.3
ii  libssl1.0.0  1.0.1k-3+deb8u1
ii  libxml2  2.9.1+dfsg1-5
ii  perl 5.20.2-3+deb8u1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages apache2-bin suggests:
ii  apache2-doc  2.4.10-10+deb8u3
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx-cur [www-browser]   2.8.9dev1-2+deb8u1
ii  w3m [www-browser]0.5.3-19

Versions of packages apache2 is related to:
ii  apache2  2.4.10-10+deb8u3
ii  apache2-bin  2.4.10-10+deb8u3

-- Configuration Files:
/etc/apache2/mods-available/mpm_prefork.conf changed:

StartServers 2
MinSpareServers   2
MaxSpareServers  4
MaxRequestWorkers 150
MaxConnectionsPerChild   0


/etc/apache2/ports.conf changed:

Listen 443


Listen 443



-- no debconf information

Bug#790943: [ssl-cert] Root and local certificate location clash

[Alan Jenkins]

On Fri, 03 Jul 2015 10:56:54 +0200 Daniel Pocock  wrote:
> Package: ssl-cert
> Version: 1.0.35

> This package provides the script /usr/sbin/make-ssl-cert
>
> It creates certificates and puts the public key / certificate PEM file
> in /etc/ssl/certs
>
> The ca-certificates package puts symlinks to CA certificates in the same
> location, /etc/ssl/certs
>
> Some other packages refer to /etc/ssl/certs as a directory of trusted
> roots.

> Some people suggest using /etc/ssl/ssl.crt or /etc/ssl/public for local
> certificate files.
>
> I did a Google search to try and find out of there is a policy about
> this directory and no results were found. So I can't say that this
> package is violating any specific policy or what should be done to fix
> it, but I do feel the status quo is troublesome.

+1.

/etc/ssl/certs is generated by ca-certificates, I don't think it should 
be modified by anyone else.  I found a weird bug/conflict as a result.


Debian Jessie provides this awesomely convenient setup for Apache. You 
can literally just enable SSL, and it uses the "snakeoil" (self-signed) 
certificate created by ssl-cert.  (Then Iceweasel/Firefox let you add 
the server cert when you visit).



I'm looking at trusting the snakeoil cert (to get secure Owncloud 
sync).  I tested curl from the server to itself - certificate error.  
But the snakeoil cert is already in /etc/ssl/certs, so how does this 
actually work[*]?  curl --cacert  works fine.  Let's 
poke around...


update-ca-certificates # no change

update-ca-certificates --fresh # now curl works! without specifying any 
options.



`update-ca-certificates --fresh` is only documented to remove any stale 
symlinks.  It shouldn't suddenly change the trust status of the default 
snakeoil!  It's not a massive security problem because the snakeoil 
isn't a CA cert.  But it's obviously unintended and surprising behavior.


You could argue it suggests sloppy coding in ca-certificates as well, 
but ssl-cert's behavior is just asking for trouble.



[*] The "standard", documented way is to copy certs to 
/usr/local/share/ca-certificates (huh?) and run update-ca-certificates.


> Should local certs go in some other directory,

+1

> or should other packages
> stop trusting everything in /etc/ssl/certs?

Btw I don't mind an extra step to trust local certs, so long as there's 
a documented method I can have confidence in.


Alan

Bug#678340: gnome-packagekit: gpk-update-viewer fails listing available updates

[Alan Jenkins]

On 18 May 2015 at 17:33, Alan Jenkins 
wrote:

>
> On 18 May 2015 at 09:43, Matthias Klumpp  wrote:
>
>> 2015-05-16 16:50 GMT+02:00 Alan Jenkins <
>> alan.christopher.jenk...@gmail.com>:
>> > [...]
>>
>> Right, I forgot that this was dropped from gpk-prefs.
>> Please open the dconf-editor (GUI editor for dconf) and navigate to the
>> /org/gnome/settings-daemon/plugins/updates section.
>> Is the "active" value set to "true"?
>>
>> Cheers,
>> Matthias
>>
>
> Ok, thanks for revised instructions :).
>
> That is indeed what it shows.  There's also a plausible value for a key
> called 'frequency-refresh-cache'.
>
>
> I attach a dconf-editor screenshot.  I'd use the `dconf` cli but for
> whatever reason it doesn't see the /plugins/ section.
>
> $ dconf list /org/gnome/settings-daemon/
> peripherals/
> $
>

Ful disclosure - I said this was a clean test VM.  The one quirk is I
migrated it from gnome Boxes to virt-manager, had to futz NetworkManager,
and then added a second network interface.

However I can't see any problems when I try
 - `nm-online && echo online`
 - installing packages from repos
 - web browsing

Bug#702241: gnome-packagekit: Update information is not refreshed

[Alan Jenkins]

On Fri, 7 Nov 2014 19:33:16 +0100 Matthias Klumpp  wrote:
>
> have to configure the Apt cronjob to do the updating for you (GNOME
> will do that on it's own, depending on the system's state (e.g.
> network availability, or if the system is running on battery power).
>

GNOME isn't refreshing the packagekit cache (syslog shows PackageKit 
'get-updates' but never a 'refresh').  You still have to configure 
Apt::Periodic::Update-Package-Lists manually (and hope your internet 
connection is available at the right time :), or you never see any 
updates in gnome.


I noticed the bug on Jessie stable - I think it was the same in Wheezy 
stable too.  I think people didn't see the bug when they upgraded 
earlier systems, because the old update-notifier configured 
Apt::Periodic and that got left over.


Alan


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

Bug#678340: gnome-packagekit: gpk-update-viewer fails listing available updates

[Alan Jenkins]

On Sun, 09 Jun 2013 16:58:41 +0200 =?utf-8?q?Andrzej_Zi=C4=99ba?= 
 wrote:

>
> When I run "pkcon refresh" the package cache is refreshed and the 
gpk-update-

> viewer shows all the available updates.
>
> So "pkcon refresh" is fine but is probably never used.


I agree, you can see it in the logs.  Debian's gnome runs 'get-updates' 
but never 'refresh':


# cd /var/log && zgrep "PackageKit" syslog syslog.*
syslog:May 16 10:42:10 debian-test PackageKit: get-updates transaction 
/113_eecabaaa from uid 1000 finished with success after 548ms

...

Whereas Fedora runs PackageKit refresh as intended:

# journalctl /usr/libexec/packagekitd
-- Reboot --
May 14 07:59:27 volcano.localdomain PackageKit[1486]: daemon start
May 14 08:00:37 volcano.localdomain PackageKit[1486]: uid 1000 is trying 
to obtain org.freedesktop.packagekit.system-sources-refresh auth (o
May 14 08:00:38 volcano.localdomain PackageKit[1486]: uid 1000 obtained 
auth for org.freedesktop.packagekit.system-sources-refresh
May 14 08:01:32 volcano.localdomain PackageKit[1486]: refresh-cache 
transaction /2330_cccdedbe from uid 1000 finished with success after 546
May 14 08:01:33 volcano.localdomain PackageKit[1486]: get-updates 
transaction /2331_ebccabab from uid 1000 finished with success after 270ms

-- Reboot --

Alan


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

Bug#413642: debian-installer-manual: After debootstrap, /dev is too minimal to mount partitions

[Alan Jenkins]

Hi

I think someone could close this bug now.  The installer manual does now 
outline the process of creating device nodes with MAKEDEV.


"D.3.4.1. Create device files" 
https://www.debian.org/releases/jessie/amd64/apds03.html.en#idp8293600


(It also suggests bind-mounting /dev instead, which is what I would try 
nowadays.)


Alan


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

Bug#783358: installation-reports: Debian 8 CD - "Graphical install" is not the default (installation guide says it should be)

[Alan Jenkins]

Package: installation-reports
Severity: normal

I've just installed debian-8.0.0-amd64-CD-1.iso in a virtual machine.
By default, the "Install" entry was selected.
But the install guide says the default should be "Graphical install".

So maybe the default needs changing on the CD.  I have _not_ tried the DVD,
but maybe that defaults to graphical and it's what the author checked.

Happy Debian release day!
Alan


-- Package-specific info:

Boot method: CD drive of virtual machine (GNOME Boxes)
Image version: debian-8.0.0-amd64-CD-1.iso
Date: Sun 26 Apr 2015

Machine: GNOME Boxes virtual machine host, from Fedora 21
Partitions:

$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda  8:00   20G  0 disk 
├─sda1   8:10 19.1G  0 part /
├─sda2   8:201K  0 part 
└─sda5   8:50  880M  0 part [SWAP]
sr0 11:01  627M  0 rom

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ O ]
Detect network card:[ O ]
Configure network:  [ O ]
Detect CD:  [ O ]
Load installer modules: [ O ]
Clock/timezone setup:   [ O ]
User/password setup:[ O ]
Detect hard drives: [ O ]
Partition hard drives:  [ O ]
Install base system:[ O ]
Install tasks:  [ O ]
Install boot loader:[ O ]
Overall install:[ O ]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="8 (jessie) - installer build 20150422"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian-test 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 
(2015-04-13) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC 
[Natoma] [8086:1237] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA 
[Natoma/Triton II] [8086:7000]
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE 
[Natoma/Triton II] [8086:7010]
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: ata_piix
lspci -knn: 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI 
[8086:7113] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Red Hat, Inc. QXL 
paravirtual graphic card [1b36:0100] (rev 04)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:03.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL-8100/8101L/8139 PCI Fast Ethernet Adapter [10ec:8139] (rev 20)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: 8139cp
lspci -knn: 00:04.0 Multimedia audio controller [0401]: Intel Corporation 
82801AA AC'97 Audio Controller [8086:2415] (rev 01)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: snd_intel8x0
lspci -knn: 00:05.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #1 [8086:2934] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:05.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #2 [8086:2935] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:05.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #3 [8086:2936] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:05.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:06.0 Communication controller [0780]: Red Hat, Inc Virtio 
console [1af4:1003]
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:0003]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: 00:07.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory 
balloon [1af4:1002]
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:0005]
lspci -knn: Kernel driver in use: virtio-pci
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 

Bug#757989: No update notifications - affects default GNOME desktop

[Alan Jenkins]

On 05/10/2014, Alan Jenkins  wrote:
> On 04/10/2014, Matthias Klumpp  wrote:
>> 2014-10-04 14:49 GMT+02:00 Alan Jenkins
>> :
>>> I'd like to make one point I don't see here.   This happens for me on
>>> GNOME; I'm not using LXDE or GNOME classic.  Since GNOME is the default
>>> desktop for Debian, this could easily hurt new Debian users (if it makes
>>> sense to talk about such a thing).

Sorry, I'm wrong.  I just had an update notification from g-p-k under GNOME.

(I clicked on the notification's update button and g-p-k is what
opened.  Not the old update-manager.  My g-s-d is still on the same
version.)

I'm continuing testing by subscribing to debian-security-announce,
purging update-notifier (which includes the anacron it sets up), and a
one-off 'apt-get clean'.  IOW I don't trust it yet.

.


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

Bug#757989: No update notifications - affects default GNOME desktop

[Alan Jenkins]

On 04/10/2014, Matthias Klumpp  wrote:
> 2014-10-04 14:49 GMT+02:00 Alan Jenkins
> :
>> I'd like to make one point I don't see here.   This happens for me on
>> GNOME; I'm not using LXDE or GNOME classic.  Since GNOME is the default
>> desktop for Debian, this could easily hurt new Debian users (if it makes
>> sense to talk about such a thing).
>>
>> For now I'm just installing update-notifier, which seems to work fine.
> Which version of gnome-settings-daemon do you currently have?

I'm running stable, and gsd is

3.4.2+git20121218.7c1322-3+deb7u3

Thanks for your time
Alan


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

Bug#757989: No update notifications - affects default GNOME desktop

[Alan Jenkins]

I'd like to make one point I don't see here.   This happens for me on
GNOME; I'm not using LXDE or GNOME classic.  Since GNOME is the default
desktop for Debian, this could easily hurt new Debian users (if it makes
sense to talk about such a thing).

For now I'm just installing update-notifier, which seems to work fine.

Thanks for your work Matthias (and to other reporters for documenting
this)
Alan


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

Bug#660861: Fwd: /lib/udev/net.agent: ifup on hotplug fail when using systemd

[Alan Jenkins]

On 22/02/12 13:05, Marco d'Itri wrote:

On Feb 22, Alan Jenkins  wrote:


(I'm surprised net.agent was in udev.dev;
  I'd have thought it would be owned by ifupdown).

Tell this to the ifupdown maintainer, if you can find one.


I don't have any solid criticism.  Just trying to anticipate the 
question "why was it reported against this package?"



There's a mismatch which stops this from working:

I do not use systemd, so I will wait for a tested patch from somebody
who does.


Thanks.

Technically I could qualify.  But that wouldn't answer my suspicions 
about /lib/systemd/system/ifup@.service...  I'd better find someone to 
talk to.


Alan



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

Bug#660861: Fwd: /lib/udev/net.agent: ifup on hotplug fail when using systemd

[Alan Jenkins]

Package: udev
Version: 175-3.1
Severity: normal

(I'm surprised net.agent was in udev.dev;
 I'd have thought it would be owned by ifupdown).

There's a mismatch which stops this from working:

net_ifup():
if [ -e /sys/fs/cgroup/systemd ]; then
  exec systemctl start ifup@${INTERFACE}.service
else
  exec ifup --allow=hotplug $INTERFACE
fi

net_ifdown():
exec ifdown --allow=hotplug $INTERFACE


  i) I applied the obvious fix and it seems to help.


 ii) There's some other bug with shutting down wpa_supplicant,
 which sometimes causes it to fail (I'm using wireless).


iii) More importantly, the obvious fix may be the wrong one.

 I'm concerned that there's a big UI fail here for "normal users".
 When systemd starts the interface, it means
 you shouldn't use "ifdown wlan0" -
 you should use "systemctl stop ifup@wlan0.service".

 Otherwise systemd and ifup get out of sync,
 which is what's causing the problem here.

 It suggests a flaw in the way ifupdown is being used under systemd.

 Consider how LSB scripts are handled.
 "/etc/init.d/ifupdown restart" is actually rediected to systemctl,
 thanks to magic in /lib/lsb/init-functions.

 Could ifup do the same?
 Somehow, it would need to detect whether it's being run directly from
 the ifup@.service file or not...


== Steps to reproduce: ==

  0. Install the systemd package.

systemd is a replacement init system.
Make sure you know how to recover, IN CASE IT BREAKS YOUR DEBIAN.


  1. Configure a working wired network iterface using ifupdown.

(I'm actually using wireless, but then you have to deal with the encryption).

By default, NetworkManager overrides it.
You can probably just remove "#NetworkManager#"
from the start of the line in /etc/network/interfaces.
It will then look something like

iface eth0 inet dhcp

Make sure there's an "allow-hotplug eth0" line for it as well
(it should already be there).

NetworkManager will no longer manage your network interface.
ifupdown will manage it instead.


  2. Reboot (after making sure your ethernet cable is plugged in)

== Expected behaviour: networking still works ==
The network interface is configured on startup by ifupdown,
and you should have working internet access.

You can check ifupdown is being used by running "ifdown eth0; ifup eth0".
ifdown only works when the interface is being managed with ifup.


  3. Hot-remove and re-add the network interface
(the device, not the cable).

I use an ASUS EeePC 701 which has unusual hotpluggable wifi.

Probably the eaiest way to emulate this is
"rmmod atl2; modprobe atl2", where "atl2" is the name of
the driver for your network interface.


== Expected behaviour: working hotplug ==

 - when removed, udev rules run "ifdown eth0" to clean up.
 - when added, udev rules run "ifup eth0" to configure it.

== Actual behaviour: hotplug doesn't work ==

When systemd is installed, the "ifup" is done through a systemd
service.  You can see this with "systemctl status ifup@eth0.service",
and it's pretty cool.

But the "ifdown" isn't done through systemd :(.
That means systemd doesn't see the removal event.
As far as it's concerned, the service is still active.

When the interface is re-added, systemd is asked to start
the corresponding service.  But the service is already
active, so there's nothing for it to do.

The interface is left un-configured.

-- Extra package info:

ii  ifupdown   0.7~beta2  high level tools to configure network interf
 (which is an upgrade from experimental, in case that fixed it)

ii  systemd37-1   system and service manager


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages udev depends on:
ii  debconf [debconf-2.0]  1.5.41
ii  libc6  2.13-26
ii  libselinux12.1.0-4.1
ii  libudev0   175-3.1
ii  lsb-base   3.2-28.1
ii  util-linux 2.20.1-1.2

Versions of packages udev recommends:
ii  pciutils  1:3.1.8-2
ii  usbutils  1:005-2

udev suggests no packages.

-- debconf information:
  udev/new_kernel_needed: false
  udev/title/upgrade:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:




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

Bug#563254: du: bind mount causes corrupted filesystem warning (despite -x !)

[Alan Jenkins]

Jim Meyering wrote:

Alan Jenkins wrote:
  

Package: coreutils
Version: 8.1-1
Severity: normal


To reproduce:

$ mkdir -p /mnt/root
$ mount --bind / /mnt/root

(I have this in /etc/fstab...
 it lets me access parts of / which are hidden by other mounted filesystems -
 this happens to be useful for reasons too long and obscure to be worth 
explaining)

$ du -x
du: WARNING: Circular directory structure.
This almost certainly means that you have a corrupted file system.
NOTIFY YOUR SYSTEM MANAGER.
The following directory is part of the cycle:
  `./mnt/root'




Thanks for the report.
I confirm that this still happens with the latest.

For now, I suggest you use e.g.,

du --exclude=/mnt -x /

Unless such bind mounts appear to be common,
I may just leave the current semantics as they are.

By the way, would you want du to traverse each
root partition directory twice?
  


No.  I was thinking that -x would treat bind mounts like other mounts, 
and not traverse them.


I guess the problem is that -x is taken to mean "stay on this 
_filesystem_ only", as opposed to "stay on this _mount_ only".


And "stay on this filesystem" is probably easier to implement; you just 
check st_dev.  "Stay on this mount" requires checking /etc/mtab or 
/proc/mounts.


It doesn't seem too hard to add an extra check before printing the 
warning.  But I agree this is probably obscure, so I don't blame you for 
not being very bothered about it :-).


Thanks
Alan



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

Bug#563254: du: bind mount causes corrupted filesystem warning (despite -x !)

[Alan Jenkins]

Package: coreutils
Version: 8.1-1
Severity: normal


To reproduce:

$ mkdir -p /mnt/root
$ mount --bind / /mnt/root

(I have this in /etc/fstab...
 it lets me access parts of / which are hidden by other mounted filesystems - 
 this happens to be useful for reasons too long and obscure to be worth 
explaining)

$ du -x
du: WARNING: Circular directory structure.
This almost certainly means that you have a corrupted file system.
NOTIFY YOUR SYSTEM MANAGER.
The following directory is part of the cycle:
  `./mnt/root'



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

Kernel: Linux 2.6.33-rc1eeepc-test3 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages coreutils depends on:
ii  libacl1   2.2.49-1   Access control list shared library
ii  libattr1  1:2.4.44-1 Extended attribute shared library
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libselinux1   2.0.89-4   SELinux runtime shared libraries

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information



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

Bug#559578: [Debian-eeepc-devel] Bug#559578: 702 also

[Alan Jenkins]

On 12/15/09, jida...@jidanni.org  wrote:
> By the way, I was using a 702 "8G", not a 701.

Right, someone did report that.  You might check what this command says:

cat /sys/class/dmi/id/product_name

The kernel patch I submitted will check for a product name of either
"701" or "702".

Thanks
Alan



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

Bug#559578: eeepc-acpi-scripts: EeePC 701 freezes with garbled screen while booting

[Alan Jenkins]

On 12/9/09, Corentin Chary  wrote:
> On Wed, Dec 9, 2009 at 12:54 PM, Alan Jenkins
>  wrote:
>> Hi Corentin
>>
>> It looks like it's not just my 701 which has problems with SHE.  Given
>> that Asus don't support it on the pre-installed OS, I think we should
>> disable it for the 701.
>>
>> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578>.
>>
>> Thanks
>> Alan
>>
>
> But if I remember correctly, it worked fine on my 701 (only two modes,
> but no freeze).
> To trigger the bug, I have to "echo 0 >/sys/devices/platform/eeepc/cpufv" ?

Reportedly 
<http://groups.google.com/group/linux.debian.bugs.dist/msg/9805f22bc6b8bbda>.

Another report says it happens only when booting in "single user
mode", and not every time.

I can't reproduce it myself, even though it's happened to me in the
past, both from writing to that file manually, and from the default
configuration of eeepc-acpi-scripts.

I _can_ still reproduce the strange hissing noise in "performance" mode.

If I repeatedly plug and unplug the power adaptor with
eeepc-acpi-scripts installed  (triggering the switch between
"performance" and "normal"), I see various kernel messages.  These are
the kernel init messages for the webcam and cardreader, suggesting
that they are disappearing and re-appearing.  I wasn't able to
reproduce it without eeepc-acpi-scripts (either by plugging /
unplugging repeatedly, or by toggling the value of cpufv in a scripted
loop, or by both at the same time).

> I don't have my 701 right now, so I can't test, is there anything in
> dmesg or is it only a bad hardware freeze ?

Apparently it's just a freeze:

"Indeed it sounds like 559578, and before proceeding further, though
garbled, I have compared the blurred lines to a regular boot, and it
turns out the final words before freezing are:

Wed Dec  9 09:34:02 2009: Loading EeePC support modules...done.
Wed Dec  9 09:34:02 2009: Setting super hybrid engine according to
configuration...(AC)...done."

<http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/d3f0716684bbadd8>


> Anyway, if we disable it for 701, how can we detect that this is a 701
> ? using dmi matching ? when only 2 modes are available ?
> Thanks,

I would use a DMI match (product name "701").  Hopefully that is
distinct from the 701SD, which is marketed with SHE.  I know the
"900A" has a distinct product name, so it seems likely.

Thanks
Alan



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

Bug#559578: [Debian-eeepc-devel] Bug#559578: Fwd: Bug#559578: eeepc-acpi-scripts: EeePC 701 freezes with garbled screen while booting

[Alan Jenkins]

On 12/9/09, Ben Armstrong  wrote:
> On Wed, 9 Dec 2009 11:54:54 +
> Alan Jenkins  wrote:
>
>> Hi Corentin
>>
>> It looks like it's not just my 701 which has problems with SHE.  Given
>> that Asus don't support it on the pre-installed OS, I think we should
>> disable it for the 701.
>>
>> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578>.
>
> If by "we", you mean Debian, and by "disable" you mean disable by
> default, then I agree.  However, I don't believe it should be disabled
> upstream.  I have used SHE successfully on the 4G for several weeks.
> Although SHE became suspect when I experienced some lockups, after
> running for a few days with SHE disabled, I still get occasional
> lockups, so I don't no longer think SHE is the cause.  Users ought to
> be given the option of re-enabling it on the 4G, but be given an
> appropriate caution about lack of vendor support for this configuration.
>
> Ben

I think the kernel should disable SHE by default on the 701 models.  I
don't mind if it provides a "force_cpufv" option with an appropriate
warning.

The 701 models aren't shipped with any way to control the SHE.  It is
a form of overclocking which is not supported by the vendor.  On the
other models, SHE is a marketed feature which users will expect to
work reliably.  We should treat these cases differently in the kernel.

I don't think it should be left to userspace to get this right.  There
are other distributions than debian :-).  I've seen at least one
desktop applet which controls SHE.  I expect it has a similar option
to toggle SHE automatically when switching between mains and battery
power.  If we change the kernel, it will affect everyone.

The ABI doc for eeepc-laptop doesn't say "writing to cpufv may break",
so we need _some_ change to the kernel sources :).  I think it's
better to "fix" this in the code and not just add disclaimers in the
documentation.

Alan



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

Bug#559578: Fwd: Bug#559578: eeepc-acpi-scripts: EeePC 701 freezes with garbled screen while booting

[Alan Jenkins]

Hi Corentin

It looks like it's not just my 701 which has problems with SHE.  Given
that Asus don't support it on the pre-installed OS, I think we should
disable it for the 701.

.

Thanks
Alan



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

Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

[Alan Jenkins]

On 10/20/09, Marco d'Itri  wrote:
> On Oct 20, Torsten Crass  wrote:
>
 read(7, "", 128)= 0
 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6,
 events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5,
 3000)  = 1 ([{fd=7, revents=POLLIN}])
> So for some reason the signalfd(2) fd keeps returning nothing (which is
> an error) with your self-compiled 2.6.22.20071006 kernel.
> 2.6.22 is supposed to work, so I will keep this bug open to see if
> anybody else is affected.
>
> I see that udevd, unlike the example in the man page, is quite
> permissive in checking the results of the read.
> Maybe if read(2) returns zero it should just fail.
>
> size = read(pfd[FD_SIGNAL].fd, &fdsi, sizeof(struct signalfd_siginfo));
> if (size == sizeof(struct signalfd_siginfo))
> handle_signal(udev, fdsi.ssi_signo);
>

Sounds good to me.  A zero return from read should always mean EOF.
Whatever this means for a signalfd, it's not "ignore this result and
try again".  The manpage seems to exclude it anyway.

"If  none  of  the  signals  in mask is pending for the process, then
the read(2) either blocks  until one of the signals in mask is
generated for the process, or fails with the error  EAGAIN if the file
descriptor has been made non-blocking."

Alan



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

Bug#550119: [Debian-eeepc-devel] Bug#550119: eeepc-acpi-scripts: softkeys & power buttons do not work

[Alan Jenkins]

On 10/7/09, Voker57  wrote:
> Subject: eeepc-acpi-scripts: softkeys & power buttons do not work
> Package: eeepc-acpi-scripts
> Version: 1.1.2
> Severity: important
>
> After I reinstalled Debian from eeepc installer and upgraded it to
> Sid
> (partially), my softbuttons, power switch and lid sensor do not work
> anymore. However, Fn+F1..9 buttons like wifi toggle, sound control
> still work OK.

How odd.  It sounds like a kernel issue.  I'm puzzled since I thought
the "softbuttons" would use the exact same driver and notification
mechanism as the Fn+F1..9 keys.

Which kernel version are you using?  Do you still have an original
working kernel, and if so what version is it?

What does "dmesg" say, any interesting errors?  Did the ACPI "button"
module fail to load?

Does acpi_listen show anything when you press the soft buttons, press
the power button, or open and close the lid?  Or does it only show
anything for the working keys Fn+F1..F9 keys?

Regards
Alan



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

Bug#543326: xserver-xorg-video-intel: [Intel 965] X crashes on logout from KDE

[Alan Jenkins]

I upgraded to 2:2.9.0-1 and it still crashes on logout, but with a 
different backtrace.  I'll report it as a new bug.


Thanks!
Alan




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

Bug#540004: synaptic: Crashes with segmentation fault when keying in letters of package name (jump to).

[Alan Jenkins]

I have this same problem.  The bug with the patch seems to be 541359.  
There's no patch on bug 541736.


And here is a list of the duplicate reports :-).


"Synaptic segfaults on selection of package with Enhances"


"synaptic: Segfault on row selection - Debian Bug report logs"


"[synaptic] Frequent Segfaults, Usually on Selecting Package - Debian 
Bug report logs"



"synaptic: Synaptic crashes when searching packages - Debian Bug report 
logs"



"synaptic: Synaptic crashes randomly when a package is selected to view 
its description - Debian Bug report logs"



"synaptic crash selecting any package and press down cursor-arrow-down - 
Debian Bug report logs"



"synaptic: crash (segmentation fault) when selecting package 'dirmngr' - 
Debian Bug report logs"



"synaptic: random segmentation faults - Debian Bug report logs"




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

Bug#543326: xserver-xorg-video-intel: [Intel 965] X crashes on logout from KDE

[Alan Jenkins]

Julien Cristau wrote:

On Mon, Aug 24, 2009 at 09:24:08 +0100, Alan Jenkins wrote:

  

Package: xserver-xorg-video-intel
Version: 2:2.8.0-2
Severity: important


This seems to happen every time.  The system is a fresh "unstable" install.
The KDE settings are as per default - which means "desktop effects" are
enabled using openGL.



Known upstream bug.  Configure kdm to terminate the server on logout
instead of using the default regen.

Cheers,
Julien
  


Yup, that fixes it.  Thanks
Alan



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

Bug#522319: assumes swapfiles are directly accessible

[Alan Jenkins]

> /var/swap is there but uswsusp runs from inside a chroot. It shouldn't
> assume swap is going to be directly accessible when it is a file (for a
> dev I guess it's fine since /dev has to be bind-mounted anyway).
>
> S'està configurant uswsusp (0.8-1.1+b1) ...
> stat: ha fallat stat() sobre /var/swap: El fitxer o directori no existeix
> dpkg: s'ha produït un error en processar uswsusp (--configure):
> el subprocés post-installation script retornà el codi d'eixida d'error 1
> S'han trobat errors en processar:
> uswsusp

Do you have any more specific suggestions as to how this would work, or 
a pointer on why this is a grave issue?


It seems reasonable to expect that the swapfile can be accessed as 
listed in /etc/fstab.  The problem isn't really unique to uswsusp; e.g. 
"swapoff -a; swapon -a" isn't going to work either.


You already have to do a bit of namespace manipulation and careful 
thinking.  You can bind mount individual files.  What's wrong with 
adding /var/swap to the list of things you have to bind-mount?


Regards
Alan

Bug#543326: xserver-xorg-video-intel: [Intel 965] X crashes on logout from KDE

[Alan Jenkins]

Alan Jenkins wrote:

Package: xserver-xorg-video-intel
Version: 2:2.8.0-2
Severity: important


This seems to happen every time.  The system is a fresh "unstable" install.
The KDE settings are as per default - which means "desktop effects" are
enabled using openGL.

I have captured a full backtrace (see attachment).

-- Package-specific info:
  



Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:
  


And here's the logfile with the crash (attached).

Regards
Alan




Xorg.0.log.old
Description: application/trash

Bug#543326: xserver-xorg-video-intel: [Intel 965] X crashes on logout from KDE

[Alan Jenkins]

Package: xserver-xorg-video-intel
Version: 2:2.8.0-2
Severity: important


This seems to happen every time.  The system is a fresh "unstable" install.
The KDE settings are as per default - which means "desktop effects" are
enabled using openGL.

I have captured a full backtrace (see attachment).

-- Package-specific info:
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 2009-08-23 16:08 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1689976 2009-08-06 17:55 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
00:02.0 VGA compatible controller: Intel Corporation 82946GZ/GL Integrated 
Graphics Controller (rev 02)

/etc/X11/xorg.conf does not exist.

Xorg X server log files on system:
-rw-r--r-- 1 root root 38812 2009-08-24 09:08 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.30.4-dsa-ia32 i686 Debian
Current Operating System: Linux alan-desktop-sid 2.6.30-1-686 #1 SMP Sat Aug 15 
19:11:58 UTC 2009 i686
Build Date: 06 August 2009  04:49:57PM
xorg-server 2:1.6.3-1+b1 (bui...@murphy.debian.org) 
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 24 09:08:32 2009
(II) Loader magic: 0x6c0
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 5.0
X.Org XInput driver : 4.0
X.Org Server Extension : 2.0
(II) Loader running on linux
(++) using VT number 7

(--) PCI:*(0:0:2:0) 8086:2972:105b:0cc5 Intel Corporation 82946GZ/GL Integrated 
Graphics Controller rev 2, Mem @ 0xfda0/1048576, 0xd000/268435456, I/O 
@ 0xff00/8
(==) Using default built-in configuration (39 lines)
(==) --- Start of built-in configuration ---
Section "Device"
Identifier  "Builtin Default intel Device 0"
Driver  "intel"
EndSection
Section "Screen"
Identifier  "Builtin Default intel Screen 0"
Device  "Builtin Default intel Device 0"
EndSection
Section "Device"
Identifier  "Builtin Default i810 Device 0"
Driver  "i810"
EndSection
Section "Screen"
Identifier  "Builtin Default i810 Screen 0"
Device  "Builtin Default i810 Device 0"
EndSection
Section "Device"
Identifier  "Builtin Default vesa Device 0"
Driver  "vesa"
EndSection
Section "Screen"
Identifier  "Builtin Default vesa Screen 0"
Device  "Builtin Default vesa Device 0"
EndSection
Section "Device"
Identifier  "Builtin Default fbdev Device 0"
Driver  "fbdev"
EndSection
Section "Screen"
Identifier  "Builtin Default fbdev Screen 0"
Device  "Builtin Default fbdev Device 0"
EndSection
Section "ServerLayout"
Identifier  "Builtin Default Layout"
Screen  "Builtin Default intel Screen 0"
Screen  "Builtin Default i810 Screen 0"
Screen  "Builtin Default vesa Screen 0"
Screen  "Builtin Default fbdev Screen 0"
EndSection
(==) --- End of built-in configuration ---
(==) ServerLayout "Builtin Default Layout"
(**) |-->Screen "Builtin Default intel Screen 0" (0)
(**) |   |-->Monitor ""
(**) |   |-->Device "Builtin Default intel Device 0"
(==) No monitor specified for screen "Builtin Default intel Screen 0".
Using a default monitor configuration.
(**) |-->Screen "Builtin Default i810 Screen 0" (1)
(**) |   |-->Monitor ""
(**) |   |-->Device "Builtin Default i810 Device 0"
(==) No monitor specified for screen "Builtin Default i810 Screen 0".
Using a default monitor configuration.
(**) |-->Screen "Builtin Default vesa Screen 0" (2)
(**) |   |-->Monitor ""
(**) |   |-->Device "Builtin Default vesa Device 0"
(==) No monitor specified for screen "Builtin Default vesa Screen 0".
Using a default monitor configuration.
(**) |-->Screen "Builtin Default fbdev Screen 0" (3)
(**) |   |-->Monitor ""
(**) |   |-->Device "Builtin Default fbdev Device 0"
(==) No monitor specified for screen "Builtin Default fbdev Screen 0".
Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory "/usr/share/fonts/X11/misc" does not exist.
Entry deleted from font path.
(WW) The d

Bug#515996: locales: Locale not supported by C library

[Alan Jenkins]

I think I've experienced the same bug.  It happened after an upgrade to 
unstable.  As with the OP, it fixed itself after reinstalling locales 
and localepurge.


platform: i386 (eeepc)
localepurge: 0.5.9-0.2
locales: 2.9-4

I've copied+pasted the error messages.  Maybe this will help :).

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_GB.UTF-8
...

$ strace -f locale 2>&1| grep ENOENT
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/usr/lib/locale/en_GB.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/locale/en_GB.utf8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/locale/en_GB/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/locale/en.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/locale/en.utf8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/locale/en/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file 
or directory)


$ ls /usr/lib/locale/
locale-archive

After reinstalling, /usr/lib/locale looks the same, but "locale" stops 
complaining about nonexistent files.


I first noticed it when installing additional packages, like so:

$ sudo aptitude install reportbug
...
Get:1 http://www.mirrorservice.org lenny/main reportbug 3.48 [159kB]
Fetched 159kB in 5s (30.0kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = (unset),
   LANG = "en_GB.UTF-8"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = (unset),
   LANG = "en_GB.UTF-8"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = (unset),
   LANG = "en_GB.UTF-8"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = (unset),
   LANG = "en_GB.UTF-8"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = (unset),
   LANG = "en_GB.UTF-8"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
[master]: created 6603b42: "saving uncommitted changes in /etc prior to 
apt run"

1 files changed, 1 insertions(+), 1 deletions(-)
Traceback (most recent call last):
 File "/usr/bin/apt-listchanges", line 33, in 
   from ALChacks import *
 File "/usr/share/apt-listchanges/ALChacks.py", line 32, in 
   sys.stderr.write(_("Can't set locale; make sure $LC_* and $LANG are 
correct!\n"))

NameError: name '_' is not defined
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = (unset),
   LANG = "en_GB.UTF-8"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Selecting previously deselected package reportbug.
...



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

Bug#515739: [PATCH] "dpkg-reconfigure uswsusp" doesn't recognize swapfiles as valid

[Alan Jenkins]

Package: uswsusp
Version: 0.8-1.1

If I reconfigure uswsusp while using a swap file (as opposed to a swap
partition), it warns me that my swap file is not valid.  But it is
valid; it works both for swap and hibernation.

---
Fix "dpkg-reconfigure uswsusp" to recognise swap files as valid

My swap file is on device 0802, but "stat -c '%D' /swapfile" gives "802".
I.e. the leading zero is omitted.  Fix devid to match.

diff --git a/debian/uswsusp.config b/debian/uswsusp.config
index 68b9783..35a309a 100644
--- a/debian/uswsusp.config
+++ b/debian/uswsusp.config
@@ -97,7 +97,7 @@ elif [ -n "$USEROFFSET" ] && [ -x /usr/sbin/swap-offset ]; 
then
 # was removed before, leaving the config file. Now we don't
 # have a way to check the offset. Best is to ask if this is OK
 
-devid=`printf "%02x%02x" $(stat -c "0x%t 0x%T" $USERSWAP 2> /dev/null)`
+devid=`printf "%x%02x" $(stat -c "0x%t 0x%T" $USERSWAP 2> /dev/null)`
 
 while read name type rest; do
[ "$type" == "file" ]  || continue;







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

Bug#500138: multi-threaded processes get bogus (negative?!) strace -T / -c values

[Alan Jenkins]

Package: strace
Version: 4.5.14-2

strace -T shows the time spent in each syscall.  Looking at the source, 
it records the syscall entry time in tcp->etime, and then calculates the 
duration on syscall exit.


This clearly fails for multithreaded processes.  To get accurate 
results, there ought to be a separate "etime" for each thread of the 
process.  I'm guessing it's just not possible to fork a new strace 
instance for each thread :-).


I found this bug after running strace on udevd, with an unpublished 
patch to use a thread for each event.  It's not obvious why the time 
goes negative though.  Perhaps there's another error I missed.


$ sudo strace -qc udevd & sudo udevtrigger; sudo udevsettle; sudo killall udevd
[1] 4937
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 7.330.821332  205333 4   getdents
 7.250.811993   3866621   mremap
 6.290.705333  705333 1   execve
 6.290.705333  705333 1   chdir
 6.290.705333  705333 1   umask
 6.290.705333  705333 1   setsid
 6.290.705333  705333 1   setpriority
 6.290.705333  705333 1   uname
 6.290.705333  705333 1   rt_sigprocmask
 6.290.705333  705333 1   getrlimit
 6.290.705333  705333 1   getuid32
 6.290.705333  705333 1   set_thread_area
 6.290.705333  705333 1   set_tid_address
 6.290.705333  705333 1   inotify_init
 6.290.705333  705333 1   set_robust_list
 6.290.705333  705333 1   send
 5.740.642664   80333 8 8 access
 5.740.642664   80333 8   socket
 4.620.517142 670   772   _llseek
 4.140.463996   3866612   fcntl64
 3.660.410666  205333 2   pipe
 3.660.410666  205333 2   bind
 3.660.410666  205333 2   setsockopt
 3.660.409705 946   433   fstat64
 2.070.231998   38666 6   rt_sigaction
 2.070.231998   38666 6 5 connect
 1.040.115999   38666 3   dup2
 1.040.115999   38666 3 1 inotify_add_watch
 7.76   -1.18692222031   428   munmap
 4.70   -1.1526656   2106625 5 sigreturn
 3.50   -1.13919243379   116   read
 2.99   -1.1334703   37189 9   brk
 1.33   -1.1149311649223   mkdir
 1.32   -1.1147927 224   659   mmap2
 1.11   -1.1124873219157   futex
-2.84   -1.681908   -1472   216   mprotect
-2.12   -2.1762887-277   852 3 open
-2.66   -2.1701830-691   431 1 select
-4.03   -2.1547986-963   46923 stat64
-4.93   -2.1447442   -1340   412   362 unlink
-5.22   -2.1414563   -1420   412   recv
-5.26   -2.1410899   -1429   412 1 symlink
-5.26   -2.1410589   -1430   412   412 rmdir
-5.77   -2.1352966-751   860   close
-8.07   -2.1095702   -2189   413   time
-9.16   -2.973253   -2485   413 1 clone
-11.17   -2.748609   -2837   441   write
-- --- --- - - 
100.00   11.205400  8356   822 total





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#474691: Can't resume from swap file hibernation (as opposed to partition)

[Alan Jenkins]

Package: initramfs-tools
Version: 0.91e
Severity: wishlist
Tags: patch

To resume from a swap file within a partition using the original swsusp, 
you find the block offset of the swap file header using e.g. swap-offset 
from the uswsusp package, and add "resume=" and 
"resume_offset=" parameters to the kernel command-line. 
Unfortunately this parameter is not recognised by the initramfs scripts 
(so it would only work if you booted without an initramfs).


diff --git a/resume b/resume
index d997f81..8a41f83 100755
--- a/resume
+++ b/resume
@@ -34,5 +34,5 @@ fi

if [ -e /sys/power/resume ]; then
   # hardcode path, uswsusp ships an resume binary too
-   /bin/resume ${resume}
+   /bin/resume ${resume} ${resume_offset}
fi




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#473217: Wishlist: Don't run ckbcomp at boot-time (use a saved keymap instead)

[Alan Jenkins]

Package: console-setup
Version: 1.16
Severity: wishlist

The setupcon command, as run by console-setup during boot, runs ckbcomp 
to generate a console keymap from the X keymap files.  This can take on 
the order of half a second CPU time.


setupcon already saves the resulting keymap in 
/etc/console-setup/boottime.kmap.gz, and has support for using that 
instead.  However this is only used when /usr is not mounted.  I'm not 
interested in repartitioning my system to use this feature.


My wish is that this method would be used even when /usr is mounted.  It 
may require some documentation but I think it's sane enough.


It looks like Ubuntu (my primary OS), have altered the console-setup 
init script to regenerate the keymap if run manually (i.e. not by init):


# Are we running from init?
run_by_init()
{
   ([ "$previous" ] && [ "$runlevel" ]) || [ "$runlevel" = S ]
}

...
elif ! run_by_init; then
log_action_begin_msg "Saving console font and keymap for next boot"
if setupcon --save-only; then
log_action_end_msg 0
else
log_action_end_msg $?
fi
fi

So if you edit /etc/default/console-setup manually, you then need to run 
"/etc/init.d/console-setup restart" to apply the changes and regenerate 
the keymap.  This happens automatically when dpkg-reconfigure is used.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]