[Touch-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles

[Alkis Georgopoulos]

** Changed in: ltsp (Ubuntu)
   Status: New => Invalid

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

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  New
Status in cruft-ng package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  Invalid
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Won't Fix
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+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 1998713] [NEW] Don't add universe to cdrom: sources

[Alkis Georgopoulos]

Public bug reported:

Please do not add "universe" in "deb cdrom:" lines of
/etc/apt/sources.list.

To reproduce the issue, boot Ubuntu GNOME 22.04, and at the live
session, run:

sudo add-apt-repository universe

After that, `apt update` will keep complaining:

W: Skipping acquire of configured file 'universe/binary-amd64/Packages'
as repository 'cdrom://Ubuntu 22.04.1 LTS _Jammy Jellyfish_ - Release
amd64 (20220809.1) jammy InRelease' doesn't have the component
'universe' (component misspelt in sources.list?)

** 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/1998713

Title:
  Don't add universe to cdrom: sources

Status in software-properties package in Ubuntu:
  New

Bug description:
  Please do not add "universe" in "deb cdrom:" lines of
  /etc/apt/sources.list.

  To reproduce the issue, boot Ubuntu GNOME 22.04, and at the live
  session, run:

  sudo add-apt-repository universe

  After that, `apt update` will keep complaining:

  W: Skipping acquire of configured file 'universe/binary-
  amd64/Packages' as repository 'cdrom://Ubuntu 22.04.1 LTS _Jammy
  Jellyfish_ - Release amd64 (20220809.1) jammy InRelease' doesn't have
  the component 'universe' (component misspelt in sources.list?)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1998713/+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 1992731] Re: The cursor can be freely moved around and used to erase characters on the TTY while at the login prompt

[Alkis Georgopoulos]

Reproduced in Ubuntu 22.04 and 20.04.
Could NOT reproduce in Ubuntu 18.04.

I think the problem is in `agetty` though, not in `login`.
Added `util-linux` to affected packages.

** Also affects: util-linux (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  The cursor can be freely moved around and used to erase characters on
  the TTY while at the login prompt

Status in shadow package in Ubuntu:
  New
Status in util-linux package in Ubuntu:
  New

Bug description:
  Welp, this is a weird one. Known to affect Ubuntu Server and multiple
  flavors of Ubuntu.

  Steps to reproduce:

  1: If you are shown a graphical login prompt (e.g. GDM or SDDM), switch to a 
TTY.
  2. At the login prompt, press the up arrow key twice.
  3: Press Backspace twice.
  4: Press Enter.

  Expected result: Nothing should happen, or possibly key codes should
  appear when the arrow keys are pressed, and those key codes should be
  erased when backspace is pressed.

  Actual result: The cursor moves up two lines when the up arrow key is
  pressed twice, and the "." and "4" of "22.04.1" are erased when
  Backspace is pressed twice. Upon pressing Enter, the TTY seems to
  freeze (no user input causes anything to happen), then the login
  prompt reverts back to its original state and the cursor assumes its
  proper location.

  Notes:
  This bug was first reported by a user named Liver_K on IRC as happening on 
Ubuntu Server 22.04 after upgrading from 20.04. alkisg then confirmed it on 
Ubuntu MATE 22.04, and I confirmed it on Kubuntu Focus Suite 22.04.

  Yes, you can indeed use this to erase everything in the TTY screen and
  leave the cursor in the upper-left corner as if the system was stuck.
  Pressing Enter resolves it after a while.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: login 1:4.8.1-2ubuntu2
  ProcVersionSignature: Ubuntu 5.17.0-1017.18-oem 5.17.15
  Uname: Linux 5.17.0-1017-oem x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: KDE
  Date: Thu Oct 13 00:44:03 2022
  InstallationDate: Installed on 2022-10-04 (8 days ago)
  InstallationMedia: Kubuntu 22.04.1 LTS "Jammy Jellyfish" (20220916)
  SourcePackage: shadow
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1992731/+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 48734] Re: Home permissions too open

[Alkis Georgopoulos]

Schools have started installing/upgrading to 22.04.1 and we're just now
seeing this.

This change takes away the ability of the users to share some of their data 
WITHOUT involving the administrator.
It's not "privacy by default", it's "mandatory privacy".
Privacy by default could be done with umask.

Administrative actions can mitigate the issue, but they're tricky as they 
cannot easily be applied to users that haven't logged in yet and folders that 
don't exist yet.
Sudoer scripts that would give the ability to the users to share stuff by 
themselves can be a worse security risk.

On the other hand, encrypted home directories is a trend with similar
issues.

I guess it'll be a bit easier to rewrite all the programs that need access to 
/home/username to use other locations such as /run/user/XXX, /home/shared/XXX, 
/home/public_html/XXX, /var/lib/AccountsService/users/user/face.png, 
/var/spool/* etc,
than to introduce an XDG specification for a new /home/user/private directory, 
and rewrite all the programs that need private or encryped data to use that 
one. That would be a much cleaner solution, but it can't be a goal for a single 
distribution.

So while this change does require us to spend some weeks reimplementing
our shared folders software, it might be for the best, let's see how it
goes. Cheers!

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

Title:
  Home permissions too open

Status in adduser package in Ubuntu:
  Fix Released
Status in shadow package in Ubuntu:
  Fix Released
Status in adduser source package in Hirsute:
  Fix Released
Status in shadow source package in Hirsute:
  Fix Released
Status in Ubuntu RTM:
  Opinion

Bug description:
  Binary package hint: debian-installer

  On a fresh dapper install i noticed that the file permissons for the
  home directory for the user created by the installer is set to 755,
  giving read access to everyone on the system.

  Surely this is a bad idea? If your set on the idea can we atleast have
  a option during the boot proccess?

  Also new files that are created via the console ('touch' etc.) are
  done so with '644' permissons, is there anything that can be done
  here? nautlius seems to create files at '600', which is a better
  setting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+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 1922414] Re: ssh-agent fails to start (has_option: command not found)

[Alkis Georgopoulos]

I also see it on Ubuntu MATE Jammy.
Will the fix come from Xorg,
or should we add LightDM to the affected projects list?

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

Title:
  ssh-agent fails to start (has_option: command not found)

Status in gdm3 package in Ubuntu:
  Fix Released
Status in xorg package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  I have been using ssh-agent for years and since I upgraded my system
  to Ubuntu 21.04/groovy, ssh-agent fails to start.

  Here is the error message:

  # journalctl | grep ssh-agent
  [...]
  Apr 02 20:16:32 vougeot /usr/libexec/gdm-x-session[3752]: 
/etc/X11/Xsession.d/90x11-common_ssh-agent: line 9: has_option: command not 
found

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: x11-common 1:7.7+22ubuntu1
  Uname: Linux 5.11.11-05-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu61
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: unknown
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Sat Apr  3 09:02:46 2021
  Dependencies: lsb-base 11.1.0ubuntu2
  DistUpgraded: Fresh install
  DistroCodename: hirsute
  DistroVariant: ubuntu
  DkmsStatus:
   tuxedo-keyboard, 3.0.4, 5.11.0-13-generic, x86_64: installed
   tuxedo-keyboard, 3.0.4, 5.11.0-13-lowlatency, x86_64: installed
   tuxedo-keyboard, 3.0.4, 5.11.11-05-lowlatency, x86_64: installed
  ExtraDebuggingInterest: No
  GraphicsCard:
   Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) 
(prog-if 00 [VGA controller])
 Subsystem: CLEVO/KAPOK Computer Iris Xe Graphics [1558:51a1]
  MachineType: TUXEDO TUXEDO InfinityBook S 15 Gen6
  PackageArchitecture: all
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.11-05-lowlatency 
root=/dev/mapper/MonVolume2-UbuntuRacine ro vsyscall=none security=apparmor 
quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/07/2020
  dmi.bios.release: 7.3
  dmi.bios.vendor: INSYDE Corp.
  dmi.bios.version: 1.07.03RTR
  dmi.board.name: NS50MU
  dmi.board.vendor: TUXEDO
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.ec.firmware.release: 7.2
  dmi.modalias: 
dmi:bvnINSYDECorp.:bvr1.07.03RTR:bd09/07/2020:br7.3:efr7.2:svnTUXEDO:pnTUXEDOInfinityBookS15Gen6:pvrNotApplicable:rvnTUXEDO:rnNS50MU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A:
  dmi.product.family: Not Applicable
  dmi.product.name: TUXEDO InfinityBook S 15 Gen6
  dmi.product.sku: Not Applicable
  dmi.product.version: Not Applicable
  dmi.sys.vendor: TUXEDO
  version.compiz: compiz 1:0.9.14.1+20.10.20200813-0ubuntu4
  version.libdrm2: libdrm2 2.4.104-1build1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.1-1
  version.libgl1-mesa-glx: libgl1-mesa-glx 21.0.1-1
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.10-3ubuntu5
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-2build1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1922414/+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 964705] Re: System policy prevents modification of network settings for all users

[Alkis Georgopoulos]

My problem is a bit different: everything works fine, but the dialog
appears when we ACTIVATE a VPN connection, even if we don't want to
modify it.

1) I've prepared a VPN connection for my non-admin users and put it in 
/etc/NetworkManager/system-connections/vpn.nmconnection.
2) When they click to activate it, they get the "System policy prevents..." 
dialog.
3a) If I do enter the root password there, the vpn.nmconnection file isn't 
modified. Why did it ask for permission then?
3b) If the users cancel the dialog (twice), they're able to properly connect to 
the VPN. Why did it show up then?

That's on fully updated Ubuntu 20.04.4.

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

Title:
  System policy prevents modification of network settings for all users

Status in NetworkManager:
  Invalid
Status in network-manager package in Ubuntu:
  Confirmed
Status in network-manager package in Debian:
  Fix Released
Status in network-manager package in openSUSE:
  Fix Released

Bug description:
  This seems like a regression? The screen shot is at
  http://thesii.org/Screenshot.jpg The nearest link I can find is from
  the forum area at http://ubuntuforums.org/showthread.php?p=1146

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
  ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
  Uname: Linux 3.2.0-20-generic x86_64
  ApportVersion: 1.95-0ubuntu1
  Architecture: amd64
  CRDA: Error: [Errno 2] No such file or directory
  Date: Sun Mar 25 19:36:45 2012
  IfupdownConfig:
   auto lo
   iface lo inet loopback
  InstallationMedia: Lubuntu 12.04 "Precise Pangolin" - Alpha amd64 (20120323)
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
   WimaxEnabled=true
  ProcEnviron:
   LANGUAGE=en_GB:en
   TERM=xterm
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: network-manager
  UpgradeStatus: No upgrade log present (probably fresh install)

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

[Alkis Georgopoulos]

The issue is still there in today's Ubuntu MATE 22.04 daily built.
Greeks cannot even type their names in the installer (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/1892014

Title:
  18.04.14.7 regression: no alt_shift_toggle in XKBOPTIONS

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

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 1772859] Re: Network Manager is not able to manage the devices on Ubuntu 18.04

[Alkis Georgopoulos]

While working on a remote server, it took me 2-3 hours to locate this
bug report and apply its workarounds. It's certainly not a good default
behavior.

In case someone has already removed netplan, the recommended steps to
get network-manager to manage the interfaces, as I understood them, are:

```
sudo -i
apt install ubuntu-minimal
echo "# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager" >/etc/netplan/01-network-manager-all.yaml
update-initramfs -u  # Not sure if this is needed or not
reboot
```

I.e. I think that /etc/netplan/01-network-manager-all.yaml comes from
some installer and it's not part of some package and it needs to be
manually re-created.

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

Title:
  Network Manager is not able to manage the devices on Ubuntu 18.04

Status in Ubuntu on IBM z Systems:
  Invalid
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  NetworkManager is not able to manage the devices on latest Ubuntu(18.04)
   
  ---uname output---
  Linux (none) 4.15.0-12-generic #13-Ubuntu SMP Wed Mar 7 21:36:36 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = z14 s390 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Install the latest Ubuntu(18.04) with Network Manager(1.10.4).
  2. Configure a network device and login to the partition through ssh.
  3. Now you can see the following output
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
   
  Userspace tool common name: 1.10.6-2ubuntu1: amd64 arm64 armhf i386 ppc64el 
s390x 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: NetworkManager --version 1.10.4

  Userspace tool obtained from project website:  na 
   

  Some more information about the issue:

  Network device has been configured manually after the image is up from 
Support Element(SE):
  - znetconf -a 
  - cat /sys/bus/ccwgroup/drivers/qeth//if_name
  - ifconfig   netmask 255.255.255.0
  - route add default gw  
  - SSH service has been configured
  
  This helped us to login to the Lpar. In Lpar
  - output of znetconf -c
  Device IDs TypeCard Type  CHPID Drv. Name 
State
  
-
  0.0.1a80,0.0.1a81,0.0.1a82 1731/01 OSD_10GIG A8 qeth eth0 
online
  0.0.1810,0.0.1811,0.0.1812 1731/01 OSD_1000  D0 qeth eth1 
online

  - output of nmcli c s
  root@(none):~# nmcli c s
  NAME  UUID  TYPE  DEVICE
  
  - output of nmcli d s
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
  
  * The above output shows that devices are not managed by nmcli
  
  After some investigation we found couple of suggestions like
  1. Ubuntu(version <17.04): Creating an empty 
file(/etc/NetworkManager/conf.d/10-globally-managed-devices.conf) and 
restarting NM,
 solved the issue.
 
  2. Ubuntu(version 17.10): Copying the said 
file(10-globally-managed-devices.conf) from /usr/lib to /etc/ and modifying the 
 "unmanaged-devices" to none, resolved the issue.

  * link for reference:
  https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1638842

  For the latest version(18.04), none of the above solutions worked.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1772859/+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 206924] Re: Make it possible to create a guest account

[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

[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)

[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

[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)

[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

[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)

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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 :

[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]

[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]

[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]

[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]

[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]

[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

[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

[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

[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)

[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

[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

[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

[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

[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

[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

[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"

[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

[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

[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

[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"

[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"

[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

[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"

[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"

[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

[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"

[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"

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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