[Touch-packages] [Bug 2055012] Re: When I upgraded from 22.04 to 24.04, DNS resolution went wrong.

[Fabien]

*** This bug is a duplicate of bug 2054761 ***
https://bugs.launchpad.net/bugs/2054761

I have the same issue on multiple hosts, including my laptop, with
intermittent DNS failures depending on the command used, after upgrading
to 24.04. The fix is rather unclear.

For a laptop which connects and reconnects to different networks, this is a 
pain.
For a server, this is also a pain. I understand that `cloud-init` recorded 

Notably, it seems (?!) the DNS configuration do not match DHCP settings,
so it is unclear from where cloud init got it.

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

Title:
  When I upgraded from 22.04 to 24.04, DNS resolution went wrong.

Status in network-manager package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  Confirmed

Bug description:
  I was an unpatient idiot, and I upgraded from 22.04 to 24.04. Near to
  the end of the upgrade, I got an „Oh, no! Something has gone wrong and
  the system cannot recover. Call the system administrator” message
  after a red FAILED in the terminal. The system administrator is
  myself, because my computer is a personal one. Hard reset, same error,
  Ctrl+Alt+F3, sudo apt reinstall gdm3. Obviously. I needed to finish
  the update with dpkg. While dpkg was upgrading, it printed an error
  message for every WiFi connection:

  „[Failed] Failed to migrate [I do not remember, something with
  /etc/netplan]”

  It took at least one and a half hour to find the solution on Ask
  Ubuntu. The problem was: /etc/resolv.conf became a broken link, along
  with systemd-resolve.service. I needed to remove both of them and
  write a new resolv.conf to fix the error.

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: network-manager 1.45.90-1ubuntu1
  ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
  Uname: Linux 6.6.0-14-generic x86_64
  ApportVersion: 2.28.0-0ubuntu1
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 08:21:02 2024
  InstallationDate: Installed on 2023-07-05 (236 days ago)
  InstallationMedia: Ubuntu 20.04.6 LTS "Focal Fossa" - Release amd64 (20230316)
  IpRoute:
   default via 192.168.0.1 dev wlp3s0 proto dhcp src 192.168.0.100 metric 600
   192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.100 metric 
600
   192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 
linkdown
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  RfKill:
   0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to noble on 2024-02-24 (2 days ago)
  modified.conffile..etc.init.d.apport: [modified]
  mtime.conffile..etc.init.d.apport: 2024-02-22T15:20:00
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.45.90  connected  started  full  enabled enabled  
enabled  missing  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2055012/+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 1999881] [NEW] unmkinitramfs fails with symlinked zstd compressed initrds

[Fabien Malfoy]

Public bug reported:

[Impact]

 * Cannot unpack zstd compressed initrds when accessed through a
symbolic link

[Test Case]

$ grep COMPRESS= /etc/initramfs-tools/initramfs.conf
COMPRESS=zstd
# This is the default

$ stat -c '%F %N' /boot/initrd.img*
symbolic link '/boot/initrd.img' -> 'initrd.img-5.15.0-53-generic'
regular file '/boot/initrd.img-5.15.0-53-generic'

$ lsinitramfs /boot/initrd.img-5.15.0-53-generic
... works as expected ...

$ lsinitramfs /boot/initrd.img
cpio: premature end of archive

[Regression Potential]

 * Ubuntu Jammy changes the default compression scheme for the initrd
from lz4 to zstd. Unpacking lz4 initrds had already been fixed by
https://bugs.launchpad.net/ubuntu/cosmic/+source/initramfs-
tools/+bug/1832108 but unpacking zstd initrds works as expected when
directly accessing the file. However, it fails when accessing it through
a symbolic link.

[Other Info]

A fix proposal is attached.

$ lsb_release -rd
Description:Ubuntu 22.04.1 LTS
Release:22.04
$ dpkg-query -W initramfs-tools
initramfs-tools 0.140ubuntu13

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

** Patch added: "Proposed fix"
   
https://bugs.launchpad.net/bugs/1999881/+attachment/5635890/+files/proposed_fix.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/1999881

Title:
  unmkinitramfs fails with symlinked zstd compressed initrds

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  [Impact]

   * Cannot unpack zstd compressed initrds when accessed through a
  symbolic link

  [Test Case]

  $ grep COMPRESS= /etc/initramfs-tools/initramfs.conf
  COMPRESS=zstd
  # This is the default

  $ stat -c '%F %N' /boot/initrd.img*
  symbolic link '/boot/initrd.img' -> 'initrd.img-5.15.0-53-generic'
  regular file '/boot/initrd.img-5.15.0-53-generic'

  $ lsinitramfs /boot/initrd.img-5.15.0-53-generic
  ... works as expected ...

  $ lsinitramfs /boot/initrd.img
  cpio: premature end of archive

  [Regression Potential]

   * Ubuntu Jammy changes the default compression scheme for the initrd
  from lz4 to zstd. Unpacking lz4 initrds had already been fixed by
  https://bugs.launchpad.net/ubuntu/cosmic/+source/initramfs-
  tools/+bug/1832108 but unpacking zstd initrds works as expected when
  directly accessing the file. However, it fails when accessing it
  through a symbolic link.

  [Other Info]

  A fix proposal is attached.

  $ lsb_release -rd
  Description:  Ubuntu 22.04.1 LTS
  Release:  22.04
  $ dpkg-query -W initramfs-tools
  initramfs-tools   0.140ubuntu13

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1999881/+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 1882034] Re: cannot start X session with NIS account

[Fabien]

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

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

Title:
  cannot start X session with NIS account

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  When login with a NIS account, X does not start, or more precisely it
  starts and exits immediately.

  Only errors in logs is:
   (EE) systemd-logind: failed to get session: PID 4335 does not belong to any 
known session

  X11/gdm login works fine with local accounts.

  SSH/terminal console login with NIS accounts works fine.

  /etc/X11/Xwrapper.config:
allowed_users=anybody

  I've seen several reports of such problems under other versions (eg
  19.10), but no working solutions was found. It seems that the problem
  is the same with lightdm.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gdm3 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30
  Uname: Linux 5.4.0-29-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.2
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun  4 08:59:25 2020
  InstallationDate: Installed on 2019-11-26 (190 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to focal on 2020-04-24 (40 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1882034/+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 1882034] Re: cannot start X session with NIS account

[Fabien]

> Do you seem to observe https://github.com/systemd/systemd/issues/2941
?

The message is the same, but I cannot see a "hidepid" mount option
anywhere.

As a standard user I can see all /proc/ directories, and read
the /proc//cgroup file of other users, including root.

So I'd say that it is not exactly the same issue.

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

Title:
  cannot start X session with NIS account

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  When login with a NIS account, X does not start, or more precisely it
  starts and exits immediately.

  Only errors in logs is:
   (EE) systemd-logind: failed to get session: PID 4335 does not belong to any 
known session

  X11/gdm login works fine with local accounts.

  SSH/terminal console login with NIS accounts works fine.

  /etc/X11/Xwrapper.config:
allowed_users=anybody

  I've seen several reports of such problems under other versions (eg
  19.10), but no working solutions was found. It seems that the problem
  is the same with lightdm.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gdm3 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30
  Uname: Linux 5.4.0-29-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.2
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun  4 08:59:25 2020
  InstallationDate: Installed on 2019-11-26 (190 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to focal on 2020-04-24 (40 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1882034/+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 1853203] Re: 30 seconds boot delay when usr fs is on lvm

[Fabien SK]

I upgraded to Kubuntu 19.10 and the delay disappeared.

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

Title:
  30 seconds boot delay when usr fs is on lvm

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  A bit similar to "30 seconds boot delay when root fs is on lvm": 
  https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1807499

  I installed Kubuntu 19.04 with 2 LVM volume groups (one per disk). My root 
and my /usr are both located on the same LVM. Mounting /usr takes 30s, but if I 
move the /usr to a non-LVM partition then the mounting takes no time and the 
whole boot process is very fast.
  In the script "scripts/local" of initramfs-tools, there is a 30s timeout 
called "slumber" passed to the "wait-for-root" program (from 
initramfs-tools-bin), and the wait comes from there (I could see it by adding 
traces before and after). If I decrease the timeout to 10s, the system can 
still boot correctly (and 20s faster).

  I don't know if the problem comes from the initramfs-tools scripts,
  from wait-for-root or from the integration in (K)Ubuntu.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: initramfs-tools-core 0.131ubuntu19.2 [modified: 
usr/share/initramfs-tools/scripts/local]
  ProcVersionSignature: Ubuntu 5.0.0-36.39-generic 5.0.21
  Uname: Linux 5.0.0-36-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.3
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Tue Nov 19 22:11:18 2019
  InstallationDate: Installed on 2017-08-26 (815 days ago)
  InstallationMedia: Kubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: Upgraded to disco on 2019-08-18 (93 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1853203/+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 1853203] [NEW] 30 seconds boot delay when usr fs is on lvm

[Fabien SK]

Public bug reported:

A bit similar to "30 seconds boot delay when root fs is on lvm": 
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1807499

I installed Kubuntu 19.04 with 2 LVM volume groups (one per disk). My root and 
my /usr are both located on the same LVM. Mounting /usr takes 30s, but if I 
move the /usr to a non-LVM partition then the mounting takes no time and the 
whole boot process is very fast.
In the script "scripts/local" of initramfs-tools, there is a 30s timeout called 
"slumber" passed to the "wait-for-root" program (from initramfs-tools-bin), and 
the wait comes from there (I could see it by adding traces before and after). 
If I decrease the timeout to 10s, the system can still boot correctly (and 20s 
faster).

I don't know if the problem comes from the initramfs-tools scripts, from
wait-for-root or from the integration in (K)Ubuntu.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: initramfs-tools-core 0.131ubuntu19.2 [modified: 
usr/share/initramfs-tools/scripts/local]
ProcVersionSignature: Ubuntu 5.0.0-36.39-generic 5.0.21
Uname: Linux 5.0.0-36-generic x86_64
ApportVersion: 2.20.10-0ubuntu27.3
Architecture: amd64
CurrentDesktop: KDE
Date: Tue Nov 19 22:11:18 2019
InstallationDate: Installed on 2017-08-26 (815 days ago)
InstallationMedia: Kubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
PackageArchitecture: all
SourcePackage: initramfs-tools
UpgradeStatus: Upgraded to disco on 2019-08-18 (93 days ago)

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


** Tags: amd64 apport-bug disco

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

Title:
  30 seconds boot delay when usr fs is on lvm

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  A bit similar to "30 seconds boot delay when root fs is on lvm": 
  https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1807499

  I installed Kubuntu 19.04 with 2 LVM volume groups (one per disk). My root 
and my /usr are both located on the same LVM. Mounting /usr takes 30s, but if I 
move the /usr to a non-LVM partition then the mounting takes no time and the 
whole boot process is very fast.
  In the script "scripts/local" of initramfs-tools, there is a 30s timeout 
called "slumber" passed to the "wait-for-root" program (from 
initramfs-tools-bin), and the wait comes from there (I could see it by adding 
traces before and after). If I decrease the timeout to 10s, the system can 
still boot correctly (and 20s faster).

  I don't know if the problem comes from the initramfs-tools scripts,
  from wait-for-root or from the integration in (K)Ubuntu.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: initramfs-tools-core 0.131ubuntu19.2 [modified: 
usr/share/initramfs-tools/scripts/local]
  ProcVersionSignature: Ubuntu 5.0.0-36.39-generic 5.0.21
  Uname: Linux 5.0.0-36-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.3
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Tue Nov 19 22:11:18 2019
  InstallationDate: Installed on 2017-08-26 (815 days ago)
  InstallationMedia: Kubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: Upgraded to disco on 2019-08-18 (93 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1853203/+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 1781652] Re: should be possible to specify static routes on a dhcp-configured interface

[Fabien Toral]

I've the same problem.

I'm operating 17.10 systems with network initially configured with DHCP.
We need to add pemanent static routes and networkd failed with the same
error than reported here.

I think I've found the upstream bug in systemd :
https://github.com/systemd/systemd/issues/1850


** Bug watch added: github.com/systemd/systemd/issues #1850
   https://github.com/systemd/systemd/issues/1850

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

Title:
  should be possible to specify static routes on a dhcp-configured
  interface

Status in netplan:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  From , a user wants to add a static route to a
  network interface where the gateway is known, but the interface's
  local address is configured via dhcp.

  This doesn't work with direct netplan yaml, because networkd will try
  to apply the static routes before the interface has been configured
  via dhcp, failing because there is not yet a route to the gateway on
  that interface.

  Demonstrating in a lxd container locally, which has 10.44.49.0/24 as
  its network:

  $ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  eth0:
  dhcp4: true
  routes:
 - to: 10.44.48.0/24
   via: 10.44.49.2
   metric: 10
  $  systemctl status systemd-networkd --no-pager -l
  ● systemd-networkd.service - Network Service
 Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; 
vendor preset: enabled)
 Active: active (running) since Fri 2018-07-13 19:21:29 UTC; 8min ago
   Docs: man:systemd-networkd.service(8)
   Main PID: 165 (systemd-network)
 Status: "Processing requests..."
  Tasks: 1 (limit: 4915)
 CGroup: /system.slice/systemd-networkd.service
 └─165 /lib/systemd/systemd-networkd

  Jul 13 19:21:29 stable-dane systemd[1]: Starting Network Service...
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: Enumeration completed
  Jul 13 19:21:29 stable-dane systemd[1]: Started Network Service.
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Could not set route: 
Network is unreachable
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: DHCPv4 address 
10.44.49.32/24 via 10.44.49.1
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: Not connected to system 
bus, not setting hostname.
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Gained IPv6LL
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Configured
  Jul 13 19:21:55 stable-dane systemd-networkd[165]: Could not set hostname: 
Method call timed out
  $ ip route 
  default via 10.44.49.1 dev eth0 proto dhcp src 10.44.49.32 metric 100 
  10.44.49.0/24 dev eth0 proto kernel scope link src 10.44.49.32 
  10.44.49.1 dev eth0 proto dhcp scope link src 10.44.49.32 metric 100 
  $

  netplan and networkd should DTRT.

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

[Fabien-toral]

So, after few tries in Virtual Machines to test different Debian/gtk
versions, and other researches on the net, I found a workaround to make
Luna work on my Debian laptop :

export SWT_GTK3=0

That aims to fallback to the GTK2 SWT implementation and bring my
Eclipse back!

I was not on the right bug report, and found my way with a comment on
bug #430736 https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736#c26

With that, it comes to me that the only solution, as i don't want to
upgrade my glibc, is to fallback to GTK2...

And thanks to
http://www.eclipse.org/swt/R4_4/new_and_noteworthy.html#m3, the
information was there...

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

Title:
  Java crash in libglib-2.0 after upgrade from 13.04 to 13.10

Status in Eclipse:
  Confirmed
Status in “gtk+2.0” package in Ubuntu:
  Triaged
Status in “unity” package in Ubuntu:
  Invalid
Status in “gtk+2.0” package in Suse:
  New

Bug description:
  Running smartgit 4.6.4 on 13.10 64 bits. After registering the
  product, smartgit crash when trying to open a new repository. Java
  error log :

  # A fatal error has been detected by the Java Runtime Environment:
  #
  #  SIGSEGV (0xb) at pc=0x7fa59061f9c0, pid=12494, tid=140349308167936
  #
  # JRE version: 7.0_25-b30
  # Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 
compressed oops)
  # Problematic frame:
  # C  [libglib-2.0.so.0+0x389c0]  g_str_hash+0x0

  I tried different version of Java (Oracle v7 and v6 jre) with same
  result. Also, Eclipse display blank menus so there's a general java
  problem with displays.

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