Bug#971545: cloud.debian.org: Provide AMI image ID that is always recent

[Adam Bolte]

On 2/10/20 3:55 am, Ross Vandegrift wrote:
> On Thu, Oct 01, 2020 at 05:16:36PM +0200, tkoeck wrote:
>> is there an AMI image ID that is always the recent one?
> 
> Instead of hardcoding an AMI somewhere, you can search to find the
> current release.  With awscli, try something like this:
> $ aws ec2 describe-images \
>   --output text \
>   --owners 136693071363 \
>   --filters Name=name,Values="debian-10-amd64-*" \
>   --query 'Images[].[Name,ImageId]' \
>   | sort -rn \
>   | head -n 1 \
>   | awk '{print $2}'


There's a small tool I wrote earlier in the year to address the problem
of quickly finding the latest AMI for a given type. It is now hosted here:

https://github.com/sitepoint/amifinder

eg. running something like:

amifinder --name 'debian-10-amd64-*' 136693071363

in the us-west-2 region would give you:

Name: debian-10-amd64-20200928-407
Architecture: x86_64
CreationDate: 2020-09-28T23:58:51.000Z
ImageId: ami-06d8a32aedc6986f5
ImageLocation: 136693071363/debian-10-amd64-20200928-407
ImageType: machine
Public: True
OwnerId: 136693071363
State: available
  DeviceName: /dev/xvda
DeleteOnTermination: True
SnapshotId: snap-01eca3d280b2d9f69
VolumeSize: 8
VolumeType: gp2
Encrypted: False
Description: Debian 10 (20200928-407)
EnaSupport: True
Hypervisor: xen
RootDeviceName: /dev/xvda
RootDeviceType: ebs
SriovNetSupport: simple
VirtualizationType: hvm

I feel it makes things a fair bit easier.

Cheers,
Adam



signature.asc
Description: OpenPGP digital signature

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

[Adam Bolte]

Package: command-not-found
Version: 18.04.5-1
Followup-For: Bug #916783
Tags: patch

This patch seems to be working for me:

--- a/CommandNotFound/db/creator.py
+++ b/CommandNotFound/db/creator.py
@@ -88,6 +88,7 @@ class DbCreator:
 "%s does not require an update (inputs unchanged)", dbname)
 return
 tmpdb = dbname+".tmp"
+oldmask = os.umask(0o022)
 with sqlite3.connect(tmpdb) as con:
 con.executescript(create_db_sql)
 self._fill_commands(con)
@@ -98,6 +99,7 @@ class DbCreator:
 # add new metadata
 with open(metadata_file, "w") as fp:
 json.dump(self._calc_input_metadata(), fp)
+os.umask(oldmask)
 def _db_update_needed(self, metadata_file):
 if not os.path.exists(metadata_file):
 return True

I'm not sure if it's the correct way to solve this.

Regards,
Adam


signature.asc
Description: PGP signature

Bug#704089: tzdata config script prevents non-interactive (re)configuration

[Adam Bolte]

On Wed, Jan 16, 2019 at 11:43:57AM +0100, Aurelien Jarno wrote:
> I don't think the patch is correct. Debconf is not a registry, the
> canonical location for the configuration is the configuration files, not
> the debconf database. Quoting debconf-devel(7):
> 
> "The issue to watch out for here is that debconf is not intended to be,
> and must not be used as a registry."
> 
> I think it also applies when DEBCONF_RECONFIGURE is set.

That's interesting, but also very confusing. If your assumption is
correct, what is the point of being able to run dpkg-reconfigure in
non-interactive mode?

You can only reconfigure a package that is already installed, so (as I
understand it) if the debconf registry is supposed to be clobbered by
whatever the actual system configuration is before use, that would
mean `dpkg-reconfigure -fnoninteractive ` is a completely
useless and pointless command.

Let's look at the dash package

$ sudo debconf-get-selections | grep dash
# Use dash as the default system shell (/bin/sh)?
dashdash/sh boolean true
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 24  2017 /bin/sh -> dash
$ echo dash dash/sh boolean false | sudo debconf-set-selections
$ sudo debconf-get-selections | grep dash
# Use dash as the default system shell (/bin/sh)?
dashdash/sh boolean false
$ sudo dpkg-reconfigure -fnoninteractive dash
Removing 'diversion of /bin/sh to /bin/sh.distrib by dash'
Adding 'diversion of /bin/sh to /bin/sh.distrib by bash'
Removing 'diversion of /usr/share/man/man1/sh.1.gz to 
/usr/share/man/man1/sh.distrib.1.gz by dash'
Adding 'diversion of /usr/share/man/man1/sh.1.gz to 
/usr/share/man/man1/sh.distrib.1.gz by bash'
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 17 10:55 /bin/sh -> bash
$ 

The dash package reconfiguration has no issues modifying the system
configuration based on debconf. I would expect tzdata to behave in a
consistent manner with other packages.

Regards,
Adam


signature.asc
Description: PGP signature

Bug#704089: tzdata config script prevents non-interactive (re)configuration

[Adam Bolte]

Package: tzdata
Version: 2018i-0+deb9u1
Followup-For: Bug #704089

Dear Maintainer,

This is still a problem 4 years later, and I unexpectedly found myself
spending time to track it down when doing configuration
management. Can we please get the above patch applied *before* the
Buster soft-freeze on 2019-02-12 (just over a month away)?

It seems the only work-around for now (aside from patching
tzdata.config before executing dpkg-reconfigure in non-interactive
mode) is to delete /etc/timezone first. As discussed in #516755, that
has the effect of causing a race condition that can lead to things
like log files showing wrong timestamps. Not great.

Thanks,
Adam

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

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en:ja 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.61

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf-show failed


signature.asc
Description: PGP signature

Bug#871717: xfce4-sensors-plugin: Newer version available / Memory leak

[Adam Bolte]

I'm hitting a rather significant memory leak too. My HDD started
trashing and my machine became incredibly slow. At this point I
noticed xfce4-sensors-plugin was using about 2Gb of RAM.

$ uptime
 11:15:14 up 51 days, 18:10,  1 user,  load average: 3.30, 3.91, 3.68

$ top
  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 2652 user  20   0 2343876 1.865g   4968 S   0.0  7.9  71:09.88 
xfce4-sensors-p

$ ps auxf
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root  1279  0.0  0.0 309732  1312 ?SLsl Sep07   0:00 
/usr/sbin/lightdm
root  1521 13.3  0.3 1407696 90544 tty7Rsl+ Sep07 9952:48  \_ 
/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp 
vt7 -novtswitch
root  1924  0.0  0.0 267788   624 ?Sl   Sep07   0:00  \_ lightdm 
--session-child 14 23
user  1988  0.0  0.0   4292 8 ?Ss   Sep07   0:00  |   \_ 
/bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
user  2375  0.0  0.0  11148   176 ?Ss   Sep07   0:32  |   \_ 
/usr/bin/ssh-agent /home/user/.xsession
user  2569  0.0  0.0 345872  6188 ?Sl   Sep07   6:15  |   \_ 
xfce4-session
user  2602  0.3  0.0 421048 16400 ?Sl   Sep07 295:09  |   
\_ xfwm4 --display :0.0 --sm-client-id 25f8d8283-7988-4b29-a508-3819f2dea688
user  2603  0.0  0.0 362164  5796 ?Sl   Sep07   0:00  |   
\_ Thunar --sm-client-id 24d5a28e0-b5f9-4268-96b7-ebb4742aec3d --daemon
user  2605  0.0  0.0 457208 19264 ?Sl   Sep07  17:22  |   
\_ xfce4-panel --display :0.0 --sm-client-id 2f7fea66a-cc58-4e2f-bf2c-8f1068a
user  2652  0.0  7.9 2343876 192 ? Sl   Sep07  71:09  |   | 
  \_ /usr/lib/x86_64-linux-gnu/xfce4/panel-plugins/xfce4-sensors-plugin  30 
16777254 xfce4-sensors-plugin Sensor plugin Show sensor values.

$ apt-cache policy xfce4-sensors-plugin
xfce4-sensors-plugin:
  Installed: 1.2.6-1+b1
  Candidate: 1.2.6-1+b1
  Version table:
 1.3.0-2 50
 50 http://ftp.debian.org/debian sid/main amd64 Packages
 *** 1.2.6-1+b1 500
500 http://ftp.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status


signature.asc
Description: PGP signature

Bug#905318: monitoring-plugins-common: $PATH_TO_SUDO is not set (required by check_mailq -s)

[Adam Bolte]

Package: monitoring-plugins-common
Version: 2.2-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I have a postfix installation where main.cf is configured like so:

-rw-r- 1 root root 2013 Aug  3 11:41 /etc/postfix/main.cf

This breaks mailq if executed without sudo, so I have icinga2 call
check_mail (from the monitoring-plugins-standard package) with
-s. This doesn't work since the check_mail script is actually unable
to call the sudo command.


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

This fixes the issue:

$ diff /usr/lib/nagios/plugins/utils.pm{.orig,}
20c20
< $PATH_TO_SUDO= "";
---
> $PATH_TO_SUDO= "/usr/bin/sudo";

Apparently the build system is supposed to take care of this
automatically.


   * What was the outcome of this action?

$ /usr/lib/nagios/plugins/check_mailq -s -w 4 -c 8 -M postfix -v
mailq: fatal: open /etc/postfix/main.cf: Permission denied
CRITICAL: Error code 75 returned from /usr/bin/mailq


   * What outcome did you expect instead?

$ /usr/lib/nagios/plugins/check_mailq -s -w 4 -c 8 -M postfix -v
OK: postfix mailq reports queue is empty|unsent=0;4;8;0

Hopefully it's a simple fix. Thanks for taking a look.

Regards,
Adam


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


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

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

Versions of packages monitoring-plugins-common depends on:
ii  libc6  2.24-11+deb9u3
ii  ucf3.0036

monitoring-plugins-common recommends no packages.

Versions of packages monitoring-plugins-common suggests:
pn  icinga | icinga2  

Bug#904532: euca2ools: euca-upload-bundle fails with python-requests >= 2.11.0

[Adam Bolte]

Package: euca2ools
Version: 3.3.1-1
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?

Upgrading to Stretch, which upgraded python-requests (currently to
2.12.4-1).

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

I tried to bundle an image like so:

$ euca-upload-bundle -b my-s3-bucket/prefix/ -m my-image.manifest.xml

   * What was the outcome of this action?

euca-upload-bundle: error: Header value 10485760 must be of type str or bytes, 
not 

   * What outcome did you expect instead?

Uploaded my-s3-bucket/prefix/my-image.manifest.xml


There is an upstream patch that fixes this issue here:
https://github.com/eucalyptus/euca2ools/pull/83

This patch was also included in euca2ools 3.3.2, so you might find it
easier to upgrade the packaged version instead.

The original issue triggered by a python-requests change is documented
here:
https://github.com/requests/requests/issues/3477


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

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

Versions of packages euca2ools depends on:
ii  python 2.7.13-2
ii  python-lxml3.7.1-1
ii  python-requestbuilder  0.5.2-2
ii  python-requests2.12.4-1
ii  python-setuptools  33.1.1-1
ii  python-six 1.10.0-3
ii  python-yaml3.12-1

Versions of packages euca2ools recommends:
ii  openssl  1.1.0f-3+deb9u2

euca2ools suggests no packages.

-- debconf-show failed

Bug#853926: cloud-init depends on net-base

[Adam Bolte]

On Sun, Feb 05, 2017 at 08:56:58PM +0100, Thomas Goirand wrote:
> On 02/03/2017 04:15 AM, Adam Bolte wrote:
> > On closer inspection, the error from netstat is different. I missed
> > the "Reason: [Errno 2] No such file or directory: 'netstat'" line from
> > the original report, so I'm seeing a different bug.
> > 
> > If the netstat command isn't doing anything critical (as implied by
> > cloud-init otherwise working just fine without it), perhaps references
> > to it can simply be removed from cloud-init to address both problems?
> > Otherwise, I guess I'll open a new bug report.
> 
> Considering what you just wrote, you don't even know if you are
> experiencing a bug or otherwise. In such case, please investigate before
> reporting.

It was easy to overlook that these are not the same issue because of
the exact same command in cloud-init failing, because I didn't have
"net-base" installed (because the original reporter got the package
name wrong) and because I experienced the issue around the same time
the bug was opened. For that mistake, I apologize.

In what possible way would such an error not be a bug? Can you clarify
what you mean with an example? Surely even if netstat is being called
before the interface is ready (which is the only other possibility I
can imagine causing this right now), shouldn't that be an expected
possibility by the code and handled gracefully.


signature.asc
Description: Digital signature

Bug#853926: cloud-init depends on net-base

[Adam Bolte]

On closer inspection, the error from netstat is different. I missed
the "Reason: [Errno 2] No such file or directory: 'netstat'" line from
the original report, so I'm seeing a different bug.

If the netstat command isn't doing anything critical (as implied by
cloud-init otherwise working just fine without it), perhaps references
to it can simply be removed from cloud-init to address both problems?
Otherwise, I guess I'll open a new bug report.


signature.asc
Description: Digital signature

Bug#853926: cloud-init depends on net-base

[Adam Bolte]

On Thu, Feb 02, 2017 at 02:22:12PM +0100, Thomas Goirand wrote:
> I don't see how Jessie would be affected, as there, net-base is
> still an essential package.

You are correct, and it certainly is installed into the AMIs in
question. I think the suggested cause is incorrect.


From the debug log:

Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.7 
running 'init' at Fri, 03 Feb 2017 02:41:13 +. Up 6.61 seconds.
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Writing to 
/var/log/cloud-init.log - ab: [420] 0 bytes
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Changing the ownership of 
/var/log/cloud-init.log to 0:4
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Running command 
['ifconfig', '-a'] with allowed return codes [0] (shell=False, capture=True)
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Running command 
['netstat', '-rn'] with allowed return codes [0] (shell=False, capture=True)
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[WARNING]: Route info failed: 
Unexpected error while running command.#012Command: ['netstat', '-rn']#012Exit 
code: 1#012Reason: -#012Stdout: 'Kernel IP routing table\nDestination 
Gateway Genmask Flags   MSS Window  irtt Iface\n'#012Stderr: ''
Feb  3 13:41:13 localhost [CLOUDINIT] util.py[DEBUG]: Route info failed: 
Unexpected error while running command.#012Command: ['netstat', '-rn']#012Exit 
code: 1#012Reason: -#012Stdout: 'Kernel IP routing table\nDestination 
Gateway Genmask Flags   MSS Window  irtt Iface\n'#012Stderr: 
''#012Traceback (most recent call last):#012  File 
"/usr/lib/python3/dist-packages/cloudinit/netinfo.py", line 199, in 
route_pformat#012routes = route_info()#012  File 
"/usr/lib/python3/dist-packages/cloudinit/netinfo.py", line 99, in 
route_info#012(route_out, _err) = util.subp(["netstat", "-rn"])#012  File 
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 1684, in subp#012
cmd=args)#012cloudinit.util.ProcessExecutionError: Unexpected error while 
running command.#012Command: ['netstat', '-rn']#012Exit code: 1#012Reason: 
-#012Stdout: 'Kernel IP routing table\nDestination Gateway Genmask  
   Flags   MSS Window  irtt Iface\n'#012Stderr: ''


Standard output:

Cloud-init v. 0.7.7 running 'init-local' at Fri, 03 Feb 2017 02:41:12 +. Up 
5.69 seconds.
Cloud-init v. 0.7.7 running 'init' at Fri, 03 Feb 2017 02:41:13 +. Up 6.61 
seconds.
2017-02-03 13:41:13,763 - util.py[WARNING]: Route info failed: Unexpected error 
while running command.
Command: ['netstat', '-rn']
Exit code: 1
Reason: -
Stdout: 'Kernel IP routing table\nDestination Gateway Genmask   
  Flags   MSS Window  irtt Iface\n'
Stderr: ''
ci-info: +++Net device 
info
ci-info: 
++--++---+---+---+
ci-info: | Device |  Up  |  Address   |Mask   | Scope | 
Hw-Address|
ci-info: 
++--++---+---+---+
ci-info: |   lo   | True | 127.0.0.1  | 255.0.0.0 |   .   | 
. |
ci-info: |   lo   | True |  ::1/128   | . |  host | 
. |
ci-info: |  eth0  | True | .  | . |   .   | 
**:**:**:**:**:** |
ci-info: |  eth0  | True | ::**:::/** | . |  link | 
**:**:**:**:**:** |
ci-info: 
++--++---+---+---+
ci-info: !!!Route info 
failed

-Adam


signature.asc
Description: Digital signature

Bug#853926: cloud-init depends on net-base

[Adam Bolte]

I'm also confirming this issue exists in the jessie-backports package
version 0.7.7~bzr1156-1~bpo8+1. It's not fatal (networking still
works), but certainly something I noticed when creating new EC2 AMIs.

-Adam



signature.asc
Description: Digital signature

Bug#844785: systemd prevents polkit from working properly

[Adam Bolte]

On 20/11/16 15:13, Raphaël Halimi wrote:
> Control: retitle -1 systemd-shim not fully compatible with systemd
> 232 Control: affects -1 policykit-1 policykit-1-gnome mate-polkit
>
> Le 20/11/2016 à 04:21, Adam Bolte a écrit : Right. I retitled the bug
> to more precisely describe the problem, and added affected packages
> (at least the ones I tried...

Thanks! That's a great idea.


> Yeah, that's basically what I did, except with systemd 231-10.

I saw 231-10, but wasn't sure it ever made it to testing (possibly
suggesting a problem with it). I could be mistaken, but I never had it
installed on my machine at least, and I do upgrade reasonably often.


> I then pinned systemd with a preferences file, and now apt is
> holding libpam-systemd and libsystemd0 too, but accepted to upgrade
> udev and libudev1 (I initially thought that there would be a
> versioned dependency between the two sets, but that's not the case).
> So in fact, only those three packages (four in case of multi-arch)
> have to be downgraded to restore the system to a functional state.

Thanks for reporting. I'll just pin those packages for now too then.

Cheers,
Adam




signature.asc
Description: OpenPGP digital signature

Bug#844785: systemd prevents polkit from working properly

[Adam Bolte]

It took about an hour to find this bug report, since I was looking for
changes related to consolekit, polkit, pam, etc. I've been using using
sysvinit-core to avoid systemd issues (systemd doesn't even boot for me
for some reason I don't care to investigate), so it didn't immediately
occur to me to look at possible systemd libraries changes. I wouldn't be
surprised if a lot of people hitting this don't know to look here.

On Sat, 19 Nov 2016 09:35:32 -0300 Felipe Sateler 
wrote:
> Because you use sysvinit, this means the systemd-shim compatibility
> layer is not working for 232. I'm reassigning so that it can be fixed.

Confirming this all seems accurate. I too am using systemd-shim (which
was not updated in a while.

As a work-around, look through the log to get the systemd-related
packages which were upgraded:

$ grep 232-3 /var/log/dpkg.log | grep ' status installed ' | \
  cut -d ' ' -f 5 | sort | uniq
libpam-systemd:amd64
libsystemd0:amd64
libsystemd0:i386
libudev1:amd64
libudev1:i386
libudev-dev:amd64
systemd:amd64
udev:amd64

Then head over to http://snapshot.debian.org/package/systemd/231-9/ and
download the debs for each of the above. Check the hashes, and install:

# dpkg -i *.deb

Reboot, and now you can shutdown via lightdm, mount drives, etc as normal.

Cheers,
Adam



signature.asc
Description: OpenPGP digital signature

Bug#783597: asterisk: Modules fail to load

[Adam Bolte]

Is this a duplicate of #780392?


signature.asc
Description: Digital signature

Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates

[Adam Bolte]

This issue also affects rsyslog. I hit this when I upgraded a bunch of
servers, including an rsyslog server from wheezy to jessie.

There are still a few wheezy servers that have yet to be upgraded, but
now they are unable to send their logs to the jessie rsyslog server
due to what appears to be this bug. Only the upgraded jessie servers
can send through their logs. Looks like I'll have to implement a
work-around.

Since this is obviously an issue with stable Debian releases, I too do
not believe this bug should be marked as closed.

Adam


signature.asc
Description: Digital signature

Bug#770885: [Pkg-xfce-devel] Bug#770885: lightdm: Restart, Suspend, Hibernate, Shut Down all greyed out and nonfunctional

[Adam Bolte]

Hi believe I'm running into the same issue.

$ apt-cache policy lightdm cgmanager policykit-1 systemd-shim systemd 
libpam-systemd sysvinit-core libvirt-daemon-system | grep -E -A1 
'^[^[:space:]]+' | grep -v '^--$'
lightdm:
Installed: 1.10.3-3
cgmanager:
Installed: 0.33-2+deb8u2
policykit-1:
Installed: 0.105-8
systemd-shim:
Installed: 9-1
systemd:
Installed: 215-17+deb8u2
libpam-systemd:
Installed: 215-17+deb8u2
sysvinit-core:
Installed: 2.88dsf-59
libvirt-daemon-system:
Installed: 1.2.9-9+deb8u1

Also:

$ dpkg -S /sbin/init
sysvinit-core: /sbin/init

Since I'm not running systemd but I am using libvirt, I have the following set:

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.19.0 root=/dev/sda2 ro cgroup_enable=memory quiet

(note the "cgroup_enable=memory" bit) as well as:

$ sed -n '/^[^#]/p' /etc/default/libvirtd
start_libvirtd="yes"
mount_cgroups=yes

This mounts cgroups nicely, as advertised:

$ mount | grep ^cgroup
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k)
cgroup_root on /sys/fs/cgroup type tmpfs (rw,relatime)
cgroup_cpuset on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuset,clone_children)
cgroup_cpu on /sys/fs/cgroup/cpu type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,release_agent=/run/cgmanager/agents/cgm-release-agent.cpu)
cgroup_cpuacct on /sys/fs/cgroup/cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuacct,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuacct)
cgroup_devices on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices,release_agent=/run/cgmanager/agents/cgm-release-agent.devices)
cgroup_freezer on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer,release_agent=/run/cgmanager/agents/cgm-release-agent.freezer)
cgroup_net_cls on /sys/fs/cgroup/net_cls type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,release_agent=/run/cgmanager/agents/cgm-release-agent.net_cls)
cgroup_blkio on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio,release_agent=/run/cgmanager/agents/cgm-release-agent.blkio)
cgroup_perf_event on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event)
cgroup_memory on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory,release_agent=/run/cgmanager/agents/cgm-release-agent.memory)

However, according to #760640, these cgroups are created by hand and
not via cgmanager. This is clear by inspecting how
/etc/init.d/libvirtd works.

This is where some guesswork on my part comes into being, since I'm
not entirely clear on how this is all supposed to fit together. I'm
guessing lightdm is relying on policykit, which in turn is using
cgmanager and libpam-systemd. When cgroups are manually created as per
#760640 for virtd, it somehow borks cgmanager, and thus policykit, and
thus lightdm.

You can also observe NetworkManager doesn't allow state to be changed
by the user in this situation.

So if my theory is correct, #760640 is a blocker for resolving
this. I'm happy to run any tests anyone might suggest to verify this,
but it seems easily reproducible on the few boxes I have tested
with. Simply set mount_cgroups=yes in /etc/default/libvirtd and the
lightdm shutdown drop-down options become grayed out. At least libvirt
cgroup support is supposed to start working though. :/

Related bugs seem to be:

#760640 - Should use cgmanager
#769494 - Please mount cgroup automatically
#601757 - Please mount cgroup automatically

So the only real option to have lightdm/NetworkManager and
libvirt+cgroups working is to use systemd. But I can't use that yet
due to other systemd bugs, and I'd rather not use it anyway.

If anyone has a work-around/hack to have libvirtd register cgroup
mounts via cgmanager, please do tell.


signature.asc
Description: Digital signature

Bug#237925: RFP: cdemu -- program for emulating optical drives

[Adam Bolte]

On Tue, 24 Mar 2015 05:27:54 +0100 Christoph Anton Mitterer
cales...@scientia.net wrote:
 Just to add some more details:
 - The big difference from CDEmu to loopback is, that CDEmu actually
   emulates a CD drive (with all it's commands and interfaces), while
   the loopback method only makes an ISO image mountable.

I sometimes play old games under Wine on newer computers that don't
have CD drives (or find them too slow and annoying to deal with). I
have the CD images created long ago on a backup drive, but the games
need the emulation CDEmu provides to satisfy various copy protection
schemes.

CDEmu has built-in DPM emulation, transfer rate emulation and bad
sector emulation, and support for an extensive range of disc image
types - all of which make this project essential for playing a number
of old games on newer machines without an optical drive.

Debian would certainly benefit from including this software. Since we
package Wine, we should package CDEmu.

Cheers,
Adam


signature.asc
Description: Digital signature

Bug#237925: RFP: cdemu -- program for emulating optical drives

[Adam Bolte]

On Tue, 24 Mar 2015 05:27:54 +0100 Christoph Anton Mitterer
cales...@scientia.net wrote:
 Just to add some more details:
 - The big difference from CDEmu to loopback is, that CDEmu actually
   emulates a CD drive (with all it's commands and interfaces), while the
   loopback method only makes an ISO image mountable.
   device emulator vs. filesystem

I sometimes play old games under Wine on newer computers that don't have
CD drives. I have the CD images created long ago on a backup drive, but
the games need the emulation CDEmu provides to satisfy various copy
protection schemes.

CDEmu has built-in DPM emulation, transfer rate emulation and bad sector
emulation, and support for an extensive range of disc image types - all
of which make this project essential for playing a number of old games
on newer machines without an optical drive.

Debian would certainly benefit from including this software. Since we
package Wine, we should package CDEmu.

Cheers,
Adam



signature.asc
Description: OpenPGP digital signature

Bug#717945: libgcr-3-1: libgcr-3.so.1 missing

[Adam Bolte]

Package: libgcr-3-1
Version: 3.8.2-4
Severity: normal

Dear Maintainer,

The Online Accounts menu in gnome-control-center isn't working. The console
output includes the following:

libgcr-3.so.1: cannot open shared object file: No such file or directory
Failed to load module: /usr/lib/control-center-1/panels/libonline-accounts.so

Further investigation:

$ ldd /usr/lib/control-center-1/panels/libonline-accounts.so | grep 'not found'
libgcr-3.so.1 = not found
$ dpkg -S /usr/lib/x86_64-linux-gnu/libgcr-3.so.1
libgcr-3-1:amd64: /usr/lib/x86_64-linux-gnu/libgcr-3.so.1
$ ls -l /usr/lib/x86_64-linux-gnu/libgcr-3.so.1*
ls: cannot access /usr/lib/x86_64-linux-gnu/libgcr-3.so.1*: No such file or 
directory
$

Interestingly, I was able to correct the situation with:

$ sudo apt-get install --reinstall libgcr-3-1:amd64

which then created symlinks to libgcr-ui-3.so.1.0.0.

No idea what could have caused this. My installation is just over a month old
and is relatively clean (no 3rd party repositories, etc).

I have a i386 jessie chroot which I tried installing libgcr-3-1 in, and there
were no issues there. Main differences would be architecture, and the fact that
I performed my amd64 install from a wheezy netinst (which seemed to have
installed libgcr-3-1 from wheezy on June 23rd according to the logs), and
dist-upgraded to jessy soon afterwards.

Feel free to close this if it cannot be reproduced, but I thought I'd bring it
to your attention just in case the package isn't upgrading correctly under
certain conditions.


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

Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#639875: [Pkg-fglrx-devel] Bug#639875: fglrx-driver: xorg-video-abi-11

[Adam Bolte]

Worked like a charm. I also posted more detailed instructions on how to
downgrade to 1.10.4 on my blog, in case anyone else is still stuck on
this.

http://systemsaviour.com/?p=514

Cheers,
Adam


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