[Touch-packages] [Bug 1784116] Re: ubuntu-bug reports the package from other arch as not installed

2023-02-23 Thread Benjamin Drung
** Changed in: apport
Milestone: 2.26.0 => 2.27.0

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

Title:
  ubuntu-bug reports the package from other arch as not installed

Status in Apport:
  Triaged
Status in apport package in Ubuntu:
  Triaged

Bug description:
  Ubuntu 18.04.1 Minimal (+++)

  ubuntu-bug steam returns package not installed:

  -steam/bionic,now 1:1.0.0.54+repack-5ubuntu1 i386 [installed]
  -se attachment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1784116/+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 1947920] Re: tracker-miner-f 100% CPU and slows system down

2023-02-23 Thread ExploreWiki
My problem was with the CPU being throttled to 500Mhz if I turned the
power supply on at the wrong time during boot up. Nothing to do with
tracker-miner-f.

Please delete my bug report!

** This bug is no longer a duplicate of bug 1961540
   tracker-miner-fs-3 massive CPU usage and system slowdown

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

** Description changed:

- tracker-miner-f has been using 100% CPU and my system making it almost
- unresponsive. This happens around once a month or so when I boot up. It
- sometimes lasts for a number of days (or a number of resets) until the
- system becomes responsive again.
- 
- The command "tracker status" always shows the same thing: "Estimated
- less than one second left" although it appears that everything is
- already indexed because the file and folder counts do not increase.
- 
- Even so tracker-miner-f is still showing 100% CPU
- 
- 
- 
- inspiron@Inspiron-7348:~$ tracker status
- Currently indexed: 101154 files, 16046 folders
- Remaining space on database partition: 160.5 GB (64.11%)
- Data is still being indexed: Estimated less than one second left
- 
- 
- 
- inspiron@Inspiron-7348:~$ tracker status
- Currently indexed: 101155 files, 16045 folders
- Remaining space on database partition: 161.1 GB (64.31%)
- Data is still being indexed: Estimated 01h 19m 03s left
- 
- ProblemType: Bug
- DistroRelease: Ubuntu 20.04
- Package: tracker 2.3.6-0ubuntu1
- ProcVersionSignature: Ubuntu 5.11.0-37.41~20.04.2-generic 5.11.22
- Uname: Linux 5.11.0-37-generic x86_64
- ApportVersion: 2.20.11-0ubuntu27.20
- Architecture: amd64
- CasperMD5CheckResult: skip
- CurrentDesktop: ubuntu:GNOME
- Date: Thu Oct 21 08:25:58 2021
- InstallationDate: Installed on 2021-06-28 (114 days ago)
- InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
- SourcePackage: tracker
- UpgradeStatus: No upgrade log present (probably fresh install)
- 
- 
- 
- UPDATE
- 
- I have now reset the tracker and it seems to be going through and
- indexing everything again.
- 
- tracker reset --hard
- 
- Now tracker-miner-f has re-indexed everything and tracker-extract and
- tracker-store are running.
- 
- 
- 
- UPDATE 2
- 
- The tracker reset completed indexing everything and the went into idle
- state. However when rebooting, tracker-miner-f went to 100% CPU once
- again.
+ Invalid.

** Information type changed from Public to Private

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

Title:
  tracker-miner-f 100% CPU and slows system down

Status in tracker package in Ubuntu:
  Invalid

Bug description:
  Invalid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1947920/+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 1525628] Re: tracker needs to be killed on every boot

2023-02-23 Thread ExploreWiki
I originally thought I had this problem but it turns out it was nothing
to do with tracker.

My problem was with the CPU being throttled to 500Mhz if I turned the
power supply on at the wrong time during boot up.

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

Title:
  tracker needs to be killed on every boot

Status in tracker package in Ubuntu:
  Confirmed

Bug description:
  At every boot, tacker-miner-fs and tracker-extract uses all of the
  processor and needs to be killed manually for computer to work.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: tracker 1.6.1-1ubuntu1
  ProcVersionSignature: Ubuntu 4.3.0-2.11-generic 4.3.0
  Uname: Linux 4.3.0-2-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sun Dec 13 13:02:58 2015
  InstallationDate: Installed on 2015-04-24 (232 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
  SourcePackage: tracker
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1525628/+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 2008393] [NEW] armhf dep8 failure due to restrictions changing apparmor profile status

2023-02-23 Thread Andreas Hasenack
Public bug reported:

The armhf DEP8 testers in Ubuntu infrastructure have some restrictions
and cannot change an apparmor profile. This is causing the tests to
fail, because they try to make sure rsyslog is being tested in enforced
mode:

Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile
Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode.

ERROR: /sbin/apparmor_parser: Unable to replace "rsyslogd".  Permission
denied; attempted to load a profile while confined?

The package migrated to lunar even with this error because it never had
DEP8 tests before, and the armhf baseline was born in this error state.

** Affects: rsyslog (Ubuntu)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Description changed:

  The armhf DEP8 testers in Ubuntu infrastructure have some restrictions
  and cannot change an apparmor profile. This is causing the tests to
  fail, because they try to make sure rsyslog is being tested in enforced
  mode:
  
  Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile
  Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode.
  
  ERROR: /sbin/apparmor_parser: Unable to replace "rsyslogd".  Permission
  denied; attempted to load a profile while confined?
+ 
+ The package migrated to lunar even with this error because it never had
+ DEP8 tests before, and the armhf baseline was born in this error state.

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

Title:
  armhf dep8 failure due to restrictions changing apparmor profile
  status

Status in rsyslog package in Ubuntu:
  In Progress

Bug description:
  The armhf DEP8 testers in Ubuntu infrastructure have some restrictions
  and cannot change an apparmor profile. This is causing the tests to
  fail, because they try to make sure rsyslog is being tested in
  enforced mode:

  Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile
  Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode.

  ERROR: /sbin/apparmor_parser: Unable to replace "rsyslogd".
  Permission denied; attempted to load a profile while confined?

  The package migrated to lunar even with this error because it never
  had DEP8 tests before, and the armhf baseline was born in this error
  state.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2008393/+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 1991606] Re: Invalid PEP440 package version breaking setuptools >= 66

2023-02-23 Thread Henry Ward Hopeman Jr.
Also a duplicate https://bugs.launchpad.net/ubuntu/+source/distro-
info/+bug/2008121

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

Title:
  Invalid PEP440 package version breaking setuptools >= 66

Status in devscripts package in Ubuntu:
  New
Status in distro-info package in Ubuntu:
  Fix Released
Status in drslib package in Ubuntu:
  New
Status in duecredit package in Ubuntu:
  Fix Released
Status in python-debian package in Ubuntu:
  Fix Released
Status in reportbug package in Ubuntu:
  Fix Released
Status in ubuntu-dev-tools package in Ubuntu:
  Fix Released
Status in update-manager package in Ubuntu:
  Fix Released
Status in devscripts source package in Bionic:
  New
Status in distro-info source package in Bionic:
  New
Status in drslib source package in Bionic:
  Invalid
Status in duecredit source package in Bionic:
  New
Status in python-debian source package in Bionic:
  Invalid
Status in reportbug source package in Bionic:
  New
Status in ubuntu-dev-tools source package in Bionic:
  New
Status in update-manager source package in Bionic:
  New
Status in devscripts source package in Focal:
  New
Status in distro-info source package in Focal:
  New
Status in drslib source package in Focal:
  New
Status in duecredit source package in Focal:
  New
Status in python-debian source package in Focal:
  New
Status in reportbug source package in Focal:
  New
Status in ubuntu-dev-tools source package in Focal:
  New
Status in update-manager source package in Focal:
  New
Status in devscripts source package in Jammy:
  New
Status in distro-info source package in Jammy:
  New
Status in drslib source package in Jammy:
  New
Status in duecredit source package in Jammy:
  New
Status in python-debian source package in Jammy:
  New
Status in reportbug source package in Jammy:
  New
Status in ubuntu-dev-tools source package in Jammy:
  Invalid
Status in update-manager source package in Jammy:
  New
Status in devscripts source package in Kinetic:
  New
Status in distro-info source package in Kinetic:
  New
Status in drslib source package in Kinetic:
  New
Status in duecredit source package in Kinetic:
  New
Status in python-debian source package in Kinetic:
  Invalid
Status in reportbug source package in Kinetic:
  New
Status in ubuntu-dev-tools source package in Kinetic:
  Invalid
Status in update-manager source package in Kinetic:
  New

Bug description:
  With setuptools 66, the versions of all packages visible in the Python
  environment *must* obey PEP440 .
  Otherwise, attempts to use pip to install a package with a setup.py-
  based build system, or other attempts to use the `pkg-resources`
  module, can produce errors like this:

    File 
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
 line 844, in _resolve_dist
  env = Environment(self.entries)
    File 
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
 line 1044, in __init__
  self.scan(search_path)
    File 
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
 line 1077, in scan
  self.add(dist)
    File 
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
 line 1096, in add
  dists.sort(key=operator.attrgetter('hashcmp'), reverse=True)
    File 
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
 line 2631, in hashcmp
  self.parsed_version,
    File 
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
 line 2678, in parsed_version
  self._parsed_version = parse_version(self.version)
    File 
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py",
 line 266, in __init__
  raise InvalidVersion(f"Invalid version: '{version}'")
  pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: 
'0.23ubuntu1'

  The official opinion of the setuptools maintainers seems to be that
  version strings of this form haven't *really* been allowed since about
  2014, and distributions need to change their package version naming
  scheme for Python packages they install, so that the resulting version
  strings obey PEP440. See for example
  .

  suffix 1build1 is invalid.

  Some python building tools, that verifies if version strings are
  compatible with PEP440, are failing.

  Example: python poetry: Invalid PEP 440 version: '1.1build1'

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


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

[Touch-packages] [Bug 2007837] Re: 22.04: Backport request from 3.2.4 for fix of 3.2.3 regression

2023-02-23 Thread Paride Legovini
Thanks. According to the package versions the bug is not present in >=
Kinetic, so setting the devel release task as Fix Released.

** Changed in: rsync (Ubuntu)
   Status: New => Fix Released

** Changed in: rsync (Ubuntu Jammy)
   Status: Incomplete => Triaged

** Tags added: server-todo

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

Title:
  22.04: Backport request from 3.2.4 for fix of 3.2.3 regression

Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Jammy:
  Triaged
Status in rsync package in Debian:
  Unknown

Bug description:
  rsync 3.2.3 (packaged in Ubuntu 22.04) changes stderr handling,
  leading another bug in libfile-rsyncp-perl (in Ubuntu 18.04 and 20.04)
  to surface [1].

  It practically makes using BackupPC 3 impossible with clients using
  rsync 3.2.3, as is packaged for 22.04. The fact that BackupPC on 20.04
  can't be used to back up machines with 22.04 is rather surprising and
  has bitten other users [2].

  It's unclear whether the bug will be fixed in 18.04's and 20.04's
  libfile-rsyncp-perl package (for status, see [3]).

  Because of this, the rsync maintainer has included a patch in 3.2.4
  that fixes this regression [4] (even though not strictly an rsync
  bug). As a result, rsync 3.2.3 is the only affected version, which
  happens to be the one packaged in 22.04.

  This report is to request backporting that fix [4] to Ubuntu 22.04, so
  that things don't silently break in scenarios where the backup server
  is left at 20.04, and some backup clients happen to upgrade to 22.04.

  I'm not sure what the criteria for security releases are, but as the
  issue causes backup denial of service and has easy mitigation, I think
  it would make sense to put it through the security channel.

  [1]: https://github.com/WayneD/rsync/issues/95#issuecomment-699185358
  [2]: 
https://www.mail-archive.com/backuppc-users@lists.sourceforge.net/msg32673.html
  [3]: 
https://bugs.launchpad.net/ubuntu/+source/libfile-rsyncp-perl/+bug/2007833
  [4]: 
https://github.com/WayneD/rsync/commit/4adfdaaf12db26c348b4d6150119b377f9b622c8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2007837/+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 2007124] Re: Move available config files from /etc to /usr

2023-02-23 Thread Gunnar Hjalmarsson
This was uploaded to lunar after a brief IRC conversation:

https://irclogs.ubuntu.com/2023/02/23/%23ubuntu-desktop.html#t14:18

** Changed in: fontconfig (Ubuntu)
   Status: New => Fix Committed

** Changed in: fontconfig (Ubuntu)
 Assignee: (unassigned) => Gunnar Hjalmarsson (gunnarhj)

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

Title:
  Move available config files from /etc to /usr

Status in fontconfig package in Ubuntu:
  Fix Committed

Bug description:
  At the upgrade to fontconfig 2.10 a decade ago, the directory for
  storing available config files was changed from /etc/fonts/conf.avail
  to /usr/share/fontconfig/conf.avail. It was done upstream as well as
  in Debian, but Ubuntu delayed the transition for some reason. I think
  we should do that transition in Ubuntu too. That will get Ubuntu in
  sync with the upstream documentation and the delta to Debian gets
  reduced a little.

  The changes needed are straightforward. I put a proposed upload in
  this PPA:

  https://launchpad.net/~gunnarhj/+archive/ubuntu/fontconfig

  and I would appreciate someone's eyes on it.

  So, what's the caveat? The only thing I can think of is that distros,
  system admins and individual users may have tweaked the font
  configuration by including symlinks which point to the moved files.
  While I don't have the impression that such symlinks are very frequent
  — custom conf files put directly in /etc/fonts/conf.d or equivalent
  places in $HOME seem to be more common — to the extent they exist,
  they will be silently disabled.

  Bug #2005124 revealed an example of a symlink which pointed to a file
  which will be moved if we do this. OTOH, in that case upstream added a
  symlink with the very same name, so we had to deal with that conflict.
  If the name of Kubuntu's link had been something else, we might not be
  aware of it yet.

  The changelog for this upload:

  https://launchpad.net/ubuntu/+source/fontconfig/2.10.1-0ubuntu1

  states that the transition will be done "later with another upload
  once the details are sorted". Are there other details which I have
  missed? If not, I suppose that the potential inconvenience is
  approximately as big today as it was 2012. And since next LTS release
  is more than one year ahead, this ought to be an appropriate time to
  make the change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/2007124/+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 1933090] Re: systemd/245.4-4ubuntu3.6 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1

2023-02-23 Thread Launchpad Bug Tracker
** Merge proposal linked:
   
https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/437809

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

Title:
  systemd/245.4-4ubuntu3.6 ADT test failure with linux-
  hwe-5.11/5.11.0-20.21~20.04.1

Status in linux-hwe-5.11 package in Ubuntu:
  Won't Fix
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in linux-hwe-5.11 source package in Focal:
  Won't Fix
Status in linux-hwe-5.15 source package in Focal:
  Invalid
Status in systemd source package in Focal:
  Triaged

Bug description:
  [SRU Impact]

  Sysctl was removed from 5.5 kernels. In src/test/test-seccomp.c, 
test_protect_syscall
  sysctl is called with the expectation the error result is EFAULT and not 
ENOSYS.
  This affects autotests for all focal-5.15 linux kernels (hwe, azure, gcp, 
oem, gke, oracle).

  [Fix]
  Assertion checks if either EFAULT or ENOSYS is returned. This way it will 
work for focal-5.4 kernels and focal-5.15 kernels.

  [Test to reproduce the issue]
  1. Create a vm and install one of the focal-5.15 kernels (i.e 
5.15.0-1029.35~20.04.1 linux-oracle-5.15).
  2. Run the autotests for upstream and/or root-unittests:
  autopkgtest --test-name=upstream systemd -- qemu 

  [Test to verify the fix]
  1. Same as above
  2. Apply the fix in your local repo and run the tests using your local repo
  autopkgtest --test-name=upstream  -- qemu 

  [Where problems could occur]
  This is not gonna affect end users since it is a change in the test only.
  It may impact autotests, but it's a very low probability.

  [Original Description]

  This is a scripted bug report about ADT failures while running systemd
  tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this
  is caused by the dep8 tests of the tested source or the kernel has yet
  to be determined.

  Testing failed on:
  amd64: 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/s/systemd/20210611_220645_bf5b6@/log.gz
  armhf: 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/armhf/s/systemd/20210617_124738_5b554@/log.gz
  ppc64el: 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/s/systemd/20210611_235629_92856@/log.gz
  s390x: 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/s/systemd/20210611_214456_6427f@/log.gz

  In arm64, ppc64el and s390x, 'root-unittests' fails with:

  /* test_protect_sysctl */
  Assertion 'errno == EFAULT' failed at src/test/test-seccomp.c:311, function 
test_protect_sysctl(). A
  borting.
  sysctlseccomp terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("sysctlseccomp", pid, WAIT_LOG) == 
EXIT_SUCCESS' failed at s
  rc/test/test-seccomp.c:324, function test_protect_sysctl(). Aborting.
  FAIL: test-seccomp (code: 134)

  In amd64, 'upstream' also fails on 'TEST-24-UNIT-TESTS', which
  apparently is caused by the same 'test-seccomp.c:311' assertion
  failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe-5.11/+bug/1933090/+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 2002445] Re: udev NIC renaming race with mlx5_core driver

2023-02-23 Thread Launchpad Bug Tracker
** Merge proposal linked:
   
https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/437809

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

Title:
  udev NIC renaming race with mlx5_core driver

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Focal:
  Triaged
Status in systemd source package in Jammy:
  Triaged
Status in systemd source package in Kinetic:
  New
Status in systemd source package in Lunar:
  New

Bug description:
  [Impact]
  On systems with mellanox NICs, udev's NIC renaming races with the mlx5_core 
driver's own configuration of subordinate interfaces. When the kernel wins this 
race, the device cannot be renamed as udev has attempted, and this causes 
systemd-network-online.target to timeout waiting for links to be configured. 
This ultimately results in boot being delayed by about 2 minutes.

  [Test Plan]
  Since this is a race condition, we need to boot many instances before we see 
the issue. The Ubuntu Server team will help coordinate the testing at scale to 
confirm the fix.

  [Where problems could occur]
  The patches effectively make it so that if a interface cannot be renamed from 
udev, then the new name is left as an alternative name as a fallback. If 
problems occur, it would be related to device renaming, and particularly 
related to the devices alternative names.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2002445/+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 2003851] Re: occasional hanging 'apt-get update' from daily cronjob since Jammy 22.04

2023-02-23 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: apt (Ubuntu)
   Status: New => Confirmed

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

Title:
  occasional hanging 'apt-get update' from daily cronjob since Jammy
  22.04

Status in apt package in Ubuntu:
  Confirmed

Bug description:
  Hi!

  Yesterday I spotted several machines of ours where a period `apt-get
  update` was stalled. The `http` children were hanging in `WaitFd`
  (waiting for parent instructions/queue). The parent was looping in
  `AcquireUpdate` every 500ms.

  
  We have a cronjob that runs every few hours which calls `apt-get update` and 
does some post-processing. We noticed that several of them had stalled at some 
point in time. Killing the parent (apt-get) got it unstuck, removing the locks.

  Example:
  ```
  # apt-get update
  Reading package lists... Done
  E: Could not get lock /var/lib/apt/lists/lock. It is held by process 154026 
(apt-get)
  N: Be aware that removing the lock file is not a solution and may break your 
system.
  E: Unable to lock directory /var/lib/apt/lists/
  ```

  Task listing:
  ```
  root  153929  \_ /usr/sbin/CRON -f -P
  root  153942  \_ /bin/sh -c  [ -x /etc/zabbix/scripts/dpkg.updates ] 
&& /etc/zabbix/scripts/dpkg.updates --cron
  root  153943  \_ /bin/sh /etc/zabbix/scripts/dpkg.updates --cron
  root  154026  \_ apt-get update
  _apt  154029  \_ /usr/lib/apt/methods/http
  _apt  154030  \_ /usr/lib/apt/methods/http
  _apt  154031  \_ /usr/lib/apt/methods/http
  _apt  154033  \_ /usr/lib/apt/methods/gpgv
  ```
  Open (TCP) sockets. All have 1 item in the Recv-Q (probably a FIN or RST?):
  ```
  # netstat -apn | grep -E '154026|154029|154030|154031|154033'
  tcp  1  0  10.x.x.x:60868  217.x.x.x:80  CLOSE_WAIT  154030/http 
  tcp  1  0  10.x.x.x:40756  178.x.x.x:80  CLOSE_WAIT  154029/http 
  tcp  1  0  10.x.x.x:56818  185.x.x.x:80  CLOSE_WAIT  154031/http 
  ```
  All children (including gpgv) were waiting using pselect6(1, [0], NULL, NULL, 
NULL, NULL).

  The parent (apt-get) was waiting using pselect6(10, [5 6 7 9], [],
  NULL, {tv_sec=0, tv_nsec=5}, NULL).

  The http sockets in the children were at fd=3.

  Parent lsof:
  ```
  # lsof -p 154026 +E
  ...
  apt-get   154026 root4uW  REG8,10  262281 
/var/lib/apt/lists/lock
  apt-get   154026 root5r  FIFO   0,13  0t0 4015176 pipe 154029,http,1w
  apt-get   154026 root6r  FIFO   0,13  0t0 4012448 pipe 154030,http,1w
  apt-get   154026 root7r  FIFO   0,13  0t0 4015192 pipe 154031,http,1w
  apt-get   154026 root8w  FIFO   0,13  0t0 4015177 pipe 154029,http,0r
  apt-get   154026 root9r  FIFO   0,13  0t0 4015233 pipe 154033,gpgv,1w
  apt-get   154026 root   10w  FIFO   0,13  0t0 4012449 pipe 154030,http,0r
  apt-get   154026 root   12w  FIFO   0,13  0t0 4015193 pipe 154031,http,0r
  apt-get   154026 root   14w  FIFO   0,13  0t0 4015234 pipe 154033,gpgv,0r
  http  154029 _apt0r  FIFO   0,13  0t0 4015177 pipe 
154026,apt-get,8w
  http  154029 _apt1w  FIFO   0,13  0t0 4015176 pipe 
154026,apt-get,5r
  http  154030 _apt0r  FIFO   0,13  0t0 4012449 pipe 
154026,apt-get,10w
  http  154030 _apt1w  FIFO   0,13  0t0 4012448 pipe 
154026,apt-get,6r
  http  154031 _apt0r  FIFO   0,13  0t0 4015193 pipe 
154026,apt-get,12w
  http  154031 _apt1w  FIFO   0,13  0t0 4015192 pipe 
154026,apt-get,7r
  gpgv  154033 _apt0r  FIFO   0,13  0t0 4015234 pipe 
154026,apt-get,14w
  gpgv  154033 _apt1w  FIFO   0,13  0t0 4015233 pipe 
154026,apt-get,9r
  ```
  So:
  - apt-get is waiting for any data written by any of its four children (at fd 
5/6/7/9)
  - http and gpgv are waiting for any data written by their parent (at their 
respective fd 0)

  Parent backtrace:
  ```
  #0  0x7f420116a74d in select ()
 from /lib/x86_64-linux-gnu/libc.so.6
  #1  0x7f420153fb5d in pkgAcquire::Run(int) ()
 from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
  #2  0x7f420161d535 in AcquireUpdate(pkgAcquire&, int, bool, bool) ()
 from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
  #3  0x7f420161d986 in ListUpdate(pkgAcquireStatus&, pkgSourceList&, int) 
()
 from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
  #4  0x7f42016d127b in DoUpdate (CmdL=...)
  at ./apt-private/private-update.cc:73
  #5  0x7f420156d73f in CommandLine::DispatchArg(CommandLine::Dispatch 
const*, bool) ()
 from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
  #6  0x7f420169fa97 in DispatchCommandLine (CmdL=..., 
  Cmds=std::vector of length 27, capacity 32 = {...})
  at ./apt-private/private-cmndline.cc:588
  #7  

[Touch-packages] [Bug 2003331] Re: Can't log in to lunar x11 session

2023-02-23 Thread Gunnar Hjalmarsson
The above observations are with virtualbox 6.1.38-dfsg-3~ubuntu1.22.04.1
on jammy.

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

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

Title:
  Can't log in to lunar x11 session

Status in ubuntu-meta package in Ubuntu:
  New
Status in virtualbox package in Ubuntu:
  New

Bug description:
  On a freshly installed and updated lunar in VirtualBox it doesn't let
  me log in to Ubuntu on Xorg. I'm just bumped back to the login screen.
  journalctl extract attached.

  On my regular (updated) lunar install, logging in to Ubuntu on Xorg
  works fine. But that's anything but a fresh install.

  Missing dependency?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2003331/+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 2003851] Re: occasional hanging 'apt-get update' from daily cronjob since Jammy 22.04

2023-02-23 Thread Walter
Relevant bug in apt-cacher-ng:
https://bugs.launchpad.net/ubuntu/+source/apt-cacher-ng/+bug/1983856

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

Title:
  occasional hanging 'apt-get update' from daily cronjob since Jammy
  22.04

Status in apt package in Ubuntu:
  New

Bug description:
  Hi!

  Yesterday I spotted several machines of ours where a period `apt-get
  update` was stalled. The `http` children were hanging in `WaitFd`
  (waiting for parent instructions/queue). The parent was looping in
  `AcquireUpdate` every 500ms.

  
  We have a cronjob that runs every few hours which calls `apt-get update` and 
does some post-processing. We noticed that several of them had stalled at some 
point in time. Killing the parent (apt-get) got it unstuck, removing the locks.

  Example:
  ```
  # apt-get update
  Reading package lists... Done
  E: Could not get lock /var/lib/apt/lists/lock. It is held by process 154026 
(apt-get)
  N: Be aware that removing the lock file is not a solution and may break your 
system.
  E: Unable to lock directory /var/lib/apt/lists/
  ```

  Task listing:
  ```
  root  153929  \_ /usr/sbin/CRON -f -P
  root  153942  \_ /bin/sh -c  [ -x /etc/zabbix/scripts/dpkg.updates ] 
&& /etc/zabbix/scripts/dpkg.updates --cron
  root  153943  \_ /bin/sh /etc/zabbix/scripts/dpkg.updates --cron
  root  154026  \_ apt-get update
  _apt  154029  \_ /usr/lib/apt/methods/http
  _apt  154030  \_ /usr/lib/apt/methods/http
  _apt  154031  \_ /usr/lib/apt/methods/http
  _apt  154033  \_ /usr/lib/apt/methods/gpgv
  ```
  Open (TCP) sockets. All have 1 item in the Recv-Q (probably a FIN or RST?):
  ```
  # netstat -apn | grep -E '154026|154029|154030|154031|154033'
  tcp  1  0  10.x.x.x:60868  217.x.x.x:80  CLOSE_WAIT  154030/http 
  tcp  1  0  10.x.x.x:40756  178.x.x.x:80  CLOSE_WAIT  154029/http 
  tcp  1  0  10.x.x.x:56818  185.x.x.x:80  CLOSE_WAIT  154031/http 
  ```
  All children (including gpgv) were waiting using pselect6(1, [0], NULL, NULL, 
NULL, NULL).

  The parent (apt-get) was waiting using pselect6(10, [5 6 7 9], [],
  NULL, {tv_sec=0, tv_nsec=5}, NULL).

  The http sockets in the children were at fd=3.

  Parent lsof:
  ```
  # lsof -p 154026 +E
  ...
  apt-get   154026 root4uW  REG8,10  262281 
/var/lib/apt/lists/lock
  apt-get   154026 root5r  FIFO   0,13  0t0 4015176 pipe 154029,http,1w
  apt-get   154026 root6r  FIFO   0,13  0t0 4012448 pipe 154030,http,1w
  apt-get   154026 root7r  FIFO   0,13  0t0 4015192 pipe 154031,http,1w
  apt-get   154026 root8w  FIFO   0,13  0t0 4015177 pipe 154029,http,0r
  apt-get   154026 root9r  FIFO   0,13  0t0 4015233 pipe 154033,gpgv,1w
  apt-get   154026 root   10w  FIFO   0,13  0t0 4012449 pipe 154030,http,0r
  apt-get   154026 root   12w  FIFO   0,13  0t0 4015193 pipe 154031,http,0r
  apt-get   154026 root   14w  FIFO   0,13  0t0 4015234 pipe 154033,gpgv,0r
  http  154029 _apt0r  FIFO   0,13  0t0 4015177 pipe 
154026,apt-get,8w
  http  154029 _apt1w  FIFO   0,13  0t0 4015176 pipe 
154026,apt-get,5r
  http  154030 _apt0r  FIFO   0,13  0t0 4012449 pipe 
154026,apt-get,10w
  http  154030 _apt1w  FIFO   0,13  0t0 4012448 pipe 
154026,apt-get,6r
  http  154031 _apt0r  FIFO   0,13  0t0 4015193 pipe 
154026,apt-get,12w
  http  154031 _apt1w  FIFO   0,13  0t0 4015192 pipe 
154026,apt-get,7r
  gpgv  154033 _apt0r  FIFO   0,13  0t0 4015234 pipe 
154026,apt-get,14w
  gpgv  154033 _apt1w  FIFO   0,13  0t0 4015233 pipe 
154026,apt-get,9r
  ```
  So:
  - apt-get is waiting for any data written by any of its four children (at fd 
5/6/7/9)
  - http and gpgv are waiting for any data written by their parent (at their 
respective fd 0)

  Parent backtrace:
  ```
  #0  0x7f420116a74d in select ()
 from /lib/x86_64-linux-gnu/libc.so.6
  #1  0x7f420153fb5d in pkgAcquire::Run(int) ()
 from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
  #2  0x7f420161d535 in AcquireUpdate(pkgAcquire&, int, bool, bool) ()
 from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
  #3  0x7f420161d986 in ListUpdate(pkgAcquireStatus&, pkgSourceList&, int) 
()
 from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
  #4  0x7f42016d127b in DoUpdate (CmdL=...)
  at ./apt-private/private-update.cc:73
  #5  0x7f420156d73f in CommandLine::DispatchArg(CommandLine::Dispatch 
const*, bool) ()
 from /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
  #6  0x7f420169fa97 in DispatchCommandLine (CmdL=..., 
  Cmds=std::vector of length 27, capacity 32 = {...})
  at ./apt-private/private-cmndline.cc:588
  #7  0x561fc06bafbd in main (argc=2, 

[Touch-packages] [Bug 2003851] Re: occasional hanging 'apt-get update' from daily cronjob since Jammy 22.04

2023-02-23 Thread Walter
Got some more pcaps. I can also reproduce by sending a 503 after a 200,
without aborting during/before body transfer (*).


server.py logs

13:29:55 [3666956] client said: b'GET /ubuntu/dists/jammy/InRelease 
HTTP/1.1\r\nHost: junk.devs.nu:3851\r\nCache-Control: max-age=0\r\nAccept: 
text/*\r\nUser-Agent: Debian APT-HTTP/1.3 (2.4.9) non-interactive\r\n\r\n'
13:29:55 [3666956] we say: 200 and serve local InRelease
13:29:55 [3666956] client said: b'GET /ubuntu/dists/jammy-updates/InRelease 
HTTP/1.1\r\nHost: junk.devs.nu:3851\r\nCache-Control: max-age=0\r\nAccept: 
text/*\r\nUser-Agent: Debian APT-HTTP/1.3 (2.4.9) non-interactive\r\n\r\n'
13:29:55 [3666956] we say: 503


503 request/response (valid length, no early FIN)

GET /ubuntu/dists/jammy-updates/InRelease HTTP/1.1
Host: junk.devs.nu:3851
Cache-Control: max-age=0
Accept: text/*
User-Agent: Debian APT-HTTP/1.3 (2.4.9) non-interactive


HTTP/1.1 503 OK
date: Fri, 17 Feb 2023 15:11:49 GMT
content-type: text/plain
content-length: 19

something is broken



I present to you:

- https://junk.devs.nu/2023/lp2003851/not-reproduced-port-34634.txt
- https://junk.devs.nu/2023/lp2003851/not-reproduced-port-34634.pcap
- https://junk.devs.nu/2023/lp2003851/reproduced-port-58014.txt
- https://junk.devs.nu/2023/lp2003851/reproduced-port-58014.pcap

In the not-reproduced case, the error is acknowledged and the download
is retried. Then it fails quickly.

In the reproduced case, the error is not acknowledged, and the result is
a hanging apt-get. Logs ending with:

Hit:3 http://repo.zabbix.com/zabbix/6.2/ubuntu jammy InRelease
0% [Working]


(*) observed in the wild with these req/resp:

GET /ubuntu/dists/jammy-backports/InRelease HTTP/1.1
Host: apt.osso.nl
Cache-Control: max-age=0
Accept: text/*
If-Modified-Since: Tue, 21 Feb 2023 19:32:00 GMT
User-Agent: Debian APT-HTTP/1.3 (2.4.8) non-interactive

HTTP/1.1 200 OK
date: Wed, 22 Feb 2023 02:36:08 GMT
content-type: octet/stream
content-length: 106807
last-modified: Wed, 22 Feb 2023 01:49:00 GMT
x-original-source: 
http://nl.archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease
(+ valid body)

GET /ubuntu-security/dists/jammy-security/InRelease HTTP/1.1
Host: apt.osso.nl
Cache-Control: max-age=0
Accept: text/*
If-Modified-Since: Tue, 21 Feb 2023 23:11:00 GMT
User-Agent: Debian APT-HTTP/1.3 (2.4.8) non-interactive

HTTP/1.1 503 Connection timeout
date: Wed, 22 Feb 2023 02:36:08 GMT
content-type: text/html
content-length: 486
(+ valid body)


extra contemplations:

We've only recently added the /ubuntu-security/ (extra path, on the same 
server). Maybe that is the reason why this is biting us right now.

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

Title:
  occasional hanging 'apt-get update' from daily cronjob since Jammy
  22.04

Status in apt package in Ubuntu:
  New

Bug description:
  Hi!

  Yesterday I spotted several machines of ours where a period `apt-get
  update` was stalled. The `http` children were hanging in `WaitFd`
  (waiting for parent instructions/queue). The parent was looping in
  `AcquireUpdate` every 500ms.

  
  We have a cronjob that runs every few hours which calls `apt-get update` and 
does some post-processing. We noticed that several of them had stalled at some 
point in time. Killing the parent (apt-get) got it unstuck, removing the locks.

  Example:
  ```
  # apt-get update
  Reading package lists... Done
  E: Could not get lock /var/lib/apt/lists/lock. It is held by process 154026 
(apt-get)
  N: Be aware that removing the lock file is not a solution and may break your 
system.
  E: Unable to lock directory /var/lib/apt/lists/
  ```

  Task listing:
  ```
  root  153929  \_ /usr/sbin/CRON -f -P
  root  153942  \_ /bin/sh -c  [ -x /etc/zabbix/scripts/dpkg.updates ] 
&& /etc/zabbix/scripts/dpkg.updates --cron
  root  153943  \_ /bin/sh /etc/zabbix/scripts/dpkg.updates --cron
  root  154026  \_ apt-get update
  _apt  154029  \_ /usr/lib/apt/methods/http
  _apt  154030  \_ /usr/lib/apt/methods/http
  _apt  154031  \_ /usr/lib/apt/methods/http
  _apt  154033  \_ /usr/lib/apt/methods/gpgv
  ```
  Open (TCP) sockets. All have 1 item in the Recv-Q (probably a FIN or RST?):
  ```
  # netstat -apn | grep -E '154026|154029|154030|154031|154033'
  tcp  1  0  10.x.x.x:60868  217.x.x.x:80  CLOSE_WAIT  154030/http 
  tcp  1  0  10.x.x.x:40756  178.x.x.x:80  CLOSE_WAIT  154029/http 
  tcp  1  0  10.x.x.x:56818  185.x.x.x:80  CLOSE_WAIT  154031/http 
  ```
  All children (including gpgv) 

[Touch-packages] [Bug 1906333] Re: Missing dep8 tests

2023-02-23 Thread Launchpad Bug Tracker
This bug was fixed in the package rsyslog - 8.2210.0-3ubuntu2

---
rsyslog (8.2210.0-3ubuntu2) lunar; urgency=medium

  * Support apparmor profile snippets:
- d/usr.sbin.rsyslogd: add "include if exists" for the rsyslog.d
  directory, and remove the now unnecessary  mysql and postgresql
  sections
- d/rsyslog.preinst: don't disable the apparmor profile on install
- d/rsyslog.postinst: remove disabling of apparmor on upgrades if we
  are upgrading from a version older than $now.
- d/rsyslog.dirs: install /etc/apparmor.d/rsyslog.d/
- d/{apparmor/rsyslog-mysql,rsyslog-mysql.install}: add apparmor
  profile for mysql plugin
- d/{apparmor/rsyslog-pgsql,rsyslog-pgsql.install}: add apparmor
  profile for postgresql plugin
- d/{apparmor/rsyslog-gnutls.apparmor,rsyslog-gnutls.install}: add
  apparmor profile for the gnutls plugin
- d/{apparmor/rsyslog-openssl.apparmor,rsyslog-gnutls.install}: add
  apparmor profile for the openssl plugin
- New script to reload apparmor profile:
  + d/rsyslog.service: reload apparmor profile in ExecStartPre and
set StandardError to journal so we can see errors from the
script
  + d/rsyslog.install: install reload-apparmor-profile
  + d/reload-apparmor-profile: script to reload the
rsyslogd apparmor profile
- d/NEWS: add info about apparmor changes in the Ubuntu packaging
- d/rsyslog.docs, d/README.apparmor: explains how the dynamic
  component of the rsyslog apparmor profile is applied
- d/README.apparmor.rsyslog.d, d/rsyslog.install: install a specific
  README file in the apparmor include directory for rsyslog
  * Add DEP8 tests (LP: #1906333):
- d/t/control, d/t/simple-logger: simple logger test
- d/t/utils: common function(s)
- d/t/control, d/t/simple-mysql: DEP8 test using rsyslog with a
  MySQL server
- d/t/control, d/t/simple-pgsql: DEP8 test using rsyslog with a
  PostgreSQL server
- d/t/apparmor-include-mechanism: DEP8 test for the rsyslog.d
  include mechanism used by the rsyslog apparmor profile

 -- Andreas Hasenack   Fri, 17 Feb 2023 14:22:27
-0300

** Changed in: rsyslog (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  Missing dep8 tests

Status in rsyslog package in Ubuntu:
  Fix Released

Bug description:
  rsyslog is missing dep8 tests, which would be really good to have
  given the importance of this package and the amount of delta we're
  currently carrying.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1906333/+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 2007828] Re: /usr/bin/software-properties-gtk:http.client.RemoteDisconnected:poll_for_magic_token:wait:_wait:get_magic_attach_token_info:request_url:readurl:urlopen:open:_open:_c

2023-02-23 Thread Nathan Teodosio
This should be fixed on 0.99.22.6, which catches all exceptions to
wait().

** Changed in: software-properties (Ubuntu)
   Status: New => Fix Committed

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

Title:
  /usr/bin/software-properties-
  
gtk:http.client.RemoteDisconnected:poll_for_magic_token:wait:_wait:get_magic_attach_token_info:request_url:readurl:urlopen:open:_open:_call_chain:https_open:do_open:getresponse:begin:_read_status

Status in software-properties package in Ubuntu:
  Fix Committed

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.99.22.5, the problem page at 
https://errors.ubuntu.com/problem/14dff5c7440aa4c34eafc2c75fbbad24211c0e85 
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/.

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