[Touch-packages] [Bug 1484027] Re: systemd-tmpfiles-clean warns about duplicate /var/log line

2017-04-03 Thread Paul Crawford 
If it was fixed in 8.12.0-1ubuntu3 why am I still seeing this on a
16.04.2 system with:

apt-cache policy rsyslog
rsyslog:
  Installed: 8.16.0-1ubuntu3
  Candidate: 8.16.0-1ubuntu3
  Version table:
 *** 8.16.0-1ubuntu3 500
500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
100 /var/lib/dpkg/status

It happens one per day it seems.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1484027

Title:
  systemd-tmpfiles-clean warns about duplicate /var/log line

Status in rsyslog package in Ubuntu:
  Fix Released

Bug description:
  Triggered by the two /var/log entries that were reported in
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1434295, I get
  daily log messages from systemd-tmpfiles-clean saying:

  Aug 10 15:04:13 seraph systemd[1]: Starting Cleanup of Temporary 
Directories...
  Aug 10 15:04:13 seraph systemd-tmpfiles[5897]: 
[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
  Aug 10 15:04:13 seraph systemd[1]: Started Cleanup of Temporary Directories.

  I don't know much about systemd, so I have no ideas for how to fix it,
  sorry.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1484027/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1535840] Re: systemd ignoring /etc/modules due to blacklist

2017-02-24 Thread Paul Crawford 
Generally me work-around so far has been to avoid systemd!
However, where that is not an option you might be able to edit 
/etc/default/watchdog so the module is loaded on watchdog start-up. It is not 
ideal as you might have some other reasons for wanting the /dev/watchdog 
virtual file to be testable without the watchdog having started though (e.g. 
automated install script that probes harder support, etc).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1535840

Title:
  systemd ignoring /etc/modules due to blacklist

Status in systemd package in Ubuntu:
  New

Bug description:
  I tried the daily build of 16.04 32-bit to test out the watchdog
  daemon code. Usually (Ubuntu 10.04-14.04) I add the watchdog module in
  /etc/modules so it is loaded at boot-time, as watchdog timer modules
  are not normally auto-loaded due to the risk of an unexpected reboot.

  However I now find that systemd is choosing to ignore my command to
  load the module in /etc/modules since it appears in the watchdog
  blacklist. Typical syslog entries look like this:

  Jan 19 16:46:14 ubuntu systemd-modules-load[337]: Module 'softdog' is 
blacklisted
  Jan 19 17:53:23 ubuntu systemd-modules-load[342]: Module 'softdog' is 
blacklisted

  This is just dumb! I have explicitly told the system to load the
  module, an action that works perfectly well using modprobe or by
  adding it to the start script for the watchdog, and yet systemd
  chooses to override that because of the blacklist for auto-loaded
  modules (in this case in /etc/modprobe.d/blacklist-watchdog.conf).

  $ lsb_release -rd
  Description:  Ubuntu Xenial Xerus (development branch)
  Release:  16.04

  $ apt-cache policy systemd
  systemd:
Installed: 228-4ubuntu1
Candidate: 228-4ubuntu1
Version table:
   *** 228-4ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages
  100 /var/lib/dpkg/status

  What I expect to happen is modules added to /etc/modules are loaded at
  boot time, and not subject to the blacklist for hardware detect /
  automatic loading.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1535840/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1594658] Re: diskless setup with nfs mounted home hangs on shutdown/reboot

2016-10-31 Thread Paul Crawford 
We were seeing this on a fresh Ubuntu 16.04 64-bit installation using
fixed IP addresses and automounter for NFS drives. The suggestion #7
seems to fix it for use, but it would be useful to know just what is
happening with the script. Is it trawling through some user's home
directory when expanding the '~*' entry in the case statement in
/sbin/resolvconf by any chance?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1594658

Title:
  diskless setup with nfs mounted home hangs on shutdown/reboot

Status in nfs-utils package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 16.04 fresh install hangs when shutting down.
  The system is diskless PXE-booted with a couple of nfs mounted directories 
including homedir.

  As I have no persistent storage whatsoever, I don't have any logs, but
  in debug-shell, running journalctl -f I can see that it hangs at

  [   *] (1 of 2) A stop job running for Raise Network Interfaces (10s / 1min 
30s)Jun 20 20:23:05 $hostname kernel: nfs: server $nfs-ip-address not 
responding, still trying
  Jun 20 20:23:05 $hostname kernel: nfs: server $nfs-ip-address not responding, 
still trying
  Jun 20 20:23:14 $hostname kernel: nfs: server $nfs-ip-address not responding, 
still trying
  Jun 20 20:24:08 $hostname kernel: nfs: server $nfs-ip-address not responding, 
still trying

  Second job in "(1 of 2)" is thermald, turning it off does not fix the problem.
  Also, this counter "(10s / 1min 30s)" stops visually updating.

  server $nfs-ip-address is not responding, because, all network
  interfaces are already down at this point.

  I am not exactly sure why this happens. Looks like there is a wrong
  ordering of shutdown of systemd services, which bring down interfaces
  before something nfs-related, but I am not sure if that's the reason
  of hanging.

  
  Workaround that fixes the problem:
  In /lib/systemd/system/networking.service
  comment following line:
  ExecStop=/sbin/ifdown -a --read-environment

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1594658/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1577596] Re: ntpd not started when using ntpdate

2016-07-12 Thread Paul Crawford 
*** This bug is a duplicate of bug 1575572 ***
https://bugs.launchpad.net/bugs/1575572

I don't think this is a duplicate of bug #1575572
I am seeing this problem on an Ubuntu 16.04 machine that has the update "This 
bug was fixed in the package init-system-helpers - 1.29ubuntu2" mentioned as 
being a fix for that bug but ntpd is still broken on booting. I am seeing this:

Jul 12 14:14:43 metop ntpd[1933]: unable to bind to wildcard address :: - 
another process may be running - EXITING
Jul 12 14:14:50 metop ntpdate[1758]: step time server 134.36.22.27 offset 
0.264278 sec

So basically the systemd dependency arrangement is broken: ntpdate is
slow now (as for comment #16 above) and not exiting before ntpd is
started, it then it fails due to ntpdate still running.

A later manual start of ntpd works fine, but that is not an acceptable
situation for machines that are unattended and/or used by people that
don't have administrative rights (or knowledge) to manually start ntpd
later.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1577596

Title:
  ntpd not started when using ntpdate

Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in ntp package in Ubuntu:
  Confirmed

Bug description:
  After updating from 14.04 to 16.04 on a number of my systems, ntpd no
  longer starts at boot on any of those systems.

  `systemctl status ntp` shows:
 ntp.service - LSB: Start NTP daemon
 Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
 Active: inactive (dead)
   Docs: man:systemd-sysv-generator(8)
  May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon.
  May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon.

  Manually starting it using `systemctl start ntp` works fine.  However,
  systemd does not seem to want to start it automatically at boot time.


  As best as I can tell based on trial and error, there is something
  special about the combination of the service being named "ntp.service"
  and the service depending on network.target.  However, I haven't been
  able to identify exactly what is causing this.

  If I copy the init script to any other name, everything works fine:
  cp /etc/init.d/ntp /etc/init.d/ntpd
  Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd"
  systemctl enable ntpd
  # After a reboot, ntpd.service is started, but ntp.service is not.

  If I remove "$network" from the "# Required-Start: $network $remote_fs
  $syslog" line in /etc/init.d/ntp, then systemd starts it automatically
  ... But of course it is started before the network comes up, so it
  fails.

  If I replace /etc/init.d/ntp with a file containing only the following, 
systemd won't try to start it automatically at boot:
  #!/bin/sh
  ### BEGIN INIT INFO
  # Provides: ntp
  # Required-Start: $network
  # Required-Stop: $network
  # Default-Start: 2 3 4 5
  # Default-Stop: 1
  # Short-Description: Start NTP daemon
  ### END INIT INFO
  echo "script was run" >> /ntp.log

  If I rename that same dummy script to /etc/init.d/ntp2, it is started
  automatically at boot.

  However, grepping the systemd source code and my systemd config files for ntp 
doesn't seem to find anything that might cause this behavior:
  /etc/systemd# grep -iR ntp *
  timesyncd.conf:#NTP=
  timesyncd.conf:#FallbackNTP=ntp.ubuntu.com
  /lib/systemd# grep -R ntp *
  
system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd
  
system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd
  Binary file systemd-networkd matches
  Binary file systemd-timedated matches
  Binary file systemd-timesyncd matches

  What else can I do to debug this further?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1577596/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1535840] [NEW] systemd ignoring /etc/modules due to blacklist

2016-01-19 Thread Paul Crawford 
Public bug reported:

I tried the daily build of 16.04 32-bit to test out the watchdog daemon
code. Usually (Ubuntu 10.04-14.04) I add the watchdog module in
/etc/modules so it is loaded at boot-time, as watchdog timer modules are
not normally auto-loaded due to the risk of an unexpected reboot.

However I now find that systemd is choosing to ignore my command to load
the module in /etc/modules since it appears in the watchdog blacklist.
Typical syslog entries look like this:

Jan 19 16:46:14 ubuntu systemd-modules-load[337]: Module 'softdog' is 
blacklisted
Jan 19 17:53:23 ubuntu systemd-modules-load[342]: Module 'softdog' is 
blacklisted

This is just dumb! I have explicitly told the system to load the module,
an action that works perfectly well using modprobe or by adding it to
the start script for the watchdog, and yet systemd chooses to override
that because of the blacklist for auto-loaded modules (in this case in
/etc/modprobe.d/blacklist-watchdog.conf).

$ lsb_release -rd
Description:Ubuntu Xenial Xerus (development branch)
Release:16.04

$ apt-cache policy systemd
systemd:
  Installed: 228-4ubuntu1
  Candidate: 228-4ubuntu1
  Version table:
 *** 228-4ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages
100 /var/lib/dpkg/status

What I expect to happen is modules added to /etc/modules are loaded at
boot time, and not subject to the blacklist for hardware detect /
automatic loading.

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1535840

Title:
  systemd ignoring /etc/modules due to blacklist

Status in systemd package in Ubuntu:
  New

Bug description:
  I tried the daily build of 16.04 32-bit to test out the watchdog
  daemon code. Usually (Ubuntu 10.04-14.04) I add the watchdog module in
  /etc/modules so it is loaded at boot-time, as watchdog timer modules
  are not normally auto-loaded due to the risk of an unexpected reboot.

  However I now find that systemd is choosing to ignore my command to
  load the module in /etc/modules since it appears in the watchdog
  blacklist. Typical syslog entries look like this:

  Jan 19 16:46:14 ubuntu systemd-modules-load[337]: Module 'softdog' is 
blacklisted
  Jan 19 17:53:23 ubuntu systemd-modules-load[342]: Module 'softdog' is 
blacklisted

  This is just dumb! I have explicitly told the system to load the
  module, an action that works perfectly well using modprobe or by
  adding it to the start script for the watchdog, and yet systemd
  chooses to override that because of the blacklist for auto-loaded
  modules (in this case in /etc/modprobe.d/blacklist-watchdog.conf).

  $ lsb_release -rd
  Description:  Ubuntu Xenial Xerus (development branch)
  Release:  16.04

  $ apt-cache policy systemd
  systemd:
Installed: 228-4ubuntu1
Candidate: 228-4ubuntu1
Version table:
   *** 228-4ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages
  100 /var/lib/dpkg/status

  What I expect to happen is modules added to /etc/modules are loaded at
  boot time, and not subject to the blacklist for hardware detect /
  automatic loading.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1535840/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 459730] Re: rsyslog doesn't create /dev/xconsole

2016-01-19 Thread Paul Crawford 
This is still present in the development branch for 16.04

Jan 19 17:53:23 ubuntu rsyslogd-2039: Could not open output pipe
'/dev/xconsole':: No such file or directory [v8.14.0 try
http://www.rsyslog.com/e/2039 ]

System information:

$ lsb_release -rd
Description:Ubuntu Xenial Xerus (development branch)
Release:16.04

$ apt-cache policy rsyslog
rsyslog:
  Installed: 8.14.0-2ubuntu2
  Candidate: 8.14.0-2ubuntu2
  Version table:
 *** 8.14.0-2ubuntu2 500
500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages
100 /var/lib/dpkg/status

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/459730

Title:
  rsyslog doesn't create /dev/xconsole

Status in One Hundred Papercuts:
  Triaged
Status in rsyslog package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: rsyslog

  Looks like this was missed in the move to upstart.

  This function was called in init.d/rsyslog start:

  create_xconsole() {
  if [ ! -e /dev/xconsole ]
  then
  mknod -m 640 /dev/xconsole p
  chown root:adm /dev/xconsole
  [ -x /sbin/restorecon ] && /sbin/restorecon /dev/xconsole
  fi
  }

  I can't find any reference to it now. If this is old school then it should be 
re
  moved from the config.

  rsyslog:
Installed: 4.2.0-2ubuntu5

To manage notifications about this bug go to:
https://bugs.launchpad.net/hundredpapercuts/+bug/459730/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1535854] [NEW] watchdog daemon going in to failed state on reboot

2016-01-19 Thread Paul Crawford 
Public bug reported:

I was testing the watchdog daemon code on the development version of
16.04 today and found the associated systemd service files for this has
some bugs.

The first of these was a typo in /lib/systemd/system/watchdog.service
where there was a missing ['] character. This lead to an error message
"Unbalanced quoting, ignoring" which was easy to fix. The update is now
in the source-forge repository for the project as commit
http://sourceforge.net/p/watchdog/code/ci/38e6430f80907a84741c760ef48df69a679b294c/

However, I have not found the reason for the second problem where the
daemon has some fault at reboot time and goes in to "failed state" and
then it will not restart with the machine booting. The typical related
syslog entries are:

Jan 19 16:46:08 ubuntu watchdog[2066]: stopping daemon (5.14)
Jan 19 16:46:08 ubuntu systemd[1]: Stopping watchdog daemon...
Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Control process exited, 
code=exited status=1
Jan 19 16:46:09 ubuntu systemd[1]: Stopped watchdog daemon.
Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Unit entered failed state.
Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Triggering OnFailure= 
dependencies.
Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Failed to enqueue 
OnFailure= job: Resource deadlock avoided
Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Failed with result 
'exit-code'.

I am guessing this is related to the shut-down approach for the watchdog
daemon where normally the wd_keepalive daemon is started afterwards (to
prevent a reboot if the hardware module is configured for "no way out"
so the timer cannot be stopped).

$ lsb_release -rd
Description:Ubuntu Xenial Xerus (development branch)
Release:16.04

$ apt-cache policy watchdog
watchdog:
  Installed: 5.14-3
  Candidate: 5.14-3
  Version table:
 *** 5.14-3 500
500 http://us.archive.ubuntu.com/ubuntu xenial/universe i386 Packages
100 /var/lib/dpkg/status

I have contacted the watchdog project maintainer with a view to working
out a solution to this. This bug report is more of a marker to let folks
know that there is an issue here if you plan on having high-availability
servers based on Ubuntu 16.04 (well, any systemd based system really..)
where watchdog-based fault recovery is an expectation.

** Affects: watchdog (Ubuntu)
 Importance: Undecided
 Status: New

** Package changed: rsyslog (Ubuntu) => watchdog (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1535854

Title:
  watchdog daemon going in to failed state on reboot

Status in watchdog package in Ubuntu:
  New

Bug description:
  I was testing the watchdog daemon code on the development version of
  16.04 today and found the associated systemd service files for this
  has some bugs.

  The first of these was a typo in /lib/systemd/system/watchdog.service
  where there was a missing ['] character. This lead to an error message
  "Unbalanced quoting, ignoring" which was easy to fix. The update is
  now in the source-forge repository for the project as commit
  
http://sourceforge.net/p/watchdog/code/ci/38e6430f80907a84741c760ef48df69a679b294c/

  However, I have not found the reason for the second problem where the
  daemon has some fault at reboot time and goes in to "failed state" and
  then it will not restart with the machine booting. The typical related
  syslog entries are:

  Jan 19 16:46:08 ubuntu watchdog[2066]: stopping daemon (5.14)
  Jan 19 16:46:08 ubuntu systemd[1]: Stopping watchdog daemon...
  Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Control process exited, 
code=exited status=1
  Jan 19 16:46:09 ubuntu systemd[1]: Stopped watchdog daemon.
  Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Unit entered failed 
state.
  Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Triggering OnFailure= 
dependencies.
  Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Failed to enqueue 
OnFailure= job: Resource deadlock avoided
  Jan 19 16:46:09 ubuntu systemd[1]: watchdog.service: Failed with result 
'exit-code'.

  I am guessing this is related to the shut-down approach for the
  watchdog daemon where normally the wd_keepalive daemon is started
  afterwards (to prevent a reboot if the hardware module is configured
  for "no way out" so the timer cannot be stopped).

  $ lsb_release -rd
  Description:  Ubuntu Xenial Xerus (development branch)
  Release:  16.04

  $ apt-cache policy watchdog
  watchdog:
Installed: 5.14-3
Candidate: 5.14-3
Version table:
   *** 5.14-3 500
  500 http://us.archive.ubuntu.com/ubuntu xenial/universe i386 Packages
  100 /var/lib/dpkg/status

  I have contacted the watchdog project maintainer with a view to
  working out a solution to this. This bug report is more of a marker to
  let folks know that there is an issue here if y

[Touch-packages] [Bug 1328264] Re: packaging issues with the trusty Xstack in precise xserver-xorg-lts-trusty

2014-08-04 Thread Paul Crawford 
A recent update to the update-manager seems to have fixed this for me.
Still problems with the Nvidia driver post-update, but that is not the
same bug/dependency issue.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1328264

Title:
  packaging issues with the trusty Xstack in precise xserver-xorg-lts-
  trusty

Status in “apt” package in Ubuntu:
  Confirmed

Bug description:
  Hello,

  I've tested the trusty Xstack HWE xserver-xorg-lts-trusty in precise;

  When you have installed another Xstack (e.g.saucy), it is not possible
  to install the trusty Xstack smoothly.

  Only installing the original precice Xstack (xserver-xorg-lts-
  precise), which removes the current xstack and after that installing
  the trusty xstack in one step without restart, works.

  Please help to make that smoother!

  Thanks, Bernhard

  Error Message while trying to install trusty xstack, when saucy xstack
  is installed (in precise);

  apt-get install -V libglapi-mesa-lts-trusty libgl1-mesa-glx-lts-trusty 
xserver-xorg-lts-trusty xserver-xorg-input-all-lts-trusty 
xserver-xorg-video-all-lts-trusty libgl1-mesa-dri-lts-trusty 
x11-xserver-utils-lts-trusty libglapi-mesa-lts-trusty:i386 
libgl1-mesa-dri-lts-trusty:i386 libgl1-mesa-glx-lts-trusty:i386
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libglapi-mesa-lts-trusty : Conflicts: libglapi-mesa
   libglapi-mesa-lts-trusty:i386 : Conflicts: libglapi-mesa
   xserver-xorg-lts-trusty : Conflicts: libglapi-mesa (>= 0~)   

 
 Conflicts: libgles2-mesa (>= 0~)   

 
  E: Unable to correct problems, you have held broken packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1328264/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1192037] Re: rsyslog shuts down too soon with Upstart

2014-08-06 Thread Paul Crawford 
I would also like to have shutdown messages logged. Could it be
configured to stop on reaching the last of the init-style of run-levels?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1192037

Title:
  rsyslog shuts down too soon with Upstart

Status in “rsyslog” package in Ubuntu:
  Confirmed

Bug description:
  The Upstart configuration file (/etc/init/rsyslog.conf) that appears
  to come with rsyslog 5.8.6-1ubuntu8 contains the stanza "stop on
  runlevel [06]". This results in some applications being unable to log
  their shutdown messages. This is a particular problem if those
  messages are important, such as from the STONITH meatware module. This
  would also be a problem for any application that needed to report
  trouble during a shutdown.

  I don't see any viable alternative to simply removing the "stop"
  stanza from /etc/init/rsyslog.conf.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1192037/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1237042] Re: ureadahead source needs "tracing_enabled" changed to "tracing_on" for 12.04.3

2014-08-26 Thread Paul Crawford 
Still broken on 12.04.5 recently updated:

$ apt-cache policy ureadahead
ureadahead:
  Installed: 0.100.0-12
  Candidate: 0.100.0-12
  Version table:
 *** 0.100.0-12 0
500 http://gb.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
100 /var/lib/dpkg/status

$ uname -a
Linux pscpc 3.13.0-34-generic #60~precise1-Ubuntu SMP Wed Aug 13 15:55:33 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux

Also finding nothing in /var/lib/ureadahead suggesting it never worked
on my system (installed as 12.04.4 I think)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ureadahead in Ubuntu.
https://bugs.launchpad.net/bugs/1237042

Title:
  ureadahead source needs "tracing_enabled" changed to "tracing_on" for
  12.04.3

Status in “ureadahead” package in Ubuntu:
  Confirmed

Bug description:
  On a fresh install of Ubuntu 12.04.3 (64-bit), ureadahead was always
  exiting with status code 5.

  When manually run as:  sudo /sbin/ureadahead --force-trace --debug
  The output is:
  Counted 4 CPUs
  trace: Missing uselib tracing: No such file or directory
  ureadahead: Error while tracing: No such file or directory

  The uselib tracing notice is not important.  The "error while tracing" notice 
lead me to compare ureadahead sources between 12.04.3 and 13.04.  Note that 
ureadahead in 13.04 works.  I noticed this difference on lines 195 and 232:
if (set_value (dfd, "tracing_enabled",
  vs:
if (set_value (dfd, "tracing_on",

  This change is mentioned in the changelog as:

  ureadahead (0.100.0-13) raring; urgency=low
* src/trace.c: tracing_enabled is deprecated and gone, switch to tracing_on
  (LP: #1085766).
   -- Andy Whitcroft   Fri, 11 Jan 2013 12:05:17 +

  I suspect that this issue occurs in 12.04.3 because it is now using
  the newer raring kernel 3.8.0-31.  Previous flavors of 12.04 such as
  12.04.2 do not seem to exhibit this ureadahead issue, probably because
  the kernel is older 3.5.xx.

  As a proof-of-concept test, I hex edited the 12.04.3 /sbin/ureadahead
  to change "tracing_enabled" to "tracing_on".  Upon reboot, now
  ureadahead works, generates the /var/lib/ureadahead/pack file, and it
  does not report status code 5.

  Another workaround is to use the ureadahead binary from 13.04, but the
  updated /lib/x86_64-linux-gnu/libext2fs.so.2.4 is also required from
  13.04.

  
  $ lsb_release -rd
  Description:  Ubuntu 12.04.3 LTS
  Release:  12.04

  $ apt-cache policy ureadahead
  ureadahead:
Installed: 0.100.0-12
Candidate: 0.100.0-12
Version table:
   *** 0.100.0-12 0
  500 http://mirror.peer1.net/ubuntu/ precise/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/1237042/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1328264] Re: packaging issues with the trusty Xstack in precise xserver-xorg-lts-trusty

2014-07-30 Thread Paul Crawford 
This bug, the ability to get the kernel back on to a supported stream,
is still broken a month on, even though there was some update to the
update manager today (which still caused a crash report, though that was
supposed to be fixed).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1328264

Title:
  packaging issues with the trusty Xstack in precise xserver-xorg-lts-
  trusty

Status in “apt” package in Ubuntu:
  Confirmed

Bug description:
  Hello,

  I've tested the trusty Xstack HWE xserver-xorg-lts-trusty in precise;

  When you have installed another Xstack (e.g.saucy), it is not possible
  to install the trusty Xstack smoothly.

  Only installing the original precice Xstack (xserver-xorg-lts-
  precise), which removes the current xstack and after that installing
  the trusty xstack in one step without restart, works.

  Please help to make that smoother!

  Thanks, Bernhard

  Error Message while trying to install trusty xstack, when saucy xstack
  is installed (in precise);

  apt-get install -V libglapi-mesa-lts-trusty libgl1-mesa-glx-lts-trusty 
xserver-xorg-lts-trusty xserver-xorg-input-all-lts-trusty 
xserver-xorg-video-all-lts-trusty libgl1-mesa-dri-lts-trusty 
x11-xserver-utils-lts-trusty libglapi-mesa-lts-trusty:i386 
libgl1-mesa-dri-lts-trusty:i386 libgl1-mesa-glx-lts-trusty:i386
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libglapi-mesa-lts-trusty : Conflicts: libglapi-mesa
   libglapi-mesa-lts-trusty:i386 : Conflicts: libglapi-mesa
   xserver-xorg-lts-trusty : Conflicts: libglapi-mesa (>= 0~)   

 
 Conflicts: libgles2-mesa (>= 0~)   

 
  E: Unable to correct problems, you have held broken packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1328264/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1328264] Re: packaging issues with the trusty Xstack in precise xserver-xorg-lts-trusty

2014-07-30 Thread Paul Crawford 
Running from the command line reports:

$ /usr/bin/update-manager
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/defer/__init__.py", line 473, in 
_inline_callbacks
result = gen.throw(result.type, result.value, result.traceback)
  File 
"/usr/lib/python2.7/dist-packages/UpdateManager/backend/InstallBackendAptdaemon.py",
 line 54, in commit
yield self._run_in_dialog(trans, self.INSTALL)
  File "/usr/lib/python2.7/dist-packages/defer/__init__.py", line 473, in 
_inline_callbacks
result = gen.throw(result.type, result.value, result.traceback)
  File 
"/usr/lib/python2.7/dist-packages/UpdateManager/backend/InstallBackendAptdaemon.py",
 line 75, in _run_in_dialog
yield dia.run()
aptdaemon.errors.TransactionFailed: Transaction failed: None
 The following packages have unmet dependencies:

libgl1-mesa-glx-lts-trusty: Depends: libglapi-mesa-lts-trusty (= 
10.1.3-0ubuntu0.1~precise1) but 10.1.3-0ubuntu0.1~precise1 is to be installed
Depends: libx11-6 (>= 2:1.4.99.1) but 
2:1.4.99.1-0ubuntu2.2 is to be installed
Depends: libxdamage1 (>= 1:1.1) but 1:1.1.3-2build1 
is to be installed
xserver-xorg-lts-trusty: Depends: xserver-xorg-core-lts-trusty (>= 2:1.11) but 
2:1.15.1-0ubuntu2~precise1 is to be installed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1328264

Title:
  packaging issues with the trusty Xstack in precise xserver-xorg-lts-
  trusty

Status in “apt” package in Ubuntu:
  Confirmed

Bug description:
  Hello,

  I've tested the trusty Xstack HWE xserver-xorg-lts-trusty in precise;

  When you have installed another Xstack (e.g.saucy), it is not possible
  to install the trusty Xstack smoothly.

  Only installing the original precice Xstack (xserver-xorg-lts-
  precise), which removes the current xstack and after that installing
  the trusty xstack in one step without restart, works.

  Please help to make that smoother!

  Thanks, Bernhard

  Error Message while trying to install trusty xstack, when saucy xstack
  is installed (in precise);

  apt-get install -V libglapi-mesa-lts-trusty libgl1-mesa-glx-lts-trusty 
xserver-xorg-lts-trusty xserver-xorg-input-all-lts-trusty 
xserver-xorg-video-all-lts-trusty libgl1-mesa-dri-lts-trusty 
x11-xserver-utils-lts-trusty libglapi-mesa-lts-trusty:i386 
libgl1-mesa-dri-lts-trusty:i386 libgl1-mesa-glx-lts-trusty:i386
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libglapi-mesa-lts-trusty : Conflicts: libglapi-mesa
   libglapi-mesa-lts-trusty:i386 : Conflicts: libglapi-mesa
   xserver-xorg-lts-trusty : Conflicts: libglapi-mesa (>= 0~)   

 
 Conflicts: libgles2-mesa (>= 0~)   

 
  E: Unable to correct problems, you have held broken packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1328264/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp