[Touch-packages] [Bug 1966800] Re: systemd locks up due to incorrect handling of time zone changes

2022-03-28 Thread Neal Gompa
** Bug watch added: Red Hat Bugzilla #1941335
   https://bugzilla.redhat.com/show_bug.cgi?id=1941335

** Also affects: systemd (Fedora) via
   https://bugzilla.redhat.com/show_bug.cgi?id=1941335
   Importance: Unknown
   Status: Unknown

-- 
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/1966800

Title:
  systemd locks up due to incorrect handling of time zone changes

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd package in Fedora:
  Unknown

Bug description:
  Recently on systems in Ireland, systemd became unresponsive due the
  change from GMT to Irish Standard Time. This is due to Ireland being
  unique in having their standard time during the summer, unlike most
  regions.

  Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1941335
  Fixed by: 
https://github.com/systemd/systemd-stable/commit/a8b66ca9af811148b67ee952ab32748f88b8bba3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966800/+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 1292324] Re: Support non-root X

2017-04-08 Thread Neal Gompa
** Bug watch added: Red Hat Bugzilla #1078808
   https://bugzilla.redhat.com/show_bug.cgi?id=1078808

** Also affects: lightdm (Fedora) via
   https://bugzilla.redhat.com/show_bug.cgi?id=1078808
   Importance: Unknown
   Status: Unknown

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

Title:
  Support non-root X

Status in Light Display Manager:
  Triaged
Status in lightdm package in Ubuntu:
  Triaged
Status in lightdm package in Debian:
  Confirmed
Status in lightdm package in Fedora:
  Unknown

Bug description:
  Support running X as an unprivileged user.

  Currently X servers are run as root means a large complex process has
  access to services it might not need (i.e. potential security and
  stability problems). It would be nice to run each X server as either
  an unprivileged user or in the session they are being used in.

  Logind provides a system for sharing access to the display and input
  devices so this can be done - this seems like the most likely
  implementation of non-root X.

  For more information see Hans de Goede request:
  http://lists.freedesktop.org/archives/lightdm/2014-March/000539.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1292324/+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 1641121] [NEW] Switch packaging to "3.0 (quilt)"

2016-11-11 Thread Neal Gompa
Public bug reported:

The packaging for Mir is in the legacy 1.0 format.

Please switch to "3.0 (quilt)" format.

Thanks in advance.

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


** Tags: packaging

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

Title:
  Switch packaging to "3.0 (quilt)"

Status in mir package in Ubuntu:
  New

Bug description:
  The packaging for Mir is in the legacy 1.0 format.

  Please switch to "3.0 (quilt)" format.

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1641121/+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 1573275] Re: ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'

2016-04-22 Thread Neal Gompa
Yes. Actually, it might be more useful to diff between 15.10[1] and
16.04[2]. That lets you see all the differences that were required to
get it working.

[1]: https://build.opensuse.org/project/prjconf/Ubuntu:15.10
[2]: https://build.opensuse.org/project/prjconf/Ubuntu:16.04

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

Title:
  ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  '/etc/init.d/networking' for 'ifupdown' starts with:

    # Required-Start:mountkernfs $local_fs urandom

  it would appear that 'mountkernfs' and 'urandom' are not hard-
  dependencies, and their presence prevents successful installation in
  virtual machines in some circumstances.  This was reported by Neal
  Gompa/ on #ubuntu-devel whilst working on support for
  Suse Open Build System (OBS) to build Xenial packages:

  
http://changelogs.ubuntu.com/changelogs/pool/main/i/ifupdown/ifupdown_0.8.10ubuntu1/changelog

  Full and snipped output logs are at:

    http://paste.fedoraproject.org/358318/61266534/
    https://paste.fedoraproject.org/358315/66065146/

  in particular:

    [  530s] [239/256] installing ifupdown-0.8.10ubuntu1
    [  530s] Creating /etc/network/interfaces.
    [  531s] insserv: Service mountkernfs has to be enabled to start service 
networking
    [  531s] insserv: Service urandom has to be enabled to start service 
networking
    [  531s] insserv: exiting now!
    [  531s] update-rc.d: error: insserv rejected the script header
    [  531s] dpkg: error processing package ifupdown (--install):
    [  531s]  subprocess installed post-installation script returned error exit 
status 1

  The reporter tested that commenting out 'mountkernfs' and 'urandom'
  allowed the ifupdown '/etc/init.d/networking' init-script to
  successfully complete.

  Ideally a hard-dependency should not be declared if it is not actually
  a hard-dependency, and introduces a regression by  preventing
  successfully installation in circumstances that are reported to have
  worked previously for installing earlier Debian/Ubuntu versions on
  OBS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1573275/+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 1573275] Re: ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'

2016-04-22 Thread Neal Gompa
Paul: Unfortunately not, but you can see how the configuration is set up
on build.opensuse.org[1]. Details about the prjconf format is available
on the openSUSE Wiki[2].

[1]: https://build.opensuse.org/project/prjconf/Ubuntu:16.04
[2]: https://en.opensuse.org/openSUSE:Build_Service_prjconf

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

Title:
  ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  '/etc/init.d/networking' for 'ifupdown' starts with:

    # Required-Start:mountkernfs $local_fs urandom

  it would appear that 'mountkernfs' and 'urandom' are not hard-
  dependencies, and their presence prevents successful installation in
  virtual machines in some circumstances.  This was reported by Neal
  Gompa/ on #ubuntu-devel whilst working on support for
  Suse Open Build System (OBS) to build Xenial packages:

  
http://changelogs.ubuntu.com/changelogs/pool/main/i/ifupdown/ifupdown_0.8.10ubuntu1/changelog

  Full and snipped output logs are at:

    http://paste.fedoraproject.org/358318/61266534/
    https://paste.fedoraproject.org/358315/66065146/

  in particular:

    [  530s] [239/256] installing ifupdown-0.8.10ubuntu1
    [  530s] Creating /etc/network/interfaces.
    [  531s] insserv: Service mountkernfs has to be enabled to start service 
networking
    [  531s] insserv: Service urandom has to be enabled to start service 
networking
    [  531s] insserv: exiting now!
    [  531s] update-rc.d: error: insserv rejected the script header
    [  531s] dpkg: error processing package ifupdown (--install):
    [  531s]  subprocess installed post-installation script returned error exit 
status 1

  The reporter tested that commenting out 'mountkernfs' and 'urandom'
  allowed the ifupdown '/etc/init.d/networking' init-script to
  successfully complete.

  Ideally a hard-dependency should not be declared if it is not actually
  a hard-dependency, and introduces a regression by  preventing
  successfully installation in circumstances that are reported to have
  worked previously for installing earlier Debian/Ubuntu versions on
  OBS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1573275/+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 1573275] Re: ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'

2016-04-22 Thread Neal Gompa
This is no longer a problem on the Open Build Service, as we're now
ignoring the ifupdown dependency from upstart. Thus, Ubuntu 16.04 LTS
build environments now work, as seen by this example[1].

[1]:
https://build.opensuse.org/package/live_build_log/home:Pharaoh_Atem:u1604_stuff
/php-libvirt/xUbuntu_16.04/x86_64

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

Title:
  ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  '/etc/init.d/networking' for 'ifupdown' starts with:

    # Required-Start:mountkernfs $local_fs urandom

  it would appear that 'mountkernfs' and 'urandom' are not hard-
  dependencies, and their presence prevents successful installation in
  virtual machines in some circumstances.  This was reported by Neal
  Gompa/ on #ubuntu-devel whilst working on support for
  Suse Open Build System (OBS) to build Xenial packages:

  
http://changelogs.ubuntu.com/changelogs/pool/main/i/ifupdown/ifupdown_0.8.10ubuntu1/changelog

  Full and snipped output logs are at:

    http://paste.fedoraproject.org/358318/61266534/
    https://paste.fedoraproject.org/358315/66065146/

  in particular:

    [  530s] [239/256] installing ifupdown-0.8.10ubuntu1
    [  530s] Creating /etc/network/interfaces.
    [  531s] insserv: Service mountkernfs has to be enabled to start service 
networking
    [  531s] insserv: Service urandom has to be enabled to start service 
networking
    [  531s] insserv: exiting now!
    [  531s] update-rc.d: error: insserv rejected the script header
    [  531s] dpkg: error processing package ifupdown (--install):
    [  531s]  subprocess installed post-installation script returned error exit 
status 1

  The reporter tested that commenting out 'mountkernfs' and 'urandom'
  allowed the ifupdown '/etc/init.d/networking' init-script to
  successfully complete.

  Ideally a hard-dependency should not be declared if it is not actually
  a hard-dependency, and introduces a regression by  preventing
  successfully installation in circumstances that are reported to have
  worked previously for installing earlier Debian/Ubuntu versions on
  OBS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1573275/+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 1573275] Re: ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'

2016-04-21 Thread Neal Gompa
** Package changed: ubuntu => ifupdown (Ubuntu)

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

Title:
  ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  '/etc/init.d/networking' for 'ifupdown' starts with:

    # Required-Start:mountkernfs $local_fs urandom

  it would appear that 'mountkernfs' and 'urandom' are not hard-
  dependencies, and their presence prevents successful installation in
  virtual machines in some circumstances.  This was reported by Neal
  Gompa/ on #ubuntu-devel whilst working on support for
  Suse Open Build System (OBS) to build Xenial packages:

  
http://changelogs.ubuntu.com/changelogs/pool/main/i/ifupdown/ifupdown_0.8.10ubuntu1/changelog

  Full and snipped output logs are at:

    http://paste.fedoraproject.org/358318/61266534/
    https://paste.fedoraproject.org/358315/66065146/

  in particular:

    [  530s] [239/256] installing ifupdown-0.8.10ubuntu1
    [  530s] Creating /etc/network/interfaces.
    [  531s] insserv: Service mountkernfs has to be enabled to start service 
networking
    [  531s] insserv: Service urandom has to be enabled to start service 
networking
    [  531s] insserv: exiting now!
    [  531s] update-rc.d: error: insserv rejected the script header
    [  531s] dpkg: error processing package ifupdown (--install):
    [  531s]  subprocess installed post-installation script returned error exit 
status 1

  The reporter tested that commenting out 'mountkernfs' and 'urandom'
  allowed the ifupdown '/etc/init.d/networking' init-script to
  successfully complete.

  Ideally a hard-dependency should not be declared if it is not actually
  a hard-dependency, and introduces a regression by  preventing
  successfully installation in circumstances that are reported to have
  worked previously for installing earlier Debian/Ubuntu versions on
  OBS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1573275/+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 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script

2016-02-17 Thread Neal Gompa
This is very clearly not fixed on Ubuntu trusty, and the changelog of
the package in trusty does not indicate any fix was applied.

Please remove the incorrect designation of "Fix Committed" for trusty.

-- 
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/1325142

Title:
  failure to update libpam-systemd in 14.04 due to missing logind init
  script

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Released
Status in systemd source package in Utopic:
  Fix Released

Bug description:
  Hi,

  while running inside an i386 lubuntu 14.04 chroot, upgrading libpam-
  systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken
  state. 'apt-get -f install' from within the chroot will not fix it,
  but if the build is made bootable and put into a iso/VM you can
  recover that way in a live session.

  the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm 
script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind 
stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't 
exist) and not /etc/init/systemd-logind.conf (does exist).
  ?

  
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following packages will be upgraded:
libpam-systemd
  1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded.
  3 not fully installed or removed.
  Need to get 0 B/25.2 kB of archives.
  After this operation, 1024 B of additional disk space will be used.
  (Reading database ... 113986 files and directories currently installed.)
  Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ...
  invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
  dpkg: warning: subprocess old pre-removal script returned error exit status 
100
  dpkg: trying script from the new package instead ...
  invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
  dpkg: error processing archive 
/var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack):
   subprocess new pre-removal script returned error exit status 100
  invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
  dpkg: error while cleaning up:
   subprocess installed post-installation script returned error exit status 100
  Errors were encountered while processing:
   /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  
  Our build logs available upon request, but the scripts to setup the chroot to 
recreate it are here:

https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh

https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh

  
  In a web-search I notice a few others running into the same bug,

  chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28
  /%23ubuntu-devel.txt

  someone else's build log:
  https://launchpad.net/~qutim/+archive/qutim/+build/6039800

  launchpad bug #1323575 seems to be a duplicate of this one.

  
  perhaps related to older launchpad bug #1305395 ?

  note we are also suffering from a failure with update-initramfs, not sure of 
the root cause of that one but I thought I'd mention it in case they were 
related, since they both started happening about the same time, a couple weeks 
ago. (launchpad bug #1317602)
  It all worked ok after the inital releases of 14.04, so something to do with 
a package update since then.

  
  thanks,
  Hamish

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+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 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script

2016-02-17 Thread Neal Gompa
I'm also being bitten by this issue. I can't create chroots or VM images
based on trusty due to polkit-1 bringing in libpam-systemd, which breaks
as other commenters have described earlier...

-- 
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/1325142

Title:
  failure to update libpam-systemd in 14.04 due to missing logind init
  script

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Released
Status in systemd source package in Utopic:
  Fix Released

Bug description:
  Hi,

  while running inside an i386 lubuntu 14.04 chroot, upgrading libpam-
  systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken
  state. 'apt-get -f install' from within the chroot will not fix it,
  but if the build is made bootable and put into a iso/VM you can
  recover that way in a live session.

  the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm 
script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind 
stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't 
exist) and not /etc/init/systemd-logind.conf (does exist).
  ?

  
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following packages will be upgraded:
libpam-systemd
  1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded.
  3 not fully installed or removed.
  Need to get 0 B/25.2 kB of archives.
  After this operation, 1024 B of additional disk space will be used.
  (Reading database ... 113986 files and directories currently installed.)
  Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ...
  invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
  dpkg: warning: subprocess old pre-removal script returned error exit status 
100
  dpkg: trying script from the new package instead ...
  invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
  dpkg: error processing archive 
/var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack):
   subprocess new pre-removal script returned error exit status 100
  invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
  dpkg: error while cleaning up:
   subprocess installed post-installation script returned error exit status 100
  Errors were encountered while processing:
   /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  
  Our build logs available upon request, but the scripts to setup the chroot to 
recreate it are here:

https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh

https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh

  
  In a web-search I notice a few others running into the same bug,

  chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28
  /%23ubuntu-devel.txt

  someone else's build log:
  https://launchpad.net/~qutim/+archive/qutim/+build/6039800

  launchpad bug #1323575 seems to be a duplicate of this one.

  
  perhaps related to older launchpad bug #1305395 ?

  note we are also suffering from a failure with update-initramfs, not sure of 
the root cause of that one but I thought I'd mention it in case they were 
related, since they both started happening about the same time, a couple weeks 
ago. (launchpad bug #1317602)
  It all worked ok after the inital releases of 14.04, so something to do with 
a package update since then.

  
  thanks,
  Hamish

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+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