[Touch-packages] [Bug 206924] Re: Make it possible to create a guest account

2021-07-04 Thread Alkis Georgopoulos
** No longer affects: ltsp

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

Title:
  Make it possible to create a guest account

Status in accountsservice:
  Confirmed
Status in gdm:
  Fix Released
Status in GNOME Shutdown:
  Fix Released
Status in Xubuntu:
  New
Status in accountsservice package in Ubuntu:
  Confirmed
Status in kde-workspace package in Ubuntu:
  Won't Fix
Status in lxdm package in Ubuntu:
  Opinion
Status in sdm package in Ubuntu:
  Opinion
Status in slim package in Ubuntu:
  Opinion
Status in wdm package in Ubuntu:
  Opinion
Status in wing package in Ubuntu:
  Opinion
Status in xdm package in Ubuntu:
  Won't Fix

Bug description:
  Make a guest account that people can login to, and check their mail,
  surf web, etc.

  Every time the guest account logs out, its purged so the next user who
  login is a clean fresh account.

  This would be great in public terminals, libraries, hotels, lobbys,
  etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/accountsservice/+bug/206924/+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 1902109] Re: rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

2020-12-09 Thread Alkis Georgopoulos
Since this was fixed upstream and it doesn't affect any LTS Ubuntu
releases, I don't think it's important enough to do SRUs. Thank you!

(For LTSP users, that are affected by this: once a fixed rsync version
lands in Ubuntu, I'll copy it to the LTSP PPA for Groovy, so LTSP will
work there too)

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

Title:
  rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

Status in GLibC:
  Confirmed
Status in glibc package in Ubuntu:
  Invalid
Status in rsync package in Ubuntu:
  Triaged
Status in glibc source package in Groovy:
  Invalid
Status in rsync source package in Groovy:
  Won't Fix

Bug description:
  Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
  This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it 
returned "no" before.

  Steps to reproduce:

  # Emulate /proc not being mounted
  $ mount --bind / /mnt
  $ chroot /mnt rsync -a /bin/ls .
  rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not 
supported (95)
  rsync error: some files/attrs were not transferred (see previous errors) 
(code 3) at main.c(1330) [sender=3.2.3]

  I reported this issue upstream in
  https://github.com/WayneD/rsync/issues/109 but the rsync developer
  says it's a problem in libc, and it might well be.

  Simple C code to reproduce the problem without rsync:

  printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));

  If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails
  when /proc isn't mounted, yet it succeeds if it is mounted.

  Python had a similar issue, and they ended up avoiding
  AC_CHECK_FUNC(lchmod) under Linux:

  https://bugs.python.org/issue34652
  
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140

  ```c
  if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
  fi
  ```

  So I'm not sure which package is causing the bug here. Should autoconf
  return false? Should libc implement lchown without the bug? Or should
  rsync skip lchmod under Linux, like python did?

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/1902109/+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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

2020-11-04 Thread Alkis Georgopoulos
Thank you Łukasz, I filed it in LP: #1902879.

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

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
  * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.

  * It's especially harmful in containers to have such "small" limit, so
  we are hereby SRUing a more recent bump from upstream systemd, in the
  form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
  [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
  releases, like Focal and subsequent ones, already include this patch
  so effectively we're putting Bionic on-par with newer releases.

  * A discussion about this topic (leading to this SRU) is present in
  ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
  devel/2020-September/041159.html.

  [Test Case]
  * The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a 
current Bionic system, and then install an updated version with the hereby 
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a 
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely 
to be deleted in next month or so).

  * A more interesting test is to run a Focal container in a current
  Bionic system and try to build the cryptsetup package - it'll fail in
  some tests. After updating the host (Bionic) systemd to include the
  mlock bump patch, the build succeeds in the Focal container.

  [Regression Potential]
  * Since it's a simple bump and it makes Bionic behave like Focal, I don't 
foresee regressions. One potential issue would be if some users rely on the 
lower default limit (16M) and this value is bumped by a package update, but 
that could be circumvented by setting a lower limit in limits.conf. The 
benefits for such bump are likely much bigger than any "regression" caused for 
users relying on such default limit.

  
  [0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 1662244] Re: lightdm causes all greeters to fail to start

2020-11-04 Thread Alkis Georgopoulos
What torel proposed in https://bugs.launchpad.net/ubuntu/+source/unity-
greeter/+bug/1662244/comments/14 avoids the segfault:

* soft memlock 262144
* hard memlock 262144

Should all lightdm users manually put that in limits.conf, or should we
expect some update?

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

Title:
  lightdm causes all greeters to fail to start

Status in Light Display Manager:
  Invalid
Status in LightDM GTK+ Greeter:
  Invalid
Status in lightdm package in Ubuntu:
  Invalid
Status in unity-greeter package in Ubuntu:
  Invalid

Bug description:
  lightdm is failing to start. Best guess is because of unity-session-
  manager. This is from .xsession-errors.

  dbus-update-activation-environment: setting 
_=/usr/bin/dbus-update-activation-environment
  upstart: click-user-hooks main process (4028) terminated with status 1
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon respawning too fast, stopped
  upstart: indicator-application main process ended, respawning
  upstart: indicator-application main process ended, respawning
  upstart: indicator-application respawning too fast, stopped
  xbrlapi: window 0x03a00084 changed to NULL name
  xbrlapi: window 0x03a00084 changed to NULL name
  xbrlapi: window 0x03c00084 changed to NULL name
  xbrlapi: window 0x03c00084 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  upstart: dbus main process (4023) killed by TERM signal

  
  I've tried to move aside $HOME/.config/dconf/user and that didn't work. I've 
reverted kernel versions and that didn't work. I've moved aside $HOME/.cache 
and that didn't work.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: lightdm 1.19.5-0ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-30.32-generic 4.8.6
  Uname: Linux 4.8.0-30-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.3-0ubuntu8.2
  Architecture: amd64
  Date: Mon Feb  6 10:21:29 2017
  InstallationDate: Installed on 2015-07-20 (566 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
  SourcePackage: lightdm
  UpgradeStatus: Upgraded to yakkety on 2016-12-14 (53 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1662244/+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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

2020-11-04 Thread Alkis Georgopoulos
What torel proposed in https://bugs.launchpad.net/ubuntu/+source/unity-
greeter/+bug/1662244/comments/14 avoids the segfault:

* soft memlock 262144
* hard memlock 262144

Should all lightdm users manually put that in limits.conf, or should we
expect some update?

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

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
  * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.

  * It's especially harmful in containers to have such "small" limit, so
  we are hereby SRUing a more recent bump from upstream systemd, in the
  form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
  [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
  releases, like Focal and subsequent ones, already include this patch
  so effectively we're putting Bionic on-par with newer releases.

  * A discussion about this topic (leading to this SRU) is present in
  ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
  devel/2020-September/041159.html.

  [Test Case]
  * The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a 
current Bionic system, and then install an updated version with the hereby 
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a 
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely 
to be deleted in next month or so).

  * A more interesting test is to run a Focal container in a current
  Bionic system and try to build the cryptsetup package - it'll fail in
  some tests. After updating the host (Bionic) systemd to include the
  mlock bump patch, the build succeeds in the Focal container.

  [Regression Potential]
  * Since it's a simple bump and it makes Bionic behave like Focal, I don't 
foresee regressions. One potential issue would be if some users rely on the 
lower default limit (16M) and this value is bumped by a package update, but 
that could be circumvented by setting a lower limit in limits.conf. The 
benefits for such bump are likely much bigger than any "regression" caused for 
users relying on such default limit.

  
  [0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 1662244] Re: lightdm causes all greeters to fail to start

2020-11-04 Thread Alkis Georgopoulos
Hi, a recent systemd update in 18.04 makes slick-greeter segfault.
So all Ubuntu MATE 18.04 users now get black screens instead of lightdm.

It's related to memory limits so I'm cross-referencing it here:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746

This didn't help:

[LightDM]
lock-memory=false

Can I put something in /etc/security/limits.conf to see if it helps?

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

Title:
  lightdm causes all greeters to fail to start

Status in Light Display Manager:
  Invalid
Status in LightDM GTK+ Greeter:
  Invalid
Status in lightdm package in Ubuntu:
  Invalid
Status in unity-greeter package in Ubuntu:
  Invalid

Bug description:
  lightdm is failing to start. Best guess is because of unity-session-
  manager. This is from .xsession-errors.

  dbus-update-activation-environment: setting 
_=/usr/bin/dbus-update-activation-environment
  upstart: click-user-hooks main process (4028) terminated with status 1
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon main process ended, respawning
  upstart: unity-settings-daemon respawning too fast, stopped
  upstart: indicator-application main process ended, respawning
  upstart: indicator-application main process ended, respawning
  upstart: indicator-application respawning too fast, stopped
  xbrlapi: window 0x03a00084 changed to NULL name
  xbrlapi: window 0x03a00084 changed to NULL name
  xbrlapi: window 0x03c00084 changed to NULL name
  xbrlapi: window 0x03c00084 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  xbrlapi: window 0x0484 changed to NULL name
  upstart: dbus main process (4023) killed by TERM signal

  
  I've tried to move aside $HOME/.config/dconf/user and that didn't work. I've 
reverted kernel versions and that didn't work. I've moved aside $HOME/.cache 
and that didn't work.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: lightdm 1.19.5-0ubuntu1
  ProcVersionSignature: Ubuntu 4.8.0-30.32-generic 4.8.6
  Uname: Linux 4.8.0-30-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.3-0ubuntu8.2
  Architecture: amd64
  Date: Mon Feb  6 10:21:29 2017
  InstallationDate: Installed on 2015-07-20 (566 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
  SourcePackage: lightdm
  UpgradeStatus: Upgraded to yakkety on 2016-12-14 (53 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1662244/+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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

2020-11-04 Thread Alkis Georgopoulos
Hi, this update makes slick-greeter segfault, so Ubuntu MATE 18.04 users
doing normal updates now get a black screen with a flicking cursor.

A temporary workaround is to enable autologin in
/etc/lightdm/lightdm.conf:

[Seat:*]
autologin-guest=false
autologin-user=administrator
autologin-user-timeout=0

*** What would be a proper fix for this? ***

A related discussion about memory limits and lightdm issues exists in this bug 
report:
https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1662244

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

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
  * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.

  * It's especially harmful in containers to have such "small" limit, so
  we are hereby SRUing a more recent bump from upstream systemd, in the
  form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
  [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
  releases, like Focal and subsequent ones, already include this patch
  so effectively we're putting Bionic on-par with newer releases.

  * A discussion about this topic (leading to this SRU) is present in
  ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
  devel/2020-September/041159.html.

  [Test Case]
  * The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a 
current Bionic system, and then install an updated version with the hereby 
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a 
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely 
to be deleted in next month or so).

  * A more interesting test is to run a Focal container in a current
  Bionic system and try to build the cryptsetup package - it'll fail in
  some tests. After updating the host (Bionic) systemd to include the
  mlock bump patch, the build succeeds in the Focal container.

  [Regression Potential]
  * Since it's a simple bump and it makes Bionic behave like Focal, I don't 
foresee regressions. One potential issue would be if some users rely on the 
lower default limit (16M) and this value is bumped by a package update, but 
that could be circumvented by setting a lower limit in limits.conf. The 
benefits for such bump are likely much bigger than any "regression" caused for 
users relying on such default limit.

  
  [0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 1902109] Re: rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

2020-10-30 Thread Alkis Georgopoulos
Hi Robie, thank you for the feedback,

I located an upstream bug report in glibc for this:
https://sourceware.org/bugzilla/show_bug.cgi?id=26401

** Bug watch added: Sourceware.org Bugzilla #26401
   https://sourceware.org/bugzilla/show_bug.cgi?id=26401

** Also affects: rsync via
   https://sourceware.org/bugzilla/show_bug.cgi?id=26401
   Importance: Unknown
   Status: Unknown

** No longer affects: rsync

** Also affects: glibc via
   https://sourceware.org/bugzilla/show_bug.cgi?id=26401
   Importance: Unknown
   Status: Unknown

** Also affects: glibc (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

Status in GLibC:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in rsync package in Ubuntu:
  Triaged

Bug description:
  Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
  This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it 
returned "no" before.

  Steps to reproduce:

  # Emulate /proc not being mounted
  $ mount --bind / /mnt
  $ chroot /mnt rsync -a /bin/ls .
  rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not 
supported (95)
  rsync error: some files/attrs were not transferred (see previous errors) 
(code 3) at main.c(1330) [sender=3.2.3]

  I reported this issue upstream in
  https://github.com/WayneD/rsync/issues/109 but the rsync developer
  says it's a problem in libc, and it might well be.

  Simple C code to reproduce the problem without rsync:

  printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));

  If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails
  when /proc isn't mounted, yet it succeeds if it is mounted.

  Python had a similar issue, and they ended up avoiding
  AC_CHECK_FUNC(lchmod) under Linux:

  https://bugs.python.org/issue34652
  
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140

  ```c
  if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
  fi
  ```

  So I'm not sure which package is causing the bug here. Should autoconf
  return false? Should libc implement lchown without the bug? Or should
  rsync skip lchmod under Linux, like python did?

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/1902109/+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 1902109] [NEW] rsync uses lchmod and fails in Ubuntu >= 20.10

2020-10-29 Thread Alkis Georgopoulos
Public bug reported:

Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it 
returned "no" before.

Steps to reproduce:

# Emulate /proc not being mounted
$ mount --bind / /mnt
$ chroot /mnt rsync -a /bin/ls .
rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not 
supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 
3) at main.c(1330) [sender=3.2.3]

I reported this issue upstream in
https://github.com/WayneD/rsync/issues/109 but the rsync developer says
it's a problem in libc, and it might well be.

Simple C code to reproduce the problem without rsync:

printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));

If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails when
/proc isn't mounted, yet it succeeds if it is mounted.

Python had a similar issue, and they ended up avoiding
AC_CHECK_FUNC(lchmod) under Linux:

https://bugs.python.org/issue34652
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140

```c
if test "$MACHDEP" != linux; then
  AC_CHECK_FUNC(lchmod)
fi
```

So I'm not sure which package is causing the bug here. Should autoconf
return false? Should libc implement lchown without the bug? Or should
rsync skip lchmod under Linux, like python did?

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

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

Title:
  rsync uses lchmod and fails in Ubuntu >= 20.10

Status in rsync package in Ubuntu:
  New

Bug description:
  Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
  This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it 
returned "no" before.

  Steps to reproduce:

  # Emulate /proc not being mounted
  $ mount --bind / /mnt
  $ chroot /mnt rsync -a /bin/ls .
  rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not 
supported (95)
  rsync error: some files/attrs were not transferred (see previous errors) 
(code 3) at main.c(1330) [sender=3.2.3]

  I reported this issue upstream in
  https://github.com/WayneD/rsync/issues/109 but the rsync developer
  says it's a problem in libc, and it might well be.

  Simple C code to reproduce the problem without rsync:

  printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));

  If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails
  when /proc isn't mounted, yet it succeeds if it is mounted.

  Python had a similar issue, and they ended up avoiding
  AC_CHECK_FUNC(lchmod) under Linux:

  https://bugs.python.org/issue34652
  
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140

  ```c
  if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
  fi
  ```

  So I'm not sure which package is causing the bug here. Should autoconf
  return false? Should libc implement lchown without the bug? Or should
  rsync skip lchmod under Linux, like python did?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1902109/+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 1829401] Re: gi.repository.GLib.GError: pk-client-error-quark: could not do untrusted question as no klass support

2020-09-24 Thread Alkis Georgopoulos
Same problem here when telling software-properties-gtk to refresh the
cache, in Ubuntu MATE 20.04.1.

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

Title:
  gi.repository.GLib.GError: pk-client-error-quark: could not do
  untrusted question as no klass support

Status in packagekit package in Ubuntu:
  Triaged
Status in packagekit source package in Eoan:
  Won't Fix
Status in packagekit source package in Focal:
  Confirmed

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
software-properties.  This problem was most recently seen with package version 
0.98.2, the problem page at 
https://errors.ubuntu.com/problem/300ff7bf9068dc50ace4c5db5c4a34ba0dfc926d 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

  [Back trace]
  Traceback (most recent call last):
File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/DialogCacheOutdated.py", 
line 86, in on_pktask_finish
  results = self._pktask.generic_finish(result)
  gi.repository.GLib.GError: pk-client-error-quark: could not do untrusted 
question as no klass support (8)

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/DialogCacheOutdated.py", 
line 89, in on_pktask_finish
  Gtk.ButtonsType.CANCEL, _("Error while refreshing cache"))
File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 319, 
in new_init
  return super_init_func(self, **new_kwargs)
File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 575, in 
__init__
  self._init(*args, **new_kwargs)
File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 319, 
in new_init
  return super_init_func(self, **new_kwargs)
File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 521, in 
__init__
  _window_init(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 319, 
in new_init
  return super_init_func(self, **new_kwargs)
  TypeError: could not convert value for property `transient_for' from 
DialogCacheOutdated to GtkWindow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1829401/+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 1854190] Re: software-properties-gtk crashed with TypeError in new_init(): could not convert value for property `transient_for' from DialogCacheOutdated to GtkWindow

2020-09-24 Thread Alkis Georgopoulos
*** This bug is a duplicate of bug 1829401 ***
https://bugs.launchpad.net/bugs/1829401

** This bug has been marked a duplicate of bug 1829401
   gi.repository.GLib.GError: pk-client-error-quark: could not do untrusted 
question as no klass support

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

Title:
  software-properties-gtk crashed with TypeError in new_init(): could
  not convert value for property `transient_for' from
  DialogCacheOutdated to GtkWindow

Status in software-properties package in Ubuntu:
  New

Bug description:
  Upon attempting to add debug repositories to apt and then opening
  Software Updater, the cache loaded and then I switched to the Ubuntu
  Software Tab. I then clicked the checkmark next to "software
  restricted by copyright or legal issues." I then clicked the Close
  button, and then the reload button.

  The window that shows the reload process became stuck and would not be
  dismissed, softlocking me in the update-manager app and forcing me to
  kill the application.

  Expected Results:
  Software Update applies the changes without issue and then quits, or throws 
and error if that is not possible and I made a mistake

  Actual Results:
  Software Update manager hangs ans softlocks me into forcing me to kill the 
process.

  Prior to the issue occurring, I ran "echo -e "deb
  http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted
  universe multiverse\ndeb http://ddebs.ubuntu.com $(lsb_release
  -cs)-proposed main restricted universe multiverse" | sudo tee -a
  /etc/apt/sources.list.d/ddebs.list" and then opened Software Update
  manager. I was attempting to follow the steps to debug on this URL:
  https://wiki.ubuntu.com/DebuggingProgramCrash

  However, I skipped the first step in adding the debug repositories and
  added the one in the second step before opening Software & Updates.

  Description: Ubuntu 19.10
  Release: 19.10

  software-properties-gtk:
Installed: 0.98.5
Candidate: 0.98.5
Version table:
   *** 0.98.5 500
  500 http://us.archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  500 http://us.archive.ubuntu.com/ubuntu eoan/main i386 Packages
  100 /var/lib/dpkg/status

  ProblemType: Crash
  DistroRelease: Ubuntu 19.10
  Package: software-properties-gtk 0.98.5
  ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7
  Uname: Linux 5.3.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Nov 27 11:34:09 2019
  ExecutablePath: /usr/bin/software-properties-gtk
  ExecutableTimestamp: 1562940163
  InstallationDate: Installed on 2019-11-20 (6 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  InterpreterPath: /usr/bin/python3.7
  PackageArchitecture: all
  ProcCmdline: /usr/bin/python3 /usr/bin/software-properties-gtk --open-tab 2 
--toplevel 67108867
  ProcCwd: /home/edwin
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
  Python3Details: /usr/bin/python3.7, Python 3.7.5, python3-minimal, 3.7.5-1
  PythonArgs: ['/usr/bin/software-properties-gtk', '--open-tab', '2', 
'--toplevel', '67108867']
  PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1
  SourcePackage: software-properties
  Title: software-properties-gtk crashed with TypeError in new_init(): could 
not convert value for property `transient_for' from DialogCacheOutdated to 
GtkWindow
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
  mtime.conffile..etc.apport.crashdb.conf: 2019-11-24T17:17:29.098099

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1854190/+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 1892014] Re: 18.04.14.7 regression: no alt_shift_toggle in XKBOPTIONS

2020-08-27 Thread Alkis Georgopoulos
Hi Gunnar, thank you for the feedback,

> Possibly console-setup could be modified again, so the default
shortcut depends on XDG_CURRENT_DESKTOP ("No toggling" for GNOME and
"Alt+Shift" for others). That way there wouldn't be a need to involve
ubiquity or other desktops.

When launching a console, XDG_CURRENT_DESKTOP isn't guaranteed to be
set. E.g. one can just switch to vt2 and login there, or one can run
`sudo -i` which doesn't preserve the XDG_* environment variables. Losing
the ability to type Greek because I used `sudo -i` wouldn't be
appropriate.

> Right. Super+Space is default on GNOME.

Up to now, /etc/default/keyboard allowed for defining a shortcut
GLOBALLY, and the console, the display managers, and all the desktop
environments respected that. Is supporting "a global shortcut" no longer
a Debian/Ubuntu goal?

> That's reasonably about personal preferences rather than geographical.

Well, the official Greek school books teach Alt+Shift for layout
toggling, so I'm not sure it can be called a "personal preference" and
not a geographical one. That said, I wouldn't mind if Linux decided to
globally endorse Win+Space, but AFAIK console doesn't support Win+Space
as an option yet.

> As regards the console, is there a use case which would be worth to
take into consideration where there is a need to switch to a non-latin
keyboard layout?

Normal PC usage is impossible without it. Some examples:

# Change directory to Desktop
cd "Επιφάνεια εργασίας"

# Edit a file
nano Αρχείο.txt

# Set a user's name
usermod -c Άλκης alkisg

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

Title:
  18.04.14.7 regression: no alt_shift_toggle in XKBOPTIONS

Status in console-setup package in Ubuntu:
  New
Status in ubiquity package in Ubuntu:
  New

Bug description:
  Up to ubuntu-mate-18.04.1.iso, everything was fine. Starting with
  18.04.2, XKB_OPTIONS does not contain "alt_shift_toggle" anymore and
  we cannot switch the keyboard layout to e.g. Greek using Alt+Shift.

  Reading the changelog, I see:

  $ ~/source/ubiquity$ git show 786a5325ef
  +console-setup (1.178ubuntu6) cosmic; urgency=medium
  +
  +  * keyboard-configuration.{config,templates}: There is no good default for
  +layout toggling, stop pretending there is.  Console users can set one
  +with dpkg-reconfigure or editing /etc/defaults/keyboard (LP: #1762952)

  I'm guessing that ubiquity duplicates some code from console-setup,
  and LP: #1762952 caused this regression.

  To reproduce:
  1) Start ubuntu-mate-18.04.1-desktop-amd64.iso
  2) Select Ελληνικά (Greek) and start installing Ubuntu using the default 
options
  3) Right after the keyboard layout step, run:
  $ grep XKBOPTIONS /etc/default/keyboard 
  XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll"
  4) Verify that you can switch to Greek with Alt+Shift

  Starting from ubuntu-mate-18.04.2-desktop-amd64.iso (.1=OK, .2=BAD), we 
cannot switch to Greek using Alt+Shift anymore:
  $ grep XKBOPTIONS /etc/default/keyboard 
  XKBOPTIONS="grp_led:scroll"

  Does ubiquity really expect the users to run `dpkg-reconfigure
  console-setup`?

  Note that selecting Greek in the syslinux menu produces the correct
  XKBOPTIONS, yet ubiquity overwrites them later on with the wrong ones.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1892014/+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 1854588] Re: gdebi-gtk calls pkexec inappropriately

2020-08-23 Thread Alkis Georgopoulos
The problem is not in firefox or mate, it's in gdebi-gtk, and
specifically in GDebiGtk.py, line 619:

os.execv(pkexec_cmd, pkexec_args+gdebi_args)

This replaces the current process with a pkexec call. This is not a
valid usage of pkexec, as pkexec requires the parent process to not be
init (ppid!=1).

To reproduce the issue without firefox, one can just run `setsid gdebi-
gtk package.deb`.

In a similar bug report for update-manager (LP: #1020115), this flag was
used instead of os.execv:

flags = GObject.SPAWN_DO_NOT_REAP_CHILD
https://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/UpdateManager/backend/InstallBackendSynaptic.py#L63

Is gdebi still maintained by Ubuntu developers, or should we report this in 
Debian?
Can we propose a patch similar to the update manager, or even just use a simple 
shell wrapper?

** Summary changed:

- Clicking 'Install' on gdebi-gtk makes it vanish ONLY when .deb opened from 
Chrome/Firefox
+ gdebi-gtk calls pkexec inappropriately

** No longer affects: firefox (Ubuntu)

** Project changed: ubuntu-mate => gdebi

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

Title:
  gdebi-gtk calls pkexec inappropriately

Status in gdebi:
  Confirmed
Status in gdebi package in Ubuntu:
  Confirmed

Bug description:
  Steps to reproduce:

  1. Have Ubuntu with gdebi-gtk installed
  2. Open Firefox
  3. Visit some site with deb-package download link or use direct link like 
https://github.com/jgm/pandoc/releases/download/2.9.2.1/pandoc-2.9.2.1-1-amd64.deb
  4. Proceed with file downloading
  5. In Firefox select Library → Downloads, click on downloaded deb-file

  Expected results:
  * gdebi-gtk is opened, the package installs normally after users clicks 
Install button

  Actual results:
  * gdebi-gtk is opened, the package is not installed because of vanishing of 
gdebi-gtk window just after clicking Install button


  

  Before anyone says this bug already exists... it doesn't (at least as
  far as I can see).  It's just that a lot of similar bugs do/did exist
  where people have also experienced the same symptoms (of gdebi-gtk
  vanishing upon clicking 'Install').

  So yes this is the same symptoms, but it must be a different cause as
  the circumstances are different and doesn't have the same resolution.

  The meat of it...

  Basically on a fresh install of Ubuntu MATE 18.04.3 amd64... with Firefox (or 
with Chrome if you installed that) go to any site that offers a .deb package 
and either...
  a) choose to open it directly from the browser (rather than saving it to 
'Downloads' folder)
  b) or... save the file (e.g. to the 'Downloads' folder), BUT!.. open that 
file from within the browser itself.

  You should find that gdebi-gtk appears but vanishes the moment you
  click 'Install' without a prompt for a password, an explanation or the
  package actually getting installed.

  This bug has existed since the beginning of Ubuntu 18.04 however it's
  been largely confused with other similar bugs.  I've had it on half a
  dozen machines and confirmed it exists with IRC users on #ubuntu-mate
  of freenode.

  However with *this* bug (compared to others) gdebi-gtk works perfectly
  fine if you run it from the terminal or just double click the .deb
  package from your file manager.

  It's the kind of bug which if you're a hardened desktop Linux user,
  you'd just work around it...

  But if you're a novice and you can't get a simple thing like
  Teamviewer installed (which is a .deb, and a thing I might ask someone
  to do over the phone to try to help them) you likely get fed up and
  re-install Windows :S

  Any input on this would be brilliant as I can't seem to get any
  logs/output.

  ~lantizia

To manage notifications about this bug go to:
https://bugs.launchpad.net/gdebi/+bug/1854588/+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 1762952] Re: Alternative shortcut for layout switching Alt+Shift unexpectedly set by default

2020-08-18 Thread Alkis Georgopoulos
Hi, this fix caused a regression in ubiquity: LP: #1892014

Ubiquity doesn't put alt_shift_toggle in XKBOPTIONS anymore, so we
cannot switch to e.g. Greek using Alt+Shift, after going through a
normal installation (or even in the live session).

Are users expected to manually run `dpkg-reconfigure keyboard-
configuration` right after a GUI installation of Ubuntu?

E.g. ubuntu-mate-18.04.2-desktop-amd64.iso is affected while 18.04.1
isn't.

Should this issue be resolved in console-setup or in ubiquity?

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

Title:
  Alternative shortcut for layout switching Alt+Shift unexpectedly set
  by default

Status in console-setup package in Ubuntu:
  Fix Released
Status in gnome-control-center package in Ubuntu:
  Invalid
Status in console-setup source package in Bionic:
  Fix Released
Status in gnome-control-center source package in Bionic:
  Invalid

Bug description:
  [Impact]

  The keyboard-configuration package provides a tool for configuring the
  keyboard via /etc/default/keyboard. However, there are desktop GUIs
  which provide such tools as well, and in the case of gnome-control-
  center it has another idea of what /etc/default/keyboard should
  contain. In short: The different tools don't play well together.

  The proposed upload does not claim to fix all issues with this
  incompatibility. But one of the annoyances is that a pure upgrade of
  the keyboard-configuration package may result in a changed keyboard
  configuration without the user asking for it. The proposed upload does
  address that particular issue on desktop systems.

  [Test Case]

  1. On an Ubuntu 18.04 system, make sure that the contents of
 /etc/default/keyboard is 'the g-c-c style', for instance:

 XKBLAYOUT=se,us
 BACKSPACE=guess
 XKBVARIANT=,

  2. Reboot.

  3. Upgrade to the version of the keyboard-configuration package in
 bionic-proposed.

  => Find that /etc/default/keyboard was not changed through the
  upgrade.

  4. Run the command

 sudo dpkg-reconfigure keyboard-configuration

  => Find that you are now offered to change your keyboard
  configuration.

  [Regression Potential]

  As a result of this upload, and unlike before, no keyboard
  configuration will happen behind the scenes on a desktop system due to
  an upgrade of the keyboard-configuration package. This is the desired
  change, and I can't think of a case when a user would want the
  configuration to be changed without having asked for it.

  [Original description]

  Version: Ubuntu 18.04 Final Beta with default Gnome Shell included in
  18.04

  Steps to reproduce:
  1. Define two keyboard input methods in Settings -> Region & Language -> 
Input Sources
  2. Open several applications
  3. Observe that application windows can be iterated with Alt + Tab
  4. Once application window iteration was begun with Alt + Tab, try to iterate 
backwards with Alt + Shift + Tab.
  5. Try to change keyboard input method switching hotkeys in Settings -> 
Region & Language -> Input Sources -> Options.
  6. Observe that Keyboard shortcut for "Alternative switch to next source" is 
set to "Alt + Shift" and that keyboard shortcuts can only be changed in 
Settings -> Devices -> Keyboard -> Keyboard Shortcuts.
  7. Observe that the shortcut for "Alternative switch to next source" is not 
available for configuration in Settings -> Devices -> Keyboard -> Keyboard 
Shortcuts.

  Actual state:
  * Performing step 4 does not select the previous app in application switcher 
but instead changes  keyboard input method.

  Expected state:
  * The shortcut for "Alternative switch to next source" can be changed and / 
or deactivated in Settings -> Devices -> Keyboard -> Keyboard Shortcuts.

  Notes:
  * The above was working fine in Ubuntu 17.10. I assume "Alternative switch to 
next source" did not exist in that version of Gnome Shell.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1762952/+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 1867908] Re: Fix RTM NEW/DELLINK IFLA_IFNAME copy for maximum ifname length

2020-04-16 Thread Alkis Georgopoulos
Thank you seb128! :)

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

Title:
  Fix RTM NEW/DELLINK IFLA_IFNAME copy for maximum ifname length

Status in wpa package in Ubuntu:
  Fix Committed
Status in wpa source package in Focal:
  Fix Committed

Bug description:
  Some wifi adapters kept asking for a password when MAC address
  randomization was enabled.

  I reported this to Realtek, and they gave me a patch for
  wpa_supplicant, which fixes the issue.

  I asked Realtek to report this upstream to wpasupplicant, and they
  did, the commit is:
  http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563

  It would be very nice to cherrypick that for Focal.

  I uploaded it as a merge request below, and I tested that it fixes the issue 
with adapters based on the following chipsets:
  ath9k, rtl8812au, rtl88x2bu and rtl8821cu

  To reproduce this:

  Ubuntu's network-manager defaults to "MAC randomization disabled", I think as 
a workaround to this specific issue. This is defined in two places:
  - wifi.scan-rand-mac-address=no in /etc/NetworkManager/NetworkManager.conf
  - Some specific drivers in 
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf.

  With these, the problem happens in around 10% of the cases.
  To be able to reproduce it in 100% of the cases, it's best to remove these 
Ubuntu workarounds. So:
  - Set "wifi.scan-rand-mac-address=yes" in 
/etc/NetworkManager/NetworkManager.conf
  - Remove /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf.
  - systemctl stop network-manager
  - killall wpa_supplicant
  - systemctl start network-manager

  Then insert a USB wifi adapter that results in a big name with 15
  characters like wlx74ee2ae2436a and try to connect to a wifi network.
  It will keep asking for a password.

  Then apply the patch, run the 3 commands above to restart network-
  manager, and verify that it can now connect properly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1867908/+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 1869716] Re: Removing libpango1.0-0 broke Minecraft Launcher

2020-03-31 Thread Alkis Georgopoulos
Anydesk too. Thanks for the fix! :)

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

Title:
  Removing  libpango1.0-0  broke Minecraft Launcher

Status in pango1.0 package in Ubuntu:
  Fix Committed

Bug description:
  I just updated my machine, and when I did libpango1.0-0 was removed.
  This removed minecraft-launcher - the (very) popular launcher for
  Minecraft Java edition.

  I have reported this upstream, in case they can update their package
  https://bugs.mojang.com/browse/MCL-13512

  I am filing this bug so we can track it internally. I personally think
  this shouldn't have been done this late in the cycle, but there may
  well have been good reasons for it.

  As a result of the change though, it's now not possible to install
  Minecraft on Ubuntu 20.04.

  $ sudo apt install ./Minecraft\(1\).deb 
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Note, selecting 'minecraft-launcher' instead of './Minecraft(1).deb'
  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.
   minecraft-launcher : Depends: libpango1.0-0 (>= 1.14.0) but it is not 
installable
  E: Unable to correct problems, you have held broken packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/1869716/+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 1867908] Re: Fix RTM NEW/DELLINK IFLA_IFNAME copy for maximum ifname length

2020-03-28 Thread Alkis Georgopoulos
Hi all,

final freeze is approaching, and I don't see anyone syncing Andrej's new
version from Debian...

Maybe it would be easier to just accept my patch, to have this solved
for 20.04, and do the syncing for 20.10?

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

Title:
  Fix RTM NEW/DELLINK IFLA_IFNAME copy for maximum ifname length

Status in wpa package in Ubuntu:
  Triaged

Bug description:
  Some wifi adapters kept asking for a password when MAC address
  randomization was enabled.

  I reported this to Realtek, and they gave me a patch for
  wpa_supplicant, which fixes the issue.

  I asked Realtek to report this upstream to wpasupplicant, and they
  did, the commit is:
  http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563

  It would be very nice to cherrypick that for Focal.

  I uploaded it as a merge request below, and I tested that it fixes the issue 
with adapters based on the following chipsets:
  ath9k, rtl8812au, rtl88x2bu and rtl8821cu

  To reproduce this:

  Ubuntu's network-manager defaults to "MAC randomization disabled", I think as 
a workaround to this specific issue. This is defined in two places:
  - wifi.scan-rand-mac-address=no in /etc/NetworkManager/NetworkManager.conf
  - Some specific drivers in 
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf.

  With these, the problem happens in around 10% of the cases.
  To be able to reproduce it in 100% of the cases, it's best to remove these 
Ubuntu workarounds. So:
  - Set "wifi.scan-rand-mac-address=yes" in 
/etc/NetworkManager/NetworkManager.conf
  - Remove /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf.
  - systemctl stop network-manager
  - killall wpa_supplicant
  - systemctl start network-manager

  Then insert a USB wifi adapter that results in a big name with 15
  characters like wlx74ee2ae2436a and try to connect to a wifi network.
  It will keep asking for a password.

  Then apply the patch, run the 3 commands above to restart network-
  manager, and verify that it can now connect properly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1867908/+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 1867315] [NEW] templates.dat is regenerated even without changes

2020-03-13 Thread Alkis Georgopoulos
Public bug reported:

Running for example `pam-auth-update` results in 
/var/cache/debconf/templates.{dat,dat-old} getting regenerated with no diff.
In focal live CD this file is 17 MB, so that wastes 34 MB of cow/tmpfs/RAM.
This also affects ltsp.org which too uses a live session.
And of course it makes debconf slower than it can be.

This was reported back in 2006 in LP #43706, but a workaround was
employed then, instead of pinpointing the underlying debconf issue.

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

** Description changed:

  Running for example `pam-auth-update` results in 
/var/cache/debconf/templates.{dat,dat-old} getting regenerated with no diff.
- In focal live CD this file is 17 MB, so that wastes 34 MB of cow/tmpfs.
+ In focal live CD this file is 17 MB, so that wastes 34 MB of cow/tmpfs/RAM.
  This also affects ltsp.org which too uses a live session.
  And of course it makes debconf slower than it can be.
  
  This was reported back in 2006 in LP #43706, but a workaround was
  employed then, instead of pinpointing the underlying debconf issue.

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

Title:
  templates.dat is regenerated even without changes

Status in debconf package in Ubuntu:
  New

Bug description:
  Running for example `pam-auth-update` results in 
/var/cache/debconf/templates.{dat,dat-old} getting regenerated with no diff.
  In focal live CD this file is 17 MB, so that wastes 34 MB of cow/tmpfs/RAM.
  This also affects ltsp.org which too uses a live session.
  And of course it makes debconf slower than it can be.

  This was reported back in 2006 in LP #43706, but a workaround was
  employed then, instead of pinpointing the underlying debconf issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1867315/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-07 Thread Alkis Georgopoulos
I checked with 20.04 and it appears that recent Ubuntu live CDs don't
have boot=casper anymore; they do still have initrd=/casper/initrd; but
anyway, ^/cow should be fine (sorry I hadn't noticed the ^ there
before).

Thank you for your work in this.

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  In Progress

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-07 Thread Alkis Georgopoulos
I commented before I saw the previous reply; I'll reply to that now.

The "grep cow" approach breaks the LTSP package and other software that uses a 
COW root.
To check for casper, please `grep -w boot=casper /proc/cmdline` or something 
casper-specific.

In schools, we sometimes have students of various nationalities. They're
not frequent enough to install whole langpacks for them, but they are
frequent enough to configure locales for them (locale-gen).

I do not see any reason to keep the Ubuntu-specific
04_language_handling.patch, when we know that it's causing issues and we
do not know its benefit. Of course it's your call. :)

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  In Progress

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-07 Thread Alkis Georgopoulos
Btw, lightdm doesn't set LANGUAGE at all in Debian; it only sets LANG,
like GDM, and everything works fine.

Gunnar, do you see any issues with just completely dropping your 
04_language_handling.patch?
Or at least this line there:

+session_set_env (session, "LANGUAGE", language);

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  In Progress

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-07 Thread Alkis Georgopoulos
I mean that if, on a normal 20.04 installation, I uninstall the el langpack, 
then
1) If I'm using GDM, universe apps show Greek,
2) If I'm using LightDM, universe apps show English (this one regressed in 
19.10).

If we're modifying LightDM, I suggest to modify LightDM to not set LANGUAGE at 
all, not just in live CDs.
This is what GDM does and it works fine everywhere.

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  New

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-06 Thread Alkis Georgopoulos
Gunnar, so if a MATE user doesn't have the langpack installed, he shouldn't 
have a translated session?
Why do we want to fix this only for Live CDs?

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  New

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-05 Thread Alkis Georgopoulos
The reason that this regression doesn't affect ubuntu-desktop, might be
that unlike LightDM, GDM doesn't have that Ubuntu-specific patch to use
/usr/share/language-tools/language-options.

So, I subscribed "lightdm (Ubuntu)" to the affected packages, in case we
just want to drop the Ubuntu-specific patch, and that way make lightdm
not pass LANGUAGE when it shouldn't.

I think that this won't address the source of the regression, but it
will make the problem not appear in flavors that use lightdm which
should be good enough.

** Also affects: lightdm (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed
Status in lightdm package in Ubuntu:
  New

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-02-01 Thread Alkis Georgopoulos
On a focal live cd, I tried to downgrade lightdm and accountsservice to
their bionic versions and restart their services without rebooting, yet
again the session was not translated. So I'm at a loss on which package
was the one that caused the change in 19.10, maybe even glibc itself.

Nevertheless, I was able to reproduce a similar problem in a normal
(non-live) focal installation, by just purging language-pack-el, or by
just moving aside the directory /usr/share/locale-langpack/el and
restarting accounts-daemon and lightdm.

Without the language pack, my LANGUAGE is "en" and my session is
untranslated. And if I launch d-feet and check
/org/freedesktop/Accounts/User1000 => org.freedesktop.Accounts.User =>
property Language, it says "en".

I think that is the problem, accountsservice should report that my
language is either "el" or empty, but definitely not "en". Even if the
langpack isn't there, LANG in /etc/default/locale is el_GR.UTF-8, and I
don't have "en" defined anywhere in my system or my account; and MATE
can show Greek even without a langpack.

I think then LightDM will work fine without any changes.
Does this approach sound OK?

** Changed in: accountsservice (Ubuntu)
   Status: Incomplete => Confirmed

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Confirmed

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-01-31 Thread Alkis Georgopoulos
I.e. from what I can see, the basic difference is that since 19.10,
something sets LANGUAGE=en.

While in the Italian session that has a langpack in the live iso,
LANGUAGE=it.

It's not /etc/default/locale, in all the cases only LANG is there and
not LANGUAGE.

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Incomplete

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-01-31 Thread Alkis Georgopoulos
Hi Gunnar, here are the results:

Output of Ubuntu MATE 20.04 today's daily build:

$ env | grep LANG
LANGUAGE=en
GDM_LANG=en
LANG=el_GR.UTF-8

$ locale -a
C
C.UTF-8
de_AT.utf8
de_BE.utf8
de_CH.utf8
de_DE.utf8
de_IT.utf8
de_LI.utf8
de_LU.utf8
el_GR.utf8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IL
en_IL.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
es_AR.utf8
es_BO.utf8
es_CL.utf8
es_CO.utf8
es_CR.utf8
es_CU
es_CU.utf8
es_DO.utf8
es_EC.utf8
es_ES.utf8
es_GT.utf8
es_HN.utf8
es_MX.utf8
es_NI.utf8
es_PA.utf8
es_PE.utf8
es_PR.utf8
es_PY.utf8
es_SV.utf8
es_US.utf8
es_UY.utf8
es_VE.utf8
fr_BE.utf8
fr_CA.utf8
fr_CH.utf8
fr_FR.utf8
fr_LU.utf8
it_CH.utf8
it_IT.utf8
POSIX
pt_BR.utf8
pt_PT.utf8
ru_RU.utf8
ru_UA.utf8

$ /usr/share/language-tools/language-options
de_CH
de_DE
en
en_AU
en_CA
en_GB
en_US
es_AR
es_CL
es_CO
es_CR
es_DO
es_EC
es_ES
es_MX
es_NI
es_PA
es_PE
es_PR
es_SV
es_US
es_UY
es_VE
fr_CA
fr_FR
it_IT
pt_BR
pt_PT
ru


Output of Ubuntu MATE 18.04.3 iso:

$ env | grep LANG
LANG=el_GR.UTF-8

$ locale -a
C
C.UTF-8
de_AT.utf8
de_BE.utf8
de_CH.utf8
de_DE.utf8
de_IT.utf8
de_LI.utf8
de_LU.utf8
el_GR.utf8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IL
en_IL.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
es_AR.utf8
es_BO.utf8
es_CL.utf8
es_CO.utf8
es_CR.utf8
es_CU
es_CU.utf8
es_DO.utf8
es_EC.utf8
es_ES.utf8
es_GT.utf8
es_HN.utf8
es_MX.utf8
es_NI.utf8
es_PA.utf8
es_PE.utf8
es_PR.utf8
es_PY.utf8
es_SV.utf8
es_US.utf8
es_UY.utf8
es_VE.utf8
fr_BE.utf8
fr_CA.utf8
fr_CH.utf8
fr_FR.utf8
fr_LU.utf8
it_CH.utf8
it_IT.utf8
POSIX
pt_BR.utf8
pt_PT.utf8
ru_RU.utf8
ru_UA.utf8
zh_CN.utf8
zh_SG.utf8

$ /usr/share/language-tools/language-options
de_CH
de_DE
en
en_AU
en_CA
en_GB
en_US
es_AR
es_CL
es_CO
es_CR
es_DO
es_EC
es_ES
es_MX
es_NI
es_PA
es_PE
es_PR
es_SV
es_US
es_UY
es_VE
fr_CA
fr_FR
it_IT
pt_BR
pt_PT
ru
zh_CN

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Incomplete

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-01-31 Thread Alkis Georgopoulos
No, sorry, that's not it, I removed it and restarted lightdm and I still
had LANGUAGE=en in the live session.

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Incomplete

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-01-31 Thread Alkis Georgopoulos
In Ubuntu 20.04 live CD, in .xsession-errors, I see this line:

dbus-update-activation-environment: setting LANGUAGE=en

Maybe that's to blame here; looking more...

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Incomplete

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] Re: language-options causes live CD sessions to be untranslated

2020-01-31 Thread Alkis Georgopoulos
Gunnar, yes, the live sessions are properly translated up to and including 
19.04 (and of course 18.04 too).
Starting from 19.10, all child processes of lightdm have LANGUAGE=en, so the 
session is untranslated. But this only happens for languages that don't have 
the langpack installed.

Running /usr/share/language-tools/language-options in the Ubuntu 18.04
live CD does NOT show el_GR in the output though.

But if that script hasn't changed, and lightdm hasn't changed... what
did change and broke this in the 19.10 live CDs? :/

I wonder if the lightdm patch changed, and it used to call locale -a,
and it was changed to call the language-options script in 19.10.

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  Incomplete

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1861481] [NEW] language-options causes live CD sessions to be untranslated

2020-01-31 Thread Alkis Georgopoulos
Public bug reported:

Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g. MATE
and Xubuntu), if a user selects a language in syslinux other than those
with an included langpack, the session is then untranslated.

For example, if one boots Ubuntu MATE 20.04 and selects Greek in
syslinux, he ends up with LANGUAGE=en in the session.

The chain of events is:
LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
`locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
But language-options doesn't list el_GR, so it fools LightDM into thinking that 
Greek aren't supported; while they're all there, since e.g. MATE doesn't rely 
on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

I believe the correct fix would be for language-options to list el_GR on
live CDs (to merge the output of locale -a in its output).

Thanks!

** Affects: accountsservice (Ubuntu)
 Importance: High
 Status: New


** Tags: rls-ff-incoming

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

Title:
  language-options causes live CD sessions to be untranslated

Status in accountsservice package in Ubuntu:
  New

Bug description:
  Since Ubuntu 19.10, for all Ubuntu live CDs that use LightDM (e.g.
  MATE and Xubuntu), if a user selects a language in syslinux other than
  those with an included langpack, the session is then untranslated.

  For example, if one boots Ubuntu MATE 20.04 and selects Greek in
  syslinux, he ends up with LANGUAGE=en in the session.

  The chain of events is:
  LightDM has an Ubuntu-specific patch that makes it call 
/usr/share/language-tools/language-options instead of the upstream `locale -a`.
  `locale -a` does list el_GR as a supported locale because casper correctly 
updated the locales.
  But language-options doesn't list el_GR, so it fools LightDM into thinking 
that Greek aren't supported; while they're all there, since e.g. MATE doesn't 
rely on langpacks; mate-panel.mo and mate-calc.mo etc are all there.

  I believe the correct fix would be for language-options to list el_GR
  on live CDs (to merge the output of locale -a in its output).

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481/+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 1051288] Re: LightDM assumes there's only ONE system default layout

2019-12-22 Thread Alkis Georgopoulos
Are you still using lightdm there? Ubuntu 19.10 uses GDM; only some
other flavors like MATE, Xubuntu and Lubuntu use lightdm.

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

Title:
  LightDM assumes there's only ONE system default layout

Status in Light Display Manager:
  Triaged
Status in lightdm package in Ubuntu:
  Triaged

Bug description:
  In Greece, the default system layout is "us,gr":
  $ grep XKBLAYOUT /etc/default/keyboard 
  XKBLAYOUT="us,gr"

  For new users that don't have .dmrc or accountsservice entries and are 
supposed to get the system defaults, LightDM assumes their keyboard layout is 
"us".
  So they can't switch languages in the greeter and they can't input national 
characters until they login, go to gnome settings and manually set the keyboard 
layout.

  A similar bug was
  https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/919200, but
  that was only solved for the single-layout case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1051288/+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 1855492] [NEW] Please drop LTSP specific Ubuntu diff

2019-12-06 Thread Alkis Georgopoulos
Public bug reported:

Hi, I'm upstream and Debian/Ubuntu maintainer for LTSP.
In the past, LTSP required some patches in isc-dhcp-server and tftpd-hpa.
Since Bullseye and Focal these are no longer needed and they should be dropped.

Specifically, LTSP now defaults to dnsmasq, and in the case where users
need isc-dhcp-server instead, the LTSP wiki (https://ltsp.org/advanced
/isc-dhcp-server/) proposes manually editing the appropriate file. We do
not ship an /etc/ltsp/dhcpd.conf file anymore at all.

Thank you.

** Affects: isc-dhcp (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Please drop LTSP specific Ubuntu diff

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  Hi, I'm upstream and Debian/Ubuntu maintainer for LTSP.
  In the past, LTSP required some patches in isc-dhcp-server and tftpd-hpa.
  Since Bullseye and Focal these are no longer needed and they should be 
dropped.

  Specifically, LTSP now defaults to dnsmasq, and in the case where
  users need isc-dhcp-server instead, the LTSP wiki
  (https://ltsp.org/advanced/isc-dhcp-server/) proposes manually editing
  the appropriate file. We do not ship an /etc/ltsp/dhcpd.conf file
  anymore at all.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1855492/+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 1854588] Re: Clicking 'Install' on gdebi-gtk makes it vanish ONLY when .deb opened from Chrome/Firefox

2019-11-30 Thread Alkis Georgopoulos
The following workaround doesn't remove anything and allows the wrapper
to survive updates:

sudo -i
printf '#!/bin/sh\n\n/usr/share/gdebi/gdebi-gtk "$@"\n' > 
/usr/local/bin/gdebi-gtk
chmod +x /usr/local/bin/gdebi-gtk
exit

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

Title:
  Clicking 'Install' on gdebi-gtk makes it vanish ONLY when .deb opened
  from Chrome/Firefox

Status in Ubuntu MATE:
  New
Status in gdebi package in Ubuntu:
  New

Bug description:
  Before anyone says this bug already exists... it doesn't (at least as
  far as I can see).  It's just that a lot of similar bugs do/did exist
  where people have also experienced the same symptoms (of gdebi-gtk
  vanishing upon clicking 'Install').

  So yes this is the same symptoms, but it must be a different cause as
  the circumstances are different and doesn't have the same resolution.

  The meat of it...

  Basically on a fresh install of Ubuntu MATE 18.04.3 amd64... with Firefox (or 
with Chrome if you installed that) go to any site that offers a .deb package 
and either...
  a) choose to open it directly from the browser (rather than saving it to 
'Downloads' folder)
  b) or... save the file (e.g. to the 'Downloads' folder), BUT!.. open that 
file from within the browser itself.

  You should find that gdebi-gtk appears but vanishes the moment you
  click 'Install' without a prompt for a password, an explanation or the
  package actually getting installed.

  This bug has existed since the beginning of Ubuntu 18.04 however it's
  been largely confused with other similar bugs.  I've had it on half a
  dozen machines and confirmed it exists with IRC users on #ubuntu-mate
  of freenode.

  However with *this* bug (compared to others) gdebi-gtk works perfectly
  fine if you run it from the terminal or just double click the .deb
  package from your file manager.

  It's the kind of bug which if you're a hardened desktop Linux user,
  you'd just work around it...

  But if you're a novice and you can't get a simple thing like
  Teamviewer installed (which is a .deb, and a thing I might ask someone
  to do over the phone to try to help them) you likely get fed up and
  re-install Windows :S

  Any input on this would be brilliant as I can't seem to get any
  logs/output.

  ~lantizia

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-mate/+bug/1854588/+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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2019-11-11 Thread Alkis Georgopoulos
** No longer affects: epoptes (Ubuntu)

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

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  New
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  New
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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 183303] Re: Can't create new wireless network using mac80211 based drivers

2019-10-03 Thread Alkis Georgopoulos
** No longer affects: ltsp (Ubuntu)

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

Title:
  Can't create new wireless network using mac80211 based drivers

Status in NetworkManager:
  Unknown
Status in linux package in Ubuntu:
  Won't Fix
Status in network-manager package in Ubuntu:
  Invalid
Status in wpasupplicant package in Ubuntu:
  Fix Released
Status in network-manager package in Debian:
  Fix Released

Bug description:
  I am trying to create a new wireless network (particularly, with no
  encryption) with the gnome applet. However, I just get the message
  "Trying to connect to wireless network  «(null)»". Then, after a
  couple of minutes or so, it gets back to the cabled connection and no
  wireless connection is created.

  I am using Gutsy, network-manager 0.6.5-0ubuntu16.7.10.0 and network-
  manager-gnome 0.6.5-0ubuntu11~7.10.0.

  Updated description: The original reporter used ipw2200, but for that driver 
a bug has already been reported for this isse: Bug #75358. 
  This bug now addresses users with mac20811-based drivers, since the majority 
of the commenters have such cards/drivers.

  The bug has persisted in Gutsy, Hardy, Intrepid and even Jaunty RC...

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/183303/+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 1815172] Re: [bionic] drm/i915: softpin broken, needs to be fixed for 32bit mesa

2019-09-16 Thread Alkis Georgopoulos
Hi Timo,

if I remember correctly, there were some schools that were affected by this 
issue, but I wasn't able to reproduce it in the office due to lack of similar 
hardware.
Unfortunately it's not easy to check which were those schools; but I can keep 
an eye on this issue, in case I hear about black screens in the near future

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

Title:
  [bionic] drm/i915: softpin broken, needs to be fixed for 32bit mesa

Status in Mesa:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in mesa source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Won't Fix
Status in mesa source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  Several schools reported black screens after normally updating their Ubuntu 
boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

  This is caused by mesa assuming that soft-pinning on GEN8+ is working
  since kernel 4.5, but in fact this issue wasn't fixed until 4.19.3. So
  a proper fix would be to backport commits from 4.19.3/4.20 to fix GTT
  sizes/pin flags, but that's left for future.

  [Test case]
  install fixed mesa or kernel, check that the regression is fixed

  [Regression potential]
  mesa: shouldn't be any, it just reverts the change to always soft-pin
  (TODO kernel: adds commits from upstream stable, which have been well tested 
upstream by now)

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1840965] Re: dhclient initramfs code writes invalid net-eth0.conf

2019-09-07 Thread Alkis Georgopoulos
** No longer affects: initramfs-tools (Ubuntu)

** No longer affects: initramfs-tools (Ubuntu Eoan)

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

Title:
  dhclient initramfs code writes invalid net-eth0.conf

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Eoan:
  Fix Released

Bug description:
  Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in 
initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is 
generated, with unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

  This file is sourced by initramfs-tools/init in various places, and produces 
the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

  Here is the erroneous file that dhclient-enter-hooks.d/config produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=

  Here is the correct one that ipconfig produces:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''

  I.e. please either fix dhclient-enter-hooks.d/config, or revert the
  ipconfig => dhclient change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1840965/+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 1840965] Re: dhclient initramfs code writes invalid net-eth0.conf

2019-08-27 Thread Alkis Georgopoulos
I uploaded my patch as a merge proposal instead.

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

Title:
  dhclient initramfs code writes invalid net-eth0.conf

Status in initramfs-tools package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Triaged
Status in initramfs-tools source package in Eoan:
  New
Status in isc-dhcp source package in Eoan:
  Triaged

Bug description:
  Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in 
initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is 
generated, with unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

  This file is sourced by initramfs-tools/init in various places, and produces 
the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

  Here is the erroneous file that dhclient-enter-hooks.d/config produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=

  Here is the correct one that ipconfig produces:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''

  I.e. please either fix dhclient-enter-hooks.d/config, or revert the
  ipconfig => dhclient change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1840965/+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 1840965] Re: dhclient initramfs code writes invalid net-eth0.conf

2019-08-27 Thread Alkis Georgopoulos
I just noticed that the original script used tabs instead of spaces;
I'm attaching a new .diff that respects that.

** Patch removed: "isc-dhcp.diff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1840965/+attachment/5284861/+files/isc-dhcp.diff

** Patch added: "isc-dhcp.diff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1840965/+attachment/5284863/+files/isc-dhcp.diff

** Tags added: patch

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

Title:
  dhclient initramfs code writes invalid net-eth0.conf

Status in initramfs-tools package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Triaged
Status in initramfs-tools source package in Eoan:
  New
Status in isc-dhcp source package in Eoan:
  Triaged

Bug description:
  Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in 
initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is 
generated, with unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

  This file is sourced by initramfs-tools/init in various places, and produces 
the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

  Here is the erroneous file that dhclient-enter-hooks.d/config produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=

  Here is the correct one that ipconfig produces:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''

  I.e. please either fix dhclient-enter-hooks.d/config, or revert the
  ipconfig => dhclient change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1840965/+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 1840965] Re: dhclient initramfs code writes invalid net-eth0.conf

2019-08-26 Thread Alkis Georgopoulos
I'm attaching a patch for dhclient-enter-hooks.d/config.
I thought to imitate ipconfig and write all values even if they're empty.

For the debian/dhclient-script.* scripts which use chmod/chown parameters that 
aren't available in busybox, it might be best to just omit them, or use `cp/rm` 
instead of `chown/mv`.
`cp` is supposed to preserve target attributes etc, so it'll work in a real 
system, even if `busybox cp` doesn't do that.

** Patch added: "isc-dhcp.diff"
   
https://bugs.launchpad.net/netplan/+bug/1840965/+attachment/5284861/+files/isc-dhcp.diff

** No longer affects: netplan

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

Title:
  dhclient initramfs code writes invalid net-eth0.conf

Status in initramfs-tools package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Triaged
Status in initramfs-tools source package in Eoan:
  New
Status in isc-dhcp source package in Eoan:
  Triaged

Bug description:
  Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in 
initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is 
generated, with unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

  This file is sourced by initramfs-tools/init in various places, and produces 
the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

  Here is the erroneous file that dhclient-enter-hooks.d/config produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=

  Here is the correct one that ipconfig produces:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''

  I.e. please either fix dhclient-enter-hooks.d/config, or revert the
  ipconfig => dhclient change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1840965/+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 1840965] Re: netplan initramfs code writes invalid net-eth0.conf

2019-08-26 Thread Alkis Georgopoulos
The code that generates the invalid /run/net-enp0s3.conf belongs in the
Ubuntu isc-dhcp package, and specifically in debian/initramfs-
tools/lib/etc/dhcp/dhclient-enter-hooks.d/config.

It got in effect in 18.10 when initramfs-tools in Ubuntu switched to
calling dhclient instead of ipconfig.

Additionally, dhclient-script calls `chmod --reference=/etc/resolv.conf
$new_resolv_conf`, but busybox chmod doesn't support the --reference
parameter.

I.e. dhclient has numerous issues that need to be fixed, otherwise the
ipconfig => dhclient change should be reverted...

Thank you.

** Also affects: isc-dhcp (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

- While netbooting, in initramfs-tools/scripts/functions, netplan for some
- reason tries to overwrite /run/net-enp0s3.conf that is initially and
- correctly generated by ipconfig.
- 
- There, it writes unquoted values like the following, which are a shell syntax 
error:
+ Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in 
initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is 
generated, with unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3
  
- Then, initramfs-tools/init tries to source that in various places, and 
produces the following message a lot of times:
+ This file is sourced by initramfs-tools/init in various places, and produces 
the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found
  
  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.
  
- Here is the erroneous file that netplan produces:
+ Here is the erroneous file that dhclient-enter-hooks.d/config produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=
  
- Here is the correct one that ipconfig initially produces, before getting 
overwritten:
+ Here is the correct one that ipconfig produces:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''
  
- Thank you.
+ I.e. please either fix dhclient-enter-hooks.d/config, or revert the
+ ipconfig => dhclient change.

** Summary changed:

- netplan initramfs code writes invalid net-eth0.conf
+ dhclient initramfs code writes invalid net-eth0.conf

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

Title:
  dhclient initramfs code writes invalid net-eth0.conf

Status in netplan:
  New
Status in initramfs-tools package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in 
initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is 
generated, with unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

  This file is sourced by initramfs-tools/init in various places, and produces 
the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

  Here is the erroneous file that dhclient-enter-hooks.d/config produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=

  Here is the correct one that ipconfig produces:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''

  I.e. please either fix dhclient-enter-hooks.d/config, or revert the
  ipconfig => dhclient change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1840965/+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 1840965] Re: netplan initramfs code writes invalid net-eth0.conf

2019-08-21 Thread Alkis Georgopoulos
Using Ubuntu live CDs, I verified that this did not happen in 18.04 and
happens in both 18.10 and 19.04.

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

Title:
  netplan initramfs code writes invalid net-eth0.conf

Status in netplan:
  New
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  While netbooting, in initramfs-tools/scripts/functions, netplan for
  some reason tries to overwrite /run/net-enp0s3.conf that is initially
  and correctly generated by ipconfig.

  There, it writes unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

  Then, initramfs-tools/init tries to source that in various places, and 
produces the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

  Here is the erroneous file that netplan produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=

  Here is the correct one that ipconfig initially produces, before getting 
overwritten:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1840965/+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 1840965] [NEW] netplan initramfs code writes invalid net-eth0.conf

2019-08-21 Thread Alkis Georgopoulos
Public bug reported:

While netbooting, in initramfs-tools/scripts/functions, netplan for some
reason tries to overwrite /run/net-enp0s3.conf that is initially and
correctly generated by ipconfig.

There, it writes unquoted values like the following, which are a shell syntax 
error:
IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

Then, initramfs-tools/init tries to source that in various places, and produces 
the following message a lot of times:
/init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

I.e. values should be quoted, and 2 DNS entries should go in
IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

Here is the erroneous file that netplan produces:
DEVICE=enp0s3
PROTO=dhcp
IPV4PROTO=dhcp
IPV4ADDR=10.161.254.38
IPV4NETMASK=255.255.255.0
IPV4BROADCAST=10.161.254.255
IPV4GATEWAY=10.161.254.1
IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
ROOTSERVER=10.161.254.1
HOSTNAME=
DNSDOMAIN=

Here is the correct one that ipconfig initially produces, before getting 
overwritten:
DEVICE='enp0s3'
PROTO='dhcp'
IPV4ADDR='10.161.254.38'
IPV4BROADCAST='10.161.254.255'
IPV4NETMASK='255.255.255.0'
IPV4GATEWAY='10.161.254.1'
IPV4DNS0='194.63.237.4'
IPV4DNS1='194.63.239.164'
HOSTNAME=''
DNSDOMAIN=''
NISDOMAIN=''
ROOTSERVER='10.161.254.1'
ROOTPATH=''
filename=''
UPTIME='594'
DHCPLEASETIME='25200'
DOMAINSEARCH=''

Thank you.

** Affects: netplan
 Importance: Undecided
 Status: New

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  While netbooting, in initramfs-tools/scripts/functions, netplan for some
  reason tries to overwrite /run/net-enp0s3.conf that is initially and
  correctly generated by ipconfig.
  
  There, it writes unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3
  
  Then, initramfs-tools/init tries to source that in various places, and 
produces the following message a lot of times:
- /init: /run/net-enp0s3.conf: line 8: 1.2.32: not found
+ /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found
  
  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.
  
  Here is the erroneous file that netplan produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=
- 
  
  Here is the correct one that ipconfig initially produces, before getting 
overwritten:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''
  
  Thank you.

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

Title:
  netplan initramfs code writes invalid net-eth0.conf

Status in netplan:
  New
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  While netbooting, in initramfs-tools/scripts/functions, netplan for
  some reason tries to overwrite /run/net-enp0s3.conf that is initially
  and correctly generated by ipconfig.

  There, it writes unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

  Then, initramfs-tools/init tries to source that in various places, and 
produces the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

  Here is the erroneous file that netplan produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=

  Here is the correct one that ipconfig initially produces, before getting 
overwritten:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''

  Thank you.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 1815172] Re: Black screen on skylake after 18.0 => 18.2 update

2019-03-13 Thread Alkis Georgopoulos
Exactly. I did the "verification-done-bionic" step for 18.2.2 in comment
#12 above; and unfortunately I don't have an affected school nearby,
where I could test 18.2.8 in cosmic, and installing cosmic in a remote
school would be hard.

Thanks a lot Timo!

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

Title:
  Black screen on skylake after 18.0 => 18.2 update

Status in Mesa:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  New
Status in mesa source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  New
Status in mesa source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]
  Several schools reported black screens after normally updating their Ubuntu 
boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

  This is caused by mesa assuming that soft-pinning on GEN8+ is working
  since kernel 4.5, but in fact this issue wasn't fixed until 4.19.3. So
  a proper fix would be to backport commits from 4.19.3/4.20 to fix GTT
  sizes/pin flags, but that's left for future.

  [Test case]
  install fixed mesa or kernel, check that the regression is fixed

  [Regression potential]
  mesa: shouldn't be any, it just reverts the change to always soft-pin
  (TODO kernel: adds commits from upstream stable, which have been well tested 
upstream by now)

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :

2019-02-28 Thread Alkis Georgopoulos
A workaround to avoid rebuilding the initramfs is to use TWO
initramfs's. The second one contains just a symlink from scripts/casper-
bottom/25disable_cdrom.mount to /bin/true. I.e.:

cd $(mktemp -d)
mkdir -p scripts/casper-bottom/
ln -s /bin/true scripts/casper-bottom/25disable_cdrom.mount
find . | cpio -o -H newc | gzip > initrd-1755863.img

Copy the generated initrd-1755863.img to your TFTP/HTTP server, and pass
it in the kernel cmdline. In iPXE vernacular:

kernel /images/cdrom/casper/vmlinuz initrd=initrd.lz initrd=initrd-1755863.img 
boot=casper netboot=nfs nfsroot=10.161.254.11:/cdrom 
file=/cdrom/preseed/ubuntu.seed -- 
initrd /images/cdrom/casper/initrd.lz
initrd /liveclone/initrd-1755863.img

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

Title:
  netbooting the bionic live CD over NFS goes straight to maintenance
  mode :

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Triaged
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  Mounting manually a network share (NFS) and masking it breaks the state of 
other units (and their dependencies).
  Casper is masking a mounted NFS share, blocking the normal boot process as 
described in the original description, but the issue comes from systemd.

  [Test Case]

  - NFS mount point at /media
  root@iscsi-bionic:/home/ubuntu# mount | grep media
  10.230.56.72:/tmp/mnt on /media type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72)

  - Test mount point (/test) defined in /etc/fstab:
  root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test
  tmpfs /test tmpfs nosuid,nodev 0 0

  1. If media.mount is not masked, everything works fine:

  root@iscsi-bionic:/home/ubuntu# mount | grep test
  root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active
 Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days 
ago
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test

  2. If media.mount is masked, other mounts are failing:

  root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount
  Created symlink /etc/systemd/system/media.mount → /dev/null.
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active
 Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s 
ago
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl start test.mount
  Job for test.mount failed.
  See "systemctl status test.mount" and "journalctl -xe" for details.
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount
  root@iscsi-bionic:/home/ubuntu# mount | grep test
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)
  tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime)

  [Regression potential]

  Minimal. Originally, one failing mount point blocked the processing of
  the rest due to how the return codes were handled for every line in
  /proc/self/mountinfo. This patch removes this "dependency" and keeps
  the failure local to the affected mount point, allowing the rest to be
  processed normally.

  [Other Info]

  Upstream bug: https://github.com/systemd/systemd/issues/10874
  Fixed upstream with commit: 

[Touch-packages] [Bug 1815172]

2019-02-14 Thread Alkis Georgopoulos
Just correcting a wrong comment (#2) I made:
> It happens on both 32bit and 64bit installations.

I asked the school that reported the issue on 64bit to check again, and
they said they have a 32bit installation after all.

So the problem has only been reported in 32bit installations; I don't
know if it happened on 64bit. And btw everything is fixed now, thanks
again to all. :)

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

Title:
  Black screen on skylake after 18.0 => 18.2 update

Status in Mesa:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in mesa source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  New
Status in mesa source package in Cosmic:
  Fix Committed

Bug description:
  Several schools reported black screens after normally updating their
  Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1815172]

2019-02-09 Thread Alkis Georgopoulos
I tried a small kernel bisection using the ubuntu kernel binaries,
4.19.2-041902=fails,
4.19.3-041903=works

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

Title:
  Black screen on skylake after 18.0 => 18.2 update

Status in Mesa:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in mesa source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  New
Status in mesa source package in Cosmic:
  Fix Committed

Bug description:
  Several schools reported black screens after normally updating their
  Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1815172]

2019-02-09 Thread Alkis Georgopoulos
I don't know the software stacks involved:

If I understood it correctly,
mesa 18.3.3 doesn't work with older kernels while 18.0 did work,
and so I'll do a bisection to see which kernel commit fixes the issue,
and then distro kernel maintainers may cherrypick it for older kernels.

If there's no need for mesa to work with older kernels without the
cherrypicked commit, then I guess yes, this issue should be closed, in
which case please close it for me or tell me to close it.

Thanks again!

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

Title:
  Black screen on skylake after 18.0 => 18.2 update

Status in Mesa:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in mesa source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  New
Status in mesa source package in Cosmic:
  Fix Committed

Bug description:
  Several schools reported black screens after normally updating their
  Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1815172]

2019-02-09 Thread Alkis Georgopoulos
Hello Sergii,

I tried with 4.20.7 and it appears to work fine! Thanks!

Output of the commands:

# uname -a
Linux srv-6gym-chalk 4.20.7-042007-generic #201902061234 SMP Wed Feb 6 17:49:39 
UTC 2019 i686 i686 i686 GNU/Linux

# file /usr/bin/glxinfo
/usr/bin/glxinfo: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, 
BuildID[sha1]=6cef7eab38835376734bdc80c5ab1ee786a6157a, stripped

# glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) x86/MMX/SSE2 
(0x1912)   
Version: 18.3.3
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) 
x86/MMX/SSE2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 18.3.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

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

Title:
  Black screen on skylake after 18.0 => 18.2 update

Status in Mesa:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in mesa source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  New
Status in mesa source package in Cosmic:
  Fix Committed

Bug description:
  Several schools reported black screens after normally updating their
  Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1815172]

2019-02-09 Thread Alkis Georgopoulos
I just tried with 4.18.0-14-generic, the same issue happens there as
well.

And, another school reported the issue on HD Graphics 630:

root@pc02:~# lspci -nn -k | grep -A 2 VGA 00:02.0 VGA compatible
controller [0300]: Intel Corporation HD Graphics 630 [8086:5912] (rev
04) Subsystem: ASRock Incorporation HD Graphics 630 [1849:5912]
Kernel driver in use: i915

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

Title:
  Black screen on skylake after 18.0 => 18.2 update

Status in Mesa:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in mesa source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  New
Status in mesa source package in Cosmic:
  Fix Committed

Bug description:
  Several schools reported black screens after normally updating their
  Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1815172] Re: Black screen on skylake after 18.0 => 18.2 update

2019-02-08 Thread Alkis Georgopoulos
I verify that the bionic-proposed package addresses the issue.

Tested in:
# lspci -nn -k | grep -A 2 VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 
[8086:5912] (rev 04)
Subsystem: Gigabyte Technology Co., Ltd HD Graphics 630 [1458:d000]
Kernel driver in use: i915


** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

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

Title:
  Black screen on skylake after 18.0 => 18.2 update

Status in Mesa:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  New
Status in linux source package in Bionic:
  New
Status in mesa source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  New
Status in mesa source package in Cosmic:
  Fix Committed

Bug description:
  Several schools reported black screens after normally updating their
  Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1815172] [NEW] Black screen on skylake after 18.0 => 18.2 update

2019-02-08 Thread Alkis Georgopoulos
Public bug reported:

Several schools reported black screens after normally updating their
Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

Downgrading mesa fixes the problem.

lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

Unfortunately I can't find a lot of useful information, here are some bits:
 * systemctl --failed says "gpu-manager" and "lightdm" have failed
 * Xorg.log is clean: https://termbin.com/6l2b
 * dmesg too: https://termbin.com/ip4e
 * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
 * If one runs `xinit` from ssh, it fails with:
i965: Failed to submit batchbuffer: Invalid argument

** Affects: mesa
 Importance: Unknown
 Status: Unknown

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

** Affects: mesa (Ubuntu Bionic)
 Importance: Undecided
 Assignee: Timo Aaltonen (tjaalton)
 Status: New

** Affects: mesa (Ubuntu Cosmic)
 Importance: Undecided
 Assignee: Timo Aaltonen (tjaalton)
 Status: New

** Bug watch added: freedesktop.org Bugzilla #109583
   https://bugs.freedesktop.org/show_bug.cgi?id=109583

** Also affects: mesa via
   https://bugs.freedesktop.org/show_bug.cgi?id=109583
   Importance: Unknown
   Status: Unknown

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

Title:
  Black screen on skylake after 18.0 => 18.2 update

Status in Mesa:
  Unknown
Status in mesa package in Ubuntu:
  New
Status in mesa source package in Bionic:
  New
Status in mesa source package in Cosmic:
  New

Bug description:
  Several schools reported black screens after normally updating their
  Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

  Downgrading mesa fixes the problem.

  lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
  Graphics 530 [8086:1912] (rev 06) Subsystem: ASUSTeK Computer
  Inc. HD Graphics 530 [1043:8694]Kernel modules: i915

  Unfortunately I can't find a lot of useful information, here are some bits:
   * systemctl --failed says "gpu-manager" and "lightdm" have failed
   * Xorg.log is clean: https://termbin.com/6l2b
   * dmesg too: https://termbin.com/ip4e
   * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
   * If one runs `xinit` from ssh, it fails with:
  i965: Failed to submit batchbuffer: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815172/+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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2018-03-29 Thread Alkis Georgopoulos
For the maintainers of the affected packages to be able to help in this issue,
addressing the main question already stated above would be most helpful:

To support netplan, do we have to implement netlink events listeners ourselves?
I'm not sure all maintainers are willing to do that.
Or is there another package that provides this functionality that we could rely 
on?
E.g. NetworkManager does have a dispatcher.d directory that we can use, but 
does Ubuntu ship something similar (networkd-dispatcher?) in systems that don't 
use NetworkManager?

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

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Confirmed
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  New
Status in epoptes package in Ubuntu:
  New
Status in ethtool package in Ubuntu:
  New
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  New
Status in ntp package in Ubuntu:
  New
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  New
Status in openvpn package in Ubuntu:
  New
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 1751011] Re: bash crashes in qemu-user environments (bionic)

2018-03-27 Thread Alkis Georgopoulos
Another use case is in LTSP, where we debootstrap an armhf chroot to netboot 
raspberrypi clients.
This currently fails in 18.04.

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

Title:
  bash crashes in qemu-user environments (bionic)

Status in bash package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Confirmed
Status in bash package in Debian:
  Fix Released

Bug description:
  Attempts to launch bash in an arm64 qemu-user environment in bionic
  results in the following error message:

  bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes
  allocated)

  This causes any qemu/chroot based bootstrapping to fail as many
  packages invoke bash during postinst.

  Version: bash_4.4.18-1ubuntu1_arm64
  Release: 18.04 pre-release

  QEMU: 2.8.0

  This appears to have been reported and fixed in the corresponding
  Debian package (https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=889869)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1751011/+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 696435] Re: wait-for-root fails to detect nbd root

2017-11-11 Thread Alkis Georgopoulos
I'm the bug reporter, and I have a problem in doing the verification.

a) The initial testcase that I reported happens in both 4.4 unpatched
and 4.10. I.e. the bug that I reported is not yet fixed.

b) Some Ubuntu developer wrote a new testcase as part of doing the SRU.
I cannot reproduce that testcase neither in 4.4 unpatched nor in 4.10,
i.e. `udevadm monitor` does show add/change events for nbd devices for
me in both kernels. I.e. that sounds like a different bug that I never
saw.

So I'm not sure how I can help here...

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

Title:
  wait-for-root fails to detect nbd root

Status in linux package in Ubuntu:
  Fix Released
Status in nbd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  [Impact]
  Kernel does not generate any events when ndb-client connects /dev/nbd0 
devices, therefore it is impossible to monitor/react to the state of /dev/nbd0.

  [Fix]
  Generate change uevent when size of /dev/nbd0 changes

  [Testcase]
  * Start udevadm monitor
  * modprobe nbd
  * use ndb-client to connect something to /dev/nbd0
  * observe that there are change udev events generated on /dev/nbd0 itself

  [Regression Potential]
  There is no change to existing uevents, or their ordering.
  There is now an addition change event which will cause systemd to mark ndb 
devices as ready and trigger appropriate actions

  [Original Bug Report]

  When using an nbd root, wait-for-root blocks for 30 seconds before
  booting continues successfully.

  Using Ubuntu Natty, related packages versions:
  nbd-client 1:2.9.16-6ubuntu1
  initramfs-tools 0.98.1ubuntu9

  The wait-for-root call from /usr/share/initramfs-tools/scripts/local:
   while [ -z "${FSTYPE}" ]; do
    FSTYPE=$(wait-for-root "${ROOT}" ${ROOTDELAY:-30})

    # Run failure hooks, hoping one of them can fix up the system
    # and we can restart the wait loop.  If they all fail, abort
    # and move on to the panic handler and shell.
    if [ -z "${FSTYPE}" ] && ! try_failure_hooks; then
     break
    fi
   done

  I replaced wait-for-root with a sh script that did `set >&2`, here are the 
relevant environment variables at the time wait-for-root was called:
  ROOT='/dev/nbd0'
  ROOTDELAY=''
  ROOTFLAGS=''
  ROOTFSTYPE=''
  nbdroot='192.168.0.1,2011'

  It's probably worth noting that "nbd0: unknown partition table" was
  displayed asynchronously 1-2 seconds after wait-for-root was invoked
  and while it was still waiting. But I tried adding a "sleep 5" as the
  last line of local-top/nbd, so that the nbd message was displayed a
  lot before wait-for-root was called, and it didn't make a difference.
  So I don't think a race condition is involved in this problem.

  Temporarily I'm passing rootdelay=1 in the kernel command line to work
  around the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/696435/+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 1651044] Re: ProxyDHCP replies on invalid range

2016-12-20 Thread Alkis Georgopoulos
Hi Christian,

Simon, the dnsmasq developer and Debian maintainer, frequently answers here in 
launchpad as well (and there's no upstream bug tracker).
In any case, I did forward the report to the dnsmasq mailing list:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/011010.html

Thank you for your feedback!

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

Title:
  ProxyDHCP replies on invalid range

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  In Ubuntu 16.04, I've configured dnsmasq to reply on subnet=10.160.37.0/24, 
yet it replies even when it gets an IP on subnet=10.161.254.0/24.
  I've only seen this after clean system restart. If I restart dnsmasq later 
on, it works as expected.
  Maybe when dnsmasq starts, the network isn't up yet, and it incorrectly 
initializes some networking information? I'm using network-manager with DHCP.

  Details:
  $ egrep -rv '^#|^$' /etc/dnsmasq.*
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.160.37.0,proxy
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=192.168.67.20,192.168.67.250,8h
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:enable-tftp
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:tftp-root=/var/lib/tftpboot/
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=17,/opt/ltsp/i386
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=etherboot,Etherboot
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=pxe,PXEClient
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=ltsp,"Linux ipconfig"
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=vendor:pxe,6,2b
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-no-override
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:pxe-service=X86PC, "Boot from 
network", /ltsp/i386/pxelinux

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  2: enp2s0:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
  link/ether d0:50:99:a6:bc:0a brd ff:ff:ff:ff:ff:ff
  inet 10.161.254.185/24 brd 10.161.254.255 scope global dynamic enp2s0
 valid_lft 431873sec preferred_lft 431873sec
  inet6 fe80::f363:c1e2:9cb8:d9e2/64 scope link 
 valid_lft forever preferred_lft forever

  $ sudo netstat -nap | grep dnsmasq
  [sudo] password for administrator: 
  tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN
  843/dnsmasq 
  tcp6   0  0 :::53   :::*LISTEN
  843/dnsmasq 
  udp0  0 0.0.0.0:53  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:67  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:69  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:40110.0.0.0:* 
  843/dnsmasq 
  udp6   0  0 :::53   :::*  
  843/dnsmasq 
  udp6   0  0 :::69   :::*  
  843/dnsmasq 
  unix  2  [ ] DGRAM15746843/dnsmasq
 

  $ grep dnsmasq /var/log/syslog | tail -n 30
  Dec 19 10:52:17 ltsp-server systemd[1]: Starting dnsmasq - A lightweight DHCP 
and caching DNS server...
  Dec 19 10:52:17 ltsp-server dnsmasq[630]: dnsmasq: syntax check OK.
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: started, version 2.75 cachesize 150
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: compile time options: IPv6 
GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC 
loop-detect inotify
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: DNS service limited to local subnets
  Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, IP range 192.168.67.20 
-- 192.168.67.250, lease time 8h
  Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, proxy on subnet 
10.160.37.0
  Dec 19 10:52:20 ltsp-server dnsmasq-tftp[843]: TFTP root is /var/lib/tftpboot/
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: no servers found in 
/var/run/dnsmasq/resolv.conf, will retry
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: read /etc/hosts - 7 addresses
  Dec 19 10:52:23 ltsp-server systemd[1]: Started dnsmasq - A lightweight DHCP 
and caching DNS server.
  Dec 19 10:52:29 ltsp-server dnsmasq[843]: reading 

[Touch-packages] [Bug 1651044] Re: ProxyDHCP replies on invalid range

2016-12-18 Thread Alkis Georgopoulos
I did another test:
 * I unplugged the network cable so that the ltsp-server didn't have an ip.
 * I ran `service dnsmasq restart`.
 * I plugged the network cable back in.
 * ...and the problem came back again, i.e. dnsmasq replied on invalid range.

This again suggests that it's some kind of wrong initialization when the
network is down while dnsmasq starts.

Using dnsmasq 2.75-1ubuntu0.16.04.1 on i386 architecture.

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

Title:
  ProxyDHCP replies on invalid range

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  In Ubuntu 16.04, I've configured dnsmasq to reply on subnet=10.160.37.0/24, 
yet it replies even when it gets an IP on subnet=10.161.254.0/24.
  I've only seen this after clean system restart. If I restart dnsmasq later 
on, it works as expected.
  Maybe when dnsmasq starts, the network isn't up yet, and it incorrectly 
initializes some networking information? I'm using network-manager with DHCP.

  Details:
  $ egrep -rv '^#|^$' /etc/dnsmasq.*
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.160.37.0,proxy
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=192.168.67.20,192.168.67.250,8h
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:enable-tftp
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:tftp-root=/var/lib/tftpboot/
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=17,/opt/ltsp/i386
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=etherboot,Etherboot
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=pxe,PXEClient
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=ltsp,"Linux ipconfig"
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=vendor:pxe,6,2b
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-no-override
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:pxe-service=X86PC, "Boot from 
network", /ltsp/i386/pxelinux

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  2: enp2s0:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
  link/ether d0:50:99:a6:bc:0a brd ff:ff:ff:ff:ff:ff
  inet 10.161.254.185/24 brd 10.161.254.255 scope global dynamic enp2s0
 valid_lft 431873sec preferred_lft 431873sec
  inet6 fe80::f363:c1e2:9cb8:d9e2/64 scope link 
 valid_lft forever preferred_lft forever

  $ sudo netstat -nap | grep dnsmasq
  [sudo] password for administrator: 
  tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN
  843/dnsmasq 
  tcp6   0  0 :::53   :::*LISTEN
  843/dnsmasq 
  udp0  0 0.0.0.0:53  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:67  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:69  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:40110.0.0.0:* 
  843/dnsmasq 
  udp6   0  0 :::53   :::*  
  843/dnsmasq 
  udp6   0  0 :::69   :::*  
  843/dnsmasq 
  unix  2  [ ] DGRAM15746843/dnsmasq
 

  $ grep dnsmasq /var/log/syslog | tail -n 30
  Dec 19 10:52:17 ltsp-server systemd[1]: Starting dnsmasq - A lightweight DHCP 
and caching DNS server...
  Dec 19 10:52:17 ltsp-server dnsmasq[630]: dnsmasq: syntax check OK.
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: started, version 2.75 cachesize 150
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: compile time options: IPv6 
GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC 
loop-detect inotify
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: DNS service limited to local subnets
  Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, IP range 192.168.67.20 
-- 192.168.67.250, lease time 8h
  Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, proxy on subnet 
10.160.37.0
  Dec 19 10:52:20 ltsp-server dnsmasq-tftp[843]: TFTP root is /var/lib/tftpboot/
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: no servers found in 
/var/run/dnsmasq/resolv.conf, will retry
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: read /etc/hosts - 7 addresses
  Dec 19 10:52:23 ltsp-server systemd[1]: Started dnsmasq - A lightweight 

[Touch-packages] [Bug 1651044] [NEW] ProxyDHCP replies on invalid range

2016-12-18 Thread Alkis Georgopoulos
Public bug reported:

In Ubuntu 16.04, I've configured dnsmasq to reply on subnet=10.160.37.0/24, yet 
it replies even when it gets an IP on subnet=10.161.254.0/24.
I've only seen this after clean system restart. If I restart dnsmasq later on, 
it works as expected.
Maybe when dnsmasq starts, the network isn't up yet, and it incorrectly 
initializes some networking information? I'm using network-manager with DHCP.

Details:
$ egrep -rv '^#|^$' /etc/dnsmasq.*
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.160.37.0,proxy
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=192.168.67.20,192.168.67.250,8h
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:enable-tftp
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:tftp-root=/var/lib/tftpboot/
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=17,/opt/ltsp/i386
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=etherboot,Etherboot
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=pxe,PXEClient
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=ltsp,"Linux ipconfig"
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=vendor:pxe,6,2b
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-no-override
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:pxe-service=X86PC, "Boot from network", 
/ltsp/i386/pxelinux

$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp2s0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether d0:50:99:a6:bc:0a brd ff:ff:ff:ff:ff:ff
inet 10.161.254.185/24 brd 10.161.254.255 scope global dynamic enp2s0
   valid_lft 431873sec preferred_lft 431873sec
inet6 fe80::f363:c1e2:9cb8:d9e2/64 scope link 
   valid_lft forever preferred_lft forever

$ sudo netstat -nap | grep dnsmasq
[sudo] password for administrator: 
tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN  
843/dnsmasq 
tcp6   0  0 :::53   :::*LISTEN  
843/dnsmasq 
udp0  0 0.0.0.0:53  0.0.0.0:*   
843/dnsmasq 
udp0  0 0.0.0.0:67  0.0.0.0:*   
843/dnsmasq 
udp0  0 0.0.0.0:69  0.0.0.0:*   
843/dnsmasq 
udp0  0 0.0.0.0:40110.0.0.0:*   
843/dnsmasq 
udp6   0  0 :::53   :::*
843/dnsmasq 
udp6   0  0 :::69   :::*
843/dnsmasq 
unix  2  [ ] DGRAM15746843/dnsmasq 

$ grep dnsmasq /var/log/syslog | tail -n 30
Dec 19 10:52:17 ltsp-server systemd[1]: Starting dnsmasq - A lightweight DHCP 
and caching DNS server...
Dec 19 10:52:17 ltsp-server dnsmasq[630]: dnsmasq: syntax check OK.
Dec 19 10:52:20 ltsp-server dnsmasq[843]: started, version 2.75 cachesize 150
Dec 19 10:52:20 ltsp-server dnsmasq[843]: compile time options: IPv6 GNU-getopt 
DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect 
inotify
Dec 19 10:52:20 ltsp-server dnsmasq[843]: DNS service limited to local subnets
Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, IP range 192.168.67.20 -- 
192.168.67.250, lease time 8h
Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, proxy on subnet 10.160.37.0
Dec 19 10:52:20 ltsp-server dnsmasq-tftp[843]: TFTP root is /var/lib/tftpboot/
Dec 19 10:52:20 ltsp-server dnsmasq[843]: no servers found in 
/var/run/dnsmasq/resolv.conf, will retry
Dec 19 10:52:20 ltsp-server dnsmasq[843]: read /etc/hosts - 7 addresses
Dec 19 10:52:23 ltsp-server systemd[1]: Started dnsmasq - A lightweight DHCP 
and caching DNS server.
Dec 19 10:52:29 ltsp-server dnsmasq[843]: reading /var/run/dnsmasq/resolv.conf
Dec 19 10:52:29 ltsp-server dnsmasq[843]: ignoring nameserver 127.0.0.1 - local 
interface
Dec 19 10:52:29 ltsp-server dnsmasq[843]: using nameserver 194.63.238.4#53
Dec 19 10:52:29 ltsp-server dnsmasq[843]: using nameserver 8.8.8.8#53
Dec 19 08:52:47 ltsp-server dnsmasq-dhcp[843]: PXE(enp2s0) 52:54:00:8f:74:ad 
proxy
Dec 19 08:52:47 ltsp-server dnsmasq-dhcp[843]: PXE(enp2s0) 10.161.254.195 
52:54:00:8f:74:ad /ltsp/i386/pxelinux.0
Dec 19 08:52:47 ltsp-server dnsmasq-tftp[843]: sent 
/var/lib/tftpboot/ltsp/i386/pxelinux.0 to 10.161.254.195
...


Note that it replies in "52:54:00:8f:74:ad proxy" while it shouldn't.
If I run this:
# service dnsmasq restart

Then it behaves correctly:
Dec 

[Touch-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting

2016-05-26 Thread Alkis Georgopoulos
The network-manager package still ships /etc/dnsmasq.d/network-manager
with "bind-interfaces" in it
and that breaks the TFTP server of dnsmasq
and sometimes even the DNS server of dnsmasq.

"bind-dynamic" is a little better, but too unreliable to be used in
production.

So this bug is still not resolved, after 150 messages it was just made a
little worse.

One workaround is to undo the "solution" offered in this bug report:
1) In /etc/NetworkManager/NetworkManager.conf, comment out: # dns=dnsmasq
2) And in /etc/dnsmasq.d/network-manager, comment out: #bind-interfaces

A better solution would be for Mathieu to create a separate package for
the nm-spawned dnsmasq, one that would conflict with the real dnsmasq
server so that it would be automatically uninstalled when the sysadmin
would install the real dnsmasq.

I can send a patch for that if it will be accepted.

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

Title:
  NM-controlled dnsmasq prevents other DNS servers from starting

Status in djbdns package in Ubuntu:
  Confirmed
Status in dnsmasq package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Confirmed
Status in pdns-recursor package in Ubuntu:
  Invalid
Status in pdnsd package in Ubuntu:
  Invalid
Status in djbdns source package in Precise:
  Confirmed
Status in dnsmasq source package in Precise:
  Triaged
Status in network-manager source package in Precise:
  Triaged
Status in pdns-recursor source package in Precise:
  Invalid
Status in pdnsd source package in Precise:
  Invalid

Bug description:
  As described in
  https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-
  resolving, network manager now starts a dnsmasq instance for local DNS
  resolving.

  That breaks the default bind9 and dnsmasq installations, for people that 
actually want to install a DNS server.
  Having to manually comment out "#dns=dnsmasq" in 
/etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays 
that way, it should be moved to the bind9 and dnsmasq postinst scripts.

  Please make network-manager smarter so that it checks if bind9 or
  dnsmasq are installed, so that it doesn't start the local resolver in
  that case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+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 1584314] Re: Togo keyboard layout / compose keys

2016-05-24 Thread Alkis Georgopoulos
Hi Gunnar,

the issue was that in some cases, typing the Greek key for accent (tonos, the 
key is ";"), and then after releasing it, typing "α", resulted in two separate 
characters, i.e.
;+α=´α
instead of the correct
;+α=ά

At first I thought this was because of ibus, because I was seeing the issue 
only on setups where ibus was installed.
But later on I realized that something, maybe /usr/bin/gnome-language-selector, 
but possibly something else too, was creating a ~/.xinputrc file:
# im-config(8) generated on Wed, 25 May 2016 07:25:38 +0300
run_im xim
# im-config signature: 5f2367a738e8f9717ddbb719455f7930  -

So when that file was present, even when ibus was not installed, I was still 
having the tonos issue.
After running `rm ~/.xinputrc` and logging in again, the issue was gone.

Btw note that opening gnome-language-selector and selecting "None"
creates that file and causes the issue again!!! So we try to never open
gnome-language-selector.

That's all I know about the issue; I found out that Ubuntu Mate comes
without ibus/fcitx installed, so we've switched to using that one, where
the Xorg system-wide keyboard defaults are respected and remain
unmodified after login and everything works flawlessly! :)

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

Title:
  Togo keyboard layout / compose keys

Status in ibus package in Ubuntu:
  New
Status in libx11 package in Ubuntu:
  In Progress
Status in xkeyboard-config package in Ubuntu:
  Fix Released

Bug description:
  Hi
  My name is Rodrigo with my team we develop the Togo-Africa Keyboard Layout in 
the Linux Distribution.
  We want to include this keyboard in the Ubuntu distribution.

  I've uploaded a keyboard to XKB:
  
https://cgit.freedesktop.org/xkeyboard-config/commit/?id=53452c901fcab08a43705c9aa79a5ec5642cca08

  
  
https://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=3129c757f9da8586ab8b8654a56c8f687cc9ef5c

  
  Here is the Keyboard
  ##

  diff --git a/rules/base.xml.in b/rules/base.xml.in
  index f495c8d..5e91717 100644
  --- a/rules/base.xml.in
  +++ b/rules/base.xml.in
  @@ -5680,6 +5680,16 @@
   
   
     
  +tg
  +<_shortDescription>fr-tg
  +<_description>French (Togo)
  +
  +  fra
  +
  +  
  +
  +
  +  
   ke
   
   <_shortDescription>sw
  diff --git a/symbols/Makefile.am b/symbols/Makefile.am
  index 77ec0ff..3226d41 100644
  --- a/symbols/Makefile.am
  +++ b/symbols/Makefile.am
  @@ -29,7 +29,7 @@ pc ph pk pl pt \
   ro rs ru \
   se si sk sn \
   sy th \
  -terminate \
  +terminate tg \
   tj tm tr tw tz \
   ua us uz vn \
   za \
  diff --git a/symbols/tg b/symbols/tg
  new file mode 100644
  index 000..f7b2cb3
  --- /dev/null
  +++ b/symbols/tg
  @@ -0,0 +1,68 @@
  +default partial alphanumeric_keys
  +xkb_symbols "basic" {
  +
  +include "fr(azerty)"
  +
  +name[Group1]="French (Togo)";
  +
  +// French AZERTY-Keyboard layout including symbols for Togolese local 
languages
  +// Created 2015 by Globalbility Togo (www.globalbility.org)
  +// Authors: Issaka Ouro-Wétchiré, Caroline Riefstahl, Mats Blakstad 
  +//
  +// LAYOUT OVERVIEW
  +//  
  +// | 1 3| 1 = Shift,  3 = AltGr + Shift(AltGr is the right side alt key)
  +// | 2 4| 2 = normal, 4 = AltGr
  +//  
  +//               ___
  +// || 1  | 2  | 3  | 4  | 5  | 6  | 7  | 8  | 9  | 0  | °  | +  | <--   |
  +// | ²  | &  | é ~| " #| ' {| ( [| - || è `| _ \| ç ^| à @| ) ]| = }|   |
  +//  
  +// | |<-  | A  | Z Ʒ| E Ɛ| R Ɗ| T  | Y Ƴ| U Ʊ| I Ɩ| O Ɔ| P  | ¨  | $ €|   , |
  +// |  ->| | a  | z ʒ| e ɛ| r ɗ| t  | y ƴ| u ʊ| i ɩ| o ɔ| p  | ^  ̌| £ ¤| <-' 
|
  +//  ===¬|
  +// |   | Q Ǝ| S  | D Ɖ| F Ƒ| G Ɣ| H Ĥ | J  | K  | L  | M Ŋ| %  | µ  |
|
  +// | MAJ   | q ǝ| s  | d ɖ| f ƒ| g ɣ| h ɦ| j  | k  | l  | m ɲ| ù `| *  ́|
|
  +//  
  +// | ^   | >  | W  | X  | C  | V Ʋ| B Ɓ| N Ŋ| ?  | .  | /  | §  | | |
  +// | |   | <  | w  | x  | c  | v ʋ| b ɓ| n ŋ| , ~| ; ¯| :  | !  | | |
  +//  
  +// |  |  |  |   |   |  | |  |
  +// | Ctrl | Super| Alt  | SpaceNobreakspace | AltGr | Super|Menu | Ctrl |
  +//  ¯¯ ¯¯ ¯¯ ¯¯¯ ¯¯¯ ¯¯ ¯ ¯¯
  +// Togolese local languages use 8 tones markers.
  +// Acute ( ´ ),  Grave ( ` ), Circumflex ( ˆ ), Caron ( ˇ ), Macron ( ¯ 
), Tilde ( ~ ), Tilde + Acute (  ̃́ ), Tilde + Grave (  ̃̀ 

[Touch-packages] [Bug 1512002] Re: Annoying dialog "Authentication is required to change your own user data"

2016-05-20 Thread Alkis Georgopoulos
> Sebastien Bacher (seb128) wrote on 2016-04-29:#43

> @Alkis, right, the line changed was what you suggested in the upstream report 
> and in comment #33, 
> if that's incorrect/incomplete could you update the upstream report?


I'm sorry guys for some reason I wasn't getting notifications from this bug 
report, I've just commented on the upstream bug.

Glad to see this was fixed! Thanks!

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

Title:
  Annoying dialog "Authentication is required to change your own user
  data"

Status in accountsservice:
  Confirmed
Status in accountsservice package in Ubuntu:
  Fix Released
Status in indicator-messages package in Ubuntu:
  Invalid
Status in policykit-1-gnome package in Ubuntu:
  Invalid
Status in accountsservice source package in Xenial:
  Fix Released

Bug description:
  * Impact

  Sometimes useless "Authentication is required to change your own user
  data" prompts are displayed

  * Test case

  
  $ ssh -X localhost
  $ /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &
  $ dbus-send --system --print-reply=literal --dest=org.freedesktop.Accounts 
/org/freedesktop/Accounts/User1001 
org.freedesktop.Accounts.User.SetXHasMessages boolean:true

  that shouldn't trigger a prompt

  * Regression potential

  it allows the change to be done without prompting in more cases,
  shouldn't have an impact on cases which were already working

  
  --

  Every few days a dialog pops up saying "Authentication is required to change 
your own user data" with an entry field for a password. If I type my user's 
password the dialog will reappear with an empty entry field. If I click on the 
cross to close the window many times it will be gone, but reappear a few days 
later. I don't know what this window is for and it makes no difference whether 
I close it or leave it. I don't use the gnome keyring.
  This started with Ubuntu 15.04 or maybe with an earlier release, and is still 
there in Ubuntu 15.10, also on machines I did a fresh install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/accountsservice/+bug/1512002/+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 1487679] Re: Breaking ordering cycle by deleting job nbd-client.service/start

2016-04-28 Thread Alkis Georgopoulos
Hi Martin,

I don't have access to any systems without network-manager (that's
ubuntu-server installations, I imagine?) so I cannot say if it currently
works with plain ifupdown or not, and if the patch will break it.

Let's assume the worst, that it now works there and that the patch will
break it. In that case we have:

1) The nbd-client sysvinit service will not work as expected; users will
notice and hopefully will find this bug report telling them that they
need to revert the $network patch.

But now we have:

2) The nbd-client sysvinit service breaking not only itself but other packages 
as well! Network-manager or other services randomly not starting!
This even affects persons that don't use the nbd-client sysvinit service at 
all, but just need the nbd-client executable (like LTSP or QEMU users or 
persons wishing to use nbd-client to temporarily access a remote disk).

I believe that (2) is a lesser evil than (1), which I imagine only
affect a minority of the ubuntu-server installations that also happend
to need the nbd-client service.

In any case, if this won't be fixed for Xenial, let's please mention it
in this bug report, so that we develop a workaround in LTSP, for all
LTSP users that need it immediately.

Thanks a lot,
Alkis

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

Title:
  Breaking ordering cycle by deleting job nbd-client.service/start

Status in nbd package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  Won't Fix

Bug description:
  $ lsb_release -rd
  Description:  Ubuntu 15.04
  Release:  15.04

  $ apt-cache policy nbd-client
  nbd-client:
Installed: 1:3.8-4ubuntu0.1
Candidate: 1:3.8-4ubuntu0.1
Version table:
   *** 1:3.8-4ubuntu0.1 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ vivid-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:3.8-4 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages

  I'm using the nbd-client to mount some raw disk images over the
  network but starting the nbd-client automatically during bootup does
  not happen due to the following:

  Aug 22 08:54:20 fractal kernel: [   11.875885] systemd[1]: Found dependency 
on nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875890] systemd[1]: Breaking ordering 
cycle by deleting job nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875891] systemd[1]: Job 
nbd-client.service/start deleted to break ordering cycle starting with 
basic.target/start

  Meaning after boot, I have to manually run `sudo ndb-client start`
  every time I want to access these images. Note that this is no
  diskless system, the images I mount via NBD do not contain the local
  system, they are totally unrelated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679/+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 1487679] Re: Breaking ordering cycle by deleting job nbd-client.service/start

2016-04-25 Thread Alkis Georgopoulos
@pitti, since
1) wouter isn't planning to fix this upstream soonish (Debian freeze is months 
ahead),
2) the issue is serious, i.e. people that install nbd-client, then randomly 
don't have network-manager running after reboots,
3) the included patch is surely better than the existing situation, i.e. it 
solves the ordering cycle issue by just starting nbd-client later on,

would you approve an SRU for the included patch,
or do you have some better idea on how to handle this?

Thanks!

** Patch added: "no-required-start-network.patch"
   
https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679/+attachment/4646305/+files/no-required-start-network.patch

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

Title:
  Breaking ordering cycle by deleting job nbd-client.service/start

Status in nbd package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  Won't Fix
Status in systemd package in Ubuntu:
  New

Bug description:
  $ lsb_release -rd
  Description:  Ubuntu 15.04
  Release:  15.04

  $ apt-cache policy nbd-client
  nbd-client:
Installed: 1:3.8-4ubuntu0.1
Candidate: 1:3.8-4ubuntu0.1
Version table:
   *** 1:3.8-4ubuntu0.1 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ vivid-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:3.8-4 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages

  I'm using the nbd-client to mount some raw disk images over the
  network but starting the nbd-client automatically during bootup does
  not happen due to the following:

  Aug 22 08:54:20 fractal kernel: [   11.875885] systemd[1]: Found dependency 
on nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875890] systemd[1]: Breaking ordering 
cycle by deleting job nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875891] systemd[1]: Job 
nbd-client.service/start deleted to break ordering cycle starting with 
basic.target/start

  Meaning after boot, I have to manually run `sudo ndb-client start`
  every time I want to access these images. Note that this is no
  diskless system, the images I mount via NBD do not contain the local
  system, they are totally unrelated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679/+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 1487679] Re: Breaking ordering cycle by deleting job nbd-client.service/start

2016-04-25 Thread Alkis Georgopoulos
** Also 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/1487679

Title:
  Breaking ordering cycle by deleting job nbd-client.service/start

Status in nbd package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  Won't Fix
Status in systemd package in Ubuntu:
  New

Bug description:
  $ lsb_release -rd
  Description:  Ubuntu 15.04
  Release:  15.04

  $ apt-cache policy nbd-client
  nbd-client:
Installed: 1:3.8-4ubuntu0.1
Candidate: 1:3.8-4ubuntu0.1
Version table:
   *** 1:3.8-4ubuntu0.1 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ vivid-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:3.8-4 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages

  I'm using the nbd-client to mount some raw disk images over the
  network but starting the nbd-client automatically during bootup does
  not happen due to the following:

  Aug 22 08:54:20 fractal kernel: [   11.875885] systemd[1]: Found dependency 
on nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875890] systemd[1]: Breaking ordering 
cycle by deleting job nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875891] systemd[1]: Job 
nbd-client.service/start deleted to break ordering cycle starting with 
basic.target/start

  Meaning after boot, I have to manually run `sudo ndb-client start`
  every time I want to access these images. Note that this is no
  diskless system, the images I mount via NBD do not contain the local
  system, they are totally unrelated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679/+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 1512002] Re: Annoying dialog "Authentication is required to change your own user data"

2016-04-21 Thread Alkis Georgopoulos
@seb128, thanks for releasing the fix, but it appears that not all the patch 
from comment #36 was applied:
-  auth_self
-  auth_self
+  yes
+  yes

 is still "auth_self" in accountsservice 0.6.40-2ubuntu10,
and I think that it takes priority over , so the problem
still persists and can be reproduced as described in comment #36.

Could you please re-release the fix while applying the whole patch?
Thank you!

** Changed in: accountsservice (Ubuntu)
   Status: Fix Released => Triaged

** Changed in: accountsservice (Ubuntu)
 Assignee: (unassigned) => Sebastien Bacher (seb128)

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

Title:
  Annoying dialog "Authentication is required to change your own user
  data"

Status in accountsservice:
  Confirmed
Status in accountsservice package in Ubuntu:
  Triaged
Status in indicator-messages package in Ubuntu:
  Confirmed
Status in policykit-1-gnome package in Ubuntu:
  Confirmed

Bug description:
  Every few days a dialog pops up saying "Authentication is required to change 
your own user data" with an entry field for a password. If I type my user's 
password the dialog will reappear with an empty entry field. If I click on the 
cross to close the window many times it will be gone, but reappear a few days 
later. I don't know what this window is for and it makes no difference whether 
I close it or leave it. I don't use the gnome keyring.
  This started with Ubuntu 15.04 or maybe with an earlier release, and is still 
there in Ubuntu 15.10, also on machines I did a fresh install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/accountsservice/+bug/1512002/+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 1512002] Re: Annoying dialog "Authentication is required to change your own user data"

2016-04-18 Thread Alkis Georgopoulos
@desrt, isn't that explained in comment #33,
i.e. in 
https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1192300/comments/13
i.e. in patch 
https://code.launchpad.net/~mterry/indicator-messages/tell-accounts-services/+merge/93290
 ?

SetXHasMessages is called by the accounts_notify() function that mterry
implemented.

I think what we can do in Ubuntu now, is to apply the patch, and if/when
upstream accepts it, to drop the .diff.

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

Title:
  Annoying dialog "Authentication is required to change your own user
  data"

Status in accountsservice:
  Confirmed
Status in accountsservice package in Ubuntu:
  Confirmed
Status in indicator-messages package in Ubuntu:
  Confirmed
Status in policykit-1-gnome package in Ubuntu:
  Confirmed

Bug description:
  Every few days a dialog pops up saying "Authentication is required to change 
your own user data" with an entry field for a password. If I type my user's 
password the dialog will reappear with an empty entry field. If I click on the 
cross to close the window many times it will be gone, but reappear a few days 
later. I don't know what this window is for and it makes no difference whether 
I close it or leave it. I don't use the gnome keyring.
  This started with Ubuntu 15.04 or maybe with an earlier release, and is still 
there in Ubuntu 15.10, also on machines I did a fresh install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/accountsservice/+bug/1512002/+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 221363] Re: Policy Kit Unlock Buttons Greyed Out when using NX / VNC / LTSP

2016-04-12 Thread Alkis Georgopoulos
Since noone has answered for 4 months, and since some related commits
have been made, I'm marking it fix released in LTSP.

** Changed in: ltsp (Ubuntu)
   Status: Incomplete => Fix Released

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

Title:
  Policy Kit Unlock Buttons Greyed Out when using NX / VNC / LTSP

Status in FreeNX Server:
  Fix Released
Status in gdm:
  New
Status in PolicyKit:
  Invalid
Status in system-tools-backends:
  Fix Released
Status in ltsp package in Ubuntu:
  Fix Released
Status in policykit package in Ubuntu:
  Invalid
Status in policykit-1 package in Ubuntu:
  Invalid
Status in system-tools-backends package in Ubuntu:
  Triaged

Bug description:
  I installed 8.04 LTS server on a system.  Then installed ubuntu-
  desktop using apt.  Installed Nomachine's NX server and connected to
  it.

  The unlock buttons on Users and Groups or Network are greyed out and
  un-accessible.  Tried running from a term 'sudo users-admin' with the
  same results.

  Works fine with VNC and NX "Shadow" session however this is not really
  acceptable as it means a session has to be running on console first.

  I have tried to enable every option in Authorizations to allow the
  remote session to have privileges to no avail.

  output of dpkg relevant packages:

  ii  gnome-system-t 2.22.0-0ubuntu Cross-platform configuration utilities for G
  ii  liboobs-1-42.22.0-0ubuntu GObject based interface to system-tools-back
  ii  policykit  0.7-2ubuntu7   framework for managing administrative polici
  ii  system-tools-b 2.6.0-0ubuntu7 System Tools to manage computer configuratio

  
  == Workarounds  ==
  

  1) *Jaunty or older*

  From
  https://bugs.launchpad.net/ubuntu/+source/policykit/+bug/238799/comments/16
  (the packages from comment 24 are broken links now):

  I was able to get access via VNC tunneled through SSH by changing the
  following settings in policykit. You can do it locally via
  Authorizations, or you can do it remotely using "sudo ck-launch-
  session polkit-gnome-authorization" in a terminal window in your
  tunneled VNC session. This worked on Ubuntu 9.04 Server RC running
  xubuntu-desktop, so as always YMMV.

  For system configuration, change all implicit authorizations under org
  -> freedesktop -> systemtoolsbackends -> Manage System Configuration
  (org.freedesktop.systemtoolsbackends.set) to "Admin Authentication."

  For user management, change all implicit authorizations under org ->
  freedesktop -> systemtoolsbackends -> self -> Change User
  Configuration (org.freedesktop.systemtoolsbackends.self.set) to
  "Authentication."

  Reset gdm by rebooting or running "sudo /etc/init.d/gdm restart" from
  a terminal window, and you should be able to unlock the user settings
  control panel and other similarly useful things through your tunneled
  VNC session.

  2) *Karmic or newer*

  Apply this patch: 
http://launchpadlibrarian.net/39471473/polkit-systemtools-remote-allow.patch
  # sudo cp -a 
/usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy 
/usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy.ori
  # sudo patch 
/usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy 
polkit-systemtools-remote-allow.patch

  Then kill polkitd, it will be restarted automatically:
  # sudo pkill polkitd

To manage notifications about this bug go to:
https://bugs.launchpad.net/freenx-server/+bug/221363/+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 1512002] Re: Annoying dialog "Authentication is required to change your own user data"

2016-04-11 Thread Alkis Georgopoulos
** Bug watch added: freedesktop.org Bugzilla #94895
   https://bugs.freedesktop.org/show_bug.cgi?id=94895

** Also affects: accountsservice via
   https://bugs.freedesktop.org/show_bug.cgi?id=94895
   Importance: Unknown
   Status: Unknown

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

Title:
  Annoying dialog "Authentication is required to change your own user
  data"

Status in accountsservice:
  Unknown
Status in accountsservice package in Ubuntu:
  Confirmed
Status in indicator-messages package in Ubuntu:
  Confirmed
Status in policykit-1-gnome package in Ubuntu:
  Confirmed

Bug description:
  Every few days a dialog pops up saying "Authentication is required to change 
your own user data" with an entry field for a password. If I type my user's 
password the dialog will reappear with an empty entry field. If I click on the 
cross to close the window many times it will be gone, but reappear a few days 
later. I don't know what this window is for and it makes no difference whether 
I close it or leave it. I don't use the gnome keyring.
  This started with Ubuntu 15.04 or maybe with an earlier release, and is still 
there in Ubuntu 15.10, also on machines I did a fresh install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/accountsservice/+bug/1512002/+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 1512002] Re: Annoying dialog "Authentication is required to change your own user data"

2016-04-11 Thread Alkis Georgopoulos
Here's another way to reproduce it:


$ ssh -X localhost
$ /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &
$ dbus-send --system --print-reply=literal --dest=org.freedesktop.Accounts 
/org/freedesktop/Accounts/User1001 
org.freedesktop.Accounts.User.SetXHasMessages boolean:true

It doesn't make sense to have the user authenticate himself just to tell him he 
has new mail.
This affects gnome-screensaver, lightdm's user switching ability, X2go, LTSP 
etc.

Please replace the "auth_self" with "yes" as in the provided patch.

** Patch added: "change-own-user-data.patch"
   
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1512002/+attachment/4632965/+files/change-own-user-data.patch

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

Title:
  Annoying dialog "Authentication is required to change your own user
  data"

Status in accountsservice package in Ubuntu:
  Confirmed
Status in indicator-messages package in Ubuntu:
  Confirmed
Status in policykit-1-gnome package in Ubuntu:
  Confirmed

Bug description:
  Every few days a dialog pops up saying "Authentication is required to change 
your own user data" with an entry field for a password. If I type my user's 
password the dialog will reappear with an empty entry field. If I click on the 
cross to close the window many times it will be gone, but reappear a few days 
later. I don't know what this window is for and it makes no difference whether 
I close it or leave it. I don't use the gnome keyring.
  This started with Ubuntu 15.04 or maybe with an earlier release, and is still 
there in Ubuntu 15.10, also on machines I did a fresh install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1512002/+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 1487679] Re: Breaking ordering cycle by deleting job nbd-client.service/start

2016-04-11 Thread Alkis Georgopoulos
I confirm that by enabling NetworkManager-wait-online.service in Debian 
Stretch, I started getting dependency cycles.
Replacing  "# Default-Start: S" with "# Default-Start: 2 3 4 5" didn't solve 
the cycles.

Any fixes or workarounds for Xenial?

For now, I removed "Required start: $network" from all the sysvinit
services that had it (e.g. /etc/init.d/nbd-client).

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

Title:
  Breaking ordering cycle by deleting job nbd-client.service/start

Status in nbd package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  Won't Fix

Bug description:
  $ lsb_release -rd
  Description:  Ubuntu 15.04
  Release:  15.04

  $ apt-cache policy nbd-client
  nbd-client:
Installed: 1:3.8-4ubuntu0.1
Candidate: 1:3.8-4ubuntu0.1
Version table:
   *** 1:3.8-4ubuntu0.1 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ vivid-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:3.8-4 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages

  I'm using the nbd-client to mount some raw disk images over the
  network but starting the nbd-client automatically during bootup does
  not happen due to the following:

  Aug 22 08:54:20 fractal kernel: [   11.875885] systemd[1]: Found dependency 
on nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875890] systemd[1]: Breaking ordering 
cycle by deleting job nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875891] systemd[1]: Job 
nbd-client.service/start deleted to break ordering cycle starting with 
basic.target/start

  Meaning after boot, I have to manually run `sudo ndb-client start`
  every time I want to access these images. Note that this is no
  diskless system, the images I mount via NBD do not contain the local
  system, they are totally unrelated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679/+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 1512002] Re: Annoying dialog "Authentication is required to change your own user data"

2016-04-11 Thread Alkis Georgopoulos
Here is one method to see the dialog without working remotely:

sudo sed 's/yes/auth_self/' -i 
/usr/share/polkit-1/actions/org.freedesktop.accounts.policy
Then press Alt+Ctrl+F2 to switch to vt2, and Alt+Ctrl+F7 to switch back to vt7.

After testing, to revert the change, run:
sudo sed 's/auth_self/yes/' -i 
/usr/share/polkit-1/actions/org.freedesktop.accounts.policy


On LTSP thin clients, one can reproduce it by just changing VTs, without 
changing the accountsservice polkit files.

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

Title:
  Annoying dialog "Authentication is required to change your own user
  data"

Status in accountsservice package in Ubuntu:
  Confirmed
Status in indicator-messages package in Ubuntu:
  Confirmed
Status in policykit-1-gnome package in Ubuntu:
  Confirmed

Bug description:
  Every few days a dialog pops up saying "Authentication is required to change 
your own user data" with an entry field for a password. If I type my user's 
password the dialog will reappear with an empty entry field. If I click on the 
cross to close the window many times it will be gone, but reappear a few days 
later. I don't know what this window is for and it makes no difference whether 
I close it or leave it. I don't use the gnome keyring.
  This started with Ubuntu 15.04 or maybe with an earlier release, and is still 
there in Ubuntu 15.10, also on machines I did a fresh install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1512002/+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 1512002] Re: Annoying dialog "Authentication is required to change your own user data"

2016-04-08 Thread Alkis Georgopoulos
mterry, charlesk, I took the liberty of subscribing you because I think it 
involves this commit:
https://code.launchpad.net/~mterry/indicator-messages/tell-accounts-services/+merge/93290

The issue is happening to me as well, on Ubuntu 16.04 gnome-flashback, in 2 
cases:
1) sometimes when I try to unlock the screensaver,
2) sometimes when I login via ltsp thin/fat clients.

I think the problem is the one mentioned by khadgaray in
https://bugs.launchpad.net/ubuntu/+source/indicator-
messages/+bug/1192300.

I.e. that the system is trying to notify us if we have new mails etc,
and that for some reason(s) it's considering us an "inactive user"
(inactive means not in the active screen of the pc, either remote or in
a screensaver etc) and thus we need authentication.

The necessary rights are defined in this file:
/usr/share/polkit-1/actions/org.freedesktop.accounts.policy

  
...

  auth_self
  auth_self
  yes

...

I think that if we change "auth_self"
to "yes",
we'll have a temporary workaround to the problem.

But the real issue is, should the system consider us "inactive" in the screen 
saver?
Should it consider us inactive in ltsp thin clients that are remote sessions?
Should it consider us inactive in ltsp fat clients where accountsservice 
doesn't have information about the remote user account? (similar with ldap)

If the answer to the above is yes, then maybe the workaround that I
mentioned above should be committed to accountsservice?

** Also affects: accountsservice (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Annoying dialog "Authentication is required to change your own user
  data"

Status in accountsservice package in Ubuntu:
  New
Status in indicator-messages package in Ubuntu:
  Confirmed
Status in policykit-1-gnome package in Ubuntu:
  Confirmed

Bug description:
  Every few days a dialog pops up saying "Authentication is required to change 
your own user data" with an entry field for a password. If I type my user's 
password the dialog will reappear with an empty entry field. If I click on the 
cross to close the window many times it will be gone, but reappear a few days 
later. I don't know what this window is for and it makes no difference whether 
I close it or leave it. I don't use the gnome keyring.
  This started with Ubuntu 15.04 or maybe with an earlier release, and is still 
there in Ubuntu 15.10, also on machines I did a fresh install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1512002/+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 1487679] Re: Breaking ordering cycle by deleting job nbd-client.service/start

2016-04-07 Thread Alkis Georgopoulos
I was able to reproduce the issue in Debian Stretch after applying an
Ubuntu specific patch to it. So I'm suspecting that Ubuntu's etwork-
manager might be involved in this, I've put it to the affects list.

Specifically, by editing Debian's /lib/systemd/system/NetworkManager.service 
like this:
-After=network-pre.target dbus.service
+Wants=network.target
+Before=network.target

...the dependency cycle error was affecting Debian too.

Tomorrow I'll try the opposite, to revert the Ubuntu .diff from
/lib/systemd/system/NetworkManager.service and see if it solves the
issue.

** Also affects: network-manager (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Breaking ordering cycle by deleting job nbd-client.service/start

Status in nbd package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  New

Bug description:
  $ lsb_release -rd
  Description:  Ubuntu 15.04
  Release:  15.04

  $ apt-cache policy nbd-client
  nbd-client:
Installed: 1:3.8-4ubuntu0.1
Candidate: 1:3.8-4ubuntu0.1
Version table:
   *** 1:3.8-4ubuntu0.1 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ vivid-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:3.8-4 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages

  I'm using the nbd-client to mount some raw disk images over the
  network but starting the nbd-client automatically during bootup does
  not happen due to the following:

  Aug 22 08:54:20 fractal kernel: [   11.875885] systemd[1]: Found dependency 
on nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875890] systemd[1]: Breaking ordering 
cycle by deleting job nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875891] systemd[1]: Job 
nbd-client.service/start deleted to break ordering cycle starting with 
basic.target/start

  Meaning after boot, I have to manually run `sudo ndb-client start`
  every time I want to access these images. Note that this is no
  diskless system, the images I mount via NBD do not contain the local
  system, they are totally unrelated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679/+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 696435] Re: wait-for-root fails to detect nbd root

2016-03-19 Thread Alkis Georgopoulos
This is still an issue in Ubuntu 16.04, now initramfs-tools
unconditionally calls `wait-for-root /dev/nbd0 10` without even using
ROOTDELAY.

I also reported this bug to https://github.com/yoe/nbd/issues/36.

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

Title:
  wait-for-root fails to detect nbd root

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in nbd package in Ubuntu:
  Confirmed

Bug description:
  When using an nbd root, wait-for-root blocks for 30 seconds before
  booting continues successfully.

  Using Ubuntu Natty, related packages versions:
  nbd-client 1:2.9.16-6ubuntu1 
  initramfs-tools 0.98.1ubuntu9

  The wait-for-root call from /usr/share/initramfs-tools/scripts/local:
while [ -z "${FSTYPE}" ]; do
FSTYPE=$(wait-for-root "${ROOT}" ${ROOTDELAY:-30})

# Run failure hooks, hoping one of them can fix up the system
# and we can restart the wait loop.  If they all fail, abort
# and move on to the panic handler and shell.
if [ -z "${FSTYPE}" ] && ! try_failure_hooks; then
break
fi
done

  I replaced wait-for-root with a sh script that did `set >&2`, here are the 
relevant environment variables at the time wait-for-root was called:
  ROOT='/dev/nbd0'
  ROOTDELAY=''
  ROOTFLAGS=''
  ROOTFSTYPE=''
  nbdroot='192.168.0.1,2011'

  It's probably worth noting that "nbd0: unknown partition table" was
  displayed asynchronously 1-2 seconds after wait-for-root was invoked
  and while it was still waiting. But I tried adding a "sleep 5" as the
  last line of local-top/nbd, so that the nbd message was displayed a
  lot before wait-for-root was called, and it didn't make a difference.
  So I don't think a race condition is involved in this problem.

  Temporarily I'm passing rootdelay=1 in the kernel command line to work
  around the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/696435/+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 1492546] Re: ifdown stops LTSP's "manual" interface on shutdown

2016-02-22 Thread Alkis Georgopoulos
I'm closing the LTSP task as LTSP 5.5.6 got released and was published
in Xenial without the fix being included, and the newer ifupdown makes
the fix not necessary anymore.

** Changed in: ltsp (Ubuntu)
   Status: Triaged => Won't Fix

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

Title:
  ifdown stops LTSP's "manual" interface on shutdown

Status in ifupdown package in Ubuntu:
  Fix Released
Status in ltsp package in Ubuntu:
  Won't Fix
Status in ifupdown package in Debian:
  Fix Released
Status in ltsp package in Debian:
  New

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1492546/+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 1541532] Re: migrate UTC setting from /etc/default/rcS to adjtime

2016-02-16 Thread Alkis Georgopoulos
Hi Martin,

I reported it here: https://github.com/systemd/systemd/issues/2638

We also need to fix this in the systemd packaging in Debian/Ubuntu:
# grep printf /var/lib/dpkg/info/systemd.postinst 
printf "0.0 0 0.0\n0\nLOCAL" > /etc/adjtime

This is similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699554
and it should have a newline at the end:
printf "0.0 0 0.0\n0\nLOCAL\n" > /etc/adjtime

Thanks!

** Bug watch added: Debian Bug tracker #699554
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699554

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

Title:
  migrate UTC setting from  /etc/default/rcS to adjtime

Status in installation-guide package in Ubuntu:
  Fix Released
Status in lupin package in Ubuntu:
  Fix Released
Status in mbr package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in sysvinit package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  Fix Released
Status in mbr package in Debian:
  New

Bug description:
  This has been an Ubuntu delta in systemd and perhaps other Ubuntu
  packages for a long time. But /etc/default/rcS is a SysV-ism, and no
  other setting in there is relevant. Steps:

   * Bump the version guard in systemd.conf for migrating the actual setting 
(keep until 16.04 LTS)
   * Ensure that we only look at the LOCAL setting during boot, and do no 
actual drift correction at boot, as the kernel does that by itself.
   * grep the archive for software which might directly look at or even write 
that file (Ubuntu specific config tools and the like).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/installation-guide/+bug/1541532/+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 1541532] Re: migrate UTC setting from /etc/default/rcS to adjtime

2016-02-16 Thread Alkis Georgopoulos
With the switch to configure UTC from /etc/adjtime instead of
/etc/default/rcS, I'm having the following regression:

I've installed Xenial some months ago and it's fully updated.
Without customizing it, my /etc/adjtime reads:
0.0 0 0
0

The regression is this:
# timedatectl set-local-rtc 1
Failed to set local RTC: Failed to set RTC to local/UTC: Input/output error

I can work around the issue with two ways:
1) Completely delete /etc/adjtime. Then `timedatectl set-local-rtc 1` generates 
it, and `timedatectl set-local-rtc 0` deletes it with no errors.
2) Add "LOCAL" or "UTC" to the end of /etc/adjtime. Then again  `timedatectl 
set-local-rtc XXX` works as expected.

Am I supposed not to have that file?
Should I file a bug report against systemd so that it doesn't have parse errors 
if the LOCAL/UTC keyword is missing?

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

Title:
  migrate UTC setting from  /etc/default/rcS to adjtime

Status in installation-guide package in Ubuntu:
  Fix Released
Status in lupin package in Ubuntu:
  Fix Released
Status in mbr package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in sysvinit package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  Fix Released
Status in mbr package in Debian:
  New

Bug description:
  This has been an Ubuntu delta in systemd and perhaps other Ubuntu
  packages for a long time. But /etc/default/rcS is a SysV-ism, and no
  other setting in there is relevant. Steps:

   * Bump the version guard in systemd.conf for migrating the actual setting 
(keep until 16.04 LTS)
   * Ensure that we only look at the LOCAL setting during boot, and do no 
actual drift correction at boot, as the kernel does that by itself.
   * grep the archive for software which might directly look at or even write 
that file (Ubuntu specific config tools and the like).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/installation-guide/+bug/1541532/+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 1492546] Re: Systemd runs ifdown on shutdown even when it shouldn't

2016-01-13 Thread Alkis Georgopoulos
Well...

This is *not* needed anymore, i.e. the current bug was solved:
# sed '/^ExecStop=/d' -i /lib/systemd/system/ifup@.service

Unfortunately now this is needed, i.e. the same bug appeared elsewhere:
# sed '/^ExecStop=/d' -i /lib/systemd/system/networking.service

The networking.service file now got an unconditional ifdown command:
$ grep ExecStop /lib/systemd/system/networking.service  
ExecStop=/sbin/ifdown -a --read-environment

Wouldn't it be easier to create a small "careful-ifdown"  script,
that borrows code from /etc/init/networking.conf, and have all the
.service and init files call that one instead?

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

Title:
  Systemd runs ifdown on shutdown even when it shouldn't

Status in ifupdown package in Ubuntu:
  Fix Released
Status in ltsp package in Ubuntu:
  Invalid
Status in ifupdown package in Debian:
  Fix Released

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1492546/+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 1492546] Re: Systemd runs ifdown on shutdown even when it shouldn't

2016-01-13 Thread Alkis Georgopoulos
> ifupdown should not have a config stanza (or at least only a manual
one) for this.

Hi Martin, yup, when network manager was introduced in Ubuntu I've had added 
code to LTSP to dynamically put "iface $DEVICE inet manual" in 
/etc/network/interfaces, to prevent network manager from assigning an IP to it, 
breaking netboot.
An empty line didn't do the trick, "manual" was necessary.

I'll test and leave feedback when systemd 0.8.8ubuntu1 reaches the
repositories.

Thanks a lot for your work in this!

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

Title:
  Systemd runs ifdown on shutdown even when it shouldn't

Status in ifupdown package in Ubuntu:
  Fix Released
Status in ltsp package in Ubuntu:
  Invalid
Status in ifupdown package in Debian:
  Fix Released

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1492546/+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 1492546] Re: ifdown stops "manual" interfaces on shutdown

2016-01-13 Thread Alkis Georgopoulos
> Alkis, would be great if you could test with 0.8.8ubuntu2!

I confirm that ifupdown 0.8.8ubuntu2 solves the issue.
I tested both with plain `poweroff` and with `ifdown -a`, which didn't bring 
DOWN the "manual" interface.

Thanks a lot Martin!

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

Title:
  ifdown stops "manual" interfaces on shutdown

Status in ifupdown package in Ubuntu:
  Fix Released
Status in ltsp package in Ubuntu:
  Invalid
Status in ifupdown package in Debian:
  Unknown

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1492546/+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 1492546] Re: Systemd runs ifdown on shutdown even when it shouldn't

2015-12-14 Thread Alkis Georgopoulos
Hi Martin, I've set up remote syslogging and I'm attaching the relevant
lines for the "ltsp33" client.

** Attachment added: "syslog"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1492546/+attachment/4534472/+files/syslog

** Changed in: systemd (Ubuntu)
   Status: Incomplete => Triaged

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

Title:
  Systemd runs ifdown on shutdown even when it shouldn't

Status in ltsp package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Triaged
Status in systemd package in Debian:
  Fix Released

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1492546/+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 1492546] Re: Systemd runs ifdown on shutdown even when it shouldn't

2015-12-14 Thread Alkis Georgopoulos
Thank you Martin, I'm attaching journal.txt.

** Attachment added: "journal.txt"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1492546/+attachment/4534902/+files/journal.txt

** Changed in: systemd (Ubuntu)
   Status: Incomplete => Triaged

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

Title:
  Systemd runs ifdown on shutdown even when it shouldn't

Status in ltsp package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Triaged
Status in systemd package in Debian:
  Fix Released

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1492546/+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 1492546] Re: Systemd runs ifdown on shutdown even when it shouldn't

2015-12-06 Thread Alkis Georgopoulos
Martin, I'm seeing a regression for this with systemd 228-2ubuntu1 in Ubuntu 
Xenial.
Now I again have to remove the "ExecStop=/sbin/ifdown %I" stanza in order to 
get netbooted clients to shut down.

Maybe something else is stopping the ifup service on shutdown now?
I tried to downgrade to the version shipped with Wily, but I was blocked by 
some dependency issues.

** Changed in: systemd (Ubuntu)
   Status: Fix Released => Triaged

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

Title:
  Systemd runs ifdown on shutdown even when it shouldn't

Status in ltsp package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Triaged
Status in systemd package in Debian:
  Fix Released

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1492546/+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 221363] Re: Policy Kit Unlock Buttons Greyed Out when using NX / VNC / LTSP

2015-12-06 Thread Alkis Georgopoulos
Is this still an issue in recent Ubuntu/LTSP versions?

** Changed in: ltsp (Ubuntu)
   Status: Confirmed => Incomplete

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

Title:
  Policy Kit Unlock Buttons Greyed Out when using NX / VNC / LTSP

Status in FreeNX Server:
  Fix Released
Status in gdm:
  New
Status in PolicyKit:
  Invalid
Status in system-tools-backends:
  Fix Released
Status in ltsp package in Ubuntu:
  Incomplete
Status in policykit package in Ubuntu:
  Invalid
Status in policykit-1 package in Ubuntu:
  Invalid
Status in system-tools-backends package in Ubuntu:
  Triaged

Bug description:
  I installed 8.04 LTS server on a system.  Then installed ubuntu-
  desktop using apt.  Installed Nomachine's NX server and connected to
  it.

  The unlock buttons on Users and Groups or Network are greyed out and
  un-accessible.  Tried running from a term 'sudo users-admin' with the
  same results.

  Works fine with VNC and NX "Shadow" session however this is not really
  acceptable as it means a session has to be running on console first.

  I have tried to enable every option in Authorizations to allow the
  remote session to have privileges to no avail.

  output of dpkg relevant packages:

  ii  gnome-system-t 2.22.0-0ubuntu Cross-platform configuration utilities for G
  ii  liboobs-1-42.22.0-0ubuntu GObject based interface to system-tools-back
  ii  policykit  0.7-2ubuntu7   framework for managing administrative polici
  ii  system-tools-b 2.6.0-0ubuntu7 System Tools to manage computer configuratio

  
  == Workarounds  ==
  

  1) *Jaunty or older*

  From
  https://bugs.launchpad.net/ubuntu/+source/policykit/+bug/238799/comments/16
  (the packages from comment 24 are broken links now):

  I was able to get access via VNC tunneled through SSH by changing the
  following settings in policykit. You can do it locally via
  Authorizations, or you can do it remotely using "sudo ck-launch-
  session polkit-gnome-authorization" in a terminal window in your
  tunneled VNC session. This worked on Ubuntu 9.04 Server RC running
  xubuntu-desktop, so as always YMMV.

  For system configuration, change all implicit authorizations under org
  -> freedesktop -> systemtoolsbackends -> Manage System Configuration
  (org.freedesktop.systemtoolsbackends.set) to "Admin Authentication."

  For user management, change all implicit authorizations under org ->
  freedesktop -> systemtoolsbackends -> self -> Change User
  Configuration (org.freedesktop.systemtoolsbackends.self.set) to
  "Authentication."

  Reset gdm by rebooting or running "sudo /etc/init.d/gdm restart" from
  a terminal window, and you should be able to unlock the user settings
  control panel and other similarly useful things through your tunneled
  VNC session.

  2) *Karmic or newer*

  Apply this patch: 
http://launchpadlibrarian.net/39471473/polkit-systemtools-remote-allow.patch
  # sudo cp -a 
/usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy 
/usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy.ori
  # sudo patch 
/usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy 
polkit-systemtools-remote-allow.patch

  Then kill polkitd, it will be restarted automatically:
  # sudo pkill polkitd

To manage notifications about this bug go to:
https://bugs.launchpad.net/freenx-server/+bug/221363/+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 891793] Re: Login with USB key or smart card

2015-12-05 Thread Alkis Georgopoulos
Hi, LDM will be deprecated in LTSP 6, so I don't think anyone's going to work 
on this issue.
So I'm marking it "Won't Fix".

** Changed in: ltsp
   Status: Triaged => Won't Fix

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

Title:
  Login with USB key or smart card

Status in LTSP:
  Won't Fix
Status in gdm package in Ubuntu:
  New
Status in lightdm package in Ubuntu:
  Triaged
Status in lxdm package in Ubuntu:
  New
Status in pam package in Ubuntu:
  New
Status in sdm package in Ubuntu:
  New
Status in seahorse package in Ubuntu:
  New
Status in shadow package in Ubuntu:
  New
Status in slim package in Ubuntu:
  Invalid
Status in wdm package in Ubuntu:
  New
Status in xdm package in Ubuntu:
  New

Bug description:
  I want to be able to authenticate/login by using a USB key, SD/MMC
  card or a smart card.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ltsp/+bug/891793/+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 1457730] Re: Upstart packaging conflicts with man Xsession

2015-12-04 Thread Alkis Georgopoulos
Fix released in LDM 2.2.16.

** Changed in: ltsp (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  Upstart packaging conflicts with man Xsession

Status in ltsp package in Ubuntu:
  Fix Released
Status in upstart package in Ubuntu:
  New

Bug description:
  Ubuntu 14.04, upstart 1.12.1-0ubuntu4.2.

  man Xsession:
  "Xsession  may  optionally be passed a single argument indicating the type of 
X session to be started."
  "default produces the same behavior as if no session type argument had been 
given at all."

  In /etc/X11/Xsession.d/20x11-common_process-args and in 
/etc/X11/Xsession.d/50x11-common_determine-startup, Xsession processes its 
command line, the user settings, and the Debian alternatives system and sets 
STARTUP which after that is the correct program to run.
  I.e. the program to run is decided at the "50" number.

  As an example of correct behaviour, gnome-session-common in
  /etc/X11/Xsession.d/55gnome-session_gnomerc processes $STARTUP in
  55gnome-session_gnomerc.

  Unfortunately /etc/X11/Xsession.d/00upstart doesn't care for $STARTUP
  only works if "$1" points to an Exec= line of an xsession.desktop
  file. This does work with e.g. lightdm, but it breaks in a lot of
  other cases, notably in LTSP where LDM passes "" as the default case
  when the user didn't select anything at all from the session selection
  combo box.

  This used to work in 12.04 and it's now broken in 14.04. I haven't
  checked non LTS releases.

  The fix consists of two parts:
  1) To rename /etc/X11/Xsession.d/00upstart to /etc/X11/Xsession.d/55upstart, 
so that $STARTUP is set. This doesn't cause any issues with the variables that 
00upstart sets inside it, they're only accessed after the "50" number which is 
where $STARTUP is determined.
  2) Inside 55upstart, to change
  BASESESSION=${1% *}
  to
  BASESESSION=${STARTUP%% *}
  That's all, but if you do want more common code with 55gnome-session_gnomerc, 
you can copy the code from there, it does the same thing even if it calls it 
BASESTARTUP instead of BASESESSION.

  Thanks,
  Alkis

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1457730/+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 1501189] Re: DNS breaks when port=0 is used in dnsmasq.conf

2015-10-06 Thread Alkis Georgopoulos
Hi Robie,

while this also happens in Debian, the use case is more common in Ubuntu, 
because NetworkManager is patched to use a spawned dnsmasq instance as a local 
resolver, and mixing the two DNS servers is problematic (neither bind-dynamic 
nor bind-interfaces work very well).
In Debian they more frequently use the normal dnsmasq/DNS service as it was 
designed, because NM doesn't spawn a local resolver there.

For upstream report, Simon (the upstream dnsmasq developer and Debian
maintainer) already answered here, Simon would you like me to file a
debian bug as well? It's easy to work around this issue, so we can even
close it with won't fix if you prefer.

Thank you.

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

Title:
  DNS breaks when port=0 is used in dnsmasq.conf

Status in dnsmasq package in Ubuntu:
  Triaged

Bug description:
  The following function is defined in /etc/init.d/dnsmasq:

  start_resolvconf()
  {
  # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
  # Then dnsmasq won't be providing local DNS, so don't add it to
  # the resolvconf server set.
  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  if [ -x /sbin/resolvconf ] ; then
  echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
  fi
  return 0
  }

  When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it 
only as a (proxy)DHCP/TFTP server,
  127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens 
there.

  One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
  But that doesn't make much sense, we don't want to exclude some interface, 
we're not running a DNS server at all.

  So it would be nice if dnsmasq checked if port=0 is defined in its
  configuration, and didn't add 127.0.0.1 to resolvconf then.

  Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf 
]`:
  grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+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 1492546] Re: Systemd runs ifdown on shutdown even when it shouldn't

2015-10-05 Thread Alkis Georgopoulos
Thanks a lot Martin, works fine for me.
/me reverts the LTSP workaround...

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

Title:
  Systemd runs ifdown on shutdown even when it shouldn't

Status in ltsp package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd package in Debian:
  New

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1492546/+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 1481025] Re: Keyboard shortcut for layout switching works in Unity but not in Gnome-Flashback

2015-10-04 Thread Alkis Georgopoulos
Gunnar, one of the 3 problems here is that im-config starts ibus while it 
shouldn't.
We Greeks have no need for ibus, and 
  IM_CONFIG_DEFAULT_MODE=auto
should understand that and act accordingly like im-switch did in the past.

In the past I've exchanged some emails with Osamu, the im-config Debian
maintainer, and he told me to file a bug report for it.

Do you have some different information to mark this bug as invalid in that 
package?
If so, could you please explain why?
Thank you.

** Changed in: im-config (Ubuntu)
   Status: Invalid => Confirmed

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

Title:
  Keyboard shortcut for layout switching works in Unity but not in
  Gnome-Flashback

Status in gnome-flashback package in Ubuntu:
  Confirmed
Status in ibus package in Ubuntu:
  New
Status in im-config package in Ubuntu:
  Confirmed
Status in unity-settings-daemon package in Ubuntu:
  Confirmed

Bug description:
  My keyboard layout is "us,gr", and the new Gnome way to switch between them 
is by pressing "Super+Space".
  This works fine in:
   * Gnome-Flashback (Metacity) 14.04
   * Unity 14.04
   * Unity 15.10

  It doesn't work in:
   * Gnome-Flashback (Metacity) 15.10

  I've tested with the 15.10 default (Unity) installation, selecting
  Greek language in ubiquity, and adding gnome-flashback after the
  installation.

  Just for reference, here are my related gsettings:
  $ gsettings list-recursively org.gnome.desktop.input-sources
  org.gnome.desktop.input-sources show-all-sources false
  org.gnome.desktop.input-sources per-window false
  org.gnome.desktop.input-sources current uint32 1
  org.gnome.desktop.input-sources sources [('xkb', 'us'), ('xkb', 'gr')]
  org.gnome.desktop.input-sources xkb-options ['grp:alt_shift_toggle', 
'grp_led:scroll']

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-flashback/+bug/1481025/+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 1481025] Re: Keyboard shortcut for layout switching works in Unity but not in Gnome-Flashback

2015-10-04 Thread Alkis Georgopoulos
** Also affects: im-config (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: ibus (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Keyboard shortcut for layout switching works in Unity but not in
  Gnome-Flashback

Status in gnome-flashback package in Ubuntu:
  Confirmed
Status in ibus package in Ubuntu:
  New
Status in im-config package in Ubuntu:
  New
Status in unity-settings-daemon package in Ubuntu:
  Confirmed

Bug description:
  My keyboard layout is "us,gr", and the new Gnome way to switch between them 
is by pressing "Super+Space".
  This works fine in:
   * Gnome-Flashback (Metacity) 14.04
   * Unity 14.04
   * Unity 15.10

  It doesn't work in:
   * Gnome-Flashback (Metacity) 15.10

  I've tested with the 15.10 default (Unity) installation, selecting
  Greek language in ubiquity, and adding gnome-flashback after the
  installation.

  Just for reference, here are my related gsettings:
  $ gsettings list-recursively org.gnome.desktop.input-sources
  org.gnome.desktop.input-sources show-all-sources false
  org.gnome.desktop.input-sources per-window false
  org.gnome.desktop.input-sources current uint32 1
  org.gnome.desktop.input-sources sources [('xkb', 'us'), ('xkb', 'gr')]
  org.gnome.desktop.input-sources xkb-options ['grp:alt_shift_toggle', 
'grp_led:scroll']

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-flashback/+bug/1481025/+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 1481025] Re: Keyboard shortcut for layout switching works in Unity but not in Gnome-Flashback

2015-10-04 Thread Alkis Georgopoulos
Hi Gunnar,

that patch works lovely for me, I tried it in Wily beta 2 + updates in:
gnome-flashback-metacity (running ibus)
mate-desktop (running fcitx)
lubuntu (running fcitx)
...and it prohibited ibus and fcitx from running, solving the keyboard layout 
switching problems that they were causing (fcitx is causing a different 
problem, LP #1501832).

Is it possible to have Wily shipped with that patch included? Many many
users will be grateful for that! :)

Thank you very much!

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

Title:
  Keyboard shortcut for layout switching works in Unity but not in
  Gnome-Flashback

Status in gnome-flashback package in Ubuntu:
  Confirmed
Status in ibus package in Ubuntu:
  New
Status in im-config package in Ubuntu:
  Confirmed
Status in unity-settings-daemon package in Ubuntu:
  Confirmed

Bug description:
  My keyboard layout is "us,gr", and the new Gnome way to switch between them 
is by pressing "Super+Space".
  This works fine in:
   * Gnome-Flashback (Metacity) 14.04
   * Unity 14.04
   * Unity 15.10

  It doesn't work in:
   * Gnome-Flashback (Metacity) 15.10

  I've tested with the 15.10 default (Unity) installation, selecting
  Greek language in ubiquity, and adding gnome-flashback after the
  installation.

  Just for reference, here are my related gsettings:
  $ gsettings list-recursively org.gnome.desktop.input-sources
  org.gnome.desktop.input-sources show-all-sources false
  org.gnome.desktop.input-sources per-window false
  org.gnome.desktop.input-sources current uint32 1
  org.gnome.desktop.input-sources sources [('xkb', 'us'), ('xkb', 'gr')]
  org.gnome.desktop.input-sources xkb-options ['grp:alt_shift_toggle', 
'grp_led:scroll']

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-flashback/+bug/1481025/+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 1481025] Re: Keyboard shortcut for layout switching works in Unity but not in Gnome-Flashback

2015-10-04 Thread Alkis Georgopoulos
> How can you tell that im-config shouldn't start IBus?

Isn't that why system settings vs user settings exist?

For example, my /etc/default/keyboard reads:
XKBLAYOUT="us,gr"
XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll"

Then for example Gnome puts those as the default layouts for my session. That's 
what 99% of the local users want.
It doesn't automatically include Swedish, Hebrew and all other possible layouts 
that I might need.
But if some person wants to type in Swedish, he can easily select that on a 
per-user basis from a menu or a configuration file.

Same for im-config, ibus, fcitx, there can be system defaults, and per user 
settings (and AFAIK there already are, the problem is that 
IM_CONFIG_DEFAULT_MODE=auto doesn't process them).
There's no point in millions of users worldwide running ibus without needing it 
just to avoid reading user settings.


> Did im-switch work differently in this respect? To be honest, I don't 
> remember.

I'm certain that ibus was installed but not started for the Greek locale
in previous Ubuntu versions. I haven't looked into im-switch more than
that though.


After Wily is out (when hopefully I'll have some more free time), I'll install 
Debian in a VM and report it there as well, and link the bug # here.

I was just hoping to have a quicker fix, in any of the above packages, in time 
for Wily.
Thank you.

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

Title:
  Keyboard shortcut for layout switching works in Unity but not in
  Gnome-Flashback

Status in gnome-flashback package in Ubuntu:
  Confirmed
Status in ibus package in Ubuntu:
  New
Status in im-config package in Ubuntu:
  Confirmed
Status in unity-settings-daemon package in Ubuntu:
  Confirmed

Bug description:
  My keyboard layout is "us,gr", and the new Gnome way to switch between them 
is by pressing "Super+Space".
  This works fine in:
   * Gnome-Flashback (Metacity) 14.04
   * Unity 14.04
   * Unity 15.10

  It doesn't work in:
   * Gnome-Flashback (Metacity) 15.10

  I've tested with the 15.10 default (Unity) installation, selecting
  Greek language in ubiquity, and adding gnome-flashback after the
  installation.

  Just for reference, here are my related gsettings:
  $ gsettings list-recursively org.gnome.desktop.input-sources
  org.gnome.desktop.input-sources show-all-sources false
  org.gnome.desktop.input-sources per-window false
  org.gnome.desktop.input-sources current uint32 1
  org.gnome.desktop.input-sources sources [('xkb', 'us'), ('xkb', 'gr')]
  org.gnome.desktop.input-sources xkb-options ['grp:alt_shift_toggle', 
'grp_led:scroll']

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-flashback/+bug/1481025/+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 1501189] Re: Don't put 127.0.0.1 in resolvconf when port=0

2015-09-30 Thread Alkis Georgopoulos
Better regex to avoid a possibly commented #port=0:
grep -qr "^[[:space:]]*port=0" /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

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

Title:
  Don't put 127.0.0.1 in resolvconf when port=0

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  The following function is defined in /etc/init.d/dnsmasq:

  start_resolvconf()
  {
  # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
  # Then dnsmasq won't be providing local DNS, so don't add it to
  # the resolvconf server set.
  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  if [ -x /sbin/resolvconf ] ; then
  echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
  fi
  return 0
  }

  When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it 
only as a (proxy)DHCP/TFTP server,
  127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens 
there.

  One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
  But that doesn't make much sense, we don't want to exclude some interface, 
we're not running a DNS server at all.

  So it would be nice if dnsmasq checked if port=0 is defined in its
  configuration, and didn't add 127.0.0.1 to resolvconf then.

  Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf 
]`:
  grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+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 1501189] [NEW] Don't put 127.0.0.1 in resolvconf when port=0

2015-09-30 Thread Alkis Georgopoulos
Public bug reported:

The following function is defined in /etc/init.d/dnsmasq:

start_resolvconf()
{
# If interface "lo" is explicitly disabled in /etc/default/dnsmasq
# Then dnsmasq won't be providing local DNS, so don't add it to
# the resolvconf server set.
for interface in $DNSMASQ_EXCEPT
do
[ $interface = lo ] && return
done

if [ -x /sbin/resolvconf ] ; then
echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
fi
return 0
}

When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it only 
as a (proxy)DHCP/TFTP server,
127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens 
there.

One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
But that doesn't make much sense, we don't want to exclude some interface, 
we're not running a DNS server at all.

So it would be nice if dnsmasq checked if port=0 is defined in its
configuration, and didn't add 127.0.0.1 to resolvconf then.

Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf ]`:
grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

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


** Tags: patch

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

Title:
  Don't put 127.0.0.1 in resolvconf when port=0

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  The following function is defined in /etc/init.d/dnsmasq:

  start_resolvconf()
  {
  # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
  # Then dnsmasq won't be providing local DNS, so don't add it to
  # the resolvconf server set.
  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  if [ -x /sbin/resolvconf ] ; then
  echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
  fi
  return 0
  }

  When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it 
only as a (proxy)DHCP/TFTP server,
  127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens 
there.

  One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
  But that doesn't make much sense, we don't want to exclude some interface, 
we're not running a DNS server at all.

  So it would be nice if dnsmasq checked if port=0 is defined in its
  configuration, and didn't add 127.0.0.1 to resolvconf then.

  Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf 
]`:
  grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+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 1494139] [NEW] If a source has a comment and a single component, the component is not displayed

2015-09-10 Thread Alkis Georgopoulos
Public bug reported:

Ubuntu 14.04.3, software-properties-gtk 0.92.37.3

If I have this in my sources.list.d/some-source.list:
deb http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu trusty main #My repository

Then "main" does not appear in the list box in the software-properties-gtk 
dialog → Other Software tab:
> My repository trusty
> http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu

If I have 2 components, e.g. "main non-free", then both appear OK:
> My repository trusty main non-free
> http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu

If I again put 1 component there, but remove the comment, then the component 
does appear on a single line:
> http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu trusty main

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  If a source has a comment and a single component, the component is not
  displayed

Status in software-properties package in Ubuntu:
  New

Bug description:
  Ubuntu 14.04.3, software-properties-gtk 0.92.37.3

  If I have this in my sources.list.d/some-source.list:
  deb http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu trusty main #My repository

  Then "main" does not appear in the list box in the software-properties-gtk 
dialog → Other Software tab:
  > My repository trusty
  > http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu

  If I have 2 components, e.g. "main non-free", then both appear OK:
  > My repository trusty main non-free
  > http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu

  If I again put 1 component there, but remove the comment, then the component 
does appear on a single line:
  > http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu trusty main

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1494139/+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 1492546] [NEW] Systemd runs ifdown on shutdown even when it shouldn't

2015-09-05 Thread Alkis Georgopoulos
Public bug reported:

The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, it's 
not part of upstream systemd.
On shutdown, it unconditionally ifdowns all interfaces:
  ExecStop=/sbin/ifdown %I

This is a regression from previous init systems (sysvinit and upstart)
which cared so that when a network file system was in use, they didn't
ifdown the interfaces.

Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
  check_network_file_systems()
  check_network_swaps()
which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

So, please call the same functions in the ExecStop= part of
ifup@.service.

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

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Assignee: Martin Pitt (pitti)
 Status: New

** Also affects: ltsp (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/1492546

Title:
  Systemd runs ifdown on shutdown even when it shouldn't

Status in ltsp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  The unit /lib/systemd/system/ifup@.service is Debian and Ubuntu specific, 
it's not part of upstream systemd.
  On shutdown, it unconditionally ifdowns all interfaces:
ExecStop=/sbin/ifdown %I

  This is a regression from previous init systems (sysvinit and upstart)
  which cared so that when a network file system was in use, they didn't
  ifdown the interfaces.

  Specifically, both /etc/init.d/networking and /etc/init/networking contain 
these functions:
check_network_file_systems()
check_network_swaps()
  which output the message "not deconfiguring network interfaces: network file 
systems still mounted" and exit.

  So, please call the same functions in the ExecStop= part of
  ifup@.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1492546/+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 1492546] Re: Systemd runs ifdown on shutdown even when it shouldn't

2015-09-05 Thread Alkis Georgopoulos
This also affects LTSP, e.g. Wily clients can't shutdown because
/sbin/poweroff is no longer accessible once ifup@.service unmounts
/dev/nbd0.

If systemd is fixed in Ubuntu before 15.10 is released, problem solved,
otherwise we'll need to commit the following in upstream LTSP.

Script /usr/share/ltsp/init-ltsp.d/50-systemd-ifup:

if [ -f /lib/systemd/system/ifup@.service ]; then
mkdir -p /etc/systemd/system/ifup@$DEVICE.service.d
cat > /etc/systemd/system/ifup@$DEVICE.service.d/ltsp.conf 

[Touch-packages] [Bug 133072] Re: tty console doen't show characters with accent

2015-08-12 Thread Alkis Georgopoulos
The problem still exists in 15.10 daily build.

** Changed in: console-setup (Ubuntu)
   Status: Fix Released = Confirmed

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

Title:
  tty console doen't show characters with accent

Status in console-setup package in Ubuntu:
  Confirmed
Status in kbd package in Ubuntu:
  Fix Released

Bug description:
  In Kubuntu 7.10 tribe 4, tty console (out of X) cannot display characters 
with accent, also can't display 'ñ' and '€'.
  Locale value:

  LANG=es_ES.UTF-8
  LANGUAGE=es_ES:es:en_GB:en
  LC_CTYPE=es_ES.UTF-8
  LC_NUMERIC=es_ES.UTF-8
  LC_TIME=es_ES.UTF-8
  LC_COLLATE=es_ES.UTF-8
  LC_MONETARY=es_ES.UTF-8
  LC_MESSAGES=es_ES.UTF-8
  LC_PAPER=es_ES.UTF-8
  LC_NAME=es_ES.UTF-8
  LC_ADDRESS=es_ES.UTF-8
  LC_TELEPHONE=es_ES.UTF-8
  LC_MEASUREMENT=es_ES.UTF-8
  LC_IDENTIFICATION=es_ES.UTF-8
  LC_ALL=

  Thanks for your atention.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/133072/+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 1484101] [NEW] Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10

2015-08-12 Thread Alkis Georgopoulos
Public bug reported:

This affects all Ubuntu CDs and installations after 14.10.

The VTs are not configured to show UTF-8 characters because of a wrong
CHARMAP value at /etc/default/console-setup (ISO-8859-15 instead of
UTF-8).

The cause most probably is that recent console-setup.postinst versions
create a different configuration file based on LANG:

# rm /etc/default/console-setup
# LANG=C apt-get install --reinstall console-setup
# grep CHARMAP /etc/default/console-setup 
CHARMAP=ISO-8859-15

While with C.UTF-8 (or en_US.UTF-8 or whatever) it produces the correct CHARMAP:
# rm /etc/default/console-setup
# LANG=en_US.UTF-8 apt-get install --reinstall console-setup
# grep CHARMAP /etc/default/console-setup 
CHARMAP=UTF-8

I think this should be fixed in console-setup, but it's possible that
the live CD code may want to use LANG=C.UTF-8 in any case.

** Affects: console-setup (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Broken CHARMAP with LANG=C on postinst, affects all installations
  after 14.10

Status in console-setup package in Ubuntu:
  New

Bug description:
  This affects all Ubuntu CDs and installations after 14.10.

  The VTs are not configured to show UTF-8 characters because of a wrong
  CHARMAP value at /etc/default/console-setup (ISO-8859-15 instead of
  UTF-8).

  The cause most probably is that recent console-setup.postinst versions
  create a different configuration file based on LANG:

  # rm /etc/default/console-setup
  # LANG=C apt-get install --reinstall console-setup
  # grep CHARMAP /etc/default/console-setup 
  CHARMAP=ISO-8859-15

  While with C.UTF-8 (or en_US.UTF-8 or whatever) it produces the correct 
CHARMAP:
  # rm /etc/default/console-setup
  # LANG=en_US.UTF-8 apt-get install --reinstall console-setup
  # grep CHARMAP /etc/default/console-setup 
  CHARMAP=UTF-8

  I think this should be fixed in console-setup, but it's possible that
  the live CD code may want to use LANG=C.UTF-8 in any case.

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


  1   2   >